On Thu, Oct 28, 2021 at 10:43:01PM -0400, Sean Anderson wrote: > > On 10/28/21 10:10 PM, Tom Rini wrote: > > On Fri, Oct 29, 2021 at 09:28:01AM +0800, Peng Fan (OSS) wrote: > > > From: Peng Fan <peng....@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 <s...@chromium.org> > > > Signed-off-by: Peng Fan <peng....@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. > > > > OK, right, so... it should be a generic property to say what, early > > firmware should ignore this clock unless otherwise required and use the > > preconfigured value? > > > > The issue is that for platforms sharing devicetrees between U-Boot and > Linux, Linux may add assigned-clocks which are not implemented in > U-Boot. Although assigning a specific frequency or parent to a clock may > not be necessary to use the device, it will fail to probe because the > clock cannot be found. I believe this property is intended for these > cases.
Alright. An example might help, but, why can't we either make this a positive general property of the node, or otherwise infer that from what's present in the node today? -- Tom
signature.asc
Description: PGP signature
