I notice that io.h on alpha pulls in asm-generic/iomap.h.
This header includes these bits:
#ifdef CONFIG_PCI
/* Create a virtual mapping cookie for a PCI BAR (memory or IO) */
struct pci_dev;
extern void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned
ong max);
extern void pci_iounmap(struct pci_dev *dev, void __iomem *);
#else
struct pci_dev;
static inline void __iomem *pci_iomap(struct pci_dev *dev, int bar,
nsigned long max)
{
return NULL;
}
static inline void pci_iounmap(struct pci_dev *dev, void __iomem *addr)
{ }
#endif
#endif
Thus if PCI is not selected we get pci_iomap and pci_iounmap
stubbed out with inline functions. However, on the Jenkins architecture,
arch/alpha/kernel/pci-noop.c is compiled, which includes
offline versions of same stubs. Since Jenkins disables PCI,
I wonder how does this compile - won't the two definitions
conflict?
It's possible that the ones in arch/alpha/kernel/pci-noop.c
can just be removed, and that the conflict is avoided by luck
and the offline functions are never used.
If true, would the following (untested) patch be the right thing to do?
Feedback from someone who has the tools to build the Jenkins
config would also be appreciated.
Thanks!
-->
alpha: drop pci_iomap/pci_iounmap from pci-noop.c
Jenkins disables PCI so asm-generic provides inline
stubs for these, we don't need offline stubs as well.
Signed-off-by: Michael S. Tsirkin <mst@xxxxxxxxxx>
---
diff --git a/arch/alpha/kernel/pci-noop.c b/arch/alpha/kernel/pci-noop.c
index 246100e..04eea48 100644
--- a/arch/alpha/kernel/pci-noop.c
+++ b/arch/alpha/kernel/pci-noop.c
@@ -185,15 +185,3 @@ struct dma_map_ops alpha_noop_ops = {
struct dma_map_ops *dma_ops = &alpha_noop_ops;
EXPORT_SYMBOL(dma_ops);
-
-void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long maxlen)
-{
- return NULL;
-}
-
-void pci_iounmap(struct pci_dev *dev, void __iomem * addr)
-{
-}
-
-EXPORT_SYMBOL(pci_iomap);
-EXPORT_SYMBOL(pci_iounmap);
--
MST
--
To unsubscribe from this list: send the line "unsubscribe linux-alpha" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
