From: Hans de Goede
> Sent: 10 February 2023 19:33
>
> Hi,
>
> On 2/10/23 20:09, Hans de Goede wrote:
> > Hi,
> >
> > On 2/10/23 05:48, Orlando Chamberlain wrote:
> >> Currently it manually flips the byte order, but we can instead use
> >> cpu_to_be32(val) for this.
> >>
> >> Signed-off-by:
From: Segher Boessenkool
> Sent: 20 January 2023 10:54
...
> > > I suggest to file a bug against gcc complaining about a "spurious
> > > warning", and using "-Werror -Wno-error-sizeof-pointer-div" until gcc is
> > > adapted to not emit the warning about the pointer division if the result
> > > is
From: Hamza Mahfooz
> Sent: 18 August 2022 17:49
>
> Addresses the following warning:
> drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn30/display_mode_vba_30.c:3596:6:
> error: stack frame
> size (2092) exceeds limit (2048) in
> 'dml30_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-
>
From: Arnd Bergmann
> Sent: 05 August 2022 20:32
...
> One thing to try would be to condense a function call like
>
> dml32_CalculateWatermarksMALLUseAndDRAMSpeedChangeSupport(
>
...
> /* more arguments */);
>
> into calling conventions that take a
...
> * NOTE:
> * This file is gcc-parsable HW gospel, coming straight from HW engineers.
I never trust hardware engineers to write code :-)
(Although at the moment they trust me to write VHDL...)
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
From: Dan Carpenter
> Sent: 07 March 2022 15:01
>
> Updating this API is risky because some places rely on the old behavior
> and not all of them have been updated. Here are some additional places
> you might want to change.
I really can't help thinking that trying to merge this patch is
From: Xiaomeng Tong
> Sent: 03 March 2022 07:27
>
> On Thu, 3 Mar 2022 04:58:23 +0000, David Laight wrote:
> > on 3 Mar 2022 10:27:29 +0800, Xiaomeng Tong wrote:
> > > The problem is the mis-use of iterator outside the loop on exit, and
> > > the iterator will b
From: Xiaomeng Tong
> Sent: 03 March 2022 02:27
>
> On Wed, 2 Mar 2022 14:04:06 +0000, David Laight
> wrote:
> > I think that it would be better to make any alternate loop macro
> > just set the variable to NULL on the loop exit.
> > That is easier to code for and t
From: Xiaomeng Tong
> Sent: 02 March 2022 09:31
>
> On Mon, 28 Feb 2022 16:41:04 -0800, Linus Torvalds
> wrote:
> >
> > But basically to _me_, the important part is that the end result is
> > maintainable longer-term.
>
> I couldn't agree more. And because of that, I stick with the following
>
From: Linus Torvalds
> Sent: 01 March 2022 19:07
> On Mon, Feb 28, 2022 at 2:29 PM James Bottomley
> wrote:
> >
> > However, if the desire is really to poison the loop variable then we
> > can do
> >
> > #define list_for_each_entry(pos, head, member) \
> > for
From: Linus Torvalds
> Sent: 01 March 2022 23:03
>
> On Tue, Mar 1, 2022 at 2:58 PM David Laight wrote:
> >
> > Can it be resolved by making:
> > #define list_entry_is_head(pos, head, member) ((pos) == NULL)
> > and double-checking that it isn't used anywhere el
From: Linus Torvalds
> Sent: 28 February 2022 19:56
> On Mon, Feb 28, 2022 at 4:19 AM Christian König
> wrote:
> >
> > I don't think that using the extra variable makes the code in any way
> > more reliable or easier to read.
>
> So I think the next step is to do the attached patch (which
From: Matthew Wilcox
> Sent: 28 February 2022 20:16
>
> On Mon, Feb 28, 2022 at 12:10:24PM -0800, Linus Torvalds wrote:
> > We can do
> >
> > typeof(pos) pos
> >
> > in the 'for ()' loop, and never use __iter at all.
> >
> > That means that inside the for-loop, we use a _different_ 'pos'
From: t...@redhat.com
> Sent: 26 February 2022 15:59
>
> From: Tom Rix
>
> Clang static analysis reports this error
> amdgpu_debugfs.c:1690:9: warning: 1st function call
> argument is an uninitialized value
> tmp = krealloc_array(tmp, i + 1,
> ^~~
>
>
...
> Yeah, and I am sorry for bikeshedding. Honestly, I do not know what is
> better. This is why I do not want to block this series when others
> like this.
>
> My main motivation is to point out that:
>
> enabledisable(enable)
>
> might be, for some people, more eye bleeding than
>
>
> > except '"no\0\0yes" + v * 4' works a bit better.
>
> Is it a C code obfuscation contest?
That would be:
return &(v * 3)["no\0yes"];
:-)
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
UK
Registration No: 1397386 (Wales)
> > > +static inline const char *yesno(bool v) { return v ? "yes" : "no"; }
return "yes\0no" + v * 4;
:-)
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
UK
Registration No: 1397386 (Wales)
> > > > +static inline const char *yesno(bool v) { return v ? "yes" : "no"; }
>
> return "yes\0no" + v * 4;
>
> :-)
except '"no\0\0yes" + v * 4' works a bit better.
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
UK
Registration No: 1397386 (Wales)
From: Greg KH
> Sent: 02 November 2020 20:11
>
> On Mon, Nov 02, 2020 at 02:43:45PM -0500, Alex Deucher wrote:
> > On Mon, Nov 2, 2020 at 1:42 PM Deepak R Varma wrote:
> > >
> > > Initializing global variable to 0 or NULL is not necessary and should
> > > be avoided. Issue reported by checkpatch
From: Christian König
> Sent: 15 April 2020 08:57
> Am 15.04.20 um 09:41 schrieb Jani Nikula:
> > On Tue, 14 Apr 2020, Alex Deucher wrote:
> >> On Tue, Apr 14, 2020 at 9:05 AM Bernard Zhao wrote:
> >>> On some processors, the / operate will call the compiler`s div lib,
> >>> which is low
From: Arnd Bergmann
> Sent: 15 October 2019 08:19
>
> On Tue, Oct 15, 2019 at 9:08 AM S, Shirish wrote:
> > On 10/15/2019 3:52 AM, Nick Desaulniers wrote:
>
> > My gcc build fails with below errors:
> >
> > dcn_calcs.c:1:0: error: -mpreferred-stack-boundary=3 is not between 4 and 12
> >
> >
21 matches
Mail list logo
