On 05/06/2023 12:01, Mike Looijmans wrote: > 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. Linux driver problems are not a reason to add bindings for virtual hardware... Best regards, Krzysztof
