Re: [PATCH RFC 0/4] mtd/spi-mem: Enable DQS support

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

On 07/02/2026 at 01:02:12 +0530, Santhosh Kumar K <s-k6@ti.com> wrote:

> Hello Miquel,
>
> On 06/02/26 00:36, Miquel Raynal wrote:
>> For his PHY tuning series on the Cadence QSPI controller embedded in TI
>> SoCs, Santhosh needs to access the availability of the DQS (data strobe)
>> signal. This is a chip dependent capability, which may sometimes be
>> enabled.
>> Create a SPI memory flag for it, let the SPI NAND core set this flag
>> when it knows about the capability, and show how to use it from a SPI
>> controller driver.
>> This is an alternative at needing a DT property. Please note that
>> there
>> are a few blind spots:
>> - the line may not be wired (this would be surprising, but can be
>>    flagged this time by a DT property)
>> - manufacturer drivers must enable the feature if it is
>>    available (especially for high speed DTR modes)
>> - this implementation is proposed for SPI NANDs only, if this proposal
>>    is accepted the same approach must be taken in SPI NOR.
>
> Thank you for the series!
>
> As mentioned in the tuning series, in addition to the flash advertising
> its DQS capability, we also need a DT property to describe whether DQS
> is physically connected to the controller. This can be represented using
> either a "dqs-wired" or "dqs-not-wired" property; the exact naming can
> be chosen based on the majority case.
>
> With this series, the controller will enable or disable DQS by logically
> AND-ing both pieces of information.

Do we really need this?

My expectation is that someone wiring an octal DTR SPI chip for high
speed octal DTR use **will** route the DQS signal. If this signal is not
wired, I want to consider this as a hardware bug.

As a result, the default case should be "if there is a DQS signal, use
it".

If, however people come up with non correctly routed chips but still
want high frequency support, the burden will be on them to ask for a DT
property describing a non compliant hardware layout, eg. the "no-dqs"
property. You can take this on your shoulders if you want, but I would
recommend not to, because this will require more patches and another
round of review from DT maintainers which, I believe, we do not need at
the moment. This DT property would be orthogonal and could very easily
be added in a second step, keeping this series "small".

Thanks,
Miquèl