linux-kernel - Re: [PATCH V3 3/5] iio: accel: sca3300: modified to support multi chips

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]

Date:   Wed, 4 May 2022 16:38:51 +0200
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     LI Qingwu <qing-wu.li@...ca-geosystems.com.cn>
Cc:     Jonathan Cameron <jic23@...nel.org>,
        Lars-Peter Clausen <lars@...afoo.de>,
        Rob Herring <robh+dt@...nel.org>,
        Tomas Melin <tomas.melin@...sala.com>,
        devicetree <devicetree@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-iio <linux-iio@...r.kernel.org>,
        Rob Herring <robh@...nel.org>
Subject: Re: [PATCH V3 3/5] iio: accel: sca3300: modified to support multi chips

On Wed, May 4, 2022 at 4:35 PM LI Qingwu
<qing-wu.li@...ca-geosystems.com.cn> wrote:
> > From: Andy Shevchenko <andy.shevchenko@...il.com>
> > Sent: Wednesday, May 4, 2022 10:20 PM
> > On Wed, May 4, 2022 at 3:36 PM LI Qingwu
> > <Qing-wu.Li@...ca-geosystems.com.cn> wrote:

...

> > > +struct sca3300_chip_info {
> > > +       const struct iio_chan_spec *channels;
> > > +       const int (*accel_scale_table)[2];
> > > +       const int *accel_scale_modes_map;
> > > +       const unsigned long *scan_masks;
> > > +       const int *avail_modes_table;
> > > +       const int *freq_modes_map;
> > > +       const int *freq_table;
> > > +       const u8 num_accel_scales;
> > > +       const u8 num_avail_modes;
> > > +       const u8 num_channels;
> > > +       const u8 num_freqs;
> > > +       const u8 chip_id;
> >
> > Why do you have const qualifier on all members?  The last one is
> > understandable, but the rest, esp. pointers should be justified.
> Because I thought it was static and has fix value for each chip, unacceptable for you?

But why const qualifier? What is the point of it for example for u8
members if the entire object is qualified as const below in the same
patch?

On top of that, please explain what in your opinion the "const ...
*foo" gives us, and what we will lose if we remove the "const" part
out of them.

> > > +       const char *name;
> > > +};

-- 
With Best Regards,
Andy Shevchenko