diff options
| author | Dan Williams <dan.j.williams@intel.com> | 2015-08-11 06:07:06 +0300 |
|---|---|---|
| committer | Dan Williams <dan.j.williams@intel.com> | 2015-08-11 06:07:06 +0300 |
| commit | 92b19ff50e8f242392d78b2aacc5b5b672f1796b (patch) | |
| tree | 463927d91228174419ba1fe327f3cec6b9a2615a /lib/pci_iomap.c | |
| parent | 2584cf83578c26db144730ef498f4070f82ee3ea (diff) | |
| download | linux-92b19ff50e8f242392d78b2aacc5b5b672f1796b.tar.xz | |
cleanup IORESOURCE_CACHEABLE vs ioremap()
Quoting Arnd:
I was thinking the opposite approach and basically removing all uses
of IORESOURCE_CACHEABLE from the kernel. There are only a handful of
them.and we can probably replace them all with hardcoded
ioremap_cached() calls in the cases they are actually useful.
All existing usages of IORESOURCE_CACHEABLE call ioremap() instead of
ioremap_nocache() if the resource is cacheable, however ioremap() is
uncached by default. Clearly none of the existing usages care about the
cacheability. Particularly devm_ioremap_resource() never worked as
advertised since it always fell back to plain ioremap().
Clean this up as the new direction we want is to convert
ioremap_<type>() usages to memremap(..., flags).
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Diffstat (limited to 'lib/pci_iomap.c')
| -rw-r--r-- | lib/pci_iomap.c | 7 |
1 files changed, 2 insertions, 5 deletions
diff --git a/lib/pci_iomap.c b/lib/pci_iomap.c index bcce5f149310..e1930dbab2da 100644 --- a/lib/pci_iomap.c +++ b/lib/pci_iomap.c @@ -41,11 +41,8 @@ void __iomem *pci_iomap_range(struct pci_dev *dev, len = maxlen; if (flags & IORESOURCE_IO) return __pci_ioport_map(dev, start, len); - if (flags & IORESOURCE_MEM) { - if (flags & IORESOURCE_CACHEABLE) - return ioremap(start, len); - return ioremap_nocache(start, len); - } + if (flags & IORESOURCE_MEM) + return ioremap(start, len); /* What? */ return NULL; } |