[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1193088267.6745.108.camel@pasglop>
Date: Tue, 23 Oct 2007 07:24:27 +1000
From: Benjamin Herrenschmidt <benh@...nel.crashing.org>
To: Linas Vepstas <linas@...tin.ibm.com>
Cc: Michael Ellerman <michael@...erman.id.au>, netdev@...r.kernel.org,
mcarlson@...adcom.com, linuxppc-dev list <linuxppc-dev@...abs.org>,
mchan@...adcom.com, linux-pci@...ey.karlin.mff.cuni.cz,
David Miller <davem@...emloft.net>
Subject: Re: [PATCH 5/7] pci: Export the pci_restore_msi_state() function
On Mon, 2007-10-22 at 13:13 -0500, Linas Vepstas wrote:
> On Mon, Oct 22, 2007 at 11:49:24AM +1000, Michael Ellerman wrote:
> >
> > On pseries there's a chance it will work for PCI error recovery, but if
> > so it's just lucky that firmware has left everything configured the same
> > way.
>
> ? The papr is quite clear that i is up to the OS to restore the msi
> state after an eeh error.
Via direct config space access or via firmware change-msi calls ?
> > Yes I think so. That way we can properly reconfigure via the firmware
> > interface. The other option would be to design some new arch hook to do
> > resume, but just doing a disable/enable seems simpler to me.
>
> Err, If you read the code for suspend/resume, it never actually calls
> disable/enable (and thus doesn't go to the firmware); it calls
> restore_msi_state() function!
>
> If suspend/resume needs to call firmware to restore the state, then,
> at the moment, suspend/resume is broken. As I mentioned earlier,
> I presumed that no powerpc laptops currently use msi-enabled devices,
> as otherwise, this would have been flushed out.
I don't know why you keep talking about powerpc laptops here ...
Ben.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists