mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Aisheng Dong <aisheng.dong@nxp.com>
Cc: Saravana Kannan <saravanak@google.com>,
	Sudip Mukherjee <sudipm.mukherjee@gmail.com>,
	"Rafael J . Wysocki" <rafael@kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Shawn Guo <shawnguo@kernel.org>, Stephen Boyd <sboyd@kernel.org>
Subject: Re: [PATCH RESEND] driver core: export device_is_bound() to fix build failure
Date: Thu, 19 Nov 2020 15:25:38 +0100	[thread overview]
Message-ID: <X7aAYlgx0ZvUELlX@kroah.com> (raw)
In-Reply-To: <AM6PR04MB49662EB50652F3BC6FE67C9980E00@AM6PR04MB4966.eurprd04.prod.outlook.com>

On Thu, Nov 19, 2020 at 02:09:42PM +0000, Aisheng Dong wrote:
> > From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > 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	other threads:[~2020-11-19 14:24 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-07 22:47 Sudip Mukherjee
2020-11-08  8:23 ` Greg Kroah-Hartman
2020-11-09 10:14   ` Sudip Mukherjee
2020-11-09 10:37     ` Greg Kroah-Hartman
2020-11-09 10:57       ` Aisheng Dong
2020-11-09 11:18         ` Sudip Mukherjee
2020-11-09 11:32           ` Aisheng Dong
2020-11-09 11:42           ` Greg Kroah-Hartman
2020-11-09 11:41         ` Greg Kroah-Hartman
2020-11-09 11:55           ` Aisheng Dong
2020-11-09 12:04             ` Greg Kroah-Hartman
2020-11-09 12:05             ` Greg Kroah-Hartman
2020-11-09 12:26               ` Aisheng Dong
2020-11-09 12:48                 ` Greg Kroah-Hartman
2020-11-18 10:23                   ` Aisheng Dong
2020-11-18 10:45                     ` Greg Kroah-Hartman
2020-11-18 15:40                       ` Aisheng Dong
2020-11-18 22:22                         ` Saravana Kannan
2020-11-19  4:13                           ` Aisheng Dong
2020-11-19 13:10                             ` Greg Kroah-Hartman
2020-11-19 14:09                               ` Aisheng Dong
2020-11-19 14:25                                 ` Greg Kroah-Hartman [this message]
2020-11-19 15:20                                   ` Aisheng Dong

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=X7aAYlgx0ZvUELlX@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=aisheng.dong@nxp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=saravanak@google.com \
    --cc=sboyd@kernel.org \
    --cc=shawnguo@kernel.org \
    --cc=sudipm.mukherjee@gmail.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

Powered by JetHome