[PATCH] propagate pci_enable_device() errors

[PATCH] propagate pci_enable_device() errors

[Bjorn Helgaas]

Jeff Garzik pointed out that I should have propagated the error returned
from pci_enable_device() rather than making up -ENODEV.


Propagate pci_enable_device() error returns rather than using -ENODEV.

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>

===== drivers/atm/idt77252.c 1.25 vs edited =====
--- 1.25/drivers/atm/idt77252.c	2004-08-24 03:08:33 -06:00
+++ edited/drivers/atm/idt77252.c	2004-08-26 13:08:03 -06:00
@@ -3684,9 +3684,9 @@
 	int i, err;
 
 
-	if (pci_enable_device(pcidev)) {
+	if ((err = pci_enable_device(pcidev))) {
 		printk("idt77252: can't enable PCI device at %s\n", pci_name(pcidev));
-		return -ENODEV;
+		return err;
 	}
 
 	if (pci_read_config_word(pcidev, PCI_REVISION_ID, &revision)) {
===== drivers/isdn/tpam/tpam_main.c 1.12 vs edited =====
--- 1.12/drivers/isdn/tpam/tpam_main.c	2004-08-24 03:08:33 -06:00
+++ edited/drivers/isdn/tpam/tpam_main.c	2004-08-26 13:09:52 -06:00
@@ -88,10 +88,10 @@
 	tpam_card *card, *c;
 	int i, err;
 
-	if (pci_enable_device(dev)) {
+	if ((err = pci_enable_device(dev))) {
 		printk(KERN_ERR "TurboPAM: can't enable PCI device at %s\n",
 			pci_name(dev));
-		return -ENODEV;
+		return err;
 	}
 
 	/* allocate memory for the board structure */
===== drivers/misc/ibmasm/module.c 1.3 vs edited =====
--- 1.3/drivers/misc/ibmasm/module.c	2004-08-24 03:08:34 -06:00
+++ edited/drivers/misc/ibmasm/module.c	2004-08-26 13:11:17 -06:00
@@ -59,13 +59,13 @@
 
 static int __init ibmasm_init_one(struct pci_dev *pdev, const struct pci_device_id *id)
 {
-	int result = -ENOMEM;
+	int err, result = -ENOMEM;
 	struct service_processor *sp;
 
-	if (pci_enable_device(pdev)) {
+	if ((err = pci_enable_device(pdev))) {
 		printk(KERN_ERR "%s: can't enable PCI device at %s\n",
 			DRIVER_NAME, pci_name(pdev));
-		return -ENODEV;
+		return err;
 	}
 
 	sp = kmalloc(sizeof(struct service_processor), GFP_KERNEL);
===== drivers/net/tulip/de4x5.c 1.40 vs edited =====
--- 1.40/drivers/net/tulip/de4x5.c	2004-08-25 11:34:58 -06:00
+++ edited/drivers/net/tulip/de4x5.c	2004-08-26 13:13:04 -06:00
@@ -2242,8 +2242,8 @@
 		return -ENODEV;
 
 	/* Ok, the device seems to be for us. */
-	if (pci_enable_device (pdev))
-		return -ENODEV;
+	if ((error = pci_enable_device (pdev)))
+		return error;
 
 	if (!(dev = alloc_etherdev (sizeof (struct de4x5_private)))) {
 		error = -ENOMEM;

Re: pci_disable_device kills hardware (was Re: [PATCH] propagate pci_enable_device() errors)

[Greg KH]

On Thu, Aug 26, 2004 at 03:52:51PM -0400, Jeff Garzik wrote:
> thanks much.
> 
> We still need to figure out what to do for multiple-driver situations, 
> since the additional of pci_disable_device() calls literally 
> _guarantees_ failures in a two-drivers-for-the-same-hardware situation.

the "two-drivers-for-the-same-hardware" is what needs to be fixed.
You are on your own if you do that.

good luck,

greg k-h

Re: pci_disable_device kills hardware (was Re: [PATCH] propagate pci_enable_device() errors)

[Jeff Garzik]

Greg KH wrote:
> On Thu, Aug 26, 2004 at 03:52:51PM -0400, Jeff Garzik wrote:
> 
>>thanks much.
>>
>>We still need to figure out what to do for multiple-driver situations, 
>>since the additional of pci_disable_device() calls literally 
>>_guarantees_ failures in a two-drivers-for-the-same-hardware situation.
> 
> 
> the "two-drivers-for-the-same-hardware" is what needs to be fixed.
> You are on your own if you do that.


Sure, but that's handwaving away reality...  It stands to reason that we 
would all _prefer_ one driver for each piece of hardware.

	Jeff

Re: pci_disable_device kills hardware (was Re: [PATCH] propagate pci_enable_device() errors)

[Greg KH]

On Thu, Aug 26, 2004 at 07:14:11PM -0400, Jeff Garzik wrote:
> Greg KH wrote:
> >On Thu, Aug 26, 2004 at 03:52:51PM -0400, Jeff Garzik wrote:
> >
> >>thanks much.
> >>
> >>We still need to figure out what to do for multiple-driver situations, 
> >>since the additional of pci_disable_device() calls literally 
> >>_guarantees_ failures in a two-drivers-for-the-same-hardware situation.
> >
> >
> >the "two-drivers-for-the-same-hardware" is what needs to be fixed.
> >You are on your own if you do that.
> 
> 
> Sure, but that's handwaving away reality...  It stands to reason that we 
> would all _prefer_ one driver for each piece of hardware.

That's what the pci driver model forces you to do.  If you go around
behind the back of it, you get what you deserve :)

For stuff like this, the IDE drivers need to be changed to use the (what
is it, 4 years old now?) pci driver model.  There's no reason technical
why such a conversion hasn't happened yet, right?

thanks,

greg k-h