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@gmail.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
--
v5:
  - New.
---
 drivers/iio/imu/smi330/smi330_core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/iio/imu/smi330/smi330_core.c b/drivers/iio/imu/smi330/smi330_core.c
index d9178725ade3da83..a79964fe68fadf47 100644
--- a/drivers/iio/imu/smi330/smi330_core.c
+++ b/drivers/iio/imu/smi330/smi330_core.c
@@ -68,7 +68,9 @@
 #define SMI330_SOFT_RESET_DELAY 2000
 
 /* Non-constant mask variant of FIELD_GET() and FIELD_PREP() */
+#undef field_get
 #define field_get(_mask, _reg) (((_reg) & (_mask)) >> (ffs(_mask) - 1))
+#undef field_prep
 #define field_prep(_mask, _val) (((_val) << (ffs(_mask) - 1)) & (_mask))
 
 #define SMI330_ACCEL_CHANNEL(_axis) {					\
-- 
2.43.0

On Mon, 27 Oct 2025 19:41:44 +0100
Geert Uytterhoeven <geert+renesas@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@gmail.com>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@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.

> --
> v5:
>   - New.
> ---
>  drivers/iio/imu/smi330/smi330_core.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/iio/imu/smi330/smi330_core.c b/drivers/iio/imu/smi330/smi330_core.c
> index d9178725ade3da83..a79964fe68fadf47 100644
> --- a/drivers/iio/imu/smi330/smi330_core.c
> +++ b/drivers/iio/imu/smi330/smi330_core.c
> @@ -68,7 +68,9 @@
>  #define SMI330_SOFT_RESET_DELAY 2000
>  
>  /* Non-constant mask variant of FIELD_GET() and FIELD_PREP() */
> +#undef field_get
>  #define field_get(_mask, _reg) (((_reg) & (_mask)) >> (ffs(_mask) - 1))
> +#undef field_prep
>  #define field_prep(_mask, _val) (((_val) << (ffs(_mask) - 1)) & (_mask))
>  
>  #define SMI330_ACCEL_CHANNEL(_axis) {					\

Hi Jonathan,

On Sun, 2 Nov 2025 at 11:43, Jonathan Cameron <jic23@kernel.org> wrote:
> On Mon, 27 Oct 2025 19:41:44 +0100
> Geert Uytterhoeven <geert+renesas@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@gmail.com>
> > Signed-off-by: Geert Uytterhoeven <geert+renesas@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!

> > --- a/drivers/iio/imu/smi330/smi330_core.c
> > +++ b/drivers/iio/imu/smi330/smi330_core.c
> > @@ -68,7 +68,9 @@
> >  #define SMI330_SOFT_RESET_DELAY 2000
> >
> >  /* Non-constant mask variant of FIELD_GET() and FIELD_PREP() */
> > +#undef field_get
> >  #define field_get(_mask, _reg) (((_reg) & (_mask)) >> (ffs(_mask) - 1))
> > +#undef field_prep
> >  #define field_prep(_mask, _val) (((_val) << (ffs(_mask) - 1)) & (_mask))
> >
> >  #define SMI330_ACCEL_CHANNEL(_axis) {                                        \

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

On Mon, 3 Nov 2025 11:09:36 +0100
Geert Uytterhoeven <geert@linux-m68k.org> wrote:

> Hi Jonathan,
> 
> On Sun, 2 Nov 2025 at 11:43, Jonathan Cameron <jic23@kernel.org> wrote:
> > On Mon, 27 Oct 2025 19:41:44 +0100
> > Geert Uytterhoeven <geert+renesas@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@gmail.com>
> > > Signed-off-by: Geert Uytterhoeven <geert+renesas@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.

So I'll rebase now and rename these functions to have an smi330_ prefix.
Better to potentially cause people problems when I have 23 patches
on top of this (and hopefully no one is based on those yet) than when
I have many more.

So tweaked and pushed out a new version where this patch isn't needed.
We can move to your new code next cycle.

Jonathan



> 
> > > --- a/drivers/iio/imu/smi330/smi330_core.c
> > > +++ b/drivers/iio/imu/smi330/smi330_core.c
> > > @@ -68,7 +68,9 @@
> > >  #define SMI330_SOFT_RESET_DELAY 2000
> > >
> > >  /* Non-constant mask variant of FIELD_GET() and FIELD_PREP() */
> > > +#undef field_get
> > >  #define field_get(_mask, _reg) (((_reg) & (_mask)) >> (ffs(_mask) - 1))
> > > +#undef field_prep
> > >  #define field_prep(_mask, _val) (((_val) << (ffs(_mask) - 1)) & (_mask))
> > >
> > >  #define SMI330_ACCEL_CHANNEL(_axis) {                                        \  
> 
> Gr{oetje,eeting}s,
> 
>                         Geert
>

Hi Jonathan,

On Sun, 9 Nov 2025 at 14:01, Jonathan Cameron <jic23@kernel.org> wrote:
> On Mon, 3 Nov 2025 11:09:36 +0100
> Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Sun, 2 Nov 2025 at 11:43, Jonathan Cameron <jic23@kernel.org> wrote:
> > > On Mon, 27 Oct 2025 19:41:44 +0100
> > > Geert Uytterhoeven <geert+renesas@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@gmail.com>
> > > > Signed-off-by: Geert Uytterhoeven <geert+renesas@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?

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

> Hi Jonathan,

Hi Geert,

> 
> On Sun, 9 Nov 2025 at 14:01, Jonathan Cameron <jic23@kernel.org> wrote:
> > On Mon, 3 Nov 2025 11:09:36 +0100
> > Geert Uytterhoeven <geert@linux-m68k.org> wrote:  
> > > On Sun, 2 Nov 2025 at 11:43, Jonathan Cameron <jic23@kernel.org> wrote:  
> > > > On Mon, 27 Oct 2025 19:41:44 +0100
> > > > Geert Uytterhoeven <geert+renesas@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@gmail.com>
> > > > > Signed-off-by: Geert Uytterhoeven <geert+renesas@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
>