On Saturday 30 May 2015 14:16:28 Dan Williams wrote:
> On Sat, May 30, 2015 at 1:52 PM, Arnd Bergmann <a...@arndb.de> 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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
