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