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@ti.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
+
   stacked-memories:
     description: Several SPI memories can be wired in stacked mode.
       This basically means that either a device features several chip
-- 
2.34.1

On 13/01/2026 at 19:46:06 +0530, Santhosh Kumar K <s-k6@ti.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@ti.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).

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.

I will try to come up with a proposal soon!

Cheers,
Miquèl

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@ti.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@ti.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

Hi Santhosh,

>> 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.

I know we can be surprised by our hardware colleagues :-), but I would
consider "not wiring the DQS signal of a (DQS capable) octal DTR SPI
memory" a bug? Hence I would opt for handling the broken case, when/if
that need arises.

Thanks,
Miquèl