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]

Message-ID: <9806d99fab46c928f337b30b21057b3e@walle.cc>
Date: Sun, 21 Jan 2024 19:06:31 +0100
From: Michael Walle <michael@...le.cc>
To: Guenter Roeck <linux@...ck-us.net>
Cc: Mark Brown <broonie@...nel.org>, 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,
 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

>>> 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.

Given that, that the rest of this series is under discussion (and esp. 
whether
it is the correct way to do it) it might make sense to just revert the 
picked
patches.

-michael