[<prev] [next>] [<thread-prev] [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.
Powered by blists - more mailing lists