linux-kernel - Re: [PATCH v3 2/5] iio: accel: bma400: Use macros for generic event configuration values

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAE3SzaTaq7QFoRZMTd33e__ORsHiCMqBK0joVEdSt2YnEfhkSw@mail.gmail.com>
Date: Tue, 7 Oct 2025 12:16:29 +0530
From: Akshay Jindal <akshayaj.lkd@...il.com>
To: Jonathan Cameron <jic23@...nel.org>
Cc: dan@...obertson.com, dlechner@...libre.com, nuno.sa@...log.com, 
	andy@...nel.org, shuah@...nel.org, linux-iio@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 2/5] iio: accel: bma400: Use macros for generic event
 configuration values

On Sat, Oct 4, 2025 at 6:28 PM Jonathan Cameron <jic23@...nel.org> wrote:
>
> On Fri,  3 Oct 2025 00:11:03 +0530
> Akshay Jindal <akshayaj.lkd@...il.com> wrote:
>
> > Add macros and enums for configuration values used in generic event
> > handling for activity and inactivity detection. Replace hard-coded
> > values in activity_event_en() with the new definitions to make the
> > configuration explicit.
> >
> > No functional changes are intended.
> >
> > Signed-off-by: Akshay Jindal <akshayaj.lkd@...il.com>
> > ---
> >  drivers/iio/accel/bma400.h      | 30 ++++++++++++++++++++++++++++++
> >  drivers/iio/accel/bma400_core.c | 14 +++++++++++---
> >  2 files changed, 41 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/iio/accel/bma400.h b/drivers/iio/accel/bma400.h
> > index ae3411c090c9..13fe2e5a3175 100644
> > --- a/drivers/iio/accel/bma400.h
> > +++ b/drivers/iio/accel/bma400.h
> > @@ -106,8 +106,38 @@
> >  #define BMA400_GEN1INT_CONFIG0_REG      0x3f
> >  #define BMA400_GEN2INT_CONFIG0_REG      0x4A
> >  #define BMA400_GENINT_CONFIG0_HYST_MASK              GENMASK(1, 0)
> > +#define BMA400_GENINT_CONFIG0_REF_UPD_MODE_MASK      GENMASK(3, 2)
> > +#define BMA400_GENINT_CONFIG0_DATA_SRC_MASK  BIT(4)
> > +#define BMA400_GENINT_CONFIG0_X_EN_MASK              BIT(5)
> > +#define BMA400_GENINT_CONFIG0_Y_EN_MASK              BIT(6)
> > +#define BMA400_GENINT_CONFIG0_Z_EN_MASK              BIT(7)
> > +
> > +enum bma400_accel_data_src {
> > +     ACCEL_FILT1,
> > +     ACCEL_FILT2,
> > +};
> > +
> > +enum bma400_ref_updt_mode {
> > +     BMA400_REF_MANUAL_UPDT_MODE,
> > +     BMA400_REF_ONETIME_UPDT_MODE,
> > +     BMA400_REF_EVERYTIME_UPDT_MODE,
> > +     BMA400_REF_EVERYTIME_LP_UPDT_MODE,
> > +};
> >
> >  #define BMA400_GEN_CONFIG1_OFF      0x01
> > +#define BMA400_GENINT_CONFIG1_AXES_COMB_MASK BIT(0)
> > +#define BMA400_GENINT_CONFIG1_DETCT_CRIT_MASK        BIT(1)
> > +
> > +enum bma400_genintr_acceleval_axescomb {
> > +     BMA400_EVAL_X_OR_Y_OR_Z,
> > +     BMA400_EVAL_X_AND_Y_AND_Z,
>
> An enum for potential field values only makes sense if you are going to
> use it as a type somewhere.  If not it is simpler to just
> use a define next to the mask for the field.  Also these should be named
> with prefixes that align with that mask.
> If you do use it as a type in future patches that's fine but the naming
> point still remains and you should specify values = 0, = 1 etc
> as they matter whereas implication of using an enum is that the actual
> values assigned doesn't matter.
>
> Same applies to the other enums introduced in here.
Assigned explicit values to enums in v4 patch series.

Thanks,
Akshay.