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: <6aa66380-8109-472e-8869-bcdc4b0114aa@gmail.com>
Date: Mon, 4 Aug 2025 08:56:20 +0300
From: Matti Vaittinen <mazziesaccount@...il.com>
To: Andy Shevchenko <andy.shevchenko@...il.com>
Cc: Matti Vaittinen <matti.vaittinen@...rohmeurope.com>,
 Lars-Peter Clausen <lars@...afoo.de>,
 Michael Hennerich <Michael.Hennerich@...log.com>,
 Jonathan Cameron <jic23@...nel.org>, David Lechner <dlechner@...libre.com>,
 Nuno Sá <nuno.sa@...log.com>,
 Andy Shevchenko <andy@...nel.org>, Liam Girdwood <lgirdwood@...il.com>,
 Mark Brown <broonie@...nel.org>, linux-iio@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 1/2] iio: adc: ad7476: Simplify chip type detection

On 02/08/2025 01:01, Andy Shevchenko wrote:
> On Fri, Aug 1, 2025 at 12:07 PM Matti Vaittinen
> <mazziesaccount@...il.com> wrote:
>>
>> The ad7476 driver uses a table of structures for defining the IC variant
>> specific data. Table is indexed using enum values, which are picked by
>> SPI ID.
>>
>> Having the table and an enum adds extra complexity. It is potentially
>> unsafe if someone alters the enumeration values, or size of the IC data
>> table.
> 
> I don't see the problem here. I like the part about converting ID
> tables to use chip_info instead of plain integers, but other than that
> I do not see how enum is worse than the split version.

The potential culprit with using the enum for array indexing is, that it 
requires the array size and enum values (used for indexing) to stay in 
sync. Eg, used enum values must be smaller than the size of the array. 
Also, the chip-info items in the array must be kept in locations which 
match the enum values.

Yes, we have ways to do this, often using the last enum value as the 
size of the array, and/or using designated array initializers. It still 
requires programmer to do this correctly. Changing enum at the top of 
the file may break the array indexing (in seemingly unrelated place, at 
the bottom of the file). I agree this is pretty trivial issue, but it's 
still a thing to keep in mind.

Splitting the chip-info in own structs and using direct pointer to the 
struct makes it harder to get it wrong.

Finally, dropping the enum makes adding code which does decisions based 
on the chip-ID less appealing. It hopefully encourages adding _all_ IC 
specific quirks in the chip-info instead, which will keep the code path 
(IMHO) cleaner when all chip-specifics are in the chip-info.

Anyways, Thanks for the feedback!

Yours,
	-- Matti

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ