[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201212112220.04597.arnd@arndb.de>
Date: Tue, 11 Dec 2012 22:20:03 +0000
From: Arnd Bergmann <arnd@...db.de>
To: Alan Cox <alan@...rguk.ukuu.org.uk>
Cc: Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>,
"Russell King - ARM Linux" <linux@....linux.org.uk>,
Lior Amsalem <alior@...vell.com>, Andrew Lunn <andrew@...n.ch>,
Yehuda Yitschak <yehuday@...vell.com>,
Maen Suleiman <maen@...vell.com>,
Jason Cooper <jason@...edaemon.net>,
Tawfik Bayouk <tawfik@...vell.com>,
Stephen Warren <swarren@...dotorg.org>,
Thierry Reding <thierry.reding@...onic-design.de>,
linux-kernel@...r.kernel.org,
Jesse Barnes <jbarnes@...tuousgeek.org>,
"Eran Ben-Avi" <benavi@...vell.com>,
Nadav Haklai <nadavh@...vell.com>,
Paul Gortmaker <paul.gortmaker@...driver.com>,
Shadi Ammouri <shadi@...vell.com>,
Gregory Clement <gregory.clement@...e-electrons.com>,
Yinghai Lu <yinghai@...nel.org>,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [RFC v1 01/16] lib: devres: don't enclose pcim_*() functions in CONFIG_HAS_IOPORT
On Tuesday 11 December 2012, Alan Cox wrote:
> The "no I/O space" case really applies to things like the S/390 mainframe
> which simply have no such concept on the system or the devices. In the
> ARM case the bus has an I/O space and the bridge glues the processors
> simpler model to the bridge model.
While we are getting slightly offtopic, s390 is actually gaining PCI support
now: https://patchwork.kernel.org/patch/1740231/ For all I can tell, they
would theoretically support an I/O space, but none of the supported
add-on cards use it, so the kernel implementation doesn't need to bother.
One architecture that never has an I/O space is the arch/um, but that is
special in a lot of ways, e.g. since it also never has MMIO.
On ARM, we have platforms that fall into four categories:
1. Full PCI or PCMCIA or ISA support with directly mapped I/O space
2. No PCI or PCMCIA or ISA support, and consequently no I/O space
3. PCI support but no I/O space because of limitations or bugs in
the PCI hardware implementation.
4. ISA-style I/O space that is not offsettable (CONFIG_NO_IOPORT)
but still has inb/outb accessors.
For cases 2 and 3, we can undefine the __io() macro, which leads to
intentional build errors someone tries to build code that uses the
inb/outb accessors. One missing piece that I have been working on
in the past and been meaning to pick up again is a patch set to
globally rename CONFIG_NO_IOPORT to the more appropriate
CONFIG_NO_IOPORT_MAP, and introduce a new CONFIG_NO_IOPORT that
signifies whether inb/outb are supported or not, rather than whether
you can access the I/O ports through ioport_map() and ioread/iowrite.
Arnd
--
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