@@ -50,3 +50,22 @@ void __iomem *ioremap_coherent(phys_addr_t addr, unsigned long size)returniowa_ioremap(addr,size,prot,caller);return__ioremap_caller(addr,size,prot,caller);}++void__iomem*ioremap_prot(phys_addr_taddr,unsignedlongsize,unsignedlongflags)+{+pte_tpte=__pte(flags);+void*caller=__builtin_return_address(0);++/* writeable implies dirty for kernel addresses */+if(pte_write(pte))+pte=pte_mkdirty(pte);++/* we don't want to let _PAGE_USER and _PAGE_EXEC leak out */+pte=pte_exprotect(pte);+pte=pte_mkprivileged(pte);++if(iowa_is_active())+returniowa_ioremap(addr,size,pte_pgprot(pte),caller);+return__ioremap_caller(addr,size,pte_pgprot(pte),caller);+}+EXPORT_SYMBOL(ioremap_prot);
@@ -39,23 +39,6 @@ EXPORT_SYMBOL(ioremap_bot); /* aka VMALLOC_END */externcharetext[],_stext[],_sinittext[],_einittext[];void__iomem*-ioremap_prot(phys_addr_taddr,unsignedlongsize,unsignedlongflags)-{-pte_tpte=__pte(flags);--/* writeable implies dirty for kernel addresses */-if(pte_write(pte))-pte=pte_mkdirty(pte);--/* we don't want to let _PAGE_USER and _PAGE_EXEC leak out */-pte=pte_exprotect(pte);-pte=pte_mkprivileged(pte);--return__ioremap_caller(addr,size,pte_pgprot(pte),__builtin_return_address(0));-}-EXPORT_SYMBOL(ioremap_prot);--void__iomem*__ioremap_caller(phys_addr_taddr,unsignedlongsize,pgprot_tprot,void*caller){unsignedlongv,i;
@@ -204,29 +204,6 @@ void __iomem * __ioremap_caller(phys_addr_t addr, unsigned long size,returnret;}-void__iomem*ioremap_prot(phys_addr_taddr,unsignedlongsize,-unsignedlongflags)-{-pte_tpte=__pte(flags);-void*caller=__builtin_return_address(0);--/* writeable implies dirty for kernel addresses */-if(pte_write(pte))-pte=pte_mkdirty(pte);--/* we don't want to let _PAGE_EXEC leak out */-pte=pte_exprotect(pte);-/*-*Forcekernelmapping.-*/-pte=pte_mkprivileged(pte);--if(iowa_is_active())-returniowa_ioremap(addr,size,pte_pgprot(pte),caller);-return__ioremap_caller(addr,size,pte_pgprot(pte),caller);-}--/* *UnmapanIOregionandremoveitfromimalloc'dlist.*AccesstoIOmemoryshouldbeserializedbydriver.
Until vmalloc system is up and running, ioremap basically
allocates addresses at the border of the IOREMAP area.
On PPC32, addresses are allocated down from the top of the area
while on PPC64, addresses are allocated up from the base of the
area.
On PPC32, the base of vmalloc area is not known yet when ioremap()
starts to be used, while the end of it is fixed. On PPC64, both the
start and the end are already fixed when ioremap() starts to being
used.
Changing PPC64 behaviour is the lighest change, so change PPC64
ioremap() to allocate addresses from the top as PPC32 does.
Signed-off-by: Christophe Leroy <redacted>
---
arch/powerpc/mm/book3s64/hash_utils.c | 2 +-
arch/powerpc/mm/book3s64/radix_pgtable.c | 2 +-
arch/powerpc/mm/pgtable_64.c | 18 +++++++++---------
3 files changed, 11 insertions(+), 11 deletions(-)
On PPC64 iounmap() does nothing else than calling __iounmap()
and is the only user of __iounmap().
__iounmap() is almost similar to PPC32 iounmap().
Lets define a common iounmap() and drop __iounmap().
Signed-off-by: Christophe Leroy <redacted>
---
arch/powerpc/include/asm/book3s/32/pgtable.h | 2 ++
arch/powerpc/include/asm/io.h | 5 -----
arch/powerpc/include/asm/nohash/32/pgtable.h | 2 ++
arch/powerpc/mm/ioremap.c | 31 ++++++++++++++++++++++++++++
arch/powerpc/mm/pgtable_32.c | 14 -------------
arch/powerpc/mm/pgtable_64.c | 28 -------------------------
6 files changed, 35 insertions(+), 47 deletions(-)
@@ -72,3 +75,31 @@ void __iomem *ioremap_prot(phys_addr_t addr, unsigned long size, unsigned long freturn__ioremap_caller(addr,size,pte_pgprot(pte),caller);}EXPORT_SYMBOL(ioremap_prot);++/*+*UnmapanIOregionandremoveitfromvmalloc'dlist.+*AccesstoIOmemoryshouldbeserializedbydriver.+*/+voidiounmap(volatilevoid__iomem*token)+{+void*addr;++/*+*IfmappedbyBATsthenthereisnothingtodo.+*/+if(v_block_mapped((unsignedlong)token))+return;++if(!slab_is_available())+return;++addr=(void*)((unsignedlong__force)PCI_FIX_ADDR(token)&PAGE_MASK);+if(WARN_ON((unsignedlong)addr<IOREMAP_BASE))+return;+if((unsignedlong)addr>=ioremap_bot){+pr_warn("Attempt to %s early bolted mapping at 0x%p\n",__func__,addr);+return;+}+vunmap(addr);+}+EXPORT_SYMBOL(iounmap);
@@ -201,8 +201,6 @@ int map_kernel_page(unsigned long va, phys_addr_t pa, pgprot_t prot);#include<linux/sched.h>#include<linux/threads.h>-externunsignedlongioremap_bot;-/* Bits to mask out from a PGD to get to the PUD page */#define PGD_MASKED_BITS 0
book3s64's ioremap_range() is almost same as fallback ioremap_range(),
except that it calls radix__ioremap_range() when radix is enabled.
radix__ioremap_range() is also very similar to the other ones, expect
that it calls ioremap_page_range when slab is available.
Lets keep only one version of ioremap_range() which calls
ioremap_page_range() on all platforms when slab is available.
At the same time, drop the nid parameter which is not used.
Signed-off-by: Christophe Leroy <redacted>
---
arch/powerpc/include/asm/book3s/64/radix.h | 3 ---
arch/powerpc/mm/book3s64/pgtable.c | 21 ---------------------
arch/powerpc/mm/book3s64/radix_pgtable.c | 20 --------------------
arch/powerpc/mm/ioremap.c | 23 +++++++++++++----------
4 files changed, 13 insertions(+), 54 deletions(-)
@@ -446,24 +446,3 @@ int pmd_move_must_withdraw(struct spinlock *new_pmd_ptl,returntrue;}--intioremap_range(unsignedlongea,phys_addr_tpa,unsignedlongsize,pgprot_tprot,intnid)-{-unsignedlongi;--if(radix_enabled())-returnradix__ioremap_range(ea,pa,size,prot,nid);--for(i=0;i<size;i+=PAGE_SIZE){-interr=map_kernel_page(ea+i,pa+i,prot);-if(err){-if(slab_is_available())-unmap_kernel_range(ea,size);-else-WARN_ON_ONCE(1);/* Should clean up */-returnerr;-}-}--return0;-}
@@ -1218,26 +1218,6 @@ int pmd_free_pte_page(pmd_t *pmd, unsigned long addr)return1;}-intradix__ioremap_range(unsignedlongea,phys_addr_tpa,unsignedlongsize,-pgprot_tprot,intnid)-{-if(likely(slab_is_available())){-interr=ioremap_page_range(ea,ea+size,pa,prot);-if(err)-unmap_kernel_range(ea,size);-returnerr;-}else{-unsignedlongi;--for(i=0;i<size;i+=PAGE_SIZE){-interr=map_kernel_page(ea+i,pa+i,prot);-if(WARN_ON_ONCE(err))/* Should clean up */-returnerr;-}-return0;-}-}-int__initarch_ioremap_p4d_supported(void){return0;
@@ -76,21 +76,24 @@ void __iomem *ioremap_prot(phys_addr_t addr, unsigned long size, unsigned long f}EXPORT_SYMBOL(ioremap_prot);-int__weakioremap_range(unsignedlongea,phys_addr_tpa,unsignedlongsize,-pgprot_tprot,intnid)+staticintioremap_range(unsignedlongea,phys_addr_tpa,unsignedlongsize,+pgprot_tprot){unsignedlongi;+if(slab_is_available()){+interr=ioremap_page_range(ea,ea+size,pa,prot);++if(err)+unmap_kernel_range(ea,size);+returnerr;+}+for(i=0;i<size;i+=PAGE_SIZE){interr=map_kernel_page(ea+i,pa+i,prot);-if(err){-if(slab_is_available())-unmap_kernel_range(ea,size);-else-WARN_ON_ONCE(1);/* Should clean up */+if(WARN_ON_ONCE(err))/* Should clean up */returnerr;-}}return0;
__ioremap_caller() do the same thing. Define a common one.
__ioremap() is not reused because most of the tests included in
it are unnecessary when coming from __ioremap_caller()
Signed-off-by: Christophe Leroy <redacted>
---
arch/powerpc/mm/ioremap.c | 99 ++++++++++++++++++++++++++++++++++++++++++++
arch/powerpc/mm/pgtable_32.c | 75 ---------------------------------
arch/powerpc/mm/pgtable_64.c | 61 ---------------------------
3 files changed, 99 insertions(+), 136 deletions(-)
@@ -76,6 +76,105 @@ void __iomem *ioremap_prot(phys_addr_t addr, unsigned long size, unsigned long f}EXPORT_SYMBOL(ioremap_prot);+int__weakioremap_range(unsignedlongea,phys_addr_tpa,unsignedlongsize,+pgprot_tprot,intnid)+{+unsignedlongi;++for(i=0;i<size;i+=PAGE_SIZE){+interr=map_kernel_page(ea+i,pa+i,prot);++if(err){+if(slab_is_available())+unmap_kernel_range(ea,size);+else+WARN_ON_ONCE(1);/* Should clean up */+returnerr;+}+}++return0;+}++void__iomem*__ioremap_caller(phys_addr_taddr,unsignedlongsize,+pgprot_tprot,void*caller)+{+phys_addr_tpa=addr&PAGE_MASK;+intret;+unsignedlongva;++size=PAGE_ALIGN(addr+size)-pa;++#ifdef CONFIG_PPC64+/* We don't support the 4K PFN hack with ioremap */+if(pgprot_val(prot)&H_PAGE_4K_PFN)+returnNULL;+#else+/*+*Iftheaddresslieswithinthefirst16MB,assumeit'sinISA+*memoryspace+*/+if(pa<SZ_16M)+pa+=_ISA_MEM_BASE;++#ifndef CONFIG_CRASH_DUMP+/*+*Don'tallowanybodytoremapnormalRAMthatwe'reusing.+*mem_init()setshigh_memorysoonlydothecheckafterthat.+*/+if(slab_is_available()&&pa<=virt_to_phys(high_memory-1)&&+page_is_ram(__phys_to_pfn(pa))){+pr_err("%s(): phys addr 0x%llx is RAM lr %ps\n",__func__,+(unsignedlonglong)pa,__builtin_return_address(0));+returnNULL;+}+#endif+#endif /* CONFIG_PPC64 */++if(size==0||pa==0)+returnNULL;++/*+*Isitalreadymapped?Perhapsoverlappedbyaprevious+*mapping.+*/+va=p_block_mapped(pa);+if(va)+return(void__iomem*)va+(addr&~PAGE_MASK);++/*+*Chooseanaddresstomapitto.+*Oncethevmallocsystemisrunning,weuseit.+*Beforethat,wemapusingaddressesgoing+*downfromioremap_bot.vmallocwilluse+*theaddressesfromIOREMAP_BASEthrough+*ioremap_bot+*+*/+if(slab_is_available()){+structvm_struct*area;++area=__get_vm_area_caller(size,VM_IOREMAP,IOREMAP_BASE,+ioremap_bot,caller);+if(area==NULL)+returnNULL;++area->phys_addr=pa;+va=(unsignedlong)area->addr;+}else{+ioremap_bot-=size;+va=ioremap_bot;+}+ret=ioremap_range(va,pa,size,prot,NUMA_NO_NODE);+if(!ret)+return(void__iomem*)va+(addr&~PAGE_MASK);++if(!slab_is_available())+ioremap_bot+=size;++returnNULL;+}+/**UnmapanIOregionandremoveitfromvmalloc'dlist.*AccesstoIOmemoryshouldbeserializedbydriver.
Allthough __ioremap_at() and __iounmap_at() are specific to PPC64,
lets move them into ioremap.c as it wouldn't be worth creating an
ioremap_64.c only for those functions.
Signed-off-by: Christophe Leroy <redacted>
---
arch/powerpc/mm/ioremap.c | 43 +++++++++++++++++++++++++++++++++++++++++++
arch/powerpc/mm/pgtable_64.c | 42 ------------------------------------------
2 files changed, 43 insertions(+), 42 deletions(-)
@@ -103,3 +103,46 @@ void iounmap(volatile void __iomem *token)vunmap(addr);}EXPORT_SYMBOL(iounmap);++#ifdef CONFIG_PPC64+/**+*__ioremap_at-Lowlevelfunctiontoestablishthepagetables+*foranIOmapping+*/+void__iomem*__ioremap_at(phys_addr_tpa,void*ea,unsignedlongsize,pgprot_tprot)+{+/* We don't support the 4K PFN hack with ioremap */+if(pgprot_val(prot)&H_PAGE_4K_PFN)+returnNULL;++if((ea+size)>=(void*)IOREMAP_END){+pr_warn("Outside the supported range\n");+returnNULL;+}++WARN_ON(pa&~PAGE_MASK);+WARN_ON(((unsignedlong)ea)&~PAGE_MASK);+WARN_ON(size&~PAGE_MASK);++if(ioremap_range((unsignedlong)ea,pa,size,prot,NUMA_NO_NODE))+returnNULL;++return(void__iomem*)ea;+}+EXPORT_SYMBOL(__ioremap_at);++/**+*__iounmap_from-Lowlevelfunctiontoteardownthepagetables+*foranIOmapping.Thisisusedformappingsthat+*aremanipulatedmanually,likepartialunmappingof+*PCIIOsorISAspace.+*/+void__iounmap_at(void*ea,unsignedlongsize)+{+WARN_ON(((unsignedlong)ea)&~PAGE_MASK);+WARN_ON(size&~PAGE_MASK);++unmap_kernel_range((unsignedlong)ea,size);+}+EXPORT_SYMBOL(__iounmap_at);+#endif
@@ -119,45 +119,6 @@ int __weak ioremap_range(unsigned long ea, phys_addr_t pa, unsigned long size, preturn0;}-/**-*__ioremap_at-Lowlevelfunctiontoestablishthepagetables-*foranIOmapping-*/-void__iomem*__ioremap_at(phys_addr_tpa,void*ea,unsignedlongsize,pgprot_tprot)-{-/* We don't support the 4K PFN hack with ioremap */-if(pgprot_val(prot)&H_PAGE_4K_PFN)-returnNULL;--if((ea+size)>=(void*)IOREMAP_END){-pr_warn("Outside the supported range\n");-returnNULL;-}--WARN_ON(pa&~PAGE_MASK);-WARN_ON(((unsignedlong)ea)&~PAGE_MASK);-WARN_ON(size&~PAGE_MASK);--if(ioremap_range((unsignedlong)ea,pa,size,prot,NUMA_NO_NODE))-returnNULL;--return(void__iomem*)ea;-}--/**-*__iounmap_from-Lowlevelfunctiontoteardownthepagetables-*foranIOmapping.Thisisusedformappingsthat-*aremanipulatedmanually,likepartialunmappingof-*PCIIOsorISAspace.-*/-void__iounmap_at(void*ea,unsignedlongsize)-{-WARN_ON(((unsignedlong)ea)&~PAGE_MASK);-WARN_ON(size&~PAGE_MASK);--unmap_kernel_range((unsignedlong)ea,size);-}-void__iomem*__ioremap_caller(phys_addr_taddr,unsignedlongsize,pgprot_tprot,void*caller){
ppc_md.ioremap() is only used for I/O workaround on CELL platform,
so indirect function call can be avoided.
This patch reworks the io-workaround and ioremap() functions to
use static keys for the activation of io-workaround.
When CONFIG_PPC_IO_WORKAROUNDS or CONFIG_PPC_INDIRECT_MMIO are not
selected, the I/O workaround ioremap() voids and the static key is
not used at all.
Signed-off-by: Christophe Leroy <redacted>
---
arch/powerpc/include/asm/io-workarounds.h | 19 +++++++++++++++++++
arch/powerpc/include/asm/machdep.h | 2 --
arch/powerpc/kernel/io-workarounds.c | 11 ++++++-----
arch/powerpc/mm/pgtable_64.c | 17 +++++++++--------
4 files changed, 34 insertions(+), 15 deletions(-)
ioremap(), __ioremap(), ioremap_wc() and ioremap_coherent() are
now identical on PPC32 and PPC64 as iowa_is_active() will always
return false on PPC32. Move them into a new common location called
ioremap.c
Allthough ioremap_wt() only exists on PPC32, move it into ioremap.c
as well. As it is the only one specific to PPC32, it is not worth
creating an ioremap_32.c file and leaving it in pgtable_32.c would
make it the only ioremap function in that file at the end of the
series.
Signed-off-by: Christophe Leroy <redacted>
---
arch/powerpc/mm/Makefile | 2 +-
arch/powerpc/mm/ioremap.c | 52 ++++++++++++++++++++++++++++++++++++++++++++
arch/powerpc/mm/pgtable_32.c | 43 ------------------------------------
arch/powerpc/mm/pgtable_64.c | 39 ---------------------------------
4 files changed, 53 insertions(+), 83 deletions(-)
create mode 100644 arch/powerpc/mm/ioremap.c
From: Christoph Hellwig <hch@infradead.org> Date: 2019-08-14 05:23:58
+/**
+ * __iounmap_from - Low level function to tear down the page tables
+ * for an IO mapping. This is used for mappings that
+ * are manipulated manually, like partial unmapping of
+ * PCI IOs or ISA space.
+ */
+void __iounmap_at(void *ea, unsigned long size)
The comment doesn't mention the function name. That's why I ususally
don't even add the function name so that it doesn't get out of sync.
From: Christoph Hellwig <hch@infradead.org> Date: 2019-08-14 05:39:02
On Tue, Aug 13, 2019 at 08:11:34PM +0000, Christophe Leroy wrote:
ppc_md.ioremap() is only used for I/O workaround on CELL platform,
so indirect function call can be avoided.
This patch reworks the io-workaround and ioremap() functions to
use static keys for the activation of io-workaround.
When CONFIG_PPC_IO_WORKAROUNDS or CONFIG_PPC_INDIRECT_MMIO are not
selected, the I/O workaround ioremap() voids and the static key is
not used at all.
Why bother with the complex static key? ioremap isn't exactly a fast
path. Just make it a normal branch if enabled, with the option to
compile it out entirely as in your patch.
From: Christoph Hellwig <hch@infradead.org> Date: 2019-08-14 05:49:51
Somehow this series is missing a cover letter.
While you are touching all this "fun" can you also look into killing
__ioremap? It seems to be a weird non-standard version of ioremap_prot
(probably predating ioremap_prot) that is missing a few lines of code
setting attributes that might not even be applicable for the two drivers
calling it.
From: Christoph Hellwig <hch@infradead.org> Date: 2019-08-14 05:55:36
On Tue, Aug 13, 2019 at 08:11:38PM +0000, Christophe Leroy wrote:
Until vmalloc system is up and running, ioremap basically
allocates addresses at the border of the IOREMAP area.
Note that while a few other architectures have a magic hack like powerpc
to make ioremap work before vmalloc, the normal practice would be
to explicitly use early_ioremap. I guess your change is fine for now,
but it might make sense convert powerpc to the explicit early_ioremap
scheme as well.
Le 14/08/2019 à 07:55, Christoph Hellwig a écrit :
On Tue, Aug 13, 2019 at 08:11:38PM +0000, Christophe Leroy wrote:
quoted
Until vmalloc system is up and running, ioremap basically
allocates addresses at the border of the IOREMAP area.
Note that while a few other architectures have a magic hack like powerpc
to make ioremap work before vmalloc, the normal practice would be
to explicitly use early_ioremap. I guess your change is fine for now,
but it might make sense convert powerpc to the explicit early_ioremap
scheme as well.
I've been looking into early_ioremap(), but IIUC early_ioremap() is for
ephemeral mappings only, it expects all early mappings to be gone at the
end of init.
PPC installs definitive early mappings (for instance for PCI). How does
that have to be handled ?
Christophe
From: Christoph Hellwig <hch@infradead.org> Date: 2019-08-14 06:14:24
On Wed, Aug 14, 2019 at 08:10:59AM +0200, Christophe Leroy wrote:
quoted
Note that while a few other architectures have a magic hack like powerpc
to make ioremap work before vmalloc, the normal practice would be
to explicitly use early_ioremap. I guess your change is fine for now,
but it might make sense convert powerpc to the explicit early_ioremap
scheme as well.
I've been looking into early_ioremap(), but IIUC early_ioremap() is for
ephemeral mappings only, it expects all early mappings to be gone at the end
of init.
Yes.
PPC installs definitive early mappings (for instance for PCI). How does that
have to be handled ?
Good question, and no good answer. I've just been looking at a generic
ioremap for simple architectures, and been finding all kinds of crap
and inconsistencies, and this is one of the things I noticed.
Le 14/08/2019 à 07:49, Christoph Hellwig a écrit :
Somehow this series is missing a cover letter.
While you are touching all this "fun" can you also look into killing
__ioremap? It seems to be a weird non-standard version of ioremap_prot
(probably predating ioremap_prot) that is missing a few lines of code
setting attributes that might not even be applicable for the two drivers
calling it.
ocm_init_node() [arch/powerpc/platforms/4xx/ocm.c] calls __ioremap()
with _PAGE_EXEC set while ioremap_prot() clears _PAGE_EXEC
Christophe
From: Christoph Hellwig <hch@infradead.org> Date: 2019-08-14 06:31:10
On Wed, Aug 14, 2019 at 08:23:54AM +0200, Christophe Leroy wrote:
Le 14/08/2019 à 07:49, Christoph Hellwig a écrit :
quoted
Somehow this series is missing a cover letter.
While you are touching all this "fun" can you also look into killing
__ioremap? It seems to be a weird non-standard version of ioremap_prot
(probably predating ioremap_prot) that is missing a few lines of code
setting attributes that might not even be applicable for the two drivers
calling it.
ocm_init_node() [arch/powerpc/platforms/4xx/ocm.c] calls __ioremap() with
_PAGE_EXEC set while ioremap_prot() clears _PAGE_EXEC
Indeed. But I don't see anything marking this intentional. Then again
the driver is entirely unused, so we might as well kill it off now.
From: Nicholas Piggin <npiggin@gmail.com> Date: 2019-08-19 13:42:52
Christophe Leroy's on August 14, 2019 6:11 am:
Until vmalloc system is up and running, ioremap basically
allocates addresses at the border of the IOREMAP area.
On PPC32, addresses are allocated down from the top of the area
while on PPC64, addresses are allocated up from the base of the
area.
This series looks pretty good to me, but I'm not sure about this patch.
It seems like quite a small divergence in terms of code, and it looks
like the final result still has some ifdefs in these functions. Maybe
you could just keep existing behaviour for this cleanup series so it
does not risk triggering some obscure regression? Merging behaviour
could be proposed at the end.
Thanks,
Nick
@@ -103,3 +103,46 @@ void iounmap(volatile void __iomem *token)vunmap(addr);}EXPORT_SYMBOL(iounmap);++#ifdef CONFIG_PPC64+/**+*__ioremap_at-Lowlevelfunctiontoestablishthepagetables+*foranIOmapping+*/+void__iomem*__ioremap_at(phys_addr_tpa,void*ea,unsignedlongsize,pgprot_tprot)+{+/* We don't support the 4K PFN hack with ioremap */+if(pgprot_val(prot)&H_PAGE_4K_PFN)+returnNULL;++if((ea+size)>=(void*)IOREMAP_END){+pr_warn("Outside the supported range\n");+returnNULL;+}++WARN_ON(pa&~PAGE_MASK);+WARN_ON(((unsignedlong)ea)&~PAGE_MASK);+WARN_ON(size&~PAGE_MASK);++if(ioremap_range((unsignedlong)ea,pa,size,prot,NUMA_NO_NODE))
This doesn't build.
Adding ...
extern int ioremap_range(unsigned long ea, phys_addr_t pa, unsigned long size, pgprot_t prot, int nid);
... above, until the next patch, fixes it.
cheers
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2019-08-20 00:20:24
Nicholas Piggin [off-list ref] writes:
Christophe Leroy's on August 14, 2019 6:11 am:
quoted
Until vmalloc system is up and running, ioremap basically
allocates addresses at the border of the IOREMAP area.
On PPC32, addresses are allocated down from the top of the area
while on PPC64, addresses are allocated up from the base of the
area.
This series looks pretty good to me, but I'm not sure about this patch.
It seems like quite a small divergence in terms of code, and it looks
like the final result still has some ifdefs in these functions. Maybe
you could just keep existing behaviour for this cleanup series so it
does not risk triggering some obscure regression?
Yeah that is also my feeling. Changing it *should* work, and I haven't
found anything that breaks yet, but it's one of those things that's
bound to break something for some obscure reason.
Christophe do you think you can rework it to retain the different
allocation directions at least for now?
cheers
Until vmalloc system is up and running, ioremap basically
allocates addresses at the border of the IOREMAP area.
On PPC32, addresses are allocated down from the top of the area
while on PPC64, addresses are allocated up from the base of the
area.
This series looks pretty good to me, but I'm not sure about this patch.
It seems like quite a small divergence in terms of code, and it looks
like the final result still has some ifdefs in these functions. Maybe
you could just keep existing behaviour for this cleanup series so it
does not risk triggering some obscure regression?
Yeah that is also my feeling. Changing it *should* work, and I haven't
found anything that breaks yet, but it's one of those things that's
bound to break something for some obscure reason.
Christophe do you think you can rework it to retain the different
allocation directions at least for now?
Yes I have started addressing the comments I received, and I think for
now I'll keep all the machinery aside from the merge. Not sure yet if
I'll leave it in pgtables_32/64.c or if I'll add ioremap_32/64.c
Christophe