Re: [RFC PATCH v2 08/12] spi: cadence-quadspi: read 'has-dqs' DT property

[Michael Walle]

On Thu Feb 5, 2026 at 6:35 PM CET, Miquel Raynal wrote:
> On 13/01/2026 at 19:46:13 +0530, Santhosh Kumar K <s-k6@xxxxxx> wrote:
>
>> Add a boolean field to struct cqspi_flash_pdata to store whether the
>> attached flash device supports DQS (Data Strobe) mode. Read this from
>> the 'spi-has-dqs' device tree property during flash node parsing.
>>
>> This is preparatory infrastructure for PHY tuning support. The field
>> will be used by subsequent patches to configure read data capture timing
>> with DQS enabled for improved margins in high-speed operations.
>>
>> Signed-off-by: Santhosh Kumar K <s-k6@xxxxxx>
>
> As mentioned in my answer to the cover letter, I am not too much in
> favour of this property because this is something that is somewhat
> related to the chip ID, thus discoverable. I drafted something to get
> rid of this property already, I will share it for opening the
> discussion.
>
> However, for now I am closing my eyes on the fact that the DQS pin might
> not be wired to the controller. In this case we will need some kind of
> "dqs-not-wired" DT property, that's true, but also easily manageable at
> the core level later, when/if the need arises.

Usually, a DQS pin is optional. AFAIK, there is no requirement for
it. I.e. it will probably work fine with slower frequencies and
using an internal loopback. So if you run your flash with slower
frequency you can probably save one pin and use it for something
different.

What I wanted to say is, that not having a DQS pin wired is not
really a mistake. But "dqs-not-wired" sounds exactly like it.
So IMHO it should be the other way around and the device tree should
tell you that *is* wired, if we cannot find detect it otherwise,
like looking at pinmuxing for example (not sure that is feasible
though).

-michael

Attachment: signature.asc
Description: PGP signature