propagating failures down to pci_module_init()

propagating failures down to pci_module_init()

[Dave Jones]

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 ?

		Dave

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: propagating failures down to pci_module_init()

[Christoph Hellwig]

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.

Re: propagating failures down to pci_module_init()

[Jeff Garzik]

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.

	Jeff

Re: propagating failures down to pci_module_init()

[Dave Jones]

On Mon, Jan 20, 2003 at 11:52:36AM -0500, Jeff Garzik wrote:
 > 
 > 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.

*nod*. I cheated, and used a static global, which seems to get the
desired effect I was after.

		Dave

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs