[PATCH V2] clk: introduce u-boot,ignore-clk-defaults

[Mark Kettenis]

> From: Sean Anderson <seanga2 at gmail.com>
> Date: Sat, 20 Nov 2021 10:06:55 -0500
> 
> On 11/20/21 7:57 AM, Tom Rini wrote:
> > On Sat, Nov 20, 2021 at 12:10:54PM +0000, Peng Fan (OSS) wrote:
> >>> Subject: [PATCH V2] clk: introduce u-boot,ignore-clk-defaults
> >>>
> >>> From: Peng Fan <peng.fan at nxp.com>
> >>>
> >>> Current code has a force clk_set_defaults in multiple stages, U-Boot reuse the
> >>> same device tree and Linux Kernel device tree, but we not register all the clks
> >>> as Linux Kernel, so clk_set_defaults will fail and cause the clk provider
> >>> registeration fail.
> >>>
> >>> So introduce a new property to ignore the default settings which could be
> >>> used by any node that wanna ignore default settings.
> >>>
> >>> Reviewed-by: Simon Glass <sjg at chromium.org>
> >>> Signed-off-by: Peng Fan <peng.fan at nxp.com>
> >>> ---
> >>>
> >>> V2:
> >>>   Add R-b tag
> >>>   Tom, Simon
> >>>     After a thought, I think still put it as a u-boot thing. assigned-clock-x is
> >>>     actually Linux specific, however I could not add the new property to Linux,
> >>>     because we are supporting SystemReady-IR, we need the
> >>> assigned-clock-x property
> >>>     in linux working and ignore it in U-Boot.
> >>
> >> Any more thoughts?
> > 
> > Just my continued request that you treat this as generic and submit the
> > binding upstream so it can be in the device tree for the platform.
> > 
> 
> Hmm.
> 
> Could we just do
> 
> /delete-property/ assigned-clocks;
> 
> in our u-boot dtsi?

No!  Those properties are needed by the OS loaded by U-Boot.

The right answer is probably that U-Boot should use these properties
to set up the clocks correctly.  Paradoxically that means the OS would
no longer have to worry about them and the properties could be deleted ;).