linux-kernel - Re: [PATCH 0/3] spi: spi-imx: fix use of more than four 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] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 16 May 2023 13:43:23 +0200
From:   Rasmus Villemoes <rasmus.villemoes@...vas.dk>
To:     Rasmus Villemoes <linux@...musvillemoes.dk>,
        Mark Brown <broonie@...nel.org>
Cc:     Shawn Guo <shawnguo@...nel.org>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        Pengutronix Kernel Team <kernel@...gutronix.de>,
        Fabio Estevam <festevam@...il.com>,
        NXP Linux Team <linux-imx@....com>,
        linux-spi@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-kernel@...r.kernel.org,
        Marc Kleine-Budde <mkl@...gutronix.de>,
        Kevin Groeneveld <kgroeneveld@...brook.com>
Subject: Re: [PATCH 0/3] spi: spi-imx: fix use of more than four chip selects

On 26/04/2023 15.23, Rasmus Villemoes wrote:

>>> It's not exactly a regression, because any chip_select >= 4 never
>>> actually worked, but what I'm saying is that 87c614175bbf also isn't a
>>> complete fix if one wants to support mixing native and gpio chip
>>> selects. For that, one really needs the unused_native_cs to be used for
>>> all gpio chip selects; in particular, one needs some unused native cs to
>>> exist. IOW, what my series tries to do.
>>
>> No, we only need one unused chip select to be available.
> 
> Which is exactly what I'm saying, so I think we're in agreement.
> 
> I.e., something like this 3-patch series is needed to actually support
> mixing native and gpio chip selects (having the core verify that there
> is an unused chip select available, and provide that in the
> ->unused_native_cs field in the spi_controller). I don't think there's
> any textual conflict with 87c614175bbf, and the masking done by
> 87c614175bbf doesn't hurt, but also becomes irrelevant if this series is
> applied, since we'd never pass any value > 3 to those macros.

So, what's the conclusion here? Will these three patches be applied, or
will we just live with the status as of next-20230516, namely that

* for up to four slaves, any combination of native and gpio chip select
works

* with more then four slaves, CSn and CS(n&3) must be be gpios for all n
>= 4

?

Rasmus