From: Stephen Boyd <sboyd@kernel.org>
To: Saravana Kannan <saravanak@google.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Michael Turquette <mturquette@baylibre.com>,
Linus Walleij <linus.walleij@linaro.org>,
kernel-team@android.com, linux-clk@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1] clk: Mark a fwnode as initialized when using CLK_OF_DECLARE* macros
Date: Wed, 01 Mar 2023 14:45:12 -0800 [thread overview]
Message-ID: <a3bde7aa1793c20638cbf2749f3209a2.sboyd@kernel.org> (raw)
In-Reply-To: <CAGETcx82r-YC7cBUY5xa57FCEOUP_BeGNp2zURG=HUJkUMSVPA@mail.gmail.com>
Quoting Saravana Kannan (2023-03-01 13:25:13)
> On Wed, Mar 1, 2023 at 12:48 PM Stephen Boyd <sboyd@kernel.org> wrote:
> >
> > Quoting Stephen Boyd (2023-03-01 12:40:03)
> > > Quoting Saravana Kannan (2023-02-28 17:25:06)
> > > > The CLK_OF_DECLARE macros sometimes prevent the creation of struct
> > > > devices for the device node being handled. It does this by
> > > > setting/clearing OF_POPULATED flag. This can block the probing of some
> > > > devices because fw_devlink will block the consumers of this node till a
> > > > struct device is created and probed.
> > >
> > > Why can't you use CLK_OF_DECLARE_DRIVER()?
> >
> > Ah I misunderstood. CLK_OF_DECLARE() _always_ prevents the creation of a
> > struct device for the device node being handled. The 'sometimes' threw
> > me off.
>
> The "sometimes" is because dependending on the macro we go back and
> clear the flag.
Ok. Maybe instead of this paragraph you can explain the problem being
fixed, specifically ux500 container node not being marked as
"initialized" and that preventing consumer devices from probing. That
would help the reviewer understand the specific problem you're solving.
>
> > >
> > > >
> > > > Set the appropriate fwnode flags when these device nodes are initialized
> > > > by the clock framework and when OF_POPULATED flag is set/cleared. This
> > > > will allow fw_devlink to handle the dependencies correctly.
This is the "what" and not the "why".
> >
> > How is this different from commit 3c9ea42802a1 ("clk: Mark fwnodes when
> > their clock provider is added/removed")? Do you have some user of
> > CLK_OF_DECLARE() that isn't registering an OF clk provider?
>
> So it looks like drivers don't always register the same node used for
> CLK_OF_DECLARE() as the clock provider. So, this is covering for the
> case when that's not true.
Please add this information to the commit text. Otherwise the patch
looks entirely unnecessary.
If the node used for CLK_OF_DECLARE() isn't the same as the node as the
clock provider then how are we certain that the CLK_OF_DECLARE() probe
function has actually registered a clk provider?
Should we simply remove the calls to fwnode_dev_initialized() in the OF
clk provider functions and put the call in CLK_OF_DECLARE() (and
specifically _not_ CLK_OF_DECLARE_DRIVER) as this patch does? What about
bindings that are registering clks early with CLK_OF_DECLARE_DRIVER()
and then probing something like a reset controller later with a platform
device created by an MFD matching the same compatible as the
CLK_OF_DECLARE_DRIVER() compatible?
next prev parent reply other threads:[~2023-03-01 22:45 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-01 1:25 [PATCH v1] clk: Mark a fwnode as initialized when using CLK_OF_DECLARE* macros Saravana Kannan
2023-03-01 12:10 ` Linus Walleij
2023-03-01 20:40 ` Stephen Boyd
2023-03-01 20:45 ` Saravana Kannan
2023-03-01 20:48 ` Stephen Boyd
2023-03-01 21:25 ` Saravana Kannan
2023-03-01 22:45 ` Stephen Boyd [this message]
2023-03-01 23:52 ` Saravana Kannan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a3bde7aa1793c20638cbf2749f3209a2.sboyd@kernel.org \
--to=sboyd@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=kernel-team@android.com \
--cc=linus.walleij@linaro.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mturquette@baylibre.com \
--cc=saravanak@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox