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

[Tom Rini <trini@konsulko.com>]

[-- Attachment #1: Type: text/plain, Size: 2233 bytes --]

On Sat, Nov 20, 2021 at 04:21:12PM +0100, Mark Kettenis wrote:
> > From: Sean Anderson <seanga2@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@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@chromium.org>
> > >>> Signed-off-by: Peng Fan <peng.fan@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 ;).

Yeah, so this needs a better commit message to explain what the
reasoning / logic is, in a positive manner, rather than negative.  And
the binding portion needs a longer explanation.  And it needs to be sent
upstream.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]