All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@suse.de>
To: dtor_core@ameritech.net
Cc: rene.herman@keyaccess.nl, alsa-devel@alsa-project.org,
	linux-kernel@vger.kernel.org, tiwai@suse.de
Subject: Re: patch bus_add_device-losing-an-error-return-from-the-probe-method.patch added to gregkh-2.6 tree
Date: Tue, 4 Apr 2006 14:00:48 -0700	[thread overview]
Message-ID: <20060404210048.GA5694@suse.de> (raw)
In-Reply-To: <d120d5000604041323h448c1ccfi7e9dcedd82c385ba@mail.gmail.com>

On Tue, Apr 04, 2006 at 04:23:43PM -0400, Dmitry Torokhov wrote:
> On 4/4/06, gregkh@suse.de <gregkh@suse.de> wrote:
> >
> > --- gregkh-2.6.orig/drivers/base/bus.c
> > +++ gregkh-2.6/drivers/base/bus.c
> > @@ -372,14 +372,17 @@ int bus_add_device(struct device * dev)
> >
> >        if (bus) {
> >                pr_debug("bus %s: add device %s\n", bus->name, dev->bus_id);
> > -               device_attach(dev);
> > +               error = device_attach(dev);
> > +               if (error < 0)
> > +                       goto exit;
> 
> I do not believe that this is correct. The fact that _some_ driver
> failed to attach to a device does not necessarily mean that device
> itself does not exist. While this assuption might work for platform
> devices it won't work for other busses.

Hm, no, I unwound this mess, and found the following:

 - bus_add_device() calls device_attach()
 - device_attach() calls bus_for_each_drv() for every driver on the bus
 - bus_for_each_drv() walks all drivers on the bus and calls
   __device_attach() for every individual driver
 - __device_attach() calls driver_probe_device() for that driver and device
 - driver_probe_device() calls down to the probe() function for the
   driver, passing it that driver, if match() for the bus matches this
   device.
 - if that probe() function returns -ENODEV or -ENXIO[1] then the error
   is ignored and 0 is returned, causing the loop to continue to try
   more drivers
 - if the probe() function returns any other error code, it is
   propagated up, all the way back to bus_add_device.
 - if the probe() function returns 0, the device is bound to the driver,
   and it returns 0.  Hm, looks like we continue to loop here too, we
   could probably stop now that we have bound a driver to the device.

So, I'm pretty sure that this is safe and should work just fine.  To be
sure, let me go reboot my box with this change on it after I finish this
email :)

Does that help?

thanks,

greg k-h

[1] - stupid agp drivers (or some other video drivers) require this.  I
    need to go fix them up so they don't do this, if they haven't been
    fixed already...

  parent reply	other threads:[~2006-04-04 21:01 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-24  5:32 bus_add_device() losing an error return from the probe() method Rene Herman
2006-03-26  1:53 ` Andrew Morton
2006-03-26 22:30   ` Rene Herman
2006-03-26 22:30   ` Rene Herman
2006-03-26  1:53 ` Andrew Morton
2006-04-04 19:10 ` patch bus_add_device-losing-an-error-return-from-the-probe-method.patch added to gregkh-2.6 tree gregkh
2006-04-04 19:10 ` gregkh
2006-04-04 20:23   ` Dmitry Torokhov
2006-04-04 21:00     ` Greg KH
2006-04-04 21:00     ` Greg KH [this message]
2006-04-04 21:15       ` Greg KH
2006-04-04 21:15         ` Greg KH
2006-04-04 21:22         ` Andrew Morton
2006-04-04 21:22         ` Andrew Morton
2006-04-04 21:28       ` Dmitry Torokhov
2006-04-04 21:45         ` Greg KH
2006-04-04 21:45         ` Greg KH
2006-04-05  1:35           ` Dmitry Torokhov
2006-04-05  1:35             ` Dmitry Torokhov
2006-04-05  7:36             ` Russell King
2006-04-06  1:05               ` Greg KH
2006-04-06  1:05               ` Greg KH
2006-04-05  7:36             ` Russell King
2006-04-05  1:59           ` Dmitry Torokhov
2006-04-05  1:59           ` Dmitry Torokhov
2006-04-04 21:28       ` Dmitry Torokhov
2006-04-04 22:12       ` Rene Herman
2006-04-04 22:12       ` Rene Herman
2006-04-05  0:23         ` Rene Herman
2006-04-05  0:23         ` Rene Herman
2006-04-05  1:45           ` Dmitry Torokhov
2006-04-05  1:45             ` Dmitry Torokhov
2006-04-05 18:36             ` Rene Herman
2006-04-05 18:44               ` Dmitry Torokhov
2006-04-05 18:44               ` Dmitry Torokhov
2006-04-05 18:36             ` Rene Herman
2006-04-05  1:48         ` Dmitry Torokhov
2006-04-05 13:50           ` Rene Herman
2006-04-05 14:59             ` Dmitry Torokhov
2006-04-05 21:22               ` Rene Herman
2006-04-05 21:22               ` Rene Herman
2006-04-05 14:59             ` Dmitry Torokhov
2006-04-05 13:50           ` Rene Herman
2006-04-05 13:55           ` Rene Herman
2006-04-05 13:55           ` Rene Herman
2006-04-05  1:48         ` Dmitry Torokhov
2006-04-04 20:23   ` Dmitry Torokhov

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=20060404210048.GA5694@suse.de \
    --to=gregkh@suse.de \
    --cc=alsa-devel@alsa-project.org \
    --cc=dtor_core@ameritech.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rene.herman@keyaccess.nl \
    --cc=tiwai@suse.de \
    /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.