linux-kernel - Re: [RFC PATCH v2 01/12] spi: dt-bindings: add spi-has-dqs property

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: <ba78303e-36aa-4f40-9416-c22ff12b7458@ti.com>
Date: Thu, 5 Feb 2026 23:16:47 +0530
From: Santhosh Kumar K <s-k6@...com>
To: Miquel Raynal <miquel.raynal@...tlin.com>
CC: <broonie@...nel.org>, <robh@...nel.org>, <krzk+dt@...nel.org>,
	<conor+dt@...nel.org>, <richard@....at>, <vigneshr@...com>,
	<tudor.ambarus@...aro.org>, <pratyush@...nel.org>, <mwalle@...nel.org>,
	<linux-spi@...r.kernel.org>, <devicetree@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <linux-mtd@...ts.infradead.org>,
	<praneeth@...com>, <u-kumar1@...com>, <p-mantena@...com>, <a-dutta@...com>,
	<s-k6@...com>
Subject: Re: [RFC PATCH v2 01/12] spi: dt-bindings: add spi-has-dqs property

Hello Miquel,

On 04/02/26 16:16, Miquel Raynal wrote:
> On 13/01/2026 at 19:46:06 +0530, Santhosh Kumar K <s-k6@...com> wrote:
> 
>> Add the optional 'spi-has-dqs' boolean property for SPI flash device
>> subnodes. This property indicates the flash device supports DQS (Data
>> Strobe) mode, which provides improved timing margins for data capture
>> in high-speed SPI operations.
>>
>> Signed-off-by: Santhosh Kumar K <s-k6@...com>
>> ---
>>   .../devicetree/bindings/spi/spi-peripheral-props.yaml       | 6 ++++++
>>   1 file changed, 6 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml b/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml
>> index 8b6e8fc009db..c6f330fd32aa 100644
>> --- a/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml
>> +++ b/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml
>> @@ -89,6 +89,12 @@ properties:
>>       description:
>>         Delay, in microseconds, after a write transfer.
>>   
>> +  spi-has-dqs:
>> +    description:
>> +      Indicates the SPI flash device supports DQS (Data Strobe) mode for
>> +      improved data capture timing.
>> +    $ref: /schemas/types.yaml#/definitions/flag
> 
> This information is currently lacking indeed, mostly because nobody ever
> cared about it. The DT property is IMO not the correct way to give this
> information for two reasons:
> - this is a capability of the chip, we discover the chip dynamically in
>    both cases (NAND and NOR) and attach many capabilities to the chips
>    already, so I believe this information should be provided through a
>    flag.
> - the fact that the DQS signal might be supported does not indicate it
>    is actually driven. Winbond chips, for instance, can either enable it
>    or not depending on their configuration (probably through their VCR
>    register, I need to check again).

I agree. The flash device's capability to provide DQS - whether in SDR,
DDR or both modes - can be represented as a flag in the flash
description. We can list out the possible combinations and use them to
clearly describe the flash's supported capabilities.

However, whether the DQS signal is actually connected to the controller
is a non-discoverable hardware detail and should be described only via
Device Tree. The DT property is not meant to describe the flash's
capabilities, but to indicate whether DQS is physically connected to the
controller.

> 
> The question I have is: shall we enable the DQS pin automatically if it
> is available? Not all controllers support it I suppose, and wiring the
> line might as well not be done (or incorrectly). For these cases we may
> need DT properties in the future. But for the DQS presence indication, I
> bet it is not useful, and should be handled at the core level (not
> parsed by the driver like you do) because it may have an impact on the
> chip internal configuration.

We can handle this in either way: keep DQS disabled by default and
enable it using a "has-dqs" property, or enable it by default and
disable it explicitly using a "no-dqs" property.

Thanks,
Santhosh.

> 
> I will try to come up with a proposal soon!
> 
> Cheers,
> Miquèl