Hi Peng, On Sun, 21 Nov 2021 at 20:33, Peng Fan (OSS) <peng....@oss.nxp.com> wrote: > > + Rob > > On 2021/11/20 20:57, 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....@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. > >> > >> 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. > > > > As Sean said, this is to serve cast that linux and U-Boot use the same > device tree, I mean U-Boot runtime export device tree to linux for SR-IR > (system-ready IR) booting. > > Linux needs assigned-clocks to some reason, but U-Boot not need that > because the driver not added the support or not a must to have that. > > Because assigned-clocks failure in U-Boot will cause probe fail now, > the device driver will report failure. > > You mean rename this to "ignore-clk-defaults" or keep > "u-boot,ignore-clk-defauls" or "firmware,ignore-clk-defaults" to linux > device tree binding? > > I could try to send to linux kernel with "firmware" as a prefix.
I'd argue that you are safer with a 'u-boot,' prefix since even U-Boot might one day implement these clocks if they are needed there. Then we could drop the property. This seems like something that is specific to a project. Regards, Simon