Re: [PATCH] powerpc/4xx/ocm: fix compiler error
On Sat, Dec 22, 2018 at 08:37:28PM +0100, christophe leroy wrote: > Le 22/12/2018 à 18:16, Segher Boessenkool a écrit : > >On Sat, Dec 22, 2018 at 02:08:02PM +0100, christophe leroy wrote: > >> > >>Usually, Guarded implies no exec (at least on 6xx and 8xx). > > > >Huh? What do you mean here? > > From the 885 Reference Manual: > > Address translation: the EA is translated by using the MMU’s TLB > mechanism. Instructions are not fetched from no-execute or guarded > memory and data accesses are not executed speculatively to or from the > guarded memory. > > 6.1.3.4 Instruction TLB Error Exception (0x01300) > This type of exception occurs as a result of one of the following > conditions if MSR[IR] = 1: > - The EA cannot be translated. > - The fetch access violates memory protection > - The fetch access is to guarded memory > > > From e300core reference manual: > > Translation Exception Conditions: > Exception condition: Instruction fetch from guarded memory > with MSR[IR] = 1 ==> ISI interrupt SRR1[3] = 1 Right, but you said 6xx as well, i.e. pure PowerPC. If for example IR=0 you cannot have N=1, but you do have G=1. There is no case where G=1 implies N=1 afaik, or where fetch is prohibited some other way (causes an ISI, say). Segher
Re: Pull request: scottwood/linux.git next
On Sat, 2018-12-22 at 11:50 +0100, christophe leroy wrote: > Hi Scott, > > Le 22/12/2018 à 05:42, Scott Wood a écrit : > > Christophe Leroy (1): > >powerpc/83xx: handle machine check caused by watchdog timer > > kbuild robot reported a build failure, most likely due to missing > asm/debug.h > Did you fix it or do you need an updated patch ? I added the missing #include -Scott
Re: [PATCH] powerpc/4xx/ocm: fix compiler error
Le 22/12/2018 à 18:16, Segher Boessenkool a écrit : On Sat, Dec 22, 2018 at 02:08:02PM +0100, christophe leroy wrote: Usually, Guarded implies no exec (at least on 6xx and 8xx). Huh? What do you mean here? From the 885 Reference Manual: Address translation: the EA is translated by using the MMU’s TLB mechanism. Instructions are not fetched from no-execute or guarded memory and data accesses are not executed speculatively to or from the guarded memory. 6.1.3.4 Instruction TLB Error Exception (0x01300) This type of exception occurs as a result of one of the following conditions if MSR[IR] = 1: - The EA cannot be translated. - The fetch access violates memory protection - The fetch access is to guarded memory From e300core reference manual: Translation Exception Conditions: Exception condition: Instruction fetch from guarded memory with MSR[IR] = 1 ==> ISI interrupt SRR1[3] = 1 Christophe --- L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast. https://www.avast.com/antivirus
Re: [PATCH] powerpc/4xx/ocm: fix compiler error
On Sat, Dec 22, 2018 at 02:08:02PM +0100, christophe leroy wrote: > > Usually, Guarded implies no exec (at least on 6xx and 8xx). Huh? What do you mean here? Segher
Re: [PATCH v2] powerpc/4xx/ocm: fix compilation error
Le 22/12/2018 à 15:35, Christian Lamparter a écrit :
This patch fixes a recent compilation regression in ocm:
| ocm.c: In function ‘ocm_init_node’:
| ocm.c:182:18: error: invalid operands to binary |
| (have ‘int’ and ‘pgprot_t’ {aka ‘struct ’})
| _PAGE_EXEC | PAGE_KERNEL_NCG);
| ^
|
| ocm.c:197:17: error: invalid operands to binary |
| (have ‘int’ and ‘pgprot_t’ {aka ‘struct ’})
|_PAGE_EXEC | PAGE_KERNEL);
| ^
Fixes: 56f3c1413f5c ("powerpc/mm: properly set PAGE_KERNEL flags in ioremap()")
Signed-off-by: Christian Lamparter
Reviewed-by: Christophe Leroy
Cc: sta...@vger.kernel.org
---
arch/powerpc/platforms/4xx/ocm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/4xx/ocm.c b/arch/powerpc/platforms/4xx/ocm.c
index 561b09de69bf..de3565353153 100644
--- a/arch/powerpc/platforms/4xx/ocm.c
+++ b/arch/powerpc/platforms/4xx/ocm.c
@@ -179,7 +179,7 @@ static void __init ocm_init_node(int count, struct
device_node *node)
/* ioremap the non-cached region */
if (ocm->nc.memtotal) {
ocm->nc.virt = __ioremap(ocm->nc.phys, ocm->nc.memtotal,
-_PAGE_EXEC | PAGE_KERNEL_NCG);
+ _PAGE_EXEC | pgprot_val(PAGE_KERNEL_NCG));
if (!ocm->nc.virt) {
printk(KERN_ERR
@@ -194,7 +194,7 @@ static void __init ocm_init_node(int count, struct
device_node *node)
if (ocm->c.memtotal) {
ocm->c.virt = __ioremap(ocm->c.phys, ocm->c.memtotal,
- _PAGE_EXEC | PAGE_KERNEL);
+ _PAGE_EXEC | pgprot_val(PAGE_KERNEL));
if (!ocm->c.virt) {
printk(KERN_ERR
---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel
antivirus Avast.
https://www.avast.com/antivirus
[PATCH v2] powerpc/4xx/ocm: fix compilation error
This patch fixes a recent compilation regression in ocm:
| ocm.c: In function ‘ocm_init_node’:
| ocm.c:182:18: error: invalid operands to binary |
| (have ‘int’ and ‘pgprot_t’ {aka ‘struct ’})
| _PAGE_EXEC | PAGE_KERNEL_NCG);
| ^
|
| ocm.c:197:17: error: invalid operands to binary |
| (have ‘int’ and ‘pgprot_t’ {aka ‘struct ’})
|_PAGE_EXEC | PAGE_KERNEL);
| ^
Fixes: 56f3c1413f5c ("powerpc/mm: properly set PAGE_KERNEL flags in ioremap()")
Signed-off-by: Christian Lamparter
---
arch/powerpc/platforms/4xx/ocm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/4xx/ocm.c b/arch/powerpc/platforms/4xx/ocm.c
index 561b09de69bf..de3565353153 100644
--- a/arch/powerpc/platforms/4xx/ocm.c
+++ b/arch/powerpc/platforms/4xx/ocm.c
@@ -179,7 +179,7 @@ static void __init ocm_init_node(int count, struct
device_node *node)
/* ioremap the non-cached region */
if (ocm->nc.memtotal) {
ocm->nc.virt = __ioremap(ocm->nc.phys, ocm->nc.memtotal,
-_PAGE_EXEC | PAGE_KERNEL_NCG);
+ _PAGE_EXEC | pgprot_val(PAGE_KERNEL_NCG));
if (!ocm->nc.virt) {
printk(KERN_ERR
@@ -194,7 +194,7 @@ static void __init ocm_init_node(int count, struct
device_node *node)
if (ocm->c.memtotal) {
ocm->c.virt = __ioremap(ocm->c.phys, ocm->c.memtotal,
- _PAGE_EXEC | PAGE_KERNEL);
+ _PAGE_EXEC | pgprot_val(PAGE_KERNEL));
if (!ocm->c.virt) {
printk(KERN_ERR
--
2.20.1
Re: [PATCH] powerpc/4xx/ocm: fix compiler error
On Saturday, December 22, 2018 2:08:02 PM CET christophe leroy wrote:
>
> Le 22/12/2018 à 12:27, Christian Lamparter a écrit :
> > On Saturday, December 22, 2018 11:59:04 AM CET christophe leroy wrote:
> >>
> >> Le 22/12/2018 à 11:09, Christian Lamparter a écrit :
> >>> This patch fixes a recent regression in ocm:
> >>>
> >>> ocm.c: In function ‘ocm_init_node’:
> >>> ocm.c:182:18: error: invalid operands to binary |
> >>> ocm.c:197:17: error: invalid operands to binary |
> >>>
> >>> Fixes: 56f3c1413f5c ("powerpc/mm: properly set PAGE_KERNEL flags in
> >>> ioremap()")
> >>> Signed-off-by: Christian Lamparter
> >>
> >> What's the problem here ? Is PAGE_KERNEL_NCG undefined ? If that's the
> >> case, wouldn't it be better for fix that by including asm/pgtable.h ?
> >
> > PAGE_KERNEL[_NCG] type is a struct of pgprot_t, whereas _PAGE_EXEC is
> > considered an int.
>
> Oops, I missed that.
>
> Could you put the entire error message in the commit log ?
Will do in v2... which I'm going to sent out shortly. I mainly wanted to
make the most "trivial fix" since it probably needs to be backported to
4.20-stable at this late in the rc phase.
> >
> > arch/powerpc/platforms/4xx/ocm.c: In function ‘ocm_init_node’:
> > arch/powerpc/platforms/4xx/ocm.c:182:18: error: invalid operands to binary
> > | (have ‘int’ and ‘pgprot_t’ {aka ‘struct ’})
> > _PAGE_EXEC | PAGE_KERNEL_NCG);
>
> Usually, Guarded implies no exec (at least on 6xx and 8xx). Does the 4xx
> accept guarded exec ?
Oh, I simply copied over the individual _PAGE_* flags that the PAGE_KERNEL_NCG
macro set. The OCM is usually a small (32 KiB) DMA descriptor storage, I don't
think anyone would want to execute code in there.
>
> >^
> > arch/powerpc/platforms/4xx/ocm.c:197:17: error: invalid operands to binary
> > | (have ‘int’ and ‘pgprot_t’ {aka ‘struct ’})
> > _PAGE_EXEC | PAGE_KERNEL);
>
> That's PAGE_KERNEL_X
>
> >^
> >
> > I think pgprot_val(PAGE_KERNEL[_NCG]) could be an option too.
>
> Yes I may have a preference for that.
K, I liked having all _PAGE_*. But I'm fine either way.
see you for v2. :-D
> >
> > Christian
> >>> ---
> >>>arch/powerpc/platforms/4xx/ocm.c | 6 --
> >>>1 file changed, 4 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/arch/powerpc/platforms/4xx/ocm.c
> >>> b/arch/powerpc/platforms/4xx/ocm.c
> >>> index 561b09de69bf..04ff69ddac09 100644
> >>> --- a/arch/powerpc/platforms/4xx/ocm.c
> >>> +++ b/arch/powerpc/platforms/4xx/ocm.c
> >>> @@ -179,7 +179,8 @@ static void __init ocm_init_node(int count, struct
> >>> device_node *node)
> >>> /* ioremap the non-cached region */
> >>> if (ocm->nc.memtotal) {
> >>> ocm->nc.virt = __ioremap(ocm->nc.phys, ocm->nc.memtotal,
> >>> - _PAGE_EXEC | PAGE_KERNEL_NCG);
> >>> + _PAGE_EXEC | _PAGE_BASE_NC |
> >>> + _PAGE_KERNEL_RW | _PAGE_NO_CACHE | _PAGE_GUARDED);
>
> Could be _PAGE_BASE_NC | _PAGE_KERNEL_RWX | _PAGE_NO_CACHE | _PAGE_GUARDED
>
> Or pgprot_val(PAGE_KERNEL_NCG) | _PAGE_EXEC
>
> Or pgprot_val(pgprot_noncached(PAGE_KERNEL_RWX)) (that's my preference)
>
> >>>
> >>> if (!ocm->nc.virt) {
> >>> printk(KERN_ERR
> >>> @@ -194,7 +195,8 @@ static void __init ocm_init_node(int count, struct
> >>> device_node *node)
> >>>
> >>> if (ocm->c.memtotal) {
> >>> ocm->c.virt = __ioremap(ocm->c.phys, ocm->c.memtotal,
> >>> - _PAGE_EXEC | PAGE_KERNEL);
> >>> + _PAGE_EXEC | _PAGE_BASE |
> >>> + _PAGE_KERNEL_RW);
>
> What about _PAGE_BASE | _PAGE_KERNEL_RWX instead ?
>
> Or pgprot_val(PAGE_KERNEL_RWX) (that's my preference)
I'll test if any of these make a difference and sent a separate patch.
Christian
Re: [PATCH] powerpc/4xx/ocm: fix compiler error
Le 22/12/2018 à 12:27, Christian Lamparter a écrit :
On Saturday, December 22, 2018 11:59:04 AM CET christophe leroy wrote:
Le 22/12/2018 à 11:09, Christian Lamparter a écrit :
This patch fixes a recent regression in ocm:
ocm.c: In function ‘ocm_init_node’:
ocm.c:182:18: error: invalid operands to binary |
ocm.c:197:17: error: invalid operands to binary |
Fixes: 56f3c1413f5c ("powerpc/mm: properly set PAGE_KERNEL flags in ioremap()")
Signed-off-by: Christian Lamparter
What's the problem here ? Is PAGE_KERNEL_NCG undefined ? If that's the
case, wouldn't it be better for fix that by including asm/pgtable.h ?
PAGE_KERNEL[_NCG] type is a struct of pgprot_t, whereas _PAGE_EXEC is
considered an int.
Oops, I missed that.
Could you put the entire error message in the commit log ?
arch/powerpc/platforms/4xx/ocm.c: In function ‘ocm_init_node’:
arch/powerpc/platforms/4xx/ocm.c:182:18: error: invalid operands to binary | (have
‘int’ and ‘pgprot_t’ {aka ‘struct ’})
_PAGE_EXEC | PAGE_KERNEL_NCG);
Usually, Guarded implies no exec (at least on 6xx and 8xx). Does the 4xx
accept guarded exec ?
^
arch/powerpc/platforms/4xx/ocm.c:197:17: error: invalid operands to binary | (have
‘int’ and ‘pgprot_t’ {aka ‘struct ’})
_PAGE_EXEC | PAGE_KERNEL);
That's PAGE_KERNEL_X
^
I think pgprot_val(PAGE_KERNEL[_NCG]) could be an option too.
Yes I may have a preference for that.
Christian
---
arch/powerpc/platforms/4xx/ocm.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/4xx/ocm.c b/arch/powerpc/platforms/4xx/ocm.c
index 561b09de69bf..04ff69ddac09 100644
--- a/arch/powerpc/platforms/4xx/ocm.c
+++ b/arch/powerpc/platforms/4xx/ocm.c
@@ -179,7 +179,8 @@ static void __init ocm_init_node(int count, struct
device_node *node)
/* ioremap the non-cached region */
if (ocm->nc.memtotal) {
ocm->nc.virt = __ioremap(ocm->nc.phys, ocm->nc.memtotal,
-_PAGE_EXEC | PAGE_KERNEL_NCG);
+ _PAGE_EXEC | _PAGE_BASE_NC |
+ _PAGE_KERNEL_RW | _PAGE_NO_CACHE | _PAGE_GUARDED);
Could be _PAGE_BASE_NC | _PAGE_KERNEL_RWX | _PAGE_NO_CACHE | _PAGE_GUARDED
Or pgprot_val(PAGE_KERNEL_NCG) | _PAGE_EXEC
Or pgprot_val(pgprot_noncached(PAGE_KERNEL_RWX)) (that's my preference)
if (!ocm->nc.virt) {
printk(KERN_ERR
@@ -194,7 +195,8 @@ static void __init ocm_init_node(int count, struct
device_node *node)
if (ocm->c.memtotal) {
ocm->c.virt = __ioremap(ocm->c.phys, ocm->c.memtotal,
- _PAGE_EXEC | PAGE_KERNEL);
+ _PAGE_EXEC | _PAGE_BASE |
+ _PAGE_KERNEL_RW);
What about _PAGE_BASE | _PAGE_KERNEL_RWX instead ?
Or pgprot_val(PAGE_KERNEL_RWX) (that's my preference)
Christophe
if (!ocm->c.virt) {
printk(KERN_ERR
---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel
antivirus Avast.
https://www.avast.com/antivirus
Re: [for-next][PATCH 05/24] powerpc/frace: Use ftrace_graph_get_ret_stack() instead of curr_ret_stack
On Sat, 22 Dec 2018 20:51:21 +1100 Michael Ellerman wrote: > I did test the previous series you posted and I think everything was OK > running the ftracetest suite (I got one or two fails but I think that > was because of missing CONFIG options). > > Acked-by: Michael Ellerman (powerpc) Thanks! I'll add your ack. -- Steve
Re: [PATCH] powerpc/4xx/ocm: fix compiler error
On Saturday, December 22, 2018 11:59:04 AM CET christophe leroy wrote:
>
> Le 22/12/2018 à 11:09, Christian Lamparter a écrit :
> > This patch fixes a recent regression in ocm:
> >
> > ocm.c: In function ‘ocm_init_node’:
> > ocm.c:182:18: error: invalid operands to binary |
> > ocm.c:197:17: error: invalid operands to binary |
> >
> > Fixes: 56f3c1413f5c ("powerpc/mm: properly set PAGE_KERNEL flags in
> > ioremap()")
> > Signed-off-by: Christian Lamparter
>
> What's the problem here ? Is PAGE_KERNEL_NCG undefined ? If that's the
> case, wouldn't it be better for fix that by including asm/pgtable.h ?
PAGE_KERNEL[_NCG] type is a struct of pgprot_t, whereas _PAGE_EXEC is
considered an int.
arch/powerpc/platforms/4xx/ocm.c: In function ‘ocm_init_node’:
arch/powerpc/platforms/4xx/ocm.c:182:18: error: invalid operands to binary |
(have ‘int’ and ‘pgprot_t’ {aka ‘struct ’})
_PAGE_EXEC | PAGE_KERNEL_NCG);
^
arch/powerpc/platforms/4xx/ocm.c:197:17: error: invalid operands to binary |
(have ‘int’ and ‘pgprot_t’ {aka ‘struct ’})
_PAGE_EXEC | PAGE_KERNEL);
^
I think pgprot_val(PAGE_KERNEL[_NCG]) could be an option too.
Christian
> > ---
> > arch/powerpc/platforms/4xx/ocm.c | 6 --
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/powerpc/platforms/4xx/ocm.c
> > b/arch/powerpc/platforms/4xx/ocm.c
> > index 561b09de69bf..04ff69ddac09 100644
> > --- a/arch/powerpc/platforms/4xx/ocm.c
> > +++ b/arch/powerpc/platforms/4xx/ocm.c
> > @@ -179,7 +179,8 @@ static void __init ocm_init_node(int count, struct
> > device_node *node)
> > /* ioremap the non-cached region */
> > if (ocm->nc.memtotal) {
> > ocm->nc.virt = __ioremap(ocm->nc.phys, ocm->nc.memtotal,
> > -_PAGE_EXEC | PAGE_KERNEL_NCG);
> > + _PAGE_EXEC | _PAGE_BASE_NC |
> > + _PAGE_KERNEL_RW | _PAGE_NO_CACHE | _PAGE_GUARDED);
> >
> > if (!ocm->nc.virt) {
> > printk(KERN_ERR
> > @@ -194,7 +195,8 @@ static void __init ocm_init_node(int count, struct
> > device_node *node)
> >
> > if (ocm->c.memtotal) {
> > ocm->c.virt = __ioremap(ocm->c.phys, ocm->c.memtotal,
> > - _PAGE_EXEC | PAGE_KERNEL);
> > + _PAGE_EXEC | _PAGE_BASE |
> > + _PAGE_KERNEL_RW);
> >
> > if (!ocm->c.virt) {
> > printk(KERN_ERR
> >
>
Re: Pull request: scottwood/linux.git next
Hi Scott, Le 22/12/2018 à 05:42, Scott Wood a écrit : Highlights include elimination of legacy clock bindings use from dts files, an 83xx watchdog handler, fixes to old dts interrupt errors, and some minor cleanup. The following changes since commit 8c6c942d33f2a79439e86f8f406afae40a5bc767: powerpc/eeh: Fix debugfs_simple_attr.cocci warnings (2018-12-20 22:59:03 +1100) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git next for you to fetch changes up to 5f470b3638a4ed03df79b993ece819cac2f4ca7e: powerpc/configs/85xx: Enable CONFIG_DEBUG_KERNEL (2018-12-21 22:07:54 -0600) Alexandre Belloni (1): powerpc/fsl-rio: fix spelling mistake "reserverd" -> "reserved" Christoph Hellwig (1): powerpc/fsl_pci: simplify fsl_pci_dma_set_mask Christophe Leroy (1): powerpc/83xx: handle machine check caused by watchdog timer kbuild robot reported a build failure, most likely due to missing asm/debug.h Did you fix it or do you need an updated patch ? Christophe Sabyasachi Gupta (1): arch/powerpc/fsl_rmu: Use dma_zalloc_coherent Scott Wood (3): powerpc/fsl: Use new clockgen binding powerpc/dts/fsl: Fix dtc-flagged interrupt errors powerpc/configs/85xx: Enable CONFIG_DEBUG_KERNEL Yuantian Tang (1): clk: qoriq: add more compatibles strings .../devicetree/bindings/clock/qoriq-clock.txt | 6 + arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi | 4 +- arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi | 8 +- arch/powerpc/boot/dts/fsl/b4si-post.dtsi | 15 --- arch/powerpc/boot/dts/fsl/mpc8641_hpcn.dts | 128 ++--- arch/powerpc/boot/dts/fsl/mpc8641_hpcn_36b.dts | 128 ++--- arch/powerpc/boot/dts/fsl/mpc8641si-post.dtsi | 2 + arch/powerpc/boot/dts/fsl/p1020rdb-pc.dtsi | 4 +- arch/powerpc/boot/dts/fsl/p2041si-post.dtsi| 18 --- arch/powerpc/boot/dts/fsl/p2041si-pre.dtsi | 8 +- arch/powerpc/boot/dts/fsl/p3041si-post.dtsi| 18 --- arch/powerpc/boot/dts/fsl/p3041si-pre.dtsi | 8 +- arch/powerpc/boot/dts/fsl/p4080si-post.dtsi| 70 --- arch/powerpc/boot/dts/fsl/p4080si-pre.dtsi | 16 +-- arch/powerpc/boot/dts/fsl/p5020si-pre.dtsi | 4 +- arch/powerpc/boot/dts/fsl/p5040si-post.dtsi| 18 --- arch/powerpc/boot/dts/fsl/p5040si-pre.dtsi | 8 +- arch/powerpc/boot/dts/fsl/qoriq-clockgen1.dtsi | 47 arch/powerpc/boot/dts/fsl/qoriq-clockgen2.dtsi | 30 - arch/powerpc/boot/dts/fsl/t1023si-post.dtsi| 16 --- arch/powerpc/boot/dts/fsl/t102xsi-pre.dtsi | 4 +- arch/powerpc/boot/dts/fsl/t1040si-post.dtsi| 44 --- arch/powerpc/boot/dts/fsl/t104xsi-pre.dtsi | 8 +- arch/powerpc/boot/dts/fsl/t2081si-post.dtsi| 22 arch/powerpc/boot/dts/fsl/t208xsi-pre.dtsi | 8 +- arch/powerpc/boot/dts/fsl/t4240si-post.dtsi| 61 -- arch/powerpc/boot/dts/fsl/t4240si-pre.dtsi | 24 ++-- arch/powerpc/boot/dts/mpc832x_rdb.dts | 4 - arch/powerpc/configs/fsl-emb-nonhw.config | 1 + arch/powerpc/include/asm/cputable.h| 1 + arch/powerpc/include/asm/reg.h | 2 + arch/powerpc/kernel/cputable.c | 10 +- arch/powerpc/platforms/83xx/misc.c | 17 +++ arch/powerpc/sysdev/fsl_pci.c | 6 +- arch/powerpc/sysdev/fsl_rio.h | 2 +- arch/powerpc/sysdev/fsl_rmu.c | 4 +- 36 files changed, 218 insertions(+), 556 deletions(-) --- L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast. https://www.avast.com/antivirus
Re: [PATCH] powerpc/4xx/ocm: fix compiler error
Le 22/12/2018 à 11:09, Christian Lamparter a écrit :
This patch fixes a recent regression in ocm:
ocm.c: In function ‘ocm_init_node’:
ocm.c:182:18: error: invalid operands to binary |
ocm.c:197:17: error: invalid operands to binary |
Fixes: 56f3c1413f5c ("powerpc/mm: properly set PAGE_KERNEL flags in ioremap()")
Signed-off-by: Christian Lamparter
What's the problem here ? Is PAGE_KERNEL_NCG undefined ? If that's the
case, wouldn't it be better for fix that by including asm/pgtable.h ?
Christophe
---
arch/powerpc/platforms/4xx/ocm.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/4xx/ocm.c b/arch/powerpc/platforms/4xx/ocm.c
index 561b09de69bf..04ff69ddac09 100644
--- a/arch/powerpc/platforms/4xx/ocm.c
+++ b/arch/powerpc/platforms/4xx/ocm.c
@@ -179,7 +179,8 @@ static void __init ocm_init_node(int count, struct
device_node *node)
/* ioremap the non-cached region */
if (ocm->nc.memtotal) {
ocm->nc.virt = __ioremap(ocm->nc.phys, ocm->nc.memtotal,
-_PAGE_EXEC | PAGE_KERNEL_NCG);
+ _PAGE_EXEC | _PAGE_BASE_NC |
+ _PAGE_KERNEL_RW | _PAGE_NO_CACHE | _PAGE_GUARDED);
if (!ocm->nc.virt) {
printk(KERN_ERR
@@ -194,7 +195,8 @@ static void __init ocm_init_node(int count, struct
device_node *node)
if (ocm->c.memtotal) {
ocm->c.virt = __ioremap(ocm->c.phys, ocm->c.memtotal,
- _PAGE_EXEC | PAGE_KERNEL);
+ _PAGE_EXEC | _PAGE_BASE |
+ _PAGE_KERNEL_RW);
if (!ocm->c.virt) {
printk(KERN_ERR
---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel
antivirus Avast.
https://www.avast.com/antivirus
[PATCH] powerpc/4xx/ocm: fix compiler error
This patch fixes a recent regression in ocm:
ocm.c: In function ‘ocm_init_node’:
ocm.c:182:18: error: invalid operands to binary |
ocm.c:197:17: error: invalid operands to binary |
Fixes: 56f3c1413f5c ("powerpc/mm: properly set PAGE_KERNEL flags in ioremap()")
Signed-off-by: Christian Lamparter
---
arch/powerpc/platforms/4xx/ocm.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/4xx/ocm.c b/arch/powerpc/platforms/4xx/ocm.c
index 561b09de69bf..04ff69ddac09 100644
--- a/arch/powerpc/platforms/4xx/ocm.c
+++ b/arch/powerpc/platforms/4xx/ocm.c
@@ -179,7 +179,8 @@ static void __init ocm_init_node(int count, struct
device_node *node)
/* ioremap the non-cached region */
if (ocm->nc.memtotal) {
ocm->nc.virt = __ioremap(ocm->nc.phys, ocm->nc.memtotal,
-_PAGE_EXEC | PAGE_KERNEL_NCG);
+ _PAGE_EXEC | _PAGE_BASE_NC |
+ _PAGE_KERNEL_RW | _PAGE_NO_CACHE | _PAGE_GUARDED);
if (!ocm->nc.virt) {
printk(KERN_ERR
@@ -194,7 +195,8 @@ static void __init ocm_init_node(int count, struct
device_node *node)
if (ocm->c.memtotal) {
ocm->c.virt = __ioremap(ocm->c.phys, ocm->c.memtotal,
- _PAGE_EXEC | PAGE_KERNEL);
+ _PAGE_EXEC | _PAGE_BASE |
+ _PAGE_KERNEL_RW);
if (!ocm->c.virt) {
printk(KERN_ERR
--
2.20.1
Re: [PATCH 00/11 v2] powerpc/fsl: NXP PowerPC Spectre variant 2 workarounds
Diana Craciun writes: > Implement Spectre variant 2 workarounds for NXP PowerPC Book3E > processors. > > Diana Craciun (11): > Add infrastructure to fixup branch predictor flush > Add macro to flush the branch predictor > Fix spectre_v2 mitigations reporting > Emulate SPRN_BUCSR register > Add nospectre_v2 command line argument > Flush the branch predictor at each kernel entry (64bit) > Flush the branch predictor at each kernel entry (32 bit) > Flush branch predictor when entering KVM > Enable runtime patching if nospectre_v2 boot arg is used > Update Spectre v2 reporting > Add FSL_PPC_BOOK3E as supported arch for nospectre_v2 boot arg Hi Diana, Sorry I already applied v1 a few days ago. I realise I didn't send out the "applied to next" emails, so my fault for that. Can you send me an incremental patch for the changes in v2? Thanks. cheers
Re: powerpc/xmon: fix dump_segments()
On Fri, 2018-11-16 at 17:31:08 UTC, Christophe Leroy wrote: > mfsrin() takes segment num from bits 0-3 > > Signed-off-by: Christophe Leroy Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/32c8c4c621897199e690760c2d5705 cheers
Re: powerpc/book3s/32: fix number of bats in p/v_block_mapped()
On Fri, 2018-11-16 at 17:27:42 UTC, Christophe Leroy wrote: > This patch fixes the loop in p_block_mapped() and v_block_mapped() > to scan the entire bat_addrs[] array. > > Signed-off-by: Christophe Leroy Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/e93ba1b7eb5b188c749052df7af1c9 cheers
Re: powerpc/mm: Eliminate not possible mmu features at compile time
On Fri, 2018-11-16 at 17:08:03 UTC, Christophe Leroy wrote: > Depending on the CONFIG selected, many of the MMU features are > not possible. Lets only get the possible ones in MMU_FTRS_POSSIBLE. > > This allows gcc to get rid at compile time of code related to > not possible features. > > Signed-off-by: Christophe Leroy Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/712877f8740471d96f703647d813d8 cheers
Re: [v2] powerpc/32: Avoid unsupported flags with clang
On Mon, 2018-11-12 at 05:28:06 UTC, Joel Stanley wrote:
> When building for ppc32 with clang these flags are unsupported:
>
> -ffixed-r2 and -mmultiple
>
> llvm's lib/Target/PowerPC/PPCRegisterInfo.cpp marks r2 as reserved on
> when building for SVR4ABI and !ppc64:
>
> // The SVR4 ABI reserves r2 and r13
> if (Subtarget.isSVR4ABI()) {
> // We only reserve r2 if we need to use the TOC pointer. If we have no
> // explicit uses of the TOC pointer (meaning we're a leaf function with
> // no constant-pool loads, etc.) and we have no potential uses inside an
> // inline asm block, then we can treat r2 has an ordinary callee-saved
> // register.
> const PPCFunctionInfo *FuncInfo = MF.getInfo();
> if (!TM.isPPC64() || FuncInfo->usesTOCBasePtr() || MF.hasInlineAsm())
> markSuperRegs(Reserved, PPC::R2); // System-reserved register
> markSuperRegs(Reserved, PPC::R13); // Small Data Area pointer register
> }
>
> This means we can safely omit -ffixed-r2 when building for 32-bit
> targets.
>
> The -mmultiple/-mno-multiple flags are not supported by clang, so
> platforms that might support multiple miss out on using multiple word
> instructions.
>
> We wrap these flags in cc-option so that when Clang gains support the
> kernel will be able use these flags.
>
> Clang 8 can then build a ppc44x_defconfig which boots in Qemu:
>
> make CC=clang-8 ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu-
> ppc44x_defconfig
> ./scripts/config -e CONFIG_DEVTMPFS -d DEVTMPFS_MOUNT
> make CC=clang-8 ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu-
>
> qemu-system-ppc -M bamboo \
>-kernel arch/powerpc/boot/zImage \
>-dtb arch/powerpc/boot/dts/bamboo.dtb \
>-initrd ~/ppc32-440-rootfs.cpio \
>-nographic -serial stdio -monitor pty -append "console=ttyS0"
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/261
> Link: https://bugs.llvm.org/show_bug.cgi?id=39556
> Link: https://bugs.llvm.org/show_bug.cgi?id=39555
> Signed-off-by: Joel Stanley
> Reviewed-by: Nick Desaulniers
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/72e7bcc2cdf82bf03caaa5e6c9b013
cheers
Re: [1/9] powerpc: simplify patch_instruction_site() and patch_branch_site()
On Fri, 2018-11-09 at 17:33:15 UTC, Christophe Leroy wrote: > Using patch_site_addr() helper, patch_instruction_site() and > patch_branch_site() can be simplified and inlined. > > Signed-off-by: Christophe Leroy Series applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/45090c26614fe991d9d5a2cd08e65c cheers
Re: powerpc: Add some documentation of ISA versions
On Mon, 2018-11-05 at 09:01:01 UTC, Michael Ellerman wrote: > Add some documentation on which CPU versions map to which ISA > versions. This is all publicly available information, some of it > already in the kernel source, but it's much nicer to have it all in > one place. > > Signed-off-by: Michael Ellerman Applied to powerpc next. https://git.kernel.org/powerpc/c/ec2adcd8dd64588cb4bcd1c1e0b863 cheers
Re: [v2] raid6/ppc: Fix build for clang
On Fri, 2018-11-02 at 00:44:55 UTC, Joel Stanley wrote: > We cannot build these files with clang as it does not allow altivec > instructions in assembly when -msoft-float is passed. > > Jinsong Ji wrote: > > We currently disable Altivec/VSX support when enabling soft-float. So > > any usage of vector builtins will break. > > > > Enable Altivec/VSX with soft-float may need quite some clean up work, so > > I guess this is currently a limitation. > > > > Removing -msoft-float will make it work (and we are lucky that no > > floating point instructions will be generated as well). > > This is a workaround until the issue is resolved in clang. > > Link: https://bugs.llvm.org/show_bug.cgi?id=31177 > Link: https://github.com/ClangBuiltLinux/linux/issues/239 > Signed-off-by: Joel Stanley > Reviewed-by: Nick Desaulniers Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/e213574a449f7a57d4202c1869bbc7 cheers
Re: powerpc/mm: remove unused variable
On Thu, 2018-10-18 at 05:22:06 UTC, Christophe Leroy wrote: > In file included from ./include/linux/hugetlb.h:445:0, > from arch/powerpc/kernel/setup-common.c:37: > ./arch/powerpc/include/asm/hugetlb.h: In function > âÂÂhuge_ptep_clear_flushâÂÂ: > ./arch/powerpc/include/asm/hugetlb.h:154:8: error: variable âÂÂpteâ > set but not used [-Werror=unused-but-set-variable] > > Signed-off-by: Christophe Leroy Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/584dbc7727a22459dfcb6e4c9faef6 cheers
Re: [NEXT,v2,3/4] powerpc/pasemi: Add Nemo board device init code.
On Sun, 2018-08-19 at 20:23:57 UTC, Darren Stevens wrote: > Add routines for Nemo specific devices to init at boot time, these > being board level power-off and SB600's rtc. > > Also add a run time variable to prevent these being activated > if we boot on a reference board. > > Signed-off-by: Darren Stevens Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/656fdf3ad8e0ae4c6c3d75af373df6 cheers
Re: [NEXT,v2,2/4] powerpc/pasemi: Add Nemo board IRQ initroutine
On Sun, 2018-08-19 at 20:21:47 UTC, Darren Stevens wrote: > Add a IRQ init routine for the Nemo board which inits and attatches > the i8259 found in the SB600, and a cascade routine to dispatch the > interrupts. > > Signed-off-by: Darren Stevens Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/0428a5f494a003c98c1d1fc98aae60 cheers
Re: [NEXT, v2, 1/4] powerpc/pasemi: Add PCI initialisation for Nemo board.
On Sun, 2018-08-19 at 20:21:55 UTC, Darren Stevens wrote: > The A-Eon Amigaone X1000's Nemo motherboard has an AMD SB600 > connected to one of the PCI-e root ports on its PaSemi > Pwrficient 1628M SoC. Normally the SB600 southbridge would be > connected to a hidden PCI-e port on the system's northbridge, > and as a result doesn't fully comply with the PCI-e spec. > > Add code to relax the PCI-e detection in both the root port > and the Linux kernel allowing on board devices to be detected. > > Signed-off-by: Darren Stevens Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/68f211a4d1e5882e881bbb84b65059 cheers
Re: [NEXT,v2,2/4] powerpc/pasemi: Add Nemo board IRQ initroutine
On Sun, 2018-08-19 at 20:21:47 UTC, Darren Stevens wrote: > Add a IRQ init routine for the Nemo board which inits and attatches > the i8259 found in the SB600, and a cascade routine to dispatch the > interrupts. > > Signed-off-by: Darren Stevens Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/51f4cc2047a4b7e9bf1b49acf06c11 cheers
Re: [1/2] powerpc/perf: Add constraints for power9 l2/l3 bus events
On Sun, 2018-06-10 at 14:27:01 UTC, Madhavan Srinivasan wrote:
> In previous generation processors, both bus events and direct
> events of performance monitoring unit can be individually
> programmabled and monitored in PMCs.
>
> But in Power9, L2/L3 bus events are always available as a
> "bank" of 4 events. To obtain the counts for any of the
> l2/l3 bus events in a given bank, the user will have to
> program PMC4 with corresponding l2/l3 bus event for that
> bank.
>
> Patch enforce two contraints incase of L2/L3 bus events.
>
> 1)Any L2/L3 event when programmed is also expected to program corresponding
> PMC4 event from that group.
> 2)PMC4 event should always been programmed first due to group constraint
> logic limitation
>
> For ex. consider these L3 bus events
>
> PM_L3_PF_ON_CHIP_MEM (0x460A0),
> PM_L3_PF_MISS_L3 (0x160A0),
> PM_L3_CO_MEM (0x260A0),
> PM_L3_PF_ON_CHIP_CACHE (0x360A0),
>
> 1) This is an INVALID group for L3 Bus event monitoring,
> since it is missing PMC4 event.
> perf stat -e "{r160A0,r260A0,r360A0}" < >
>
> And this is a VALID group for L3 Bus events:
> perf stat -e "{r460A0,r160A0,r260A0,r360A0}" < >
>
> 2) This is an INVALID group for L3 Bus event monitoring,
> since it is missing PMC4 event.
> perf stat -e "{r260A0,r360A0}" < >
>
> And this is a VALID group for L3 Bus events:
> perf stat -e "{r460A0,r260A0,r360A0}" < >
>
> 3) This is an INVALID group for L3 Bus event monitoring,
> since it is missing PMC4 event.
> perf stat -e "{r360A0}" < >
>
> And this is a VALID group for L3 Bus events:
> perf stat -e "{r460A0,r360A0}" < >
>
> Patch here implements group constraint logic suggested by Michael Ellerman.
>
> Signed-off-by: Madhavan Srinivasan
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/59029136d75022cb8b7c7bebd1738a
cheers
Re: [v2,1/2] powerpc/perf: Cleanup cache_sel bits comment
On Mon, 2017-10-09 at 14:12:39 UTC, Madhavan Srinivasan wrote: > Update the raw event code comment in power9-pmu.c with respect to > "cache" bits, since power9 MMCRC does not support these. > > Signed-off-by: Madhavan Srinivasan Series applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/8c31459d6138b07537346d976e7c30 cheers
Re: [-next] powerpc/eeh: Fix debugfs_simple_attr.cocci warnings
On Thu, 2018-12-20 at 02:42:51 UTC, YueHaibing wrote: > Use DEFINE_DEBUGFS_ATTRIBUTE rather than DEFINE_SIMPLE_ATTRIBUTE > for debugfs files. > > Semantic patch information: > Rationale: DEFINE_SIMPLE_ATTRIBUTE + debugfs_create_file() > imposes some significant overhead as compared to > DEFINE_DEBUGFS_ATTRIBUTE + debugfs_create_file_unsafe(). > > Generated by: scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci > > Signed-off-by: YueHaibing > Acked-by: Russell Currey Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/8c6c942d33f2a79439e86f8f406afa cheers
Re: [v3] powerpc: implement CONFIG_DEBUG_VIRTUAL
On Tue, 2018-12-11 at 22:40:53 UTC, Christophe Leroy wrote: > This patch implements CONFIG_DEBUG_VIRTUAL to warn about > incorrect use of virt_to_phys() and page_to_phys() > > Below is the result of test_debug_virtual: > > [1.438746] WARNING: CPU: 0 PID: 1 at ./arch/powerpc/include/asm/io.h:808 > test_debug_virtual_init+0x3c/0xd4 > [1.448156] CPU: 0 PID: 1 Comm: swapper Not tainted > 4.20.0-rc5-00560-g6bfb52e23a00-dirty #532 > [1.457259] NIP: c066c550 LR: c0650ccc CTR: c066c514 > [1.462257] REGS: c900bdb0 TRAP: 0700 Not tainted > (4.20.0-rc5-00560-g6bfb52e23a00-dirty) > [1.471184] MSR: 00029032 CR: 48000422 XER: 2000 > [1.477811] > [1.477811] GPR00: c0650ccc c900be60 c60d 006000c0 c900 > 9032 c7fa0020 > [1.477811] GPR08: 2400 0001 0900 c07b5d04 > c00037d8 > [1.477811] GPR16: c076 c074 > 0092 c0685bb0 > [1.477811] GPR24: c065042c c068a734 c0685b8c 0006 c076 > c075c3c0 > [1.512711] NIP [c066c550] test_debug_virtual_init+0x3c/0xd4 > [1.518315] LR [c0650ccc] do_one_initcall+0x8c/0x1cc > [1.523163] Call Trace: > [1.525595] [c900be60] [c0567340] 0xc0567340 (unreliable) > [1.530954] [c900be90] [c0650ccc] do_one_initcall+0x8c/0x1cc > [1.536551] [c900bef0] [c0651000] kernel_init_freeable+0x1f4/0x2cc > [1.542658] [c900bf30] [c00037ec] kernel_init+0x14/0x110 > [1.547913] [c900bf40] [c000e1d0] ret_from_kernel_thread+0x14/0x1c > [1.553971] Instruction dump: > [1.556909] 3ca50100 bfa10024 54a5000e 3fa0c076 7c0802a6 3d454000 813dc204 > 554893be > [1.564566] 7d294010 7d294910 90010034 39290001 <0f09> 7c3e0b78 > 955e0008 3fe0c062 > [1.572425] ---[ end trace 6f6984225b280ad6 ]--- > [1.577467] PA: 0x0900 for VA: 0xc900 > [1.581799] PA: 0x061e8f50 for VA: 0xc61e8f50 > > Signed-off-by: Christophe Leroy Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/6bf752daca07c85c181159f75dcf65 cheers
Re: powerpc/prom: move the device tree if not in declared memory.
On Mon, 2018-12-17 at 14:18:27 UTC, Christophe Leroy wrote: > If the device tree doesn't reside in the memory which is declared > inside it, it has to be moved as well as this memory will not be > mapped by the kernel. > > Signed-off-by: Christophe Leroy Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/f242e0ac95cadb27527d0b06c95772 cheers
Re: ocxl: Fix endiannes bug in ocxl_link_update_pe()
On Sun, 2018-12-16 at 21:28:50 UTC, Greg Kurz wrote:
> All fields in the PE are big-endian. Use cpu_to_be32() like everywhere
> else something is written to the PE. Otherwise a wrong TID will be used
> by the NPU. If this TID happens to point to an existing thread sharing
> the same mm, it could be woken up by error. This is highly improbable
> though. The likely outcome of this is the NPU not finding the target
> thread and forcing the AFU into sending an interrupt, which userspace
> is supposed to handle anyway.
>
> Fixes: e948e06fc63a ("ocxl: Expose the thread_id needed for wait on POWER9")
> Cc: sta...@vger.kernel.org # v4.18
> Signed-off-by: Greg Kurz
> Acked-by: Andrew Donnellan
> Reviewed-by: Alastair D'Silva
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/e1e71e201703500f708bdeaf64660a
cheers
Re: powerpc/ptrace: cleanup do_syscall_trace_enter
On Sun, 2018-12-16 at 17:28:28 UTC, "Dmitry V. Levin" wrote: > Invoke tracehook_report_syscall_entry once. > > Signed-off-by: Dmitry V. Levin Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/8dbdec0bcb416d0ef0bfd737620d08 cheers
Re: [1/8] powerpc: allow NOT_COHERENT_CACHE for amigaone
On Sun, 2018-12-16 at 17:19:44 UTC, Christoph Hellwig wrote: > AMIGAONE selects NOT_COHERENT_CACHE, so we better allow it. > > Signed-off-by: Christoph Hellwig Series applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/9286356907caa2d4737bd9dd8afe0b cheers
Re: powerpc: use mm zones more sensibly
On Sun, 2018-12-16 at 16:53:49 UTC, Christoph Hellwig wrote: > Powerpc has somewhat odd usage where ZONE_DMA is used for all memory on > common 64-bit configfs, and ZONE_DMA32 is used for 31-bit schemes. > > Move to a scheme closer to what other architectures use (and I dare to > say the intent of the system): > > - ZONE_DMA: optionally for memory < 31-bit (64-bit embedded only) > - ZONE_NORMAL: everything addressable by the kernel > - ZONE_HIGHMEM: memory > 32-bit for 32-bit kernels > > Also provide information on how ZONE_DMA is used by defining > ARCH_ZONE_DMA_BITS. > > Contains various fixes from Benjamin Herrenschmidt. > > Signed-off-by: Christoph Hellwig Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/25078dc1f74be16b858e914f52cc8f cheers
Re: [v2] powerpc/mm: make NULL pointer deferences explicit on bad page faults.
On Fri, 2018-12-14 at 15:23:33 UTC, Christophe Leroy wrote: > As several other arches including x86, this patch makes it explicit > that a bad page fault is a NULL pointer dereference when the fault > address is lower than PAGE_SIZE > > In the mean time, this page makes all bad_page_fault() messages shorter > so that they remain on one single line. And it prefixes them by "BUG: " > so that they get easily greped. > > Signed-off-by: Christophe Leroy Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/49a502ea23bf9dec47f8f3c3960909 cheers
Re: powerpc/configs: Don't enable PPC_EARLY_DEBUG in defconfigs
On Fri, 2018-12-14 at 13:57:11 UTC, Michael Ellerman wrote:
> This reverts the remains of commit b9ef7d6b11c1 ("powerpc: Update
> default configurations").
>
> That commit was proceeded by a commit which added a config option to
> control use of BOOTX for early debug, ie. PPC_EARLY_DEBUG_BOOTX, and
> then the update of the defconfigs was intended to not change behaviour
> by then enabling the new config option.
>
> However enabling PPC_EARLY_DEBUG had other consequences, notably
> causing us to register the udbg console at the end of udbg_early_init().
>
> This means on a system which doesn't have anything that BOOTX can
> use (most systems), we register the udbg console very early but the
> bootx code just throws everything away, meaning early boot messages
> are never printed to the console.
>
> What we want to happen is for the udbg console to only be registered
> later (from setup_arch()) once we've setup udbg_putc, and then all
> early boot messages will be replayed.
>
> Fixes: b9ef7d6b11c1 ("powerpc: Update default configurations")
> Reported-by: Torsten Duwe
> Signed-off-by: Michael Ellerman
Applied to powerpc next.
https://git.kernel.org/powerpc/c/2b874a5c7b75fdc90fdd1e2ffaa3ec
cheers
Re: [v2] powerpc/prom: fix early DEBUG messages
On Fri, 2018-12-14 at 10:27:47 UTC, Christophe Leroy wrote: > This patch fixes early DEBUG messages in prom.c: > - Use %px instead of %p to see the addresses > - Cast memblock_phys_mem_size() with (unsigned long long) to > avoid build failure when phys_addr_t is not 64 bits. > > Signed-off-by: Christophe Leroy Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/b18f0ae92b0a1db565c3e505fa87b6 cheers
Re: [01/11] powerpc/fsl: Add infrastructure to fixup branch predictor flush
On Wed, 2018-12-12 at 14:03:00 UTC, Diana Craciun wrote: > In order to protect against speculation attacks (Spectre > variant 2) on NXP PowerPC platforms, the branch predictor > should be flushed when the privillege level is changed. > This patch is adding the infrastructure to fixup at runtime > the code sections that are performing the branch predictor flush > depending on a boot arg parameter which is added later in a > separate patch. > > Signed-off-by: Diana Craciun Series applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/76a5eaa38b15dda92cd6964248c39b cheers
Re: powerpc/44x/bamboo: Fix PCI range
On Tue, 2018-12-11 at 02:27:33 UTC, Benjamin Herrenschmidt wrote: > >From 88509506b80b4960004146280eb740be64513a0b Mon Sep 17 00:00:00 2001 > The bamboo dts has a bug: it uses a non-naturally aligned range > for PCI memory space. This isnt' supported by the code, thus > causing PCI to break on this system. > > This is due to the fact that while the chip memory map has 1G > reserved for PCI memory, it's only 512M aligned. The code doesn't > know how to split that into 2 different PMMs and fails, so limit > the region to 512M. > > Signed-off-by: Benjamin Herrenschmidt Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/3cfb9ebe906b51f2942b1e251009bb cheers
Re: powerpc: eeh_event: convert semaphore to completion
On Mon, 2018-12-10 at 21:51:57 UTC, Arnd Bergmann wrote: > For this use case, completions and semaphores are equivalent, > but semaphores are an awkward interface that should generally > be avoided, so use the completion instead. > > Signed-off-by: Arnd Bergmann Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/2fea82db113e4422ef5c8e62099088 cheers
Re: ocxl/afu_irq: Don't include
On Mon, 2018-12-10 at 15:13:38 UTC, Greg Kurz wrote: > The AFU irq code doesn't need to reach out to the platform. > > Signed-off-by: Greg Kurz > Acked-by: Andrew Donnellan Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/d1f75a96842b265ca2a89b7ed477a5 cheers
Re: ocxl: Clarify error path in setup_xsl_irq()
On Mon, 2018-12-10 at 15:18:13 UTC, Greg Kurz wrote: > Implementing rollback with goto and labels is a common practice that > leads to prettier and more maintainable code. FWIW, this design pattern > is already being used in alloc_link() a few lines below in this file. > > Do the same in setup_xsl_irq(). > > Signed-off-by: Greg Kurz > Acked-by: Frederic Barrat > Acked-by: Andrew Donnellan Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/759bc01586535700fbb1aaf40dd727 cheers
Re: powerpc/mm: define an empty slice_init_new_context_exec()
On Mon, 2018-12-10 at 12:23:05 UTC, Christophe Leroy wrote: > Define slice_init_new_context_exec() at all time to avoid > > Signed-off-by: Christophe Leroy Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/badb9687cec50bdba59746532de196 cheers
Re: lib: fix build failure in CONFIG_DEBUG_VIRTUAL test
On Mon, 2018-12-10 at 08:08:28 UTC, Christophe Leroy wrote:
> On several arches, virt_to_phys() is in io.h
>
> Build fails without it:
>
> CC lib/test_debug_virtual.o
> lib/test_debug_virtual.c: In function 'test_debug_virtual_init':
> lib/test_debug_virtual.c:26:7: error: implicit declaration of function
> 'virt_to_phys' [-Werror=implicit-function-declaration]
> pa = virt_to_phys(va);
>^
>
> Fixes: e4dace361552 ("lib: add test module for CONFIG_DEBUG_VIRTUAL")
> CC: sta...@vger.kernel.org
> Signed-off-by: Christophe Leroy
> Reviewed-by: Kees Cook
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/10fdf838e5f540beca466e9d132599
cheers
Re: [v3] powerpc/uaccess: fix warning/error with access_ok()
On Mon, 2018-12-10 at 06:50:09 UTC, Christophe Leroy wrote:
> With the following piece of code, the following compilation warning
> is encountered:
>
> if (_IOC_DIR(ioc) != _IOC_NONE) {
> int verify = _IOC_DIR(ioc) & _IOC_READ ? VERIFY_WRITE :
> VERIFY_READ;
>
> if (!access_ok(verify, ioarg, _IOC_SIZE(ioc))) {
>
> drivers/platform/test/dev.c: In function 'my_ioctl':
> drivers/platform/test/dev.c:219:7: warning: unused variable 'verify'
> [-Wunused-variable]
>int verify = _IOC_DIR(ioc) & _IOC_READ ? VERIFY_WRITE : VERIFY_READ;
>
> This patch fixes it by referencing 'type' in the macro allthough
> doing nothing with it.
>
> Signed-off-by: Christophe Leroy
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/05a4ab823983d9136a460b7b5e0d49
cheers
Re: [v2, 1/2] powerpc/perf: Update perf_regs structure to include SIER
On Sun, 2018-12-09 at 09:25:35 UTC, Madhavan Srinivasan wrote: > On each sample, Sample Instruction Event Register (SIER) content > is saved in pt_regs. SIER does not have a entry as-is in the pt_regs > but instead, SIER content is saved in the "dar" register of pt_regs. > > Patch adds another entry to the perf_regs structure to include the "SIER" > printing which internally maps to the "dar" of pt_regs. > > It also check for the SIER availability in the platform and present > value accordingly > > Signed-off-by: Madhavan Srinivasan Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/333804dc3b7a92158ab63a48febff0 cheers
Re: powerpc/perf: Fix thersholding counter data for unknown type
On Sun, 2018-12-09 at 09:18:15 UTC, Madhavan Srinivasan wrote:
> MMCRA[34:36] and MMCRA[38:44] expose the thresholding counter value.
> Thresholding counter can be used to count latency cycles such as
> load miss to reload. But threshold counter value is not relevant
> when the sampled instruction type is unknown or reserved. Patch to
> fix the thersholding counter value to zero when sampled instruction
> type is unknown or reserved.
>
> Fixes: 170a315f41c6('powerpc/perf: Support to export MMCRA[TEC*] field to
> userspace')
> Signed-off-by: Madhavan Srinivasan
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/17cfccc91545682513541924245abb
cheers
Re: [v2] powerpc/ipic: Remove unused ipic_set_priority()
On Thu, 2018-12-06 at 06:58:59 UTC, Michael Ellerman wrote:
> ipic_set_priority() has been unused since 2006 when the last usage was
> removed in commit b9f0f1bb2bca ("[POWERPC] Adapt ipic driver to new
> host_ops interface, add set_irq_type to set IRQ sense").
>
> Reported-by: Dan Carpenter
> Signed-off-by: Michael Ellerman
Applied to powerpc next.
https://git.kernel.org/powerpc/c/c7e900c05b8f10894b649bdae50cf5
cheers
Re: [v2] powerpc/32: Move the old 6xx -mcpu logic before the TARGET_CPU logic
On Wed, 2018-12-05 at 17:53:55 UTC, Mathieu Malaterre wrote:
> The code:
>
> ifdef CONFIG_6xx
> KBUILD_CFLAGS += -mcpu=powerpc
> endif
>
> was added in 2006 in commit f48b8296b315 ("[PATCH] powerpc32: Set cpu
> explicitly in kernel compiles"). This change was acceptable since the
> TARGET_CPU logic was 64-bit only.
>
> Since commit 0e00a8c9fd92 ("powerpc: Allow CPU selection
> also on PPC32") this logic is no longer acceptable after the TARGET_CPU
> specific. It currently appends -mcpu=powerpc at the end of the command
> line, after any TARGET_CPU specific:
>
> gcc -Wp,-MD,init/.do_mounts.o.d ...
> -mcpu=powerpc -mbig-endian -m32 ...
> -mcpu=e300c2 ...
> -mcpu=powerpc ...
> ../init/do_mounts.c
>
> Cc: Christophe Leroy
> Fixes: 0e00a8c9fd92 ("powerpc: Allow CPU selection also on PPC32")
> Suggested-by: Michael Ellerman
> Link:
> https://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg142315.html
> Signed-off-by: Mathieu Malaterre
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/ebd1d3b74f8542a8f3bb80b453692d
cheers
Re: powerpc: remove remaining bits from CONFIG_APUS
On Tue, 2018-12-04 at 17:59:15 UTC, Christophe Leroy wrote:
> commit f21f49ea639a ("[POWERPC] Remove the dregs of APUS support from
> arch/powerpc") removed CONFIG_APUS, but forgot to remove the logic
> which adapts tophys() and tovirt() for it.
>
> This patch removes the last stale pieces.
>
> Signed-off-by: Christophe Leroy
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/c62ce9ef97ba8af4120c766c32e230
cheers
Re: [v3] powerpc/mm: add exec protection on powerpc 603
On Wed, 2018-11-28 at 17:21:10 UTC, Christophe Leroy wrote: > The 603 doesn't have a HASH table, TLB misses are handled by > software. It is then possible to generate page fault when > _PAGE_EXEC is not set like in nohash/32. > > There is one "reserved" PTE bit available, this patch uses > it for _PAGE_EXEC. > > In order to support it, set_pte_filter() and > set_access_flags_filter() are made common, and the handling > is made dependent on MMU_FTR_HPTE_TABLE > > Signed-off-by: Christophe Leroy > Reviewed-by: Aneesh Kumar K.V Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/385e89d5b20f5a7c33fd7c1904da0e cheers
Re: powerpc/8xx: add exception frame marker
On Tue, 2018-11-27 at 17:38:16 UTC, Christophe Leroy wrote: > This patch adds STACK_FRAME_REGS_MARKER in the stack at exception entry > in order to see interrupts in call traces as below: > > [0.013964] Call Trace: > [0.014014] [c0745db0] [c007a9d4] tick_periodic.constprop.5+0xd8/0x104 > (unreliable) > [0.014086] [c0745dc0] [c007aa20] tick_handle_periodic+0x20/0x9c > [0.014181] [c0745de0] [c0009cd0] timer_interrupt+0xa0/0x264 > [0.014258] [c0745e10] [c000e484] ret_from_except+0x0/0x14 > [0.014390] --- interrupt: 901 at console_unlock.part.7+0x3f4/0x528 > [0.014390] LR = console_unlock.part.7+0x3f0/0x528 > [0.014455] [c0745ee0] [c0050334] console_unlock.part.7+0x114/0x528 > (unreliable) > [0.014542] [c0745f30] [c00524e0] register_console+0x3d8/0x44c > [0.014625] [c0745f60] [c0675aac] cpm_uart_console_init+0x18/0x2c > [0.014709] [c0745f70] [c06614f4] console_init+0x114/0x1cc > [0.014795] [c0745fb0] [c0658b68] start_kernel+0x300/0x3d8 > [0.014864] [c0745ff0] [c00022cc] start_here+0x44/0x98 > > Signed-off-by: Christophe Leroy Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/0ed5b55884f8b1fa368454d47cc6ec cheers
Re: powerpc/mm/hash: Hand user access of kernel address gracefully
On Mon, 2018-11-26 at 14:35:04 UTC, "Aneesh Kumar K.V" wrote:
> With commit 2865d08dd9ea ("powerpc/mm: Move the DSISR_PROTFAULT sanity check")
> we moved the protection fault access check before vma lookup. That means we
> hit that WARN_ON when user space access a kernel address. Before the commit
> this was handled by find_vma() not finding vma for the kernel address and
> considering that access as bad area access.
>
> Avoid the confusing WARN_ON and convert that to a ratelimited printk.
> With the patch we now get
>
> for load:
> [ 187.700294] a.out[5997]: User access of kernel address (c000dea0)
> - exploit attempt? (uid: 1000)
> [ 187.700344] a.out[5997]: segfault (11) at c000dea0 nip 1317c0798
> lr 7fff80d6441c code 1 in a.out[1317c+1]
> [ 187.700429] a.out[5997]: code: 6000 6042 3c4c0002 38427790
> 4b20 3c4c0002 38427784 fbe1fff8
> [ 187.700435] a.out[5997]: code: f821ffc1 7c3f0b78 6000 e9228030
> <8929> 993f002f 6000 383f0040
>
> for exec:
> [ 225.100903] a.out[6067]: User access of kernel address (c000dea0)
> - exploit attempt? (uid: 1000)
> [ 225.100938] a.out[6067]: segfault (11) at c000dea0 nip
> c000dea0 lr 129d507b0 code 1
> [ 225.100943] a.out[6067]: Bad NIP, not dumping instructions.
>
> Fixes: 2865d08dd9ea ("powerpc/mm: Move the DSISR_PROTFAULT sanity check")
> Signed-off-by: Aneesh Kumar K.V
> Tested-by: Breno Leitao
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/374f3f5979f9b28bfb5b5799208d82
cheers
Re: [for-next][PATCH 05/24] powerpc/frace: Use ftrace_graph_get_ret_stack() instead of curr_ret_stack
Steven Rostedt writes: > From: "Steven Rostedt (VMware)" > > The structure of the ret_stack array on the task struct is going to > change, and accessing it directly via the curr_ret_stack index will no > longer give the ret_stack entry that holds the return address. To access > that, architectures must now use ftrace_graph_get_ret_stack() to get the > associated ret_stack that matches the saved return address. > > Cc: Benjamin Herrenschmidt > Cc: Paul Mackerras > Cc: Michael Ellerman > Cc: linuxppc-dev@lists.ozlabs.org > Signed-off-by: Steven Rostedt (VMware) > --- > arch/powerpc/kernel/process.c | 13 + > 1 file changed, 9 insertions(+), 4 deletions(-) I did test the previous series you posted and I think everything was OK running the ftracetest suite (I got one or two fails but I think that was because of missing CONFIG options). Acked-by: Michael Ellerman (powerpc) cheers
Re: [PATCH] soc: fsl: guts: us devm_kstrdup_const() for RO data
On Fri, Dec 21, 2018 at 08:29:56PM -0600, Scott Wood wrote: > On Fri, 2018-12-07 at 09:22 +0100, Nicholas Mc Guire wrote: > > devm_kstrdup() may return NULL if internal allocation failed, but > > as machine is from the device tree, and thus RO, devm_kstrdup_const() > > can be used here, which will only copy the reference. > > Is it really going to only copy the reference? That would require that > is_kernel_rodata(machine) be true, which it shouldn't be since it's not part > of the kernel image. > I had tried to figure out what is RO and what not but was not able to determine that - from the discussion it seemed that the assumption of RO is correct though I did not ask if it would satisfy is_kernel_rodata() so that explains the incorrect assertion. see https://lkml.org/lkml/2018/12/6/42 So then the only option is to check the return and cleanup on allocation failure as the orriginal patch proposed. thanks for clearifying this ! hofrat
