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
Attachment:
signature.asc
Description: PGP signature
