linux-kernel - Re: [PATCH v11 03/10] spi: Add multi-cs memories support in SPI core

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]

Date: Sun, 21 Jan 2024 08:58:36 -0800
From: Guenter Roeck <linux@...ck-us.net>
To: Mark Brown <broonie@...nel.org>
Cc: Amit Kumar Mahapatra <amit.kumar-mahapatra@....com>,
 tudor.ambarus@...aro.org, pratyush@...nel.org, miquel.raynal@...tlin.com,
 richard@....at, vigneshr@...com, sbinding@...nsource.cirrus.com,
 lee@...nel.org, james.schulman@...rus.com, david.rhodes@...rus.com,
 rf@...nsource.cirrus.com, perex@...ex.cz, tiwai@...e.com,
 linux-spi@...r.kernel.org, linux-kernel@...r.kernel.org, michael@...le.cc,
 linux-mtd@...ts.infradead.org, nicolas.ferre@...rochip.com,
 alexandre.belloni@...tlin.com, claudiu.beznea@...on.dev,
 michal.simek@....com, linux-arm-kernel@...ts.infradead.org,
 alsa-devel@...a-project.org, patches@...nsource.cirrus.com,
 linux-sound@...r.kernel.org, git@....com, amitrkcian2002@...il.com
Subject: Re: [PATCH v11 03/10] spi: Add multi-cs memories support in SPI core

On 1/20/24 17:04, Mark Brown wrote:
> On Sat, Jan 20, 2024 at 09:05:43AM -0800, Guenter Roeck wrote:
> 
>> FWIW, the problem is due to
> 
>> +#define SPI_CS_CNT_MAX 4
> 
>> in the offending patch, but apeed2400 FMC supports up to 5 SPI chip selects.
>>
>>   static const struct aspeed_spi_data ast2400_fmc_data = {
>>          .max_cs        = 5,
>> 	^^^^^^^^^^^^^^^^^^^
>>          .hastype       = true,
> 
>> Limiting .max_cs to 4 or increasing SPI_CS_CNT_MAX to 5 fixes the problem,
>> though of course I don't know if increasing SPI_CS_CNT_MAX has other side
>> effects.
> 
> Yeah, I was coming to a similar conclusion myself - the limit is just
> too low.  I can't see any problem with increasing it.

It would cost a bit of memory and somewhat affect performance sine many
of the newly introduced loops are bound by SPI_CS_CNT_MAX and not by
num_chipselect.

It also might make sense to document the new limit somewhere. Prior
to this commit it was not limited at all.
Documentation/devicetree/bindings/spi/spi-davinci.txt lists 5 chip
selects in its example for the use of cs-gpios.
Documentation/devicetree/bindings/spi/spi-controller.yaml also does not
list a limit.

Thanks,
Guenter