* 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 related [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
[parent not found: <20191209135823.28465-3-hch@lst.de>]
* 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: 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).