On 17/09/2024 10:21:32+0300, Ciprian Marian Costea wrote: > On 9/12/2024 5:03 PM, Alexandre Belloni wrote: > > On 12/09/2024 15:36:46+0300, Ciprian Marian Costea wrote: > > > > Then should this mux be registered in the CCF so you can use the usual > > > > clock node properties? > > > > > > Hello Alexandre, > > > > > > In hardware, these clock muxes and divisors are part of the RTC module > > > itself and not external. Therefore, I would say no. > > > > This is irrelevant, if this is a clock mux, it must be in the CCF, just > > as when the RTC has a clock output. > > > > > > I understand your point, but taking into account the fact that FIRC clock > should be used in most scenarios, would it be acceptable to not export this > 'clksel' property in the devicetree bindings and simply use the FIRC clock > by default in the RTC driver ? > No, this doesn't work for RTCs because their lifecycle is longer than the system's and f you change a configuration from the default value without providing a way to control it, we won't have any upgrade path without breaking users. > At least for this patchset, in order to ease the review process. If > configurable clock source support would want to be enabled and exported via > bindings for this S32G2/S32G3 RTC driver, then CCF registration for this clk > mux could be added in future patches. -- Alexandre Belloni, co-owner and COO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
