[RFC PATCH v2 00/11] clk: imx8mn: setup clocks from the device tree

[Stephen Boyd]

Quoting Michael Nazzareno Trimarchi (2023-01-26 02:49:54)
> Hi
> 
> On Wed, Jan 25, 2023 at 10:11 PM Stephen Boyd <sboyd at kernel.org> wrote:
> >
> > Quoting Dario Binacchi (2023-01-01 09:57:29)
> > > The idea for this series was born back from Dublin (ELCE 2022) after
> > > having attended the talk entitled "Updating and Modernizing Clock
> > > Drivers" held by Chen-Yu Tsai and the availability of a board with
> > > imx8mn SOC.
> >
> > Interesting. I didn't see any mention of putting clks into DT in that
> > presentation.
> >
> > >
> > > This series aims to setup all imx8mn's clocks from the device tree and
> > > remove the legacy setup code with hardwired parameters.
> >
> > Please, no! We don't want one node per clk style of bindings.
> 
> I think the idea behind is:
> - create a way from silicon vendor to export their clock mapping with
> automatic exportation

I suspect silicon vendors automatically generate their clk drivers
today.

> - reduce the copy and paste code across the drivers
> - avoid code duplication

Code duplication should be avoided. Surely the clk_ops is shared? Data
duplication is the real problem here. The status quo has been to have
data descriptions of clks in drivers so that drivers can turn them on.
If we're trying to avoid bloat then we only enable the drivers that we
care about, or make them modular so they don't waste kernel memory.

If you have ideas on how to avoid duplication there then by all means
implement them. Don't move the data duplication problem to devicetree
though.

I've been wondering if we can tag drivers that are compiled into the
kernel as freeable if they aren't ever going to probe because they're
for some SoC that isn't present. That would allow us to shed various
builtin clk drivers on systems instead of forcing us to make everything
a module.

> 
> Is the binding a way to solve this problem?

Don't think so.

> If you don't want one node
> per clk style bindings, did you still think that the way
> to go is totally wrong?

Yes.