All of lore.kernel.org
 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


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

WARNING: multiple messages have this Message-ID (diff)
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: 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  1:53 ` Andrew Morton
2006-03-26 22:30   ` Rene Herman
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: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-05  1:35           ` Dmitry Torokhov [this message]
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:45         ` Greg KH
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:36             ` Rene Herman
2006-04-05 18:44               ` Dmitry Torokhov
2006-04-05 18:44               ` Dmitry Torokhov
2006-04-05  1:48         ` 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 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-04 21:00     ` Greg KH
2006-04-04 20:23   ` Dmitry Torokhov
2006-04-04 19:10 ` gregkh

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 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.