[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z9mZ_xIMyqUg2Vs9@thinkpad>
Date: Tue, 18 Mar 2025 12:06:23 -0400
From: Yury Norov <yury.norov@...il.com>
To: Vincent Mailhol <mailhol.vincent@...adoo.fr>
Cc: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Lucas De Marchi <lucas.demarchi@...el.com>,
Rasmus Villemoes <linux@...musvillemoes.dk>,
Jani Nikula <jani.nikula@...ux.intel.com>,
Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>,
Rodrigo Vivi <rodrigo.vivi@...el.com>,
Tvrtko Ursulin <tursulin@...ulin.net>,
David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org, intel-gfx@...ts.freedesktop.org,
dri-devel@...ts.freedesktop.org,
Andi Shyti <andi.shyti@...ux.intel.com>,
David Laight <David.Laight@...lab.com>,
Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
Subject: Re: [PATCH v6 1/7] bits: split the definition of the asm and non-asm
GENMASK()
On Sat, Mar 08, 2025 at 06:10:25PM +0900, Vincent Mailhol wrote:
> On 08/03/2025 at 02:42, Andy Shevchenko wrote:
> > On Sat, Mar 08, 2025 at 01:48:48AM +0900, Vincent Mailhol via B4 Relay wrote:
> >> From: Vincent Mailhol <mailhol.vincent@...adoo.fr>
> >>
> >> In an upcoming change, GENMASK() and its friends will indirectly
> >> depend on sizeof() which is not available in asm.
> >>
> >> Instead of adding further complexity to __GENMASK() to make it work
> >> for both asm and non asm, just split the definition of the two
> >> variants.
> >
> > ...
> >
> >> -/*
> >> - * BUILD_BUG_ON_ZERO is not available in h files included from asm files,
> >> - * disable the input check if that is the case.
> >> - */
> >
> >> +/*
> >> + * BUILD_BUG_ON_ZERO() is not available in h files included from asm files, so
> >> + * no input checks in assembly.
> >> + */
> >
> > In case of a new version I would reformat this as
> >
> > /*
> > * BUILD_BUG_ON_ZERO() is not available in h files included from asm files,
> > * so no input checks in assembly.
> > */
> >
> > It makes easier to review the changes and see that the first line is kept
> > the same.
>
> Not fully convinced, but why not. I staged this change locally, it will
> be in v7.
I don't understand why this change is needed at all. The comment
states the same thing before and after, but the history gets wiped.
Maybe just don't touch it?
Powered by blists - more mailing lists