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: <20250709-bronze-duck-from-valhalla-118ef8-mkl@pengutronix.de>
Date: Wed, 9 Jul 2025 10:24:20 +0200
From: Marc Kleine-Budde <mkl@...gutronix.de>
To: "Hohn, Torben" <Torben.Hohn@...ker.com>
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: Re: AW: [PATCH v2] spi: Raise limit on number of chip selects

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;

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

Marc

-- 
Pengutronix e.K.                 | Marc Kleine-Budde          |
Embedded Linux                   | https://www.pengutronix.de |
Vertretung Nürnberg              | Phone: +49-5121-206917-129 |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-9   |

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ