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] [day] [month] [year] [list]

Message-ID: <87ldh7f4k9.fsf@bootlin.com>
Date: Thu, 05 Feb 2026 19:06:30 +0100
From: Miquel Raynal <miquel.raynal@...tlin.com>
To: Santhosh Kumar K <s-k6@...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>
Subject: Re: [RFC PATCH v2 01/12] spi: dt-bindings: add spi-has-dqs property

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