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
| ||
|
Date: Mon, 7 Apr 2014 09:35:50 +0100 From: Liviu Dudau <Liviu.Dudau@....com> To: Benjamin Herrenschmidt <benh@...nel.crashing.org> Cc: Bjorn Helgaas <bhelgaas@...gle.com>, linux-pci <linux-pci@...r.kernel.org>, Catalin Marinas <Catalin.Marinas@....com>, Will Deacon <Will.Deacon@....com>, linaro-kernel <linaro-kernel@...ts.linaro.org>, Arnd Bergmann <arnd@...db.de>, LKML <linux-kernel@...r.kernel.org>, "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>, LAKML <linux-arm-kernel@...ts.infradead.org>, Tanmay Inamdar <tinamdar@....com>, Grant Likely <grant.likely@...retlab.ca> Subject: Re: [PATCH v7 1/6] pci: Introduce pci_register_io_range() helper function. On Sun, Apr 06, 2014 at 10:49:53AM +0100, Benjamin Herrenschmidt wrote: > On Fri, 2014-04-04 at 18:19 -0600, Bjorn Helgaas wrote: > > > Introduce a pci_register_io_range() helper function that can be used > > > by the architecture code to keep track of the I/O ranges described by the > > > PCI bindings. If the PCI_IOBASE macro is not defined that signals > > > lack of support for PCI and we return an error. > > > > I don't quite see how you intend to use this, because this series doesn't > > include any non-stub implementation of pci_register_io_range(). > > > > Is this anything like the ia64 strategy I mentioned above? If so, it would > > be really nice to unify some of this stuff. > > We also use two different strategies on ppc32 and ppc64 > > - On ppc32, inb/outb turn into an MMIO access to _IO_BASE + port > > That _IO_BASE is a variable which is initialized to the ioremapped address > of the IO space MMIO aperture of the first bridge we discover. Then port > numbers are "fixed up" on all other bridges so that the addition _IO_BASE + port > fits the ioremapped address of the IO space on that bridge. A bit messy... and breaks > whenever drivers copy port numbers into variables of the wrong type such as shorts. > > - On ppc64, we have more virtual space, so instead we reserve a range > of address space (fixed) for IO space, it's always the same. Bridges IO spaces > are then mapped into that range, so we always have a positive offset from _IO_BASE > which makes things a bit more robust and less "surprising" than ppc32. Additionally, > the first 64k are reserved. They are only mapped if we see an ISA bridge (which some > older machines have). Otherwise it's left unmapped, so crappy drivers trying to > hard code x86 IO ports will blow up immediately which I deem better than silently > whacking the wrong hardware. In addition, we have a mechanism we use on powernv to > re-route accesses to that first 64k to the power8 built-in LPC bus which can > have some legacy IOs on it such as a UART or a RTC. > > Cheers, > Ben. > Hi Benjamin, Thanks for the summary, is really useful as I was recently looking into code in that area. One thing I was trying to understand is why ppc needs _IO_BASE at all rather than using the generic PCI_IOBASE? Best regards, Liviu -- ==================== | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --------------- ¯\_(ツ)_/¯ -- 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