mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Dmitry Torokhov <dtor_core@ameritech.net>
To: Greg KH <gregkh@suse.de>
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 21:35:40 -0400	[thread overview]
Message-ID: <200604042135.41371.dtor_core@ameritech.net> (raw)
In-Reply-To: <20060404214522.GA20390@suse.de>

On Tuesday 04 April 2006 17:45, Greg KH wrote:
> On Tue, Apr 04, 2006 at 05:28:48PM -0400, Dmitry Torokhov wrote:
> > On 4/4/06, Greg KH <gregkh@suse.de> wrote:
> > >
> > > 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.
> > 
> > But why do we do that? probe() failing is driver's problem. The device
> > is still there and should still be presented in sysfs. I don't think
> > that we should stop if probe() fails - maybe next driver manages to
> > bind itself.
> 
> The device is still there.
> 
> Ah, I see what you are saying now.  Yeah, we should still add the
> default attributes for the bus and create the bus link even if some
> random driver had problems.  But then, we should still propagate the
> error back up, right?
> 

I don't think so because device creation did not fail. Otherwise how
would you as a caller of device_register() distinguish between the
following 2 scenarios:

 - you got -ENOMEM (or other error code) because device creation
   indeed failed;
 - you got -ENOMEM because some odd driver could not allocate 4MB
   of memory.

IOW you trying to propagate driver error to device creation code...

Also result of device_register() should not depend on whether
driver_register() was called earlier or not.

-- 
Dmitry

  reply	other threads:[~2006-04-05  1:35 UTC|newest]

Thread overview: 24+ 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-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 20:23   ` Dmitry Torokhov
2006-04-04 21:00     ` Greg KH
2006-04-04 21:15       ` Greg KH
2006-04-04 21:22         ` Andrew Morton
2006-04-04 21:28       ` Dmitry Torokhov
2006-04-04 21:45         ` Greg KH
2006-04-05  1:35           ` Dmitry Torokhov [this message]
2006-04-05  7:36             ` Russell King
2006-04-06  1:05               ` Greg KH
2006-04-05  1:59           ` Dmitry Torokhov
2006-04-04 22:12       ` Rene Herman
2006-04-05  0:23         ` Rene Herman
2006-04-05  1:45           ` Dmitry Torokhov
2006-04-05 18:36             ` Rene Herman
2006-04-05 18:44               ` Dmitry Torokhov
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 13:55           ` Rene Herman

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=200604042135.41371.dtor_core@ameritech.net \
    --to=dtor_core@ameritech.net \
    --cc=alsa-devel@alsa-project.org \
    --cc=gregkh@suse.de \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome