[PATCH repost] pci: fix compilation when CONFIG_PCI_MSI=n

[PATCH repost] pci: fix compilation when CONFIG_PCI_MSI=n

[Michael S. Tsirkin]

vers/pci/pci.c:2277: error: redefinition of ‘pci_msi_off’
include/linux/pci.h:786: note: previous definition of ‘pci_msi_off’ was here

No need for ifdef: we must disable the capability at startup even if the
current kernel does not support MSI, otherwise the device won't work.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---

Looks like I didn't tag this old patch of mine clearly enough
so it's still not fixed in -rc5.
It's late in the cycle, but the patch is trivial
and it's a build fix, so ... please consider for 2.6.35.

 include/linux/pci.h |    4 ----
 1 files changed, 0 insertions(+), 4 deletions(-)

diff --git a/include/linux/pci.h b/include/linux/pci.h
index 31d8a12..7cb0084 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -780,11 +780,7 @@ int __must_check pci_set_mwi(struct pci_dev *dev);
 int pci_try_set_mwi(struct pci_dev *dev);
 void pci_clear_mwi(struct pci_dev *dev);
 void pci_intx(struct pci_dev *dev, int enable);
-#ifdef CONFIG_PCI_MSI
 void pci_msi_off(struct pci_dev *dev);
-#else
-static inline void pci_msi_off(struct pci_dev *dev) {}
-#endif
 int pci_set_dma_max_seg_size(struct pci_dev *dev, unsigned int size);
 int pci_set_dma_seg_boundary(struct pci_dev *dev, unsigned long mask);
 int pcix_get_max_mmrbc(struct pci_dev *dev);
-- 
1.7.2.rc0.14.g41c1c

Re: [PATCH repost] pci: fix compilation when CONFIG_PCI_MSI=n

[Jesse Barnes]

On Fri, 16 Jul 2010 17:20:50 +0300
"Michael S. Tsirkin" <mst@redhat.com> wrote:

> vers/pci/pci.c:2277: error: redefinition of ‘pci_msi_off’
> include/linux/pci.h:786: note: previous definition of ‘pci_msi_off’ was here
> 
> No need for ifdef: we must disable the capability at startup even if the
> current kernel does not support MSI, otherwise the device won't work.
> 
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> 
> Looks like I didn't tag this old patch of mine clearly enough
> so it's still not fixed in -rc5.
> It's late in the cycle, but the patch is trivial
> and it's a build fix, so ... please consider for 2.6.35.

I thought this was supposed to go via the virtualization tree...  But I
can pick it up and try to send to Linus.

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [PATCH repost] pci: fix compilation when CONFIG_PCI_MSI=n

[Jesse Barnes]

On Fri, 16 Jul 2010 17:20:50 +0300
"Michael S. Tsirkin" <mst@redhat.com> wrote:

> vers/pci/pci.c:2277: error: redefinition of ‘pci_msi_off’
> include/linux/pci.h:786: note: previous definition of ‘pci_msi_off’ was here
> 
> No need for ifdef: we must disable the capability at startup even if the
> current kernel does not support MSI, otherwise the device won't work.
> 
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> 
> Looks like I didn't tag this old patch of mine clearly enough
> so it's still not fixed in -rc5.
> It's late in the cycle, but the patch is trivial
> and it's a build fix, so ... please consider for 2.6.35.

I don't see the same context in the current tree.  So this patch must
be against the virtualization tree I guess?

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [PATCH repost] pci: fix compilation when CONFIG_PCI_MSI=n

[Michael S. Tsirkin]

On Fri, Jul 16, 2010 at 12:06:03PM -0700, Jesse Barnes wrote:
> On Fri, 16 Jul 2010 17:20:50 +0300
> "Michael S. Tsirkin" <mst@redhat.com> wrote:
> 
> > vers/pci/pci.c:2277: error: redefinition of ‘pci_msi_off’
> > include/linux/pci.h:786: note: previous definition of ‘pci_msi_off’ was here
> > 
> > No need for ifdef: we must disable the capability at startup even if the
> > current kernel does not support MSI, otherwise the device won't work.
> > 
> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > ---
> > 
> > Looks like I didn't tag this old patch of mine clearly enough
> > so it's still not fixed in -rc5.
> > It's late in the cycle, but the patch is trivial
> > and it's a build fix, so ... please consider for 2.6.35.
> 
> I don't see the same context in the current tree.  So this patch must
> be against the virtualization tree I guess?

Yes, looks like it got fixed in the virtualization tree.
Thanks,
MST