linux-kernel - Re: [PATCH v5 02/11] iio: adc: Add basic support for AD4170

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: <20250614115258.29a281c9@jic23-huawei>
Date: Sat, 14 Jun 2025 11:52:58 +0100
From: Jonathan Cameron <jic23@...nel.org>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc: Marcelo Schmitt <marcelo.schmitt1@...il.com>, Marcelo Schmitt
 <marcelo.schmitt@...log.com>, linux-iio@...r.kernel.org,
 devicetree@...r.kernel.org, linux-gpio@...r.kernel.org,
 linux-kernel@...r.kernel.org, Ana-Maria Cusco <ana-maria.cusco@...log.com>,
 lars@...afoo.de, Michael.Hennerich@...log.com, dlechner@...libre.com,
 nuno.sa@...log.com, robh@...nel.org, krzk+dt@...nel.org,
 conor+dt@...nel.org, linus.walleij@...aro.org, brgl@...ev.pl
Subject: Re: [PATCH v5 02/11] iio: adc: Add basic support for AD4170

On Thu, 12 Jun 2025 15:48:02 +0300
Andy Shevchenko <andriy.shevchenko@...ux.intel.com> wrote:

> On Wed, Jun 11, 2025 at 06:04:49PM -0300, Marcelo Schmitt wrote:
> > On 06/11, Andy Shevchenko wrote:  
> > > On Tue, Jun 10, 2025 at 05:31:25PM -0300, Marcelo Schmitt wrote:  
> 
> ...
> 
> > > > +	return spi_write(st->spi, st->tx_buf, size + 2);  
> > > 
> > > ... + sizeof(reg) ?  
> > 
> > The size of the specific ADC register is stored in the size variable.
> > The result of sizeof(reg) can be different on different machines and will
> > probably not be equal to the size of the register in the ADC chip.  
> 
> Hmm... But shouldn't we have a variable type that respects the sizeof() of the
> register in HW to keep it there? 2 is magic.
> 
> ...
> 
> > > > +static bool ad4170_setup_eq(struct ad4170_setup *a, struct ad4170_setup *b)
> > > > +{
> > > > +	/*
> > > > +	 * The use of static_assert() here is to make sure that, if
> > > > +	 * struct ad4170_setup is ever changed (e.g. a field is added to the
> > > > +	 * struct's declaration), the comparison below is adapted to keep
> > > > +	 * comparing each of struct ad4170_setup fields.
> > > > +	 */  
> > > 
> > > Okay. But this also will trigger the case when the field just changes the type.
> > > So, it also brings false positives. I really think this is wrong place to put
> > > static_assert(). To me it looks like a solving rare problem, if any.  
> > 
> > I think it is unlikely that struct ad4170_setup declaration will ever change.
> > The fields match the registers that are associated with a channel setup and
> > the their types match the size of the respective registers. So, I do agree
> > that triggering this assert would be something rare.  
> 
> Yep, which thinks to me as an unneeded noise in the code, making it harder to
> read and maintain (in _this_ case).

This whole thing with static asserts was a compromise in the original drivers.
I'm fine with just dropping it (here at least) and relying on review to pick up
changes to these structures.

Jonathan