[lkml]   [2003]   [Jan]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: propagating failures down to pci_module_init()
On Mon, Jan 20, 2003 at 04:33:21PM +0000, Christoph Hellwig wrote:
> On Mon, Jan 20, 2003 at 03:54:35PM +0000, Dave Jones wrote:
> > I've got a wierd situation with a certain chipset for agpgart.
> > There are a few cases where I want to be able to use the existing
> > pci_driver api to detect the right PCI device, and call
> > the relevant .probe routine. No problem there.
> >
> > The problem is that in these cases, I want to be able to read
> > a certain register in that device, and if a bit is 0, bail out
> > of the .probe function with -ENODEV, and make the loading of
> > the module fail.
> >
> > The problem is that the ENODEV in my .probe routine doesn't
> > propagate back down as far as pci_module_init().
> >
> > Ideas ?
> Just use pci_register_driver.

Nope. Look at pci_module_init code. It propagates pci_register_driver
return value.

The _real_ problem is that ->probe return value is not propagated back
to pci_register_driver return value. The reason for this is that you
may call ->probe many times, and nobody has written the code to collate
the error returns.

Since one can only sanely return an error code when there was _one_
device and it failed, you are rather limited in error propagation.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:32    [W:0.032 / U:1.508 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site