From: Valerie Henson <val_henson@linux.intel.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Jeff Garzik <jeff@garzik.org>
Subject: Re: [patch 08/10] [TULIP] Handle pci_enable_device() errors in resume
Date: Sat, 26 Aug 2006 21:15:04 -0700 [thread overview]
Message-ID: <20060827041504.GE25003@goober> (raw)
In-Reply-To: <1156610518.3007.287.camel@localhost.localdomain>
On Sat, Aug 26, 2006 at 05:41:58PM +0100, Alan Cox wrote:
> Ar Gwe, 2006-08-25 am 17:02 -0700, ysgrifennodd Valerie Henson:
> > pci_set_power_state(pdev, PCI_D0);
> > pci_restore_state(pdev);
> >
> > - pci_enable_device(pdev);
> > + if ((retval = pci_enable_device(pdev))) {
> > + printk (KERN_ERR "tulip: pci_enable_device failed in resume\n");
> > + return retval;
> > + }
> Should you not stick it back in D3 if you are being neat about this ?
I don't know. Any thoughts from the peanut gallery? I've spent some
time trolling both docs and other drivers, but I haven't yet found an
example of a driver that correctly handles all the resume error cases.
Also, at least one other driver does a pci_disable_device() if the
request_irq() fails - should tulip do this too?
> NAK: What about rtnl_lock()
Gah. Thanks, how about the patch below instead?
-VAL
Subject: [TULIP] Handle pci_enable_device() errors in resume
Signed-off-by: Valerie Henson <val_henson@linux.intel.com>
Cc: Jeff Garzik <jeff@garzik.org>
---
drivers/net/tulip/de2104x.c | 16 ++++++++++------
drivers/net/tulip/tulip_core.c | 5 ++++-
drivers/net/tulip/winbond-840.c | 12 ++++++++----
3 files changed, 22 insertions(+), 11 deletions(-)
--- linux-2.6.18-rc4-mm1-tulip.orig/drivers/net/tulip/tulip_core.c
+++ linux-2.6.18-rc4-mm1-tulip/drivers/net/tulip/tulip_core.c
@@ -1780,7 +1780,10 @@ static int tulip_resume(struct pci_dev *
pci_set_power_state(pdev, PCI_D0);
pci_restore_state(pdev);
- pci_enable_device(pdev);
+ if ((retval = pci_enable_device(pdev))) {
+ printk (KERN_ERR "tulip: pci_enable_device failed in resume\n");
+ return retval;
+ }
if ((retval = request_irq(dev->irq, &tulip_interrupt, IRQF_SHARED, dev->name, dev))) {
printk (KERN_ERR "tulip: request_irq failed in resume\n");
--- linux-2.6.18-rc4-mm1-tulip.orig/drivers/net/tulip/winbond-840.c
+++ linux-2.6.18-rc4-mm1-tulip/drivers/net/tulip/winbond-840.c
@@ -1626,14 +1626,18 @@ static int w840_resume (struct pci_dev *
{
struct net_device *dev = pci_get_drvdata (pdev);
struct netdev_private *np = netdev_priv(dev);
+ int retval = 0;
rtnl_lock();
if (netif_device_present(dev))
goto out; /* device not suspended */
if (netif_running(dev)) {
- pci_enable_device(pdev);
- /* pci_power_on(pdev); */
-
+ if ((retval = pci_enable_device(pdev))) {
+ printk (KERN_ERR
+ "%s: pci_enable_device failed in resume\n",
+ dev->name);
+ goto out;
+ }
spin_lock_irq(&np->lock);
iowrite32(1, np->base_addr+PCIBusCfg);
ioread32(np->base_addr+PCIBusCfg);
@@ -1651,7 +1655,7 @@ static int w840_resume (struct pci_dev *
}
out:
rtnl_unlock();
- return 0;
+ return retval;
}
#endif
--- linux-2.6.18-rc4-mm1-tulip.orig/drivers/net/tulip/de2104x.c
+++ linux-2.6.18-rc4-mm1-tulip/drivers/net/tulip/de2104x.c
@@ -2138,17 +2138,21 @@ static int de_resume (struct pci_dev *pd
{
struct net_device *dev = pci_get_drvdata (pdev);
struct de_private *de = dev->priv;
+ int retval = 0;
rtnl_lock();
if (netif_device_present(dev))
goto out;
- if (netif_running(dev)) {
- pci_enable_device(pdev);
- de_init_hw(de);
- netif_device_attach(dev);
- } else {
- netif_device_attach(dev);
+ if (!netif_running(dev))
+ goto out_attach;
+ if ((retval = pci_enable_device(pdev))) {
+ printk (KERN_ERR "%s: pci_enable_device failed in resume\n",
+ dev->name);
+ goto out;
}
+ de_init_hw(de);
+out_attach:
+ netif_device_attach(dev);
out:
rtnl_unlock();
return 0;
next prev parent reply other threads:[~2006-08-27 4:15 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-26 0:02 [patch 00/10] [TULIP] Tulip update Valerie Henson
2006-08-26 0:02 ` [patch 01/10] [TULIP] Change tulip maintainer Valerie Henson
2006-08-26 0:02 ` [patch 02/10] [TULIP] Print physical address in tulip_init_one Valerie Henson
2006-08-26 0:02 ` [patch 03/10] [TULIP] Make DS21143 printout match lspci output Valerie Henson
2006-08-26 0:02 ` [patch 04/10] [TULIP] Flush MMIO writes in reset sequence Valerie Henson
2006-08-26 0:02 ` [patch 05/10] [TULIP] Defer tulip_select_media() to process context Valerie Henson
2006-08-26 16:44 ` Alan Cox
2006-08-26 0:02 ` [patch 06/10] [TULIP] Clean up tulip.h Valerie Henson
2006-08-26 0:02 ` [patch 07/10] [TULIP] Use tulip.h in winbond-840.c Valerie Henson
2006-08-29 20:46 ` Jeff Garzik
2006-08-26 0:02 ` [patch 08/10] [TULIP] Handle pci_enable_device() errors in resume Valerie Henson
2006-08-26 16:41 ` Alan Cox
2006-08-27 4:15 ` Valerie Henson [this message]
2006-08-29 20:46 ` Jeff Garzik
2006-08-26 0:02 ` [patch 09/10] [TULIP] Update tulip version Valerie Henson
2006-08-26 0:02 ` [patch 10/10] [TULIP] Update winbond840.c version Valerie Henson
2006-08-29 20:46 ` Jeff Garzik
-- strict thread matches above, loose matches on Subject: below --
2006-09-08 18:15 [patch 00/10] [TULIP] Tulip update Valerie Henson
2006-09-08 18:15 ` [patch 08/10] [TULIP] Handle pci_enable_device() errors in resume Valerie Henson
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=20060827041504.GE25003@goober \
--to=val_henson@linux.intel.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=jeff@garzik.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
/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.