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, 9 Apr 2012 17:38:15 -0400 From: Chris Metcalf <cmetcalf@...era.com> To: Arnd Bergmann <arnd@...db.de> CC: <linux-kernel@...r.kernel.org>, <linux-pci@...r.kernel.org>, Bjorn Helgaas <bhelgaas@...gle.com>, Jesse Barnes <jbarnes@...tuousgeek.org>, "Michael S. Tsirkin" <mst@...hat.com>, Myron Stowe <myron.stowe@...hat.com>, Jiri Kosina <jkosina@...e.cz>, Joe Perches <joe@...ches.com>, David Howells <dhowells@...hat.com> Subject: Re: [PATCH 3/3] arch/tile: tilegx PCI root complex support On 4/9/2012 9:59 AM, Arnd Bergmann wrote: > On Saturday 07 April 2012, Chris Metcalf wrote: >> This change implements PCIe root complex support for tilegx using >> the kernel support layer for accessing the TRIO hardware shim. >> >> Signed-off-by: Chris Metcalf <cmetcalf@...era.com> > Hi Chris, > > I don't know if we discussed it during the initial merge, but I notice that the PIO > accessors (inb/outb and friends) are still not implemented in this patch. Normally > PIO can just be mapped into the MMIO address space, so that inb() becomes > a call to readb() with an offset on the address. I asked our PCI expert here, who said, "My understanding is that if someone wants to use inb/outb to access MMIO space, he'll get the MMIO, as opposed to methods implemented with I/O instructions which are not supported by TILE. If the driver is dependent on the I/O instructions, it won't work on TILE. These drivers are legacy PC drivers, e.g. ATA devices, which are not supported by TILE." Should we just arrange to #include <asm-generic/io.h> to pick up inb/outb et al? Any reason to think a non-zero offset should be part of the solution? (I don't really understand how inb/outb are used by modern drivers.) > Using mdelay is generally considered very rude. Since you are not in > atomic context here, just use msleep() instead. Done. Thanks for all your reviews! -- Chris Metcalf, Tilera Corp. http://www.tilera.com -- 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