linux-kernel - Re: [PATCH v3 4/6] iio: accel: adxl345: Remove single info instances

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: <CAFXKEHZWArvErzeoaO+jMrrA7AuQ4izJioNW_wWTza-bLXV22A@mail.gmail.com>
Date: Sun, 24 Mar 2024 20:06:51 +0100
From: Lothar Rubusch <l.rubusch@...il.com>
To: Jonathan Cameron <jic23@...nel.org>
Cc: lars@...afoo.de, Michael.Hennerich@...log.com, robh+dt@...nel.org, 
	krzysztof.kozlowski+dt@...aro.org, conor+dt@...nel.org, 
	linux-iio@...r.kernel.org, devicetree@...r.kernel.org, 
	linux-kernel@...r.kernel.org, eraretuya@...il.com
Subject: Re: [PATCH v3 4/6] iio: accel: adxl345: Remove single info instances

On Sun, Mar 24, 2024 at 2:35 PM Jonathan Cameron <jic23@...nel.org> wrote:
>
> On Sat, 23 Mar 2024 12:20:28 +0000
> Lothar Rubusch <l.rubusch@...il.com> wrote:
>
> > Add a common array adxl3x5_chip_info and an enum for
> > indexing. This allows to remove local redundantly
> > initialized code in the bus specific modules.
> >
> > Signed-off-by: Lothar Rubusch <l.rubusch@...il.com>
> > ---
> >  drivers/iio/accel/adxl345.h      |  7 +++++++
> >  drivers/iio/accel/adxl345_core.c | 12 ++++++++++++
> >  drivers/iio/accel/adxl345_i2c.c  | 20 +++++---------------
> >  drivers/iio/accel/adxl345_spi.c  | 20 +++++---------------
> >  4 files changed, 29 insertions(+), 30 deletions(-)
> >
> > diff --git a/drivers/iio/accel/adxl345.h b/drivers/iio/accel/adxl345.h
> > index 6b84a2cee..de6b1767d 100644
> > --- a/drivers/iio/accel/adxl345.h
> > +++ b/drivers/iio/accel/adxl345.h
> > @@ -26,11 +26,18 @@
> >   */
> >  #define ADXL375_USCALE       480000
> >
> > +enum adxl345_device_type {
> > +     ADXL345,
> > +     ADXL375,
> > +};
> > +
> >  struct adxl345_chip_info {
> >       const char *name;
> >       int uscale;
> >  };
> >
> > +extern const struct adxl345_chip_info adxl3x5_chip_info[];
> > +
> >  int adxl345_core_probe(struct device *dev, struct regmap *regmap,
> >                      int (*setup)(struct device*, struct regmap*));
> >
> > diff --git a/drivers/iio/accel/adxl345_core.c b/drivers/iio/accel/adxl345_core.c
> > index 33424edca..e3718d0dd 100644
> > --- a/drivers/iio/accel/adxl345_core.c
> > +++ b/drivers/iio/accel/adxl345_core.c
> > @@ -62,6 +62,18 @@ struct adxl345_data {
> >               BIT(IIO_CHAN_INFO_SAMP_FREQ),                           \
> >  }
> >
> > +const struct adxl345_chip_info adxl3x5_chip_info[] = {
> > +     [ADXL345] = {
> > +             .name = "adxl345",
> > +             .uscale = ADXL345_USCALE,
> > +     },
> > +     [ADXL375] = {
> > +             .name = "adxl375",
> > +             .uscale = ADXL375_USCALE,
> > +     },
> > +};
> > +EXPORT_SYMBOL_NS_GPL(adxl3x5_chip_info, IIO_ADXL345);
>
> There is little advantage here form using an array.  I'd just have
> two exported structures.   Then the name alone is enough in the
> id tables.  And probably no need for the enum definition.
>
> This use of arrays is an old pattern that makes little sense if the
> IDs have no actual meaning and you aren't supporting lots of different
> parts.  For 2 parts I'd argue definitely not worth it.
>

Agree. I see your point. I drop the info array enum patch.

(...)

Btw. may I ask another question: The adxl345/75 driver is doing the
configuration
inside the probe(). Other Analog drivers moved that out into a
xxx_setup() and call
this function in the probe(). In general, is it better to keep all
inside  the probe() or
separate? I mean, the probe is still quite short, and reading through
severl call
hierarchies feels a bit "sparghetti". On the other side I can see a
certain idea of
separation of functionality: dedicated chip configuration. Would you
mind to give
me a small statement/opinion on this please?