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

[Miquel Raynal <miquel.raynal@bootlin.com>]

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