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

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]

Date:   Mon, 5 Jun 2023 12:01:35 +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 v2 1/2] dt-bindings: clock: Add nvmem-clock

On 31-05-2023 21:27, Krzysztof Kozlowski wrote:
> On 26/05/2023 16:38, 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.
> This does not look like real hardware. I mean, the clock does not fetch
> its rate from nvmem, right? It's the Linux which does it, so basically
> you described here driver, not hardware.
Right, this just reads a setting from an NVMEM provider.
> Extend existing fixed-clock bindings to allow reading frequency via
> nvmem cells.

I just tried and implemented this, but it does not work. The reason is 
that the fixed-clock implementation returns "void" in its 
of_fixed_clk_setup() init function. The nvmem provider returns 
EPROBE_DEFER because it isn't ready at this early stage, and this error 
will not be propagated up because of the "void" signature. Thus, it's 
never retried and the clock just disappears.


> 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