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 > > > > > > 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 > > > Signed-off-by: Peng Fan > > > --- > > > > > > 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