* Re: [RFC v1 0/2] Plumbing to support multiple secure memory backends.
From: Christoph Hellwig @ 2020-10-14 6:31 UTC (permalink / raw)
To: Ram Pai; +Cc: bharata, linuxppc-dev, kvm-ppc, farosas
In-Reply-To: <1602487663-7321-1-git-send-email-linuxram@us.ibm.com>
Please don't add an abstraction without a second implementation.
Once we have the implementation we can consider the tradeoffs. E.g.
if expensive indirect function calls are really needed vs simple
branches.
^ permalink raw reply
* [PATCH] powerpc/opal_elog: Handle multiple writes to ack attribute
From: Aneesh Kumar K.V @ 2020-10-14 6:48 UTC (permalink / raw)
To: linuxppc-dev, mpe
Cc: Aneesh Kumar K.V, Oliver O'Halloran, Mahesh Salgaonkar
Even though we use self removing sysfs helper, we still need
to make sure we do the final kobject delete conditionally.
sysfs_remove_file_self() will handle parallel calls to remove
the sysfs attribute file and returns true only in the caller
that removed the attribute file. The other parallel callers
are returned false. Do the final kobject delete checking
the return value of sysfs_remove_file_self().
Cc: Mahesh Salgaonkar <mahesh@linux.ibm.com>
Cc: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
---
arch/powerpc/platforms/powernv/opal-elog.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/opal-elog.c b/arch/powerpc/platforms/powernv/opal-elog.c
index 5e33b1fc67c2..37b380eef41a 100644
--- a/arch/powerpc/platforms/powernv/opal-elog.c
+++ b/arch/powerpc/platforms/powernv/opal-elog.c
@@ -72,9 +72,14 @@ static ssize_t elog_ack_store(struct elog_obj *elog_obj,
const char *buf,
size_t count)
{
- opal_send_ack_elog(elog_obj->id);
- sysfs_remove_file_self(&elog_obj->kobj, &attr->attr);
- kobject_put(&elog_obj->kobj);
+ /*
+ * Try to self remove this attribute. If we are successful,
+ * delete the kobject itself.
+ */
+ if (sysfs_remove_file_self(&elog_obj->kobj, &attr->attr)) {
+ opal_send_ack_elog(elog_obj->id);
+ kobject_put(&elog_obj->kobj);
+ }
return count;
}
--
2.26.2
^ permalink raw reply related
* Re: [PATCH] powerpc/opal_elog: Handle multiple writes to ack attribute
From: Mahesh J Salgaonkar @ 2020-10-14 7:14 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: Oliver O'Halloran, linuxppc-dev
In-Reply-To: <20201014064813.109515-1-aneesh.kumar@linux.ibm.com>
On 2020-10-14 12:18:13 Wed, Aneesh Kumar K.V wrote:
> Even though we use self removing sysfs helper, we still need
> to make sure we do the final kobject delete conditionally.
> sysfs_remove_file_self() will handle parallel calls to remove
> the sysfs attribute file and returns true only in the caller
> that removed the attribute file. The other parallel callers
> are returned false. Do the final kobject delete checking
> the return value of sysfs_remove_file_self().
>
> Cc: Mahesh Salgaonkar <mahesh@linux.ibm.com>
> Cc: Oliver O'Halloran <oohall@gmail.com>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> ---
> arch/powerpc/platforms/powernv/opal-elog.c | 11 ++++++++---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/platforms/powernv/opal-elog.c b/arch/powerpc/platforms/powernv/opal-elog.c
> index 5e33b1fc67c2..37b380eef41a 100644
> --- a/arch/powerpc/platforms/powernv/opal-elog.c
> +++ b/arch/powerpc/platforms/powernv/opal-elog.c
> @@ -72,9 +72,14 @@ static ssize_t elog_ack_store(struct elog_obj *elog_obj,
> const char *buf,
> size_t count)
> {
> - opal_send_ack_elog(elog_obj->id);
> - sysfs_remove_file_self(&elog_obj->kobj, &attr->attr);
> - kobject_put(&elog_obj->kobj);
> + /*
> + * Try to self remove this attribute. If we are successful,
> + * delete the kobject itself.
> + */
> + if (sysfs_remove_file_self(&elog_obj->kobj, &attr->attr)) {
> + opal_send_ack_elog(elog_obj->id);
> + kobject_put(&elog_obj->kobj);
> + }
> return count;
> }
Looks good.
Reviewed-by: Mahesh Salgaonkar <mahesh@linux.ibm.com>
Thanks,
-Mahesh.
^ permalink raw reply
* [PATCH v4 1/2] powerpc/64: Set up a kernel stack for secondaries before cpu_restore()
From: Jordan Niethe @ 2020-10-14 7:28 UTC (permalink / raw)
To: linuxppc-dev; +Cc: oohall, npiggin, 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().
As noted by mpe, for a kexec boot, the secondary CPUs are released from
the spin loop at address 0x60 by smp_release_cpus() and then jump to
generic_secondary_smp_init(). The call to smp_release_cpus() is in
setup_arch(), and it comes before the call to emergency_stack_init().
emergency_stack_init() allocates an emergency stack in the PACA for each
CPU. This address in the PACA is what is used to set up the temp kernel
stack in generic_secondary_smp_init(). Move releasing the secondary CPUs
to after the PACAs have been allocated an emergency stack, otherwise the
PACA stack pointer will contain garbage and hence the temp kernel stack
created from it will be broken.
Fixes: 5a61ef74f269 ("powerpc/64s: Support new device tree binding for discovering CPU features")
Signed-off-by: Jordan Niethe <jniethe5@gmail.com>
---
v2: Add more detail to the commit message
v3: Release secondary CPUs after the emergency stack is created
v4: No need to guard smp_release_cpus() with #ifdef CONFIG_SMP
---
arch/powerpc/kernel/head_64.S | 8 ++++----
arch/powerpc/kernel/setup-common.c | 4 ++--
2 files changed, 6 insertions(+), 6 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)
+ subi r1,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)
- subi r1,r1,STACK_FRAME_OVERHEAD
-
b __secondary_start
#endif /* SMP */
diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c
index 808ec9fab605..da8c71f321ad 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -919,8 +919,6 @@ void __init setup_arch(char **cmdline_p)
/* On BookE, setup per-core TLB data structures. */
setup_tlb_core_data();
-
- smp_release_cpus();
#endif
/* Print various info about the machine that has been gathered so far. */
@@ -944,6 +942,8 @@ void __init setup_arch(char **cmdline_p)
exc_lvl_early_init();
emergency_stack_init();
+ smp_release_cpus();
+
initmem_init();
early_memtest(min_low_pfn << PAGE_SHIFT, max_low_pfn << PAGE_SHIFT);
--
2.17.1
^ permalink raw reply related
* [PATCH v4 2/2] powerpc/64s: Convert some cpu_setup() and cpu_restore() functions to C
From: Jordan Niethe @ 2020-10-14 7:28 UTC (permalink / raw)
To: linuxppc-dev; +Cc: oohall, npiggin, Jordan Niethe
In-Reply-To: <20201014072837.24539-1-jniethe5@gmail.com>
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 <jniethe5@gmail.com>
---
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 | 12 +-
4 files changed, 285 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 000000000000..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..000000000000
--- 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 (benh@kernel.crashing.org)
- */
-
-#include <asm/processor.h>
-#include <asm/page.h>
-#include <asm/cputable.h>
-#include <asm/ppc_asm.h>
-#include <asm/asm-offsets.h>
-#include <asm/cache.h>
-#include <asm/book3s/64/mmu-hash.h>
-
-/* Entry: r3 = crap, r4 = ptr to cputable entry
- *
- * Note that we can be called twice for pseudo-PVRs
- */
-_GLOBAL(__setup_cpu_power7)
- mflr r11
- bl __init_hvmode_206
- mtlr r11
- 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
- mtlr r11
- blr
-
-_GLOBAL(__restore_cpu_power7)
- mflr r11
- 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
- mtlr r11
- blr
-
-_GLOBAL(__setup_cpu_power8)
- mflr r11
- bl __init_FSCR
- bl __init_PMU
- bl __init_PMU_ISA207
- bl __init_hvmode_206
- mtlr r11
- 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
- mtlr r11
- blr
-
-_GLOBAL(__restore_cpu_power8)
- mflr r11
- bl __init_FSCR
- bl __init_PMU
- bl __init_PMU_ISA207
- mfmsr r3
- rldicl. r0,r3,4,63
- mtlr r11
- 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
- mtlr r11
- blr
-
-_GLOBAL(__setup_cpu_power10)
- mflr r11
- bl __init_FSCR_power10
- bl __init_PMU
- bl __init_PMU_ISA31
- b 1f
-
-_GLOBAL(__setup_cpu_power9)
- mflr r11
- bl __init_FSCR_power9
- bl __init_PMU
-1: bl __init_hvmode_206
- mtlr r11
- 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, LPCR_UPRT | LPCR_HR)
- andc r3, r3, r4
- li r4,0 /* LPES = 0 */
- bl __init_LPCR_ISA300
- bl __init_HFSCR
- bl __init_PMU_HV
- mtlr r11
- blr
-
-_GLOBAL(__restore_cpu_power10)
- mflr r11
- bl __init_FSCR_power10
- bl __init_PMU
- bl __init_PMU_ISA31
- b 1f
-
-_GLOBAL(__restore_cpu_power9)
- mflr r11
- bl __init_FSCR_power9
- bl __init_PMU
-1: mfmsr r3
- rldicl. r0,r3,4,63
- mtlr r11
- 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, LPCR_UPRT | LPCR_HR)
- andc r3, r3, r4
- li r4,0 /* LPES = 0 */
- bl __init_LPCR_ISA300
- bl __init_HFSCR
- bl __init_PMU_HV
- mtlr r11
- blr
-
-__init_hvmode_206:
- /* Disable CPU_FTR_HVMODE and exit if MSR:HV is not set */
- mfmsr r3
- rldicl. r0,r3,4,63
- bnelr
- ld r5,CPU_SPEC_FEATURES(r4)
- LOAD_REG_IMMEDIATE(r6,CPU_FTR_HVMODE | CPU_FTR_P9_TM_HV_ASSIST)
- andc r5,r5,r6
- std r5,CPU_SPEC_FEATURES(r4)
- blr
-
-__init_LPCR_ISA206:
- /* Setup a sane LPCR:
- * Called with initial LPCR in R3 and desired LPES 2-bit value in R4
- *
- * LPES = 0b01 (HSRR0/1 used for 0x500)
- * PECE = 0b111
- * DPFD = 4
- * HDICE = 0
- * VC = 0b100 (VPM0=1, VPM1=0, ISL=0)
- * VRMASD = 0b10000 (L=1, LP=00)
- *
- * Other bits untouched for now
- */
- li r5,0x10
- rldimi r3,r5, LPCR_VRMASD_SH, 64-LPCR_VRMASD_SH-5
-
- /* POWER9 has no VRMASD */
-__init_LPCR_ISA300:
- rldimi r3,r4, LPCR_LPES_SH, 64-LPCR_LPES_SH-2
- ori r3,r3,(LPCR_PECE0|LPCR_PECE1|LPCR_PECE2)
- li r5,4
- rldimi r3,r5, LPCR_DPFD_SH, 64-LPCR_DPFD_SH-3
- clrrdi r3,r3,1 /* clear HDICE */
- li r5,4
- rldimi r3,r5, LPCR_VC_SH, 0
- mtspr SPRN_LPCR,r3
- isync
- blr
-
-__init_FSCR_power10:
- mfspr r3, SPRN_FSCR
- ori r3, r3, FSCR_PREFIX
- mtspr SPRN_FSCR, r3
- // fall through
-
-__init_FSCR_power9:
- mfspr r3, SPRN_FSCR
- ori r3, r3, FSCR_SCV
- mtspr SPRN_FSCR, r3
- // fall through
-
-__init_FSCR:
- mfspr r3,SPRN_FSCR
- ori r3,r3,FSCR_TAR|FSCR_EBB
- mtspr SPRN_FSCR,r3
- blr
-
-__init_HFSCR:
- mfspr r3,SPRN_HFSCR
- ori r3,r3,HFSCR_TAR|HFSCR_TM|HFSCR_BHRB|HFSCR_PM|\
- HFSCR_DSCR|HFSCR_VECVSX|HFSCR_FP|HFSCR_EBB|HFSCR_MSGP
- mtspr SPRN_HFSCR,r3
- blr
-
-__init_PMU_HV:
- li r5,0
- mtspr SPRN_MMCRC,r5
- blr
-
-__init_PMU_HV_ISA207:
- li r5,0
- mtspr SPRN_MMCRH,r5
- blr
-
-__init_PMU:
- li r5,0
- mtspr SPRN_MMCRA,r5
- mtspr SPRN_MMCR0,r5
- mtspr SPRN_MMCR1,r5
- mtspr SPRN_MMCR2,r5
- blr
-
-__init_PMU_ISA207:
- li r5,0
- mtspr SPRN_MMCRS,r5
- blr
-
-__init_PMU_ISA31:
- li r5,0
- mtspr SPRN_MMCR3,r5
- LOAD_REG_IMMEDIATE(r5, MMCRA_BHRB_DISABLE)
- mtspr SPRN_MMCRA,r5
- blr
diff --git a/arch/powerpc/kernel/cpu_setup_power.c b/arch/powerpc/kernel/cpu_setup_power.c
new file mode 100644
index 000000000000..cf5201b0579d
--- /dev/null
+++ b/arch/powerpc/kernel/cpu_setup_power.c
@@ -0,0 +1,269 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) 2020 IBM Corporation
+ * This file contains low level CPU setup functions.
+ * Originally written in assembly by
+ * Benjamin Herrenschmidt (benh@kernel.crashing.org)
+ */
+#include <asm/reg.h>
+#include <asm/synch.h>
+#include <linux/bitops.h>
+#include <asm/cputable.h>
+#include <asm/cpu_setup_power.h>
+
+/* Disable CPU_FTR_HVMODE and return false if MSR:HV is not set */
+static bool init_hvmode_206(struct cpu_spec *t)
+{
+ u64 msr;
+
+ msr = mfmsr();
+ if (msr & MSR_HV)
+ return true;
+
+ t->cpu_features &= ~(CPU_FTR_HVMODE | CPU_FTR_P9_TM_HV_ASSIST);
+ return false;
+}
+
+static void init_LPCR_ISA300(u64 lpcr, u64 lpes)
+{
+ /* POWER9 has no VRMASD */
+ lpcr |= (lpes << LPCR_LPES_SH) & LPCR_LPES;
+ lpcr |= LPCR_PECE0|LPCR_PECE1|LPCR_PECE2;
+ lpcr |= (4ull << LPCR_DPFD_SH) & LPCR_DPFD;
+ lpcr &= ~LPCR_HDICE; /* clear HDICE */
+ lpcr |= (4ull << LPCR_VC_SH);
+ mtspr(SPRN_LPCR, lpcr);
+ isync();
+}
+
+/*
+ * Setup a sane LPCR:
+ * Called with initial LPCR and desired LPES 2-bit value
+ *
+ * LPES = 0b01 (HSRR0/1 used for 0x500)
+ * PECE = 0b111
+ * DPFD = 4
+ * HDICE = 0
+ * VC = 0b100 (VPM0=1, VPM1=0, ISL=0)
+ * VRMASD = 0b10000 (L=1, LP=00)
+ *
+ * Other bits untouched for now
+ */
+static void init_LPCR_ISA206(u64 lpcr, u64 lpes)
+{
+ lpcr |= (0x10ull << LPCR_VRMASD_SH) & LPCR_VRMASD;
+ init_LPCR_ISA300(lpcr, lpes);
+}
+
+static void init_FSCR(void)
+{
+ u64 fscr;
+
+ fscr = mfspr(SPRN_FSCR);
+ fscr |= FSCR_TAR|FSCR_EBB;
+ mtspr(SPRN_FSCR, fscr);
+}
+
+static void init_FSCR_power9(void)
+{
+ u64 fscr;
+
+ fscr = mfspr(SPRN_FSCR);
+ fscr |= FSCR_SCV;
+ mtspr(SPRN_FSCR, fscr);
+ init_FSCR();
+}
+
+static void init_FSCR_power10(void)
+{
+ u64 fscr;
+
+ fscr = mfspr(SPRN_FSCR);
+ fscr |= FSCR_PREFIX;
+ mtspr(SPRN_FSCR, fscr);
+ init_FSCR_power9();
+}
+
+static void init_HFSCR(void)
+{
+ u64 hfscr;
+
+ hfscr = mfspr(SPRN_HFSCR);
+ hfscr |= HFSCR_TAR|HFSCR_TM|HFSCR_BHRB|HFSCR_PM|HFSCR_DSCR|\
+ HFSCR_VECVSX|HFSCR_FP|HFSCR_EBB|HFSCR_MSGP;
+ mtspr(SPRN_HFSCR, hfscr);
+}
+
+static void init_PMU_HV(void)
+{
+ mtspr(SPRN_MMCRC, 0);
+}
+
+static void init_PMU_HV_ISA207(void)
+{
+ mtspr(SPRN_MMCRH, 0);
+}
+
+static void init_PMU(void)
+{
+ mtspr(SPRN_MMCRA, 0);
+ mtspr(SPRN_MMCR0, 0);
+ mtspr(SPRN_MMCR1, 0);
+ mtspr(SPRN_MMCR2, 0);
+}
+
+static void init_PMU_ISA207(void)
+{
+ mtspr(SPRN_MMCRS, 0);
+}
+
+static void init_PMU_ISA31(void)
+{
+ mtspr(SPRN_MMCR3, 0);
+ mtspr(SPRN_MMCRA, MMCRA_BHRB_DISABLE);
+}
+
+/*
+ * Note that we can be called twice of pseudo-PVRs.
+ * The parameter offset is not used.
+ */
+
+void __setup_cpu_power7(unsigned long offset, struct cpu_spec *t)
+{
+ if (!init_hvmode_206(t))
+ return;
+
+ mtspr(SPRN_LPID, 0);
+ mtspr(SPRN_PCR, PCR_MASK);
+ init_LPCR_ISA206(mfspr(SPRN_LPCR), LPCR_LPES1 >> LPCR_LPES_SH);
+}
+
+void __restore_cpu_power7(void)
+{
+ u64 msr;
+
+ msr = mfmsr();
+ if (!(msr & MSR_HV))
+ return;
+
+ mtspr(SPRN_LPID, 0);
+ mtspr(SPRN_PCR, PCR_MASK);
+ init_LPCR_ISA206(mfspr(SPRN_LPCR), LPCR_LPES1 >> LPCR_LPES_SH);
+}
+
+void __setup_cpu_power8(unsigned long offset, struct cpu_spec *t)
+{
+ init_FSCR();
+ init_PMU();
+ init_PMU_ISA207();
+
+ if (!init_hvmode_206(t))
+ return;
+
+ mtspr(SPRN_LPID, 0);
+ mtspr(SPRN_PCR, PCR_MASK);
+ init_LPCR_ISA206(mfspr(SPRN_LPCR) | LPCR_PECEDH, 0); /* LPES = 0 */
+ init_HFSCR();
+ init_PMU_HV();
+ init_PMU_HV_ISA207();
+}
+
+void __restore_cpu_power8(void)
+{
+ u64 msr;
+
+ init_FSCR();
+ init_PMU();
+ init_PMU_ISA207();
+
+ msr = mfmsr();
+ if (!(msr & MSR_HV))
+ return;
+
+ mtspr(SPRN_LPID, 0);
+ mtspr(SPRN_PCR, PCR_MASK);
+ init_LPCR_ISA206(mfspr(SPRN_LPCR) | LPCR_PECEDH, 0); /* LPES = 0 */
+ init_HFSCR();
+ init_PMU_HV();
+ init_PMU_HV_ISA207();
+}
+
+void __setup_cpu_power9(unsigned long offset, struct cpu_spec *t)
+{
+ init_FSCR_power9();
+ init_PMU();
+
+ if (!init_hvmode_206(t))
+ return;
+
+ mtspr(SPRN_PSSCR, 0);
+ mtspr(SPRN_LPID, 0);
+ mtspr(SPRN_PID, 0);
+ mtspr(SPRN_PCR, PCR_MASK);
+ init_LPCR_ISA300((mfspr(SPRN_LPCR) | LPCR_PECEDH | LPCR_PECE_HVEE |\
+ LPCR_HVICE | LPCR_HEIC) & ~(LPCR_UPRT | LPCR_HR), 0);
+ init_HFSCR();
+ init_PMU_HV();
+}
+
+void __restore_cpu_power9(void)
+{
+ u64 msr;
+
+ init_FSCR_power9();
+ init_PMU();
+
+ msr = mfmsr();
+ if (!(msr & MSR_HV))
+ return;
+
+ mtspr(SPRN_PSSCR, 0);
+ mtspr(SPRN_LPID, 0);
+ mtspr(SPRN_PID, 0);
+ mtspr(SPRN_PCR, PCR_MASK);
+ init_LPCR_ISA300((mfspr(SPRN_LPCR) | LPCR_PECEDH | LPCR_PECE_HVEE |\
+ LPCR_HVICE | LPCR_HEIC) & ~(LPCR_UPRT | LPCR_HR), 0);
+ init_HFSCR();
+ init_PMU_HV();
+}
+
+void __setup_cpu_power10(unsigned long offset, struct cpu_spec *t)
+{
+ init_FSCR_power10();
+ init_PMU();
+ init_PMU_ISA31();
+
+ if (!init_hvmode_206(t))
+ return;
+
+ mtspr(SPRN_PSSCR, 0);
+ mtspr(SPRN_LPID, 0);
+ mtspr(SPRN_PID, 0);
+ mtspr(SPRN_PCR, PCR_MASK);
+ init_LPCR_ISA300((mfspr(SPRN_LPCR) | LPCR_PECEDH | LPCR_PECE_HVEE |\
+ LPCR_HVICE | LPCR_HEIC) & ~(LPCR_UPRT | LPCR_HR), 0);
+ init_HFSCR();
+ init_PMU_HV();
+}
+
+void __restore_cpu_power10(void)
+{
+ u64 msr;
+
+ init_FSCR_power10();
+ init_PMU();
+ init_PMU_ISA31();
+
+ msr = mfmsr();
+ if (!(msr & MSR_HV))
+ return;
+
+ mtspr(SPRN_PSSCR, 0);
+ mtspr(SPRN_LPID, 0);
+ mtspr(SPRN_PID, 0);
+ mtspr(SPRN_PCR, PCR_MASK);
+ init_LPCR_ISA300((mfspr(SPRN_LPCR) | LPCR_PECEDH | LPCR_PECE_HVEE |\
+ LPCR_HVICE | LPCR_HEIC) & ~(LPCR_UPRT | LPCR_HR), 0);
+ init_HFSCR();
+ init_PMU_HV();
+}
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index 2aa89c6b2896..26a56c9d6650 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -59,19 +59,15 @@ extern void __setup_cpu_7410(unsigned long offset, struct cpu_spec* spec);
extern void __setup_cpu_745x(unsigned long offset, struct cpu_spec* spec);
#endif /* CONFIG_PPC32 */
#ifdef CONFIG_PPC64
+#include <asm/cpu_setup_power.h>
extern void __setup_cpu_ppc970(unsigned long offset, struct cpu_spec* spec);
extern void __setup_cpu_ppc970MP(unsigned long offset, struct cpu_spec* spec);
extern void __setup_cpu_pa6t(unsigned long offset, struct cpu_spec* spec);
extern void __restore_cpu_pa6t(void);
extern void __restore_cpu_ppc970(void);
-extern void __setup_cpu_power7(unsigned long offset, struct cpu_spec* spec);
-extern void __restore_cpu_power7(void);
-extern void __setup_cpu_power8(unsigned long offset, struct cpu_spec* spec);
-extern void __restore_cpu_power8(void);
-extern void __setup_cpu_power9(unsigned long offset, struct cpu_spec* spec);
-extern void __restore_cpu_power9(void);
-extern void __setup_cpu_power10(unsigned long offset, struct cpu_spec* spec);
-extern void __restore_cpu_power10(void);
+extern long __machine_check_early_realmode_p7(struct pt_regs *regs);
+extern long __machine_check_early_realmode_p8(struct pt_regs *regs);
+extern long __machine_check_early_realmode_p9(struct pt_regs *regs);
#endif /* CONFIG_PPC64 */
#if defined(CONFIG_E500)
extern void __setup_cpu_e5500(unsigned long offset, struct cpu_spec* spec);
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v5 1/5] powerpc/sstep: Emulate prefixed instructions only when CPU_FTR_ARCH_31 is set
From: Ravi Bangoria @ 2020-10-14 7:34 UTC (permalink / raw)
To: Daniel Axtens
Cc: Ravi Bangoria, bala24, paulus, sandipan, jniethe5, naveen.n.rao,
linuxppc-dev
In-Reply-To: <877drvwocx.fsf@dja-thinkpad.axtens.net>
Hi Daniel,
On 10/12/20 7:14 PM, Daniel Axtens wrote:
> Hi,
>
> To review this, I looked through the supported instructions to see if
> there were any that I thought might have been missed.
>
> I didn't find any other v3.1 ones, although I don't have a v3.1 ISA to
> hand so I was basically looking for instructions I didn't recognise.
>
> I did, however, find a number of instructions that are new in ISA 3.0
> that aren't guarded:
>
> - addpcis
> - lxvl/stxvl
> - lxvll/stxvll
> - lxvwsx
> - stxvx
> - lxsipzx
> - lxvh8x
> - lxsihzx
> - lxvb16x/stxvb16x
> - stxsibx
> - stxsihx
> - lxvb16x
> - lxsd/stxsd
> - lxssp/stxssp
> - lxv/stxv
>
> Also, I don't know how bothered we are about P7, but if I'm reading the
> ISA correctly, lqarx/stqcx. are not supported before ISA 2.07. Likewise
> a number of the vector instructions like lxsiwzx and lxsiwax (and the
> companion stores).
>
> I realise it's not really the point of this particular patch, so I don't
> think this should block acceptance. What I would like to know - and
> maybe this is something where we need mpe to weigh in - is whether we
> need consistent guards for 2.07 and 3.0. We have some 3.0 guards already
> but clearly not everywhere.
Yes, those needs to be handled properly. Otherwise they can be harmful
when emulated on a non-supporting platform. Will work on it when I get
some time. Thanks for reporting it.
>
> With all that said - the patch does what it says it does, and looks good
> to me:
>
> Reviewed-by: Daniel Axtens <dja@axtens.net>
Thanks!
Ravi
^ permalink raw reply
* [PATCH] soc: fsl: dpio: Change 'cpumask_t mask' to global variable
From: Yi Wang @ 2020-10-14 7:27 UTC (permalink / raw)
To: Roy.Pledge
Cc: wang.yi59, jiang.xuexin, Hao Si, linux-kernel, leoyang.li,
xue.zhihong, Lin Chen, linuxppc-dev, linux-arm-kernel
[-- Attachment #1.1: Type: text/plain, Size: 3434 bytes --]
From: Hao Si <si.hao@zte.com.cn>
The local variable 'cpumask_t mask' is in the stack memory, and its address
is assigned to 'desc->affinity' in 'irq_set_affinity_hint()'.
But the memory area where this variable is located is at risk of being
modified.
During LTP testing, the following error was generated:
Unable to handle kernel paging request at virtual address ffff000012e9b790
Mem abort info:
ESR = 0x96000007
Exception class = DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
Data abort info:
ISV = 0, ISS = 0x00000007
CM = 0, WnR = 0
swapper pgtable: 4k pages, 48-bit VAs, pgdp = 0000000075ac5e07
[ffff000012e9b790] pgd=00000027dbffe003, pud=00000027dbffd003,
pmd=00000027b6d61003, pte=0000000000000000
Internal error: Oops: 96000007 [#1] PREEMPT SMP
Modules linked in: xt_conntrack
Process read_all (pid: 20171, stack limit = 0x0000000044ea4095)
CPU: 14 PID: 20171 Comm: read_all Tainted: G B W
Hardware name: NXP Layerscape LX2160ARDB (DT)
pstate: 80000085 (Nzcv daIf -PAN -UAO)
pc : irq_affinity_hint_proc_show+0x54/0xb0
lr : irq_affinity_hint_proc_show+0x4c/0xb0
sp : ffff00001138bc10
x29: ffff00001138bc10 x28: 0000ffffd131d1e0
x27: 00000000007000c0 x26: ffff8025b9480dc0
x25: ffff8025b9480da8 x24: 00000000000003ff
x23: ffff8027334f8300 x22: ffff80272e97d000
x21: ffff80272e97d0b0 x20: ffff8025b9480d80
x19: ffff000009a49000 x18: 0000000000000000
x17: 0000000000000000 x16: 0000000000000000
x15: 0000000000000000 x14: 0000000000000000
x13: 0000000000000000 x12: 0000000000000040
x11: 0000000000000000 x10: ffff802735b79b88
x9 : 0000000000000000 x8 : 0000000000000000
x7 : ffff000009a49848 x6 : 0000000000000003
x5 : 0000000000000000 x4 : ffff000008157d6c
x3 : ffff00001138bc10 x2 : ffff000012e9b790
x1 : 0000000000000000 x0 : 0000000000000000
Call trace:
irq_affinity_hint_proc_show+0x54/0xb0
seq_read+0x1b0/0x440
proc_reg_read+0x80/0xd8
__vfs_read+0x60/0x178
vfs_read+0x94/0x150
ksys_read+0x74/0xf0
__arm64_sys_read+0x24/0x30
el0_svc_common.constprop.0+0xd8/0x1a0
el0_svc_handler+0x34/0x88
el0_svc+0x10/0x14
Code: f9001bbf 943e0732 f94066c2 b4000062 (f9400041)
---[ end trace b495bdcb0b3b732b ]---
Kernel panic - not syncing: Fatal exception
SMP: stopping secondary CPUs
SMP: failed to stop secondary CPUs 0,2-4,6,8,11,13-15
Kernel Offset: disabled
CPU features: 0x0,21006008
Memory Limit: none
---[ end Kernel panic - not syncing: Fatal exception ]---
Fix it by changing 'cpumask_t mask' to global variable.
Signed-off-by: Hao Si <si.hao@zte.com.cn>
Signed-off-by: Lin Chen <chen.lin5@zte.com.cn>
Signed-off-by: Yi Wang <wang.yi59@zte.com.cn>
---
drivers/soc/fsl/dpio/dpio-driver.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/soc/fsl/dpio/dpio-driver.c b/drivers/soc/fsl/dpio/dpio-driver.c
index 7b642c3..b31ec53 100644
--- a/drivers/soc/fsl/dpio/dpio-driver.c
+++ b/drivers/soc/fsl/dpio/dpio-driver.c
@@ -31,6 +31,7 @@ struct dpio_priv {
struct dpaa2_io *io;
};
+static cpumask_t mask;
static cpumask_var_t cpus_unused_mask;
static const struct soc_device_attribute ls1088a_soc[] = {
@@ -95,7 +96,6 @@ static int register_dpio_irq_handlers(struct fsl_mc_device *dpio_dev, int cpu)
{
int error;
struct fsl_mc_device_irq *irq;
- cpumask_t mask;
irq = dpio_dev->irqs[0];
error = devm_request_irq(&dpio_dev->dev,
--
2.15.2
^ permalink raw reply related
* [PATCH] powerpc/perf: Add support for programming of Thresholding in P10
From: Kajol Jain @ 2020-10-14 8:44 UTC (permalink / raw)
To: mpe; +Cc: kjain, atrajeev, maddy, linuxppc-dev
Thresholding, a performance monitoring unit feature, can be
used to identify marked instructions which take more than
expected cycles between start event and end event.
Threshold compare (thresh_cmp) bits are programmed in MMCRA
register. In Power9, thresh_cmp bits were part of the
event code. But in case of P10, thresh_cmp are not part of
event code due to inclusion of MMCR3 bits.
Patch here adds an option to use attr.config1 variable
to be used to pass thresh_cmp value to be programmed in
MMCRA register. A new ppmu flag called PPMU_HAS_ATTR_CONFIG1
has been added and this flag is used to notify the use of
attr.config1 variable. Secondly, thresh_cmp bits are not
part of the group constraints.
Patch has extended the parameter list of 'compute_mmcr',
to include power_pmu's 'flags' element.
command#: cat /sys/devices/cpu/format/thresh_cmp
config1:0-17
ex. usage:
command#: perf record -I --weight -d -e
cpu/event=0x67340101EC,thresh_cmp=500/ ./ebizzy -S 2 -t 1 -s 4096
1826636 records/s
real 2.00 s
user 2.00 s
sys 0.00 s
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.038 MB perf.data (61 samples) ]
Signed-off-by: Kajol Jain<kjain@linux.ibm.com>
---
arch/powerpc/include/asm/perf_event_server.h | 4 +-
arch/powerpc/perf/core-book3s.c | 2 +-
arch/powerpc/perf/isa207-common.c | 54 ++++++++++++++++++--
arch/powerpc/perf/isa207-common.h | 6 ++-
arch/powerpc/perf/mpc7450-pmu.c | 3 +-
arch/powerpc/perf/power10-pmu.c | 4 +-
arch/powerpc/perf/power5+-pmu.c | 3 +-
arch/powerpc/perf/power5-pmu.c | 3 +-
arch/powerpc/perf/power6-pmu.c | 3 +-
arch/powerpc/perf/power7-pmu.c | 3 +-
arch/powerpc/perf/ppc970-pmu.c | 3 +-
11 files changed, 73 insertions(+), 15 deletions(-)
diff --git a/arch/powerpc/include/asm/perf_event_server.h b/arch/powerpc/include/asm/perf_event_server.h
index f6acabb6c9be..566e41d4ff6a 100644
--- a/arch/powerpc/include/asm/perf_event_server.h
+++ b/arch/powerpc/include/asm/perf_event_server.h
@@ -34,9 +34,10 @@ struct power_pmu {
int max_alternatives;
unsigned long add_fields;
unsigned long test_adder;
+ /* TODO: parameter list is growing and should consider folding all this to a struct */
int (*compute_mmcr)(u64 events[], int n_ev,
unsigned int hwc[], struct mmcr_regs *mmcr,
- struct perf_event *pevents[]);
+ struct perf_event *pevents[], u32 flags);
int (*get_constraint)(u64 event_id, unsigned long *mskp,
unsigned long *valp);
int (*get_alternatives)(u64 event_id, unsigned int flags,
@@ -82,6 +83,7 @@ struct power_pmu {
#define PPMU_ARCH_207S 0x00000080 /* PMC is architecture v2.07S */
#define PPMU_NO_SIAR 0x00000100 /* Do not use SIAR */
#define PPMU_ARCH_31 0x00000200 /* Has MMCR3, SIER2 and SIER3 */
+#define PPMU_HAS_ATTR_CONFIG1 0x00000400 /* Using config1 attribute */
/*
* Values for flags to get_alternatives()
diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index 08643cba1494..e4c817f64566 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -1356,7 +1356,7 @@ static void power_pmu_enable(struct pmu *pmu)
memset(&cpuhw->mmcr, 0, sizeof(cpuhw->mmcr));
if (ppmu->compute_mmcr(cpuhw->events, cpuhw->n_events, hwc_index,
- &cpuhw->mmcr, cpuhw->event)) {
+ &cpuhw->mmcr, cpuhw->event, ppmu->flags)) {
/* shouldn't ever get here */
printk(KERN_ERR "oops compute_mmcr failed\n");
goto out;
diff --git a/arch/powerpc/perf/isa207-common.c b/arch/powerpc/perf/isa207-common.c
index 964437adec18..cfad88b7ca85 100644
--- a/arch/powerpc/perf/isa207-common.c
+++ b/arch/powerpc/perf/isa207-common.c
@@ -110,10 +110,48 @@ static void mmcra_sdar_mode(u64 event, unsigned long *mmcra)
static u64 thresh_cmp_val(u64 value)
{
- if (cpu_has_feature(CPU_FTR_ARCH_300))
- return value << p9_MMCRA_THR_CMP_SHIFT;
+ int exp = 0;
+ u64 result = value;
+
+ if (!value)
+ return value;
+
+ /*
+ * Incase of P10, thresh_cmp value is not part of raw event code
+ * and provided via attr.config1 parameter. To program threshold in MMCRA,
+ * take a 18 bit number N and shift right 2 places and increment
+ * the exponent E by 1 until the upper 10 bits of N are zero.
+ * Write E to the threshold exponent and write the lower 8 bits of N
+ * to the threshold mantissa.
+ * The max threshold that can be written is 261120.
+ */
+ if (cpu_has_feature(CPU_FTR_ARCH_31)) {
+ if (value > 261120)
+ value = 261120;
+ while ((64 - __builtin_clzl(value)) > 8) {
+ exp++;
+ value >>= 2;
+ }
+
+ /*
+ * Note that it is invalid to write a mantissa with the
+ * upper 2 bits of mantissa being zero, unless the
+ * exponent is also zero.
+ */
+ if (!(value & 0xC0) && exp)
+ result = 0;
+ else
+ result = (exp << 8) | value;
+ }
- return value << MMCRA_THR_CMP_SHIFT;
+ /*
+ * Since location of threshold compare bits in MMCRA
+ * is different for p8, using different shift value.
+ */
+ if (cpu_has_feature(CPU_FTR_ARCH_300))
+ return result << p9_MMCRA_THR_CMP_SHIFT;
+ else
+ return result << MMCRA_THR_CMP_SHIFT;
}
static unsigned long combine_from_event(u64 event)
@@ -144,7 +182,9 @@ static bool is_thresh_cmp_valid(u64 event)
/*
* Check the mantissa upper two bits are not zero, unless the
* exponent is also zero. See the THRESH_CMP_MANTISSA doc.
- * Power10: thresh_cmp is replaced by l2_l3 event select.
+ * Power10: thresh_cmp bits are not part of raw event code.
+ * attr.config1 is used to get thresh_cmp value from user.
+ * And hence thresh_cmp is not part of group constraint.
*/
if (cpu_has_feature(CPU_FTR_ARCH_31))
return false;
@@ -386,7 +426,7 @@ int isa207_get_constraint(u64 event, unsigned long *maskp, unsigned long *valp)
int isa207_compute_mmcr(u64 event[], int n_ev,
unsigned int hwc[], struct mmcr_regs *mmcr,
- struct perf_event *pevents[])
+ struct perf_event *pevents[], u32 flags)
{
unsigned long mmcra, mmcr1, mmcr2, unit, combine, psel, cache, val;
unsigned long mmcr3;
@@ -472,6 +512,10 @@ int isa207_compute_mmcr(u64 event[], int n_ev,
val = (event[i] >> EVENT_THR_CMP_SHIFT) &
EVENT_THR_CMP_MASK;
mmcra |= thresh_cmp_val(val);
+ } else if (flags & PPMU_HAS_ATTR_CONFIG1) {
+ val = (pevents[i]->attr.config1 >> p10_EVENT_THR_CMP_SHIFT) &
+ p10_EVENT_THR_CMP_MASK;
+ mmcra |= thresh_cmp_val(val);
}
}
diff --git a/arch/powerpc/perf/isa207-common.h b/arch/powerpc/perf/isa207-common.h
index 044de65e96b9..8d365dccce50 100644
--- a/arch/powerpc/perf/isa207-common.h
+++ b/arch/powerpc/perf/isa207-common.h
@@ -100,6 +100,10 @@
#define p10_EVENT_MMCR3_MASK 0x7fffull
#define p10_EVENT_MMCR3_SHIFT 45
+/* Event Threshold Compare bit constant for power10 in config1 attribute */
+#define p10_EVENT_THR_CMP_SHIFT 0
+#define p10_EVENT_THR_CMP_MASK 0x3FFFFull
+
#define p10_EVENT_VALID_MASK \
((p10_SDAR_MODE_MASK << p10_SDAR_MODE_SHIFT | \
(p10_EVENT_THRESH_MASK << EVENT_THRESH_SHIFT) | \
@@ -249,7 +253,7 @@
int isa207_get_constraint(u64 event, unsigned long *maskp, unsigned long *valp);
int isa207_compute_mmcr(u64 event[], int n_ev,
unsigned int hwc[], struct mmcr_regs *mmcr,
- struct perf_event *pevents[]);
+ struct perf_event *pevents[], u32 flags);
void isa207_disable_pmc(unsigned int pmc, struct mmcr_regs *mmcr);
int isa207_get_alternatives(u64 event, u64 alt[], int size, unsigned int flags,
const unsigned int ev_alt[][MAX_ALT]);
diff --git a/arch/powerpc/perf/mpc7450-pmu.c b/arch/powerpc/perf/mpc7450-pmu.c
index 1919e9df9165..50612b1fafb9 100644
--- a/arch/powerpc/perf/mpc7450-pmu.c
+++ b/arch/powerpc/perf/mpc7450-pmu.c
@@ -258,7 +258,8 @@ static const u32 pmcsel_mask[N_COUNTER] = {
*/
static int mpc7450_compute_mmcr(u64 event[], int n_ev, unsigned int hwc[],
struct mmcr_regs *mmcr,
- struct perf_event *pevents[])
+ struct perf_event *pevents[],
+ u32 flags __maybe_unused)
{
u8 event_index[N_CLASSES][N_COUNTER];
int n_classevent[N_CLASSES];
diff --git a/arch/powerpc/perf/power10-pmu.c b/arch/powerpc/perf/power10-pmu.c
index 83148656b524..a838da409570 100644
--- a/arch/powerpc/perf/power10-pmu.c
+++ b/arch/powerpc/perf/power10-pmu.c
@@ -176,6 +176,7 @@ PMU_FORMAT_ATTR(src_sel, "config:45-46");
PMU_FORMAT_ATTR(invert_bit, "config:47");
PMU_FORMAT_ATTR(src_mask, "config:48-53");
PMU_FORMAT_ATTR(src_match, "config:54-59");
+PMU_FORMAT_ATTR(thresh_cmp, "config1:0-17");
static struct attribute *power10_pmu_format_attr[] = {
&format_attr_event.attr,
@@ -195,6 +196,7 @@ static struct attribute *power10_pmu_format_attr[] = {
&format_attr_invert_bit.attr,
&format_attr_src_mask.attr,
&format_attr_src_match.attr,
+ &format_attr_thresh_cmp.attr,
NULL,
};
@@ -393,7 +395,7 @@ static struct power_pmu power10_pmu = {
.get_mem_weight = isa207_get_mem_weight,
.disable_pmc = isa207_disable_pmc,
.flags = PPMU_HAS_SIER | PPMU_ARCH_207S |
- PPMU_ARCH_31,
+ PPMU_ARCH_31 | PPMU_HAS_ATTR_CONFIG1,
.n_generic = ARRAY_SIZE(power10_generic_events),
.generic_events = power10_generic_events,
.cache_events = &power10_cache_events,
diff --git a/arch/powerpc/perf/power5+-pmu.c b/arch/powerpc/perf/power5+-pmu.c
index a62b2cd7914f..6eeeb4df523d 100644
--- a/arch/powerpc/perf/power5+-pmu.c
+++ b/arch/powerpc/perf/power5+-pmu.c
@@ -449,7 +449,8 @@ static int power5p_marked_instr_event(u64 event)
static int power5p_compute_mmcr(u64 event[], int n_ev,
unsigned int hwc[], struct mmcr_regs *mmcr,
- struct perf_event *pevents[])
+ struct perf_event *pevents[],
+ u32 flags __maybe_unused)
{
unsigned long mmcr1 = 0;
unsigned long mmcra = 0;
diff --git a/arch/powerpc/perf/power5-pmu.c b/arch/powerpc/perf/power5-pmu.c
index 8732b587cf71..190973b2d394 100644
--- a/arch/powerpc/perf/power5-pmu.c
+++ b/arch/powerpc/perf/power5-pmu.c
@@ -380,7 +380,8 @@ static int power5_marked_instr_event(u64 event)
static int power5_compute_mmcr(u64 event[], int n_ev,
unsigned int hwc[], struct mmcr_regs *mmcr,
- struct perf_event *pevents[])
+ struct perf_event *pevents[],
+ u32 flags __maybe_unused)
{
unsigned long mmcr1 = 0;
unsigned long mmcra = MMCRA_SDAR_DCACHE_MISS | MMCRA_SDAR_ERAT_MISS;
diff --git a/arch/powerpc/perf/power6-pmu.c b/arch/powerpc/perf/power6-pmu.c
index 0e318cf87129..579606315b4d 100644
--- a/arch/powerpc/perf/power6-pmu.c
+++ b/arch/powerpc/perf/power6-pmu.c
@@ -171,7 +171,8 @@ static int power6_marked_instr_event(u64 event)
* Assign PMC numbers and compute MMCR1 value for a set of events
*/
static int p6_compute_mmcr(u64 event[], int n_ev,
- unsigned int hwc[], struct mmcr_regs *mmcr, struct perf_event *pevents[])
+ unsigned int hwc[], struct mmcr_regs *mmcr, struct perf_event *pevents[],
+ u32 flags __maybe_unused)
{
unsigned long mmcr1 = 0;
unsigned long mmcra = MMCRA_SDAR_DCACHE_MISS | MMCRA_SDAR_ERAT_MISS;
diff --git a/arch/powerpc/perf/power7-pmu.c b/arch/powerpc/perf/power7-pmu.c
index 5e0bf09cf077..a929917f7259 100644
--- a/arch/powerpc/perf/power7-pmu.c
+++ b/arch/powerpc/perf/power7-pmu.c
@@ -243,7 +243,8 @@ static int power7_marked_instr_event(u64 event)
static int power7_compute_mmcr(u64 event[], int n_ev,
unsigned int hwc[], struct mmcr_regs *mmcr,
- struct perf_event *pevents[])
+ struct perf_event *pevents[],
+ u32 flags __maybe_unused)
{
unsigned long mmcr1 = 0;
unsigned long mmcra = MMCRA_SDAR_DCACHE_MISS | MMCRA_SDAR_ERAT_MISS;
diff --git a/arch/powerpc/perf/ppc970-pmu.c b/arch/powerpc/perf/ppc970-pmu.c
index d35223fb112c..4a0b1eeab643 100644
--- a/arch/powerpc/perf/ppc970-pmu.c
+++ b/arch/powerpc/perf/ppc970-pmu.c
@@ -254,7 +254,8 @@ static int p970_get_alternatives(u64 event, unsigned int flags, u64 alt[])
static int p970_compute_mmcr(u64 event[], int n_ev,
unsigned int hwc[], struct mmcr_regs *mmcr,
- struct perf_event *pevents[])
+ struct perf_event *pevents[],
+ u32 flags __maybe_unused)
{
unsigned long mmcr0 = 0, mmcr1 = 0, mmcra = 0;
unsigned int pmc, unit, byte, psel;
--
2.26.2
^ permalink raw reply related
* Re: [PATCH] soc: fsl: dpio: Change 'cpumask_t mask' to global variable
From: Laurentiu Tudor @ 2020-10-14 9:29 UTC (permalink / raw)
To: Yi Wang, Roy.Pledge, Youri Querry
Cc: jiang.xuexin, Hao Si, linux-kernel, Lin Chen, xue.zhihong,
Ioana Ciornei, leoyang.li, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20201014072733.15175-1-wang.yi59@zte.com.cn>
Hi,
Thanks for finding this. Comment inline.
On 10/14/2020 10:27 AM, Yi Wang wrote:
> From: Hao Si <si.hao@zte.com.cn>
>
> The local variable 'cpumask_t mask' is in the stack memory, and its address
> is assigned to 'desc->affinity' in 'irq_set_affinity_hint()'.
> But the memory area where this variable is located is at risk of being
> modified.
>
> During LTP testing, the following error was generated:
>
> Unable to handle kernel paging request at virtual address ffff000012e9b790
> Mem abort info:
> ESR = 0x96000007
> Exception class = DABT (current EL), IL = 32 bits
> SET = 0, FnV = 0
> EA = 0, S1PTW = 0
> Data abort info:
> ISV = 0, ISS = 0x00000007
> CM = 0, WnR = 0
> swapper pgtable: 4k pages, 48-bit VAs, pgdp = 0000000075ac5e07
> [ffff000012e9b790] pgd=00000027dbffe003, pud=00000027dbffd003,
> pmd=00000027b6d61003, pte=0000000000000000
> Internal error: Oops: 96000007 [#1] PREEMPT SMP
> Modules linked in: xt_conntrack
> Process read_all (pid: 20171, stack limit = 0x0000000044ea4095)
> CPU: 14 PID: 20171 Comm: read_all Tainted: G B W
> Hardware name: NXP Layerscape LX2160ARDB (DT)
> pstate: 80000085 (Nzcv daIf -PAN -UAO)
> pc : irq_affinity_hint_proc_show+0x54/0xb0
> lr : irq_affinity_hint_proc_show+0x4c/0xb0
> sp : ffff00001138bc10
> x29: ffff00001138bc10 x28: 0000ffffd131d1e0
> x27: 00000000007000c0 x26: ffff8025b9480dc0
> x25: ffff8025b9480da8 x24: 00000000000003ff
> x23: ffff8027334f8300 x22: ffff80272e97d000
> x21: ffff80272e97d0b0 x20: ffff8025b9480d80
> x19: ffff000009a49000 x18: 0000000000000000
> x17: 0000000000000000 x16: 0000000000000000
> x15: 0000000000000000 x14: 0000000000000000
> x13: 0000000000000000 x12: 0000000000000040
> x11: 0000000000000000 x10: ffff802735b79b88
> x9 : 0000000000000000 x8 : 0000000000000000
> x7 : ffff000009a49848 x6 : 0000000000000003
> x5 : 0000000000000000 x4 : ffff000008157d6c
> x3 : ffff00001138bc10 x2 : ffff000012e9b790
> x1 : 0000000000000000 x0 : 0000000000000000
> Call trace:
> irq_affinity_hint_proc_show+0x54/0xb0
> seq_read+0x1b0/0x440
> proc_reg_read+0x80/0xd8
> __vfs_read+0x60/0x178
> vfs_read+0x94/0x150
> ksys_read+0x74/0xf0
> __arm64_sys_read+0x24/0x30
> el0_svc_common.constprop.0+0xd8/0x1a0
> el0_svc_handler+0x34/0x88
> el0_svc+0x10/0x14
> Code: f9001bbf 943e0732 f94066c2 b4000062 (f9400041)
> ---[ end trace b495bdcb0b3b732b ]---
> Kernel panic - not syncing: Fatal exception
> SMP: stopping secondary CPUs
> SMP: failed to stop secondary CPUs 0,2-4,6,8,11,13-15
> Kernel Offset: disabled
> CPU features: 0x0,21006008
> Memory Limit: none
> ---[ end Kernel panic - not syncing: Fatal exception ]---
>
> Fix it by changing 'cpumask_t mask' to global variable.
>
> Signed-off-by: Hao Si <si.hao@zte.com.cn>
> Signed-off-by: Lin Chen <chen.lin5@zte.com.cn>
> Signed-off-by: Yi Wang <wang.yi59@zte.com.cn>
> ---
> drivers/soc/fsl/dpio/dpio-driver.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/soc/fsl/dpio/dpio-driver.c b/drivers/soc/fsl/dpio/dpio-driver.c
> index 7b642c3..b31ec53 100644
> --- a/drivers/soc/fsl/dpio/dpio-driver.c
> +++ b/drivers/soc/fsl/dpio/dpio-driver.c
> @@ -31,6 +31,7 @@ struct dpio_priv {
> struct dpaa2_io *io;
> };
>
> +static cpumask_t mask;
There can be multiple dpio devices with their associated driver
instances so it's not ok to make the variable global. Please place it in
the driver's private data and while at it, please rename it to cpu_mask.
---
Thanks & Best Regards, Laurentiu
^ permalink raw reply
* [PATCH v2] powerpc/perf: Fix Threshold Event Counter Multiplier width for P10
From: Madhavan Srinivasan @ 2020-10-14 10:16 UTC (permalink / raw)
To: mpe; +Cc: atrajeev, linuxppc-dev, Madhavan Srinivasan
Threshold Event Counter Multiplier (TECM) is part of Monitor Mode
Control Register A (MMCRA). This field along with Threshold Event
Counter Exponent (TECE) is used to get threshould counter value.
ISA v3.1 has 7bit mantissa field for TECM, but in Power10, the
width of TECM field is increase to 8bits. Patch fixes the current
code to modify the MMCRA[TECM] extraction macro to handle this changes.
Fixes: 170a315f41c64 ('powerpc/perf: Support to export MMCRA[TEC*] field to userspace')
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
---
Changelog v1:
- Fixed the commit message
- Fixed the condition check
arch/powerpc/include/asm/reg.h | 1 +
arch/powerpc/perf/isa207-common.c | 3 +++
arch/powerpc/perf/isa207-common.h | 4 ++++
3 files changed, 8 insertions(+)
diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
index 88fb88491fe9..a1bb0ebb3a46 100644
--- a/arch/powerpc/include/asm/reg.h
+++ b/arch/powerpc/include/asm/reg.h
@@ -1355,6 +1355,7 @@
#define PVR_POWER9 0x004E
#define PVR_BE 0x0070
#define PVR_PA6T 0x0090
+#define PVR_POWER10 0x0080
/* "Logical" PVR values defined in PAPR, representing architecture levels */
#define PVR_ARCH_204 0x0f000001
diff --git a/arch/powerpc/perf/isa207-common.c b/arch/powerpc/perf/isa207-common.c
index 964437adec18..480bbe525904 100644
--- a/arch/powerpc/perf/isa207-common.c
+++ b/arch/powerpc/perf/isa207-common.c
@@ -247,6 +247,9 @@ void isa207_get_mem_weight(u64 *weight)
u64 sier = mfspr(SPRN_SIER);
u64 val = (sier & ISA207_SIER_TYPE_MASK) >> ISA207_SIER_TYPE_SHIFT;
+ if (pvr_version_is(PVR_POWER10))
+ mantissa = P10_MMCRA_THR_CTR_MANT(mmcra);
+
if (val == 0 || val == 7)
*weight = 0;
else
diff --git a/arch/powerpc/perf/isa207-common.h b/arch/powerpc/perf/isa207-common.h
index 044de65e96b9..71380e854f48 100644
--- a/arch/powerpc/perf/isa207-common.h
+++ b/arch/powerpc/perf/isa207-common.h
@@ -219,6 +219,10 @@
#define MMCRA_THR_CTR_EXP(v) (((v) >> MMCRA_THR_CTR_EXP_SHIFT) &\
MMCRA_THR_CTR_EXP_MASK)
+#define P10_MMCRA_THR_CTR_MANT_MASK 0xFFul
+#define P10_MMCRA_THR_CTR_MANT(v) (((v) >> MMCRA_THR_CTR_MANT_SHIFT) &\
+ P10_MMCRA_THR_CTR_MANT_MASK)
+
/* MMCRA Threshold Compare bit constant for power9 */
#define p9_MMCRA_THR_CMP_SHIFT 45
--
2.26.2
^ permalink raw reply related
* Re: [PATCH 20/20] arch: dts: Fix DWC USB3 DT nodes name
From: Krzysztof Kozlowski @ 2020-10-14 10:33 UTC (permalink / raw)
To: Serge Semin
Cc: Andrew Lunn, linux-usb, Neil Armstrong, Tony Lindgren,
Bjorn Andersson, Pavel Parkhomenko,
linux-samsung-soc@vger.kernel.org, Kevin Hilman, Gregory Clement,
Wei Xu, Chen-Yu Tsai, Kukjin Kim, Andy Gross, linux-arm-msm,
linux-snps-arc, Sebastian Hesselbarth, devicetree, Jason Cooper,
Mathias Nyman, linux-kernel@vger.kernel.org, Lad Prabhakar,
Maxime Ripard, Alexey Malahov, Rob Herring, Santosh Shilimkar,
linux-omap, linux-arm-kernel, Roger Quadros, Felipe Balbi,
linux-mips, Greg Kroah-Hartman, Yoshihiro Shimoda, linuxppc-dev,
Patrice Chotard, Serge Semin, Li Yang, Manu Gautam,
Benoît Cousson, Shawn Guo
In-Reply-To: <20201014101402.18271-21-Sergey.Semin@baikalelectronics.ru>
On Wed, 14 Oct 2020 at 12:23, Serge Semin
<Sergey.Semin@baikalelectronics.ru> wrote:
>
> In accordance with the DWC USB3 bindings the corresponding node name is
> suppose to comply with Generic USB HCD DT schema, which requires the USB
> nodes to have the name acceptable by the regexp: "^usb(@.*)?" . But a lot
> of the DWC USB3-compatible nodes defined in the ARM/ARM64 DTS files have
> name as "^dwc3@.*" or "^usb[1-3]@.*" or even "^dwusb@.*", which will cause
> the dtbs_check procedure failure. Let's fix the nodes naming to be
> compatible with the DWC USB3 DT schema to make dtbs_check happy.
>
> Note we don't change the DWC USB3-compatible nodes names of
> arch/arm64/boot/dts/apm/{apm-storm.dtsi,apm-shadowcat.dtsi} since the
> in-source comment says that the nodes name need to be preserved as
> "^dwusb@.*" for some backward compatibility.
>
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
>
> ---
>
> Please, test the patch out to make sure it doesn't brake the dependent DTS
> files. I did only a manual grepping of the possible nodes dependencies.
1. It is you who should compare the decompiled DTS, not us. For example:
$ for i in dts-old/*/*dtb dts-old/*/*/*dtb; do echo $i; crosc64
scripts/dtc/dtx_diff ${i} dts-new/${i#dts-old/} ; done
$ for i in dts-old/*/*dtb dts-old/*/*/*dtb; do echo $i; crosc64
fdtdump ${i} > ${i}.fdt ; crosc64 fdtdump dts-new/${i#dts-old/} >
dts-new/${i#dts-old/}.fdt ; diff -ubB ${i}.fdt
dts-new/${i#dts-old/}.fdt ; done
2. Split it per arm architectures (and proper subject prefix - not
"arch") and subarchitectures so maintainers can pick it up.
3. The subject title could be more accurate - there is no fix here
because there was no errors in the first place. Requirement of DWC
node names comes recently, so it is more alignment with dtschema.
Otherwise automatic-pickup-stable-bot might want to pick up... and it
should not go to stable.
Best regards,
Krzysztof
> arch/arm/boot/dts/armada-375.dtsi | 2 +-
> arch/arm/boot/dts/exynos5250.dtsi | 2 +-
> arch/arm/boot/dts/exynos54xx.dtsi | 4 ++--
> arch/arm/boot/dts/keystone-k2e.dtsi | 4 ++--
> arch/arm/boot/dts/keystone.dtsi | 2 +-
> arch/arm/boot/dts/ls1021a.dtsi | 2 +-
> arch/arm/boot/dts/omap5-l4.dtsi | 2 +-
> arch/arm/boot/dts/stih407-family.dtsi | 2 +-
> arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 2 +-
> arch/arm64/boot/dts/exynos/exynos5433.dtsi | 4 ++--
> arch/arm64/boot/dts/exynos/exynos7.dtsi | 2 +-
> arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi | 4 ++--
> arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 6 +++---
> arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 4 ++--
> arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 4 ++--
> arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 2 +-
> arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi | 4 ++--
> arch/arm64/boot/dts/qcom/ipq8074.dtsi | 4 ++--
> arch/arm64/boot/dts/qcom/msm8996.dtsi | 4 ++--
> arch/arm64/boot/dts/qcom/msm8998.dtsi | 2 +-
> arch/arm64/boot/dts/qcom/qcs404-evb.dtsi | 2 +-
> arch/arm64/boot/dts/qcom/qcs404.dtsi | 4 ++--
> arch/arm64/boot/dts/qcom/sc7180.dtsi | 2 +-
> arch/arm64/boot/dts/qcom/sdm845.dtsi | 4 ++--
> arch/arm64/boot/dts/qcom/sm8150.dtsi | 2 +-
> 25 files changed, 38 insertions(+), 38 deletions(-)
>
^ permalink raw reply
* Re: [PATCH] powerpc/features: Remove CPU_FTR_NODSISRALIGN
From: Michael Ellerman @ 2020-10-14 11:00 UTC (permalink / raw)
To: Aneesh Kumar K.V, Christophe Leroy, Benjamin Herrenschmidt,
Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <7b1f7fdd-0256-3370-13ab-d808b9fe9b02@linux.ibm.com>
"Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> writes:
> On 10/13/20 3:45 PM, Michael Ellerman wrote:
>> Christophe Leroy <christophe.leroy@csgroup.eu> writes:
>>> Le 13/10/2020 à 09:23, Aneesh Kumar K.V a écrit :
>>>> Christophe Leroy <christophe.leroy@csgroup.eu> writes:
>>>>
>>>>> CPU_FTR_NODSISRALIGN has not been used since
>>>>> commit 31bfdb036f12 ("powerpc: Use instruction emulation
>>>>> infrastructure to handle alignment faults")
>>>>>
>>>>> Remove it.
>>>>>
>>>>> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
>>>>> ---
>>>>> arch/powerpc/include/asm/cputable.h | 22 ++++++++++------------
>>>>> arch/powerpc/kernel/dt_cpu_ftrs.c | 8 --------
>>>>> arch/powerpc/kernel/prom.c | 2 +-
>>>>> 3 files changed, 11 insertions(+), 21 deletions(-)
>>>>>
>>>>> diff --git a/arch/powerpc/kernel/dt_cpu_ftrs.c b/arch/powerpc/kernel/dt_cpu_ftrs.c
>>>>> index 1098863e17ee..c598961d9f15 100644
>>>>> --- a/arch/powerpc/kernel/dt_cpu_ftrs.c
>>>>> +++ b/arch/powerpc/kernel/dt_cpu_ftrs.c
>>>>> @@ -273,13 +273,6 @@ static int __init feat_enable_idle_nap(struct dt_cpu_feature *f)
>>>>> return 1;
>>>>> }
>>>>>
>>>>> -static int __init feat_enable_align_dsisr(struct dt_cpu_feature *f)
>>>>> -{
>>>>> - cur_cpu_spec->cpu_features &= ~CPU_FTR_NODSISRALIGN;
>>>>> -
>>>>> - return 1;
>>>>> -}
>>>>> -
>>>>> static int __init feat_enable_idle_stop(struct dt_cpu_feature *f)
>>>>> {
>>>>> u64 lpcr;
>>>>> @@ -641,7 +634,6 @@ static struct dt_cpu_feature_match __initdata
>>>>> {"tm-suspend-hypervisor-assist", feat_enable, CPU_FTR_P9_TM_HV_ASSIST},
>>>>> {"tm-suspend-xer-so-bug", feat_enable, CPU_FTR_P9_TM_XER_SO_BUG},
>>>>> {"idle-nap", feat_enable_idle_nap, 0},
>>>>> - {"alignment-interrupt-dsisr", feat_enable_align_dsisr, 0},
>>
>> Rather than removing it entirely, I'd rather we left a comment, so that
>> it's obvious that we are ignoring that feature on purpose, not because
>> we forget about it.
>>
>> eg:
>>
>> diff --git a/arch/powerpc/kernel/dt_cpu_ftrs.c b/arch/powerpc/kernel/dt_cpu_ftrs.c
>> index f204ad79b6b5..45cb7e59bd13 100644
>> --- a/arch/powerpc/kernel/dt_cpu_ftrs.c
>> +++ b/arch/powerpc/kernel/dt_cpu_ftrs.c
>> @@ -640,7 +640,7 @@ static struct dt_cpu_feature_match __initdata
>> {"tm-suspend-hypervisor-assist", feat_enable, CPU_FTR_P9_TM_HV_ASSIST},
>> {"tm-suspend-xer-so-bug", feat_enable, CPU_FTR_P9_TM_XER_SO_BUG},
>> {"idle-nap", feat_enable_idle_nap, 0},
>> - {"alignment-interrupt-dsisr", feat_enable_align_dsisr, 0},
>> + // "alignment-interrupt-dsisr" ignored
>> {"idle-stop", feat_enable_idle_stop, 0},
>> {"machine-check-power8", feat_enable_mce_power8, 0},
>> {"performance-monitor-power8", feat_enable_pmu_power8, 0},
>>
>
>
> why not do it as
> static int __init feat_enable_align_dsisr(struct dt_cpu_feature *f)
> {
> /* This feature should not be enabled */
> #ifdef DEBUG
> WARN(1);
> #endif
>
> return 1;
> }
No one will ever turn that #define on.
No one will ever turn the feature on either.
Even if they did, it's not a bug because the kernel doesn't use the
DSISR for alignment interrupts any more.
All I want is to be able to compare the list of features defined in
skiboot vs the ones in Linux and see that none are missing in Linux.
cheers
^ permalink raw reply
* Re: [PATCH v2] ima: defer arch_ima_get_secureboot() call to IMA init time
From: Mimi Zohar @ 2020-10-14 11:38 UTC (permalink / raw)
To: Chester Lin, Ard Biesheuvel
Cc: linux-efi, Dmitry Kasatkin, James Morris, jlee,
linux-security-module, linux-integrity,
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT), Serge E. Hallyn
In-Reply-To: <20201014093531.GA9408@linux-8mug>
On Wed, 2020-10-14 at 17:35 +0800, Chester Lin wrote:
> Hi Ard & Mimi,
>
> On Tue, Oct 13, 2020 at 06:59:21PM +0200, Ard Biesheuvel wrote:
> > On Tue, 13 Oct 2020 at 18:46, Mimi Zohar <zohar@linux.ibm.com> wrote:
> > >
> > > [Cc'ing linuxppc-dev@lists.ozlabs.org]
> > >
> > > On Tue, 2020-10-13 at 10:18 +0200, Ard Biesheuvel wrote:
> > > > Chester reports that it is necessary to introduce a new way to pass
> > > > the EFI secure boot status between the EFI stub and the core kernel
> > > > on ARM systems. The usual way of obtaining this information is by
> > > > checking the SecureBoot and SetupMode EFI variables, but this can
> > > > only be done after the EFI variable workqueue is created, which
> > > > occurs in a subsys_initcall(), whereas arch_ima_get_secureboot()
> > > > is called much earlier by the IMA framework.
> > > >
> > > > However, the IMA framework itself is started as a late_initcall,
> > > > and the only reason the call to arch_ima_get_secureboot() occurs
> > > > so early is because it happens in the context of a __setup()
> > > > callback that parses the ima_appraise= command line parameter.
> > > >
> > > > So let's refactor this code a little bit, by using a core_param()
> > > > callback to capture the command line argument, and deferring any
> > > > reasoning based on its contents to the IMA init routine.
> > > >
> > > > Cc: Chester Lin <clin@suse.com>
> > > > Cc: Mimi Zohar <zohar@linux.ibm.com>
> > > > Cc: Dmitry Kasatkin <dmitry.kasatkin@gmail.com>
> > > > Cc: James Morris <jmorris@namei.org>
> > > > Cc: "Serge E. Hallyn" <serge@hallyn.com>
> > > > Link: https://lore.kernel.org/linux-arm-kernel/20200904072905.25332-2-clin@suse.com/
> > > > Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> > > > ---
> > > > v2: rebase onto series 'integrity: improve user feedback for invalid bootparams'
> > >
> > > Thanks, Ard. Based on my initial, limited testing on Power, it looks
> > > good, but I'm hesistant to include it in the integrity 5.10 pull
> > > request without it having been in linux-next and some additional
> > > testing. It's now queued in the next-integrity-testing branch awaiting
> > > some tags.
> > >
>
> Tested-by: Chester Lin <clin@suse.com>
>
> I have tested this patch on x86 VM.
>
> * System configuration:
> - Platform: QEMU/KVM
> - Firmware: EDK2/OVMF + secure boot enabled.
> - OS: SLE15-SP2 + SUSE's kernel-vanilla (=linux v5.9) + the follow commits
> from linux-next and upstream:
> * [PATCH v2] ima: defer arch_ima_get_secureboot() call to IMA init time
> https://www.spinics.net/lists/linux-efi/msg20645.html
> * e4d7e2df3a09 "ima: limit secure boot feedback scope for appraise"
> * 7fe2bb7e7e5c "integrity: invalid kernel parameters feedback"
> * 4afb28ab03d5 "ima: add check for enforced appraise option"
>
> * Logs with UEFI secure boot enabled:
>
> [ 0.000000] Linux version 5.9.0-858-g865c50e1d279-1.g8764d18-vanilla (geeko@b
> uildhost) (gcc (SUSE Linux) 10.2.1 20200825 [revision c0746a1beb1ba073c7981eb09f
> 55b3d993b32e5c], GNU ld (GNU Binutils; openSUSE Tumbleweed) 2.34.0.20200325-1) #
> 1 SMP Wed Oct 14 04:00:11 UTC 2020 (8764d18)
> [ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-5.9.0-858-g865c50e1d279-1.
> g8764d18-vanilla root=UUID=5304c03e-4d8a-4d67-873a-32a32e57cdeb console=ttyS0,11
> 5200 resume=/dev/disk/by-path/pci-0000:04:00.0-part4 mitigations=auto ignore_log
> level crashkernel=192M,high crashkernel=72M,low ima_appraise=off
> [ 0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point regi
> sters'
> [ 0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
> [ 0.000000] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
> ....
> ....
> [ 1.720309] ima: Secure boot enabled: ignoring ima_appraise=off option
> [ 1.720314] ima: No TPM chip found, activating TPM-bypass!
> [ 1.722129] ima: Allocated hash algorithm: sha256
Thank you for testing the options aren't being set in secure boot mode.
My main concern, however, is that IMA doesn't go into TPM-bypass mode.
Does this system have a TPM?
Mimi
^ permalink raw reply
* Re: [PATCH v2] ima: defer arch_ima_get_secureboot() call to IMA init time
From: Chester Lin @ 2020-10-14 9:35 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: linux-efi, Dmitry Kasatkin, James Morris, Mimi Zohar, jlee,
linux-security-module, linux-integrity,
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT), Serge E. Hallyn
In-Reply-To: <CAMj1kXFZVR46_oeYTxJ59q-7u+zFCFtOQuSQoiEzKLhXzpydow@mail.gmail.com>
Hi Ard & Mimi,
On Tue, Oct 13, 2020 at 06:59:21PM +0200, Ard Biesheuvel wrote:
> On Tue, 13 Oct 2020 at 18:46, Mimi Zohar <zohar@linux.ibm.com> wrote:
> >
> > [Cc'ing linuxppc-dev@lists.ozlabs.org]
> >
> > On Tue, 2020-10-13 at 10:18 +0200, Ard Biesheuvel wrote:
> > > Chester reports that it is necessary to introduce a new way to pass
> > > the EFI secure boot status between the EFI stub and the core kernel
> > > on ARM systems. The usual way of obtaining this information is by
> > > checking the SecureBoot and SetupMode EFI variables, but this can
> > > only be done after the EFI variable workqueue is created, which
> > > occurs in a subsys_initcall(), whereas arch_ima_get_secureboot()
> > > is called much earlier by the IMA framework.
> > >
> > > However, the IMA framework itself is started as a late_initcall,
> > > and the only reason the call to arch_ima_get_secureboot() occurs
> > > so early is because it happens in the context of a __setup()
> > > callback that parses the ima_appraise= command line parameter.
> > >
> > > So let's refactor this code a little bit, by using a core_param()
> > > callback to capture the command line argument, and deferring any
> > > reasoning based on its contents to the IMA init routine.
> > >
> > > Cc: Chester Lin <clin@suse.com>
> > > Cc: Mimi Zohar <zohar@linux.ibm.com>
> > > Cc: Dmitry Kasatkin <dmitry.kasatkin@gmail.com>
> > > Cc: James Morris <jmorris@namei.org>
> > > Cc: "Serge E. Hallyn" <serge@hallyn.com>
> > > Link: https://lore.kernel.org/linux-arm-kernel/20200904072905.25332-2-clin@suse.com/
> > > Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> > > ---
> > > v2: rebase onto series 'integrity: improve user feedback for invalid bootparams'
> >
> > Thanks, Ard. Based on my initial, limited testing on Power, it looks
> > good, but I'm hesistant to include it in the integrity 5.10 pull
> > request without it having been in linux-next and some additional
> > testing. It's now queued in the next-integrity-testing branch awaiting
> > some tags.
> >
Tested-by: Chester Lin <clin@suse.com>
I have tested this patch on x86 VM.
* System configuration:
- Platform: QEMU/KVM
- Firmware: EDK2/OVMF + secure boot enabled.
- OS: SLE15-SP2 + SUSE's kernel-vanilla (=linux v5.9) + the follow commits
from linux-next and upstream:
* [PATCH v2] ima: defer arch_ima_get_secureboot() call to IMA init time
https://www.spinics.net/lists/linux-efi/msg20645.html
* e4d7e2df3a09 "ima: limit secure boot feedback scope for appraise"
* 7fe2bb7e7e5c "integrity: invalid kernel parameters feedback"
* 4afb28ab03d5 "ima: add check for enforced appraise option"
* Logs with UEFI secure boot enabled:
[ 0.000000] Linux version 5.9.0-858-g865c50e1d279-1.g8764d18-vanilla (geeko@b
uildhost) (gcc (SUSE Linux) 10.2.1 20200825 [revision c0746a1beb1ba073c7981eb09f
55b3d993b32e5c], GNU ld (GNU Binutils; openSUSE Tumbleweed) 2.34.0.20200325-1) #
1 SMP Wed Oct 14 04:00:11 UTC 2020 (8764d18)
[ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-5.9.0-858-g865c50e1d279-1.
g8764d18-vanilla root=UUID=5304c03e-4d8a-4d67-873a-32a32e57cdeb console=ttyS0,11
5200 resume=/dev/disk/by-path/pci-0000:04:00.0-part4 mitigations=auto ignore_log
level crashkernel=192M,high crashkernel=72M,low ima_appraise=off
[ 0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point regi
sters'
[ 0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[ 0.000000] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
....
....
[ 1.720309] ima: Secure boot enabled: ignoring ima_appraise=off option
[ 1.720314] ima: No TPM chip found, activating TPM-bypass!
[ 1.722129] ima: Allocated hash algorithm: sha256
....
>
> Thanks. No rush as far as I am concerned, although I suppose Chester
> may want to rebase his arm64 IMA enablement series on this.
Yes, I've finished coding but still verifying it. As you have suggested,
My v2 patch will separate the get_sb_mode() from arch/x86 so that other
architectures can reuse it.
Thanks,
Chester
>
> Suggestion: can we take the get_sb_mode() code from ima_arch.c in
> arch/x86, and generalize it for all EFI architectures? That way, we
> can enable 32-bit ARM and RISC-V seamlessly once someone gets around
> to enabling IMA on those platforms. In fact, get_sb_mode() itself
> should probably be factored out into a generic helper for use outside
> of IMA as well (Xen/x86 has code that does roughly the same already)
>
^ permalink raw reply
* Re: [PATCH 04/20] dt-bindings: usb: usb-hcd: Add "tpl-support" property
From: Rob Herring @ 2020-10-14 13:27 UTC (permalink / raw)
To: Serge Semin
Cc: Neil Armstrong, Bjorn Andersson, Pavel Parkhomenko, Kevin Hilman,
Andy Gross, linux-snps-arc, devicetree, Mathias Nyman,
Lad Prabhakar, Alexey Malahov, Rob Herring, linux-arm-kernel,
Roger Quadros, Felipe Balbi, Greg Kroah-Hartman,
Yoshihiro Shimoda, linux-usb, linux-mips, Serge Semin,
linux-kernel, Manu Gautam, linuxppc-dev
In-Reply-To: <20201014101402.18271-5-Sergey.Semin@baikalelectronics.ru>
On Wed, 14 Oct 2020 13:13:46 +0300, Serge Semin wrote:
> The host controller device might be designed to work for the particular
> products or applications. In that case its DT node is supposed to be
> equipped with the tpl-support property.
>
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
>
> ---
>
> Changelog v2:
> - Grammar fix: "s/it'/its"
> - Discard '|' from the property description, since we don't need to preserve
> the text formatting.
> ---
> Documentation/devicetree/bindings/usb/usb-hcd.yaml | 6 ++++++
> 1 file changed, 6 insertions(+)
>
My bot found errors running 'make dt_binding_check' on your patch:
Traceback (most recent call last):
File "/usr/local/bin/dt-extract-example", line 45, in <module>
binding = yaml.load(open(args.yamlfile, encoding='utf-8').read())
File "/usr/local/lib/python3.8/dist-packages/ruamel/yaml/main.py", line 343, in load
return constructor.get_single_data()
File "/usr/local/lib/python3.8/dist-packages/ruamel/yaml/constructor.py", line 111, in get_single_data
node = self.composer.get_single_node()
File "_ruamel_yaml.pyx", line 706, in _ruamel_yaml.CParser.get_single_node
File "_ruamel_yaml.pyx", line 724, in _ruamel_yaml.CParser._compose_document
File "_ruamel_yaml.pyx", line 775, in _ruamel_yaml.CParser._compose_node
File "_ruamel_yaml.pyx", line 891, in _ruamel_yaml.CParser._compose_mapping_node
File "_ruamel_yaml.pyx", line 904, in _ruamel_yaml.CParser._parse_next_event
ruamel.yaml.scanner.ScannerError: mapping values are not allowed in this context
in "<unicode string>", line 27, column 14
make[1]: *** [Documentation/devicetree/bindings/Makefile:20: Documentation/devicetree/bindings/usb/usb-hcd.example.dts] Error 1
make[1]: *** Deleting file 'Documentation/devicetree/bindings/usb/usb-hcd.example.dts'
make[1]: *** Waiting for unfinished jobs....
./Documentation/devicetree/bindings/usb/usb-hcd.yaml:27:14: [error] syntax error: mapping values are not allowed here (syntax)
make[1]: *** [Documentation/devicetree/bindings/Makefile:59: Documentation/devicetree/bindings/processed-schema-examples.json] Error 123
make: *** [Makefile:1366: dt_binding_check] Error 2
See https://patchwork.ozlabs.org/patch/1382001
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure dt-schema is up to date:
pip3 install git+https://github.com/devicetree-org/dt-schema.git@master --upgrade
Please check and re-submit.
^ permalink raw reply
* Re: [PATCH 09/20] dt-bindings: usb: Convert DWC USB3 bindings to DT schema
From: Rob Herring @ 2020-10-14 13:32 UTC (permalink / raw)
To: Serge Semin
Cc: Neil Armstrong, linux-kernel, Pavel Parkhomenko, Kevin Hilman,
Andy Gross, linux-snps-arc, devicetree, Mathias Nyman,
Lad Prabhakar, Alexey Malahov, Rob Herring, Bjorn Andersson,
linux-arm-kernel, Roger Quadros, Felipe Balbi, Greg Kroah-Hartman,
Yoshihiro Shimoda, linux-usb, linux-mips, Serge Semin,
Manu Gautam, linuxppc-dev
In-Reply-To: <20201014101402.18271-10-Sergey.Semin@baikalelectronics.ru>
On Wed, 14 Oct 2020 13:13:51 +0300, Serge Semin wrote:
> DWC USB3 DT node is supposed to be compliant with the Generic xHCI
> Controller schema, but with additional vendor-specific properties, the
> controller-specific reference clocks and PHYs. So let's convert the
> currently available legacy text-based DWC USB3 bindings to the DT schema
> and make sure the DWC USB3 nodes are also validated against the
> usb-xhci.yaml schema.
>
> Note we have to discard the nodename restriction of being prefixed with
> "dwc3@" string, since in accordance with the usb-hcd.yaml schema USB nodes
> are supposed to be named as "^usb(@.*)".
>
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
>
> ---
>
> Changelog v2:
> - Discard '|' from the descriptions, since we don't need to preserve
> the text formatting in any of them.
> - Drop quotes from around the string constants.
> - Fix the "clock-names" prop description to be referring the enumerated
> clock-names instead of the ones from the Databook.
> ---
> .../devicetree/bindings/usb/dwc3.txt | 125 --------
> .../devicetree/bindings/usb/snps,dwc3.yaml | 295 ++++++++++++++++++
> 2 files changed, 295 insertions(+), 125 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/usb/dwc3.txt
> create mode 100644 Documentation/devicetree/bindings/usb/snps,dwc3.yaml
>
My bot found errors running 'make dt_binding_check' on your patch:
./Documentation/devicetree/bindings/usb/snps,dwc3.yaml:44:4: [warning] wrong indentation: expected 4 but found 3 (indentation)
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/usb/qcom,dwc3.example.dt.yaml: dwc3@a600000: $nodename:0: 'dwc3@a600000' does not match '^usb(@.*)?'
From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.example.dt.yaml: usb@ff500000: snps,quirk-frame-length-adjustment: True is not of type 'array'
From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
See https://patchwork.ozlabs.org/patch/1382003
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure dt-schema is up to date:
pip3 install git+https://github.com/devicetree-org/dt-schema.git@master --upgrade
Please check and re-submit.
^ permalink raw reply
* Re: [PATCH 20/20] arch: dts: Fix DWC USB3 DT nodes name
From: Felipe Balbi @ 2020-10-14 14:09 UTC (permalink / raw)
To: Serge Semin, Mathias Nyman, Greg Kroah-Hartman, Rob Herring,
Jason Cooper, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
Kukjin Kim, Krzysztof Kozlowski, Santosh Shilimkar, Shawn Guo,
Li Yang, Benoît Cousson, Tony Lindgren, Patrice Chotard,
Maxime Ripard, Chen-Yu Tsai, Wei Xu, Andy Gross, Bjorn Andersson
Cc: devicetree, linux-samsung-soc, linux-mips, Neil Armstrong,
Kevin Hilman, Yoshihiro Shimoda, linux-usb, linux-kernel,
Lad Prabhakar, Serge Semin, Alexey Malahov, Serge Semin,
Manu Gautam, linux-omap, Pavel Parkhomenko, linux-arm-msm,
linux-snps-arc, linuxppc-dev, linux-arm-kernel, Roger Quadros
In-Reply-To: <20201014101402.18271-21-Sergey.Semin@baikalelectronics.ru>
[-- Attachment #1: Type: text/plain, Size: 1063 bytes --]
Hi Serge,
Serge Semin <Sergey.Semin@baikalelectronics.ru> writes:
> In accordance with the DWC USB3 bindings the corresponding node name is
> suppose to comply with Generic USB HCD DT schema, which requires the USB
DWC3 is not a simple HDC, though.
> nodes to have the name acceptable by the regexp: "^usb(@.*)?" . But a lot
> of the DWC USB3-compatible nodes defined in the ARM/ARM64 DTS files have
> name as "^dwc3@.*" or "^usb[1-3]@.*" or even "^dwusb@.*", which will cause
> the dtbs_check procedure failure. Let's fix the nodes naming to be
> compatible with the DWC USB3 DT schema to make dtbs_check happy.
>
> Note we don't change the DWC USB3-compatible nodes names of
> arch/arm64/boot/dts/apm/{apm-storm.dtsi,apm-shadowcat.dtsi} since the
> in-source comment says that the nodes name need to be preserved as
> "^dwusb@.*" for some backward compatibility.
interesting, compatibility with what? Some debugfs files, perhaps? :-)
In any case, I don't have any problems with this, so I'll let other
folks comment.
--
balbi
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 857 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc/pci: Fix PHB removal/rescan on PowerNV
From: Greg Kurz @ 2020-10-14 14:24 UTC (permalink / raw)
To: Cédric Le Goater
Cc: Alexey Kardashevskiy, linuxppc-dev, Oliver O'Halloran,
linux-pci
In-Reply-To: <06bf1b7b-e9b4-44b0-1aad-60b938f8e924@kaod.org>
On Thu, 8 Oct 2020 06:37:02 +0200
Cédric Le Goater <clg@kaod.org> wrote:
> On 10/8/20 4:23 AM, Oliver O'Halloran wrote:
> > On Fri, Sep 25, 2020 at 7:23 PM Cédric Le Goater <clg@kaod.org> wrote:
> >>
> >> To fix an issue with PHB hotplug on pSeries machine (HPT/XIVE), commit
> >> 3a3181e16fbd introduced a PPC specific pcibios_remove_bus() routine to
> >> clear all interrupt mappings when the bus is removed. This routine
> >> frees an array allocated in pcibios_scan_phb().
> >>
> >> This broke PHB hotplug on PowerNV because, when a PHB is removed and
> >> re-scanned through sysfs, the PCI layer un-assigns and re-assigns
> >> resources to the PHB but does not destroy and recreate the PCI
> >> controller structure. Since pcibios_remove_bus() does not clear the
> >> 'irq_map' array pointer, a second removal of the PHB will try to free
> >> the array a second time and corrupt memory.
> >
> > "PHB hotplug" and "hot-plugging devices under a PHB" are different
> > things. What you're saying here doesn't make a whole lot of sense to
> > me unless you're conflating the two. The distinction is important
> > since on pseries we can use DLPAR to add and remove actual PHBs (i.e.
> > the pci_controller) at runtime, but there's no corresponding mechanism
> > on PowerNV.
>
> And it's even different on QEMU.
>
If the real HW doesn't have the notion of adding/removing a PHB at
runtime, then QEMU should stick to that, ie. setting dc->hotpluggable
to false for PNV PHB device types.
> >> Free the 'irq_map' array in pcibios_free_controller() to fix
> >> corruption and clear interrupt mapping after it has been
> >> disposed. This to avoid filling up the array with successive
> >> remove/rescan of a bus.
> >
> > Even with this patch I think we're still broken. With this patch
> > applied the init path is something like:
> >
> > per-phb init:
> > allocate phb->irq_map array
> > per-bus init:
> > nothing
> > per-device init:
> > pcibios_bus_add_device()
> > pci_read_irq_line()
> > pci_irq_map_register(pci_dev, virq)
> > *record the device's interrupt in phb->irq_map*
> >
> > And the teardown path:
> >
> > per-device teardown:
> > nothing
> > per-bus teardown:
> > pcibios_remove_bus()
> > pci_irq_map_dispose()
> > *walk phb->irq_map and dispose of each mapped interrupt*
> > per-phb teardown:
> > free(phb->irq_map)
> >
> > There's a lot of asymmetry here, which is a problem in itself, but the
> > real issue is that when removing *any* pci_bus under a PHB we dispose
> > of the LSI\ for *every* device under that PHB. Not good.
> >
> > Ideally we should be fixing this by having the per-device teardown
> > handle disposing the mapping. Unfortunately, there's no pcibios hook
> > that's called when removing a pci_dev. However, we can register a bus
> > notifier which will be called when the pci_dev is removed from its bus
> > and we already do that for the per-device EEH teardown and to handle
> > IOMMU TCE invalidation when the device is removed.
>
> I lack the knowledge here and I think some else should take over,
> as I am not doing a good job.
>
> Michael, can you drop the initial patch again :/ It is better not
> to merge anything.
>
> Thanks,
>
> C.
>
>
^ permalink raw reply
* Re: [PATCH 18/20] arch: dts: Fix EHCI/OHCI DT nodes name
From: Florian Fainelli @ 2020-10-14 18:00 UTC (permalink / raw)
To: Serge Semin, Mathias Nyman, Felipe Balbi, Greg Kroah-Hartman,
Rob Herring, Alexey Brodkin, Vineet Gupta, Hauke Mehrtens,
Rafał Miłecki, bcm-kernel-feedback-list, Wei Xu,
Vladimir Zapolskiy, Maxime Coquelin, Alexandre Torgue,
Paul Cercueil, Thomas Bogendoerfer, Matthias Brugger,
Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras
Cc: devicetree, linux-snps-arc, linux-mips, Neil Armstrong,
Kevin Hilman, Yoshihiro Shimoda, linux-usb, linux-kernel,
Lad Prabhakar, Serge Semin, Bjorn Andersson, Manu Gautam,
Andy Gross, linux-mediatek, Pavel Parkhomenko, Alexey Malahov,
linuxppc-dev, linux-stm32, linux-arm-kernel, Roger Quadros
In-Reply-To: <20201014101402.18271-19-Sergey.Semin@baikalelectronics.ru>
On 10/14/20 3:14 AM, Serge Semin wrote:
> In accordance with the Generic EHCI/OHCI bindings the corresponding node
> name is suppose to comply with the Generic USB HCD DT schema, which
> requires the USB nodes to have the name acceptable by the regexp:
> "^usb(@.*)?" . Let's fix the DTS files, which have the nodes defined with
> incompatible names.
>
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
>
> ---
>
> Please, test the patch out to make sure it doesn't brake the dependent DTS
> files. I did only a manual grepping of the possible nodes dependencies.
Not sure how you envisioned these change to be picked up, but you may
need to split these changes between ARM/ARM64, MIPS and PowerPC at
least. And within ARM/ARM64 you will most likely have to split according
to the various SoC maintainers.
--
Florian
^ permalink raw reply
* [PATCH -next] Revert "powerpc/pci: unmap legacy INTx interrupts when a PHB is removed"
From: Qian Cai @ 2020-10-14 18:28 UTC (permalink / raw)
To: Michael Ellerman
Cc: Stephen Rothwell, Alexey Kardashevskiy, linux-kernel, linux-next,
Oliver O'Halloran, Cédric Le Goater, linuxppc-dev
This reverts commit 3a3181e16fbde752007759f8759d25e0ff1fc425 which
causes memory corruptions on POWER9 NV.
Signed-off-by: Qian Cai <cai@lca.pw>
---
arch/powerpc/include/asm/pci-bridge.h | 6 --
arch/powerpc/kernel/pci-common.c | 114 --------------------------
2 files changed, 120 deletions(-)
diff --git a/arch/powerpc/include/asm/pci-bridge.h b/arch/powerpc/include/asm/pci-bridge.h
index d21e070352dc..d2a2a14e56f9 100644
--- a/arch/powerpc/include/asm/pci-bridge.h
+++ b/arch/powerpc/include/asm/pci-bridge.h
@@ -48,9 +48,6 @@ struct pci_controller_ops {
/*
* Structure of a PCI controller (host bridge)
- *
- * @irq_count: number of interrupt mappings
- * @irq_map: interrupt mappings
*/
struct pci_controller {
struct pci_bus *bus;
@@ -130,9 +127,6 @@ struct pci_controller {
void *private_data;
struct npu *npu;
-
- unsigned int irq_count;
- unsigned int *irq_map;
};
/* These are used for config access before all the PCI probing
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index deb831f0ae13..be108616a721 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -353,115 +353,6 @@ struct pci_controller *pci_find_controller_for_domain(int domain_nr)
return NULL;
}
-/*
- * Assumption is made on the interrupt parent. All interrupt-map
- * entries are considered to have the same parent.
- */
-static int pcibios_irq_map_count(struct pci_controller *phb)
-{
- const __be32 *imap;
- int imaplen;
- struct device_node *parent;
- u32 intsize, addrsize, parintsize, paraddrsize;
-
- if (of_property_read_u32(phb->dn, "#interrupt-cells", &intsize))
- return 0;
- if (of_property_read_u32(phb->dn, "#address-cells", &addrsize))
- return 0;
-
- imap = of_get_property(phb->dn, "interrupt-map", &imaplen);
- if (!imap) {
- pr_debug("%pOF : no interrupt-map\n", phb->dn);
- return 0;
- }
- imaplen /= sizeof(u32);
- pr_debug("%pOF : imaplen=%d\n", phb->dn, imaplen);
-
- if (imaplen < (addrsize + intsize + 1))
- return 0;
-
- imap += intsize + addrsize;
- parent = of_find_node_by_phandle(be32_to_cpup(imap));
- if (!parent) {
- pr_debug("%pOF : no imap parent found !\n", phb->dn);
- return 0;
- }
-
- if (of_property_read_u32(parent, "#interrupt-cells", &parintsize)) {
- pr_debug("%pOF : parent lacks #interrupt-cells!\n", phb->dn);
- return 0;
- }
-
- if (of_property_read_u32(parent, "#address-cells", ¶ddrsize))
- paraddrsize = 0;
-
- return imaplen / (addrsize + intsize + 1 + paraddrsize + parintsize);
-}
-
-static void pcibios_irq_map_init(struct pci_controller *phb)
-{
- phb->irq_count = pcibios_irq_map_count(phb);
- if (phb->irq_count < PCI_NUM_INTX)
- phb->irq_count = PCI_NUM_INTX;
-
- pr_debug("%pOF : interrupt map #%d\n", phb->dn, phb->irq_count);
-
- phb->irq_map = kcalloc(phb->irq_count, sizeof(unsigned int),
- GFP_KERNEL);
-}
-
-static void pci_irq_map_register(struct pci_dev *pdev, unsigned int virq)
-{
- struct pci_controller *phb = pci_bus_to_host(pdev->bus);
- int i;
-
- if (!phb->irq_map)
- return;
-
- for (i = 0; i < phb->irq_count; i++) {
- /*
- * Look for an empty or an equivalent slot, as INTx
- * interrupts can be shared between adapters.
- */
- if (phb->irq_map[i] == virq || !phb->irq_map[i]) {
- phb->irq_map[i] = virq;
- break;
- }
- }
-
- if (i == phb->irq_count)
- pr_err("PCI:%s all platform interrupts mapped\n",
- pci_name(pdev));
-}
-
-/*
- * Clearing the mapped interrupts will also clear the underlying
- * mappings of the ESB pages of the interrupts when under XIVE. It is
- * a requirement of PowerVM to clear all memory mappings before
- * removing a PHB.
- */
-static void pci_irq_map_dispose(struct pci_bus *bus)
-{
- struct pci_controller *phb = pci_bus_to_host(bus);
- int i;
-
- if (!phb->irq_map)
- return;
-
- pr_debug("PCI: Clearing interrupt mappings for PHB %04x:%02x...\n",
- pci_domain_nr(bus), bus->number);
- for (i = 0; i < phb->irq_count; i++)
- irq_dispose_mapping(phb->irq_map[i]);
-
- kfree(phb->irq_map);
-}
-
-void pcibios_remove_bus(struct pci_bus *bus)
-{
- pci_irq_map_dispose(bus);
-}
-EXPORT_SYMBOL_GPL(pcibios_remove_bus);
-
/*
* Reads the interrupt pin to determine if interrupt is use by card.
* If the interrupt is used, then gets the interrupt line from the
@@ -510,8 +401,6 @@ static int pci_read_irq_line(struct pci_dev *pci_dev)
pci_dev->irq = virq;
- /* Record all interrut mappings for later removal of a PHB */
- pci_irq_map_register(pci_dev, virq);
return 0;
}
@@ -1665,9 +1554,6 @@ void pcibios_scan_phb(struct pci_controller *hose)
pr_debug("PCI: Scanning PHB %pOF\n", node);
- /* Allocate interrupt mappings array */
- pcibios_irq_map_init(hose);
-
/* Get some IO space for the new PHB */
pcibios_setup_phb_io_space(hose);
--
2.28.0
^ permalink raw reply related
* Re: [PATCH 20/20] arch: dts: Fix DWC USB3 DT nodes name
From: Rob Herring @ 2020-10-14 18:35 UTC (permalink / raw)
To: Serge Semin
Cc: Andrew Lunn, Linux USB List, Neil Armstrong, Tony Lindgren,
Bjorn Andersson, Wei Xu, linux-samsung-soc, Kevin Hilman,
Gregory Clement, Krzysztof Kozlowski, Chen-Yu Tsai, Kukjin Kim,
Andy Gross, linux-arm-msm, arcml, Sebastian Hesselbarth,
devicetree, Jason Cooper, Mathias Nyman,
linux-kernel@vger.kernel.org, Lad Prabhakar, Maxime Ripard,
Alexey Malahov, Santosh Shilimkar, linux-omap, linux-arm-kernel,
Roger Quadros, Felipe Balbi, open list:MIPS, Greg Kroah-Hartman,
Yoshihiro Shimoda, linuxppc-dev, Patrice Chotard, Serge Semin,
Li Yang, Manu Gautam, Benoît Cousson, Shawn Guo,
Pavel Parkhomenko
In-Reply-To: <20201014143720.yny3jco5pkb7dr4b@mobilestation>
On Wed, Oct 14, 2020 at 9:37 AM Serge Semin
<Sergey.Semin@baikalelectronics.ru> wrote:
>
> On Wed, Oct 14, 2020 at 05:09:37PM +0300, Felipe Balbi wrote:
> >
> > Hi Serge,
> >
> > Serge Semin <Sergey.Semin@baikalelectronics.ru> writes:
> > > In accordance with the DWC USB3 bindings the corresponding node name is
> > > suppose to comply with Generic USB HCD DT schema, which requires the USB
> >
>
> > DWC3 is not a simple HDC, though.
>
> Yeah, strictly speaking it is equipped with a lot of vendor-specific stuff,
> which are tuned by the DWC USB3 driver in the kernel. But after that the
> controller is registered as xhci-hcd device so it's serviced by the xHCI driver,
> which then registers the HCD device so the corresponding DT node is supposed
> to be compatible with the next bindings: usb/usb-hcd.yaml, usb/usb-xhci.yaml
> and usb/snps,dwc3,yaml. I've created the later one so to validate the denoted
> compatibility.
>
> >
> > > nodes to have the name acceptable by the regexp: "^usb(@.*)?" . But a lot
> > > of the DWC USB3-compatible nodes defined in the ARM/ARM64 DTS files have
> > > name as "^dwc3@.*" or "^usb[1-3]@.*" or even "^dwusb@.*", which will cause
> > > the dtbs_check procedure failure. Let's fix the nodes naming to be
> > > compatible with the DWC USB3 DT schema to make dtbs_check happy.
> > >
> > > Note we don't change the DWC USB3-compatible nodes names of
> > > arch/arm64/boot/dts/apm/{apm-storm.dtsi,apm-shadowcat.dtsi} since the
> > > in-source comment says that the nodes name need to be preserved as
> > > "^dwusb@.*" for some backward compatibility.
> >
>
> > interesting, compatibility with what? Some debugfs files, perhaps? :-)
>
> Don't really know.) In my experience the worst type of such compatibility is
> connected with some bootloader magic, which may add/remove/modify properties
> to nodes with pre-defined names.
I seriously doubt anyone is using the APM machines with DT (even ACPI
is somewhat doubtful). I say change them. Or remove the dts files and
see what happens. Either way it can always be reverted.
Rob
^ permalink raw reply
* Re: [PATCH 18/20] arch: dts: Fix EHCI/OHCI DT nodes name
From: Florian Fainelli @ 2020-10-14 18:41 UTC (permalink / raw)
To: Serge Semin
Cc: Neil Armstrong, Bjorn Andersson, Paul Cercueil, Paul Mackerras,
Pavel Parkhomenko, linux-stm32, Rafał Miłecki,
Alexey Brodkin, Wei Xu, Andy Gross, bcm-kernel-feedback-list,
Kevin Hilman, linux-snps-arc, devicetree, Alexandre Torgue,
Mathias Nyman, Hauke Mehrtens, Lad Prabhakar, Vladimir Zapolskiy,
Rob Herring, linux-mediatek, Matthias Brugger, Alexey Malahov,
linux-arm-kernel, Roger Quadros, Felipe Balbi,
Thomas Bogendoerfer, Greg Kroah-Hartman, Yoshihiro Shimoda,
linux-usb, linux-mips, Serge Semin, linux-kernel, Manu Gautam,
Maxime Coquelin, Vineet Gupta, linuxppc-dev
In-Reply-To: <20201014181136.5hwsu77rv3wbxw7w@mobilestation>
On 10/14/20 11:11 AM, Serge Semin wrote:
> On Wed, Oct 14, 2020 at 11:00:45AM -0700, Florian Fainelli wrote:
>> On 10/14/20 3:14 AM, Serge Semin wrote:
>>> In accordance with the Generic EHCI/OHCI bindings the corresponding node
>>> name is suppose to comply with the Generic USB HCD DT schema, which
>>> requires the USB nodes to have the name acceptable by the regexp:
>>> "^usb(@.*)?" . Let's fix the DTS files, which have the nodes defined with
>>> incompatible names.
>>>
>>> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
>>>
>>> ---
>>>
>>> Please, test the patch out to make sure it doesn't brake the dependent DTS
>>> files. I did only a manual grepping of the possible nodes dependencies.
>>
>
>> Not sure how you envisioned these change to be picked up, but you may
>> need to split these changes between ARM/ARM64, MIPS and PowerPC at
>> least. And within ARM/ARM64 you will most likely have to split according
>> to the various SoC maintainers.
>
> Hmm, I don't really know how it's going to be done in this case, but there must
> be a way to get the cross-platform patches picked up in general. For
> instance, see the patches like:
> 714acdbd1c94 arch: rename copy_thread_tls() back to copy_thread()
> 140c8180eb7c arch: remove HAVE_COPY_THREAD_TLS
> They touched the files from different files, but still have been merged in.
That situation is different, when a new facility is added and someone
has gone through the work of adding support for all architectures (or
nearly all of them), you want them to be merged in a way that limits
merge conflicts with other architecture changes.
Here you are fixing warnings, and each file you touch can clearly be
independently change from other files in the series without causing
merge conflicts. You are however creating the potential for merge
conflicts with other changes that the various SoC maintainers have
queued up.
> Maybe I should have copied these three patches to the "linux-arch@vger.kernel.org"
> list or some other mailing list...
Maybe Rob can queue them through his device tree repository, with the
ack of the various SoC maintainers...
--
Florian
^ permalink raw reply
* Re: [PATCH 18/20] arch: dts: Fix EHCI/OHCI DT nodes name
From: Paul Cercueil @ 2020-10-14 18:56 UTC (permalink / raw)
To: Serge Semin
Cc: Neil Armstrong, Bjorn Andersson, Paul Mackerras,
Pavel Parkhomenko, linux-stm32, Rafał Miłecki,
Alexey Brodkin, Wei Xu, Andy Gross, bcm-kernel-feedback-list,
Kevin Hilman, linux-snps-arc, devicetree, Alexandre Torgue,
Mathias Nyman, Hauke Mehrtens, Lad Prabhakar, Vladimir Zapolskiy,
Rob Herring, linux-mediatek, Matthias Brugger, Alexey Malahov,
linux-arm-kernel, Roger Quadros, Felipe Balbi,
Thomas Bogendoerfer, Vineet Gupta, Yoshihiro Shimoda, linux-usb,
linux-mips, Serge Semin, linux-kernel, Manu Gautam,
Maxime Coquelin, Greg Kroah-Hartman, linuxppc-dev
In-Reply-To: <20201014101402.18271-19-Sergey.Semin@baikalelectronics.ru>
Le mer. 14 oct. 2020 à 13:14, Serge Semin
<Sergey.Semin@baikalelectronics.ru> a écrit :
> In accordance with the Generic EHCI/OHCI bindings the corresponding
> node
> name is suppose to comply with the Generic USB HCD DT schema, which
> requires the USB nodes to have the name acceptable by the regexp:
> "^usb(@.*)?" . Let's fix the DTS files, which have the nodes defined
> with
> incompatible names.
>
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
>
> ---
>
> Please, test the patch out to make sure it doesn't brake the
> dependent DTS
> files. I did only a manual grepping of the possible nodes
> dependencies.
> ---
> arch/arc/boot/dts/axs10x_mb.dtsi | 4 ++--
> arch/arc/boot/dts/hsdk.dts | 4 ++--
> arch/arc/boot/dts/vdk_axs10x_mb.dtsi | 2 +-
> arch/arm/boot/dts/bcm5301x.dtsi | 4 ++--
> arch/arm/boot/dts/bcm53573.dtsi | 4 ++--
> arch/arm/boot/dts/hisi-x5hd2.dtsi | 4 ++--
> arch/arm/boot/dts/lpc18xx.dtsi | 4 ++--
> arch/arm/boot/dts/stm32mp151.dtsi | 4 ++--
> arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi | 4 ++--
> arch/arm64/boot/dts/hisilicon/hip06.dtsi | 4 ++--
> arch/arm64/boot/dts/hisilicon/hip07.dtsi | 4 ++--
> arch/mips/boot/dts/ingenic/jz4740.dtsi | 2 +-
> arch/mips/boot/dts/ingenic/jz4770.dtsi | 2 +-
For jz4740.dtsi and jz4770.dtsi:
Acked-by: Paul Cercueil <paul@crapouillou.net>
Cheers,
-Paul
> arch/mips/boot/dts/mti/sead3.dts | 2 +-
> arch/mips/boot/dts/ralink/mt7628a.dtsi | 2 +-
> arch/powerpc/boot/dts/akebono.dts | 6 +++---
> 16 files changed, 28 insertions(+), 28 deletions(-)
>
> diff --git a/arch/arc/boot/dts/axs10x_mb.dtsi
> b/arch/arc/boot/dts/axs10x_mb.dtsi
> index 99d3e7175bf7..b64435385304 100644
> --- a/arch/arc/boot/dts/axs10x_mb.dtsi
> +++ b/arch/arc/boot/dts/axs10x_mb.dtsi
> @@ -87,13 +87,13 @@ gmac: ethernet@18000 {
> mac-address = [00 00 00 00 00 00]; /* Filled in by U-Boot */
> };
>
> - ehci@40000 {
> + usb@40000 {
> compatible = "generic-ehci";
> reg = < 0x40000 0x100 >;
> interrupts = < 8 >;
> };
>
> - ohci@60000 {
> + usb@60000 {
> compatible = "generic-ohci";
> reg = < 0x60000 0x100 >;
> interrupts = < 8 >;
> diff --git a/arch/arc/boot/dts/hsdk.dts b/arch/arc/boot/dts/hsdk.dts
> index dcaa44e408ac..fdd4f7f635d3 100644
> --- a/arch/arc/boot/dts/hsdk.dts
> +++ b/arch/arc/boot/dts/hsdk.dts
> @@ -234,7 +234,7 @@ phy0: ethernet-phy@0 { /* Micrel KSZ9031 */
> };
> };
>
> - ohci@60000 {
> + usb@60000 {
> compatible = "snps,hsdk-v1.0-ohci", "generic-ohci";
> reg = <0x60000 0x100>;
> interrupts = <15>;
> @@ -242,7 +242,7 @@ ohci@60000 {
> dma-coherent;
> };
>
> - ehci@40000 {
> + usb@40000 {
> compatible = "snps,hsdk-v1.0-ehci", "generic-ehci";
> reg = <0x40000 0x100>;
> interrupts = <15>;
> diff --git a/arch/arc/boot/dts/vdk_axs10x_mb.dtsi
> b/arch/arc/boot/dts/vdk_axs10x_mb.dtsi
> index cbb179770293..90a412026e64 100644
> --- a/arch/arc/boot/dts/vdk_axs10x_mb.dtsi
> +++ b/arch/arc/boot/dts/vdk_axs10x_mb.dtsi
> @@ -46,7 +46,7 @@ ethernet@18000 {
> clock-names = "stmmaceth";
> };
>
> - ehci@40000 {
> + usb@40000 {
> compatible = "generic-ehci";
> reg = < 0x40000 0x100 >;
> interrupts = < 8 >;
> diff --git a/arch/arm/boot/dts/bcm5301x.dtsi
> b/arch/arm/boot/dts/bcm5301x.dtsi
> index 0016720ce530..bf5656d79a55 100644
> --- a/arch/arm/boot/dts/bcm5301x.dtsi
> +++ b/arch/arm/boot/dts/bcm5301x.dtsi
> @@ -261,7 +261,7 @@ usb2: usb2@21000 {
>
> interrupt-parent = <&gic>;
>
> - ehci: ehci@21000 {
> + ehci: usb@21000 {
> #usb-cells = <0>;
>
> compatible = "generic-ehci";
> @@ -283,7 +283,7 @@ ehci_port2: port@2 {
> };
> };
>
> - ohci: ohci@22000 {
> + ohci: usb@22000 {
> #usb-cells = <0>;
>
> compatible = "generic-ohci";
> diff --git a/arch/arm/boot/dts/bcm53573.dtsi
> b/arch/arm/boot/dts/bcm53573.dtsi
> index 4af8e3293cff..51546fccc616 100644
> --- a/arch/arm/boot/dts/bcm53573.dtsi
> +++ b/arch/arm/boot/dts/bcm53573.dtsi
> @@ -135,7 +135,7 @@ usb2: usb2@4000 {
> #address-cells = <1>;
> #size-cells = <1>;
>
> - ehci: ehci@4000 {
> + ehci: usb@4000 {
> compatible = "generic-ehci";
> reg = <0x4000 0x1000>;
> interrupt-parent = <&gic>;
> @@ -155,7 +155,7 @@ ehci_port2: port@2 {
> };
> };
>
> - ohci: ohci@d000 {
> + ohci: usb@d000 {
> #usb-cells = <0>;
>
> compatible = "generic-ohci";
> diff --git a/arch/arm/boot/dts/hisi-x5hd2.dtsi
> b/arch/arm/boot/dts/hisi-x5hd2.dtsi
> index 3ee7967c202d..693b85b2cc7d 100644
> --- a/arch/arm/boot/dts/hisi-x5hd2.dtsi
> +++ b/arch/arm/boot/dts/hisi-x5hd2.dtsi
> @@ -452,14 +452,14 @@ gmac1: ethernet@1841000 {
> status = "disabled";
> };
>
> - usb0: ehci@1890000 {
> + usb0: usb@1890000 {
> compatible = "generic-ehci";
> reg = <0x1890000 0x1000>;
> interrupts = <0 66 4>;
> clocks = <&clock HIX5HD2_USB_CLK>;
> };
>
> - usb1: ohci@1880000 {
> + usb1: usb@1880000 {
> compatible = "generic-ohci";
> reg = <0x1880000 0x1000>;
> interrupts = <0 67 4>;
> diff --git a/arch/arm/boot/dts/lpc18xx.dtsi
> b/arch/arm/boot/dts/lpc18xx.dtsi
> index 10b8249b8ab6..82ffd7b0ad8a 100644
> --- a/arch/arm/boot/dts/lpc18xx.dtsi
> +++ b/arch/arm/boot/dts/lpc18xx.dtsi
> @@ -121,7 +121,7 @@ mmcsd: mmcsd@40004000 {
> status = "disabled";
> };
>
> - usb0: ehci@40006100 {
> + usb0: usb@40006100 {
> compatible = "nxp,lpc1850-ehci", "generic-ehci";
> reg = <0x40006100 0x100>;
> interrupts = <8>;
> @@ -133,7 +133,7 @@ usb0: ehci@40006100 {
> status = "disabled";
> };
>
> - usb1: ehci@40007100 {
> + usb1: usb@40007100 {
> compatible = "nxp,lpc1850-ehci", "generic-ehci";
> reg = <0x40007100 0x100>;
> interrupts = <9>;
> diff --git a/arch/arm/boot/dts/stm32mp151.dtsi
> b/arch/arm/boot/dts/stm32mp151.dtsi
> index bfe29023fbd5..576f7da564c5 100644
> --- a/arch/arm/boot/dts/stm32mp151.dtsi
> +++ b/arch/arm/boot/dts/stm32mp151.dtsi
> @@ -1404,7 +1404,7 @@ ethernet0: ethernet@5800a000 {
> status = "disabled";
> };
>
> - usbh_ohci: usbh-ohci@5800c000 {
> + usbh_ohci: usb@5800c000 {
> compatible = "generic-ohci";
> reg = <0x5800c000 0x1000>;
> clocks = <&rcc USBH>;
> @@ -1413,7 +1413,7 @@ usbh_ohci: usbh-ohci@5800c000 {
> status = "disabled";
> };
>
> - usbh_ehci: usbh-ehci@5800d000 {
> + usbh_ehci: usb@5800d000 {
> compatible = "generic-ehci";
> reg = <0x5800d000 0x1000>;
> clocks = <&rcc USBH>;
> diff --git a/arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi
> b/arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi
> index 12bc1d3ed424..a4acecb75c89 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi
> @@ -585,7 +585,7 @@ pcie: pcie@9860000 {
> status = "disabled";
> };
>
> - ohci: ohci@9880000 {
> + ohci: usb@9880000 {
> compatible = "generic-ohci";
> reg = <0x9880000 0x10000>;
> interrupts = <GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>;
> @@ -600,7 +600,7 @@ ohci: ohci@9880000 {
> status = "disabled";
> };
>
> - ehci: ehci@9890000 {
> + ehci: usb@9890000 {
> compatible = "generic-ehci";
> reg = <0x9890000 0x10000>;
> interrupts = <GIC_SPI 66 IRQ_TYPE_LEVEL_HIGH>;
> diff --git a/arch/arm64/boot/dts/hisilicon/hip06.dtsi
> b/arch/arm64/boot/dts/hisilicon/hip06.dtsi
> index 50ceaa959bdc..1226440d54ad 100644
> --- a/arch/arm64/boot/dts/hisilicon/hip06.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hip06.dtsi
> @@ -373,7 +373,7 @@ refclk: refclk {
> #clock-cells = <0>;
> };
>
> - usb_ohci: ohci@a7030000 {
> + usb_ohci: usb@a7030000 {
> compatible = "generic-ohci";
> reg = <0x0 0xa7030000 0x0 0x10000>;
> interrupt-parent = <&mbigen_usb>;
> @@ -382,7 +382,7 @@ usb_ohci: ohci@a7030000 {
> status = "disabled";
> };
>
> - usb_ehci: ehci@a7020000 {
> + usb_ehci: usb@a7020000 {
> compatible = "generic-ehci";
> reg = <0x0 0xa7020000 0x0 0x10000>;
> interrupt-parent = <&mbigen_usb>;
> diff --git a/arch/arm64/boot/dts/hisilicon/hip07.dtsi
> b/arch/arm64/boot/dts/hisilicon/hip07.dtsi
> index 4773a533fce5..93f99a5255ac 100644
> --- a/arch/arm64/boot/dts/hisilicon/hip07.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hip07.dtsi
> @@ -1253,7 +1253,7 @@ uart0: uart@602b0000 {
> status = "disabled";
> };
>
> - usb_ohci: ohci@a7030000 {
> + usb_ohci: usb@a7030000 {
> compatible = "generic-ohci";
> reg = <0x0 0xa7030000 0x0 0x10000>;
> interrupt-parent = <&mbigen_usb>;
> @@ -1262,7 +1262,7 @@ usb_ohci: ohci@a7030000 {
> status = "disabled";
> };
>
> - usb_ehci: ehci@a7020000 {
> + usb_ehci: usb@a7020000 {
> compatible = "generic-ehci";
> reg = <0x0 0xa7020000 0x0 0x10000>;
> interrupt-parent = <&mbigen_usb>;
> diff --git a/arch/mips/boot/dts/ingenic/jz4740.dtsi
> b/arch/mips/boot/dts/ingenic/jz4740.dtsi
> index 1520585c235c..b989ff62ffbc 100644
> --- a/arch/mips/boot/dts/ingenic/jz4740.dtsi
> +++ b/arch/mips/boot/dts/ingenic/jz4740.dtsi
> @@ -281,7 +281,7 @@ dmac: dma-controller@13020000 {
> clocks = <&cgu JZ4740_CLK_DMA>;
> };
>
> - uhc: uhc@13030000 {
> + uhc: usb@13030000 {
> compatible = "ingenic,jz4740-ohci", "generic-ohci";
> reg = <0x13030000 0x1000>;
>
> diff --git a/arch/mips/boot/dts/ingenic/jz4770.dtsi
> b/arch/mips/boot/dts/ingenic/jz4770.dtsi
> index fa11ac950499..e45c03038826 100644
> --- a/arch/mips/boot/dts/ingenic/jz4770.dtsi
> +++ b/arch/mips/boot/dts/ingenic/jz4770.dtsi
> @@ -417,7 +417,7 @@ dmac1: dma-controller@13420100 {
> interrupts = <23>;
> };
>
> - uhc: uhc@13430000 {
> + uhc: usb@13430000 {
> compatible = "generic-ohci";
> reg = <0x13430000 0x1000>;
>
> diff --git a/arch/mips/boot/dts/mti/sead3.dts
> b/arch/mips/boot/dts/mti/sead3.dts
> index 192c26ff1d3d..1cf6728af8fe 100644
> --- a/arch/mips/boot/dts/mti/sead3.dts
> +++ b/arch/mips/boot/dts/mti/sead3.dts
> @@ -56,7 +56,7 @@ gic: interrupt-controller@1b1c0000 {
> interrupt-parent = <&cpu_intc>;
> };
>
> - ehci@1b200000 {
> + usb@1b200000 {
> compatible = "generic-ehci";
> reg = <0x1b200000 0x1000>;
>
> diff --git a/arch/mips/boot/dts/ralink/mt7628a.dtsi
> b/arch/mips/boot/dts/ralink/mt7628a.dtsi
> index 892e8ab863c5..45bf96a3d17a 100644
> --- a/arch/mips/boot/dts/ralink/mt7628a.dtsi
> +++ b/arch/mips/boot/dts/ralink/mt7628a.dtsi
> @@ -275,7 +275,7 @@ usb_phy: usb-phy@10120000 {
> reset-names = "host", "device";
> };
>
> - ehci@101c0000 {
> + usb@101c0000 {
> compatible = "generic-ehci";
> reg = <0x101c0000 0x1000>;
>
> diff --git a/arch/powerpc/boot/dts/akebono.dts
> b/arch/powerpc/boot/dts/akebono.dts
> index df18f8dc4642..343326c30380 100644
> --- a/arch/powerpc/boot/dts/akebono.dts
> +++ b/arch/powerpc/boot/dts/akebono.dts
> @@ -126,7 +126,7 @@ SATA0: sata@30000010000 {
> interrupts = <93 2>;
> };
>
> - EHCI0: ehci@30010000000 {
> + EHCI0: usb@30010000000 {
> compatible = "ibm,476gtr-ehci", "generic-ehci";
> reg = <0x300 0x10000000 0x0 0x10000>;
> interrupt-parent = <&MPIC>;
> @@ -140,14 +140,14 @@ SD0: sd@30000000000 {
> interrupt-parent = <&MPIC>;
> };
>
> - OHCI0: ohci@30010010000 {
> + OHCI0: usb@30010010000 {
> compatible = "ibm,476gtr-ohci", "generic-ohci";
> reg = <0x300 0x10010000 0x0 0x10000>;
> interrupt-parent = <&MPIC>;
> interrupts = <89 1>;
> };
>
> - OHCI1: ohci@30010020000 {
> + OHCI1: usb@30010020000 {
> compatible = "ibm,476gtr-ohci", "generic-ohci";
> reg = <0x300 0x10020000 0x0 0x10000>;
> interrupt-parent = <&MPIC>;
> --
> 2.27.0
>
^ permalink raw reply
* Re: [PATCH 18/20] arch: dts: Fix EHCI/OHCI DT nodes name
From: Alexey Brodkin @ 2020-10-14 19:12 UTC (permalink / raw)
To: Paul Cercueil, Serge Semin
Cc: Neil Armstrong, Bjorn Andersson, Paul Mackerras,
Pavel Parkhomenko, linux-stm32@st-md-mailman.stormreply.com,
Rafał Miłecki, Wei Xu, Andy Gross,
bcm-kernel-feedback-list@broadcom.com,
linux-snps-arc@lists.infradead.org, devicetree@vger.kernel.org,
Alexandre Torgue, Mathias Nyman, Hauke Mehrtens, Vineet Gupta,
Lad Prabhakar, Vladimir Zapolskiy, Rob Herring,
linux-mediatek@lists.infradead.org, Matthias Brugger,
Alexey Malahov, linux-arm-kernel@lists.infradead.org,
Roger Quadros, Felipe Balbi, Thomas Bogendoerfer,
Greg Kroah-Hartman, Yoshihiro Shimoda, linux-usb@vger.kernel.org,
linux-mips@vger.kernel.org, Serge Semin,
linux-kernel@vger.kernel.org, Manu Gautam, Maxime Coquelin,
Kevin Hilman, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <DLG7IQ.15UXZI2H6RYC3@crapouillou.net>
Hi Sergey,
> arch/arc/boot/dts/axs10x_mb.dtsi | 4 ++--
> arch/arc/boot/dts/hsdk.dts | 4 ++--
> arch/arc/boot/dts/vdk_axs10x_mb.dtsi | 2 +-
For ARC boards
Acked-by: Alexey Brodkin <abrodkin@synopsys.com>
^ permalink raw reply
* RE: [RFC v1 0/2] Plumbing to support multiple secure memory backends.
From: Ram Pai @ 2020-10-14 19:30 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: bharata, linuxppc-dev, kvm-ppc, farosas
In-Reply-To: <20201014063117.GA26161@infradead.org>
On Wed, Oct 14, 2020 at 07:31:17AM +0100, Christoph Hellwig wrote:
> Please don't add an abstraction without a second implementation.
> Once we have the implementation we can consider the tradeoffs. E.g.
> if expensive indirect function calls are really needed vs simple
> branches.
Ok. Not planning on upstreaming these patches till we have atleast
another backend.
--
Ram Pai
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox