linux-kernel - Re: [RFC v1 01/16] lib: devres: don't enclose pcim_*() functions in CONFIG_HAS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20121211175113.GX14363@n2100.arm.linux.org.uk>
Date:	Tue, 11 Dec 2012 17:51:13 +0000
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Arnd Bergmann <arnd@...db.de>,
	linux-arm-kernel@...ts.infradead.org,
	Thomas Petazzoni <thomas.petazzoni@...e-electrons.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>,
	Lior Amsalem <alior@...vell.com>,
	Shadi Ammouri <shadi@...vell.com>,
	Gregory Clement <gregory.clement@...e-electrons.com>,
	Yinghai Lu <yinghai@...nel.org>
Subject: Re: [RFC v1 01/16] lib: devres: don't enclose pcim_*() functions
	in CONFIG_HAS_IOPORT

On Tue, Dec 11, 2012 at 05:45:09PM +0000, Alan Cox wrote:
> > The problem comes when you end up trying to deal with stuff which
> > uses ioread{8,16} on ioport_map() cookies where it's assumed that
> > adding N to the cookie is the same as adding N to the port address.
> 
> It's a cookie - this isn't a problem, you can support it via the mapping
> approah. Whether you want to is another question.

We're drifting off the topic of whether these things should be provided
and whether the config symbols should be selected...

For a kernel configuration which includes platforms where there is are no
ISA peripherals, no PCI bridge present, and no PCMCIA support, there's
little point to having IO space support present.

However, the platform should still work correctly if IO space support is
configured into the kernel (in other words, it shouldn't cause a failure)
so that such a platform can co-operate with those platforms which do
require IO space support.

Now, there was an idea a while back about having a common virtual address
space to map PCI/ISA IO space to - which we have in the kernel - 1MB at
0xfee00000.

If PCI is disabled, the ends up being a 1:1 conversion between IO offset
and CPU virtual address - that's partly there because no one's fixed up
the soc-common PCMCIA stuff to dea with the PCMCIA socket IO spaces
there.  We really need to be fixing some of this stuff...

(Unfortunately, my SA11x0 platform with the dual PCMCIA/CF sockets is now
my firewall so its out of the question to mess around with it on an ad-hoc
basis.)
--
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/