linux-kernel - Re: spi-mem and gpio chipselects

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] [day] [month] [year] [list]

Date:   Tue, 5 Nov 2019 11:42:27 +0000
From:   Mark Brown <broonie@...nel.org>
To:     Chris Packham <Chris.Packham@...iedtelesis.co.nz>
Cc:     "linux-spi@...r.kernel.org" <linux-spi@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: spi-mem and gpio chipselects

On Mon, Nov 04, 2019 at 08:06:42PM +0000, Chris Packham wrote:
> On Mon, 2019-11-04 at 12:44 +0000, Mark Brown wrote:

> > That's only going to work in cases where the controller translates
> > things into a single SPI operation on the flash which I'm not sure is
> > always going to be the case.  We'd need a way to guarantee that the
> > controller is going to do that in order to avoid data corruption issues.

> In my particular case (spi-bcm-qspi.c) bcm_qspi_bspi_exec_mem_op() does
> seem to assert the native chip-select then do it's operation. As I
> understand the wait_for_completion_timeout() will schedule so other

The issue is what happens if the hardware translates the operations it's
being asked to do into multiple physical operations on the bus for some
reason.  It sounds like yours won't but we can't just unconditionally
push the chip select control out to software even if the normal SPI
modes support it.

> tasks may run but spi_mem_access_start() has taken an io_mutex so
> anything that accesses that spi bus will block.

That's guaranteed.

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