On Wed, Apr 05, 2023 at 02:57:26PM +0200, Paul Cercueil wrote:
> Le lundi 27 mars 2023 à 21:24 +0200, Maxime Ripard a écrit :
> > On Fri, Mar 24, 2023 at 08:58:48PM +0000, Aidan MacDonald wrote:
> > > > > My suggestion: add a per-clock bitmap to keep track of which
> > > > > parents
> > > > > are allowed. Any operation that would select a parent clock not
> > > > > on the
> > > > > whitelist should fail. Automatic reparenting should only select
> > > > > from
> > > > > clocks on the whitelist. And we need new DT bindings for
> > > > > controlling
> > > > > the whitelist, for example:
> > > > > 
> > > > >     clock-parents-0 = <&clk1>, <&pll_c>;
> > > > >     clock-parents-1 = <&clk2>, <&pll_a>, <&pll_b>;
> > > > > 
> > > > > This means that clk1 can only have pll_c as a parent, while
> > > > > clk2 can
> > > > > have pll_a or pll_b as parents. By default every clock will be
> > > > > able
> > > > > to use any parent, so a list is only needed if the machine
> > > > > needs a
> > > > > more restrictive policy.
> > > > > 
> > > > > assigned-clock-parents should disable automatic reparenting,
> > > > > but allow
> > > > > explicit clk_set_parent(). This will allow clock drivers to
> > > > > start doing
> > > > > reparenting without breaking old DTs.
> > > > 
> > > > I'm generally not a fan of putting all these policies in the
> > > > device
> > > > tree. Do you have an example where it wouldn't be possible to do
> > > > exactly
> > > > this from the driver itself?
> > > 
> > > I'm confused. What's implicit in the example is clk1 and clk2 might
> > > have *other* possible choices of parent clock and the device tree
> > > is
> > > limiting what the OS is allowed to choose.
> > > 
> > > Why would you put such arbitrary limitations into the driver?
> > 
> > Why would we put such arbitrary limitations in the firmware? As this
> > entire thread can attest, people are already using the device tree to
> > work around the limitations of the Linux driver, or reduce the
> > features of Linux because they can rely on the device tree. Either
> > way, it's linked to the state of the Linux driver, and any other OS
> > or
> > Linux version could very well implement something more dynamic.
> 
> Probably because if we have to choose between setting policy in the
> kernel or in the firmware, it is arguably better to set it in the
> firmware.

I have a very different view on this I guess. Firmware is (most of the
time) hard to update, and the policy depend on the state of support of a
given OS so it's likely to evolve. The kernel is the best place to me to
put that kind of policy. Why do you think differently?

> Especially when talking about clocks, as the firmware is already the
> one programming the boot clocks.

I'm not sure what your point is there. I don't think I ever saw a
firmware getting the clocks right for every possible scenario on a given
platform. And if it was indeed the case, then we wouldn't even a kernel
driver.

Maxime