public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Adam Belay <ambx1@neo.rr.com>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Karsten Keil <kkeil@suse.de>, Andrew Morton <akpm@osdl.org>,
	Jeff Garzik <jgarzik@pobox.com>,
	Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] fix tulip suspend/resume
Date: Mon, 6 Jun 2005 22:50:55 -0400	[thread overview]
Message-ID: <20050607025054.GC3289@neo.rr.com> (raw)
In-Reply-To: <Pine.LNX.4.58.0506061702430.1876@ppc970.osdl.org>

On Mon, Jun 06, 2005 at 05:04:07PM -0700, Linus Torvalds wrote:
> 
> Jeff, 
>  this looks ok, but I'll leave the decision to you. Things like this often 
> break.
> 
> Andrew, maybe at least a few days in -mm to see if there's some outcry?
> 
> 		Linus

This patch is an improvement, but there may still be some issues.
Specifically, it looks to me like the the interrupt handler remains
registered.  This could cause some problems when another device is sharing
the interrupt because the tulip driver must read from a hardware register
to determine if it triggered the interrupt. When the hardware has been
physically powered off, things might not go well.

I can't comment on the netdev class aspect of this routine, but following
a similar strategy to its original author, a fix might look like this:

--- a/drivers/net/tulip/tulip_core.c	2005-05-27 22:06:00.000000000 -0400
+++ b/drivers/net/tulip/tulip_core.c	2005-06-06 22:14:25.850846400 -0400
@@ -1759,7 +1759,12 @@
 	if (dev && netif_running (dev) && netif_device_present (dev)) {
 		netif_device_detach (dev);
 		tulip_down (dev);
-		/* pci_power_off(pdev, -1); */
+
+		pci_save_state(pdev);
+
+		free_irq(dev->irq, dev);
+		pci_disable_device(pdev);
+		pci_set_power_state(pdev, pci_choose_state(pdev, state));
 	}
 	return 0;
 }
@@ -1768,12 +1773,19 @@
 static int tulip_resume(struct pci_dev *pdev)
 {
 	struct net_device *dev = pci_get_drvdata(pdev);
+	int retval;
 
 	if (dev && netif_running (dev) && !netif_device_present (dev)) {
-#if 1
-		pci_enable_device (pdev);
-#endif
-		/* pci_power_on(pdev); */
+		pci_set_power_state(pdev, PCI_D0);
+		pci_restore_state(pdev);
+
+		pci_enable_device(pdev);
+
+		if ((retval = request_irq(dev->irq, &tulip_interrupt, SA_SHIRQ, dev->name, dev))) {
+			printk (KERN_ERR "tulip: request_irq failed in resume\n");
+			return retval;
+		}
+		
 		tulip_up (dev);
 		netif_device_attach (dev);
 	}

I don't have this hardware, so any testing would be appreciated.

Thanks,
Adam


P.S.: I noticed this function in the tulip driver:

static void tulip_set_power_state (struct tulip_private *tp,
				   int sleep, int snooze)
{
	if (tp->flags & HAS_ACPI) {
		u32 tmp, newtmp;
		pci_read_config_dword (tp->pdev, CFDD, &tmp);
		newtmp = tmp & ~(CFDD_Sleep | CFDD_Snooze);
		if (sleep)
			newtmp |= CFDD_Sleep;
		else if (snooze)
			newtmp |= CFDD_Snooze;
		if (tmp != newtmp)
			pci_write_config_dword (tp->pdev, CFDD, newtmp);
	}

}

Currently we aren't using CFDD_Sleep.  Should we call this in suspend?  It
could be important if the hardware doesn't support PCI PM.  I don't really
have any specifications or information about the hardware, so I'm at a loss
here.

  reply	other threads:[~2005-06-07  2:54 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-06 22:46 [PATCH] fix tulip suspend/resume Karsten Keil
2005-06-07  0:04 ` Linus Torvalds
2005-06-07  2:50   ` Adam Belay [this message]
2005-06-07  3:34     ` Benjamin Herrenschmidt
2005-06-07  3:58       ` Adam Belay
2005-06-07  4:26         ` Benjamin Herrenschmidt
2005-06-07  5:34           ` Adam Belay
2005-06-07  5:50             ` Benjamin Herrenschmidt
2005-06-07 10:55     ` Karsten Keil
2005-06-07 20:58       ` Adam Belay
2005-06-08  0:26         ` Benjamin Herrenschmidt
2005-06-08  2:16           ` Adam Belay
2005-06-08 12:23             ` Pavel Machek
2005-06-08 23:00               ` Benjamin Herrenschmidt
2005-06-09  0:04                 ` Pavel Machek
2005-06-09  0:38                   ` Adam Belay
2005-06-09 10:51                     ` Pavel Machek
2005-06-09  2:49                   ` Nigel Cunningham
2005-06-09  8:27                   ` Karsten Keil
2005-06-08 12:19           ` Pavel Machek
2005-06-08  6:39         ` Karsten Keil
2005-06-08 18:11           ` Davide Rossetti
2005-06-09  1:48             ` Adam Belay
2005-06-07 11:52   ` Stefan Seyfried
2005-06-07  2:15 ` Benjamin Herrenschmidt
2005-06-07  2:57   ` Adam Belay
2005-06-07  3:32     ` Benjamin Herrenschmidt
2005-06-07  3:42       ` Adam Belay
2005-06-07  4:29         ` Benjamin Herrenschmidt
2005-06-07  5:03           ` Adam Belay
2005-06-07  5:51             ` Nigel Cunningham
2005-06-07  5:55               ` Benjamin Herrenschmidt
2005-06-07 15:10   ` Pavel Machek

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=20050607025054.GC3289@neo.rr.com \
    --to=ambx1@neo.rr.com \
    --cc=akpm@osdl.org \
    --cc=jgarzik@pobox.com \
    --cc=kkeil@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@osdl.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox