[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120131002203.GA14344@redhat.com>
Date: Tue, 31 Jan 2012 02:22:05 +0200
From: "Michael S. Tsirkin" <mst@...hat.com>
To: Arnd Bergmann <arnd@...db.de>
Cc: Kevin Cernekee <cernekee@...il.com>,
Ralf Baechle <ralf@...ux-mips.org>,
Paul Mundt <lethal@...ux-sh.org>,
Jesse Barnes <jbarnes@...tuousgeek.org>,
Myron Stowe <myron.stowe@...hat.com>,
Paul Gortmaker <paul.gortmaker@...driver.com>,
Lucas De Marchi <lucas.demarchi@...fusion.mobi>,
Dmitry Kasatkin <dmitry.kasatkin@...el.com>,
James Morris <jmorris@...ei.org>,
"John W. Linville" <linville@...driver.com>,
Michael Witten <mfwitten@...il.com>, linux-mips@...ux-mips.org,
linux-kernel@...r.kernel.org, linux-sh@...r.kernel.org,
linux-arch@...r.kernel.org
Subject: Re: [PATCH 1/3] lib: add NO_GENERIC_PCI_IOPORT_MAP
On Mon, Jan 30, 2012 at 08:04:32PM +0000, Arnd Bergmann wrote:
> On Monday 30 January 2012, Michael S. Tsirkin wrote:
> > >
> > > +/*
> > > + * Create a virtual mapping cookie for a port on a given PCI device.
> > > + * Do not call this directly, it exists to make it easier for architectures
> > > + * to override.
> > > + */
> > > +#ifdef CONFIG_NO_GENERIC_PCI_IOPORT_MAP
> > > +extern void __iomem *__pci_ioport_map(struct pci_dev *dev, unsigned long port,
> > > + unsigned int nr);
> > > +#else
> > > +static inline void __iomem *__pci_ioport_map(struct pci_dev *dev,
> > > + unsigned long port, unsigned int nr)
> > > +{
> > > + return ioport_map(port, nr);
> > > +}
> > > +#endif
> > >
> > > Arnd
> >
> > It would be nicer in that it would
> > make the kernel a bit smaller for generic architectures
> > but this would need to go into a separate header:
> > it depends on io.h and io.h depends on pci_iomap.h.
>
> Adding extra dependencies is not good here, I agree.
> Maybe a better solution is to use a macro instead of an inline
> function then:
>
> #define __pci_ioport_map(dev, port, nr) ioport_map(port, nr)
>
> In general, macros should be avoided, but I think it's the
> best tradeoff in this case.
>
> Arnd
I have an idea: we can make the generic one inline
if we keep it in the .c file. So something like
the below on top of my patch will probably work.
Ack?
diff --git a/include/asm-generic/pci_iomap.h b/include/asm-generic/pci_iomap.h
index 2aff58e..2ec1bdb 100644
--- a/include/asm-generic/pci_iomap.h
+++ b/include/asm-generic/pci_iomap.h
@@ -15,11 +15,6 @@ struct pci_dev;
#ifdef CONFIG_PCI
/* Create a virtual mapping cookie for a PCI BAR (memory or IO) */
extern void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long max);
-/* Create a virtual mapping cookie for a port on a given PCI device.
- * Do not call this directly, it exists to make it easier for architectures
- * to override. */
-extern void __iomem *__pci_ioport_map(struct pci_dev *dev, unsigned long port,
- unsigned int nr);
#else
static inline void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long max)
{
@@ -27,4 +22,12 @@ static inline void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned lon
}
#endif
+#ifdef CONFIG_NO_GENERIC_PCI_IOPORT_MAP
+/* Create a virtual mapping cookie for a port on a given PCI device.
+ * Do not call this directly, it exists to make it easier for architectures
+ * to override. */
+extern void __iomem *__pci_ioport_map(struct pci_dev *dev, unsigned long port,
+ unsigned int nr);
+#endif
+
#endif /* __ASM_GENERIC_IO_H */
diff --git a/lib/pci_iomap.c b/lib/pci_iomap.c
index 1dfda29..8102f28 100644
--- a/lib/pci_iomap.c
+++ b/lib/pci_iomap.c
@@ -12,9 +12,9 @@
#ifndef CONFIG_NO_GENERIC_PCI_IOPORT_MAP
/* Architectures can override ioport mapping while
* still using the rest of the generic infrastructure. */
-void __iomem *__pci_ioport_map(struct pci_dev *dev,
- unsigned long port,
- unsigned int nr)
+static inline void __iomem *__pci_ioport_map(struct pci_dev *dev,
+ unsigned long port,
+ unsigned int nr)
{
return ioport_map(port, nr);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists