Re: [PATCH v4 01/16] spi: dt-bindings: add spi-max-post-config-frequency property

[Miquel Raynal]

On 22/06/2026 at 11:14:32 +02, Krzysztof Kozlowski <krzk@xxxxxxxxxx> wrote:

> On Thu, Jun 18, 2026 at 01:07:10PM +0530, Santhosh Kumar K wrote:
>> Add spi-max-post-config-frequency, a generic uint32 property for SPI
>> peripherals that support two distinct clock rates: a conservative rate
>> always reachable without controller configuration, and a higher rate
>> reachable only after controller-side configuration such as PHY tuning.
>> 
>> When both properties are present, spi-max-frequency gives the
>> conservative pre-configuration rate and spi-max-post-config-frequency
>> gives the higher post-configuration target.
>> 
>> Signed-off-by: Santhosh Kumar K <s-k6@xxxxxx>
>> ---
>>  .../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 880a9f624566..ece86f65930f 100644
>> --- a/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml
>> +++ b/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml
>> @@ -45,6 +45,12 @@ properties:
>>      description:
>>        Maximum SPI clocking speed of the device in Hz.
>>  
>> +  spi-max-post-config-frequency:
>
> -hz
> https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/property-units.yaml
>
> and you need maxItems: 1.
>
> Now, please take time and think if this should not be an array instead
> (maxItems: ...) to cover other possible cases, e.g. different tuning
> levels? IOW, having single spi-max-frequency turned out to be
> insufficient. You address that insufficiency with one more frequency,
> but what if this is going to be insufficient next month as well?

It is actually a very good remark. I do not have existing needs in mind
at the momet, but that does not mean there is none.

In SPI NAND we have per-operation maximum frequencies being defined in
manufacturer drivers (you can check drivers/mtd/nand/spi/winbond.c)
because when the speed increases, the number of dummy cycles shall be
adapted accordingly. So we kind of handle the various frequency possibilities already
(the property added by Santhosh setting an absolute maximum that cannot
be crossed).

However, I do not think SPI NORs have something similar, and also one
day we might have different tuning levels requiring different "maximum
frequencies": we could imagine a first mode where tuning is very fast to
configure and speed gains good, in competition with another mode where
tuning makes transfers extremely fast but with an extra configuration
penalty (this is pure sci-fi in my head at the moment).

It is hard to tell whether this wet finger guessing will realize any
time soon. Maybe the safest approach is to go for an array, though. In
that case, could we add a mandatory name to ease (future) parsing?
Typically here, we might want to call it phy-delay-tuning or something
like that (name to be discussed, because there is the risk to make to
too controller specific).

Thanks,
Miquèl