linux-kernel - Re: [PATCH v2 1/4] arch/*/asm/io.h: add ioremap

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1825055.kiMypDskUT@wuerfel>
Date:	Tue, 02 Jun 2015 10:20:48 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Toshi Kani <toshi.kani@...com>
Cc:	Dan Williams <dan.j.williams@...el.com>, mingo@...hat.com,
	bp@...en8.de, hpa@...or.com, tglx@...utronix.de,
	ross.zwisler@...ux.intel.com, akpm@...ux-foundation.org,
	jgross@...e.com, x86@...nel.org, linux-nvdimm@...ts.01.org,
	mcgrof@...e.com, konrad.wilk@...cle.com,
	linux-kernel@...r.kernel.org, stefan.bader@...onical.com,
	luto@...capital.net, linux-mm@...ck.org, geert@...ux-m68k.org,
	hmh@....eng.br, tj@...nel.org, hch@....de, dhowells@...hat.com
Subject: Re: [PATCH v2 1/4] arch/*/asm/io.h: add ioremap_cache() to all architectures

On Monday 01 June 2015 16:36:06 Toshi Kani wrote:
> On Sat, 2015-05-30 at 14:59 -0400, Dan Williams wrote:
> > Similar to ioremap_wc() let architecture implementations optionally
> > provide ioremap_cache().  As is, current ioremap_cache() users have
> > architecture dependencies that prevent them from compiling on archs
> > without ioremap_cache().  In some cases the architectures that have a
> > cached ioremap() capability have an identifier other than
> > "ioremap_cache".
> > 
> > Allow drivers to compile with ioremap_cache() support and fallback to a
> > safe / uncached ioremap otherwise.
>  :
> > diff --git a/arch/mn10300/include/asm/io.h b/arch/mn10300/include/asm/io.h
> > index 07c5b4a3903b..dcab414f40df 100644
> > --- a/arch/mn10300/include/asm/io.h
> > +++ b/arch/mn10300/include/asm/io.h
> > @@ -283,6 +283,7 @@ static inline void __iomem *ioremap_nocache(unsigned long offset, unsigned long
> >  
> >  #define ioremap_wc ioremap_nocache
> >  #define ioremap_wt ioremap_nocache
> > +#define ioremap_cache ioremap_nocache
> 
> From the comment in ioremap_nocache(), ioremap() may be cacheable in
> this arch.  

Right, and I guess that would be a bug. ;-)

mn10300 decides caching on the address, so presumably all arguments passed into
ioremap here already have that bit set. I've checked all the resource
definitions for mn10300, and they are all between 0xA0000000 and 0xBFFFFFFF,
which is non-cacheable.

> > diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
> > index f56094cfdeff..a0665dfcab47 100644
> > --- a/include/asm-generic/io.h
> > +++ b/include/asm-generic/io.h
> > @@ -793,6 +793,14 @@ static inline void __iomem *ioremap_wt(phys_addr_t offset, size_t size)
> >  }
> >  #endif
> >  
> > +#ifndef ioremap_cache
> > +#define ioremap_cache ioremap_cache
> > +static inline void __iomem *ioremap_cache(phys_addr_t offset, size_t size)
> > +{
> > +	return ioremap_nocache(offset, size);
> 
> Should this be defined as ioremap()?

I would leave it like this, for clarity. All architectures at the moment
need to define ioremap_nocache and ioremap to be the same thing anyway,
but this definition makes it clearer that it's not actually cached.

> > diff --git a/include/asm-generic/iomap.h b/include/asm-generic/iomap.h
> > index d8f8622fa044..f0f30464cecd 100644
> > --- a/include/asm-generic/iomap.h
> > +++ b/include/asm-generic/iomap.h
> > @@ -70,6 +70,10 @@ extern void ioport_unmap(void __iomem *);
> >  #define ioremap_wt ioremap_nocache
> >  #endif
> >  
> > +#ifndef ARCH_HAS_IOREMAP_CACHE
> > +#define ioremap_cache ioremap_nocache
> 
> Ditto.
> 
> 
> Also, it'd be nice to remove ioremap_cached() and ioremap_fullcache()
> with a separate patch in this opportunity.

Agreed.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/