linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Marco Felsch <m.felsch@pengutronix.de>
Cc: Andrzej Hajda <a.hajda@samsung.com>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Grant Likely <grant.likely@arm.com>,
	Saravana Kannan <saravanak@google.com>,
	artem.bityutskiy@linux.intel.com, balbi@kernel.org,
	fntoth@gmail.com, gregkh@linuxfoundation.org,
	linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
	peter.ujfalusi@ti.com, rafael@kernel.org,
	kernel-team@android.com, nd <nd@arm.com>,
	kernel@pengutronix.de
Subject: Re: [PATCH v3] driver core: Break infinite loop when deferred probe can't be satisfied
Date: Tue, 9 Jun 2020 14:16:00 +0100	[thread overview]
Message-ID: <20200609131600.GE4583@sirena.org.uk> (raw)
In-Reply-To: <20200609121029.nfhgilpu5meoygoa@pengutronix.de>

[-- Attachment #1: Type: text/plain, Size: 2154 bytes --]

On Tue, Jun 09, 2020 at 02:10:29PM +0200, Marco Felsch wrote:
> On 20-06-09 11:27, Andrzej Hajda wrote:
> > On 09.06.2020 08:45, Marco Felsch wrote:
> > > On 20-06-08 13:11, Andrzej Hajda wrote:
> > >> On 08.06.2020 11:17, Marco Felsch wrote:
> > >>> On 20-03-26 18:31, Andy Shevchenko wrote:
> > >>>> On Thu, Mar 26, 2020 at 03:01:22PM +0000, Grant Likely wrote:
> > >>>>> On 25/03/2020 12:51, Andy Shevchenko wrote:
> > >>>>>> On Tue, Mar 24, 2020 at 08:29:01PM -0700, Saravana Kannan wrote:
> > >>>>>>> On Tue, Mar 24, 2020 at 5:38 AM Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:

Please delete unneeded context from mails when replying.  Doing this
makes it much easier to find your reply in the message, helping ensure
it won't be missed by people scrolling through the irrelevant quoted
material.

> > I think rule of 
> > thumb should be "do not expose yourself, until you are ready", which in 
> > this case means "do not call component_add, until resources are 
> > acquired" - ie resource acquisition should be performed in probe.

> Hm.. there are is no documentation which forbid this use-case. I thought
> that the component framework bind() equals the driver probe() function..

It does, the issue is perhaps more clearly expressed as saying that a
driver should acquire whatever resources it needs before starting to
make resources available to others, this includes but isn't limited to
registering new device nodes.  This ensures that the users don't then
start trying to use resources and have them torn down underneath them.

> > I use 
> > this approach mainly to avoid multiple deferred re-probes, but it should 
> > solve also this issue, so even if there will be solution to "deferred 
> > probe issues" in core it would be good to fix imx drivers.

> Pls, see my above comments. It is not only the imx driver. Also we
> shouldn't expect that driver-developers will follow a rule which is
> not written somewhere.

If you've got an idea where this should be documented patches welcome!
I can't think of anywhere sensibly discoverable to put something off the
top of my head.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  parent reply	other threads:[~2020-06-09 13:16 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-24 17:57 [PATCH v3] driver core: Break infinite loop when deferred probe can't be satisfied Andy Shevchenko
2020-03-25  3:29 ` Saravana Kannan
2020-03-25 12:51   ` Andy Shevchenko
2020-03-25 22:08     ` Saravana Kannan
2020-03-26  8:39       ` Rafael J. Wysocki
2020-03-26  9:45         ` Peter Ujfalusi
2020-03-26 12:03           ` Andy Shevchenko
2020-03-26 13:45             ` Grant Likely
2020-03-26 14:23               ` Andy Shevchenko
2020-03-26 11:57         ` Andy Shevchenko
2020-03-26 13:48           ` Grant Likely
2020-03-26 18:45         ` Saravana Kannan
2020-03-26 11:54       ` Andy Shevchenko
2020-03-26 14:46         ` Grant Likely
2020-03-26 19:55         ` Saravana Kannan
2020-03-26 15:01     ` Grant Likely
2020-03-26 15:20       ` Grant Likely
2020-03-26 16:31       ` Andy Shevchenko
2020-03-26 16:39         ` Greg KH
2020-03-26 18:06           ` Grant Likely
2020-03-27  8:03             ` Greg KH
2020-03-27 12:37               ` Grant Likely
2020-03-27 12:51                 ` Greg KH
2020-06-08  9:17         ` Marco Felsch
2020-06-08 11:11           ` Andrzej Hajda
2020-06-09  6:45             ` Marco Felsch
2020-06-09  7:30               ` Saravana Kannan
2020-06-09  9:27               ` Andrzej Hajda
2020-06-09 12:10                 ` Marco Felsch
2020-06-09 13:02                   ` Andrzej Hajda
2020-06-09 13:16                   ` Mark Brown [this message]
2020-06-08 11:13           ` Andy Shevchenko
2020-06-08 11:59             ` Marco Felsch
2020-06-08 12:11               ` Andy Shevchenko

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=20200609131600.GE4583@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=a.hajda@samsung.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=artem.bityutskiy@linux.intel.com \
    --cc=balbi@kernel.org \
    --cc=fntoth@gmail.com \
    --cc=grant.likely@arm.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=kernel-team@android.com \
    --cc=kernel@pengutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=m.felsch@pengutronix.de \
    --cc=nd@arm.com \
    --cc=peter.ujfalusi@ti.com \
    --cc=rafael@kernel.org \
    --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;
as well as URLs for NNTP newsgroup(s).