linux-kernel - Re: [PATCH v3 1/6] spi: Add SPI mode bit for MOSI idle state configuration

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: <ZmIzXun2-DWl7cT-@debian-BULLSEYE-live-builder-AMD64>
Date: Thu, 6 Jun 2024 19:08:30 -0300
From: Marcelo Schmitt <marcelo.schmitt1@...il.com>
To: Mark Brown <broonie@...nel.org>
Cc: David Lechner <dlechner@...libre.com>,
	Marcelo Schmitt <marcelo.schmitt@...log.com>, lars@...afoo.de,
	Michael.Hennerich@...log.com, jic23@...nel.org, robh+dt@...nel.org,
	krzysztof.kozlowski+dt@...aro.org, conor+dt@...nel.org,
	nuno.sa@...log.com, linux-iio@...r.kernel.org,
	devicetree@...r.kernel.org, linux-spi@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 1/6] spi: Add SPI mode bit for MOSI idle state
 configuration

On 06/05, Mark Brown wrote:
> On Wed, Jun 05, 2024 at 11:37:48AM -0500, David Lechner wrote:
> > On 6/5/24 7:24 AM, Mark Brown wrote:
> > > On Tue, Jun 04, 2024 at 07:41:47PM -0300, Marcelo Schmitt wrote:
> 
> > >> The behavior of an SPI controller data output line (SDO or MOSI or COPI
> > >> (Controller Output Peripheral Input) for disambiguation) is not specified
> > >> when the controller is not clocking out data on SCLK edges. However, there
> > >> exist SPI peripherals that require specific COPI line state when data is
> > >> not being clocked out of the controller.
> 
> > I think this description is missing a key detail that the tx data line
> > needs to be high just before and also during the CS assertion at the start
> > of each message.
> 
> > And it would be helpful to have this more detailed description in the
> > source code somewhere and not just in the commit message.
> 
> Yes, there's no way anyone could infer this from any aspect of the
> series.  I think the properties also need a clearer name since someone
> might want the accelerator functionality at some point.

So, if I understand correctly, it would be desirable to also have flags and
descriptions for the MOSI idle configuration capabilities in include/linux/spi/spi.h.

Does the following definitions look good?
#define SPI_CONTROLLER_MOSI_IDLE_LOW		BIT(8)
#define SPI_CONTROLLER_MOSI_IDLE_HIGH		BIT(9)

Maybe also document the MOSI idle configuration feature in spi-summary.rst?

> 
> > > Even without that we'd need feature detection so that drivers that try
> > > to use this aren't just buggy when used with a controller that doesn't
> > > implement it, but once you're detecting you may as well just make things
> > > work.
> 
> > I could see something like this working for controllers that leave the
> > tx data line in the state of the last bit of a write transfer. I.e. do a
> > write transfer of 0xff (using the smallest number of bits per word
> > supported by the controller) with CS not asserted, then assert CS, then
> > do the rest of actual the transfers requested by the peripheral.
> 
> > But it doesn't seem like it would work for controllers that always
> > return the tx data line to a low state after a write since this would
> > mean that the data line would still be low during the CS assertion
> > which is what we need to prevent.
> 
> With the additional requirement it's not emulatable, but we'd still need
> the checks in the core.