Hi, On Tue, May 30, 2023 at 6:03 PM Dmitry Rokosov <ddrokosov@xxxxxxxxxxxxxx> wrote: [...] > > If I am understanding correctly, this series implements the child > > controller and a parent, which is unimplemented, provides the child with > > sys_pll_div16. > > The thing I am missing is whether the child controller has some outputs > > that depend on this sys_pll_div16 input & whether those are documented > > in this series. Regardless, you should be able to add more output clocks > > without compatibility issues. Conor, the short answer is yes, the "gen_sel" mux (see patch 6/6 from this series, which is then part of a clock tree that's an output of the peripheral clock controller) uses sys_pll_div16 as input. Dmitry goes into more details below. [...] > As for new input clock connections, such as the cpu_clock > (sys_pll_div16), these are handled by clock muxing abstraction, allowing > CCF to find the clock object by fw.name and returning -ENOENT if the > connection is missing without breaking any CCF flow. It happens in the > kernel function clk_core_fill_parent_index() > https://elixir.bootlin.com/linux/latest/source/drivers/clk/clk.c#L424 > Despite not having the connection for the new input in the old Device > Tree version, this will not break kernel boot flow and workflow, and the > new clock object just would not be utilized. > > Based on the presented arguments, I fully agree with Jerome's position. > We can add new connections and objects in new driver versions, but their > removal is prohibited. > > If it's alright with you, I would prefer to keep the Peripherals and PLL > clock driver and their bindings as they are, and continue with the CPU > and Audio clock controllers in a separate patch series. Would that be > feasible for you? To me this sounds good! Best regards, Martin
