Re: [PATCH] powerpc/tm: Save and restore AMR on treclaim and trechkpt

[Aneesh Kumar K.V]

On 9/18/20 9:35 AM, Gustavo Romero wrote:

Althought AMR is stashed on the checkpoint area, currently we don't save
it to the per thread checkpoint struct after a treclaim and so we don't
restore it either from that struct when we trechkpt. As a consequence when
the transaction is later rolled back kernel space AMR value when the
trechkpt was done appears in userspace.

That commit saves and restores AMR accordingly on treclaim and trechkpt.
Since AMR value is also used in kernel space in other functions, it also
takes care of stashing kernel live AMR into PACA before treclaim and before
trechkpt, restoring it later, just before returning from tm_reclaim and
__tm_recheckpoint.

Is also fixes two nonrelated comments about CR and MSR.

Signed-off-by: Gustavo Romero 
---
  arch/powerpc/include/asm/paca.h  |  1 +
  arch/powerpc/include/asm/processor.h |  1 +
  arch/powerpc/kernel/asm-offsets.c|  2 ++
  arch/powerpc/kernel/tm.S | 31 +++-
  4 files changed, 30 insertions(+), 5 deletions(-)

diff --git a/arch/powerpc/include/asm/paca.h b/arch/powerpc/include/asm/paca.h
index 9454d29ff4b4..44c605181529 100644
--- a/arch/powerpc/include/asm/paca.h
+++ b/arch/powerpc/include/asm/paca.h
@@ -179,6 +179,7 @@ struct paca_struct {
u64 sprg_vdso;  /* Saved user-visible sprg */
  #ifdef CONFIG_PPC_TRANSACTIONAL_MEM
u64 tm_scratch; /* TM scratch area for reclaim */
+   u64 tm_amr; /* Saved Kernel AMR for 
treclaim/trechkpt */
  #endif
  
  #ifdef CONFIG_PPC_POWERNV

diff --git a/arch/powerpc/include/asm/processor.h 
b/arch/powerpc/include/asm/processor.h
index ed0d633ab5aa..9f4f6cc033ac 100644
--- a/arch/powerpc/include/asm/processor.h
+++ b/arch/powerpc/include/asm/processor.h
@@ -220,6 +220,7 @@ struct thread_struct {
unsigned long   tm_tar;
unsigned long   tm_ppr;
unsigned long   tm_dscr;
+   unsigned long   tm_amr;
  
  	/*

 * Checkpointed FP and VSX 0-31 register set.
diff --git a/arch/powerpc/kernel/asm-offsets.c 
b/arch/powerpc/kernel/asm-offsets.c
index 8711c2164b45..cf1a6d68a91f 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -170,12 +170,14 @@ int main(void)
  
  #ifdef CONFIG_PPC_TRANSACTIONAL_MEM

OFFSET(PACATMSCRATCH, paca_struct, tm_scratch);
+   OFFSET(PACATMAMR, paca_struct, tm_amr);
OFFSET(THREAD_TM_TFHAR, thread_struct, tm_tfhar);
OFFSET(THREAD_TM_TEXASR, thread_struct, tm_texasr);
OFFSET(THREAD_TM_TFIAR, thread_struct, tm_tfiar);
OFFSET(THREAD_TM_TAR, thread_struct, tm_tar);
OFFSET(THREAD_TM_PPR, thread_struct, tm_ppr);
OFFSET(THREAD_TM_DSCR, thread_struct, tm_dscr);
+   OFFSET(THREAD_TM_AMR, thread_struct, tm_amr);
OFFSET(PT_CKPT_REGS, thread_struct, ckpt_regs);
OFFSET(THREAD_CKVRSTATE, thread_struct, ckvr_state.vr);
OFFSET(THREAD_CKVRSAVE, thread_struct, ckvrsave);
diff --git a/arch/powerpc/kernel/tm.S b/arch/powerpc/kernel/tm.S
index 6ba0fdd1e7f8..e178ddb43619 100644
--- a/arch/powerpc/kernel/tm.S
+++ b/arch/powerpc/kernel/tm.S
@@ -152,6 +152,10 @@ _GLOBAL(tm_reclaim)
li  r5, 0
mtmsrd  r5, 1
  
+/* Save AMR since it's used elsewhere in kernel space */

+   mfspr   r8, SPRN_AMR
+   std r8, PACATMAMR(r13)



Can we save this in stack instead of PACA?



+
/*
 * BE CAREFUL HERE:
 * At this point we can't take an SLB miss since we have MSR_RI
@@ -245,7 +249,7 @@ _GLOBAL(tm_reclaim)
 * but is used in signal return to 'wind back' to the abort handler.
 */
  
-	/*  CR,LR,CCR,MSR ** */

+   /* * CTR, LR, CR, XER ** */
mfctr   r3
mflrr4
mfcrr5
@@ -256,7 +260,6 @@ _GLOBAL(tm_reclaim)
std r5, _CCR(r7)
std r6, _XER(r7)
  
-

/*  TAR, DSCR ** */
mfspr   r3, SPRN_TAR
mfspr   r4, SPRN_DSCR
@@ -264,6 +267,10 @@ _GLOBAL(tm_reclaim)
std r3, THREAD_TM_TAR(r12)
std r4, THREAD_TM_DSCR(r12)
  
+/*  AMR  */

+mfspr  r3, SPRN_AMR
+stdr3, THREAD_TM_AMR(r12)
+
/*
 * MSR and flags: We don't change CRs, and we don't need to alter MSR.
 */
@@ -308,8 +315,6 @@ _GLOBAL(tm_reclaim)
std r3, THREAD_TM_TFHAR(r12)
std r4, THREAD_TM_TFIAR(r12)
  
-	/* AMR is checkpointed too, but is unsupported by Linux. */

-
/* Restore original MSR/IRQ state & clear TM mode */
ld  r14, TM_FRAME_L0(r1)/* Orig MSR */
  
@@ -330,6 +335,10 @@ _GLOBAL(tm_reclaim)

ld  r0, PACA_DSCR_DEFAULT(r13)
mtspr   SPRN_DSCR, r0
  
+/* Restore kernel saved AMR */

+   ld  r4, PACATMAMR(r13)
+   mtspr   SPRN_AMR, r4
+
blr
  
  
@@ -355,6 

[PATCH] powerpc/tm: Save and restore AMR on treclaim and trechkpt

[Gustavo Romero]

Althought AMR is stashed on the checkpoint area, currently we don't save
it to the per thread checkpoint struct after a treclaim and so we don't
restore it either from that struct when we trechkpt. As a consequence when
the transaction is later rolled back kernel space AMR value when the
trechkpt was done appears in userspace.

That commit saves and restores AMR accordingly on treclaim and trechkpt.
Since AMR value is also used in kernel space in other functions, it also
takes care of stashing kernel live AMR into PACA before treclaim and before
trechkpt, restoring it later, just before returning from tm_reclaim and
__tm_recheckpoint.

Is also fixes two nonrelated comments about CR and MSR.

Signed-off-by: Gustavo Romero 
---
 arch/powerpc/include/asm/paca.h  |  1 +
 arch/powerpc/include/asm/processor.h |  1 +
 arch/powerpc/kernel/asm-offsets.c|  2 ++
 arch/powerpc/kernel/tm.S | 31 +++-
 4 files changed, 30 insertions(+), 5 deletions(-)

diff --git a/arch/powerpc/include/asm/paca.h b/arch/powerpc/include/asm/paca.h
index 9454d29ff4b4..44c605181529 100644
--- a/arch/powerpc/include/asm/paca.h
+++ b/arch/powerpc/include/asm/paca.h
@@ -179,6 +179,7 @@ struct paca_struct {
u64 sprg_vdso;  /* Saved user-visible sprg */
 #ifdef CONFIG_PPC_TRANSACTIONAL_MEM
u64 tm_scratch; /* TM scratch area for reclaim */
+   u64 tm_amr; /* Saved Kernel AMR for 
treclaim/trechkpt */
 #endif
 
 #ifdef CONFIG_PPC_POWERNV
diff --git a/arch/powerpc/include/asm/processor.h 
b/arch/powerpc/include/asm/processor.h
index ed0d633ab5aa..9f4f6cc033ac 100644
--- a/arch/powerpc/include/asm/processor.h
+++ b/arch/powerpc/include/asm/processor.h
@@ -220,6 +220,7 @@ struct thread_struct {
unsigned long   tm_tar;
unsigned long   tm_ppr;
unsigned long   tm_dscr;
+   unsigned long   tm_amr;
 
/*
 * Checkpointed FP and VSX 0-31 register set.
diff --git a/arch/powerpc/kernel/asm-offsets.c 
b/arch/powerpc/kernel/asm-offsets.c
index 8711c2164b45..cf1a6d68a91f 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -170,12 +170,14 @@ int main(void)
 
 #ifdef CONFIG_PPC_TRANSACTIONAL_MEM
OFFSET(PACATMSCRATCH, paca_struct, tm_scratch);
+   OFFSET(PACATMAMR, paca_struct, tm_amr);
OFFSET(THREAD_TM_TFHAR, thread_struct, tm_tfhar);
OFFSET(THREAD_TM_TEXASR, thread_struct, tm_texasr);
OFFSET(THREAD_TM_TFIAR, thread_struct, tm_tfiar);
OFFSET(THREAD_TM_TAR, thread_struct, tm_tar);
OFFSET(THREAD_TM_PPR, thread_struct, tm_ppr);
OFFSET(THREAD_TM_DSCR, thread_struct, tm_dscr);
+   OFFSET(THREAD_TM_AMR, thread_struct, tm_amr);
OFFSET(PT_CKPT_REGS, thread_struct, ckpt_regs);
OFFSET(THREAD_CKVRSTATE, thread_struct, ckvr_state.vr);
OFFSET(THREAD_CKVRSAVE, thread_struct, ckvrsave);
diff --git a/arch/powerpc/kernel/tm.S b/arch/powerpc/kernel/tm.S
index 6ba0fdd1e7f8..e178ddb43619 100644
--- a/arch/powerpc/kernel/tm.S
+++ b/arch/powerpc/kernel/tm.S
@@ -152,6 +152,10 @@ _GLOBAL(tm_reclaim)
li  r5, 0
mtmsrd  r5, 1
 
+/* Save AMR since it's used elsewhere in kernel space */
+   mfspr   r8, SPRN_AMR
+   std r8, PACATMAMR(r13)
+
/*
 * BE CAREFUL HERE:
 * At this point we can't take an SLB miss since we have MSR_RI
@@ -245,7 +249,7 @@ _GLOBAL(tm_reclaim)
 * but is used in signal return to 'wind back' to the abort handler.
 */
 
-   /*  CR,LR,CCR,MSR ** */
+   /* * CTR, LR, CR, XER ** */
mfctr   r3
mflrr4
mfcrr5
@@ -256,7 +260,6 @@ _GLOBAL(tm_reclaim)
std r5, _CCR(r7)
std r6, _XER(r7)
 
-
/*  TAR, DSCR ** */
mfspr   r3, SPRN_TAR
mfspr   r4, SPRN_DSCR
@@ -264,6 +267,10 @@ _GLOBAL(tm_reclaim)
std r3, THREAD_TM_TAR(r12)
std r4, THREAD_TM_DSCR(r12)
 
+/*  AMR  */
+mfspr  r3, SPRN_AMR
+stdr3, THREAD_TM_AMR(r12)
+
/*
 * MSR and flags: We don't change CRs, and we don't need to alter MSR.
 */
@@ -308,8 +315,6 @@ _GLOBAL(tm_reclaim)
std r3, THREAD_TM_TFHAR(r12)
std r4, THREAD_TM_TFIAR(r12)
 
-   /* AMR is checkpointed too, but is unsupported by Linux. */
-
/* Restore original MSR/IRQ state & clear TM mode */
ld  r14, TM_FRAME_L0(r1)/* Orig MSR */
 
@@ -330,6 +335,10 @@ _GLOBAL(tm_reclaim)
ld  r0, PACA_DSCR_DEFAULT(r13)
mtspr   SPRN_DSCR, r0
 
+/* Restore kernel saved AMR */
+   ld  r4, PACATMAMR(r13)
+   mtspr   SPRN_AMR, r4
+
blr
 
 
@@ -355,6 +364,10 @@ _GLOBAL(__tm_recheckpoint)
 */
SAVE_NVGPRS(r1)
 
+   /* Save kernel AMR since 

RE: [PATCHv7 00/12]PCI: dwc: Add the multiple PF support for DWC and Layerscape

[Z.q. Hou]

Hi Lorenzo,

Thanks a lot for your comments!

> -Original Message-
> From: Lorenzo Pieralisi 
> Sent: 2020年9月18日 0:20
> To: Z.q. Hou 
> Cc: linux-...@vger.kernel.org; devicet...@vger.kernel.org;
> linux-ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> linuxppc-dev@lists.ozlabs.org; robh...@kernel.org; bhelg...@google.com;
> shawn...@kernel.org; Leo Li ; kis...@ti.com;
> gustavo.pimen...@synopsys.com; Roy Zang ;
> jingooh...@gmail.com; andrew.mur...@arm.com; Mingkai Hu
> ; M.h. Lian 
> Subject: Re: [PATCHv7 00/12]PCI: dwc: Add the multiple PF support for DWC
> and Layerscape
> 
> On Tue, Aug 11, 2020 at 05:54:29PM +0800, Zhiqiang Hou wrote:
> > From: Hou Zhiqiang 
> >
> > Add the PCIe EP multiple PF support for DWC and Layerscape, and use a
> > list to manage the PFs of each PCIe controller; add the doorbell MSIX
> > function for DWC; and refactor the Layerscape EP driver due to some
> > difference in Layercape platforms PCIe integration.
> >
> > Hou Zhiqiang (1):
> >   misc: pci_endpoint_test: Add driver data for Layerscape PCIe
> > controllers
> >
> > Xiaowei Bao (11):
> >   PCI: designware-ep: Add multiple PFs support for DWC
> >   PCI: designware-ep: Add the doorbell mode of MSI-X in EP mode
> >   PCI: designware-ep: Move the function of getting MSI capability
> > forward
> >   PCI: designware-ep: Modify MSI and MSIX CAP way of finding
> >   dt-bindings: pci: layerscape-pci: Add compatible strings for ls1088a
> > and ls2088a
> >   PCI: layerscape: Fix some format issue of the code
> >   PCI: layerscape: Modify the way of getting capability with different
> > PEX
> >   PCI: layerscape: Modify the MSIX to the doorbell mode
> >   PCI: layerscape: Add EP mode support for ls1088a and ls2088a
> >   arm64: dts: layerscape: Add PCIe EP node for ls1088a
> >   misc: pci_endpoint_test: Add LS1088a in pci_device_id table
> >
> >  .../bindings/pci/layerscape-pci.txt   |   2 +
> >  .../arm64/boot/dts/freescale/fsl-ls1088a.dtsi |  31 +++
> >  drivers/misc/pci_endpoint_test.c  |   8 +-
> >  .../pci/controller/dwc/pci-layerscape-ep.c| 100 +--
> >  .../pci/controller/dwc/pcie-designware-ep.c   | 258
> ++
> >  drivers/pci/controller/dwc/pcie-designware.c  |  59 ++--
> > drivers/pci/controller/dwc/pcie-designware.h  |  48 +++-
> >  7 files changed, 410 insertions(+), 96 deletions(-)
> 
> Side note: I will change it for you but please keep Signed-off-by:
> tags together in the log instead of mixing them with other tags randomly.
> 
> Can you rebase this series against my pci/dwc branch please and send a v8 ?
> 
> I will apply it then.

I'll rebase this series and put the Signed-off-by tags together today.

Regards,
Zhiqiang

> 
> Thanks,
> Lorenzo

[PATCH AUTOSEL 4.14 102/127] powerpc/traps: Make unrecoverable NMIs die instead of panic

[Sasha Levin]

From: Nicholas Piggin 

[ Upstream commit 265d6e588d87194c2fe2d6c240247f0264e0c19b ]

System Reset and Machine Check interrupts that are not recoverable due
to being nested or interrupting when RI=0 currently panic. This is not
necessary, and can often just kill the current context and recover.

Signed-off-by: Nicholas Piggin 
Signed-off-by: Michael Ellerman 
Reviewed-by: Christophe Leroy 
Link: https://lore.kernel.org/r/20200508043408.886394-16-npig...@gmail.com
Signed-off-by: Sasha Levin 
---
 arch/powerpc/kernel/traps.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 3c9457420aee8..0f1a888c04a84 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -357,11 +357,11 @@ out:
 #ifdef CONFIG_PPC_BOOK3S_64
BUG_ON(get_paca()->in_nmi == 0);
if (get_paca()->in_nmi > 1)
-   nmi_panic(regs, "Unrecoverable nested System Reset");
+   die("Unrecoverable nested System Reset", regs, SIGABRT);
 #endif
/* Must die if the interrupt is not recoverable */
if (!(regs->msr & MSR_RI))
-   nmi_panic(regs, "Unrecoverable System Reset");
+   die("Unrecoverable System Reset", regs, SIGABRT);
 
if (!nested)
nmi_exit();
@@ -701,7 +701,7 @@ void machine_check_exception(struct pt_regs *regs)
 
/* Must die if the interrupt is not recoverable */
if (!(regs->msr & MSR_RI))
-   nmi_panic(regs, "Unrecoverable Machine check");
+   die("Unrecoverable Machine check", regs, SIGBUS);
 
return;
 
-- 
2.25.1

[PATCH AUTOSEL 4.14 031/127] powerpc/eeh: Only dump stack once if an MMIO loop is detected

[Sasha Levin]

From: Oliver O'Halloran 

[ Upstream commit 4e0942c0302b5ad76b228b1a7b8c09f658a1d58a ]

Many drivers don't check for errors when they get a 0xFFs response from an
MMIO load. As a result after an EEH event occurs a driver can get stuck in
a polling loop unless it some kind of internal timeout logic.

Currently EEH tries to detect and report stuck drivers by dumping a stack
trace after eeh_dev_check_failure() is called EEH_MAX_FAILS times on an
already frozen PE. The value of EEH_MAX_FAILS was chosen so that a dump
would occur every few seconds if the driver was spinning in a loop. This
results in a lot of spurious stack traces in the kernel log.

Fix this by limiting it to printing one stack trace for each PE freeze. If
the driver is truely stuck the kernel's hung task detector is better suited
to reporting the probelm anyway.

Signed-off-by: Oliver O'Halloran 
Reviewed-by: Sam Bobroff 
Tested-by: Sam Bobroff 
Signed-off-by: Michael Ellerman 
Link: https://lore.kernel.org/r/20191016012536.22588-1-ooh...@gmail.com
Signed-off-by: Sasha Levin 
---
 arch/powerpc/kernel/eeh.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
index d2ba7936d0d33..7b46576962bfd 100644
--- a/arch/powerpc/kernel/eeh.c
+++ b/arch/powerpc/kernel/eeh.c
@@ -506,7 +506,7 @@ int eeh_dev_check_failure(struct eeh_dev *edev)
rc = 1;
if (pe->state & EEH_PE_ISOLATED) {
pe->check_count++;
-   if (pe->check_count % EEH_MAX_FAILS == 0) {
+   if (pe->check_count == EEH_MAX_FAILS) {
dn = pci_device_to_OF_node(dev);
if (dn)
location = of_get_property(dn, "ibm,loc-code",
-- 
2.25.1

[PATCH AUTOSEL 4.19 165/206] powerpc/traps: Make unrecoverable NMIs die instead of panic

[Sasha Levin]

From: Nicholas Piggin 

[ Upstream commit 265d6e588d87194c2fe2d6c240247f0264e0c19b ]

System Reset and Machine Check interrupts that are not recoverable due
to being nested or interrupting when RI=0 currently panic. This is not
necessary, and can often just kill the current context and recover.

Signed-off-by: Nicholas Piggin 
Signed-off-by: Michael Ellerman 
Reviewed-by: Christophe Leroy 
Link: https://lore.kernel.org/r/20200508043408.886394-16-npig...@gmail.com
Signed-off-by: Sasha Levin 
---
 arch/powerpc/kernel/traps.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index d5f351f02c153..7781f0168ce8c 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -430,11 +430,11 @@ out:
 #ifdef CONFIG_PPC_BOOK3S_64
BUG_ON(get_paca()->in_nmi == 0);
if (get_paca()->in_nmi > 1)
-   nmi_panic(regs, "Unrecoverable nested System Reset");
+   die("Unrecoverable nested System Reset", regs, SIGABRT);
 #endif
/* Must die if the interrupt is not recoverable */
if (!(regs->msr & MSR_RI))
-   nmi_panic(regs, "Unrecoverable System Reset");
+   die("Unrecoverable System Reset", regs, SIGABRT);
 
if (!nested)
nmi_exit();
@@ -775,7 +775,7 @@ void machine_check_exception(struct pt_regs *regs)
 
/* Must die if the interrupt is not recoverable */
if (!(regs->msr & MSR_RI))
-   nmi_panic(regs, "Unrecoverable Machine check");
+   die("Unrecoverable Machine check", regs, SIGBUS);
 
return;
 
-- 
2.25.1

[PATCH AUTOSEL 4.19 114/206] KVM: PPC: Book3S HV: Treat TM-related invalid form instructions on P9 like the valid ones

[Sasha Levin]

From: Gustavo Romero 

[ Upstream commit 1dff3064c764b5a51c367b949b341d2e38972bec ]

On P9 DD2.2 due to a CPU defect some TM instructions need to be emulated by
KVM. This is handled at first by the hardware raising a softpatch interrupt
when certain TM instructions that need KVM assistance are executed in the
guest. Althought some TM instructions per Power ISA are invalid forms they
can raise a softpatch interrupt too. For instance, 'tresume.' instruction
as defined in the ISA must have bit 31 set (1), but an instruction that
matches 'tresume.' PO and XO opcode fields but has bit 31 not set (0), like
0x7cfe9ddc, also raises a softpatch interrupt. Similarly for 'treclaim.'
and 'trechkpt.' instructions with bit 31 = 0, i.e. 0x7c00075c and
0x7c0007dc, respectively. Hence, if a code like the following is executed
in the guest it will raise a softpatch interrupt just like a 'tresume.'
when the TM facility is enabled ('tabort. 0' in the example is used only
to enable the TM facility):

int main() { asm("tabort. 0; .long 0x7cfe9ddc;"); }

Currently in such a case KVM throws a complete trace like:

[345523.705984] WARNING: CPU: 24 PID: 64413 at 
arch/powerpc/kvm/book3s_hv_tm.c:211 kvmhv_p9_tm_emulation+0x68/0x620 [kvm_hv]
[345523.705985] Modules linked in: kvm_hv(E) xt_conntrack ipt_REJECT 
nf_reject_ipv4 xt_tcpudp ip6table_mangle ip6table_nat
iptable_mangle iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 
ebtable_filter ebtables ip6table_filter
ip6_tables iptable_filter bridge stp llc sch_fq_codel ipmi_powernv at24 
vmx_crypto ipmi_devintf ipmi_msghandler
ibmpowernv uio_pdrv_genirq kvm opal_prd uio leds_powernv ib_iser rdma_cm iw_cm 
ib_cm ib_core iscsi_tcp libiscsi_tcp
libiscsi scsi_transport_iscsi ip_tables x_tables autofs4 btrfs blake2b_generic 
zstd_compress raid10 raid456
async_raid6_recov async_memcpy async_pq async_xor async_tx libcrc32c xor 
raid6_pq raid1 raid0 multipath linear tg3
crct10dif_vpmsum crc32c_vpmsum ipr [last unloaded: kvm_hv]
[345523.706030] CPU: 24 PID: 64413 Comm: CPU 0/KVM Tainted: GW   E 
5.5.0+ #1
[345523.706031] NIP:  c008072cb9c0 LR: c008072b5e80 CTR: 
c008085c7850
[345523.706034] REGS: c00399467680 TRAP: 0700   Tainted: GW   E 
 (5.5.0+)
[345523.706034] MSR:  90010282b033 
  CR: 24022428  XER: 
[345523.706042] CFAR: c008072b5e7c IRQMASK: 0
GPR00: c008072b5e80 c00399467910 c008072db500 
c00375ccc720
GPR04: c00375ccc720 0003fbec a10395dda5a6 

GPR08: 7cfe9ddc 7cfe9ddc05dc 7cfe9ddc7c0005dc 
c008072cd530
GPR12: c008085c7850 c003fffeb800 0001 
7dfb737f
GPR16: c0002001edcca558   
0001
GPR20: c1b21258 c0002001edcca558 0018 

GPR24: 0100  0001 
1500
GPR28: c0002001edcc4278 c0037dd8 80050280f033 
c00375ccc720
[345523.706062] NIP [c008072cb9c0] kvmhv_p9_tm_emulation+0x68/0x620 [kvm_hv]
[345523.706065] LR [c008072b5e80] kvmppc_handle_exit_hv.isra.53+0x3e8/0x798 
[kvm_hv]
[345523.706066] Call Trace:
[345523.706069] [c00399467910] [c00399467940] 0xc00399467940 
(unreliable)
[345523.706071] [c00399467950] [c00399467980] 0xc00399467980
[345523.706075] [c003994679f0] [c008072bd1c4] 
kvmhv_run_single_vcpu+0xa1c/0xb80 [kvm_hv]
[345523.706079] [c00399467ac0] [c008072bd8e0] 
kvmppc_vcpu_run_hv+0x5b8/0xb00 [kvm_hv]
[345523.706087] [c00399467b90] [c008085c93cc] kvmppc_vcpu_run+0x34/0x48 
[kvm]
[345523.706095] [c00399467bb0] [c008085c582c] 
kvm_arch_vcpu_ioctl_run+0x244/0x420 [kvm]
[345523.706101] [c00399467c40] [c008085b7498] 
kvm_vcpu_ioctl+0x3d0/0x7b0 [kvm]
[345523.706105] [c00399467db0] [c04adf9c] ksys_ioctl+0x13c/0x170
[345523.706107] [c00399467e00] [c04adff8] sys_ioctl+0x28/0x80
[345523.706111] [c00399467e20] [c000b278] system_call+0x5c/0x68
[345523.706112] Instruction dump:
[345523.706114] 419e0390 7f8a4840 409d0048 6d497c00 2f89075d 419e021c 6d497c00 
2f8907dd
[345523.706119] 419e01c0 6d497c00 2f8905dd 419e00a4 <0fe0> 38210040 
3860 ebc1fff0

and then treats the executed instruction as a 'nop'.

However the POWER9 User's Manual, in section "4.6.10 Book II Invalid
Forms", informs that for TM instructions bit 31 is in fact ignored, thus
for the TM-related invalid forms ignoring bit 31 and handling them like the
valid forms is an acceptable way to handle them. POWER8 behaves the same
way too.

This commit changes the handling of the cases here described by treating
the TM-related invalid forms that can generate a softpatch interrupt
just like their valid forms (w/ bit 31 = 1) instead of as a 'nop' and by
gently reporting any other unrecognized case to the 

[PATCH AUTOSEL 4.19 056/206] powerpc/eeh: Only dump stack once if an MMIO loop is detected

[Sasha Levin]

From: Oliver O'Halloran 

[ Upstream commit 4e0942c0302b5ad76b228b1a7b8c09f658a1d58a ]

Many drivers don't check for errors when they get a 0xFFs response from an
MMIO load. As a result after an EEH event occurs a driver can get stuck in
a polling loop unless it some kind of internal timeout logic.

Currently EEH tries to detect and report stuck drivers by dumping a stack
trace after eeh_dev_check_failure() is called EEH_MAX_FAILS times on an
already frozen PE. The value of EEH_MAX_FAILS was chosen so that a dump
would occur every few seconds if the driver was spinning in a loop. This
results in a lot of spurious stack traces in the kernel log.

Fix this by limiting it to printing one stack trace for each PE freeze. If
the driver is truely stuck the kernel's hung task detector is better suited
to reporting the probelm anyway.

Signed-off-by: Oliver O'Halloran 
Reviewed-by: Sam Bobroff 
Tested-by: Sam Bobroff 
Signed-off-by: Michael Ellerman 
Link: https://lore.kernel.org/r/20191016012536.22588-1-ooh...@gmail.com
Signed-off-by: Sasha Levin 
---
 arch/powerpc/kernel/eeh.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
index fe3c6f3bd3b62..d123cba0992d0 100644
--- a/arch/powerpc/kernel/eeh.c
+++ b/arch/powerpc/kernel/eeh.c
@@ -502,7 +502,7 @@ int eeh_dev_check_failure(struct eeh_dev *edev)
rc = 1;
if (pe->state & EEH_PE_ISOLATED) {
pe->check_count++;
-   if (pe->check_count % EEH_MAX_FAILS == 0) {
+   if (pe->check_count == EEH_MAX_FAILS) {
dn = pci_device_to_OF_node(dev);
if (dn)
location = of_get_property(dn, "ibm,loc-code",
-- 
2.25.1

[PATCH AUTOSEL 4.19 055/206] powerpc/powernv/ioda: Fix ref count for devices with their own PE

[Sasha Levin]

From: Frederic Barrat 

[ Upstream commit 05dd7da76986937fb288b4213b1fa10dbe0d1b33 ]

The pci_dn structure used to store a pointer to the struct pci_dev, so
taking a reference on the device was required. However, the pci_dev
pointer was later removed from the pci_dn structure, but the reference
was kept for the npu device.
See commit 902bdc57451c ("powerpc/powernv/idoa: Remove unnecessary
pcidev from pci_dn").

We don't need to take a reference on the device when assigning the PE
as the struct pnv_ioda_pe is cleaned up at the same time as
the (physical) device is released. Doing so prevents the device from
being released, which is a problem for opencapi devices, since we want
to be able to remove them through PCI hotplug.

Now the ugly part: nvlink npu devices are not meant to be
released. Because of the above, we've always leaked a reference and
simply removing it now is dangerous and would likely require more
work. There's currently no release device callback for nvlink devices
for example. So to be safe, this patch leaks a reference on the npu
device, but only for nvlink and not opencapi.

Signed-off-by: Frederic Barrat 
Reviewed-by: Andrew Donnellan 
Signed-off-by: Michael Ellerman 
Link: https://lore.kernel.org/r/20191121134918.7155-2-fbar...@linux.ibm.com
Signed-off-by: Sasha Levin 
---
 arch/powerpc/platforms/powernv/pci-ioda.c | 19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c 
b/arch/powerpc/platforms/powernv/pci-ioda.c
index ecd211c5f24a5..19cd6affdd5fb 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -1071,14 +1071,13 @@ static struct pnv_ioda_pe *pnv_ioda_setup_dev_PE(struct 
pci_dev *dev)
return NULL;
}
 
-   /* NOTE: We get only one ref to the pci_dev for the pdn, not for the
-* pointer in the PE data structure, both should be destroyed at the
-* same time. However, this needs to be looked at more closely again
-* once we actually start removing things (Hotplug, SR-IOV, ...)
+   /* NOTE: We don't get a reference for the pointer in the PE
+* data structure, both the device and PE structures should be
+* destroyed at the same time. However, removing nvlink
+* devices will need some work.
 *
 * At some point we want to remove the PDN completely anyways
 */
-   pci_dev_get(dev);
pdn->pe_number = pe->pe_number;
pe->flags = PNV_IODA_PE_DEV;
pe->pdev = dev;
@@ -1093,7 +1092,6 @@ static struct pnv_ioda_pe *pnv_ioda_setup_dev_PE(struct 
pci_dev *dev)
pnv_ioda_free_pe(pe);
pdn->pe_number = IODA_INVALID_PE;
pe->pdev = NULL;
-   pci_dev_put(dev);
return NULL;
}
 
@@ -1213,6 +1211,14 @@ static struct pnv_ioda_pe *pnv_ioda_setup_npu_PE(struct 
pci_dev *npu_pdev)
struct pci_controller *hose = pci_bus_to_host(npu_pdev->bus);
struct pnv_phb *phb = hose->private_data;
 
+   /*
+* Intentionally leak a reference on the npu device (for
+* nvlink only; this is not an opencapi path) to make sure it
+* never goes away, as it's been the case all along and some
+* work is needed otherwise.
+*/
+   pci_dev_get(npu_pdev);
+
/*
 * Due to a hardware errata PE#0 on the NPU is reserved for
 * error handling. This means we only have three PEs remaining
@@ -1236,7 +1242,6 @@ static struct pnv_ioda_pe *pnv_ioda_setup_npu_PE(struct 
pci_dev *npu_pdev)
 */
dev_info(_pdev->dev,
"Associating to existing PE %x\n", pe_num);
-   pci_dev_get(npu_pdev);
npu_pdn = pci_get_pdn(npu_pdev);
rid = npu_pdev->bus->number << 8 | npu_pdn->devfn;
npu_pdn->pe_number = pe_num;
-- 
2.25.1

[PATCH AUTOSEL 5.4 290/330] KVM: PPC: Book3S HV: Close race with page faults around memslot flushes

[Sasha Levin]

From: Paul Mackerras 

[ Upstream commit 11362b1befeadaae4d159a8cddcdaf6b8afe08f9 ]

There is a potential race condition between hypervisor page faults
and flushing a memslot.  It is possible for a page fault to read the
memslot before a memslot is updated and then write a PTE to the
partition-scoped page tables after kvmppc_radix_flush_memslot has
completed.  (Note that this race has never been explicitly observed.)

To close this race, it is sufficient to increment the MMU sequence
number while the kvm->mmu_lock is held.  That will cause
mmu_notifier_retry() to return true, and the page fault will then
return to the guest without inserting a PTE.

Signed-off-by: Paul Mackerras 
Signed-off-by: Sasha Levin 
---
 arch/powerpc/kvm/book3s_64_mmu_radix.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/powerpc/kvm/book3s_64_mmu_radix.c 
b/arch/powerpc/kvm/book3s_64_mmu_radix.c
index da8375437d161..9d73448354698 100644
--- a/arch/powerpc/kvm/book3s_64_mmu_radix.c
+++ b/arch/powerpc/kvm/book3s_64_mmu_radix.c
@@ -1104,6 +1104,11 @@ void kvmppc_radix_flush_memslot(struct kvm *kvm,
 kvm->arch.lpid);
gpa += PAGE_SIZE;
}
+   /*
+* Increase the mmu notifier sequence number to prevent any page
+* fault that read the memslot earlier from writing a PTE.
+*/
+   kvm->mmu_notifier_seq++;
spin_unlock(>mmu_lock);
 }
 
-- 
2.25.1

[PATCH AUTOSEL 5.4 270/330] powerpc/traps: Make unrecoverable NMIs die instead of panic

[Sasha Levin]

From: Nicholas Piggin 

[ Upstream commit 265d6e588d87194c2fe2d6c240247f0264e0c19b ]

System Reset and Machine Check interrupts that are not recoverable due
to being nested or interrupting when RI=0 currently panic. This is not
necessary, and can often just kill the current context and recover.

Signed-off-by: Nicholas Piggin 
Signed-off-by: Michael Ellerman 
Reviewed-by: Christophe Leroy 
Link: https://lore.kernel.org/r/20200508043408.886394-16-npig...@gmail.com
Signed-off-by: Sasha Levin 
---
 arch/powerpc/kernel/traps.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 014ff0701f245..9432fc6af28a5 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -510,11 +510,11 @@ out:
 #ifdef CONFIG_PPC_BOOK3S_64
BUG_ON(get_paca()->in_nmi == 0);
if (get_paca()->in_nmi > 1)
-   nmi_panic(regs, "Unrecoverable nested System Reset");
+   die("Unrecoverable nested System Reset", regs, SIGABRT);
 #endif
/* Must die if the interrupt is not recoverable */
if (!(regs->msr & MSR_RI))
-   nmi_panic(regs, "Unrecoverable System Reset");
+   die("Unrecoverable System Reset", regs, SIGABRT);
 
if (saved_hsrrs) {
mtspr(SPRN_HSRR0, hsrr0);
@@ -858,7 +858,7 @@ void machine_check_exception(struct pt_regs *regs)
 
/* Must die if the interrupt is not recoverable */
if (!(regs->msr & MSR_RI))
-   nmi_panic(regs, "Unrecoverable Machine check");
+   die("Unrecoverable Machine check", regs, SIGBUS);
 
return;
 
-- 
2.25.1

[PATCH AUTOSEL 5.4 224/330] powerpc/perf: Implement a global lock to avoid races between trace, core and thread imc events.

[Sasha Levin]

From: Anju T Sudhakar 

[ Upstream commit a36e8ba60b991d563677227f172db69e030797e6 ]

IMC(In-memory Collection Counters) does performance monitoring in
two different modes, i.e accumulation mode(core-imc and thread-imc events),
and trace mode(trace-imc events). A cpu thread can either be in
accumulation-mode or trace-mode at a time and this is done via the LDBAR
register in POWER architecture. The current design does not address the
races between thread-imc and trace-imc events.

Patch implements a global id and lock to avoid the races between
core, trace and thread imc events. With this global id-lock
implementation, the system can either run core, thread or trace imc
events at a time. i.e. to run any core-imc events, thread/trace imc events
should not be enabled/monitored.

Signed-off-by: Anju T Sudhakar 
Signed-off-by: Michael Ellerman 
Link: https://lore.kernel.org/r/20200313055238.8656-1-a...@linux.vnet.ibm.com
Signed-off-by: Sasha Levin 
---
 arch/powerpc/perf/imc-pmu.c | 173 +++-
 1 file changed, 149 insertions(+), 24 deletions(-)

diff --git a/arch/powerpc/perf/imc-pmu.c b/arch/powerpc/perf/imc-pmu.c
index cb50a9e1fd2d7..eb82dda884e51 100644
--- a/arch/powerpc/perf/imc-pmu.c
+++ b/arch/powerpc/perf/imc-pmu.c
@@ -44,6 +44,16 @@ static DEFINE_PER_CPU(u64 *, trace_imc_mem);
 static struct imc_pmu_ref *trace_imc_refc;
 static int trace_imc_mem_size;
 
+/*
+ * Global data structure used to avoid races between thread,
+ * core and trace-imc
+ */
+static struct imc_pmu_ref imc_global_refc = {
+   .lock = __MUTEX_INITIALIZER(imc_global_refc.lock),
+   .id = 0,
+   .refc = 0,
+};
+
 static struct imc_pmu *imc_event_to_pmu(struct perf_event *event)
 {
return container_of(event->pmu, struct imc_pmu, pmu);
@@ -698,6 +708,16 @@ static int ppc_core_imc_cpu_offline(unsigned int cpu)
return -EINVAL;
 
ref->refc = 0;
+   /*
+* Reduce the global reference count, if this is the
+* last cpu in this core and core-imc event running
+* in this cpu.
+*/
+   mutex_lock(_global_refc.lock);
+   if (imc_global_refc.id == IMC_DOMAIN_CORE)
+   imc_global_refc.refc--;
+
+   mutex_unlock(_global_refc.lock);
}
return 0;
 }
@@ -710,6 +730,23 @@ static int core_imc_pmu_cpumask_init(void)
 ppc_core_imc_cpu_offline);
 }
 
+static void reset_global_refc(struct perf_event *event)
+{
+   mutex_lock(_global_refc.lock);
+   imc_global_refc.refc--;
+
+   /*
+* If no other thread is running any
+* event for this domain(thread/core/trace),
+* set the global id to zero.
+*/
+   if (imc_global_refc.refc <= 0) {
+   imc_global_refc.refc = 0;
+   imc_global_refc.id = 0;
+   }
+   mutex_unlock(_global_refc.lock);
+}
+
 static void core_imc_counters_release(struct perf_event *event)
 {
int rc, core_id;
@@ -759,6 +796,8 @@ static void core_imc_counters_release(struct perf_event 
*event)
ref->refc = 0;
}
mutex_unlock(>lock);
+
+   reset_global_refc(event);
 }
 
 static int core_imc_event_init(struct perf_event *event)
@@ -819,6 +858,29 @@ static int core_imc_event_init(struct perf_event *event)
++ref->refc;
mutex_unlock(>lock);
 
+   /*
+* Since the system can run either in accumulation or trace-mode
+* of IMC at a time, core-imc events are allowed only if no other
+* trace/thread imc events are enabled/monitored.
+*
+* Take the global lock, and check the refc.id
+* to know whether any other trace/thread imc
+* events are running.
+*/
+   mutex_lock(_global_refc.lock);
+   if (imc_global_refc.id == 0 || imc_global_refc.id == IMC_DOMAIN_CORE) {
+   /*
+* No other trace/thread imc events are running in
+* the system, so set the refc.id to core-imc.
+*/
+   imc_global_refc.id = IMC_DOMAIN_CORE;
+   imc_global_refc.refc++;
+   } else {
+   mutex_unlock(_global_refc.lock);
+   return -EBUSY;
+   }
+   mutex_unlock(_global_refc.lock);
+
event->hw.event_base = (u64)pcmi->vbase + (config & 
IMC_EVENT_OFFSET_MASK);
event->destroy = core_imc_counters_release;
return 0;
@@ -877,7 +939,23 @@ static int ppc_thread_imc_cpu_online(unsigned int cpu)
 
 static int ppc_thread_imc_cpu_offline(unsigned int cpu)
 {
-   mtspr(SPRN_LDBAR, 0);
+   /*
+* Set the bit 0 of LDBAR to zero.
+*
+* If bit 0 of LDBAR is unset, it will stop posting
+* the counter data to memory.
+* For thread-imc, bit 0 of LDBAR will be 

[PATCH AUTOSEL 5.4 180/330] KVM: PPC: Book3S HV: Treat TM-related invalid form instructions on P9 like the valid ones

[Sasha Levin]

From: Gustavo Romero 

[ Upstream commit 1dff3064c764b5a51c367b949b341d2e38972bec ]

On P9 DD2.2 due to a CPU defect some TM instructions need to be emulated by
KVM. This is handled at first by the hardware raising a softpatch interrupt
when certain TM instructions that need KVM assistance are executed in the
guest. Althought some TM instructions per Power ISA are invalid forms they
can raise a softpatch interrupt too. For instance, 'tresume.' instruction
as defined in the ISA must have bit 31 set (1), but an instruction that
matches 'tresume.' PO and XO opcode fields but has bit 31 not set (0), like
0x7cfe9ddc, also raises a softpatch interrupt. Similarly for 'treclaim.'
and 'trechkpt.' instructions with bit 31 = 0, i.e. 0x7c00075c and
0x7c0007dc, respectively. Hence, if a code like the following is executed
in the guest it will raise a softpatch interrupt just like a 'tresume.'
when the TM facility is enabled ('tabort. 0' in the example is used only
to enable the TM facility):

int main() { asm("tabort. 0; .long 0x7cfe9ddc;"); }

Currently in such a case KVM throws a complete trace like:

[345523.705984] WARNING: CPU: 24 PID: 64413 at 
arch/powerpc/kvm/book3s_hv_tm.c:211 kvmhv_p9_tm_emulation+0x68/0x620 [kvm_hv]
[345523.705985] Modules linked in: kvm_hv(E) xt_conntrack ipt_REJECT 
nf_reject_ipv4 xt_tcpudp ip6table_mangle ip6table_nat
iptable_mangle iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 
ebtable_filter ebtables ip6table_filter
ip6_tables iptable_filter bridge stp llc sch_fq_codel ipmi_powernv at24 
vmx_crypto ipmi_devintf ipmi_msghandler
ibmpowernv uio_pdrv_genirq kvm opal_prd uio leds_powernv ib_iser rdma_cm iw_cm 
ib_cm ib_core iscsi_tcp libiscsi_tcp
libiscsi scsi_transport_iscsi ip_tables x_tables autofs4 btrfs blake2b_generic 
zstd_compress raid10 raid456
async_raid6_recov async_memcpy async_pq async_xor async_tx libcrc32c xor 
raid6_pq raid1 raid0 multipath linear tg3
crct10dif_vpmsum crc32c_vpmsum ipr [last unloaded: kvm_hv]
[345523.706030] CPU: 24 PID: 64413 Comm: CPU 0/KVM Tainted: GW   E 
5.5.0+ #1
[345523.706031] NIP:  c008072cb9c0 LR: c008072b5e80 CTR: 
c008085c7850
[345523.706034] REGS: c00399467680 TRAP: 0700   Tainted: GW   E 
 (5.5.0+)
[345523.706034] MSR:  90010282b033 
  CR: 24022428  XER: 
[345523.706042] CFAR: c008072b5e7c IRQMASK: 0
GPR00: c008072b5e80 c00399467910 c008072db500 
c00375ccc720
GPR04: c00375ccc720 0003fbec a10395dda5a6 

GPR08: 7cfe9ddc 7cfe9ddc05dc 7cfe9ddc7c0005dc 
c008072cd530
GPR12: c008085c7850 c003fffeb800 0001 
7dfb737f
GPR16: c0002001edcca558   
0001
GPR20: c1b21258 c0002001edcca558 0018 

GPR24: 0100  0001 
1500
GPR28: c0002001edcc4278 c0037dd8 80050280f033 
c00375ccc720
[345523.706062] NIP [c008072cb9c0] kvmhv_p9_tm_emulation+0x68/0x620 [kvm_hv]
[345523.706065] LR [c008072b5e80] kvmppc_handle_exit_hv.isra.53+0x3e8/0x798 
[kvm_hv]
[345523.706066] Call Trace:
[345523.706069] [c00399467910] [c00399467940] 0xc00399467940 
(unreliable)
[345523.706071] [c00399467950] [c00399467980] 0xc00399467980
[345523.706075] [c003994679f0] [c008072bd1c4] 
kvmhv_run_single_vcpu+0xa1c/0xb80 [kvm_hv]
[345523.706079] [c00399467ac0] [c008072bd8e0] 
kvmppc_vcpu_run_hv+0x5b8/0xb00 [kvm_hv]
[345523.706087] [c00399467b90] [c008085c93cc] kvmppc_vcpu_run+0x34/0x48 
[kvm]
[345523.706095] [c00399467bb0] [c008085c582c] 
kvm_arch_vcpu_ioctl_run+0x244/0x420 [kvm]
[345523.706101] [c00399467c40] [c008085b7498] 
kvm_vcpu_ioctl+0x3d0/0x7b0 [kvm]
[345523.706105] [c00399467db0] [c04adf9c] ksys_ioctl+0x13c/0x170
[345523.706107] [c00399467e00] [c04adff8] sys_ioctl+0x28/0x80
[345523.706111] [c00399467e20] [c000b278] system_call+0x5c/0x68
[345523.706112] Instruction dump:
[345523.706114] 419e0390 7f8a4840 409d0048 6d497c00 2f89075d 419e021c 6d497c00 
2f8907dd
[345523.706119] 419e01c0 6d497c00 2f8905dd 419e00a4 <0fe0> 38210040 
3860 ebc1fff0

and then treats the executed instruction as a 'nop'.

However the POWER9 User's Manual, in section "4.6.10 Book II Invalid
Forms", informs that for TM instructions bit 31 is in fact ignored, thus
for the TM-related invalid forms ignoring bit 31 and handling them like the
valid forms is an acceptable way to handle them. POWER8 behaves the same
way too.

This commit changes the handling of the cases here described by treating
the TM-related invalid forms that can generate a softpatch interrupt
just like their valid forms (w/ bit 31 = 1) instead of as a 'nop' and by
gently reporting any other unrecognized case to the 

[PATCH AUTOSEL 5.4 153/330] powerpc/book3s64: Fix error handling in mm_iommu_do_alloc()

[Sasha Levin]

From: Alexey Kardashevskiy 

[ Upstream commit c4b78169e3667413184c9a20e11b5832288a109f ]

The last jump to free_exit in mm_iommu_do_alloc() happens after page
pointers in struct mm_iommu_table_group_mem_t were already converted to
physical addresses. Thus calling put_page() on these physical addresses
will likely crash.

This moves the loop which calculates the pageshift and converts page
struct pointers to physical addresses later after the point when
we cannot fail; thus eliminating the need to convert pointers back.

Fixes: eb9d7a62c386 ("powerpc/mm_iommu: Fix potential deadlock")
Reported-by: Jan Kara 
Signed-off-by: Alexey Kardashevskiy 
Signed-off-by: Michael Ellerman 
Link: https://lore.kernel.org/r/20191223060351.26359-1-...@ozlabs.ru
Signed-off-by: Sasha Levin 
---
 arch/powerpc/mm/book3s64/iommu_api.c | 39 +++-
 1 file changed, 21 insertions(+), 18 deletions(-)

diff --git a/arch/powerpc/mm/book3s64/iommu_api.c 
b/arch/powerpc/mm/book3s64/iommu_api.c
index 56cc845205779..ef164851738b8 100644
--- a/arch/powerpc/mm/book3s64/iommu_api.c
+++ b/arch/powerpc/mm/book3s64/iommu_api.c
@@ -121,24 +121,6 @@ static long mm_iommu_do_alloc(struct mm_struct *mm, 
unsigned long ua,
goto free_exit;
}
 
-   pageshift = PAGE_SHIFT;
-   for (i = 0; i < entries; ++i) {
-   struct page *page = mem->hpages[i];
-
-   /*
-* Allow to use larger than 64k IOMMU pages. Only do that
-* if we are backed by hugetlb.
-*/
-   if ((mem->pageshift > PAGE_SHIFT) && PageHuge(page))
-   pageshift = page_shift(compound_head(page));
-   mem->pageshift = min(mem->pageshift, pageshift);
-   /*
-* We don't need struct page reference any more, switch
-* to physical address.
-*/
-   mem->hpas[i] = page_to_pfn(page) << PAGE_SHIFT;
-   }
-
 good_exit:
atomic64_set(>mapped, 1);
mem->used = 1;
@@ -158,6 +140,27 @@ good_exit:
}
}
 
+   if (mem->dev_hpa == MM_IOMMU_TABLE_INVALID_HPA) {
+   /*
+* Allow to use larger than 64k IOMMU pages. Only do that
+* if we are backed by hugetlb. Skip device memory as it is not
+* backed with page structs.
+*/
+   pageshift = PAGE_SHIFT;
+   for (i = 0; i < entries; ++i) {
+   struct page *page = mem->hpages[i];
+
+   if ((mem->pageshift > PAGE_SHIFT) && PageHuge(page))
+   pageshift = page_shift(compound_head(page));
+   mem->pageshift = min(mem->pageshift, pageshift);
+   /*
+* We don't need struct page reference any more, switch
+* to physical address.
+*/
+   mem->hpas[i] = page_to_pfn(page) << PAGE_SHIFT;
+   }
+   }
+
list_add_rcu(>next, >context.iommu_group_mem_list);
 
mutex_unlock(_list_mutex);
-- 
2.25.1

[PATCH AUTOSEL 5.4 101/330] powerpc/powernv/ioda: Fix ref count for devices with their own PE

[Sasha Levin]

From: Frederic Barrat 

[ Upstream commit 05dd7da76986937fb288b4213b1fa10dbe0d1b33 ]

The pci_dn structure used to store a pointer to the struct pci_dev, so
taking a reference on the device was required. However, the pci_dev
pointer was later removed from the pci_dn structure, but the reference
was kept for the npu device.
See commit 902bdc57451c ("powerpc/powernv/idoa: Remove unnecessary
pcidev from pci_dn").

We don't need to take a reference on the device when assigning the PE
as the struct pnv_ioda_pe is cleaned up at the same time as
the (physical) device is released. Doing so prevents the device from
being released, which is a problem for opencapi devices, since we want
to be able to remove them through PCI hotplug.

Now the ugly part: nvlink npu devices are not meant to be
released. Because of the above, we've always leaked a reference and
simply removing it now is dangerous and would likely require more
work. There's currently no release device callback for nvlink devices
for example. So to be safe, this patch leaks a reference on the npu
device, but only for nvlink and not opencapi.

Signed-off-by: Frederic Barrat 
Reviewed-by: Andrew Donnellan 
Signed-off-by: Michael Ellerman 
Link: https://lore.kernel.org/r/20191121134918.7155-2-fbar...@linux.ibm.com
Signed-off-by: Sasha Levin 
---
 arch/powerpc/platforms/powernv/pci-ioda.c | 19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c 
b/arch/powerpc/platforms/powernv/pci-ioda.c
index 058223233088e..e9cda7e316a50 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -1062,14 +1062,13 @@ static struct pnv_ioda_pe *pnv_ioda_setup_dev_PE(struct 
pci_dev *dev)
return NULL;
}
 
-   /* NOTE: We get only one ref to the pci_dev for the pdn, not for the
-* pointer in the PE data structure, both should be destroyed at the
-* same time. However, this needs to be looked at more closely again
-* once we actually start removing things (Hotplug, SR-IOV, ...)
+   /* NOTE: We don't get a reference for the pointer in the PE
+* data structure, both the device and PE structures should be
+* destroyed at the same time. However, removing nvlink
+* devices will need some work.
 *
 * At some point we want to remove the PDN completely anyways
 */
-   pci_dev_get(dev);
pdn->pe_number = pe->pe_number;
pe->flags = PNV_IODA_PE_DEV;
pe->pdev = dev;
@@ -1084,7 +1083,6 @@ static struct pnv_ioda_pe *pnv_ioda_setup_dev_PE(struct 
pci_dev *dev)
pnv_ioda_free_pe(pe);
pdn->pe_number = IODA_INVALID_PE;
pe->pdev = NULL;
-   pci_dev_put(dev);
return NULL;
}
 
@@ -1205,6 +1203,14 @@ static struct pnv_ioda_pe *pnv_ioda_setup_npu_PE(struct 
pci_dev *npu_pdev)
struct pci_controller *hose = pci_bus_to_host(npu_pdev->bus);
struct pnv_phb *phb = hose->private_data;
 
+   /*
+* Intentionally leak a reference on the npu device (for
+* nvlink only; this is not an opencapi path) to make sure it
+* never goes away, as it's been the case all along and some
+* work is needed otherwise.
+*/
+   pci_dev_get(npu_pdev);
+
/*
 * Due to a hardware errata PE#0 on the NPU is reserved for
 * error handling. This means we only have three PEs remaining
@@ -1228,7 +1234,6 @@ static struct pnv_ioda_pe *pnv_ioda_setup_npu_PE(struct 
pci_dev *npu_pdev)
 */
dev_info(_pdev->dev,
"Associating to existing PE %x\n", pe_num);
-   pci_dev_get(npu_pdev);
npu_pdn = pci_get_pdn(npu_pdev);
rid = npu_pdev->bus->number << 8 | npu_pdn->devfn;
npu_pdn->pe_number = pe_num;
-- 
2.25.1

[PATCH AUTOSEL 5.4 102/330] powerpc/eeh: Only dump stack once if an MMIO loop is detected

[Sasha Levin]

From: Oliver O'Halloran 

[ Upstream commit 4e0942c0302b5ad76b228b1a7b8c09f658a1d58a ]

Many drivers don't check for errors when they get a 0xFFs response from an
MMIO load. As a result after an EEH event occurs a driver can get stuck in
a polling loop unless it some kind of internal timeout logic.

Currently EEH tries to detect and report stuck drivers by dumping a stack
trace after eeh_dev_check_failure() is called EEH_MAX_FAILS times on an
already frozen PE. The value of EEH_MAX_FAILS was chosen so that a dump
would occur every few seconds if the driver was spinning in a loop. This
results in a lot of spurious stack traces in the kernel log.

Fix this by limiting it to printing one stack trace for each PE freeze. If
the driver is truely stuck the kernel's hung task detector is better suited
to reporting the probelm anyway.

Signed-off-by: Oliver O'Halloran 
Reviewed-by: Sam Bobroff 
Tested-by: Sam Bobroff 
Signed-off-by: Michael Ellerman 
Link: https://lore.kernel.org/r/20191016012536.22588-1-ooh...@gmail.com
Signed-off-by: Sasha Levin 
---
 arch/powerpc/kernel/eeh.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
index bc8a551013be9..c35069294ecfb 100644
--- a/arch/powerpc/kernel/eeh.c
+++ b/arch/powerpc/kernel/eeh.c
@@ -503,7 +503,7 @@ int eeh_dev_check_failure(struct eeh_dev *edev)
rc = 1;
if (pe->state & EEH_PE_ISOLATED) {
pe->check_count++;
-   if (pe->check_count % EEH_MAX_FAILS == 0) {
+   if (pe->check_count == EEH_MAX_FAILS) {
dn = pci_device_to_OF_node(dev);
if (dn)
location = of_get_property(dn, "ibm,loc-code",
-- 
2.25.1

[PATCH AUTOSEL 5.4 030/330] powerpc/64s: Always disable branch profiling for prom_init.o

[Sasha Levin]

From: Michael Ellerman 

[ Upstream commit 6266a4dadb1d0976490fdf5af4f7941e36f64e80 ]

Otherwise the build fails because prom_init is calling symbols it's
not allowed to, eg:

  Error: External symbol 'ftrace_likely_update' referenced from prom_init.c
  make[3]: *** [arch/powerpc/kernel/Makefile:197: 
arch/powerpc/kernel/prom_init_check] Error 1

Signed-off-by: Michael Ellerman 
Link: https://lore.kernel.org/r/20191106051129.7626-1-...@ellerman.id.au
Signed-off-by: Sasha Levin 
---
 arch/powerpc/kernel/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index dc0780f930d5b..59260eb962916 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -19,6 +19,7 @@ CFLAGS_btext.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
 CFLAGS_prom.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
 
 CFLAGS_prom_init.o += $(call cc-option, -fno-stack-protector)
+CFLAGS_prom_init.o += -DDISABLE_BRANCH_PROFILING
 
 ifdef CONFIG_FUNCTION_TRACER
 # Do not trace early boot code
@@ -36,7 +37,6 @@ KASAN_SANITIZE_btext.o := n
 ifdef CONFIG_KASAN
 CFLAGS_early_32.o += -DDISABLE_BRANCH_PROFILING
 CFLAGS_cputable.o += -DDISABLE_BRANCH_PROFILING
-CFLAGS_prom_init.o += -DDISABLE_BRANCH_PROFILING
 CFLAGS_btext.o += -DDISABLE_BRANCH_PROFILING
 endif
 
-- 
2.25.1

Re: [PATCH] selftests/seccomp: fix ptrace tests on powerpc

[Thadeu Lima de Souza Cascardo]

On Thu, Sep 17, 2020 at 03:37:16PM -0700, Kees Cook wrote:
> On Sun, Sep 13, 2020 at 10:34:23PM +1000, Michael Ellerman wrote:
> > Thadeu Lima de Souza Cascardo  writes:
> > > On Tue, Sep 08, 2020 at 04:18:17PM -0700, Kees Cook wrote:
> > >> On Tue, Jun 30, 2020 at 01:47:39PM -0300, Thadeu Lima de Souza Cascardo 
> > >> wrote:
> > ...
> > >> > @@ -1809,10 +1818,15 @@ void tracer_ptrace(struct __test_metadata 
> > >> > *_metadata, pid_t tracee,
> > >> >EXPECT_EQ(entry ? PTRACE_EVENTMSG_SYSCALL_ENTRY
> > >> >: PTRACE_EVENTMSG_SYSCALL_EXIT, msg);
> > >> >  
> > >> > -  if (!entry)
> > >> > +  if (!entry && !syscall_nr)
> > >> >return;
> > >> >  
> > >> > -  nr = get_syscall(_metadata, tracee);
> > >> > +  if (entry)
> > >> > +  nr = get_syscall(_metadata, tracee);
> > >> > +  else
> > >> > +  nr = *syscall_nr;
> > >> 
> > >> This is weird? Shouldn't get_syscall() be modified to do the right thing
> > >> here instead of depending on the extra arg?
> > >> 
> > >
> > > R0 might be clobered. Same documentation mentions it as volatile. So, 
> > > during
> > > syscall exit, we can't tell for sure that R0 will have the original 
> > > syscall
> > > number. So, we need to grab it during syscall enter, save it somewhere and
> > > reuse it. I used the test context/args for that.
> > 
> > The user r0 (in regs->gpr[0]) shouldn't be clobbered.
> > 
> > But it is modified if the tracer skips the syscall, by setting the
> > syscall number to -1. Or if the tracer changes the syscall number.
> > 
> > So if you need the original syscall number in the exit path then I think
> > you do need to save it at entry.
> 
> ... the selftest code wants to test the updated syscall (-1 or
> whatever), so this sounds correct. Was this test actually failing on
> powerpc? (I'd really rather not split entry/exit if I don't have to.)
> 
> -- 
> Kees Cook

Yes, it started failing when the return code started being changed as well.
Though ptrace can change the syscall at entry (IIRC), it can't change the
return code. And that is part of the ABI. If ppc is changed so it allows
changing the return code during ptrace entry, some strace uses will break. So
that is not an option.

Cascardo.

Re: [PATCH] selftests/seccomp: fix ptrace tests on powerpc

[Kees Cook]

On Sun, Sep 13, 2020 at 10:34:23PM +1000, Michael Ellerman wrote:
> Thadeu Lima de Souza Cascardo  writes:
> > On Tue, Sep 08, 2020 at 04:18:17PM -0700, Kees Cook wrote:
> >> On Tue, Jun 30, 2020 at 01:47:39PM -0300, Thadeu Lima de Souza Cascardo 
> >> wrote:
> ...
> >> > @@ -1809,10 +1818,15 @@ void tracer_ptrace(struct __test_metadata 
> >> > *_metadata, pid_t tracee,
> >> >  EXPECT_EQ(entry ? PTRACE_EVENTMSG_SYSCALL_ENTRY
> >> >  : PTRACE_EVENTMSG_SYSCALL_EXIT, msg);
> >> >  
> >> > -if (!entry)
> >> > +if (!entry && !syscall_nr)
> >> >  return;
> >> >  
> >> > -nr = get_syscall(_metadata, tracee);
> >> > +if (entry)
> >> > +nr = get_syscall(_metadata, tracee);
> >> > +else
> >> > +nr = *syscall_nr;
> >> 
> >> This is weird? Shouldn't get_syscall() be modified to do the right thing
> >> here instead of depending on the extra arg?
> >> 
> >
> > R0 might be clobered. Same documentation mentions it as volatile. So, during
> > syscall exit, we can't tell for sure that R0 will have the original syscall
> > number. So, we need to grab it during syscall enter, save it somewhere and
> > reuse it. I used the test context/args for that.
> 
> The user r0 (in regs->gpr[0]) shouldn't be clobbered.
> 
> But it is modified if the tracer skips the syscall, by setting the
> syscall number to -1. Or if the tracer changes the syscall number.
> 
> So if you need the original syscall number in the exit path then I think
> you do need to save it at entry.

... the selftest code wants to test the updated syscall (-1 or
whatever), so this sounds correct. Was this test actually failing on
powerpc? (I'd really rather not split entry/exit if I don't have to.)

-- 
Kees Cook

Re: [PATCH -next] ide: Fix symbol undeclared warnings

[David Miller]

From: Michael Ellerman 
Date: Thu, 17 Sep 2020 22:01:00 +1000

> Wang Wensheng  writes:
>> Build the object file with `C=2` and get the following warnings:
>> make allmodconfig ARCH=powerpc CROSS_COMPILE=powerpc64-linux-gnu-
>> make C=2 drivers/ide/pmac.o ARCH=powerpc64
>> CROSS_COMPILE=powerpc64-linux-gnu-
>>
>> drivers/ide/pmac.c:228:23: warning: symbol 'mdma_timings_33' was not
>> declared. Should it be static?
>> drivers/ide/pmac.c:241:23: warning: symbol 'mdma_timings_33k' was not
>> declared. Should it be static?
>> drivers/ide/pmac.c:254:23: warning: symbol 'mdma_timings_66' was not
>> declared. Should it be static?
>> drivers/ide/pmac.c:272:3: warning: symbol 'kl66_udma_timings' was not
>> declared. Should it be static?
>> drivers/ide/pmac.c:1418:12: warning: symbol 'pmac_ide_probe' was not
>> declared. Should it be static?
>>
>> Signed-off-by: Wang Wensheng 
>> ---
>>  drivers/ide/pmac.c | 10 +-
>>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> TIL davem maintains IDE?
> 
> But I suspect he isn't that interested in this powerpc only driver, so
> I'll grab this.

I did have it in my queue, but if you want to take it that's fine too :)

Re: [trivial PATCH] treewide: Convert switch/case fallthrough; to break;

[Jacob Keller]

On 9/9/2020 1:55 PM, Keith Busch wrote:
> On Wed, Sep 09, 2020 at 01:06:39PM -0700, Joe Perches wrote:
>> diff --git a/crypto/tcrypt.c b/crypto/tcrypt.c
>> index eea0f453cfb6..8aac5bc60f4c 100644
>> --- a/crypto/tcrypt.c
>> +++ b/crypto/tcrypt.c
>> @@ -2464,7 +2464,7 @@ static int do_test(const char *alg, u32 type, u32 
>> mask, int m, u32 num_mb)
>>  test_hash_speed("streebog512", sec,
>>  generic_hash_speed_template);
>>  if (mode > 300 && mode < 400) break;
>> -fallthrough;
>> +break;
>>  case 399:
>>  break;
> 
> Just imho, this change makes the preceding 'if' look even more
> pointless. Maybe the fallthrough was a deliberate choice? Not that my
> opinion matters here as I don't know this module, but it looked a bit
> odd to me.
> 

Yea this does look very odd..

Re: [PATCH] ASoC: fsl_audmix: make clock and output src write only

[Mark Brown]

On Mon, 14 Sep 2020 20:24:34 +0300, Viorel Suman (OSS) wrote:
> "alsactl -f state.conf store/restore" sequence fails because setting
> "mixing clock source" and "output source" requires active TDM clock
> being started for configuration propagation. Make these two controls
> write only so that their values are not stored at "alsactl store".

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next

Thanks!

[1/1] ASoC: fsl_audmix: make clock and output src write only
  commit: 944c517b8c838832a166f1c89afbf8724f4a6b49

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

Re: [PATCH -next] PCI: rpadlpar: use for_each_child_of_node() and for_each_node_by_name

[Bjorn Helgaas]

On Wed, Sep 16, 2020 at 02:21:28PM +0800, Qinglang Miao wrote:
> Use for_each_child_of_node() and for_each_node_by_name macro
> instead of open coding it.
> 
> Signed-off-by: Qinglang Miao 

Applied to pci/hotplug for v5.10, thanks!

> ---
>  drivers/pci/hotplug/rpadlpar_core.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/pci/hotplug/rpadlpar_core.c 
> b/drivers/pci/hotplug/rpadlpar_core.c
> index f979b7098..0a3c80ba6 100644
> --- a/drivers/pci/hotplug/rpadlpar_core.c
> +++ b/drivers/pci/hotplug/rpadlpar_core.c
> @@ -40,13 +40,13 @@ static DEFINE_MUTEX(rpadlpar_mutex);
>  static struct device_node *find_vio_slot_node(char *drc_name)
>  {
>   struct device_node *parent = of_find_node_by_name(NULL, "vdevice");
> - struct device_node *dn = NULL;
> + struct device_node *dn;
>   int rc;
>  
>   if (!parent)
>   return NULL;
>  
> - while ((dn = of_get_next_child(parent, dn))) {
> + for_each_child_of_node(parent, dn) {
>   rc = rpaphp_check_drc_props(dn, drc_name, NULL);
>   if (rc == 0)
>   break;
> @@ -60,10 +60,10 @@ static struct device_node *find_vio_slot_node(char 
> *drc_name)
>  static struct device_node *find_php_slot_pci_node(char *drc_name,
> char *drc_type)
>  {
> - struct device_node *np = NULL;
> + struct device_node *np;
>   int rc;
>  
> - while ((np = of_find_node_by_name(np, "pci"))) {
> + for_each_node_by_name(np, "pci") {
>   rc = rpaphp_check_drc_props(np, drc_name, drc_type);
>   if (rc == 0)
>   break;
> -- 
> 2.23.0
> 

Re: [PATCHv7 00/12]PCI: dwc: Add the multiple PF support for DWC and Layerscape

[Lorenzo Pieralisi]

On Tue, Aug 11, 2020 at 05:54:29PM +0800, Zhiqiang Hou wrote:
> From: Hou Zhiqiang 
> 
> Add the PCIe EP multiple PF support for DWC and Layerscape, and use
> a list to manage the PFs of each PCIe controller; add the doorbell
> MSIX function for DWC; and refactor the Layerscape EP driver due to
> some difference in Layercape platforms PCIe integration.
> 
> Hou Zhiqiang (1):
>   misc: pci_endpoint_test: Add driver data for Layerscape PCIe
> controllers
> 
> Xiaowei Bao (11):
>   PCI: designware-ep: Add multiple PFs support for DWC
>   PCI: designware-ep: Add the doorbell mode of MSI-X in EP mode
>   PCI: designware-ep: Move the function of getting MSI capability
> forward
>   PCI: designware-ep: Modify MSI and MSIX CAP way of finding
>   dt-bindings: pci: layerscape-pci: Add compatible strings for ls1088a
> and ls2088a
>   PCI: layerscape: Fix some format issue of the code
>   PCI: layerscape: Modify the way of getting capability with different
> PEX
>   PCI: layerscape: Modify the MSIX to the doorbell mode
>   PCI: layerscape: Add EP mode support for ls1088a and ls2088a
>   arm64: dts: layerscape: Add PCIe EP node for ls1088a
>   misc: pci_endpoint_test: Add LS1088a in pci_device_id table
> 
>  .../bindings/pci/layerscape-pci.txt   |   2 +
>  .../arm64/boot/dts/freescale/fsl-ls1088a.dtsi |  31 +++
>  drivers/misc/pci_endpoint_test.c  |   8 +-
>  .../pci/controller/dwc/pci-layerscape-ep.c| 100 +--
>  .../pci/controller/dwc/pcie-designware-ep.c   | 258 ++
>  drivers/pci/controller/dwc/pcie-designware.c  |  59 ++--
>  drivers/pci/controller/dwc/pcie-designware.h  |  48 +++-
>  7 files changed, 410 insertions(+), 96 deletions(-)

Side note: I will change it for you but please keep Signed-off-by:
tags together in the log instead of mixing them with other tags
randomly.

Can you rebase this series against my pci/dwc branch please and
send a v8 ?

I will apply it then.

Thanks,
Lorenzo

Re: [PATCH v4] pseries/hotplug-memory: hot-add: skip redundant LMB lookup

[Laurent Dufour]

Le 16/09/2020 à 16:51, Scott Cheloha a écrit :

During memory hot-add, dlpar_add_lmb() calls memory_add_physaddr_to_nid()
to determine which node id (nid) to use when later calling __add_memory().

This is wasteful.  On pseries, memory_add_physaddr_to_nid() finds an
appropriate nid for a given address by looking up the LMB containing the
address and then passing that LMB to of_drconf_to_nid_single() to get the
nid.  In dlpar_add_lmb() we get this address from the LMB itself.

In short, we have a pointer to an LMB and then we are searching for
that LMB *again* in order to find its nid.

If we call of_drconf_to_nid_single() directly from dlpar_add_lmb() we
can skip the redundant lookup.  The only error handling we need to
duplicate from memory_add_physaddr_to_nid() is the fallback to the
default nid when drconf_to_nid_single() returns -1 (NUMA_NO_NODE) or
an invalid nid.

Skipping the extra lookup makes hot-add operations faster, especially
on machines with many LMBs.

Consider an LPAR with 126976 LMBs.  In one test, hot-adding 126000
LMBs on an upatched kernel took ~3.5 hours while a patched kernel
completed the same operation in ~2 hours:

Unpatched (12450 seconds):
Sep  9 04:06:31 ltc-brazos1 drmgr[810169]: drmgr: -c mem -a -q 126000
Sep  9 04:06:31 ltc-brazos1 kernel: pseries-hotplug-mem: Attempting to hot-add 
126000 LMB(s)
[...]
Sep  9 07:34:01 ltc-brazos1 kernel: pseries-hotplug-mem: Memory at 2000 
(drc index 8002) was hot-added

Patched (7065 seconds):
Sep  8 21:49:57 ltc-brazos1 drmgr[877703]: drmgr: -c mem -a -q 126000
Sep  8 21:49:57 ltc-brazos1 kernel: pseries-hotplug-mem: Attempting to hot-add 
126000 LMB(s)
[...]
Sep  8 23:27:42 ltc-brazos1 kernel: pseries-hotplug-mem: Memory at 2000 
(drc index 8002) was hot-added

It should be noted that the speedup grows more substantial when
hot-adding LMBs at the end of the drconf range.  This is because we
are skipping a linear LMB search.

To see the distinction, consider smaller hot-add test on the same
LPAR.  A perf-stat run with 10 iterations showed that hot-adding 4096
LMBs completed less than 1 second faster on a patched kernel:

Unpatched:
  Performance counter stats for 'drmgr -c mem -a -q 4096' (10 runs):

 104,753.42 msec task-clock#0.992 CPUs utilized 
   ( +-  0.55% )
  4,708  context-switches  #0.045 K/sec 
   ( +-  0.69% )
  2,444  cpu-migrations#0.023 K/sec 
   ( +-  1.25% )
394  page-faults   #0.004 K/sec 
   ( +-  0.22% )
445,902,503,057  cycles#4.257 GHz   
   ( +-  0.55% )  (66.67%)
  8,558,376,740  stalled-cycles-frontend   #1.92% frontend cycles 
idle ( +-  0.88% )  (49.99%)
300,346,181,651  stalled-cycles-backend#   67.36% backend cycles 
idle  ( +-  0.76% )  (50.01%)
258,091,488,691  instructions  #0.58  insn per cycle
   #1.16  stalled cycles 
per insn  ( +-  0.22% )  (66.67%)
 70,568,169,256  branches  #  673.660 M/sec 
   ( +-  0.17% )  (50.01%)
  3,100,725,426  branch-misses #4.39% of all branches   
   ( +-  0.20% )  (49.99%)

105.583 +- 0.589 seconds time elapsed  ( +-  0.56% )

Patched:
  Performance counter stats for 'drmgr -c mem -a -q 4096' (10 runs):

 104,055.69 msec task-clock#0.993 CPUs utilized 
   ( +-  0.32% )
  4,606  context-switches  #0.044 K/sec 
   ( +-  0.20% )
  2,463  cpu-migrations#0.024 K/sec 
   ( +-  0.93% )
394  page-faults   #0.004 K/sec 
   ( +-  0.25% )
442,951,129,921  cycles#4.257 GHz   
   ( +-  0.32% )  (66.66%)
  8,710,413,329  stalled-cycles-frontend   #1.97% frontend cycles 
idle ( +-  0.47% )  (50.06%)
299,656,905,836  stalled-cycles-backend#   67.65% backend cycles 
idle  ( +-  0.39% )  (50.02%)
252,731,168,193  instructions  #0.57  insn per cycle
   #1.19  stalled cycles 
per insn  ( +-  0.20% )  (66.66%)
 68,902,851,121  branches  #  662.173 M/sec 
   ( +-  0.13% )  (49.94%)
  3,100,242,882  branch-misses #4.50% of all branches   
   ( +-  0.15% )  (49.98%)

104.829 +- 0.325 seconds time elapsed  ( +-  0.31% )

This is consistent.  An add-by-count hot-add operation adds LMBs
greedily, so LMBs near the start of the drconf range are considered
first.  On an otherwise idle LPAR with so many LMBs we would expect to
find the LMBs we need near the start of the 

Re: [PATCH v2] powerpc: fix EDEADLOCK redefinition error in uapi/asm/errno.h

[Andreas Schwab]

On Sep 17 2020, Arnd Bergmann wrote:

> The errno man page says they are supposed to be synonyms,
> and glibc defines it that way, while musl uses the numbers
> from the kernel.

glibc also uses whatever the kernel defines.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: [PATCH v2] powerpc: fix EDEADLOCK redefinition error in uapi/asm/errno.h

[Arnd Bergmann]

On Thu, Sep 17, 2020 at 1:55 PM Michael Ellerman  wrote:
>
> [ Cc += linux-arch & Arnd ]
>
> Hi Tony,
>
> This looks OK to me, but I'm always a bit nervous about changes in uapi.
> I've Cc'ed linux-arch and Arnd who look after the asm-generic headers,
> which this is slightly related to, just in case.
>
> One minor comment below.
>
> Tony Ambardar  writes:
> > A few archs like powerpc have different errno.h values for macros
> > EDEADLOCK and EDEADLK. In code including both libc and linux versions of
> > errno.h, this can result in multiple definitions of EDEADLOCK in the
> > include chain. Definitions to the same value (e.g. seen with mips) do
> > not raise warnings, but on powerpc there are redefinitions changing the
> > value, which raise warnings and errors (if using "-Werror").
> >
> > Guard against these redefinitions to avoid build errors like the following,
> > first seen cross-compiling libbpf v5.8.9 for powerpc using GCC 8.4.0 with
> > musl 1.1.24:
> >
> >   In file included from ../../arch/powerpc/include/uapi/asm/errno.h:5,
> >from ../../include/linux/err.h:8,
> >from libbpf.c:29:
> >   ../../include/uapi/asm-generic/errno.h:40: error: "EDEADLOCK" redefined 
> > [-Werror]
> >#define EDEADLOCK EDEADLK
> >
> >   In file included from 
> > toolchain-powerpc_8540_gcc-8.4.0_musl/include/errno.h:10,
> >from libbpf.c:26:
> >   toolchain-powerpc_8540_gcc-8.4.0_musl/include/bits/errno.h:58: note: this 
> > is the location of the previous definition
> >#define EDEADLOCK   58
> >
> >   cc1: all warnings being treated as errors
> >
> > Fixes: 95f28190aa01 ("tools include arch: Grab a copy of errno.h for arch's 
> > supported by perf")
> > Fixes: c3617f72036c ("UAPI: (Scripted) Disintegrate 
> > arch/powerpc/include/asm")
>
> I suspect that's not the right commit to tag. It just moved errno.h from
> arch/powerpc/include/asm to arch/powerpc/include/uapi/asm. It's content
> was almost identical, and entirely identical as far as EDEADLOCK was
> concerned.
>
> Prior to that the file lived in asm-powerpc/errno.h, eg:
>
> $ git cat-file -p b8b572e1015f^:include/asm-powerpc/errno.h
>
> Before that it was include/asm-ppc64/errno.h, content still the same.
>
> To go back further we'd have to look at the historical git trees, which
> is probably overkill. I'm pretty sure it's always had this problem.
>
> So we should probably drop the Fixes tags and just Cc: stable, that
> means please backport it as far back as possible.

I can see that the two numbers (35 and 58) were consistent across
multiple architectures (i386, m68k, ppc32) up to linux-2.0.1, while
other architectures had two unique numbers (alpha, mips, sparc)
at the time, and sparc had BSD and Solaris compatible numbers
in addition.

In linux-2.0.2, alpha and i386 got changed to use 35 for both,
but the other architectures remained unchanged. All later
architectures followed x86 in using the same number for both.

I foudn a message about tcl breaking at compile time when
it changed:
http://lkml.iu.edu/hypermail/linux/kernel/9607.3/0500.html

The errno man page says they are supposed to be synonyms,
and glibc defines it that way, while musl uses the numbers
from the kernel.

Arnd

[PATCH v3] powerpc: fix EDEADLOCK redefinition error in uapi/asm/errno.h

[Tony Ambardar]

A few archs like powerpc have different errno.h values for macros
EDEADLOCK and EDEADLK. In code including both libc and linux versions of
errno.h, this can result in multiple definitions of EDEADLOCK in the
include chain. Definitions to the same value (e.g. seen with mips) do
not raise warnings, but on powerpc there are redefinitions changing the
value, which raise warnings and errors (if using "-Werror").

Guard against these redefinitions to avoid build errors like the following,
first seen cross-compiling libbpf v5.8.9 for powerpc using GCC 8.4.0 with
musl 1.1.24:

  In file included from ../../arch/powerpc/include/uapi/asm/errno.h:5,
   from ../../include/linux/err.h:8,
   from libbpf.c:29:
  ../../include/uapi/asm-generic/errno.h:40: error: "EDEADLOCK" redefined 
[-Werror]
   #define EDEADLOCK EDEADLK

  In file included from 
toolchain-powerpc_8540_gcc-8.4.0_musl/include/errno.h:10,
   from libbpf.c:26:
  toolchain-powerpc_8540_gcc-8.4.0_musl/include/bits/errno.h:58: note: this is 
the location of the previous definition
   #define EDEADLOCK   58

  cc1: all warnings being treated as errors

CC: Stable 
Reported-by: Rosen Penev 
Signed-off-by: Tony Ambardar 
---
v1 -> v2:
 * clean up commit description formatting

v2 -> v3: (per Michael Ellerman)
 * drop indeterminate 'Fixes' tags, request stable backports instead 
---
 arch/powerpc/include/uapi/asm/errno.h   | 1 +
 tools/arch/powerpc/include/uapi/asm/errno.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/arch/powerpc/include/uapi/asm/errno.h 
b/arch/powerpc/include/uapi/asm/errno.h
index cc79856896a1..4ba87de32be0 100644
--- a/arch/powerpc/include/uapi/asm/errno.h
+++ b/arch/powerpc/include/uapi/asm/errno.h
@@ -2,6 +2,7 @@
 #ifndef _ASM_POWERPC_ERRNO_H
 #define _ASM_POWERPC_ERRNO_H
 
+#undef EDEADLOCK
 #include 
 
 #undef EDEADLOCK
diff --git a/tools/arch/powerpc/include/uapi/asm/errno.h 
b/tools/arch/powerpc/include/uapi/asm/errno.h
index cc79856896a1..4ba87de32be0 100644
--- a/tools/arch/powerpc/include/uapi/asm/errno.h
+++ b/tools/arch/powerpc/include/uapi/asm/errno.h
@@ -2,6 +2,7 @@
 #ifndef _ASM_POWERPC_ERRNO_H
 #define _ASM_POWERPC_ERRNO_H
 
+#undef EDEADLOCK
 #include 
 
 #undef EDEADLOCK
-- 
2.25.1

Re: [PATCH 1/2] ASoC: fsl_xcvr: Add XCVR ASoC CPU DAI driver

[Mark Brown]

On Wed, Sep 16, 2020 at 12:17:55PM +0300, Viorel Suman (OSS) wrote:

This looks mostly good, a few smallish things below but nothing major.

> +static int fsl_xcvr_load_firmware(struct fsl_xcvr *xcvr)
> +{
> + struct device *dev = >pdev->dev;
> + const struct firmware *fw;
> + int ret = 0, rem, off, out, page = 0, size = FSL_XCVR_REG_OFFSET;
> + u32 mask, val;
> +
> + ret = request_firmware(, xcvr->fw_name, dev);
> + if (ret) {
> + dev_err(dev, "failed to request firmware.\n");
> + return ret;
> + }
> +
> + rem = fw->size;

It would be good to see some explicit validation of the image size, at
least printing an error message if the image is bigger than can be
loaded.  The code should be safe in that it won't overflow the device
region it's writing to but it feels like it'd be better to tell people
if we spot a problem rather than just silently truncating the file.

> + /* RAM is 20KiB => max 10 pages 2KiB each */
> + for (page = 0; page < 10; page++) {
> + ret = regmap_update_bits(xcvr->regmap, FSL_XCVR_EXT_CTRL,
> +  FSL_XCVR_EXT_CTRL_PAGE_MASK,
> +  FSL_XCVR_EXT_CTRL_PAGE(page));

regmap does have paging support, though given that this is currently the
only place where paging is used this probably doesn't matter too much.

> +static irqreturn_t irq0_isr(int irq, void *devid)
> +{
> + struct fsl_xcvr *xcvr = (struct fsl_xcvr *)devid;
> + struct device *dev = >pdev->dev;
> + struct regmap *regmap = xcvr->regmap;
> + void __iomem *reg_ctrl, *reg_buff;
> + u32 isr, val, i;
> +
> + regmap_read(regmap, FSL_XCVR_EXT_ISR, );
> + regmap_write(regmap, FSL_XCVR_EXT_ISR_CLR, isr);

This will unconditionally clear any interrupts, even those we don't
understand - it might be better to only clear bits that are supported so
the IRQ core can complain if there's something unexpected showing up.

> + if (isr & FSL_XCVR_IRQ_FIFO_UOFL_ERR)
> + dev_dbg(dev, "RX/TX FIFO full/empty\n");

Should this be dev_err()?

> +static irqreturn_t irq1_isr(int irq, void *devid)
> +{
> + struct fsl_xcvr *xcvr = (struct fsl_xcvr *)devid;
> + struct device *dev = >pdev->dev;
> +
> + dev_dbg(dev, "irq[1]: %d\n", irq);
> +
> + return IRQ_HANDLED;
> +}

Is there any value in even requesting this and irq2 given the lack of
meaningful handling?


signature.asc
Description: PGP signature

Re: [PATCH v2] powerpc: fix EDEADLOCK redefinition error in uapi/asm/errno.h

[Tony Ambardar]

On Thu, 17 Sep 2020 at 04:55, Michael Ellerman  wrote:
>
> [ Cc += linux-arch & Arnd ]
>
> Hi Tony,
>
> This looks OK to me, but I'm always a bit nervous about changes in uapi.
> I've Cc'ed linux-arch and Arnd who look after the asm-generic headers,
> which this is slightly related to, just in case.
>
I agree with the caution and would welcome any other insights.

> One minor comment below.
>
> Tony Ambardar  writes:
> > A few archs like powerpc have different errno.h values for macros
> > EDEADLOCK and EDEADLK. In code including both libc and linux versions of
> > errno.h, this can result in multiple definitions of EDEADLOCK in the
> > include chain. Definitions to the same value (e.g. seen with mips) do
> > not raise warnings, but on powerpc there are redefinitions changing the
> > value, which raise warnings and errors (if using "-Werror").
> >
> > Guard against these redefinitions to avoid build errors like the following,
> > first seen cross-compiling libbpf v5.8.9 for powerpc using GCC 8.4.0 with
> > musl 1.1.24:
> >
> >   In file included from ../../arch/powerpc/include/uapi/asm/errno.h:5,
> >from ../../include/linux/err.h:8,
> >from libbpf.c:29:
> >   ../../include/uapi/asm-generic/errno.h:40: error: "EDEADLOCK" redefined 
> > [-Werror]
> >#define EDEADLOCK EDEADLK
> >
> >   In file included from 
> > toolchain-powerpc_8540_gcc-8.4.0_musl/include/errno.h:10,
> >from libbpf.c:26:
> >   toolchain-powerpc_8540_gcc-8.4.0_musl/include/bits/errno.h:58: note: this 
> > is the location of the previous definition
> >#define EDEADLOCK   58
> >
> >   cc1: all warnings being treated as errors
> >
> > Fixes: 95f28190aa01 ("tools include arch: Grab a copy of errno.h for arch's 
> > supported by perf")
> > Fixes: c3617f72036c ("UAPI: (Scripted) Disintegrate 
> > arch/powerpc/include/asm")
>
> I suspect that's not the right commit to tag. It just moved errno.h from
> arch/powerpc/include/asm to arch/powerpc/include/uapi/asm. It's content
> was almost identical, and entirely identical as far as EDEADLOCK was
> concerned.
>
> Prior to that the file lived in asm-powerpc/errno.h, eg:
>
> $ git cat-file -p b8b572e1015f^:include/asm-powerpc/errno.h
>
> Before that it was include/asm-ppc64/errno.h, content still the same.
>
> To go back further we'd have to look at the historical git trees, which
> is probably overkill. I'm pretty sure it's always had this problem.
>
> So we should probably drop the Fixes tags and just Cc: stable, that
> means please backport it as far back as possible.
>
Yes, you're right. Those two commits were simply where I stopped tracing back
the long chain. I'll drop them as you suggest and request a backport instead in
the next version of the patch.

Thanks for your feedback!
> cheers
>
>
> > Reported-by: Rosen Penev 
> > Signed-off-by: Tony Ambardar 
> > ---
> > v1 -> v2:
> >  * clean up commit description formatting
> > ---
> >  arch/powerpc/include/uapi/asm/errno.h   | 1 +
> >  tools/arch/powerpc/include/uapi/asm/errno.h | 1 +
> >  2 files changed, 2 insertions(+)
> >
> > diff --git a/arch/powerpc/include/uapi/asm/errno.h 
> > b/arch/powerpc/include/uapi/asm/errno.h
> > index cc79856896a1..4ba87de32be0 100644
> > --- a/arch/powerpc/include/uapi/asm/errno.h
> > +++ b/arch/powerpc/include/uapi/asm/errno.h
> > @@ -2,6 +2,7 @@
> >  #ifndef _ASM_POWERPC_ERRNO_H
> >  #define _ASM_POWERPC_ERRNO_H
> >
> > +#undef   EDEADLOCK
> >  #include 
> >
> >  #undef   EDEADLOCK
> > diff --git a/tools/arch/powerpc/include/uapi/asm/errno.h 
> > b/tools/arch/powerpc/include/uapi/asm/errno.h
> > index cc79856896a1..4ba87de32be0 100644
> > --- a/tools/arch/powerpc/include/uapi/asm/errno.h
> > +++ b/tools/arch/powerpc/include/uapi/asm/errno.h
> > @@ -2,6 +2,7 @@
> >  #ifndef _ASM_POWERPC_ERRNO_H
> >  #define _ASM_POWERPC_ERRNO_H
> >
> > +#undef   EDEADLOCK
> >  #include 
> >
> >  #undef   EDEADLOCK
> > --
> > 2.25.1

Re: [PATCH v6 8/8] powerpc/watchpoint/selftests: Tests for kernel accessing user memory

[Rogerio Alves]

On 9/2/20 1:29 AM, Ravi Bangoria wrote:

Introduce tests to cover simple scenarios where user is watching
memory which can be accessed by kernel as well. We also support
_MODE_EXACT with _SETHWDEBUG interface. Move those testcases out-
side of _BP_RANGE condition. This will help to test _MODE_EXACT
scenarios when CONFIG_HAVE_HW_BREAKPOINT is not set, eg:

   $ ./ptrace-hwbreak
   ...
   PTRACE_SET_DEBUGREG, Kernel Access Userspace, len: 8: Ok
   PPC_PTRACE_SETHWDEBUG, MODE_EXACT, WO, len: 1: Ok
   PPC_PTRACE_SETHWDEBUG, MODE_EXACT, RO, len: 1: Ok
   PPC_PTRACE_SETHWDEBUG, MODE_EXACT, RW, len: 1: Ok
   PPC_PTRACE_SETHWDEBUG, MODE_EXACT, Kernel Access Userspace, len: 1: Ok
   success: ptrace-hwbreak

Suggested-by: Pedro Miraglia Franco de Carvalho 
Signed-off-by: Ravi Bangoria 

Tested-by: Rogerio Alves 

---
  .../selftests/powerpc/ptrace/ptrace-hwbreak.c | 48 ++-
  1 file changed, 46 insertions(+), 2 deletions(-)

diff --git a/tools/testing/selftests/powerpc/ptrace/ptrace-hwbreak.c 
b/tools/testing/selftests/powerpc/ptrace/ptrace-hwbreak.c
index fc477dfe86a2..2e0d86e0687e 100644
--- a/tools/testing/selftests/powerpc/ptrace/ptrace-hwbreak.c
+++ b/tools/testing/selftests/powerpc/ptrace/ptrace-hwbreak.c
@@ -20,6 +20,8 @@
  #include 
  #include 
  #include 
+#include 
+#include 
  #include "ptrace.h"
  
  #define SPRN_PVR	0x11F

@@ -44,6 +46,7 @@ struct gstruct {
  };
  static volatile struct gstruct gstruct __attribute__((aligned(512)));
  
+static volatile char cwd[PATH_MAX] __attribute__((aligned(8)));
  
  static void get_dbginfo(pid_t child_pid, struct ppc_debug_info *dbginfo)

  {
@@ -138,6 +141,9 @@ static void test_workload(void)
write_var(len);
}
  
+	/* PTRACE_SET_DEBUGREG, Kernel Access Userspace test */

+   syscall(__NR_getcwd, , PATH_MAX);
+
/* PPC_PTRACE_SETHWDEBUG, MODE_EXACT, WO test */
write_var(1);
  
@@ -150,6 +156,9 @@ static void test_workload(void)

else
read_var(1);
  
+	/* PPC_PTRACE_SETHWDEBUG, MODE_EXACT, Kernel Access Userspace test */

+   syscall(__NR_getcwd, , PATH_MAX);
+
/* PPC_PTRACE_SETHWDEBUG, MODE_RANGE, DW ALIGNED, WO test */
gstruct.a[rand() % A_LEN] = 'a';
  
@@ -293,6 +302,24 @@ static int test_set_debugreg(pid_t child_pid)

return 0;
  }
  
+static int test_set_debugreg_kernel_userspace(pid_t child_pid)

+{
+   unsigned long wp_addr = (unsigned long)cwd;
+   char *name = "PTRACE_SET_DEBUGREG";
+
+   /* PTRACE_SET_DEBUGREG, Kernel Access Userspace test */
+   wp_addr &= ~0x7UL;
+   wp_addr |= (1Ul << DABR_READ_SHIFT);
+   wp_addr |= (1UL << DABR_WRITE_SHIFT);
+   wp_addr |= (1UL << DABR_TRANSLATION_SHIFT);
+   ptrace_set_debugreg(child_pid, wp_addr);
+   ptrace(PTRACE_CONT, child_pid, NULL, 0);
+   check_success(child_pid, name, "Kernel Access Userspace", wp_addr, 8);
+
+   ptrace_set_debugreg(child_pid, 0);
+   return 0;
+}
+
  static void get_ppc_hw_breakpoint(struct ppc_hw_breakpoint *info, int type,
  unsigned long addr, int len)
  {
@@ -338,6 +365,22 @@ static void test_sethwdebug_exact(pid_t child_pid)
ptrace_delhwdebug(child_pid, wh);
  }
  
+static void test_sethwdebug_exact_kernel_userspace(pid_t child_pid)

+{
+   struct ppc_hw_breakpoint info;
+   unsigned long wp_addr = (unsigned long)
+   char *name = "PPC_PTRACE_SETHWDEBUG, MODE_EXACT";
+   int len = 1; /* hardcoded in kernel */
+   int wh;
+
+   /* PPC_PTRACE_SETHWDEBUG, MODE_EXACT, Kernel Access Userspace test */
+   get_ppc_hw_breakpoint(, PPC_BREAKPOINT_TRIGGER_WRITE, wp_addr, 0);
+   wh = ptrace_sethwdebug(child_pid, );
+   ptrace(PTRACE_CONT, child_pid, NULL, 0);
+   check_success(child_pid, name, "Kernel Access Userspace", wp_addr, len);
+   ptrace_delhwdebug(child_pid, wh);
+}
+
  static void test_sethwdebug_range_aligned(pid_t child_pid)
  {
struct ppc_hw_breakpoint info;
@@ -452,9 +495,10 @@ static void
  run_tests(pid_t child_pid, struct ppc_debug_info *dbginfo, bool dawr)
  {
test_set_debugreg(child_pid);
+   test_set_debugreg_kernel_userspace(child_pid);
+   test_sethwdebug_exact(child_pid);
+   test_sethwdebug_exact_kernel_userspace(child_pid);
if (dbginfo->features & PPC_DEBUG_FEATURE_DATA_BP_RANGE) {
-   test_sethwdebug_exact(child_pid);
-
test_sethwdebug_range_aligned(child_pid);
if (dawr || is_8xx) {
test_sethwdebug_range_unaligned(child_pid);

Re: [PATCH v6 7/8] powerpc/watchpoint/ptrace: Introduce PPC_DEBUG_FEATURE_DATA_BP_ARCH_31

[Rogerio Alves]

On 9/2/20 1:29 AM, Ravi Bangoria wrote:

PPC_DEBUG_FEATURE_DATA_BP_ARCH_31 can be used to determine whether
we are running on an ISA 3.1 compliant machine. Which is needed to
determine DAR behaviour, 512 byte boundary limit etc. This was
requested by Pedro Miraglia Franco de Carvalho for extending
watchpoint features in gdb. Note that availability of 2nd DAWR is
independent of this flag and should be checked using
ppc_debug_info->num_data_bps.

Signed-off-by: Ravi Bangoria 

Tested-by: Rogerio Alves 

---
  Documentation/powerpc/ptrace.rst  | 1 +
  arch/powerpc/include/uapi/asm/ptrace.h| 1 +
  arch/powerpc/kernel/ptrace/ptrace-noadv.c | 2 ++
  3 files changed, 4 insertions(+)

diff --git a/Documentation/powerpc/ptrace.rst b/Documentation/powerpc/ptrace.rst
index 864d4b61..77725d69eb4a 100644
--- a/Documentation/powerpc/ptrace.rst
+++ b/Documentation/powerpc/ptrace.rst
@@ -46,6 +46,7 @@ features will have bits indicating whether there is support 
for::
#define PPC_DEBUG_FEATURE_DATA_BP_RANGE 0x4
#define PPC_DEBUG_FEATURE_DATA_BP_MASK  0x8
#define PPC_DEBUG_FEATURE_DATA_BP_DAWR  0x10
+  #define PPC_DEBUG_FEATURE_DATA_BP_ARCH_310x20
  
  2. PTRACE_SETHWDEBUG
  
diff --git a/arch/powerpc/include/uapi/asm/ptrace.h b/arch/powerpc/include/uapi/asm/ptrace.h

index f5f1ccc740fc..7004cfea3f5f 100644
--- a/arch/powerpc/include/uapi/asm/ptrace.h
+++ b/arch/powerpc/include/uapi/asm/ptrace.h
@@ -222,6 +222,7 @@ struct ppc_debug_info {
  #define PPC_DEBUG_FEATURE_DATA_BP_RANGE   0x0004
  #define PPC_DEBUG_FEATURE_DATA_BP_MASK0x0008
  #define PPC_DEBUG_FEATURE_DATA_BP_DAWR0x0010
+#define PPC_DEBUG_FEATURE_DATA_BP_ARCH_31  0x0020
  
  #ifndef __ASSEMBLY__
  
diff --git a/arch/powerpc/kernel/ptrace/ptrace-noadv.c b/arch/powerpc/kernel/ptrace/ptrace-noadv.c

index 48c52426af80..aa36fcad36cd 100644
--- a/arch/powerpc/kernel/ptrace/ptrace-noadv.c
+++ b/arch/powerpc/kernel/ptrace/ptrace-noadv.c
@@ -57,6 +57,8 @@ void ppc_gethwdinfo(struct ppc_debug_info *dbginfo)
} else {
dbginfo->features = 0;
}
+   if (cpu_has_feature(CPU_FTR_ARCH_31))
+   dbginfo->features |= PPC_DEBUG_FEATURE_DATA_BP_ARCH_31;
  }
  
  int ptrace_get_debugreg(struct task_struct *child, unsigned long addr,

Re: [PATCH v6 6/8] powerpc/watchpoint: Add hw_len wherever missing

[Rogerio Alves]

On 9/2/20 1:29 AM, Ravi Bangoria wrote:

There are couple of places where we set len but not hw_len. For
ptrace/perf watchpoints, when CONFIG_HAVE_HW_BREAKPOINT=Y, hw_len
will be calculated and set internally while parsing watchpoint.
But when CONFIG_HAVE_HW_BREAKPOINT=N, we need to manually set
'hw_len'. Similarly for xmon as well, hw_len needs to be set
directly.

Fixes: b57aeab811db ("powerpc/watchpoint: Fix length calculation for unaligned 
target")
Signed-off-by: Ravi Bangoria 

Tested-by: Rogerio Alves 

---
  arch/powerpc/kernel/ptrace/ptrace-noadv.c | 1 +
  arch/powerpc/xmon/xmon.c  | 1 +
  2 files changed, 2 insertions(+)

diff --git a/arch/powerpc/kernel/ptrace/ptrace-noadv.c 
b/arch/powerpc/kernel/ptrace/ptrace-noadv.c
index c9122ed91340..48c52426af80 100644
--- a/arch/powerpc/kernel/ptrace/ptrace-noadv.c
+++ b/arch/powerpc/kernel/ptrace/ptrace-noadv.c
@@ -219,6 +219,7 @@ long ppc_set_hwdebug(struct task_struct *child, struct 
ppc_hw_breakpoint *bp_inf
brk.address = ALIGN_DOWN(bp_info->addr, HW_BREAKPOINT_SIZE);
brk.type = HW_BRK_TYPE_TRANSLATE | HW_BRK_TYPE_PRIV_ALL;
brk.len = DABR_MAX_LEN;
+   brk.hw_len = DABR_MAX_LEN;
if (bp_info->trigger_type & PPC_BREAKPOINT_TRIGGER_READ)
brk.type |= HW_BRK_TYPE_READ;
if (bp_info->trigger_type & PPC_BREAKPOINT_TRIGGER_WRITE)
diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index df7bca00f5ec..55c43a6c9111 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -969,6 +969,7 @@ static void insert_cpu_bpts(void)
brk.address = dabr[i].address;
brk.type = (dabr[i].enabled & HW_BRK_TYPE_DABR) | 
HW_BRK_TYPE_PRIV_ALL;
brk.len = 8;
+   brk.hw_len = 8;
__set_breakpoint(i, );
}
}

Re: [PATCH v6 5/8] powerpc/watchpoint: Fix exception handling for CONFIG_HAVE_HW_BREAKPOINT=N

[Rogerio Alves]

On 9/2/20 1:29 AM, Ravi Bangoria wrote:

On powerpc, ptrace watchpoint works in one-shot mode. i.e. kernel
disables event every time it fires and user has to re-enable it.
Also, in case of ptrace watchpoint, kernel notifies ptrace user
before executing instruction.

With CONFIG_HAVE_HW_BREAKPOINT=N, kernel is missing to disable
ptrace event and thus it's causing infinite loop of exceptions.
This is especially harmful when user watches on a data which is
also read/written by kernel, eg syscall parameters. In such case,
infinite exceptions happens in kernel mode which causes soft-lockup.

Fixes: 9422de3e953d ("powerpc: Hardware breakpoints rewrite to handle non DABR 
breakpoint registers")
Reported-by: Pedro Miraglia Franco de Carvalho 
Signed-off-by: Ravi Bangoria 

Tested-by: Rogerio Alves 

---
  arch/powerpc/include/asm/hw_breakpoint.h  |  3 ++
  arch/powerpc/kernel/process.c | 48 +++
  arch/powerpc/kernel/ptrace/ptrace-noadv.c |  4 +-
  3 files changed, 54 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/include/asm/hw_breakpoint.h 
b/arch/powerpc/include/asm/hw_breakpoint.h
index 81872c420476..abebfbee5b1c 100644
--- a/arch/powerpc/include/asm/hw_breakpoint.h
+++ b/arch/powerpc/include/asm/hw_breakpoint.h
@@ -18,6 +18,7 @@ struct arch_hw_breakpoint {
u16 type;
u16 len; /* length of the target data symbol */
u16 hw_len; /* length programmed in hw */
+   u8  flags;
  };
  
  /* Note: Don't change the first 6 bits below as they are in the same order

@@ -37,6 +38,8 @@ struct arch_hw_breakpoint {
  #define HW_BRK_TYPE_PRIV_ALL  (HW_BRK_TYPE_USER | HW_BRK_TYPE_KERNEL | \
 HW_BRK_TYPE_HYP)
  
+#define HW_BRK_FLAG_DISABLED	0x1

+
  /* Minimum granularity */
  #ifdef CONFIG_PPC_8xx
  #define HW_BREAKPOINT_SIZE  0x4
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 016bd831908e..160fbbf41d40 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -636,6 +636,44 @@ void do_send_trap(struct pt_regs *regs, unsigned long 
address,
(void __user *)address);
  }
  #else /* !CONFIG_PPC_ADV_DEBUG_REGS */
+
+static void do_break_handler(struct pt_regs *regs)
+{
+   struct arch_hw_breakpoint null_brk = {0};
+   struct arch_hw_breakpoint *info;
+   struct ppc_inst instr = ppc_inst(0);
+   int type = 0;
+   int size = 0;
+   unsigned long ea;
+   int i;
+
+   /*
+* If underneath hw supports only one watchpoint, we know it
+* caused exception. 8xx also falls into this category.
+*/
+   if (nr_wp_slots() == 1) {
+   __set_breakpoint(0, _brk);
+   current->thread.hw_brk[0] = null_brk;
+   current->thread.hw_brk[0].flags |= HW_BRK_FLAG_DISABLED;
+   return;
+   }
+
+   /* Otherwise findout which DAWR caused exception and disable it. */
+   wp_get_instr_detail(regs, , , , );
+
+   for (i = 0; i < nr_wp_slots(); i++) {
+   info = >thread.hw_brk[i];
+   if (!info->address)
+   continue;
+
+   if (wp_check_constraints(regs, instr, ea, type, size, info)) {
+   __set_breakpoint(i, _brk);
+   current->thread.hw_brk[i] = null_brk;
+   current->thread.hw_brk[i].flags |= HW_BRK_FLAG_DISABLED;
+   }
+   }
+}
+
  void do_break (struct pt_regs *regs, unsigned long address,
unsigned long error_code)
  {
@@ -647,6 +685,16 @@ void do_break (struct pt_regs *regs, unsigned long address,
if (debugger_break_match(regs))
return;
  
+	/*

+* We reach here only when watchpoint exception is generated by ptrace
+* event (or hw is buggy!). Now if CONFIG_HAVE_HW_BREAKPOINT is set,
+* watchpoint is already handled by hw_breakpoint_handler() so we don't
+* have to do anything. But when CONFIG_HAVE_HW_BREAKPOINT is not set,
+* we need to manually handle the watchpoint here.
+*/
+   if (!IS_ENABLED(CONFIG_HAVE_HW_BREAKPOINT))
+   do_break_handler(regs);
+
/* Deliver the signal to userspace */
force_sig_fault(SIGTRAP, TRAP_HWBKPT, (void __user *)address);
  }
diff --git a/arch/powerpc/kernel/ptrace/ptrace-noadv.c 
b/arch/powerpc/kernel/ptrace/ptrace-noadv.c
index 57a0ab822334..c9122ed91340 100644
--- a/arch/powerpc/kernel/ptrace/ptrace-noadv.c
+++ b/arch/powerpc/kernel/ptrace/ptrace-noadv.c
@@ -286,11 +286,13 @@ long ppc_del_hwdebug(struct task_struct *child, long data)
}
return ret;
  #else /* CONFIG_HAVE_HW_BREAKPOINT */
-   if (child->thread.hw_brk[data - 1].address == 0)
+   if (!(child->thread.hw_brk[data - 1].flags & HW_BRK_FLAG_DISABLED) &&
+   child->thread.hw_brk[data - 1].address == 0)

Re: [PATCH v6 4/8] powerpc/watchpoint: Move DAWR detection logic outside of hw_breakpoint.c

[Rogerio Alves]

On 9/2/20 1:29 AM, Ravi Bangoria wrote:

Power10 hw has multiple DAWRs but hw doesn't tell which DAWR caused
the exception. So we have a sw logic to detect that in hw_breakpoint.c.
But hw_breakpoint.c gets compiled only with CONFIG_HAVE_HW_BREAKPOINT=Y.
Move DAWR detection logic outside of hw_breakpoint.c so that it can be
reused when CONFIG_HAVE_HW_BREAKPOINT is not set.

Signed-off-by: Ravi Bangoria 

Tested-by: Rogerio Alves 

---
  arch/powerpc/include/asm/hw_breakpoint.h  |   8 +
  arch/powerpc/kernel/Makefile  |   3 +-
  arch/powerpc/kernel/hw_breakpoint.c   | 159 +
  .../kernel/hw_breakpoint_constraints.c| 162 ++
  4 files changed, 174 insertions(+), 158 deletions(-)
  create mode 100644 arch/powerpc/kernel/hw_breakpoint_constraints.c

diff --git a/arch/powerpc/include/asm/hw_breakpoint.h 
b/arch/powerpc/include/asm/hw_breakpoint.h
index 9b68eafebf43..81872c420476 100644
--- a/arch/powerpc/include/asm/hw_breakpoint.h
+++ b/arch/powerpc/include/asm/hw_breakpoint.h
@@ -10,6 +10,7 @@
  #define _PPC_BOOK3S_64_HW_BREAKPOINT_H
  
  #include 

+#include 
  
  #ifdef	__KERNEL__

  struct arch_hw_breakpoint {
@@ -52,6 +53,13 @@ static inline int nr_wp_slots(void)
return cpu_has_feature(CPU_FTR_DAWR1) ? 2 : 1;
  }
  
+bool wp_check_constraints(struct pt_regs *regs, struct ppc_inst instr,

+ unsigned long ea, int type, int size,
+ struct arch_hw_breakpoint *info);
+
+void wp_get_instr_detail(struct pt_regs *regs, struct ppc_inst *instr,
+int *type, int *size, unsigned long *ea);
+
  #ifdef CONFIG_HAVE_HW_BREAKPOINT
  #include 
  #include 
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index cbf41fb4ee89..a5550c2b24c4 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -45,7 +45,8 @@ obj-y := cputable.o syscalls.o \
   signal.o sysfs.o cacheinfo.o time.o \
   prom.o traps.o setup-common.o \
   udbg.o misc.o io.o misc_$(BITS).o \
-  of_platform.o prom_parse.o firmware.o
+  of_platform.o prom_parse.o firmware.o \
+  hw_breakpoint_constraints.o
  obj-y += ptrace/
  obj-$(CONFIG_PPC64)   += setup_64.o \
   paca.o nvram_64.o note.o syscall_64.o
diff --git a/arch/powerpc/kernel/hw_breakpoint.c 
b/arch/powerpc/kernel/hw_breakpoint.c
index f6b24838ca3c..f4e8f21046f5 100644
--- a/arch/powerpc/kernel/hw_breakpoint.c
+++ b/arch/powerpc/kernel/hw_breakpoint.c
@@ -494,161 +494,6 @@ void thread_change_pc(struct task_struct *tsk, struct 
pt_regs *regs)
}
  }
  
-static bool dar_in_user_range(unsigned long dar, struct arch_hw_breakpoint *info)

-{
-   return ((info->address <= dar) && (dar - info->address < info->len));
-}
-
-static bool ea_user_range_overlaps(unsigned long ea, int size,
-  struct arch_hw_breakpoint *info)
-{
-   return ((ea < info->address + info->len) &&
-   (ea + size > info->address));
-}
-
-static bool dar_in_hw_range(unsigned long dar, struct arch_hw_breakpoint *info)
-{
-   unsigned long hw_start_addr, hw_end_addr;
-
-   hw_start_addr = ALIGN_DOWN(info->address, HW_BREAKPOINT_SIZE);
-   hw_end_addr = ALIGN(info->address + info->len, HW_BREAKPOINT_SIZE);
-
-   return ((hw_start_addr <= dar) && (hw_end_addr > dar));
-}
-
-static bool ea_hw_range_overlaps(unsigned long ea, int size,
-struct arch_hw_breakpoint *info)
-{
-   unsigned long hw_start_addr, hw_end_addr;
-   unsigned long align_size = HW_BREAKPOINT_SIZE;
-
-   /*
-* On p10 predecessors, quadword is handle differently then
-* other instructions.
-*/
-   if (!cpu_has_feature(CPU_FTR_ARCH_31) && size == 16)
-   align_size = HW_BREAKPOINT_SIZE_QUADWORD;
-
-   hw_start_addr = ALIGN_DOWN(info->address, align_size);
-   hw_end_addr = ALIGN(info->address + info->len, align_size);
-
-   return ((ea < hw_end_addr) && (ea + size > hw_start_addr));
-}
-
-/*
- * If hw has multiple DAWR registers, we also need to check all
- * dawrx constraint bits to confirm this is _really_ a valid event.
- * If type is UNKNOWN, but privilege level matches, consider it as
- * a positive match.
- */
-static bool check_dawrx_constraints(struct pt_regs *regs, int type,
-   struct arch_hw_breakpoint *info)
-{
-   if (OP_IS_LOAD(type) && !(info->type & HW_BRK_TYPE_READ))
-   return false;
-
-   /*
-* The Cache Management instructions other than dcbz never
-* cause a match. i.e. if type is CACHEOP, the instruction
-* is dcbz, and dcbz is treated as Store.
-

Re: [PATCH v6 3/8] powerpc/watchpoint/ptrace: Fix SETHWDEBUG when CONFIG_HAVE_HW_BREAKPOINT=N

[Rogerio Alves]

On 9/2/20 1:29 AM, Ravi Bangoria wrote:

When kernel is compiled with CONFIG_HAVE_HW_BREAKPOINT=N, user can
still create watchpoint using PPC_PTRACE_SETHWDEBUG, with limited
functionalities. But, such watchpoints are never firing because of
the missing privilege settings. Fix that.

It's safe to set HW_BRK_TYPE_PRIV_ALL because we don't really leak
any kernel address in signal info. Setting HW_BRK_TYPE_PRIV_ALL will
also help to find scenarios when kernel accesses user memory.

Reported-by: Pedro Miraglia Franco de Carvalho 
Suggested-by: Pedro Miraglia Franco de Carvalho 
Signed-off-by: Ravi Bangoria 

Tested-by: Rogerio Alves 

---
  arch/powerpc/kernel/ptrace/ptrace-noadv.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/ptrace/ptrace-noadv.c 
b/arch/powerpc/kernel/ptrace/ptrace-noadv.c
index 697c7e4b5877..57a0ab822334 100644
--- a/arch/powerpc/kernel/ptrace/ptrace-noadv.c
+++ b/arch/powerpc/kernel/ptrace/ptrace-noadv.c
@@ -217,7 +217,7 @@ long ppc_set_hwdebug(struct task_struct *child, struct 
ppc_hw_breakpoint *bp_inf
return -EIO;
  
  	brk.address = ALIGN_DOWN(bp_info->addr, HW_BREAKPOINT_SIZE);

-   brk.type = HW_BRK_TYPE_TRANSLATE;
+   brk.type = HW_BRK_TYPE_TRANSLATE | HW_BRK_TYPE_PRIV_ALL;
brk.len = DABR_MAX_LEN;
if (bp_info->trigger_type & PPC_BREAKPOINT_TRIGGER_READ)
brk.type |= HW_BRK_TYPE_READ;

Re: [PATCH v6 2/8] powerpc/watchpoint: Fix handling of vector instructions

[Rogerio Alves]

On 9/2/20 1:29 AM, Ravi Bangoria wrote:

Vector load/store instructions are special because they are always
aligned. Thus unaligned EA needs to be aligned down before comparing
it with watch ranges. Otherwise we might consider valid event as
invalid.

Fixes: 74c6881019b7 ("powerpc/watchpoint: Prepare handler to handle more than one 
watchpoint")
Signed-off-by: Ravi Bangoria 

Tested-by: Rogerio Alves 

---
  arch/powerpc/kernel/hw_breakpoint.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/arch/powerpc/kernel/hw_breakpoint.c 
b/arch/powerpc/kernel/hw_breakpoint.c
index 9f7df1c37233..f6b24838ca3c 100644
--- a/arch/powerpc/kernel/hw_breakpoint.c
+++ b/arch/powerpc/kernel/hw_breakpoint.c
@@ -644,6 +644,8 @@ static void get_instr_detail(struct pt_regs *regs, struct 
ppc_inst *instr,
if (*type == CACHEOP) {
*size = cache_op_size();
*ea &= ~(*size - 1);
+   } else if (*type == LOAD_VMX || *type == STORE_VMX) {
+   *ea &= ~(*size - 1);
}
  }
  

Re: [PATCH v6 1/8] powerpc/watchpoint: Fix quarword instruction handling on p10 predecessors

[Rogerio Alves]

On 9/2/20 1:29 AM, Ravi Bangoria wrote:

On p10 predecessors, watchpoint with quarword access is compared at
quardword length. If the watch range is doubleword or less than that
in a first half of quarword aligned 16 bytes, and if there is any
unaligned quadword access which will access only the 2nd half, the
handler should consider it as extraneous and emulate/single-step it
before continuing.

Reported-by: Pedro Miraglia Franco de Carvalho 
Fixes: 74c6881019b7 ("powerpc/watchpoint: Prepare handler to handle more than one 
watchpoint")
Signed-off-by: Ravi Bangoria 

Tested-by: Rogerio Alves 

---
  arch/powerpc/include/asm/hw_breakpoint.h |  1 +
  arch/powerpc/kernel/hw_breakpoint.c  | 12 ++--
  2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/include/asm/hw_breakpoint.h 
b/arch/powerpc/include/asm/hw_breakpoint.h
index db206a7f38e2..9b68eafebf43 100644
--- a/arch/powerpc/include/asm/hw_breakpoint.h
+++ b/arch/powerpc/include/asm/hw_breakpoint.h
@@ -42,6 +42,7 @@ struct arch_hw_breakpoint {
  #else
  #define HW_BREAKPOINT_SIZE  0x8
  #endif
+#define HW_BREAKPOINT_SIZE_QUADWORD0x10
  
  #define DABR_MAX_LEN	8

  #define DAWR_MAX_LEN  512
diff --git a/arch/powerpc/kernel/hw_breakpoint.c 
b/arch/powerpc/kernel/hw_breakpoint.c
index 1f4a1efa0074..9f7df1c37233 100644
--- a/arch/powerpc/kernel/hw_breakpoint.c
+++ b/arch/powerpc/kernel/hw_breakpoint.c
@@ -520,9 +520,17 @@ static bool ea_hw_range_overlaps(unsigned long ea, int 
size,
 struct arch_hw_breakpoint *info)
  {
unsigned long hw_start_addr, hw_end_addr;
+   unsigned long align_size = HW_BREAKPOINT_SIZE;
  
-	hw_start_addr = ALIGN_DOWN(info->address, HW_BREAKPOINT_SIZE);

-   hw_end_addr = ALIGN(info->address + info->len, HW_BREAKPOINT_SIZE);
+   /*
+* On p10 predecessors, quadword is handle differently then
+* other instructions.
+*/
+   if (!cpu_has_feature(CPU_FTR_ARCH_31) && size == 16)
+   align_size = HW_BREAKPOINT_SIZE_QUADWORD;
+
+   hw_start_addr = ALIGN_DOWN(info->address, align_size);
+   hw_end_addr = ALIGN(info->address + info->len, align_size);
  
  	return ((ea < hw_end_addr) && (ea + size > hw_start_addr));

  }

Re: [PATCH v6 0/8] powerpc/watchpoint: Bug fixes plus new feature flag

[Rogerio Alves]

On 9/2/20 1:29 AM, Ravi Bangoria wrote:

Patch #1 fixes issue for quardword instruction on p10 predecessors.
Patch #2 fixes issue for vector instructions.
Patch #3 fixes a bug about watchpoint not firing when created with
  ptrace PPC_PTRACE_SETHWDEBUG and CONFIG_HAVE_HW_BREAKPOINT=N.
  The fix uses HW_BRK_TYPE_PRIV_ALL for ptrace user which, I
  guess, should be fine because we don't leak any kernel
  addresses and PRIV_ALL will also help to cover scenarios when
  kernel accesses user memory.
Patch #4,#5 fixes infinite exception bug, again the bug happens only
  with CONFIG_HAVE_HW_BREAKPOINT=N.
Patch #6 fixes two places where we are missing to set hw_len.
Patch #7 introduce new feature bit PPC_DEBUG_FEATURE_DATA_BP_ARCH_31
  which will be set when running on ISA 3.1 compliant machine.
Patch #8 finally adds selftest to test scenarios fixed by patch#2,#3
  and also moves MODE_EXACT tests outside of BP_RANGE condition.

Christophe, let me know if this series breaks something for 8xx.

v5: 
https://lore.kernel.org/r/20200825043617.1073634-1-ravi.bango...@linux.ibm.com

v5->v6:
  - Fix build faulure reported by kernel test robot
  - patch #5. Use more compact if condition, suggested by Christophe


Ravi Bangoria (8):
   powerpc/watchpoint: Fix quarword instruction handling on p10
 predecessors
   powerpc/watchpoint: Fix handling of vector instructions
   powerpc/watchpoint/ptrace: Fix SETHWDEBUG when
 CONFIG_HAVE_HW_BREAKPOINT=N
   powerpc/watchpoint: Move DAWR detection logic outside of
 hw_breakpoint.c
   powerpc/watchpoint: Fix exception handling for
 CONFIG_HAVE_HW_BREAKPOINT=N
   powerpc/watchpoint: Add hw_len wherever missing
   powerpc/watchpoint/ptrace: Introduce PPC_DEBUG_FEATURE_DATA_BP_ARCH_31
   powerpc/watchpoint/selftests: Tests for kernel accessing user memory

  Documentation/powerpc/ptrace.rst  |   1 +
  arch/powerpc/include/asm/hw_breakpoint.h  |  12 ++
  arch/powerpc/include/uapi/asm/ptrace.h|   1 +
  arch/powerpc/kernel/Makefile  |   3 +-
  arch/powerpc/kernel/hw_breakpoint.c   | 149 +---
  .../kernel/hw_breakpoint_constraints.c| 162 ++
  arch/powerpc/kernel/process.c |  48 ++
  arch/powerpc/kernel/ptrace/ptrace-noadv.c |   9 +-
  arch/powerpc/xmon/xmon.c  |   1 +
  .../selftests/powerpc/ptrace/ptrace-hwbreak.c |  48 +-
  10 files changed, 282 insertions(+), 152 deletions(-)
  create mode 100644 arch/powerpc/kernel/hw_breakpoint_constraints.c



Tested this patch set for:
- SETHWDEBUG when CONFIG_HAVE_HW_BREAKPOINT=N = OK
- Fix exception handling for CONFIG_HAVE_HW_BREAKPOINT=N = OK
- Check for PPC_DEBUG_FEATURE_DATA_BP_ARCH_31 = OK
- Fix quarword instruction handling on p10 predecessors = OK
- Fix handling of vector instructions = OK

Also tested for:
- Set second watchpoint (P10 Mambo) = OK
- Infinity loop on sc instruction = OK

Re: [PATCH] fsl: imx-audmix : Replace seq_printf with seq_puts

[Mark Brown]

On Wed, Sep 16, 2020 at 06:14:20AM +, Xu Wang wrote:

> A multiplication for the size determination of a memory allocation
> indicated that an array data structure should be processed.
> Thus use the corresponding function "devm_kcalloc".

This looks fine but the subject says it's about seq_puts() not
kcalloc().


signature.asc
Description: PGP signature

Re: [PATCH] powerpc/perf: Exclude pmc5/6 from the irrelevant PMU group constraints

[Athira Rajeev]

> On 17-Sep-2020, at 5:43 PM, Michael Ellerman  wrote:
> 
> Athira Rajeev  writes:
>> PMU counter support functions enforces event constraints for group of
>> events to check if all events in a group can be monitored. Incase of
>> event codes using PMC5 and PMC6 ( 500fa and 600f4 respectively ),
>> not all constraints are applicable, say the threshold or sample bits.
>> But current code includes pmc5 and pmc6 in some group constraints (like
>> IC_DC Qualifier bits) which is actually not applicable and hence results
>> in those events not getting counted when scheduled along with group of
>> other events. Patch fixes this by excluding PMC5/6 from constraints
>> which are not relevant for it.
>> 
>> Fixes: 7ffd948 ('powerpc/perf: factor out power8 pmu functions')
>> Signed-off-by: Athira Rajeev 
>> ---
>> arch/powerpc/perf/isa207-common.c | 4 
>> 1 file changed, 4 insertions(+)
>> 
>> diff --git a/arch/powerpc/perf/isa207-common.c 
>> b/arch/powerpc/perf/isa207-common.c
>> index 964437a..186fad8 100644
>> --- a/arch/powerpc/perf/isa207-common.c
>> +++ b/arch/powerpc/perf/isa207-common.c
>> @@ -288,6 +288,9 @@ int isa207_get_constraint(u64 event, unsigned long 
>> *maskp, unsigned long *valp)
>> 
>>  mask  |= CNST_PMC_MASK(pmc);
>>  value |= CNST_PMC_VAL(pmc);
>> +
>> +if (pmc >= 5)
>> +goto ebb_bhrb;
> 
> This is fairly subtle. Can you please put a block comment above the if
> explaining in a few lines what's going on.

Hi Michael,

Sure, I will include a comment explaining the change in V2.

Thanks
Athira
> 
> cheers

Re: [PATCH 0/3] powerpc/mce: Fix mce handler and add selftest

[Michal Suchánek]

Hello,

On Wed, Sep 16, 2020 at 10:52:25PM +0530, Ganesh Goudar wrote:
> This patch series fixes mce handling for pseries, provides debugfs
> interface for mce injection and adds selftest to test mce handling
> on pseries/powernv machines running in hash mmu mode.
> debugfs interface and sleftest are added only for slb multihit
> injection, We can add other tests in future if possible.
> 
> Ganesh Goudar (3):
>   powerpc/mce: remove nmi_enter/exit from real mode handler
>   powerpc/mce: Add debugfs interface to inject MCE
>   selftest/powerpc: Add slb multihit selftest

Is the below logic sound? It does not agree with what is added here:

void machine_check_exception(struct pt_regs *regs)
{
int recover = 0;

/*
 * BOOK3S_64 does not call this handler as a non-maskable interrupt
 * (it uses its own early real-mode handler to handle the MCE proper
 * and then raises irq_work to call this handler when interrupts are
 * enabled).
 *
 * This is silly. The BOOK3S_64 should just call a different function
 * rather than expecting semantics to magically change. Something
 * like 'non_nmi_machine_check_exception()', perhaps?
 */
const bool nmi = !IS_ENABLED(CONFIG_PPC_BOOK3S_64);

if (nmi) nmi_enter();

Thanks

Michal

Re: [PATCH 2/3] powerpc/mce: Add debugfs interface to inject MCE

[Michal Suchánek]

Hello,

On Wed, Sep 16, 2020 at 10:52:27PM +0530, Ganesh Goudar wrote:
> To test machine check handling, add debugfs interface to inject
> slb multihit errors.
> 
> To inject slb multihit:
>  #echo 1 > /sys/kernel/debug/powerpc/mce_error_inject/inject_slb_multihit
> 
> Signed-off-by: Ganesh Goudar 
> Signed-off-by: Mahesh Salgaonkar 
> ---
>  arch/powerpc/Kconfig.debug |   9 ++
>  arch/powerpc/sysdev/Makefile   |   2 +
>  arch/powerpc/sysdev/mce_error_inject.c | 148 +
>  3 files changed, 159 insertions(+)
>  create mode 100644 arch/powerpc/sysdev/mce_error_inject.c
> 
> diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug
> index b88900f4832f..61db133f2f0d 100644
> --- a/arch/powerpc/Kconfig.debug
> +++ b/arch/powerpc/Kconfig.debug
> @@ -398,3 +398,12 @@ config KASAN_SHADOW_OFFSET
>   hex
>   depends on KASAN
>   default 0xe000
> +
> +config MCE_ERROR_INJECT
> + bool "Enable MCE error injection through debugfs"
> + depends on DEBUG_FS
> + default y
> + help
> +   This option creates an mce_error_inject directory in the
> +   powerpc debugfs directory that allows limited injection of
> +   Machine Check Errors (MCEs).
> diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
> index 026b3f01a991..7fc10b77 100644
> --- a/arch/powerpc/sysdev/Makefile
> +++ b/arch/powerpc/sysdev/Makefile
> @@ -52,3 +52,5 @@ obj-$(CONFIG_PPC_XICS)  += xics/
>  obj-$(CONFIG_PPC_XIVE)   += xive/
>  
>  obj-$(CONFIG_GE_FPGA)+= ge/
> +
> +obj-$(CONFIG_MCE_ERROR_INJECT)   += mce_error_inject.o
> diff --git a/arch/powerpc/sysdev/mce_error_inject.c 
> b/arch/powerpc/sysdev/mce_error_inject.c
> new file mode 100644
> index ..ca4726bfa2d9
> --- /dev/null
> +++ b/arch/powerpc/sysdev/mce_error_inject.c
> @@ -0,0 +1,148 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Machine Check Exception injection code
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +static inline unsigned long get_slb_index(void)
> +{
> + unsigned long index;
> +
> + index = get_paca()->stab_rr;
> +
> + /*
> +  * simple round-robin replacement of slb starting at SLB_NUM_BOLTED.
> +  */
> + if (index < (mmu_slb_size - 1))
> + index++;
> + else
> + index = SLB_NUM_BOLTED;
> + get_paca()->stab_rr = index;
> + return index;
> +}
> +
> +#define slb_esid_mask(ssize) \
> + (((ssize) == MMU_SEGSIZE_256M) ? ESID_MASK : ESID_MASK_1T)
> +
> +static inline unsigned long mk_esid_data(unsigned long ea, int ssize,
> +  unsigned long slot)
> +{
> + return (ea & slb_esid_mask(ssize)) | SLB_ESID_V | slot;
> +}
> +
> +#define slb_vsid_shift(ssize)\
> + ((ssize) == MMU_SEGSIZE_256M ? SLB_VSID_SHIFT : SLB_VSID_SHIFT_1T)
> +
> +static inline unsigned long mk_vsid_data(unsigned long ea, int ssize,
> +  unsigned long flags)
> +{
> + return (get_kernel_vsid(ea, ssize) << slb_vsid_shift(ssize)) | flags |
> + ((unsigned long)ssize << SLB_VSID_SSIZE_SHIFT);
> +}
> +
> +static void insert_slb_entry(char *p, int ssize)
> +{
> + unsigned long flags, entry;
> + struct paca_struct *paca;
> +
> + flags = SLB_VSID_KERNEL | mmu_psize_defs[MMU_PAGE_64K].sllp;
> +
> + preempt_disable();
> +
> + paca = get_paca();
This seems unused?
> +
> + entry = get_slb_index();
> + asm volatile("slbmte %0,%1" :
> + : "r" (mk_vsid_data((unsigned long)p, ssize, flags)),
> +   "r" (mk_esid_data((unsigned long)p, ssize, entry))
> + : "memory");
> +
> + entry = get_slb_index();
> + asm volatile("slbmte %0,%1" :
> + : "r" (mk_vsid_data((unsigned long)p, ssize, flags)),
> +   "r" (mk_esid_data((unsigned long)p, ssize, entry))
> + : "memory");
> + preempt_enable();
> + p[0] = '!';
> +}
> +
> +static void inject_vmalloc_slb_multihit(void)
> +{
> + char *p;
> +
> + p = vmalloc(2048);
> + if (!p)
> + return;
> +
> + insert_slb_entry(p, MMU_SEGSIZE_1T);
> + vfree(p);
> +}
> +
> +static void inject_kmalloc_slb_multihit(void)
> +{
> + char *p;
> +
> + p = kmalloc(2048, GFP_KERNEL);
> + if (!p)
> + return;
> +
> + insert_slb_entry(p, MMU_SEGSIZE_1T);
> + kfree(p);
> +}
> +
> +static ssize_t inject_slb_multihit(const char __user *u_buf, size_t count)
> +{
> + char buf[32];
> + size_t buf_size;
> +
> + buf_size = min(count, (sizeof(buf) - 1));
> + if (copy_from_user(buf, u_buf, buf_size))
> + return -EFAULT;
> + buf[buf_size] = '\0';
> +
> + if (buf[0] != '1')
> + return -EINVAL;
> +
> + inject_vmalloc_slb_multihit();
> + inject_kmalloc_slb_multihit();
This is 

Re: [PATCH v2 6/7] powerpc/perf: Remove unused variable 'target' in trace_imc_event_init()

[Athira Rajeev]

> On 15-Sep-2020, at 2:40 AM, Cédric Le Goater  wrote:
> 
> This fixes a compile error with W=1.
> 
> CC  arch/powerpc/perf/imc-pmu.o
> ../arch/powerpc/perf/imc-pmu.c: In function ‘trace_imc_event_init’:
> ../arch/powerpc/perf/imc-pmu.c:1429:22: error: variable ‘target’ set but not 
> used [-Werror=unused-but-set-variable]
>  struct task_struct *target;
>  ^~
> 
> Cc: Anju T Sudhakar 
> Reviewed-by: Christophe Leroy 
> Signed-off-by: Cédric Le Goater 
> ---
> arch/powerpc/perf/imc-pmu.c | 3 ---
> 1 file changed, 3 deletions(-)
> 
> diff --git a/arch/powerpc/perf/imc-pmu.c b/arch/powerpc/perf/imc-pmu.c
> index 62d0b54086f8..9ed4fcccf8a9 100644
> --- a/arch/powerpc/perf/imc-pmu.c
> +++ b/arch/powerpc/perf/imc-pmu.c
> @@ -1426,8 +1426,6 @@ static void trace_imc_event_del(struct perf_event 
> *event, int flags)
> 
> static int trace_imc_event_init(struct perf_event *event)
> {
> - struct task_struct *target;
> -
>   if (event->attr.type != event->pmu->type)
>   return -ENOENT;
> 
> @@ -1458,7 +1456,6 @@ static int trace_imc_event_init(struct perf_event 
> *event)
>   mutex_unlock(_global_refc.lock);
> 
>   event->hw.idx = -1;
> - target = event->hw.target;

Reviewed-by: Athira Rajeev 

Thanks
Athira
> 
>   event->pmu->task_ctx_nr = perf_hw_context;
>   event->destroy = reset_global_refc;
> -- 
> 2.25.4
> 

Re: [PATCH 1/3] powerpc/mce: remove nmi_enter/exit from real mode handler

[Michal Suchánek]

Hello,

On Wed, Sep 16, 2020 at 10:52:26PM +0530, Ganesh Goudar wrote:
> Use of nmi_enter/exit in real mode handler causes the kernel to panic
> and reboot on injecting slb mutihit on pseries machine running in hash
> mmu mode, As these calls try to accesses memory outside RMO region in
> real mode handler where translation is disabled.
> 
> Add check to not to use these calls on pseries machine running in hash
> mmu mode.
> 
> Fixes: 116ac378bb3f ("powerpc/64s: machine check interrupt update NMI 
> accounting")
> Signed-off-by: Ganesh Goudar 
> ---
>  arch/powerpc/kernel/mce.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/powerpc/kernel/mce.c b/arch/powerpc/kernel/mce.c
> index ada59f6c4298..1d42fe0f5f9c 100644
> --- a/arch/powerpc/kernel/mce.c
> +++ b/arch/powerpc/kernel/mce.c
> @@ -591,10 +591,15 @@ EXPORT_SYMBOL_GPL(machine_check_print_event_info);
>  long notrace machine_check_early(struct pt_regs *regs)
>  {
>   long handled = 0;
> - bool nested = in_nmi();
> + bool nested;
> + bool is_pseries_hpt_guest;
>   u8 ftrace_enabled = this_cpu_get_ftrace_enabled();
>  
>   this_cpu_set_ftrace_enabled(0);
> + is_pseries_hpt_guest = machine_is(pseries) &&
> +mmu_has_feature(MMU_FTR_HPTE_TABLE);
> + /* Do not use nmi_enter/exit for pseries hpte guest */
> + nested = is_pseries_hpt_guest ? true : in_nmi();
As pointed out already in another comment nesting is supported natively
since 69ea03b56ed2c7189ccd0b5910ad39f3cad1df21. You can simply do
nmi_enter and nmi_exit unconditionally - or only based on
is_pseries_hpt_guest.

The other question is what is the value of calling nmi_enter here at
all. It crashes in one case, we simply skip it for that case, and we are
good. Maybe we could skip it altogether?

Thanks

Michal

Re: [PATCH] powerpc/perf: Exclude pmc5/6 from the irrelevant PMU group constraints

[Michael Ellerman]

Athira Rajeev  writes:
> PMU counter support functions enforces event constraints for group of
> events to check if all events in a group can be monitored. Incase of
> event codes using PMC5 and PMC6 ( 500fa and 600f4 respectively ),
> not all constraints are applicable, say the threshold or sample bits.
> But current code includes pmc5 and pmc6 in some group constraints (like
> IC_DC Qualifier bits) which is actually not applicable and hence results
> in those events not getting counted when scheduled along with group of
> other events. Patch fixes this by excluding PMC5/6 from constraints
> which are not relevant for it.
>
> Fixes: 7ffd948 ('powerpc/perf: factor out power8 pmu functions')
> Signed-off-by: Athira Rajeev 
> ---
>  arch/powerpc/perf/isa207-common.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/arch/powerpc/perf/isa207-common.c 
> b/arch/powerpc/perf/isa207-common.c
> index 964437a..186fad8 100644
> --- a/arch/powerpc/perf/isa207-common.c
> +++ b/arch/powerpc/perf/isa207-common.c
> @@ -288,6 +288,9 @@ int isa207_get_constraint(u64 event, unsigned long 
> *maskp, unsigned long *valp)
>  
>   mask  |= CNST_PMC_MASK(pmc);
>   value |= CNST_PMC_VAL(pmc);
> +
> + if (pmc >= 5)
> + goto ebb_bhrb;

This is fairly subtle. Can you please put a block comment above the if
explaining in a few lines what's going on.

cheers

Re: [PATCH -next] ide: Fix symbol undeclared warnings

[Michael Ellerman]

Wang Wensheng  writes:
> Build the object file with `C=2` and get the following warnings:
> make allmodconfig ARCH=powerpc CROSS_COMPILE=powerpc64-linux-gnu-
> make C=2 drivers/ide/pmac.o ARCH=powerpc64
> CROSS_COMPILE=powerpc64-linux-gnu-
>
> drivers/ide/pmac.c:228:23: warning: symbol 'mdma_timings_33' was not
> declared. Should it be static?
> drivers/ide/pmac.c:241:23: warning: symbol 'mdma_timings_33k' was not
> declared. Should it be static?
> drivers/ide/pmac.c:254:23: warning: symbol 'mdma_timings_66' was not
> declared. Should it be static?
> drivers/ide/pmac.c:272:3: warning: symbol 'kl66_udma_timings' was not
> declared. Should it be static?
> drivers/ide/pmac.c:1418:12: warning: symbol 'pmac_ide_probe' was not
> declared. Should it be static?
>
> Signed-off-by: Wang Wensheng 
> ---
>  drivers/ide/pmac.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)

TIL davem maintains IDE?

But I suspect he isn't that interested in this powerpc only driver, so
I'll grab this.

cheers


> diff --git a/drivers/ide/pmac.c b/drivers/ide/pmac.c
> index ea0b064b5f56..6bb2fc6755c2 100644
> --- a/drivers/ide/pmac.c
> +++ b/drivers/ide/pmac.c
> @@ -225,7 +225,7 @@ struct mdma_timings_t {
>   int cycleTime;
>  };
>  
> -struct mdma_timings_t mdma_timings_33[] =
> +static struct mdma_timings_t mdma_timings_33[] =
>  {
>  { 240, 240, 480 },
>  { 180, 180, 360 },
> @@ -238,7 +238,7 @@ struct mdma_timings_t mdma_timings_33[] =
>  {   0,   0,   0 }
>  };
>  
> -struct mdma_timings_t mdma_timings_33k[] =
> +static struct mdma_timings_t mdma_timings_33k[] =
>  {
>  { 240, 240, 480 },
>  { 180, 180, 360 },
> @@ -251,7 +251,7 @@ struct mdma_timings_t mdma_timings_33k[] =
>  {   0,   0,   0 }
>  };
>  
> -struct mdma_timings_t mdma_timings_66[] =
> +static struct mdma_timings_t mdma_timings_66[] =
>  {
>  { 240, 240, 480 },
>  { 180, 180, 360 },
> @@ -265,7 +265,7 @@ struct mdma_timings_t mdma_timings_66[] =
>  };
>  
>  /* KeyLargo ATA-4 Ultra DMA timings (rounded) */
> -struct {
> +static struct {
>   int addrSetup; /* ??? */
>   int rdy2pause;
>   int wrDataSetup;
> @@ -1415,7 +1415,7 @@ static struct pci_driver pmac_ide_pci_driver = {
>  };
>  MODULE_DEVICE_TABLE(pci, pmac_ide_pci_match);
>  
> -int __init pmac_ide_probe(void)
> +static int __init pmac_ide_probe(void)
>  {
>   int error;
>  
> -- 
> 2.25.0

Re: [PATCH v2] powerpc: fix EDEADLOCK redefinition error in uapi/asm/errno.h

[Michael Ellerman]

[ Cc += linux-arch & Arnd ]

Hi Tony,

This looks OK to me, but I'm always a bit nervous about changes in uapi.
I've Cc'ed linux-arch and Arnd who look after the asm-generic headers,
which this is slightly related to, just in case.

One minor comment below.

Tony Ambardar  writes:
> A few archs like powerpc have different errno.h values for macros
> EDEADLOCK and EDEADLK. In code including both libc and linux versions of
> errno.h, this can result in multiple definitions of EDEADLOCK in the
> include chain. Definitions to the same value (e.g. seen with mips) do
> not raise warnings, but on powerpc there are redefinitions changing the
> value, which raise warnings and errors (if using "-Werror").
>
> Guard against these redefinitions to avoid build errors like the following,
> first seen cross-compiling libbpf v5.8.9 for powerpc using GCC 8.4.0 with
> musl 1.1.24:
>
>   In file included from ../../arch/powerpc/include/uapi/asm/errno.h:5,
>from ../../include/linux/err.h:8,
>from libbpf.c:29:
>   ../../include/uapi/asm-generic/errno.h:40: error: "EDEADLOCK" redefined 
> [-Werror]
>#define EDEADLOCK EDEADLK
>
>   In file included from 
> toolchain-powerpc_8540_gcc-8.4.0_musl/include/errno.h:10,
>from libbpf.c:26:
>   toolchain-powerpc_8540_gcc-8.4.0_musl/include/bits/errno.h:58: note: this 
> is the location of the previous definition
>#define EDEADLOCK   58
>
>   cc1: all warnings being treated as errors
>
> Fixes: 95f28190aa01 ("tools include arch: Grab a copy of errno.h for arch's 
> supported by perf")
> Fixes: c3617f72036c ("UAPI: (Scripted) Disintegrate arch/powerpc/include/asm")

I suspect that's not the right commit to tag. It just moved errno.h from
arch/powerpc/include/asm to arch/powerpc/include/uapi/asm. It's content
was almost identical, and entirely identical as far as EDEADLOCK was
concerned.

Prior to that the file lived in asm-powerpc/errno.h, eg:

$ git cat-file -p b8b572e1015f^:include/asm-powerpc/errno.h

Before that it was include/asm-ppc64/errno.h, content still the same.

To go back further we'd have to look at the historical git trees, which
is probably overkill. I'm pretty sure it's always had this problem.

So we should probably drop the Fixes tags and just Cc: stable, that
means please backport it as far back as possible.

cheers


> Reported-by: Rosen Penev 
> Signed-off-by: Tony Ambardar 
> ---
> v1 -> v2:
>  * clean up commit description formatting
> ---
>  arch/powerpc/include/uapi/asm/errno.h   | 1 +
>  tools/arch/powerpc/include/uapi/asm/errno.h | 1 +
>  2 files changed, 2 insertions(+)
>
> diff --git a/arch/powerpc/include/uapi/asm/errno.h 
> b/arch/powerpc/include/uapi/asm/errno.h
> index cc79856896a1..4ba87de32be0 100644
> --- a/arch/powerpc/include/uapi/asm/errno.h
> +++ b/arch/powerpc/include/uapi/asm/errno.h
> @@ -2,6 +2,7 @@
>  #ifndef _ASM_POWERPC_ERRNO_H
>  #define _ASM_POWERPC_ERRNO_H
>  
> +#undef   EDEADLOCK
>  #include 
>  
>  #undef   EDEADLOCK
> diff --git a/tools/arch/powerpc/include/uapi/asm/errno.h 
> b/tools/arch/powerpc/include/uapi/asm/errno.h
> index cc79856896a1..4ba87de32be0 100644
> --- a/tools/arch/powerpc/include/uapi/asm/errno.h
> +++ b/tools/arch/powerpc/include/uapi/asm/errno.h
> @@ -2,6 +2,7 @@
>  #ifndef _ASM_POWERPC_ERRNO_H
>  #define _ASM_POWERPC_ERRNO_H
>  
> +#undef   EDEADLOCK
>  #include 
>  
>  #undef   EDEADLOCK
> -- 
> 2.25.1

Re: [PATCH] powerpc/64: Make VDSO32 track COMPAT on 64-bit

[Michael Ellerman]

On Tue, 8 Sep 2020 22:58:50 +1000, Michael Ellerman wrote:
> When we added the VDSO32 kconfig symbol, which controls building of
> the 32-bit VDSO, we made it depend on CPU_BIG_ENDIAN (for 64-bit).
> 
> That was because back then COMPAT was always enabled for 64-bit, so
> depending on it would have left the 32-bit VDSO always enabled, which
> we didn't want.
> 
> [...]

Applied to powerpc/next.

[1/1] powerpc/64: Make VDSO32 track COMPAT on 64-bit
  https://git.kernel.org/powerpc/c/231b232df8f67e7d37af01259c21f2a131c3911e

cheers

[Bug 209297] New: powerpc: MPC10X_BRIDGE violates Kconfig dependency of PPC_INDIRECT_PCI on PCI

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=209297

Bug ID: 209297
   Summary: powerpc: MPC10X_BRIDGE violates Kconfig dependency of
PPC_INDIRECT_PCI on PCI
   Product: Platform Specific/Hardware
   Version: 2.5
Kernel Version: 5.9-rc4
  Hardware: PPC-32
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: PPC-32
  Assignee: platform_ppc...@kernel-bugs.osdl.org
  Reporter: fazilyildi...@gmail.com
CC: m...@ellerman.id.au, pau...@samba.org
Regression: No

The commit 25635c71e441 ("ppc: Use the indirect_pci.c from
arch/powerpc/sysdev")
introduced PPC_INDIRECT_PCI as a non-visible config that depends on PCI. 

Since it is non-visible, the dependency on PCI has no implications other
than leading to Kbuild build warnings if !PCI. For example, disabling PCI
and enabling LINKSTATION leads to the following Kbuild warning since
PPC_INDIRECT_PCI is selected by MPC10X_BRIDGE, which is selected by
LINKSTATION:

WARNING: unmet direct dependencies detected for PPC_INDIRECT_PCI
  Depends on [n]: PCI [=n]
  Selected by [y]:
  - MPC10X_BRIDGE [=y]

There are many other configs that select PPC_INDIRECT_PCI but they seem
to enable PCI one way or another, e.g., enabling FORCE_PCI or selecting
PPC_INDIRECT_PCI if PCI. Among them, only MPC10X_BRIDGE and MV64X60 seem
to not account for the dependency on PCI, and MV64X60 seem to be obsolete:
https://bugzilla.kernel.org/show_bug.cgi?id=209277

I am not sure about the internals of the user subsystem. However, two fix
options I see are: 1) --select FORCE_PCI-- by MPC10X_BRIDGE, 2) select
PPC_INDIRECT_PCI --if PCI-- by MPC10X_BRIDGE.

Thanks,
Necip

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

Re: [PATCH] powerpc/ps3: make two symbols static

[Michael Ellerman]

On Fri, 11 Sep 2020 10:01:21 +0800, Jason Yan wrote:
> This addresses the following sparse warning:
> 
> arch/powerpc/platforms/ps3/spu.c:451:33: warning: symbol
> 'spu_management_ps3_ops' was not declared. Should it be static?
> arch/powerpc/platforms/ps3/spu.c:592:28: warning: symbol
> 'spu_priv1_ps3_ops' was not declared. Should it be static?

Applied to powerpc/next.

[1/1] powerpc/ps3: make two symbols static
  https://git.kernel.org/powerpc/c/bbc4f40b5322b3e0b8678619f1c613dadc811669

cheers

Re: [PATCH -next] drivers/macintosh/smu.c: Fix undeclared symbol warning

[Michael Ellerman]

On Mon, 14 Sep 2020 12:26:15 +, Wang Wensheng wrote:
> Make kernel with `C=2`:
> drivers/macintosh/smu.c:1018:30: warning: symbol
> '__smu_get_sdb_partition' was not declared. Should it be static?

Applied to powerpc/next.

[1/1] drivers/macintosh/smu.c: Fix undeclared symbol warning
  https://git.kernel.org/powerpc/c/3db8715ec9dc1d32ecafc67af9fb96508c98efe5

cheers

Re: [PATCH v2] powerpc/papr_scm: Fix warning triggered by perf_stats_show()

[Michael Ellerman]

On Sat, 12 Sep 2020 13:44:51 +0530, Vaibhav Jain wrote:
> A warning is reported by the kernel in case perf_stats_show() returns
> an error code. The warning is of the form below:
> 
>  papr_scm ibm,persistent-memory:ibm,pmemory@4411:
> Failed to query performance stats, Err:-10
>  dev_attr_show: perf_stats_show+0x0/0x1c0 [papr_scm] returned bad count
>  fill_read_buffer: dev_attr_show+0x0/0xb0 returned bad count
> 
> [...]

Applied to powerpc/next.

[1/1] powerpc/papr_scm: Fix warning triggered by perf_stats_show()
  https://git.kernel.org/powerpc/c/ca78ef2f08ccfa29b711d644964cdf9d7ace15e5

cheers

Re: [PATCH v6 0/3] Offline memoryless cpuless node 0

[Michael Ellerman]

On Tue, 18 Aug 2020 13:41:01 +0530, Srikar Dronamraju wrote:
> Changelog v5:->v6:
> - Now the fix is Powerpc specific.
>   (David Hildenbrand, Michal Hocko, Christopher Lamater)
> - rebased to v5.8
> link v5: 
> https://lore.kernel.org/linuxppc-dev/20200624092846.9194-1-sri...@linux.vnet.ibm.com/t/#u
> 
> Changelog v4:->v5:
> - rebased to v5.8
> link v4: 
> http://lore.kernel.org/lkml/20200512132937.19295-1-sri...@linux.vnet.ibm.com/t/#u
> 
> [...]

Applied to powerpc/next.

[1/3] powerpc/numa: Set numa_node for all possible cpus
  https://git.kernel.org/powerpc/c/a874f1005ef5dfe53dfd8cda59a6600e89986ecd
[2/3] powerpc/numa: Prefer node id queried from vphn
  https://git.kernel.org/powerpc/c/6398eaa268168b528dd1d3d0e70e61e9c13bea23
[3/3] powerpc/numa: Offline memoryless cpuless node 0
  https://git.kernel.org/powerpc/c/e75130f20b1f48e04ccc806aea01f0a361f9cb6b

cheers

Re: [PATCH v5 00/10] Coregroup support on Powerpc

[Michael Ellerman]

On Mon, 10 Aug 2020 12:48:24 +0530, Srikar Dronamraju wrote:
> Changelog v4->v5:
> v4: 
> http://lore.kernel.org/lkml/20200727053230.19753-1-sri...@linux.vnet.ibm.com/t/#u
> 
> Changelog v4 ->v5:
> powerpc/smp: Optimize start_secondary
>   Retain cache domain, no need for generalization
>(Michael Ellerman, Peter Zijlstra,
>Valentin Schneider, Gautham R. Shenoy)
> 
> [...]

Applied to powerpc/next.

[01/10] powerpc/smp: Fix a warning under !NEED_MULTIPLE_NODES

https://git.kernel.org/powerpc/c/d0fd24bbd27619d7b8d4da26a19a2027931ae9fc
[02/10] powerpc/smp: Merge Power9 topology with Power topology

https://git.kernel.org/powerpc/c/2ef0ca54d97f40f7621d595ac5479bd7fa076bfa
[03/10] powerpc/smp: Move powerpc_topology above

https://git.kernel.org/powerpc/c/5e93f16ae48b728775496429c6db53d0bf8cdd9b
[04/10] powerpc/smp: Move topology fixups into a new function

https://git.kernel.org/powerpc/c/3c6032a8fe99547d31b2b57715e303a67d1b0c66
[05/10] powerpc/smp: Dont assume l2-cache to be superset of sibling

https://git.kernel.org/powerpc/c/f6606cfdfbcda00ce8a6e63c8fc13c93e73ac059
[06/10] powerpc/smp: Optimize start_secondary

https://git.kernel.org/powerpc/c/caa8e29da59926bef099b46ab6280333d583e944
[07/10] powerpc/numa: Detect support for coregroup

https://git.kernel.org/powerpc/c/f9f130ff2ec93c5949576bbfb168cc9530c23649
[08/10] powerpc/smp: Allocate cpumask only after searching thread group

https://git.kernel.org/powerpc/c/6e086302816b2ced602bc99641eb0189c05f018a
[09/10] powerpc/smp: Create coregroup domain

https://git.kernel.org/powerpc/c/72730bfc2a2b91a525f38dfc830f598bdb95f216
[10/10] powerpc/smp: Implement cpu_to_coregroup_id

https://git.kernel.org/powerpc/c/fa35e868f9ddcbb7984fd5ab7f91aef924fa8543

cheers

Re: [PATCH v3] powerpc/numa: Restrict possible nodes based on platform

[Michael Ellerman]

On Mon, 17 Aug 2020 11:22:57 +0530, Srikar Dronamraju wrote:
> As per draft LoPAPR (Revision 2.9_pre7), section B.5.3 "Run Time Abstaction
> Services (RTAS) Node at
> https://openpowerfoundation.org/wp-content/uploads/2020/07/LoPAR-20200611.pdf,
> there are 2 device tree property ibm,max-associativity-domains (which
> defines the maximum number of domains that the firmware i.e PowerVM can
> support) and ibm,current-associativity-domains (which defines the maximum
> number of domains that the platform can support). Value of
> ibm,max-associativity-domains property is always greater than or equal to
> ibm,current-associativity-domains property. If the said property is not
> available, use ibm,max-associativity-domain as fallback. In this yet to be
> released LoPAPR, ibm,current-associativity-domains is mentioned in page 833
> / B.5.3 which is covered under under "Appendix B. System Binding" section
> 
> [...]

Applied to powerpc/next.

[1/1] powerpc/numa: Restrict possible nodes based on platform
  https://git.kernel.org/powerpc/c/67df77845c181166d4bc324cbb0382f7e81c7631

cheers

Re: [PATCH v2 1/2] sched/topology: Allow archs to override cpu_smt_mask

[Michael Ellerman]

On Fri, 7 Aug 2020 13:15:16 +0530, Srikar Dronamraju wrote:
> cpu_smt_mask tracks topology_sibling_cpumask. This would be good for
> most architectures. One of the users of cpu_smt_mask(), would be to
> identify idle-cores. On Power9, a pair of SMT4 cores can be presented by
> the firmware as a SMT8 core for backward compatibility reasons.
> 
> Powerpc allows LPARs to be live migrated from Power8 to Power9. Do note
> Power8 had only SMT8 cores. Existing software which has been
> developed/configured for Power8 would expect to see SMT8 core.
> Maintaining the illusion of SMT8 core is a requirement to make that
> work.
> 
> [...]

Applied to powerpc/next.

[1/2] sched/topology: Allow archs to override cpu_smt_mask
  https://git.kernel.org/powerpc/c/3babbe447d76ac2919ec4d0eb3b0adfb22f5b03c
[2/2] powerpc/topology: Override cpu_smt_mask
  https://git.kernel.org/powerpc/c/f3232321db58480804f80d59aeb651a5c859a200

cheers

Re: [PATCH v6 0/8] powerpc/watchpoint: Bug fixes plus new feature flag

[Michael Ellerman]

On Wed, 2 Sep 2020 09:59:37 +0530, Ravi Bangoria wrote:
> Patch #1 fixes issue for quardword instruction on p10 predecessors.
> Patch #2 fixes issue for vector instructions.
> Patch #3 fixes a bug about watchpoint not firing when created with
>  ptrace PPC_PTRACE_SETHWDEBUG and CONFIG_HAVE_HW_BREAKPOINT=N.
>  The fix uses HW_BRK_TYPE_PRIV_ALL for ptrace user which, I
>  guess, should be fine because we don't leak any kernel
>  addresses and PRIV_ALL will also help to cover scenarios when
>  kernel accesses user memory.
> Patch #4,#5 fixes infinite exception bug, again the bug happens only
>  with CONFIG_HAVE_HW_BREAKPOINT=N.
> Patch #6 fixes two places where we are missing to set hw_len.
> Patch #7 introduce new feature bit PPC_DEBUG_FEATURE_DATA_BP_ARCH_31
>  which will be set when running on ISA 3.1 compliant machine.
> Patch #8 finally adds selftest to test scenarios fixed by patch#2,#3
>  and also moves MODE_EXACT tests outside of BP_RANGE condition.
> 
> [...]

Applied to powerpc/next.

[1/8] powerpc/watchpoint: Fix quadword instruction handling on p10 predecessors
  https://git.kernel.org/powerpc/c/4759c11ed20454b7b36db4ec15f7d5aa1519af4a
[2/8] powerpc/watchpoint: Fix handling of vector instructions
  https://git.kernel.org/powerpc/c/4441eb02333a9b46a0d919aa7a6d3b137b5f2562
[3/8] powerpc/watchpoint/ptrace: Fix SETHWDEBUG when CONFIG_HAVE_HW_BREAKPOINT=N
  https://git.kernel.org/powerpc/c/9b6b7c680cc20971444d9f836e49fc98848bcd0a
[4/8] powerpc/watchpoint: Move DAWR detection logic outside of hw_breakpoint.c
  https://git.kernel.org/powerpc/c/edc8dd99b29e4d705c45e2a3a6c01b096ee056db
[5/8] powerpc/watchpoint: Fix exception handling for CONFIG_HAVE_HW_BREAKPOINT=N
  https://git.kernel.org/powerpc/c/5b905d77987de065bdd3a2906816b5f143df087b
[6/8] powerpc/watchpoint: Add hw_len wherever missing
  https://git.kernel.org/powerpc/c/58da5984d2ea6d95f3f9d9e8dd9f7e1b0dddfb3c
[7/8] powerpc/watchpoint/ptrace: Introduce PPC_DEBUG_FEATURE_DATA_BP_ARCH_31
  https://git.kernel.org/powerpc/c/fa725cc53d353110f39a9e5b9f60d6acb2c7ff49
[8/8] selftests/powerpc: Tests for kernel accessing user memory
  https://git.kernel.org/powerpc/c/ac234524056da4e0c081f682da3ea25cdaab737a

cheers

Re: [PATCH] powerpc/powernv/idle: add a basic stop 0-3 driver for POWER10

[Michael Ellerman]

On Wed, 19 Aug 2020 19:47:00 +1000, Nicholas Piggin wrote:
> This driver does not restore stop > 3 state, so it limits itself
> to states which do not lose full state or TB.
> 
> The POWER10 SPRs are sufficiently different from P9 that it seems
> easier to split out the P10 code. The POWER10 deep sleep code
> (e.g., the BHRB restore) has been taken out, but it can be re-added
> when stop > 3 support is added.

Applied to powerpc/next.

[1/1] powerpc/powernv/idle: add a basic stop 0-3 driver for POWER10
  https://git.kernel.org/powerpc/c/ffd2961bb41f797eb00b58e019b707555197275e

cheers

Re: [PATCH 0/5] powerpc/tau: TAU driver fixes

[Michael Ellerman]

On Sat, 05 Sep 2020 09:02:20 +1000, Finn Thain wrote:
> This patch series fixes various bugs in the Thermal Assist Unit driver.
> It was tested on 266 MHz and 292 MHz PowerBook G3 laptops.
> 
> 
> Finn Thain (5):
>   powerpc/tau: Use appropriate temperature sample interval
>   powerpc/tau: Convert from timer to workqueue
>   powerpc/tau: Remove duplicated set_thresholds() call
>   powerpc/tau: Check processor type before enabling TAU interrupt
>   powerpc/tau: Disable TAU between measurements
> 
> [...]

Applied to powerpc/next.

[1/5] powerpc/tau: Use appropriate temperature sample interval
  https://git.kernel.org/powerpc/c/66943005cc41f48e4d05614e8f76c0ca1812f0fd
[2/5] powerpc/tau: Convert from timer to workqueue
  https://git.kernel.org/powerpc/c/b1c6a0a10bfaf36ec82fde6f621da72407fa60a1
[3/5] powerpc/tau: Remove duplicated set_thresholds() call
  https://git.kernel.org/powerpc/c/420ab2bc7544d978a5d0762ee736412fe9c796ab
[4/5] powerpc/tau: Check processor type before enabling TAU interrupt
  https://git.kernel.org/powerpc/c/5e3119e15fed5b9a9a7e528665ff098a4a8dbdbc
[5/5] powerpc/tau: Disable TAU between measurements
  https://git.kernel.org/powerpc/c/e63d6fb5637e92725cf143559672a34b706bca4f

cheers

Re: [PATCH -next] macintosh: windfarm: use for_each_child_of_node() macro

[Michael Ellerman]

On Mon, 14 Sep 2020 14:14:11 +0800, Qinglang Miao wrote:
> Use for_each_child_of_node() macro instead of open coding it.

Applied to powerpc/next.

[1/1] macintosh: windfarm: use for_each_child_of_node() macro
  https://git.kernel.org/powerpc/c/8f7e57e8e29c4fc788811dd4db96126272b8df91

cheers

Re: [PATCH v2] powerpc/pci: unmap legacy INTx interrupts when a PHB is removed

[Michael Ellerman]

On Fri, 7 Aug 2020 12:18:54 +0200, Cédric Le Goater wrote:
> When a passthrough IO adapter is removed from a pseries machine using
> hash MMU and the XIVE interrupt mode, the POWER hypervisor expects the
> guest OS to clear all page table entries related to the adapter. If
> some are still present, the RTAS call which isolates the PCI slot
> returns error 9001 "valid outstanding translations" and the removal of
> the IO adapter fails. This is because when the PHBs are scanned, Linux
> maps automatically the INTx interrupts in the Linux interrupt number
> space but these are never removed.
> 
> [...]

Applied to powerpc/next.

[1/1] powerpc/pci: unmap legacy INTx interrupts when a PHB is removed
  https://git.kernel.org/powerpc/c/3a3181e16fbde752007759f8759d25e0ff1fc425

cheers

Re: [PATCH v2] powerpc/powermac: Fix low_sleep_handler with KUAP and KUEP

[Michael Ellerman]

On Fri, 11 Sep 2020 10:29:15 + (UTC), Christophe Leroy wrote:
> low_sleep_handler() has an hardcoded restore of segment registers
> that doesn't take KUAP and KUEP into account.
> 
> Use head_32's load_segment_registers() routine instead.

Applied to powerpc/next.

[1/1] powerpc/powermac: Fix low_sleep_handler with KUAP and KUEP
  https://git.kernel.org/powerpc/c/2c637d2df4ee4830e9d3eb2bd5412250522ce96e

cheers

Re: [PATCH v1] powerpc/process: Tag an #endif to help locate the matching #ifdef.

[Michael Ellerman]

On Mon, 17 Aug 2020 05:46:45 + (UTC), Christophe Leroy wrote:
> That #endif is more than 100 lines after the matching #ifdef,
> and there are several #ifdef/#else/#endif inbetween.
> 
> Tag it as /* CONFIG_PPC_BOOK3S_64 */ to help locate the
> matching #ifdef.

Applied to powerpc/next.

[1/1] powerpc/process: Tag an #endif to help locate the matching #ifdef.
  https://git.kernel.org/powerpc/c/60d62bfd24efce1a595d259100b8a4e7a489e834

cheers

Re: [PATCH v1] powerpc/process: Replace #ifdef CONFIG_KALLSYMS by IS_ENABLED()

[Michael Ellerman]

On Mon, 17 Aug 2020 05:46:44 + (UTC), Christophe Leroy wrote:
> The #ifdef CONFIG_KALLSYMS encloses some printk which can
> compile in all cases.
> 
> Replace by IS_ENABLED().

Applied to powerpc/next.

[1/1] powerpc/process: Replace #ifdef CONFIG_KALLSYMS by IS_ENABLED()
  https://git.kernel.org/powerpc/c/8f020c7ca300fd60374f0347814c92ea513c24da

cheers

Re: [PATCH v1] powerpc/process: Replace an #ifdef CONFIG_PPC_BOOK3S_64 by IS_ENABLED()

[Michael Ellerman]

On Mon, 17 Aug 2020 05:46:42 + (UTC), Christophe Leroy wrote:
> This #ifdef CONFIG_PPC_BOOK3S_64 calls preload_new_slb_context()
> when radix is not enabled.
> 
> radix_enabled() is always defined, and the prototype for
> preload_new_slb_context() is always present, so the #ifdef
> is unneeded.
> 
> [...]

Applied to powerpc/next.

[1/1] powerpc/process: Replace an #ifdef CONFIG_PPC_BOOK3S_64 by IS_ENABLED()
  https://git.kernel.org/powerpc/c/bfac2799301c19d81122af04a8a3ad5ecae3737e

cheers

Re: [PATCH v1] powerpc/process: Replace an #ifdef CONFIG_PPC_47x by IS_ENABLED()

[Michael Ellerman]

On Mon, 17 Aug 2020 05:46:41 + (UTC), Christophe Leroy wrote:
> isync() is always defined, no need for an #ifdef.
> 
> Replace it by IS_ENABLED(CONFIG_PPC_47x).

Applied to powerpc/next.

[1/1] powerpc/process: Replace an #ifdef CONFIG_PPC_47x by IS_ENABLED()
  https://git.kernel.org/powerpc/c/04d476bfbb06426fef2985c8e53578bb04596a6f

cheers

Re: [PATCH v1] powerpc/process: Replace an #if defined(CONFIG_4xx) || defined(CONFIG_BOOKE) by IS_ENABLED()

[Michael Ellerman]

On Mon, 17 Aug 2020 05:46:43 + (UTC), Christophe Leroy wrote:
> The #if defined(CONFIG_4xx) || defined(CONFIG_BOOKE) encloses some
> printk which can be compiled in all cases.
> 
> Replace by IS_ENABLED().

Applied to powerpc/next.

[1/1] powerpc/process: Replace an #if defined(CONFIG_4xx) || 
defined(CONFIG_BOOKE) by IS_ENABLED()
  https://git.kernel.org/powerpc/c/2ec42996f5b12826466300a755413577b6913206

cheers

Re: [PATCH v1 1/4] powerpc/process: Remove useless #ifdef CONFIG_VSX

[Michael Ellerman]

On Mon, 17 Aug 2020 05:47:55 + (UTC), Christophe Leroy wrote:
> cpu_has_feature(CPU_FTR_VSX) returns false when CONFIG_VSX is
> not set.
> 
> There is no need to enclose the test in an #ifdef CONFIG_VSX.
> Remove it.

Applied to powerpc/next.

[1/4] powerpc/process: Remove useless #ifdef CONFIG_VSX
  https://git.kernel.org/powerpc/c/80739c2bd29133715d6828e333649a55095f4747
[2/4] powerpc/process: Remove useless #ifdef CONFIG_ALTIVEC
  https://git.kernel.org/powerpc/c/e3667ee427e224f9951eb3940a97477285548134
[3/4] powerpc/process: Remove useless #ifdef CONFIG_SPE
  https://git.kernel.org/powerpc/c/532ed1900d37a47c821718a0d8d28eb05b2c4d28
[4/4] powerpc/process: Remove useless #ifdef CONFIG_PPC_FPU
  https://git.kernel.org/powerpc/c/c83c192a6fbb1d4db4144c40296ed059f5eca384

cheers

Re: [PATCH] powerpc/uaccess: Add pre-update addressing to __put_user_asm_goto()

[Michael Ellerman]

On Fri, 4 Sep 2020 10:46:47 + (UTC), Christophe Leroy wrote:
> Enable pre-update addressing mode in __put_user_asm_goto()

Applied to powerpc/next.

[1/1] powerpc/uaccess: Add pre-update addressing to __put_user_asm_goto()
  https://git.kernel.org/powerpc/c/fcf1f26895a4f14618b0dc04e0801b123c55e4a3

cheers

Re: [PATCH] powerpc/kasan: Fix CONFIG_KASAN_VMALLOC for 8xx

[Michael Ellerman]

On Fri, 11 Sep 2020 05:05:38 + (UTC), Christophe Leroy wrote:
> Before the commit identified below, pages tables allocation was
> performed after the allocation of final shadow area for linear memory.
> But that commit switched the order, leading to page tables being
> already allocated at the time 8xx kasan_init_shadow_8M() is called.
> Due to this, kasan_init_shadow_8M() doesn't map the needed
> shadow entries because there are already page tables.
> 
> [...]

Applied to powerpc/next.

[1/1] powerpc/kasan: Fix CONFIG_KASAN_VMALLOC for 8xx
  https://git.kernel.org/powerpc/c/4c42dc5c69a8f24c467a6c997909d2f1d4efdc7f

cheers

Re: [PATCH] powerpc: Fix random segfault when freeing hugetlb range

[Michael Ellerman]

On Mon, 31 Aug 2020 07:58:19 + (UTC), Christophe Leroy wrote:
> The following random segfault is observed from time to time with
> map_hugetlb selftest:
> 
> root@localhost:~# ./map_hugetlb 1 19
> 524288 kB hugepages
> Mapping 1 Mbytes
> Segmentation fault
> 
> [...]

Applied to powerpc/next.

[1/1] powerpc: Fix random segfault when freeing hugetlb range
  https://git.kernel.org/powerpc/c/542db12a9c42d1ce70c45091765e02f74c129f43

cheers

Re: [PATCH 1/3] powerpc/uaccess: Switch __put_user_size_allowed() to __put_user_asm_goto()

[Michael Ellerman]

On Fri, 4 Sep 2020 11:01:30 + (UTC), Christophe Leroy wrote:
> __put_user_asm_goto() provides more flexibility to GCC and avoids using
> a local variable to tell if the write succeeded or not.
> GCC can then avoid implementing a cmp in the fast path.
> 
> See the difference for a small function like the PPC64 version of
> save_general_regs() in arch/powerpc/kernel/signal_32.c:
> 
> [...]

Applied to powerpc/next.

[1/3] powerpc/uaccess: Switch __put_user_size_allowed() to __put_user_asm_goto()
  https://git.kernel.org/powerpc/c/ee0a49a6870ea75e25b4d4984c1bb6b3b7c65f2b
[2/3] powerpc/uaccess: Switch __patch_instruction() to __put_user_asm_goto()
  https://git.kernel.org/powerpc/c/e64ac41ab0c510b3f85199a585eb886cad92fb19
[3/3] powerpc/uaccess: Remove __put_user_asm() and __put_user_asm2()
  https://git.kernel.org/powerpc/c/7fdf966bed155b214f4f1f9b67825a40b2e9b998

cheers

Re: [PATCH 1/2] powerpc/8xx: Refactor calculation of number of entries per PTE in page tables

[Michael Ellerman]

On Mon, 31 Aug 2020 08:30:43 + (UTC), Christophe Leroy wrote:
> On 8xx, the number of entries occupied by a PTE in the page tables
> depends on the size of the page. At the time being, this calculation
> is done in two places: in pte_update() and in set_huge_pte_at()
> 
> Refactor this calculation into a helper called
> number_of_cells_per_pte(). For the time being, the val param is
> unused. It will be used by following patch.
> 
> [...]

Applied to powerpc/next.

[1/2] powerpc/8xx: Refactor calculation of number of entries per PTE in page 
tables
  https://git.kernel.org/powerpc/c/175a1511fed16108dcb823f0af8e72325a1f
[2/2] powerpc/8xx: Support 16k hugepages with 4k pages
  https://git.kernel.org/powerpc/c/e47168f3d1b14af5281cf50c59561d59d28201f9

cheers

Re: [PATCH 1/2] powerpc/32: Fix vmap stack - Do not activate MMU before reading task struct

[Michael Ellerman]

On Mon, 7 Sep 2020 13:42:09 + (UTC), Christophe Leroy wrote:
> We need r1 to be properly set before activating MMU, so
> reading task_struct->stack must be done with MMU off.
> 
> This means we need an additional register to play with MSR
> bits while r11 now points to the stack. For that, move r10
> back to CR (As is already done for hash MMU) and use r10.
> 
> [...]

Applied to powerpc/next.

[1/2] powerpc/32: Fix vmap stack - Do not activate MMU before reading task 
struct
  https://git.kernel.org/powerpc/c/c118c7303ad528be8ff2aea8cd1ee15452c763f0
[2/2] powerpc/32: Fix vmap stack - Properly set r1 before activating MMU
  https://git.kernel.org/powerpc/c/da7bb43ab9da39bcfed0d146ce94e1f0cbae4ca0

cheers

Re: [PATCH v3] powerpc/pseries/svm: Allocate SWIOTLB buffer anywhere in memory

[Michael Ellerman]

On Tue, 18 Aug 2020 19:11:26 -0300, Thiago Jung Bauermann wrote:
> POWER secure guests (i.e., guests which use the Protection Execution
> Facility) need to use SWIOTLB to be able to do I/O with the hypervisor, but
> they don't need the SWIOTLB memory to be in low addresses since the
> hypervisor doesn't have any addressing limitation.
> 
> This solves a SWIOTLB initialization problem we are seeing in secure guests
> with 128 GB of RAM: they are configured with 4 GB of crashkernel reserved
> memory, which leaves no space for SWIOTLB in low addresses.
> 
> [...]

Applied to powerpc/next.

[1/1] powerpc/pseries/svm: Allocate SWIOTLB buffer anywhere in memory
  https://git.kernel.org/powerpc/c/eae9eec476d13fad9af6da1f44a054ee02b7b161

cheers

Re: [PATCH v2 1/4] powerpc/percpu: Update percpu bootmem allocator

[Michael Ellerman]

On Mon, 8 Jun 2020 12:39:01 +0530, Aneesh Kumar K.V wrote:
> This update the ppc64 version to be closer to x86/sparc.

Applied to powerpc/next.

[1/4] powerpc/percpu: Update percpu bootmem allocator
  https://git.kernel.org/powerpc/c/2a32abac8860aa1c3a1fc99973ce67179575b36c
[2/4] powerpc/64/mm: implement page mapping percpu first chunk allocator
  https://git.kernel.org/powerpc/c/eb553f16973ade990d05946af9ae191394712c8a
[3/4] powerpc/book3s64/hash/4k: Support large linear mapping range with 4K
  https://git.kernel.org/powerpc/c/7746406baa3bc9e23fdd7b7da2f04d86e25ab837
[4/4] powerpc/mm/book3s: Split radix and hash MAX_PHYSMEM limit
  https://git.kernel.org/powerpc/c/b32d5d7e920a364287f6206af2d20179978a617d

cheers

Re: [PATCH] powerepc/book3s64/hash: Align start/end address correctly with bolt mapping

[Michael Ellerman]

On Mon, 7 Sep 2020 12:55:39 +0530, Aneesh Kumar K.V wrote:
> This ensures we don't do a partial mapping of memory. With nvdimm, when
> creating namespaces with size not aligned to 16MB, the kernel ends up 
> partially
> mapping the pages. This can result in kernel adding multiple hash page table
> entries for the same range. A new namespace will result in
> create_section_mapping() with start and end overlapping an already existing
> bolted hash page table entry.
> 
> [...]

Applied to powerpc/next.

[1/1] powerepc/book3s64/hash: Align start/end address correctly with bolt 
mapping
  https://git.kernel.org/powerpc/c/79b123cdf9cf0d4a1620baa8c611962626323a08

cheers

[PATCH v2 2/2] powerpc/64s: Convert some cpu_setup() and cpu_restore() functions to C

[Jordan Niethe]

The only thing keeping the cpu_setup() and cpu_restore() functions used
in the cputable entries for Power7, Power8, Power9 and Power10 in
assembly was cpu_restore() being called before there was a stack in
generic_secondary_smp_init(). Commit ("powerpc/64: Set up a kernel stack
for secondaries before cpu_restore()") means that it is now possible to
use C.

Rewrite the functions in C so they are a little bit easier to read. This
is not changing their functionality.

Signed-off-by: Jordan Niethe 
---
 arch/powerpc/include/asm/cpu_setup_power.h |  12 +
 arch/powerpc/kernel/cpu_setup_power.S  | 252 ---
 arch/powerpc/kernel/cpu_setup_power.c  | 269 +
 arch/powerpc/kernel/cputable.c |   9 +-
 4 files changed, 282 insertions(+), 260 deletions(-)
 create mode 100644 arch/powerpc/include/asm/cpu_setup_power.h
 delete mode 100644 arch/powerpc/kernel/cpu_setup_power.S
 create mode 100644 arch/powerpc/kernel/cpu_setup_power.c

diff --git a/arch/powerpc/include/asm/cpu_setup_power.h 
b/arch/powerpc/include/asm/cpu_setup_power.h
new file mode 100644
index ..24be9131f803
--- /dev/null
+++ b/arch/powerpc/include/asm/cpu_setup_power.h
@@ -0,0 +1,12 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * Copyright (C) 2020 IBM Corporation
+ */
+void __setup_cpu_power7(unsigned long offset, struct cpu_spec *spec);
+void __restore_cpu_power7(void);
+void __setup_cpu_power8(unsigned long offset, struct cpu_spec *spec);
+void __restore_cpu_power8(void);
+void __setup_cpu_power9(unsigned long offset, struct cpu_spec *spec);
+void __restore_cpu_power9(void);
+void __setup_cpu_power10(unsigned long offset, struct cpu_spec *spec);
+void __restore_cpu_power10(void);
diff --git a/arch/powerpc/kernel/cpu_setup_power.S 
b/arch/powerpc/kernel/cpu_setup_power.S
deleted file mode 100644
index 704e8b9501ee..
--- a/arch/powerpc/kernel/cpu_setup_power.S
+++ /dev/null
@@ -1,252 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0-or-later */
-/*
- * This file contains low level CPU setup functions.
- *Copyright (C) 2003 Benjamin Herrenschmidt (b...@kernel.crashing.org)
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-/* Entry: r3 = crap, r4 = ptr to cputable entry
- *
- * Note that we can be called twice for pseudo-PVRs
- */
-_GLOBAL(__setup_cpu_power7)
-   mflrr11
-   bl  __init_hvmode_206
-   mtlrr11
-   beqlr
-   li  r0,0
-   mtspr   SPRN_LPID,r0
-   LOAD_REG_IMMEDIATE(r0, PCR_MASK)
-   mtspr   SPRN_PCR,r0
-   mfspr   r3,SPRN_LPCR
-   li  r4,(LPCR_LPES1 >> LPCR_LPES_SH)
-   bl  __init_LPCR_ISA206
-   mtlrr11
-   blr
-
-_GLOBAL(__restore_cpu_power7)
-   mflrr11
-   mfmsr   r3
-   rldicl. r0,r3,4,63
-   beqlr
-   li  r0,0
-   mtspr   SPRN_LPID,r0
-   LOAD_REG_IMMEDIATE(r0, PCR_MASK)
-   mtspr   SPRN_PCR,r0
-   mfspr   r3,SPRN_LPCR
-   li  r4,(LPCR_LPES1 >> LPCR_LPES_SH)
-   bl  __init_LPCR_ISA206
-   mtlrr11
-   blr
-
-_GLOBAL(__setup_cpu_power8)
-   mflrr11
-   bl  __init_FSCR
-   bl  __init_PMU
-   bl  __init_PMU_ISA207
-   bl  __init_hvmode_206
-   mtlrr11
-   beqlr
-   li  r0,0
-   mtspr   SPRN_LPID,r0
-   LOAD_REG_IMMEDIATE(r0, PCR_MASK)
-   mtspr   SPRN_PCR,r0
-   mfspr   r3,SPRN_LPCR
-   ori r3, r3, LPCR_PECEDH
-   li  r4,0 /* LPES = 0 */
-   bl  __init_LPCR_ISA206
-   bl  __init_HFSCR
-   bl  __init_PMU_HV
-   bl  __init_PMU_HV_ISA207
-   mtlrr11
-   blr
-
-_GLOBAL(__restore_cpu_power8)
-   mflrr11
-   bl  __init_FSCR
-   bl  __init_PMU
-   bl  __init_PMU_ISA207
-   mfmsr   r3
-   rldicl. r0,r3,4,63
-   mtlrr11
-   beqlr
-   li  r0,0
-   mtspr   SPRN_LPID,r0
-   LOAD_REG_IMMEDIATE(r0, PCR_MASK)
-   mtspr   SPRN_PCR,r0
-   mfspr   r3,SPRN_LPCR
-   ori r3, r3, LPCR_PECEDH
-   li  r4,0 /* LPES = 0 */
-   bl  __init_LPCR_ISA206
-   bl  __init_HFSCR
-   bl  __init_PMU_HV
-   bl  __init_PMU_HV_ISA207
-   mtlrr11
-   blr
-
-_GLOBAL(__setup_cpu_power10)
-   mflrr11
-   bl  __init_FSCR_power10
-   bl  __init_PMU
-   bl  __init_PMU_ISA31
-   b   1f
-
-_GLOBAL(__setup_cpu_power9)
-   mflrr11
-   bl  __init_FSCR_power9
-   bl  __init_PMU
-1: bl  __init_hvmode_206
-   mtlrr11
-   beqlr
-   li  r0,0
-   mtspr   SPRN_PSSCR,r0
-   mtspr   SPRN_LPID,r0
-   mtspr   SPRN_PID,r0
-   LOAD_REG_IMMEDIATE(r0, PCR_MASK)
-   mtspr   SPRN_PCR,r0
-   mfspr   r3,SPRN_LPCR
-   LOAD_REG_IMMEDIATE(r4, LPCR_PECEDH | LPCR_PECE_HVEE | LPCR_HVICE  | 
LPCR_HEIC)
-   or  r3, r3, r4
-   LOAD_REG_IMMEDIATE(r4, 

[PATCH v2 1/2] powerpc/64: Set up a kernel stack for secondaries before cpu_restore()

[Jordan Niethe]

Currently in generic_secondary_smp_init(), cur_cpu_spec->cpu_restore()
is called before a stack has been set up in r1. This was previously fine
as the cpu_restore() functions were implemented in assembly and did not
use a stack. However commit 5a61ef74f269 ("powerpc/64s: Support new
device tree binding for discovering CPU features") used
__restore_cpu_cpufeatures() as the cpu_restore() function for a
device-tree features based cputable entry. This is a C function and
hence uses a stack in r1.

generic_secondary_smp_init() is entered on the secondary cpus via the
primary cpu using the OPAL call opal_start_cpu(). In OPAL, each hardware
thread has its own stack. The OPAL call is ran in the primary's hardware
thread. During the call, a job is scheduled on a secondary cpu that will
start executing at the address of generic_secondary_smp_init().  Hence
the value that will be left in r1 when the secondary cpu enters the
kernel is part of that secondary cpu's individual OPAL stack. This means
that __restore_cpu_cpufeatures() will write to that OPAL stack. This is
not horribly bad as each hardware thread has its own stack and the call
that enters the kernel from OPAL never returns, but it is still wrong
and should be corrected.

Create the temp kernel stack before calling cpu_restore().

Fixes: 5a61ef74f269 ("powerpc/64s: Support new device tree binding for 
discovering CPU features")
Signed-off-by: Jordan Niethe 
---
v2: Add more detail to the commit message
---
 arch/powerpc/kernel/head_64.S | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S
index 0e05a9a47a4b..4b7f4c6c2600 100644
--- a/arch/powerpc/kernel/head_64.S
+++ b/arch/powerpc/kernel/head_64.S
@@ -420,6 +420,10 @@ generic_secondary_common_init:
/* From now on, r24 is expected to be logical cpuid */
mr  r24,r5
 
+   /* Create a temp kernel stack for use before relocation is on.  */
+   ld  r1,PACAEMERGSP(r13)
+   subir1,r1,STACK_FRAME_OVERHEAD
+
/* See if we need to call a cpu state restore handler */
LOAD_REG_ADDR(r23, cur_cpu_spec)
ld  r23,0(r23)
@@ -448,10 +452,6 @@ generic_secondary_common_init:
sync/* order paca.run and cur_cpu_spec */
isync   /* In case code patching happened */
 
-   /* Create a temp kernel stack for use before relocation is on.  */
-   ld  r1,PACAEMERGSP(r13)
-   subir1,r1,STACK_FRAME_OVERHEAD
-
b   __secondary_start
 #endif /* SMP */
 
-- 
2.17.1

linux-next: manual merge of the akpm-current tree with the powerpc tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the akpm-current tree got a conflict in:

  arch/powerpc/mm/kasan/kasan_init_32.c

between commit:

  4c42dc5c69a8 ("powerpc/kasan: Fix CONFIG_KASAN_VMALLOC for 8xx")

from the powerpc tree and commit:

  76713c119a9d ("arch, drivers: replace for_each_membock() with 
for_each_mem_range()")

from the akpm-current tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/powerpc/mm/kasan/kasan_init_32.c
index 929716ea21e9,26fda3203320..
--- a/arch/powerpc/mm/kasan/kasan_init_32.c
+++ b/arch/powerpc/mm/kasan/kasan_init_32.c
@@@ -137,12 -138,12 +137,12 @@@ void __init kasan_mmu_init(void
  
  void __init kasan_init(void)
  {
-   struct memblock_region *reg;
+   phys_addr_t base, end;
 +  int ret;
+   u64 i;
  
-   for_each_memblock(memory, reg) {
-   phys_addr_t base = reg->base;
-   phys_addr_t top = min(base + reg->size, total_lowmem);
+   for_each_mem_range(i, , ) {
+   phys_addr_t top = min(end, total_lowmem);
 -  int ret;
  
if (base >= top)
continue;


pgpQ6PSlQ3vg5.pgp
Description: OpenPGP digital signature

Re: [PATCH 2/3] powerpc/mce: Add debugfs interface to inject MCE

[kernel test robot]

Hi Ganesh,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on powerpc/next]
[also build test WARNING on v5.9-rc5 next-20200916]
[cannot apply to scottwood/next mpe/next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Ganesh-Goudar/powerpc-mce-Fix-mce-handler-and-add-selftest/20200917-092355
base:   https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: powerpc-allyesconfig (attached as .config)
compiler: powerpc64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=powerpc 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All warnings (new ones prefixed by >>):

   arch/powerpc/sysdev/mce_error_inject.c: In function 'insert_slb_entry':
>> arch/powerpc/sysdev/mce_error_inject.c:52:22: warning: variable 'paca' set 
>> but not used [-Wunused-but-set-variable]
  52 |  struct paca_struct *paca;
 |  ^~~~

# 
https://github.com/0day-ci/linux/commit/4ab1196e8e542fdf0e7cda8638dfb0e5771fd98e
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Ganesh-Goudar/powerpc-mce-Fix-mce-handler-and-add-selftest/20200917-092355
git checkout 4ab1196e8e542fdf0e7cda8638dfb0e5771fd98e
vim +/paca +52 arch/powerpc/sysdev/mce_error_inject.c

48  
49  static void insert_slb_entry(char *p, int ssize)
50  {
51  unsigned long flags, entry;
  > 52  struct paca_struct *paca;
53  
54  flags = SLB_VSID_KERNEL | mmu_psize_defs[MMU_PAGE_64K].sllp;
55  
56  preempt_disable();
57  
58  paca = get_paca();
59  
60  entry = get_slb_index();
61  asm volatile("slbmte %0,%1" :
62  : "r" (mk_vsid_data((unsigned long)p, ssize, 
flags)),
63"r" (mk_esid_data((unsigned long)p, ssize, 
entry))
64  : "memory");
65  
66  entry = get_slb_index();
67  asm volatile("slbmte %0,%1" :
68  : "r" (mk_vsid_data((unsigned long)p, ssize, 
flags)),
69"r" (mk_esid_data((unsigned long)p, ssize, 
entry))
70  : "memory");
71  preempt_enable();
72  p[0] = '!';
73  }
74  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip

Re: [PATCH 2/3] powerpc/mce: Add debugfs interface to inject MCE

[kernel test robot]

Hi Ganesh,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on powerpc/next]
[also build test ERROR on v5.9-rc5 next-20200916]
[cannot apply to scottwood/next mpe/next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Ganesh-Goudar/powerpc-mce-Fix-mce-handler-and-add-selftest/20200917-092355
base:   https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: powerpc-randconfig-r021-20200917 (attached as .config)
compiler: powerpc-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=powerpc 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All errors (new ones prefixed by >>):

   arch/powerpc/sysdev/mce_error_inject.c: In function 'get_slb_index':
>> arch/powerpc/sysdev/mce_error_inject.c:17:10: error: implicit declaration of 
>> function 'get_paca' [-Werror=implicit-function-declaration]
  17 |  index = get_paca()->stab_rr;
 |  ^~~~
>> arch/powerpc/sysdev/mce_error_inject.c:17:20: error: invalid type argument 
>> of '->' (have 'int')
  17 |  index = get_paca()->stab_rr;
 |^~
>> arch/powerpc/sysdev/mce_error_inject.c:22:15: error: 'mmu_slb_size' 
>> undeclared (first use in this function)
  22 |  if (index < (mmu_slb_size - 1))
 |   ^~~~
   arch/powerpc/sysdev/mce_error_inject.c:22:15: note: each undeclared 
identifier is reported only once for each function it appears in
>> arch/powerpc/sysdev/mce_error_inject.c:25:11: error: 'SLB_NUM_BOLTED' 
>> undeclared (first use in this function)
  25 |   index = SLB_NUM_BOLTED;
 |   ^~
   arch/powerpc/sysdev/mce_error_inject.c:26:12: error: invalid type argument 
of '->' (have 'int')
  26 |  get_paca()->stab_rr = index;
 |^~
   arch/powerpc/sysdev/mce_error_inject.c: In function 'mk_esid_data':
>> arch/powerpc/sysdev/mce_error_inject.c:31:15: error: 'MMU_SEGSIZE_256M' 
>> undeclared (first use in this function); did you mean 'MMU_PAGE_256M'?
  31 |  (((ssize) == MMU_SEGSIZE_256M) ? ESID_MASK : ESID_MASK_1T)
 |   ^~~~
   arch/powerpc/sysdev/mce_error_inject.c:36:15: note: in expansion of macro 
'slb_esid_mask'
  36 |  return (ea & slb_esid_mask(ssize)) | SLB_ESID_V | slot;
 |   ^
>> arch/powerpc/sysdev/mce_error_inject.c:31:35: error: 'ESID_MASK' undeclared 
>> (first use in this function); did you mean 'NMI_MASK'?
  31 |  (((ssize) == MMU_SEGSIZE_256M) ? ESID_MASK : ESID_MASK_1T)
 |   ^
   arch/powerpc/sysdev/mce_error_inject.c:36:15: note: in expansion of macro 
'slb_esid_mask'
  36 |  return (ea & slb_esid_mask(ssize)) | SLB_ESID_V | slot;
 |   ^
>> arch/powerpc/sysdev/mce_error_inject.c:31:47: error: 'ESID_MASK_1T' 
>> undeclared (first use in this function)
  31 |  (((ssize) == MMU_SEGSIZE_256M) ? ESID_MASK : ESID_MASK_1T)
 |   ^~~~
   arch/powerpc/sysdev/mce_error_inject.c:36:15: note: in expansion of macro 
'slb_esid_mask'
  36 |  return (ea & slb_esid_mask(ssize)) | SLB_ESID_V | slot;
 |   ^
>> arch/powerpc/sysdev/mce_error_inject.c:36:39: error: 'SLB_ESID_V' undeclared 
>> (first use in this function)
  36 |  return (ea & slb_esid_mask(ssize)) | SLB_ESID_V | slot;
 |   ^~
   arch/powerpc/sysdev/mce_error_inject.c: In function 'mk_vsid_data':
>> arch/powerpc/sysdev/mce_error_inject.c:45:10: error: implicit declaration of 
>> function 'get_kernel_vsid' [-Werror=implicit-function-declaration]
  45 |  return (get_kernel_vsid(ea, ssize) << slb_vsid_shift(ssize)) | 
flags |
 |  ^~~
   arch/powerpc/sysdev/mce_error_inject.c:40:14: error: 'MMU_SEGSIZE_256M' 
undeclared (first use in this function); did you mean 'MMU_PAGE_256M'?
  40 |  ((ssize) == MMU_SEGSIZE_256M ? SLB_VSID_SHIFT : SLB_VSID_SHIFT_1T)
 |  ^~~~
   arch/powerpc/sysdev/mce_error_inject.c:45:40: note: in expansion of macro 
'slb_vsid_shift'
  45 |  return (get_kernel_vsid(ea, ssize) << slb_vsid_shift(ssize)) | 
flags |
 |   

Re: [oss-drivers] [trivial PATCH] treewide: Convert switch/case fallthrough; to break;

[Simon Horman]

On Wed, Sep 09, 2020 at 01:06:39PM -0700, Joe Perches wrote:
> fallthrough to a separate case/default label break; isn't very readable.
> 
> Convert pseudo-keyword fallthrough; statements to a simple break; when
> the next label is case or default and the only statement in the next
> label block is break;
> 
> Found using:
> 
> $ grep-2.5.4 -rP --include=*.[ch] -n 
> "fallthrough;(\s*(case\s+\w+|default)\s*:\s*){1,7}break;" *
> 
> Miscellanea:
> 
> o Move or coalesce a couple label blocks above a default: block.
> 
> Signed-off-by: Joe Perches 

...

> diff --git a/drivers/net/ethernet/netronome/nfp/nfpcore/nfp6000_pcie.c 
> b/drivers/net/ethernet/netronome/nfp/nfpcore/nfp6000_pcie.c
> index 252fe06f58aa..1d5b87079104 100644
> --- a/drivers/net/ethernet/netronome/nfp/nfpcore/nfp6000_pcie.c
> +++ b/drivers/net/ethernet/netronome/nfp/nfpcore/nfp6000_pcie.c
> @@ -345,7 +345,7 @@ static int matching_bar(struct nfp_bar *bar, u32 tgt, u32 
> act, u32 tok,
>   baract = NFP_CPP_ACTION_RW;
>   if (act == 0)
>   act = NFP_CPP_ACTION_RW;
> - fallthrough;
> + break;
>   case NFP_PCIE_BAR_PCIE2CPP_MapType_FIXED:
>   break;
>   default:

This is a cascading fall-through handling all map types.
I don't think this change improves readability.

...

[powerpc:next-test] BUILD SUCCESS 10ea0d6512bcf308ed3d00b93571452448cea06c

[kernel test robot]

  defconfig
s390 allyesconfig
s390defconfig
i386 allyesconfig
sparcallyesconfig
i386defconfig
mips allyesconfig
mips allmodconfig
powerpc  allyesconfig
powerpc  allmodconfig
powerpc   allnoconfig
x86_64   randconfig-a006-20200916
x86_64   randconfig-a004-20200916
x86_64   randconfig-a003-20200916
x86_64   randconfig-a002-20200916
x86_64   randconfig-a001-20200916
x86_64   randconfig-a005-20200916
i386 randconfig-a004-20200916
i386 randconfig-a006-20200916
i386 randconfig-a003-20200916
i386 randconfig-a001-20200916
i386 randconfig-a002-20200916
i386 randconfig-a005-20200916
i386 randconfig-a004-20200917
i386 randconfig-a006-20200917
i386 randconfig-a003-20200917
i386 randconfig-a001-20200917
i386 randconfig-a002-20200917
i386 randconfig-a005-20200917
x86_64   randconfig-a014-20200917
x86_64   randconfig-a011-20200917
x86_64   randconfig-a016-20200917
x86_64   randconfig-a012-20200917
x86_64   randconfig-a015-20200917
x86_64   randconfig-a013-20200917
i386 randconfig-a015-20200917
i386 randconfig-a014-20200917
i386 randconfig-a011-20200917
i386 randconfig-a013-20200917
i386 randconfig-a016-20200917
i386 randconfig-a012-20200917
i386 randconfig-a015-20200916
i386 randconfig-a014-20200916
i386 randconfig-a011-20200916
i386 randconfig-a013-20200916
i386 randconfig-a016-20200916
i386 randconfig-a012-20200916
riscvallyesconfig
riscv allnoconfig
riscv   defconfig
riscvallmodconfig
riscvnommu_k210_defconfig
riscvnommu_virt_defconfig
riscv  rv32_defconfig
x86_64   rhel
x86_64   allyesconfig
x86_64rhel-7.6-kselftests
x86_64  defconfig
x86_64   rhel-8.3
x86_64  kexec

clang tested configs:
x86_64   randconfig-a006-20200917
x86_64   randconfig-a004-20200917
x86_64   randconfig-a003-20200917
x86_64   randconfig-a002-20200917
x86_64   randconfig-a001-20200917
x86_64   randconfig-a005-20200917
x86_64   randconfig-a014-20200916
x86_64   randconfig-a011-20200916
x86_64   randconfig-a016-20200916
x86_64   randconfig-a012-20200916
x86_64   randconfig-a015-20200916
x86_64   randconfig-a013-20200916

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org

[powerpc:next] BUILD SUCCESS b5c8a2934eecbba3d688a911b98e92f8670ff462

[kernel test robot]

defconfig
mips allyesconfig
mips allmodconfig
powerpc  allyesconfig
powerpc  allmodconfig
powerpc   allnoconfig
x86_64   randconfig-a006-20200916
x86_64   randconfig-a004-20200916
x86_64   randconfig-a003-20200916
x86_64   randconfig-a002-20200916
x86_64   randconfig-a001-20200916
x86_64   randconfig-a005-20200916
i386 randconfig-a004-20200916
i386 randconfig-a006-20200916
i386 randconfig-a003-20200916
i386 randconfig-a001-20200916
i386 randconfig-a002-20200916
i386 randconfig-a005-20200916
i386 randconfig-a004-20200917
i386 randconfig-a006-20200917
i386 randconfig-a003-20200917
i386 randconfig-a001-20200917
i386 randconfig-a002-20200917
i386 randconfig-a005-20200917
x86_64   randconfig-a014-20200917
x86_64   randconfig-a011-20200917
x86_64   randconfig-a016-20200917
x86_64   randconfig-a012-20200917
x86_64   randconfig-a015-20200917
x86_64   randconfig-a013-20200917
i386 randconfig-a015-20200916
i386 randconfig-a014-20200916
i386 randconfig-a011-20200916
i386 randconfig-a013-20200916
i386 randconfig-a016-20200916
i386 randconfig-a012-20200916
i386 randconfig-a015-20200917
i386 randconfig-a014-20200917
i386 randconfig-a011-20200917
i386 randconfig-a013-20200917
i386 randconfig-a016-20200917
i386 randconfig-a012-20200917
riscvallyesconfig
riscv allnoconfig
riscv   defconfig
riscvallmodconfig
riscvnommu_k210_defconfig
riscvnommu_virt_defconfig
riscv  rv32_defconfig
x86_64   rhel
x86_64   allyesconfig
x86_64rhel-7.6-kselftests
x86_64  defconfig
x86_64   rhel-8.3
x86_64  kexec

clang tested configs:
x86_64   randconfig-a014-20200916
x86_64   randconfig-a011-20200916
x86_64   randconfig-a016-20200916
x86_64   randconfig-a012-20200916
x86_64   randconfig-a015-20200916
x86_64   randconfig-a013-20200916
x86_64   randconfig-a006-20200917
x86_64   randconfig-a004-20200917
x86_64   randconfig-a003-20200917
x86_64   randconfig-a002-20200917
x86_64   randconfig-a001-20200917
x86_64   randconfig-a005-20200917

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org

Re: [PATCH 1/2] ASoC: fsl_xcvr: Add XCVR ASoC CPU DAI driver

[Nicolin Chen]

Hi Viorel,

It looks pretty clean to me, though some small comments inline.

On Wed, Sep 16, 2020 at 12:17:55PM +0300, Viorel Suman (OSS) wrote:
> From: Viorel Suman 
> 
> XCVR (Audio Transceiver) is a on-chip functional module found
> on i.MX8MP. It support HDMI2.1 eARC, HDMI1.4 ARC and SPDIF.
> 
> Signed-off-by: Viorel Suman 

> +static const u32 fsl_xcvr_earc_channels[] = { 1, 2, 8, 16, 32, }; /* one bit 
> 6, 12 ? */

What's the meaning of the comments?

> +static const int fsl_xcvr_phy_arc_cfg[] = {
> + FSL_XCVR_PHY_CTRL_ARC_MODE_SE_EN, FSL_XCVR_PHY_CTRL_ARC_MODE_CM_EN,
> +};

Nit: better be u32 vs. int?

> +/** phy: true => phy, false => pll */
> +static int fsl_xcvr_ai_write(struct fsl_xcvr *xcvr, u8 reg, u32 data, bool 
> phy)
> +{
> + u32 val, idx, tidx;
> +
> + idx  = BIT(phy ? 26 : 24);
> + tidx = BIT(phy ? 27 : 25);
> +
> + regmap_write(xcvr->regmap, FSL_XCVR_PHY_AI_CTRL_CLR, 0xFF);
> + regmap_write(xcvr->regmap, FSL_XCVR_PHY_AI_CTRL_SET, reg);
> + regmap_write(xcvr->regmap, FSL_XCVR_PHY_AI_WDATA, data);
> + regmap_write(xcvr->regmap, FSL_XCVR_PHY_AI_CTRL_TOG, idx);
> +
> + do {
> + regmap_read(xcvr->regmap, FSL_XCVR_PHY_AI_CTRL, );
> + } while ((val & idx) != ((val & tidx) >> 1));

Might regmap_read_poll_timeout() be better? And it seems to poll
intentionally with no sleep nor timeout -- would be nice to have
a line of comments to explain why.

> > +static int fsl_xcvr_runtime_resume(struct device *dev)
> +{
> + struct fsl_xcvr *xcvr = dev_get_drvdata(dev);
> + int ret;
> +
> + ret = clk_prepare_enable(xcvr->ipg_clk);
> + if (ret) {
> + dev_err(dev, "failed to start IPG clock.\n");
> + return ret;
> + }
> +
> + ret = clk_prepare_enable(xcvr->pll_ipg_clk);
> + if (ret) {
> + dev_err(dev, "failed to start PLL IPG clock.\n");

Should it disable ipg_clk?

> + return ret;
> + }
> +
> + ret = clk_prepare_enable(xcvr->phy_clk);
> + if (ret) {
> + dev_err(dev, "failed to start PHY clock: %d\n", ret);
> + clk_disable_unprepare(xcvr->ipg_clk);

Should it disable pll_ipg_clk?

> + return ret;
> + }
> +
> + ret = clk_prepare_enable(xcvr->spba_clk);
> + if (ret) {
> + dev_err(dev, "failed to start SPBA clock.\n");
> + clk_disable_unprepare(xcvr->phy_clk);
> + clk_disable_unprepare(xcvr->ipg_clk);

Ditto

> + return ret;
> + }
> +
> + regcache_cache_only(xcvr->regmap, false);
> + regcache_mark_dirty(xcvr->regmap);
> + ret = regcache_sync(xcvr->regmap);
> +
> + if (ret) {
> + dev_err(dev, "failed to sync regcache.\n");
> + return ret;

What about those clocks? Probably better to have some error-out
labels at the end of the function?

> + }
> +
> + reset_control_assert(xcvr->reset);
> + reset_control_deassert(xcvr->reset);
> +
> + ret = fsl_xcvr_load_firmware(xcvr);
> + if (ret) {
> + dev_err(dev, "failed to load firmware.\n");
> + return ret;

Ditto

> + }
> +
> + /* Release M0+ reset */
> + ret = regmap_update_bits(xcvr->regmap, FSL_XCVR_EXT_CTRL,
> +  FSL_XCVR_EXT_CTRL_CORE_RESET, 0);
> + if (ret < 0) {
> + dev_err(dev, "M0+ core release failed: %d\n", ret);
> + return ret;

Ditto

> + }
> + mdelay(50);

Any reason to use mdelay over msleep for a 50ms wait? May add a
line of comments if mdelay is a must?