[PATCH] clk: at91: sama5d2: Mark device OF_POPULATED after setup

Saravana Kannan saravanak at google.com
Mon Feb 1 12:16:32 EST 2021


On Mon, Feb 1, 2021 at 2:54 AM Geert Uytterhoeven <geert at linux-m68k.org> wrote:
>
> Hi Saravana,
>
> On Thu, Jan 28, 2021 at 6:08 PM Saravana Kannan <saravanak at 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



More information about the linux-arm-kernel mailing list