On Saturday 30 May 2015 14:16:28 Dan Williams wrote: > On Sat, May 30, 2015 at 1:52 PM, Arnd Bergmann <arnd@xxxxxxxx> wrote: > > On Saturday 30 May 2015, Dan Williams wrote: > >> @@ -154,7 +148,7 @@ void __iomem *devm_ioremap_resource(struct device *dev, struct resource *res) > >> } > >> > >> if (res->flags & IORESOURCE_CACHEABLE) > >> - dest_ptr = devm_ioremap(dev, res->start, size); > >> + dest_ptr = devm_ioremap_cache(dev, res->start, size); > >> else > >> dest_ptr = devm_ioremap_nocache(dev, res->start, size); > > > > I think the existing uses of IORESOURCE_CACHEABLE are mostly bugs, so changing > > the behavior here may cause more problems than it solves. > > > > Ok, but that effectively makes devm_ioremap_resource() unusable for > the cached case. How about introducing devm_ioremap_cache_resource(), > and cleaning up devm_ioremap_resource() to stop pretending that it is > honoring the memory type of the resource? 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 Arnd -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>