On 08/26/2018 08:08 PM, Masahiro Yamada wrote:
> Commit cafa0010cd51 ("Raise the minimum required gcc version to 4.6")
> bumped the minimum GCC version to 4.6 for all architectures.
>
> With GCC >= 4.6 assumed, 'upto_gcc44' is empty, 'atleast_gcc44' is y.
>
> Signed-off-by: Masahiro Yamada
Added
On 08/30/2018 02:51 AM, Will Deacon wrote:
> Yeah, the bit_spin_lock()/__bit_spin_unlock() race described in f75d48644c56a
> boils down to concurrent atomic_long_set_release() vs
> atomic_long_fetch_or_acquire(), which really needs to work.
I don't see how: __clear_bit_unlock() reads @old, flips a
On 08/30/2018 01:45 PM, Peter Zijlstra wrote:
>>
>> Indeed this is the mother of all issues, I tried and system is clearly hosed
>> with
>> and works after.
>> What's amazing is the commit 4aef66c8ae9 which introduced it is from 2016 ;-)
>> Back then we had a retry branch with backoff stuff which
On 08/30/2018 02:44 AM, Peter Zijlstra wrote:
>> Back in 2016, Peter had fixed this file due to a problem I reported on ARC.
>> See
>> commit f75d48644c56a ("bitops: Do not default to __clear_bit() for
>> __clear_bit_unlock()")
>> That made __clear_bit_unlock() use the atomic clear_bit() vs. non-a
On Thu, Aug 30, 2018 at 08:31:59PM +, Vineet Gupta wrote:
> On 08/30/2018 07:29 AM, Peter Zijlstra wrote:
> > On Thu, Aug 30, 2018 at 03:23:55PM +0100, Will Deacon wrote:
> >
> >> Yes, that would be worth trying. However, I also just noticed that the
> >> fetch-ops (which are now used to implem
On 08/30/2018 07:29 AM, Peter Zijlstra wrote:
> On Thu, Aug 30, 2018 at 03:23:55PM +0100, Will Deacon wrote:
>
>> Yes, that would be worth trying. However, I also just noticed that the
>> fetch-ops (which are now used to implement test_and_set_bit_lock()) seem
>> to be missing the backwards branch
On Thu, 2018-08-30 at 10:43 +0200, Linus Walleij wrote:
> On Tue, Aug 28, 2018 at 1:27 PM Eugeniy Paltsev
> wrote:
>
> > +++ b/Documentation/devicetree/bindings/gpio/snps,creg-gpio.txt
> > @@ -0,0 +1,49 @@
> > +GPIO via CREG (Control REGisers) driver
[snip]
> > +- snps,ngpios: Number of GPIO pin
On Thu, Aug 30, 2018 at 02:46:16PM +, Eugeniy Paltsev wrote:
> On Thu, 2018-08-30 at 16:17 +0200, Peter Zijlstra wrote:
> > On Thu, Aug 30, 2018 at 11:53:17AM +, Eugeniy Paltsev wrote:
> > > I can see crashes with LLSC enabled in both SMP running on 4 cores
> > > and SMP running on 1 core.
On Thu, 2018-08-30 at 16:17 +0200, Peter Zijlstra wrote:
> On Thu, Aug 30, 2018 at 11:53:17AM +, Eugeniy Paltsev wrote:
> > I can see crashes with LLSC enabled in both SMP running on 4 cores
> > and SMP running on 1 core.
>
> So you're running on LL/SC enabled hardware; that would make Will's
On Thu, Aug 30, 2018 at 04:29:20PM +0200, Peter Zijlstra wrote:
> Also, once it all works, they should look at switching to _relaxed
> atomics for LL/SC.
A little something like so.. should save a few smp_mb().
---
diff --git a/arch/arc/include/asm/atomic.h b/arch/arc/include/asm/atomic.h
index
On Thu, Aug 30, 2018 at 03:23:55PM +0100, Will Deacon wrote:
> Yes, that would be worth trying. However, I also just noticed that the
> fetch-ops (which are now used to implement test_and_set_bit_lock()) seem
> to be missing the backwards branch in the LL/SC case. Yet another diff
> below.
>
> Wi
On Thu, Aug 30, 2018 at 04:17:13PM +0200, Peter Zijlstra wrote:
> On Thu, Aug 30, 2018 at 11:53:17AM +, Eugeniy Paltsev wrote:
> > I can see crashes with LLSC enabled in both SMP running on 4 cores
> > and SMP running on 1 core.
>
> So you're running on LL/SC enabled hardware; that would make
On Thu, Aug 30, 2018 at 11:53:17AM +, Eugeniy Paltsev wrote:
> I can see crashes with LLSC enabled in both SMP running on 4 cores
> and SMP running on 1 core.
So you're running on LL/SC enabled hardware; that would make Will's
patch irrelevant (although still a good idea for the hardware that
Hi Eugeniy,
On Thu, Aug 30, 2018 at 11:53:17AM +, Eugeniy Paltsev wrote:
> On Thu, 2018-08-30 at 10:51 +0100, Will Deacon wrote:
> > On Thu, Aug 30, 2018 at 11:44:11AM +0200, Peter Zijlstra wrote:
> > > On Wed, Aug 29, 2018 at 09:16:43PM +, Vineet Gupta wrote:
> > > > On 08/29/2018 11:33 A
On Tue, 2018-08-28 at 20:02 -0500, Rob Herring wrote:
> On Tue, Aug 28, 2018 at 02:27:21PM +0300, Eugeniy Paltsev wrote:
> > This patch adds documentation of device tree bindings for the Synopsys
> > GPIO via CREG driver.
> >
> > Signed-off-by: Eugeniy Paltsev
> > ---
> > .../devicetree/bindings
On Tue, 2018-08-28 at 11:15 -0700, Randy Dunlap wrote:
> Hi,
>
> I don't see any updates/corrections here. :(
My fault - I've forgotten to re-generate new patch via git format-patch
and send you previous version.
>
> On 08/28/2018 04:27 AM, Eugeniy Paltsev wrote:
>
> > diff --git a/drivers/gp
Hi Will,
On Thu, 2018-08-30 at 10:51 +0100, Will Deacon wrote:
> On Thu, Aug 30, 2018 at 11:44:11AM +0200, Peter Zijlstra wrote:
> > On Wed, Aug 29, 2018 at 09:16:43PM +, Vineet Gupta wrote:
> > > On 08/29/2018 11:33 AM, Eugeniy Paltsev wrote:
> > > > Hi Guys,
> > > > Since v4.19-rc1 we are ge
On Thu, Aug 30, 2018 at 11:44:11AM +0200, Peter Zijlstra wrote:
> On Wed, Aug 29, 2018 at 09:16:43PM +, Vineet Gupta wrote:
> > On 08/29/2018 11:33 AM, Eugeniy Paltsev wrote:
> > > Hi Guys,
> > > Since v4.19-rc1 we are getting a serious regression on platforms with ARC
> > > architecture.
> >
On Wed, Aug 29, 2018 at 09:16:43PM +, Vineet Gupta wrote:
> On 08/29/2018 11:33 AM, Eugeniy Paltsev wrote:
> > Hi Guys,
> > Since v4.19-rc1 we are getting a serious regression on platforms with ARC
> > architecture.
> > The kernel have become unstable and spontaneously crashes on LTP tests
>
On Wed, Aug 29, 2018 at 09:16:43PM +, Vineet Gupta wrote:
> On 08/29/2018 11:33 AM, Eugeniy Paltsev wrote:
> > Hi Guys,
> > Since v4.19-rc1 we are getting a serious regression on platforms with ARC
> > architecture.
> > The kernel have become unstable and spontaneously crashes on LTP tests
>
On Tue, Aug 28, 2018 at 1:27 PM Eugeniy Paltsev
wrote:
> +++ b/Documentation/devicetree/bindings/gpio/snps,creg-gpio.txt
> @@ -0,0 +1,49 @@
> +GPIO via CREG (Control REGisers) driver
Speling
Also should be "Synopsys GPIO via CREG" as this is likely just
for Synopsys and not general purpose.
>
21 matches
Mail list logo
