linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Ming Lei <ming.lei@canonical.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Takashi Iwai <tiwai@suse.de>, Alan Cox <alan@lxorguk.ukuu.org.uk>,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 0/5] driver core: driver probe asynchronously
Date: Sun, 09 Sep 2012 17:47:46 +1000	[thread overview]
Message-ID: <1347176866.2385.100.camel@pasglop> (raw)
In-Reply-To: <20120909025702.GB9525@kroah.com>

On Sat, 2012-09-08 at 19:57 -0700, Greg Kroah-Hartman wrote:
> As you state, this doesn't really solve the problem, and will cause a
> lot more (think about all the busses that aren't expecting to have
> their
> probe functions called at the same time as other probe functions are
> being called.)
> 
> So while I applaud the effort, I can't accept this due to the past
> history of when it was tried before. 

Maybe a compromise would be to have ->probe() be called synchronously as
done currently, but to add support for a specific -EAGAIN return from
it, requiring a later asynchronous re-probe ? (Possibly requiring an
explicit trigger)

That would allow drivers who fail some kind of "oddball" dependency (the
firmware load is such as case, there are a few others) to basically
install some kind of notifier and try again later when the dependency
has been fulfilled.

That way existing drivers still behave synchronously, there is no
breakage unless drivers are explicitly modified for async probing.

Cheers,
Ben.



  reply	other threads:[~2012-09-09  7:48 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-08 23:25 [RFC PATCH 0/5] driver core: driver probe asynchronously Ming Lei
2012-09-08 23:25 ` [RFC PATCH 1/5] driver core: driver probe at the last minute in driver_register Ming Lei
2012-09-08 23:25 ` [RFC PATCH 2/5] driver core: introduce driver_register_sync helper Ming Lei
2012-09-08 23:25 ` [RFC PATCH 3/5] driver core: platform: apply driver_register_sync for platform_driver_probe Ming Lei
2012-09-08 23:25 ` [RFC PATCH 4/5] driver core: remove __must_check on declaration of driver_attach Ming Lei
2012-09-08 23:25 ` [RFC PATCH 5/5] driver core: implement asynchorous probe() inside driver_register Ming Lei
2012-09-09  2:57 ` [RFC PATCH 0/5] driver core: driver probe asynchronously Greg Kroah-Hartman
2012-09-09  7:47   ` Benjamin Herrenschmidt [this message]
2012-09-09  7:56     ` Takashi Iwai
2012-09-09 10:44   ` Ming Lei

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=1347176866.2385.100.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ming.lei@canonical.com \
    --cc=tiwai@suse.de \
    --cc=torvalds@linux-foundation.org \
    /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).