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]

Message-ID: <38eef5df-ca8d-41f1-93e7-e13c1d7b6232@sirena.org.uk>
Date:   Wed, 26 Apr 2023 14:10:57 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Rasmus Villemoes <linux@...musvillemoes.dk>
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 Wed, Apr 26, 2023 at 02:47:44PM +0200, Rasmus Villemoes wrote:
> On 26/04/2023 14.25, Mark Brown wrote:

> > I'm not sure this is sensible, it'll be a fairly rare situation and we
> > don't want to preclude using the built in chip select functionality for
> > some of the chip selects.  In a situation like this we only need to have
> > a single chip select to be managed as a GPIO rather than all of them,
> > which I'd expect to end up handled in the DT by not allocating that chip
> > select number.

> Sorry, I don't understand what you're saying. What exactly is not
> sensible? And what is "a situation like this"?

Building hardware which uses all the native chip selects and also GPIO
ones and then describing it in DT as using native chip selects.

> I described a problem with what is now 87c614175bbf in linux-next: If
> one has five spi devices, the first four of which use the four native
> chip selects, there is no way to use a gpio for the fifth, because
> whichever "channel" you choose in the CHANNEL_SELECT field will cause
> the ecspi IP block to drive some SSx pin low, while the spi core is also
> driving the gpio low, so two different devices would be selected.

Sure, and therefore I'd not expect anyone to actually describe the
hardware like that but to instead describe the hardware as using three
or fewer of the native chip selects with the remaining chip selects
described as GPIOs.  If the device requires that a native chip select be
controlled the hardware simply won't work without at least one native
chip select being unallocated.

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

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