linux-mips.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* RFC: kill off ioremap_nocache
@ 2019-12-09 13:58 Christoph Hellwig
  2019-12-09 13:58 ` [PATCH 1/2] MIPS: define ioremap_nocache to ioremap Christoph Hellwig
                   ` (2 more replies)
  0 siblings, 3 replies; 7+ messages in thread
From: Christoph Hellwig @ 2019-12-09 13:58 UTC (permalink / raw)
  To: Linus Torvalds, Paul Burton, James Hogan
  Cc: Arnd Bergmann, linux-mips, linux-arch, linux-kernel

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.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [PATCH 1/2] MIPS: define ioremap_nocache to ioremap
  2019-12-09 13:58 RFC: kill off ioremap_nocache Christoph Hellwig
@ 2019-12-09 13:58 ` Christoph Hellwig
  2019-12-09 18:46   ` Paul Burton
       [not found] ` <20191209135823.28465-3-hch@lst.de>
  2019-12-09 18:48 ` RFC: kill off ioremap_nocache Linus Torvalds
  2 siblings, 1 reply; 7+ messages in thread
From: Christoph Hellwig @ 2019-12-09 13:58 UTC (permalink / raw)
  To: Linus Torvalds, Paul Burton, James Hogan
  Cc: Arnd Bergmann, linux-mips, linux-arch, linux-kernel

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


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH 2/2] remove ioremap_nocache and devm_ioremap_nocache
       [not found] ` <20191209135823.28465-3-hch@lst.de>
@ 2019-12-09 15:58   ` Arnd Bergmann
  0 siblings, 0 replies; 7+ messages in thread
From: Arnd Bergmann @ 2019-12-09 15:58 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Linus Torvalds, Paul Burton, James Hogan,
	open list:BROADCOM NVRAM DRIVER, linux-arch, linux-kernel

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>

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH 1/2] MIPS: define ioremap_nocache to ioremap
  2019-12-09 13:58 ` [PATCH 1/2] MIPS: define ioremap_nocache to ioremap Christoph Hellwig
@ 2019-12-09 18:46   ` Paul Burton
  0 siblings, 0 replies; 7+ messages in thread
From: Paul Burton @ 2019-12-09 18:46 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Linus Torvalds, James Hogan, Arnd Bergmann, linux-mips,
	linux-arch, linux-kernel

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
> 

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: RFC: kill off ioremap_nocache
  2019-12-09 13:58 RFC: kill off ioremap_nocache Christoph Hellwig
  2019-12-09 13:58 ` [PATCH 1/2] MIPS: define ioremap_nocache to ioremap Christoph Hellwig
       [not found] ` <20191209135823.28465-3-hch@lst.de>
@ 2019-12-09 18:48 ` Linus Torvalds
  2019-12-09 19:48   ` Christoph Hellwig
  2019-12-17 18:35   ` Christoph Hellwig
  2 siblings, 2 replies; 7+ messages in thread
From: Linus Torvalds @ 2019-12-09 18:48 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Paul Burton, James Hogan, Arnd Bergmann, linux-mips, linux-arch, lkml

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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: RFC: kill off ioremap_nocache
  2019-12-09 18:48 ` RFC: kill off ioremap_nocache Linus Torvalds
@ 2019-12-09 19:48   ` Christoph Hellwig
  2019-12-17 18:35   ` Christoph Hellwig
  1 sibling, 0 replies; 7+ messages in thread
From: Christoph Hellwig @ 2019-12-09 19:48 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Christoph Hellwig, Paul Burton, James Hogan, Arnd Bergmann,
	linux-mips, linux-arch, lkml

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.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: RFC: kill off ioremap_nocache
  2019-12-09 18:48 ` RFC: kill off ioremap_nocache Linus Torvalds
  2019-12-09 19:48   ` Christoph Hellwig
@ 2019-12-17 18:35   ` Christoph Hellwig
  1 sibling, 0 replies; 7+ messages in thread
From: Christoph Hellwig @ 2019-12-17 18:35 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Christoph Hellwig, Paul Burton, James Hogan, Arnd Bergmann,
	linux-mips, linux-arch, lkml

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

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2019-12-17 18:35 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-12-09 13:58 RFC: kill off ioremap_nocache Christoph Hellwig
2019-12-09 13:58 ` [PATCH 1/2] MIPS: define ioremap_nocache to ioremap Christoph Hellwig
2019-12-09 18:46   ` Paul Burton
     [not found] ` <20191209135823.28465-3-hch@lst.de>
2019-12-09 15:58   ` [PATCH 2/2] remove ioremap_nocache and devm_ioremap_nocache Arnd Bergmann
2019-12-09 18:48 ` RFC: kill off ioremap_nocache Linus Torvalds
2019-12-09 19:48   ` Christoph Hellwig
2019-12-17 18:35   ` Christoph Hellwig

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).