RFC: kill off ioremap_nocache

RFC: kill off ioremap_nocache

[Christoph Hellwig]

Hi all,

with the ioremap changes that did land in 5.5-rc1 ioremap_nocache is
now equal to ioremap for all architectures.  For most architectures
including the common one this has been the case for about 20 years,
but we had a few holdouts.

That means ioremap_nocache is entirely superflous now and can be
killed off.  This series has one big scripted patch to do just that
after a little prep patch to fix up the not entirely obvious mips
definition.

Let me know what you think and if this is something acceptable for
just after -rc1.

[PATCH 1/2] MIPS: define ioremap_nocache to ioremap

[Christoph Hellwig]

They are both defined the same way, but this makes it easier to validate
the scripted ioremap_nocache removal following soon.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 arch/mips/include/asm/io.h | 25 ++-----------------------
 1 file changed, 2 insertions(+), 23 deletions(-)

diff --git a/arch/mips/include/asm/io.h b/arch/mips/include/asm/io.h
index 3f6ce74335b4..d9caa811a2fa 100644
--- a/arch/mips/include/asm/io.h
+++ b/arch/mips/include/asm/io.h
@@ -227,29 +227,8 @@ static inline void __iomem *ioremap_prot(phys_addr_t offset,
  */
 #define ioremap(offset, size)						\
 	__ioremap_mode((offset), (size), _CACHE_UNCACHED)
-
-/*
- * ioremap_nocache     -   map bus memory into CPU space
- * @offset:    bus address of the memory
- * @size:      size of the resource to map
- *
- * ioremap_nocache performs a platform specific sequence of operations to
- * make bus memory CPU accessible via the readb/readw/readl/writeb/
- * writew/writel functions and the other mmio helpers. The returned
- * address is not guaranteed to be usable directly as a virtual
- * address.
- *
- * This version of ioremap ensures that the memory is marked uncachable
- * on the CPU as well as honouring existing caching rules from things like
- * the PCI bus. Note that there are other caches and buffers on many
- * busses. In particular driver authors should read up on PCI writes
- *
- * It's useful if some control registers are in such an area and
- * write combining or read caching is not desirable:
- */
-#define ioremap_nocache(offset, size)					\
-	__ioremap_mode((offset), (size), _CACHE_UNCACHED)
-#define ioremap_uc ioremap_nocache
+#define ioremap_nocache		ioremap
+#define ioremap_uc		ioremap
 
 /*
  * ioremap_cache -	map bus memory into CPU space
-- 
2.20.1

Re: [PATCH 1/2] MIPS: define ioremap_nocache to ioremap

[Paul Burton]

Hi Christoph,

On Mon, Dec 09, 2019 at 02:58:21PM +0100, Christoph Hellwig wrote:
> They are both defined the same way, but this makes it easier to validate
> the scripted ioremap_nocache removal following soon.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>

Acked-by: Paul Burton <paulburton@kernel.org>

Thanks,
    Paul

> ---
>  arch/mips/include/asm/io.h | 25 ++-----------------------
>  1 file changed, 2 insertions(+), 23 deletions(-)
> 
> diff --git a/arch/mips/include/asm/io.h b/arch/mips/include/asm/io.h
> index 3f6ce74335b4..d9caa811a2fa 100644
> --- a/arch/mips/include/asm/io.h
> +++ b/arch/mips/include/asm/io.h
> @@ -227,29 +227,8 @@ static inline void __iomem *ioremap_prot(phys_addr_t offset,
>   */
>  #define ioremap(offset, size)						\
>  	__ioremap_mode((offset), (size), _CACHE_UNCACHED)
> -
> -/*
> - * ioremap_nocache     -   map bus memory into CPU space
> - * @offset:    bus address of the memory
> - * @size:      size of the resource to map
> - *
> - * ioremap_nocache performs a platform specific sequence of operations to
> - * make bus memory CPU accessible via the readb/readw/readl/writeb/
> - * writew/writel functions and the other mmio helpers. The returned
> - * address is not guaranteed to be usable directly as a virtual
> - * address.
> - *
> - * This version of ioremap ensures that the memory is marked uncachable
> - * on the CPU as well as honouring existing caching rules from things like
> - * the PCI bus. Note that there are other caches and buffers on many
> - * busses. In particular driver authors should read up on PCI writes
> - *
> - * It's useful if some control registers are in such an area and
> - * write combining or read caching is not desirable:
> - */
> -#define ioremap_nocache(offset, size)					\
> -	__ioremap_mode((offset), (size), _CACHE_UNCACHED)
> -#define ioremap_uc ioremap_nocache
> +#define ioremap_nocache		ioremap
> +#define ioremap_uc		ioremap
>  
>  /*
>   * ioremap_cache -	map bus memory into CPU space
> -- 
> 2.20.1
> 

Re: [PATCH 2/2] remove ioremap_nocache and devm_ioremap_nocache

[Arnd Bergmann]

On Mon, Dec 9, 2019 at 2:58 PM Christoph Hellwig <hch@lst.de> wrote:
>
> ioremap has provided non-cached semantics by default since the Linux 2.6
> days, so remove the additional ioremap_nocache interface.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>

Great work, thanks for getting this done!

Acked-by: Arnd Bergmann <arnd@arndb.de>

Re: RFC: kill off ioremap_nocache

[Linus Torvalds]

On Mon, Dec 9, 2019 at 5:58 AM Christoph Hellwig <hch@lst.de> wrote:
>
> Let me know what you think and if this is something acceptable for
> just after -rc1.

How many conflicts will this result in generally? I like it, but I'd
like to have some idea of whether it ends up being one of those
"really painful churn" things?

A couple of conflicts isn't an issue - they'll be trivial to fix. It's
the "this causes fifty silly conflicts" that I worry about, partly
because it then makes submaintainers inevitably do the wrong thing (ie
"I foresee an excessive amount of 'git rebase' rants next release").

Also, it looks like Google doesn't want this to happen. This whole
series was marked as spam for me.I'm not sure why, I don't see
anything odd that would trigger it, and DKIM and SPF both passed.
Maybe it's you, maybe it's Google, and maybe it's the infradead SRS
thing.

               Linus

Re: RFC: kill off ioremap_nocache

[Christoph Hellwig]

On Mon, Dec 09, 2019 at 10:48:20AM -0800, Linus Torvalds wrote:
> How many conflicts will this result in generally? I like it, but I'd
> like to have some idea of whether it ends up being one of those
> "really painful churn" things?
> 
> A couple of conflicts isn't an issue - they'll be trivial to fix. It's
> the "this causes fifty silly conflicts" that I worry about, partly
> because it then makes submaintainers inevitably do the wrong thing (ie
> "I foresee an excessive amount of 'git rebase' rants next release").

I had about a dozend and a half conflicts rebasing this weekend,
the previous version was approx -rc6 IIRC.

Re: RFC: kill off ioremap_nocache

[Christoph Hellwig]

I've pushed this out to the for-next branch and thus linux-next.  Let's
see if anyone screams.