linux-kernel - AW: AW: [PATCH v2] spi: Raise limit on number of chip selects

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] [day] [month] [year] [list]

Message-ID: <FR4P281MB343444EF2816EC9DD405FC5B8348A@FR4P281MB3434.DEUP281.PROD.OUTLOOK.COM>
Date: Thu, 10 Jul 2025 16:15:29 +0000
From: "Hohn, Torben" <Torben.Hohn@...ker.com>
To: Marc Kleine-Budde <mkl@...gutronix.de>
CC: Mark Brown <broonie@...nel.org>, "amit.kumar-mahapatra@....com"
	<amit.kumar-mahapatra@....com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "linux-spi@...r.kernel.org"
	<linux-spi@...r.kernel.org>, "linux@...ck-us.net" <linux@...ck-us.net>
Subject: AW: AW: [PATCH v2] spi: Raise limit on number of chip selects






-Bruker Confidential-
> On 07.07.2025 07:30:29, Hohn, Torben wrote:
> > > > +#define SPI_CS_CNT_MAX 16
> > >
> > > > If this is increased to 24 now, we need to carry another patch on top of mainline again once we add another Chipselect
> > > > into our FPGA, or into the next iteration of our hardware. We would really prefer that a Kconfig value is used.
> > > > We have handed a patch to pengutronix, because they can send proper emails.
> >
> > > > In the IIO framework there is a Konfig Value for something similar:
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/iio/trigger.h#n74
> > >
> > > This doesn't really work, we're supposed to support single kernel image
> > > so putting per platform configuration in Kconfig ends up being at best a
> > > usability problem.  At some point it's better to just bite the bullet
> > > and make things dynamic.
> >
> > After looking a bit more throughly at the code, i dont think it is
> > necessary to make this dynamic. The Value at hand is actually the
> > number of Chipselects a Device might have and not the the maximum
> > number of Chipselects a Controller might have.

> I think it's both. The struct spi_controller uses SPI_CS_CNT_MAX:
>
> | struct spi_controller {
> [...]
> |       s8                              last_cs[SPI_CS_CNT_MAX];
> |       u32                             last_cs_index_mask : SPI_CS_CNT_MAX;

This value saves that last chipselect that was active.
Before the multi-cs per device patch, this was a single u8 and no array.
The mask just states which element of last_cs is valid.
It is in struct spi_controller but since it just saves the value from one device. It still just the per device value, and unrelated to the
number of chipselects per device.
And the last_cs ccount an not be more than the maximum number of CS per device.


> See discussion
> https://lore.kernel.org/all/49b52941-6205-48bd-b2ae-e334018ac5cd@sirena.org.uk/
> for more details.


yeah... see:
https://lore.kernel.org/all/CAOiHx=mM7kpzR-MOshsgXZM+CSB0nawfWxMhpt=tuhmJyMTCzQ@mail.gmail.com/