On Tue, Sep 17, 2024 at 10:21:32AM +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 ? Devices should be described in full in the bindings, regardless of whether or not the driver for the device makes use of that information. Cheers, Conor, > > 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.
Attachment:
signature.asc
Description: PGP signature