[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1193017764.10318.17.camel@concordia>
Date: Mon, 22 Oct 2007 11:49:24 +1000
From: Michael Ellerman <michael@...erman.id.au>
To: David Miller <davem@...emloft.net>
Cc: mcarlson@...adcom.com, netdev@...r.kernel.org,
linux-pci@...ey.karlin.mff.cuni.cz, linas@...tin.ibm.com,
mchan@...adcom.com, linuxppc-dev list <linuxppc-dev@...abs.org>
Subject: Re: [PATCH 5/7] pci: Export the pci_restore_msi_state() function
On Sun, 2007-10-21 at 16:21 -0700, David Miller wrote:
> From: "Matt Carlson" <mcarlson@...adcom.com>
> Date: Fri, 19 Oct 2007 14:36:56 -0700
>
> > This patch exports the pci_restore_msi_state() function. This function
> > is needed to restore the MSI state during PCI error recovery.
> >
> > Signed-off-by: Linas Vepstas <linas@...tin.ibm.com>
> > Signed-off-by: Matt Carlson <mcarlson@...adcom.com>
> > Signed-off-by: Michael Chan <mchan@...adcom.com>
>
> I'm not so sure about this.
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. For actual suspend/resume it will never work, we need to ask
firmware to configure things.
> Perhaps, instead, you should do a pci_msi_disable() and
> pci_msi_enable() in the error detection and recovery sequence.
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.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
Download attachment "signature.asc" of type "application/pgp-signature" (190 bytes)
Powered by blists - more mailing lists