Hello:
This patch was applied to netdev/net.git (refs/heads/master):
On Fri, 23 Oct 2020 14:32:36 +1100 you wrote:
> Clang warns about the extra parentheses in this comparison:
>
> drivers/net/ethernet/freescale/ucc_geth.c:1361:28:
> warning: equality comparison with extraneous parentheses
On Fri, 23 Oct 2020 14:32:36 +1100 Michael Ellerman wrote:
> Clang warns about the extra parentheses in this comparison:
>
> drivers/net/ethernet/freescale/ucc_geth.c:1361:28:
> warning: equality comparison with extraneous parentheses
> if ((ugeth->phy_interface ==
From: Segher Boessenkool
> Sent: 23 October 2020 19:27
>
> On Fri, Oct 23, 2020 at 06:58:57PM +0100, Al Viro wrote:
> > On Fri, Oct 23, 2020 at 03:09:30PM +0200, David Hildenbrand wrote:
> >
> > > Now, I am not a compiler expert, but as I already cited, at least on
> > > x86-64 clang expects that
On Fri, Oct 23, 2020 at 10:03 AM Joe Perches wrote:
>
> Thanks Miguel, but IMO it doesn't need time in next.
You're welcome! It never hurts to keep things for a bit there.
> Applying it just before an rc1 minimizes conflicts.
There shouldn't be many conflicts after -rc1. The amount of changes
On Fri, Oct 23, 2020 at 06:58:57PM +0100, Al Viro wrote:
> On Fri, Oct 23, 2020 at 03:09:30PM +0200, David Hildenbrand wrote:
>
> > Now, I am not a compiler expert, but as I already cited, at least on
> > x86-64 clang expects that the high bits were cleared by the caller - in
> > contrast to gcc.
On Fri, Oct 23, 2020 at 03:09:30PM +0200, David Hildenbrand wrote:
> Now, I am not a compiler expert, but as I already cited, at least on
> x86-64 clang expects that the high bits were cleared by the caller - in
> contrast to gcc. I suspect it's the same on arm64, but again, I am no
> compiler
On 23.10.20 16:47, 'Greg KH' wrote:
> On Fri, Oct 23, 2020 at 02:39:24PM +, David Laight wrote:
>> From: David Hildenbrand
>>> Sent: 23 October 2020 15:33
>> ...
>>> I just checked against upstream code generated by clang 10 and it
>>> properly discards the upper 32bit via a mov w23 w2.
>>>
On Fri, Oct 23, 2020 at 02:39:24PM +, David Laight wrote:
> From: David Hildenbrand
> > Sent: 23 October 2020 15:33
> ...
> > I just checked against upstream code generated by clang 10 and it
> > properly discards the upper 32bit via a mov w23 w2.
> >
> > So at least clang 10 indeed properly
From: David Hildenbrand
> Sent: 23 October 2020 15:33
...
> I just checked against upstream code generated by clang 10 and it
> properly discards the upper 32bit via a mov w23 w2.
>
> So at least clang 10 indeed properly assumes we could have garbage and
> masks it off.
>
> Maybe the issue is
On 23.10.20 15:09, David Hildenbrand wrote:
> On 23.10.20 14:46, David Laight wrote:
>> From: Greg KH
>>> Sent: 22 October 2020 14:51
>>
>> I've rammed the code into godbolt.
>>
>> https://godbolt.org/z/9v5PPW
>>
>> Definitely a clang bug.
>>
>> Search for [wx]24 in the clang output.
>> nr_segs
Hi Christophe, Will,
On 10/23/20 12:57 PM, Christophe Leroy wrote:
>
>
> Le 23/10/2020 à 13:25, Will Deacon a écrit :
>> On Fri, Oct 23, 2020 at 01:22:04PM +0200, Christophe Leroy wrote:
>>> Hi Dmitry,
[..]
>>> I haven't seen the patches, did you sent them out finally ?
I was working on
From: Arnd Bergmann
> Sent: 23 October 2020 14:23
>
> On Fri, Oct 23, 2020 at 2:46 PM David Laight wrote:
> >
> > From: Greg KH
> > > Sent: 22 October 2020 14:51
> >
> > I've rammed the code into godbolt.
> >
> > https://godbolt.org/z/9v5PPW
> >
> > Definitely a clang bug.
> >
> > Search for
Christophe Leroy writes:
> Le 24/09/2020 à 15:17, Christophe Leroy a écrit :
>> Le 17/09/2020 à 14:33, Michael Ellerman a écrit :
>>> Christophe Leroy writes:
What is the status with the generic C vdso merge ?
In some mail, you mentionned having difficulties getting it working on
On Fri, Oct 23, 2020 at 2:46 PM David Laight wrote:
>
> From: Greg KH
> > Sent: 22 October 2020 14:51
>
> I've rammed the code into godbolt.
>
> https://godbolt.org/z/9v5PPW
>
> Definitely a clang bug.
>
> Search for [wx]24 in the clang output.
> nr_segs comes in as w2 and the initial bound
On 22.10.20 21:24, Al Viro wrote:
> On Thu, Oct 22, 2020 at 12:04:52PM -0700, Nick Desaulniers wrote:
>
>> Passing an `unsigned long` as an `unsigned int` does no such
>> narrowing: https://godbolt.org/z/TvfMxe (same vice-versa, just tail
>> calls, no masking instructions).
>> So if
On 23.10.20 14:46, David Laight wrote:
> From: Greg KH
>> Sent: 22 October 2020 14:51
>
> I've rammed the code into godbolt.
>
> https://godbolt.org/z/9v5PPW
>
> Definitely a clang bug.
>
> Search for [wx]24 in the clang output.
> nr_segs comes in as w2 and the initial bound checks are done
From: Greg KH
> Sent: 22 October 2020 14:51
I've rammed the code into godbolt.
https://godbolt.org/z/9v5PPW
Definitely a clang bug.
Search for [wx]24 in the clang output.
nr_segs comes in as w2 and the initial bound checks are done on w2.
w24 is loaded from w2 - I don't believe this changes
Hi Laurent
Le 07/05/2019 à 18:35, Laurent Dufour a écrit :
Le 01/05/2019 à 12:32, Michael Ellerman a écrit :
Laurent Dufour writes:
Le 23/04/2019 à 18:04, Dave Hansen a écrit :
On 4/23/19 4:16 AM, Laurent Dufour wrote:
...
There are 2 assumptions here:
1. 'start' and 'end' are page
Le 23/10/2020 à 13:25, Will Deacon a écrit :
On Fri, Oct 23, 2020 at 01:22:04PM +0200, Christophe Leroy wrote:
Hi Dmitry,
Le 28/09/2020 à 17:08, Dmitry Safonov a écrit :
On 9/27/20 8:43 AM, Christophe Leroy wrote:
Le 21/09/2020 à 13:26, Will Deacon a écrit :
On Fri, Aug 28, 2020 at
On Fri, Oct 23, 2020 at 01:22:04PM +0200, Christophe Leroy wrote:
> Hi Dmitry,
>
> Le 28/09/2020 à 17:08, Dmitry Safonov a écrit :
> > On 9/27/20 8:43 AM, Christophe Leroy wrote:
> > >
> > >
> > > Le 21/09/2020 à 13:26, Will Deacon a écrit :
> > > > On Fri, Aug 28, 2020 at 12:14:28PM +1000,
Hi Dmitry,
Le 28/09/2020 à 17:08, Dmitry Safonov a écrit :
On 9/27/20 8:43 AM, Christophe Leroy wrote:
Le 21/09/2020 à 13:26, Will Deacon a écrit :
On Fri, Aug 28, 2020 at 12:14:28PM +1000, Michael Ellerman wrote:
Dmitry Safonov <0x7f454...@gmail.com> writes:
[..]
I'll cook a patch for
+static void __init fixup_cpu_features(void)
+{
+ unsigned long version = mfspr(SPRN_PVR);
+
+ if ((version & 0x) == 0x00800100)
+ cur_cpu_spec->cpu_features |= CPU_FTR_POWER10_DD1;
+}
+
I am just wondering why this is needed here, but the same thing is not
On Fri, 2020-10-23 at 11:57 +1100, Michael Ellerman wrote:
>
>
> Joakim Tjernlund writes:
> > Embedded PPC CPU should send SIGBUS to user space when applicable.
>
> Yeah, but it's not clear that it's applicable in all cases.
>
> At least I need some reasoning for why it's safe in all cases
On Fri, 2020-10-23 at 08:08 +0200, Miguel Ojeda wrote:
> On Thu, Oct 22, 2020 at 4:36 AM Joe Perches wrote:
> >
> > Use a more generic form for __section that requires quotes to avoid
> > complications with clang and gcc differences.
>
> I performed visual inspection (one by one...) and the
Hi Michael,
Le 24/09/2020 à 15:17, Christophe Leroy a écrit :
Hi Michael
Le 17/09/2020 à 14:33, Michael Ellerman a écrit :
Hi Christophe,
Christophe Leroy writes:
Hi Michael,
What is the status with the generic C vdso merge ?
In some mail, you mentionned having difficulties getting it
On Thu, Oct 22, 2020 at 4:36 AM Joe Perches wrote:
>
> Use a more generic form for __section that requires quotes to avoid
> complications with clang and gcc differences.
I performed visual inspection (one by one...) and the only thing I saw
is that sometimes the `__attribute__` has a whitespace
26 matches
Mail list logo
