linux-kernel - Re: [PATCH v5 1/7] spi: Enable controllers to extend the SPI protocol with MOSI idle 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: <8df8f780c83a98480a3d19b0751cb96735c4adaf.camel@gmail.com>
Date: Wed, 26 Jun 2024 11:37:27 +0200
From: Nuno Sá <noname.nuno@...il.com>
To: Marcelo Schmitt <marcelo.schmitt@...log.com>, broonie@...nel.org, 
 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, dlechner@...libre.com, corbet@....net, 
 marcelo.schmitt1@...il.com
Cc: linux-iio@...r.kernel.org, devicetree@...r.kernel.org, 
	linux-spi@...r.kernel.org, linux-doc@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 1/7] spi: Enable controllers to extend the SPI
 protocol with MOSI idle configuration



On Tue, 2024-06-25 at 18:53 -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 usually not
> specified when the controller is not clocking out data on SCLK edges.
> However, there do exist SPI peripherals that require specific MOSI line
> state when data is not being clocked out of the controller.
> 
> Conventional SPI controllers may set the MOSI line on SCLK edges then bring
> it low when no data is going out or leave the line the state of the last
> transfer bit. More elaborated controllers are capable to set the MOSI idle
> state according to different configurable levels and thus are more suitable
> for interfacing with demanding peripherals.
> 
> Add SPI mode bits to allow peripherals to request explicit MOSI idle state
> when needed.
> 
> When supporting a particular MOSI idle configuration, the data output line
> state is expected to remain at the configured level when the controller is
> not clocking out data. When a device that needs a specific MOSI idle state
> is identified, its driver should request the MOSI idle configuration by
> setting the proper SPI mode bit.
> 
> Signed-off-by: Marcelo Schmitt <marcelo.schmitt@...log.com>
> ---

One minor nit... With that:

Acked-by: Nuno Sa <nuno.sa@...log.com>

>  Documentation/spi/spi-summary.rst | 83 +++++++++++++++++++++++++++++++
>  drivers/spi/spi.c                 |  7 +++
>  include/linux/spi/spi.h           |  6 +++
>  include/uapi/linux/spi/spi.h      |  5 +-
>  4 files changed, 99 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/spi/spi-summary.rst b/Documentation/spi/spi-
> summary.rst
> index 7f8accfae6f9..51dd8a105b7e 100644
> --- a/Documentation/spi/spi-summary.rst
> +++ b/Documentation/spi/spi-summary.rst
> @@ -614,6 +614,89 @@ queue, and then start some asynchronous transfer engine
> (unless it's
>  already running).
>  
>  
> +Extensions to the SPI protocol
> +------------------------------
> +The fact that SPI doesn't have a formal specification or standard permits
> chip
> +manufacturers to implement the SPI protocol in slightly different ways. In
> most
> +cases, SPI protocol implementations from different vendors are compatible
> among
> +each other. For example, in SPI mode 0 (CPOL=0, CPHA=0) the bus lines may
> behave
> +like the following:
> +
> +::
> +
> +  nCSx ___                                                                  
> ___
> +          \_________________________________________________________________/
> +          •                                                                 •
> +          •                                                                 •
> +  SCLK         ___     ___     ___     ___     ___     ___     ___     ___
> +       _______/   \___/   \___/   \___/   \___/   \___/   \___/   \___/  
> \_____
> +          •   :   ;   :   ;   :   ;   :   ;   :   ;   :   ;   :   ;   :   ; •
> +          •   :   ;   :   ;   :   ;   :   ;   :   ;   :   ;   :   ;   :   ; •
> +  MOSI XXX__________         _______                 _______        
> ________XXX
> +  0xA5 XXX__/ 1     \_0_____/ 1     \_0_______0_____/ 1     \_0_____/ 1   
> \_XXX
> +          •       ;       ;       ;       ;       ;       ;       ;       ; •
> +          •       ;       ;       ;       ;       ;       ;       ;       ; •
> +  MISO XXX__________         _______________________          _______       
> XXX
> +  0xBA XXX__/     1 \_____0_/     1       1       1 \_____0__/    1 
> \____0__XXX
> +
> +Legend::
> +
> +  • marks the start/end of transmission;
> +  : marks when data is clocked into the peripheral;
> +  ; marks when data is clocked into the controller;
> +  X marks when line states are not specified.
> +
> +In some few cases, chips extend the SPI protocol by specifying line behaviors
> +that other SPI protocols don't (e.g. data line state for when CS is
> inactive).

Forgot this one... inactive -> deasserted (or not asserted)

- Nuno Sá