On Mon, Feb 1, 2021 at 2:54 AM Geert Uytterhoeven <ge...@linux-m68k.org> wrote: > > Hi Saravana, > > On Thu, Jan 28, 2021 at 6:08 PM Saravana Kannan <sarava...@google.com> wrote: > > I already accounted for early clocks like this when I designed > > fw_devlink. Each driver shouldn't need to set OF_POPULATED. > > drivers/clk/clk.c already does this for you. > > > > I think the problem is that your driver is using > > CLK_OF_DECLARE_DRIVER() instead of CLK_OF_DECLARE(). The comments for > > CLK_OF_DECLARE_DRIVER() says: > > /* > > * Use this macro when you have a driver that requires two initialization > > * routines, one at of_clk_init(), and one at platform device probe > > */ > > > > In your case, you are explicitly NOT having a driver bind to this > > clock later. So you shouldn't be using CLK_OF_DECLARE() instead. >
Typo. I meant to say this driver SHOULD be using CLK_OF_DECLARE() instead. I wonder if this is what caused you to send the email -- because we are saying the same thing. > Unless I'm missing something, name##_of_clk_init_driver() clearing > OF_POPULATED again causes consumer driver probing to be postponed by > fw_devlink until the second initialization phase of the provider has been > completed? Right, if they use CLK_OF_DECLARE_DRIVER() what you said above will happen and that's the issue they are trying to fix. > This is wrong if the consumer only needs a clock instantiated during the > first phase, and may cause issues if the consumer is a critical device. > E.g. a timer, on ARM SoCs lacking an architecture timer (pre-Cortex > A7/A15) or global timer (pre-Cortex A9, or single-core Cortex A9). > Probably there are more examples. So, needing devices like IRQ, timer and clocks early is fine. fw_devlink can handle that correctly if the proper macros are used (since most frameworks set the OF_POPULATED flag for these devices). -Saravana
