linux-kernel - Re: [PATCH v3 1/2] dt-bindings: clock: fixed-clock: Add nvmem support

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

Message-ID: <96004048-0ba5-4cd6-406f-e1235c819c97@topic.nl>
Date:   Mon, 5 Jun 2023 16:00:16 +0200
From:   Mike Looijmans <mike.looijmans@...ic.nl>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        devicetree@...r.kernel.org, linux-clk@...r.kernel.org
CC:     Conor Dooley <conor+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Michael Turquette <mturquette@...libre.com>,
        Rob Herring <robh+dt@...nel.org>,
        Stephen Boyd <sboyd@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 1/2] dt-bindings: clock: fixed-clock: Add nvmem support

On 05-06-2023 15:38, Krzysztof Kozlowski wrote:
> On 05/06/2023 15:34, Mike Looijmans wrote:
>> Add bindings for a fixed-rate clock that retrieves its rate from an
>> NVMEM provider. This allows to store clock settings in EEPROM or EFUSE
>> or similar device.
>>
>> Component shortages lead to boards being shipped with different clock
>> crystals, based on what was available at the time. The clock frequency
>> was written to EEPROM at production time. Systems can adapt to a wide
>> range of input frequencies using the clock framework, but this required
>> us to patch the devicetree at runtime or use some custom driver. This
>> provides a more generic solution.
>>
>> Signed-off-by: Mike Looijmans <mike.looijmans@...ic.nl>
>>
>> ---
>>
>> Changes in v3:
>> Modify fixed-clock instead of introducing nvmem-clock
>>
>> Changes in v2:
>> Changed "fixed-clock" into "nvmem-clock" in dts example
>> Add minItems:1 to nvmem-cell-names
>>
>>   .../bindings/clock/fixed-clock.yaml           | 25 ++++++++++++++++++-
>>   1 file changed, 24 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/clock/fixed-clock.yaml b/Documentation/devicetree/bindings/clock/fixed-clock.yaml
>> index b0a4fb8256e2..23e4df96d3b0 100644
>> --- a/Documentation/devicetree/bindings/clock/fixed-clock.yaml
>> +++ b/Documentation/devicetree/bindings/clock/fixed-clock.yaml
>> @@ -12,7 +12,9 @@ maintainers:
>>   
>>   properties:
>>     compatible:
>> -    const: fixed-clock
>> +    enum:
>> +      - fixed-clock
>> +      - fixed-clock-nvmem
> Do you even need new compatible? Isn't this the same clock from the
> hardware point of view?

I need a new compatible because a "fixed-clock" only loads at init time. 
It registers using CLK_OF_DECLARE, which requires the clock to register 
early. NVMEM providers are typical devices like I2C EEPROMs that won't 
be available at that point, hence I needed to create a clock that 
registers as a regular clock driver and can handle deferral and similar.


>
>>     "#clock-cells":
>>       const: 0
>> @@ -33,6 +35,27 @@ required:
>>   
>>   additionalProperties: false
>>   
> Put it under allOf. Entire block should be before additionalProperties
> (just like in example-schema).
>
>> +if:
>> +  properties:
>> +    compatible:
>> +      contains:
>> +        const: fixed-clock-nvmem
>> +
>> +then:
>> +  properties:
>> +    nvmem-cells:
>> +      maxItems: 2
> Anyway, I don't think you tested it. Provide a DTS user of this. I don't
> think it works and such user would point to mistakes.
>
> Properties should be defined in top-level properties:, not in
> allOf:if:then. In allOf:if:then you only narrow them.

Ah, got it. Added an example dts block to the document, this revealed 
the issues, indeed didn't test the bindings.

Fixed it into an "allOf" to properly narrow the properties.

I'll test and post a v4 in a jiffie.

>
>> +      description:
>> +        Reads clock-frequency and/or clock-accuracy from an NVMEM provider in
>> +        binary native integer format. The size of the NVMEM cell can be 1, 2, 4
>> +        or 8 bytes. If the contents of the nvmem are all zeroes or all 0xff, the
>> +        value reverts to the one given in the property.
>> +
> Best regards,
> Krzysztof
>

-- 
Mike Looijmans
System Expert

TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijmans@...ic.nl
W: www.topic.nl