[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20070802.150636.77057800.davem@davemloft.net>
Date: Thu, 02 Aug 2007 15:06:36 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: mchan@...adcom.com
Cc: joachim.deguara@....com, akpm@...ux-foundation.org,
linux-kernel@...r.kernel.org, michal.k.k.piotrowski@...il.com,
netdev@...r.kernel.org, linux-acpi@...r.kernel.org
Subject: Re: [REGRESSION] tg3 dead after s2ram
From: "Michael Chan" <mchan@...adcom.com>
Date: Thu, 02 Aug 2007 12:10:29 -0700
> On Thu, 2007-08-02 at 02:23 -0700, David Miller wrote:
> > From: "Joachim Deguara" <joachim.deguara@....com>
> > Date: Thu, 2 Aug 2007 11:15:05 +0200
> >
> > > Seams like even if powersave shuts down the network that the device should
> > > still work after a suspend to ram, so who is at fault here?
> >
> > It's a good question.
> >
> > The pci_enable() is done on the PCI device at probe time, at least in
> > the tg3 driver, and with such a model restoring and saving of PCI
> > config space should not be dependant upon whether the netdev is
> > running or not.
> >
>
> Alternatively, we can also fix it by calling pci_enable_device() again
> in tg3_open(). But I think it is better to just always save and restore
> in suspend/resume. bnx2.c will also require the same fix.
We could do it that way. But don't you think it's more reliable to
save and restore around the event we know will be what clobbers the
PCI config space on us? :-)
Other things might happen between ->resume() and ->open() that could
modify PCI config space, and we could overwrite such changes if we do
the PCI restore in ->open().
One thing that's interesting to me is that, essentially, every PCI
driver with very few if any exceptions needs to do this sequence on
suspend and resume. It would be nice if there was a way to get this
to happen transparently by default, with some reasonable override
mechanism, for PCI device drivers.
Anyways, once your patch is tested feel free to send me the bnx2
one too.
Thanks!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists