user/sven/linux.git/lib/iomap.c, branch v3.14.76

lib: reduce the use of module.h wherever possible

2012-03-07T20:04:04Z

For files only using THIS_MODULE and/or EXPORT_SYMBOL, map them onto including export.h -- or if the file isn't even using those, then just delete the include. Fix up any implicit include dependencies that were being masked by module.h along the way. Signed-off-by: Paul Gortmaker

lib: add GENERIC_PCI_IOMAP

2011-11-28T19:12:42Z

Many architectures want a generic pci_iomap but not the rest of iomap.c. Split that to a separate .c file and add a new config symbol. select automatically by GENERIC_IOMAP. Signed-off-by: Michael S. Tsirkin

iomap: make IOPORT/PCI mapping functions conditional

2011-07-22T16:46:26Z

Use the CONFIG_HAS_IOPORT and CONFIG_PCI options to decide whether or not functions for mapping these areas are provided. Signed-off-by: Jonas Bonn Acked-by: Arnd Bergmann

Use WARN() in lib/

2008-07-26T19:00:07Z

Use WARN() instead of a printk+WARN_ON() pair; this way the message becomes part of the warning section for better reporting/collection. In addition, one of the if() clauses collapes into the WARN() entirely now. Signed-off-by: Arjan van de Ven Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

iomap: fix 64 bits resources on 32 bits

2008-04-29T15:06:02Z

Almost all implementations of pci_iomap() in the kernel, including the generic lib/iomap.c one, copies the content of a struct resource into unsigned long's which will break on 32 bits platforms with 64 bits resources. This fixes all definitions of pci_iomap() to use resource_size_t. I also "fixed" the 64bits arch for consistency. Signed-off-by: Benjamin Herrenschmidt Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

x86-32: Pass the full resource data to ioremap()

2008-03-24T18:22:39Z

It appears that 64-bit PCI resources cannot possibly ever have worked on x86-32 even when the RESOURCES_64BIT config option was set, because any driver that tried to [pci_]ioremap() the resource would have been unable to do so because the high 32 bits would have been silently dropped on the floor by the ioremap() routines that only used "unsigned long". Change them to use "resource_size_t" instead, which properly encodes the whole 64-bit resource data if RESOURCES_64BIT is enabled. Acked-by: H. Peter Anvin Acked-by: Stefan Richter Cc: Ivan Kokshaysky Signed-off-by: Linus Torvalds

lib: remove fastcall from lib/*

2008-02-08T17:22:31Z

[akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Harvey Harrison Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

lib/iomap.c:bad_io_access(): print 0x hex prefix

2007-10-17T15:42:57Z

Be explicit about printing hex. Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

PCI: Document pci_iomap()

2007-08-22T21:48:40Z

This useful interface is hardly mentioned anywhere in the in-tree documentation. Signed-off-by: Rolf Eike Beer Cc: Tejun Heo Acked-by: Randy Dunlap Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman

iomap: make the default iomap functions fail softer

2007-05-05T03:44:23Z

We used to BUG_ON() for a badly mapped IO port, which is certainly correct, but actually made it harder to debug the case where the ATA drivers had incorrectly mapped a nonconnected ATA port. So make badly mapped ports trigger a WARN_ON(), and throw the IO away instead (and return all ones for reads). For things like broken driver initialization - which is the most likely cause anyway - that should mean that the machine comes up and is usable (at least that was the case for the ATA breakage that triggered this patch). It tends to be a whole lot easier to do a "dmesg" on a working machine than to try to capture logs off a dead one. Signed-off-by: Linus Torvalds