mirror of
https://github.com/BobTheBlinker/android_kernel_motorola_sm6375.git
synced 2026-10-29 19:21:31 -04:00
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 <[email protected]>
Reviewed-by: Christoph Hellwig <[email protected]>
Signed-off-by: Dan Williams <[email protected]>
This commit is contained in:
parent
2584cf8357
commit
92b19ff50e
11 changed files with 16 additions and 44 deletions
|
|
@ -97,8 +97,6 @@ static int pnp_assign_mem(struct pnp_dev *dev, struct pnp_mem *rule, int idx)
|
|||
/* ??? rule->flags restricted to 8 bits, all tests bogus ??? */
|
||||
if (!(rule->flags & IORESOURCE_MEM_WRITEABLE))
|
||||
res->flags |= IORESOURCE_READONLY;
|
||||
if (rule->flags & IORESOURCE_MEM_CACHEABLE)
|
||||
res->flags |= IORESOURCE_CACHEABLE;
|
||||
if (rule->flags & IORESOURCE_MEM_RANGELENGTH)
|
||||
res->flags |= IORESOURCE_RANGELENGTH;
|
||||
if (rule->flags & IORESOURCE_MEM_SHADOWABLE)
|
||||
|
|
|
|||
Loading…
Reference in a new issue