All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Luis R. Rodriguez" <mcgrof@suse.com>
To: Yuval Mintz <Yuval.Mintz@qlogic.com>
Cc: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
	Joseph Salisbury <joseph.salisbury@canonical.com>,
	Kay Sievers <kay@vrfy.org>,
	One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>,
	Tim Gardner <tim.gardner@canonical.com>,
	Pierre Fersing <pierre-fersing@pierref.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Oleg Nesterov <oleg@redhat.com>,
	Benjamin Poirier <bpoirier@suse.de>,
	Nagalakshmi Nandigama <nagalakshmi.nandigama@avagotech.com>,
	Praveen Krishnamoorthy <praveen.krishnamoorthy@avagotech.com>,
	Sreekanth Reddy <sreekanth.reddy@avagotech.com>,
	Abhijit Mahajan <abhijit.mahajan@avagotech.com>,
	Hariprasad S <hariprasad@chelsio.com>,
	Santosh Rastapur <santosh@chelsio.com>,
	"MPT-FusionLinux.pdl@avagotech.com" <MPT-Fusi>
Subject: Re: [PATCH 1/3] driver core: enable drivers to use deferred probe from init
Date: Mon, 28 Jul 2014 17:38:11 +0200	[thread overview]
Message-ID: <20140728153811.GD21930@wotan.suse.de> (raw)
In-Reply-To: <B5657A6538887040AD3A81F1008BEC63B06F9A@avmb3.qlogic.org>

On Mon, Jul 28, 2014 at 03:12:11PM +0000, Yuval Mintz wrote:
> > +static int __driver_probe_device(struct device_driver *drv, struct
> > +device *dev) {
> > +	if (drv->delay_probe && !dev->init_delayed_probe) {
> > +		dev_info(dev, "Driver %s requests probe deferral on init\n",
> > +			 drv->name);
> > +		dev->init_delayed_probe = true;
> > +		driver_deferred_probe_add(dev);
> > +		return -EPROBE_DEFER;
> > +	}
> > +
> > +	return really_probe(dev, drv);
> > +}
> 
> Perhaps this is a silly question, but what guarantees that the deferred probe
> list will actually be triggered, e.g., in case the delayed device is the last device
> in the system?

The dev->init_delayed_probe is used to ensure that we'd add the device to the
deferred probe list once making this a per device thing if the driver has the
field delay_probe set to true. This technically also allows this to be a per
device thing so with some more work we could enable drivers to only enable this
for specific devices but at this point this did not seem required.

> [From drivers/base/dd.c  - "A successful driver probe will trigger moving all
> devices from the pending to the active list so that the workqueue will
> eventually retry them]

I had not noticed this, thanks for pointing this out, in this case
if __driver_probe_device() is still used to retrigger a probe it will
be added back to the deferred list but since dev->init_delayed_probe
is still false. I checked the original commit that added this feature
d1c3414c but in the code I see that bus_probe_device(dev) is used and
I only see the device itself being removed from the deferred probe list,
nothing else.

  Luis

WARNING: multiple messages have this Message-ID (diff)
From: "Luis R. Rodriguez" <mcgrof@suse.com>
To: Yuval Mintz <Yuval.Mintz@qlogic.com>
Cc: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
	Joseph Salisbury <joseph.salisbury@canonical.com>,
	Kay Sievers <kay@vrfy.org>,
	One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>,
	Tim Gardner <tim.gardner@canonical.com>,
	Pierre Fersing <pierre-fersing@pierref.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Oleg Nesterov <oleg@redhat.com>,
	Benjamin Poirier <bpoirier@suse.de>,
	Nagalakshmi Nandigama <nagalakshmi.nandigama@avagotech.com>,
	Praveen Krishnamoorthy <praveen.krishnamoorthy@avagotech.com>,
	Sreekanth Reddy <sreekanth.reddy@avagotech.com>,
	Abhijit Mahajan <abhijit.mahajan@avagotech.com>,
	Hariprasad S <hariprasad@chelsio.com>,
	Santosh Rastapur <santosh@chelsio.com>,
	"MPT-FusionLinux.pdl@avagotech.com" 
	<MPT-FusionLinux.pdl@avagotech.com>,
	linux-scsi <linux-scsi@vger.kernel.org>,
	netdev <netdev@vger.kernel.org>
Subject: Re: [PATCH 1/3] driver core: enable drivers to use deferred probe from init
Date: Mon, 28 Jul 2014 17:38:11 +0200	[thread overview]
Message-ID: <20140728153811.GD21930@wotan.suse.de> (raw)
In-Reply-To: <B5657A6538887040AD3A81F1008BEC63B06F9A@avmb3.qlogic.org>

On Mon, Jul 28, 2014 at 03:12:11PM +0000, Yuval Mintz wrote:
> > +static int __driver_probe_device(struct device_driver *drv, struct
> > +device *dev) {
> > +	if (drv->delay_probe && !dev->init_delayed_probe) {
> > +		dev_info(dev, "Driver %s requests probe deferral on init\n",
> > +			 drv->name);
> > +		dev->init_delayed_probe = true;
> > +		driver_deferred_probe_add(dev);
> > +		return -EPROBE_DEFER;
> > +	}
> > +
> > +	return really_probe(dev, drv);
> > +}
> 
> Perhaps this is a silly question, but what guarantees that the deferred probe
> list will actually be triggered, e.g., in case the delayed device is the last device
> in the system?

The dev->init_delayed_probe is used to ensure that we'd add the device to the
deferred probe list once making this a per device thing if the driver has the
field delay_probe set to true. This technically also allows this to be a per
device thing so with some more work we could enable drivers to only enable this
for specific devices but at this point this did not seem required.

> [From drivers/base/dd.c  - "A successful driver probe will trigger moving all
> devices from the pending to the active list so that the workqueue will
> eventually retry them]

I had not noticed this, thanks for pointing this out, in this case
if __driver_probe_device() is still used to retrigger a probe it will
be added back to the deferred list but since dev->init_delayed_probe
is still false. I checked the original commit that added this feature
d1c3414c but in the code I see that bus_probe_device(dev) is used and
I only see the device itself being removed from the deferred probe list,
nothing else.

  Luis

WARNING: multiple messages have this Message-ID (diff)
From: "Luis R. Rodriguez" <mcgrof@suse.com>
To: Yuval Mintz <Yuval.Mintz@qlogic.com>
Cc: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
	Joseph Salisbury <joseph.salisbury@canonical.com>,
	Kay Sievers <kay@vrfy.org>,
	One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>,
	Tim Gardner <tim.gardner@canonical.com>,
	Pierre Fersing <pierre-fersing@pierref.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Oleg Nesterov <oleg@redhat.com>,
	Benjamin Poirier <bpoirier@suse.de>,
	Nagalakshmi Nandigama <nagalakshmi.nandigama@avagotech.com>,
	Praveen Krishnamoorthy <praveen.krishnamoorthy@avagotech.com>,
	Sreekanth Reddy <sreekanth.reddy@avagotech.com>,
	Abhijit Mahajan <abhijit.mahajan@avagotech.com>,
	Hariprasad S <hariprasad@chelsio.com>,
	Santosh Rastapur <santosh@chelsio.com>,
	"MPT-FusionLinux.pdl@avagotech.com" <MPT-Fusi
Subject: Re: [PATCH 1/3] driver core: enable drivers to use deferred probe from init
Date: Mon, 28 Jul 2014 17:38:11 +0200	[thread overview]
Message-ID: <20140728153811.GD21930@wotan.suse.de> (raw)
In-Reply-To: <B5657A6538887040AD3A81F1008BEC63B06F9A@avmb3.qlogic.org>

On Mon, Jul 28, 2014 at 03:12:11PM +0000, Yuval Mintz wrote:
> > +static int __driver_probe_device(struct device_driver *drv, struct
> > +device *dev) {
> > +	if (drv->delay_probe && !dev->init_delayed_probe) {
> > +		dev_info(dev, "Driver %s requests probe deferral on init\n",
> > +			 drv->name);
> > +		dev->init_delayed_probe = true;
> > +		driver_deferred_probe_add(dev);
> > +		return -EPROBE_DEFER;
> > +	}
> > +
> > +	return really_probe(dev, drv);
> > +}
> 
> Perhaps this is a silly question, but what guarantees that the deferred probe
> list will actually be triggered, e.g., in case the delayed device is the last device
> in the system?

The dev->init_delayed_probe is used to ensure that we'd add the device to the
deferred probe list once making this a per device thing if the driver has the
field delay_probe set to true. This technically also allows this to be a per
device thing so with some more work we could enable drivers to only enable this
for specific devices but at this point this did not seem required.

> [From drivers/base/dd.c  - "A successful driver probe will trigger moving all
> devices from the pending to the active list so that the workqueue will
> eventually retry them]

I had not noticed this, thanks for pointing this out, in this case
if __driver_probe_device() is still used to retrigger a probe it will
be added back to the deferred list but since dev->init_delayed_probe
is still false. I checked the original commit that added this feature
d1c3414c but in the code I see that bus_probe_device(dev) is used and
I only see the device itself being removed from the deferred probe list,
nothing else.

  Luis

  reply	other threads:[~2014-07-28 15:38 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-28 14:34 [PATCH 1/3] driver core: enable drivers to use deferred probe from init Luis R. Rodriguez
2014-07-28 14:34 ` [PATCH 2/3] cxgb4: ask for deferred probe Luis R. Rodriguez
2014-07-28 14:34 ` [PATCH 3/3] mptsas: " Luis R. Rodriguez
2014-07-28 14:51 ` [PATCH 1/3] driver core: enable drivers to use deferred probe from init Takashi Iwai
2014-07-28 15:01   ` Luis R. Rodriguez
2014-07-28 15:01     ` Luis R. Rodriguez
2014-07-28 15:12 ` Yuval Mintz
2014-07-28 15:12   ` Yuval Mintz
2014-07-28 15:12   ` Yuval Mintz
2014-07-28 15:38   ` Luis R. Rodriguez [this message]
2014-07-28 15:38     ` Luis R. Rodriguez
2014-07-28 15:38     ` Luis R. Rodriguez
2014-07-28 15:46     ` Yuval Mintz
2014-07-28 15:46       ` Yuval Mintz
2014-07-28 15:46       ` Yuval Mintz
2014-07-28 16:52       ` Luis R. Rodriguez
2014-07-28 16:52         ` Luis R. Rodriguez
2014-07-28 16:52         ` Luis R. Rodriguez
2014-07-28 16:59         ` Luis R. Rodriguez
2014-07-28 16:59           ` Luis R. Rodriguez
2014-07-28 16:59           ` Luis R. Rodriguez
2014-07-28 18:30           ` Yuval Mintz
2014-07-28 18:30             ` Yuval Mintz
2014-07-28 18:30             ` Yuval Mintz
2014-07-28 18:48             ` Luis R. Rodriguez
2014-07-28 18:48               ` Luis R. Rodriguez
2014-07-28 18:48               ` Luis R. Rodriguez

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=20140728153811.GD21930@wotan.suse.de \
    --to=mcgrof@suse.com \
    --cc=Yuval.Mintz@qlogic.com \
    --cc=abhijit.mahajan@avagotech.com \
    --cc=akpm@linux-foundation.org \
    --cc=bpoirier@suse.de \
    --cc=gnomes@lxorguk.ukuu.org.uk \
    --cc=gregkh@linuxfoundation.org \
    --cc=hariprasad@chelsio.com \
    --cc=joseph.salisbury@canonical.com \
    --cc=kay@vrfy.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mcgrof@do-not-panic.com \
    --cc=nagalakshmi.nandigama@avagotech.com \
    --cc=oleg@redhat.com \
    --cc=penguin-kernel@I-love.SAKURA.ne.jp \
    --cc=pierre-fersing@pierref.org \
    --cc=praveen.krishnamoorthy@avagotech.com \
    --cc=santosh@chelsio.com \
    --cc=sreekanth.reddy@avagotech.com \
    --cc=tim.gardner@canonical.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.