[PATCH -next v5 10/23] iio: imu: smi330: #undef field_{get,prep}() before definition

[Jonathan Cameron]

On Mon, 10 Nov 2025 09:59:34 +0100
Geert Uytterhoeven <geert at linux-m68k.org> wrote:

> Hi Jonathan,

Hi Geert,

> 
> On Sun, 9 Nov 2025 at 14:01, Jonathan Cameron <jic23 at kernel.org> wrote:
> > On Mon, 3 Nov 2025 11:09:36 +0100
> > Geert Uytterhoeven <geert at linux-m68k.org> wrote:  
> > > On Sun, 2 Nov 2025 at 11:43, Jonathan Cameron <jic23 at kernel.org> wrote:  
> > > > On Mon, 27 Oct 2025 19:41:44 +0100
> > > > Geert Uytterhoeven <geert+renesas at glider.be> wrote:
> > > >  
> > > > > Prepare for the advent of globally available common field_get() and
> > > > > field_prep() macros by undefining the symbols before defining local
> > > > > variants.  This prevents redefinition warnings from the C preprocessor
> > > > > when introducing the common macros later.
> > > > >
> > > > > Suggested-by: Yury Norov <yury.norov at gmail.com>
> > > > > Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>  
> > > >
> > > > So this is going to make a mess of merging your series given this is
> > > > queued up for next merge window.
> > > >
> > > > I can pick this one up perhaps and we loop back to the replacement of
> > > > these in a future patch?  Or perhaps go instead with a rename
> > > > of these two which is probably nicer in the intermediate state than
> > > > undefs.  
> > >
> > > Renaming would mean a lot of churn.
> > > Just picking up the #undef patch should be simple and safe? The
> > > removal of the underf and redef can be done in the next cycle.
> > > Thanks!  
> >
> > Only 1 call of each of these in the driver, so churn is small either way.
> >
> > To avoid a bisection problem if your tree merges first I need to modify
> > this stuff in the original patch or leave it for Linus to deal with as
> > a merge conflict resolution which is mess I'd rather do without.  
> 
> If you add the #undef, there won't be any bisection problem?

Two different things.  The bisection comment was about squashing into the
original driver patch - not what was squashed.  Your tree may well merge
before mine does and a bisection could therefore land in between the 
driver introduction and a patch I merge today.

The rename is a preference only because I don't want an undef that smells
like a hack / bug work around kicking around in the tree for significant time
(probably a whole kernel cycle). In this case the churn is very similar
with that or a rename of the macros - so rename it is.

Jonathan

 
> Gr{oetje,eeting}s,
> 
>                         Geert
>