Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <5e900bf1-2a5c-7152-7971-37bcadd80e3e@linaro.org>
Date:   Mon, 5 Jun 2023 16:05:35 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.2
Subject: Re: [PATCH v3 1/2] dt-bindings: clock: fixed-clock: Add nvmem support
Content-Language: en-US
To:     Mike Looijmans <mike.looijmans@topic.nl>,
        devicetree@vger.kernel.org, linux-clk@vger.kernel.org
Cc:     Conor Dooley <conor+dt@kernel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Michael Turquette <mturquette@baylibre.com>,
        Rob Herring <robh+dt@kernel.org>,
        Stephen Boyd <sboyd@kernel.org>, linux-kernel@vger.kernel.org
References: <1b153bce-a66a-45ee-a5c6-963ea6fb1c82.949ef384-8293-46b8-903f-40a477c056ae.1d0217a8-661f-4359-b77b-02222c761b01@emailsignatures365.codetwo.com>
 <20230605133410.15076-1-mike.looijmans@topic.nl>
 <5d1f08f1-792b-255b-89f0-dd5fa2f0baa4@linaro.org>
 <96004048-0ba5-4cd6-406f-e1235c819c97@topic.nl>
From:   Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
In-Reply-To: <96004048-0ba5-4cd6-406f-e1235c819c97@topic.nl>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 05/06/2023 16:00, Mike Looijmans wrote:
> 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@topic.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.

Ah, ok.

> 
> 
>>
>>>     "#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.

The real DTS user would be also welcomed.

Best regards,
Krzysztof