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

[Tom Rini <trini@konsulko.com>]

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

On Sat, Nov 20, 2021 at 10:06:55AM -0500, Sean Anderson wrote:
> 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?

As a fall back?  I'm still unclear as to why the right answer isn't
something along the lines of "work with upstream to get appropriate
bindings accepted".  I think I might have even misread the comment about
SystemReady IR before even.  The assigned-lock-x property isn't in the
upstream binding?  So now we're trying to do what exactly here?

And to be clear, the situation with the layerscape dts files that's just
now getting sorted out has me extra skeptical of "just modify the dts in
U-Boot to ..." changes.  The goal within U-Boot is that our bindings are
accepted upstream (as upstream accepts non-Linux bindings) and I prefer
to start asking "is this a binding that's applicable to other firmwares
too?".

-- 
Tom

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