forked from Minki/linux
[PARISC] fix compile break caused by iomap: make IOPORT/PCI mapping functions conditional
The problem in
commit fea80311a9
Author: Randy Dunlap <rdunlap@xenotime.net>
Date: Sun Jul 24 11:39:14 2011 -0700
iomap: make IOPORT/PCI mapping functions conditional
is that if your architecture supplies pci_iomap/pci_iounmap, it expects
always to supply them. Adding empty body defitions in the !CONFIG_PCI
case, which is what this patch does, breaks the parisc compile because
the functions become doubly defined. It took us a while to spot this,
because we don't actually build !CONFIG_PCI very often (only if someone
is brave enough to test the snake/asp machines).
Since the note in the commit log says this is to fix a
CONFIG_GENERIC_IOMAP issue (which it does because CONFIG_GENERIC_IOMAP
supplies pci_iounmap only if CONFIG_PCI is set), there should actually
have been a condition upon this. This should make sure no other
architecture's !CONFIG_PCI compile breaks in the same way as parisc.
The fix had to be updated to take account of the GENERIC_PCI_IOMAP
separation.
Reported-by: Rolf Eike Beer <eike@sf-mail.de>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
This commit is contained in:
parent
500dd2370e
commit
97a29d59fc
@ -70,7 +70,7 @@ extern void ioport_unmap(void __iomem *);
|
||||
/* Destroy a virtual mapping cookie for a PCI BAR (memory or IO) */
|
||||
struct pci_dev;
|
||||
extern void pci_iounmap(struct pci_dev *dev, void __iomem *);
|
||||
#else
|
||||
#elif defined(CONFIG_GENERIC_IOMAP)
|
||||
struct pci_dev;
|
||||
static inline void pci_iounmap(struct pci_dev *dev, void __iomem *addr)
|
||||
{ }
|
||||
|
@ -25,7 +25,7 @@ extern void __iomem *__pci_ioport_map(struct pci_dev *dev, unsigned long port,
|
||||
#define __pci_ioport_map(dev, port, nr) ioport_map((port), (nr))
|
||||
#endif
|
||||
|
||||
#else
|
||||
#elif defined(CONFIG_GENERIC_PCI_IOMAP)
|
||||
static inline void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long max)
|
||||
{
|
||||
return NULL;
|
||||
|
Loading…
Reference in New Issue
Block a user