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: <d6210c5e-339e-4feb-ad4b-fad456ec5710@quicinc.com>
Date: Wed, 26 Mar 2025 14:51:45 +0530
From: Jyothi Kumar Seerapu <quic_jseerapu@...cinc.com>
To: Mukesh Kumar Savaliya <quic_msavaliy@...cinc.com>, <broonie@...nel.org>,
        <linux-spi@...r.kernel.org>, <linux-kernel@...r.kernel.org>
CC: <andersson@...nel.org>, <konradybcio@...nel.org>
Subject: Re: [PATCH V1] spi: Add support for Double Transfer Rate (DTR) mode

Tested-by: Jyothi Kumar Seerapu <quic_jseerapu@...cinc.com>

On 3/26/2025 2:09 PM, Mukesh Kumar Savaliya wrote:
> There is no support for protocol drivers to specify whether a transfer
> should use single or dual transfer mode. As a result, the SPI controller
> has no way to determine this information from the user, leading to
> potential limitations in transfer capabilities.
> 
> This change introduces a new field `dtr_mode` in the `spi_transfer`
> structure. The `dtr_mode` field allows protocol drivers to indicate if
> Double Transfer Rate (DTR) mode is supported for a given transfer. When
> `dtr_mode` is set to true, the SPI controller will use DTR mode
> otherwise, it will default to single transfer mode.
> 
> The QSPI controller driver uses this flag and configures single or double
> transfer rate using the controller register.
> 
> The existing spi-mem driver helps configure the DTR mode but is limited
> to memory devices. There is no support available to set DTR mode for
> non-memory devices, e.g., touch or any generic SPI sensor. This change
> is backward compatible and doesn't break existing SPI or QSPI drivers.
> 
> Changes include:
> - Addition of `dtr_mode` field in `spi_transfer` structure.
> - Documentation updates to reflect the new `dtr_mode` field.
> 
> Signed-off-by: Mukesh Kumar Savaliya <quic_msavaliy@...cinc.com>
> ---
>   include/linux/spi/spi.h | 5 +++++
>   1 file changed, 5 insertions(+)
> 
> diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
> index 0ba5e49bace4..4e1152de82cd 100644
> --- a/include/linux/spi/spi.h
> +++ b/include/linux/spi/spi.h
> @@ -998,6 +998,7 @@ struct spi_res {
>    *	processed the word, i.e. the "pre" timestamp should be taken before
>    *	transmitting the "pre" word, and the "post" timestamp after receiving
>    *	transmit confirmation from the controller for the "post" word.
> + * @dtr_mode: true if supports double transfer rate.
>    * @timestamped: true if the transfer has been timestamped
>    * @error: Error status logged by SPI controller driver.
>    *
> @@ -1049,6 +1050,9 @@ struct spi_res {
>    * two should both be set. User can set transfer mode with SPI_NBITS_SINGLE(1x)
>    * SPI_NBITS_DUAL(2x) and SPI_NBITS_QUAD(4x) to support these three transfer.
>    *
> + * User may also set dtr_mode to true to use dual transfer mode if desired. if
> + * not, default considered as single transfer mode.
> + *
>    * The code that submits an spi_message (and its spi_transfers)
>    * to the lower layers is responsible for managing its memory.
>    * Zero-initialize every field you don't set up explicitly, to
> @@ -1083,6 +1087,7 @@ struct spi_transfer {
>   	unsigned	tx_nbits:4;
>   	unsigned	rx_nbits:4;
>   	unsigned	timestamped:1;
> +	bool		dtr_mode;
>   #define	SPI_NBITS_SINGLE	0x01 /* 1-bit transfer */
>   #define	SPI_NBITS_DUAL		0x02 /* 2-bit transfer */
>   #define	SPI_NBITS_QUAD		0x04 /* 4-bit transfer */


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ