[RFC/PATCH 4/16] Abstract MSI suspend
Michael Ellerman
michael at ellerman.id.au
Mon Jan 29 20:47:38 EST 2007
On Mon, 2007-01-29 at 01:45 -0700, Eric W. Biederman wrote:
> Michael Ellerman <michael at ellerman.id.au> writes:
>
> > On Sun, 2007-01-28 at 01:27 -0700, Eric W. Biederman wrote:
> >> Michael Ellerman <michael at ellerman.id.au> writes:
> >>
> >> > Currently pci_disable_device() disables MSI on a device by twiddling
> >> > bits in config space via disable_msi_mode().
> >> >
> >> > On some platforms that may not be appropriate, so abstract the MSI
> >> > suspend logic into pci_disable_device_msi().
> >>
> >> >
> >> > Signed-off-by: Michael Ellerman <michael at ellerman.id.au>
> >> > ---
> >> >
> >> > drivers/pci/msi.c | 11 +++++++++++
> >> > drivers/pci/pci.c | 7 +------
> >> > drivers/pci/pci.h | 2 ++
> >> > 3 files changed, 14 insertions(+), 6 deletions(-)
> >> >
> >> > Index: msi/drivers/pci/msi.c
> >> > ===================================================================
> >> > --- msi.orig/drivers/pci/msi.c
> >> > +++ msi/drivers/pci/msi.c
> >> > @@ -271,6 +271,17 @@ void disable_msi_mode(struct pci_dev *de
> >> > pci_intx(dev, 1); /* enable intx */
> >> > }
> >> >
> >> > +void pci_disable_device_msi(struct pci_dev *dev)
> >> > +{
> >> > + if (dev->msi_enabled)
> >> > + disable_msi_mode(dev, pci_find_capability(dev, PCI_CAP_ID_MSI),
> >> > + PCI_CAP_ID_MSI);
> >> > +
> >> > + if (dev->msix_enabled)
> >> > + disable_msi_mode(dev, pci_find_capability(dev, PCI_CAP_ID_MSI),
> >> > + PCI_CAP_ID_MSIX);
> >>
> >> Just a quick note. This is wrong. It should be PCI_CAP_ID_MSIX.
> >> The code that is being moved is buggy. So the patch itself doesn't
> >> make the situation any worse.
> >
> > Greg, if you want to drop that patch I'll prepare two patches to fix it
> > and then move it. I don't have any hardware to test, although I'm
> > guessing no one does given that it's been broken since its inception.
>
> The mthca IB driver was one of the early adopters of MSI, and it uses
> MSI-X. So it isn't that no one is using MSI-X and the MSI-X code
> paths don't get exercised.
I meant the MSI-X suspend/resume path specifically, I'm guessing most
laptops don't come with IB cards yet ;)
> I expect what is closer to the truth is that the code authors have so
> far simply disabled msi separately instead of assuming pci_disable_device
> will do it magically for them. So it may be the case that we can
> just kill this code path altogether.
I recall reading comments to that effect in one driver, although it
wasn't obvious exactly what the problem was - but it's probably worth
doing a thorough review while the number of MSI/MSI-X drivers is small.
> Possibly we can just reduce it to WARN_ON(dev->msi_enabled || dev->msix_enabled);
>
> I suspect msi_remove_pci_irq_vectors may similarly not actually make a
> difference. I think the function dates from a time when the code
> attempted to cache the irq number so if you removed and re-added a module
> or at least disabled and enabled msi you would get the same linux irq
> number. I remember killing that caching because it made the code
> unmaintainable and wasn't really useful.
That was my suspicion as well, I was hoping someone who knew the code
better than me would pipe up and let me know why it was a special case.
Have the original MSI authors vanished without a trace?
It seems to date from the initial MSI submission, and has only ever been
called from pci_free_resources(). The rest of the pci hotunplug code
paths are not clear to me though, so I don't know whether we can rely on
pci_disable_msi() already being called for us.
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20070129/7b2ab4c1/attachment.pgp>
More information about the Linuxppc-dev
mailing list