On Thu, Nov 19, 2020 at 02:09:42PM +0000, Aisheng Dong wrote:
> > From: Greg Kroah-Hartman <[email protected]>
> > Sent: Thursday, November 19, 2020 9:10 PM
> > 
> > On Thu, Nov 19, 2020 at 04:13:34AM +0000, Aisheng Dong wrote:
> > > > Long story short, either
> > > >
> > > > * Don't care about the power domain in your clock driver.
> > > >
> > > > Or,
> > > >
> > > > * List the power domain in the clock controller's DT node and then
> > > > use the normal APIs to get the power domain. And defer like any
> > > > other driver if you can't get the power domain.
> > > >
> > >
> > > Yes, I understand those are for normal cases. But our case is a bit
> > > different and we don't want
> > > imx_clk_scu() API return PROBE_DEFER which is unnecessary for a hundred of
> > clocks.
> > > Even we want to defer probe, we prefer to defer in imx_clk_scu_init() 
> > > rather
> > than in imx_clk_scu().
> > 
> > What is wrong with PROBE_DEFER, that is what it is there for.
> 
> Yes, we can use PROBE_DEFER, just not want to defer in imx_clk_scu_init() 
> when creating
> sub clock devices. Instead, we want to defer at the beginning of clock driver 
> probe which
> can save tens of defer probes due to the same reasons that PD driver is not 
> ready.

There's nothing wrong with deferring that many times until your proper
driver is loaded, what does it cost you to do so?

> > > Maybe the things can be simplified as a simple requirement:
> > > How users can make Driver A (CLK) to be probed after Driver B (PD)
> > > without explicit firmware function dependency description (e.g. phandle in
> > DT)?
> > >
> > > As kernel core does not want to support it, then the left way may be
> > > change scu-pd driver Inicall level or provide a private callback to query 
> > > the
> > readiness.
> > 
> > No, do not mess with that, as it totally breaks when things are built as a 
> > module.
> > 
> 
> Can't this be addressed by proper module dependency? E.g clock module depends
> on power domain module. Then clock driver can only be loaded after power 
> domain.

Sure, if you can do that, make your modules load properly by symbol
dependency and all should be fine.  Have you done that?

thanks,

greg k-h

Reply via email to