Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220504133612.604304-1-Qing-wu.Li@leica-geosystems.com.cn>
 <20220504133612.604304-4-Qing-wu.Li@leica-geosystems.com.cn>
 <CAHp75VeseZ2ChtbafmbgVavS4KvCvrQ4+XSRkeiJSyqr8__dSw@mail.gmail.com> <AM9PR06MB7844E8FE0EDF712C769271DAD7C39@AM9PR06MB7844.eurprd06.prod.outlook.com>
In-Reply-To: <AM9PR06MB7844E8FE0EDF712C769271DAD7C39@AM9PR06MB7844.eurprd06.prod.outlook.com>
From:   Andy Shevchenko <andy.shevchenko@gmail.com>
Date:   Wed, 4 May 2022 16:38:51 +0200
Message-ID: <CAHp75VfEK_TXXA3NdGgjis7duHgoDo4aSOZntdO0wEGLw0sQ7g@mail.gmail.com>
Subject: Re: [PATCH V3 3/5] iio: accel: sca3300: modified to support multi chips
To:     LI Qingwu <qing-wu.li@leica-geosystems.com.cn>
Cc:     Jonathan Cameron <jic23@kernel.org>,
        Lars-Peter Clausen <lars@metafoo.de>,
        Rob Herring <robh+dt@kernel.org>,
        Tomas Melin <tomas.melin@vaisala.com>,
        devicetree <devicetree@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        linux-iio <linux-iio@vger.kernel.org>,
        Rob Herring <robh@kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

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