* [PATCH v1 25/30] powerpc/vdso: Remove lib32_elfinfo and lib64_elfinfo
From: Christophe Leroy @ 2020-09-27 9:16 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <cover.1601197618.git.christophe.leroy@csgroup.eu>
lib32_elfinfo and lib64_elfinfo are not used anymore, remove them.
Also remove vdso32_kbase and vdso64_kbase while removing the
last use.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
arch/powerpc/kernel/vdso.c | 29 ++---------------------------
1 file changed, 2 insertions(+), 27 deletions(-)
diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index f7b477da0b8a..0cb320b72923 100644
--- a/arch/powerpc/kernel/vdso.c
+++ b/arch/powerpc/kernel/vdso.c
@@ -44,11 +44,8 @@
/* The alignment of the vDSO */
#define VDSO_ALIGNMENT (1 << 16)
-static void *vdso32_kbase;
-
extern char vdso32_start, vdso32_end;
extern char vdso64_start, vdso64_end;
-static void *vdso64_kbase = &vdso64_start;
static int vdso_ready;
@@ -63,20 +60,6 @@ static union {
} vdso_data_store __page_aligned_data;
struct vdso_arch_data *vdso_data = &vdso_data_store.data;
-/*
- * Some infos carried around for each of them during parsing at
- * boot time.
- */
-struct lib32_elfinfo
-{
- Elf32_Ehdr *hdr; /* ptr to ELF */
-};
-
-struct lib64_elfinfo
-{
- Elf64_Ehdr *hdr;
-};
-
static int vdso_mremap(const struct vm_special_mapping *sm, struct vm_area_struct *new_vma,
unsigned long text_size)
{
@@ -209,8 +192,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
do_##type##_fixups((value), __start, __end); \
} while (0)
-static __init int vdso_fixup_features(struct lib32_elfinfo *v32,
- struct lib64_elfinfo *v64)
+static int __init vdso_fixup_features(void)
{
#ifdef CONFIG_PPC64
VDSO_DO_FIXUPS(feature, cur_cpu_spec->cpu_features, 64, ftr_fixup);
@@ -233,12 +215,7 @@ static __init int vdso_fixup_features(struct lib32_elfinfo *v32,
static __init int vdso_setup(void)
{
- struct lib32_elfinfo v32;
- struct lib64_elfinfo v64;
-
- v32.hdr = vdso32_kbase;
- v64.hdr = vdso64_kbase;
- if (vdso_fixup_features(&v32, &v64))
+ if (vdso_fixup_features())
return -1;
return 0;
@@ -334,8 +311,6 @@ static int __init vdso_init(void)
vdso_data->icache_log_block_size = ppc64_caches.l1i.log_block_size;
#endif /* CONFIG_PPC64 */
- vdso32_kbase = &vdso32_start;
-
vdso_setup_syscall_map();
/*
--
2.25.0
^ permalink raw reply related
* [PATCH v1 24/30] powerpc/vdso: Remove symbol section information in struct lib32/64_elfinfo
From: Christophe Leroy @ 2020-09-27 9:16 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <cover.1601197618.git.christophe.leroy@csgroup.eu>
The members related to the symbol section in struct lib32_elfinfo and
struct lib64_elfinfo are not used anymore, removed them.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
arch/powerpc/kernel/vdso.c | 90 --------------------------------------
1 file changed, 90 deletions(-)
diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index fa1cbddfb978..f7b477da0b8a 100644
--- a/arch/powerpc/kernel/vdso.c
+++ b/arch/powerpc/kernel/vdso.c
@@ -70,17 +70,11 @@ struct vdso_arch_data *vdso_data = &vdso_data_store.data;
struct lib32_elfinfo
{
Elf32_Ehdr *hdr; /* ptr to ELF */
- Elf32_Sym *dynsym; /* ptr to .dynsym section */
- unsigned long dynsymsize; /* size of .dynsym section */
- char *dynstr; /* ptr to .dynstr section */
};
struct lib64_elfinfo
{
Elf64_Ehdr *hdr;
- Elf64_Sym *dynsym;
- unsigned long dynsymsize;
- char *dynstr;
};
static int vdso_mremap(const struct vm_special_mapping *sm, struct vm_area_struct *new_vma,
@@ -208,59 +202,6 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
return rc;
}
-#ifdef CONFIG_VDSO32
-static void * __init find_section32(Elf32_Ehdr *ehdr, const char *secname,
- unsigned long *size)
-{
- Elf32_Shdr *sechdrs;
- unsigned int i;
- char *secnames;
-
- /* Grab section headers and strings so we can tell who is who */
- sechdrs = (void *)ehdr + ehdr->e_shoff;
- secnames = (void *)ehdr + sechdrs[ehdr->e_shstrndx].sh_offset;
-
- /* Find the section they want */
- for (i = 1; i < ehdr->e_shnum; i++) {
- if (strcmp(secnames+sechdrs[i].sh_name, secname) == 0) {
- if (size)
- *size = sechdrs[i].sh_size;
- return (void *)ehdr + sechdrs[i].sh_offset;
- }
- }
- *size = 0;
- return NULL;
-}
-#endif /* CONFIG_VDSO32 */
-
-
-#ifdef CONFIG_PPC64
-
-static void * __init find_section64(Elf64_Ehdr *ehdr, const char *secname,
- unsigned long *size)
-{
- Elf64_Shdr *sechdrs;
- unsigned int i;
- char *secnames;
-
- /* Grab section headers and strings so we can tell who is who */
- sechdrs = (void *)ehdr + ehdr->e_shoff;
- secnames = (void *)ehdr + sechdrs[ehdr->e_shstrndx].sh_offset;
-
- /* Find the section they want */
- for (i = 1; i < ehdr->e_shnum; i++) {
- if (strcmp(secnames+sechdrs[i].sh_name, secname) == 0) {
- if (size)
- *size = sechdrs[i].sh_size;
- return (void *)ehdr + sechdrs[i].sh_offset;
- }
- }
- if (size)
- *size = 0;
- return NULL;
-}
-#endif /* CONFIG_PPC64 */
-
#define VDSO_DO_FIXUPS(type, value, bits, sec) do { \
void *__start = (void *)VDSO##bits##_SYMBOL(&vdso##bits##_start, sec##_start); \
void *__end = (void *)VDSO##bits##_SYMBOL(&vdso##bits##_start, sec##_end); \
@@ -268,34 +209,6 @@ static void * __init find_section64(Elf64_Ehdr *ehdr, const char *secname,
do_##type##_fixups((value), __start, __end); \
} while (0)
-static __init int vdso_do_find_sections(struct lib32_elfinfo *v32,
- struct lib64_elfinfo *v64)
-{
- /*
- * Locate symbol tables & text section
- */
-
-#ifdef CONFIG_VDSO32
- v32->dynsym = find_section32(v32->hdr, ".dynsym", &v32->dynsymsize);
- v32->dynstr = find_section32(v32->hdr, ".dynstr", NULL);
- if (v32->dynsym == NULL || v32->dynstr == NULL) {
- printk(KERN_ERR "vDSO32: required symbol section not found\n");
- return -1;
- }
-#endif
-
-#ifdef CONFIG_PPC64
- v64->dynsym = find_section64(v64->hdr, ".dynsym", &v64->dynsymsize);
- v64->dynstr = find_section64(v64->hdr, ".dynstr", NULL);
- if (v64->dynsym == NULL || v64->dynstr == NULL) {
- printk(KERN_ERR "vDSO64: required symbol section not found\n");
- return -1;
- }
-#endif /* CONFIG_PPC64 */
-
- return 0;
-}
-
static __init int vdso_fixup_features(struct lib32_elfinfo *v32,
struct lib64_elfinfo *v64)
{
@@ -325,9 +238,6 @@ static __init int vdso_setup(void)
v32.hdr = vdso32_kbase;
v64.hdr = vdso64_kbase;
- if (vdso_do_find_sections(&v32, &v64))
- return -1;
-
if (vdso_fixup_features(&v32, &v64))
return -1;
--
2.25.0
^ permalink raw reply related
* [PATCH v1 26/30] powerpc/vdso: Remove vdso_setup()
From: Christophe Leroy @ 2020-09-27 9:16 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <cover.1601197618.git.christophe.leroy@csgroup.eu>
vdso_fixup_features() cannot fail anymore and that's
the only function called by vdso_setup().
vdso_setup() has become trivial and can be removed.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
arch/powerpc/kernel/vdso.c | 21 ++-------------------
1 file changed, 2 insertions(+), 19 deletions(-)
diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index 0cb320b72923..14fbcc76a629 100644
--- a/arch/powerpc/kernel/vdso.c
+++ b/arch/powerpc/kernel/vdso.c
@@ -192,7 +192,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
do_##type##_fixups((value), __start, __end); \
} while (0)
-static int __init vdso_fixup_features(void)
+static void __init vdso_fixup_features(void)
{
#ifdef CONFIG_PPC64
VDSO_DO_FIXUPS(feature, cur_cpu_spec->cpu_features, 64, ftr_fixup);
@@ -209,16 +209,6 @@ static int __init vdso_fixup_features(void)
#endif /* CONFIG_PPC64 */
VDSO_DO_FIXUPS(lwsync, cur_cpu_spec->cpu_features, 32, lwsync_fixup);
#endif
-
- return 0;
-}
-
-static __init int vdso_setup(void)
-{
- if (vdso_fixup_features())
- return -1;
-
- return 0;
}
/*
@@ -313,14 +303,7 @@ static int __init vdso_init(void)
vdso_setup_syscall_map();
- /*
- * Initialize the vDSO images in memory, that is do necessary
- * fixups of vDSO symbols, locate trampolines, etc...
- */
- if (vdso_setup()) {
- printk(KERN_ERR "vDSO setup failure, not enabled !\n");
- return 0;
- }
+ vdso_fixup_features();
if (IS_ENABLED(CONFIG_VDSO32))
vdso32_spec.pages = vdso_setup_pages(&vdso32_start, &vdso32_end);
--
2.25.0
^ permalink raw reply related
* [PATCH v1 27/30] powerpc/vdso: Remove vdso_ready
From: Christophe Leroy @ 2020-09-27 9:16 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <cover.1601197618.git.christophe.leroy@csgroup.eu>
There is no way to get out of vdso_init() prematuraly anymore.
Remove vdso_ready as it will always be 1.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
arch/powerpc/kernel/vdso.c | 6 ------
1 file changed, 6 deletions(-)
diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index 14fbcc76a629..e5a9b60274ba 100644
--- a/arch/powerpc/kernel/vdso.c
+++ b/arch/powerpc/kernel/vdso.c
@@ -47,8 +47,6 @@
extern char vdso32_start, vdso32_end;
extern char vdso64_start, vdso64_end;
-static int vdso_ready;
-
/*
* The vdso data page (aka. systemcfg for old ppc64 fans) is here.
* Once the early boot kernel code no longer needs to muck around
@@ -171,9 +169,6 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
mm->context.vdso = NULL;
- if (!vdso_ready)
- return 0;
-
if (mmap_write_lock_killable(mm))
return -EINTR;
@@ -312,7 +307,6 @@ static int __init vdso_init(void)
vdso64_spec.pages = vdso_setup_pages(&vdso64_start, &vdso64_end);
smp_wmb();
- vdso_ready = 1;
return 0;
}
--
2.25.0
^ permalink raw reply related
* [PATCH v1 28/30] powerpc/vdso: Remove DBG()
From: Christophe Leroy @ 2020-09-27 9:16 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <cover.1601197618.git.christophe.leroy@csgroup.eu>
DBG() is not used anymore. Remove it.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
arch/powerpc/kernel/vdso.c | 8 --------
1 file changed, 8 deletions(-)
diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index e5a9b60274ba..4e3858bb2b24 100644
--- a/arch/powerpc/kernel/vdso.c
+++ b/arch/powerpc/kernel/vdso.c
@@ -33,14 +33,6 @@
#include <asm/vdso_datapage.h>
#include <asm/setup.h>
-#undef DEBUG
-
-#ifdef DEBUG
-#define DBG(fmt...) printk(fmt)
-#else
-#define DBG(fmt...)
-#endif
-
/* The alignment of the vDSO */
#define VDSO_ALIGNMENT (1 << 16)
--
2.25.0
^ permalink raw reply related
* [PATCH v1 29/30] powerpc/vdso: Remove VDSO32_LBASE and VDSO64_LBASE
From: Christophe Leroy @ 2020-09-27 9:16 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <cover.1601197618.git.christophe.leroy@csgroup.eu>
VDSO32_LBASE and VDSO64_LBASE are 0. Remove them to simplify code.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
arch/powerpc/include/asm/vdso.h | 4 ----
arch/powerpc/kernel/vdso32/vdso32.lds.S | 2 +-
arch/powerpc/kernel/vdso64/vdso64.lds.S | 2 +-
3 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/include/asm/vdso.h b/arch/powerpc/include/asm/vdso.h
index a97384909fe5..2448419cb3e5 100644
--- a/arch/powerpc/include/asm/vdso.h
+++ b/arch/powerpc/include/asm/vdso.h
@@ -4,10 +4,6 @@
#ifdef __KERNEL__
-/* Default link addresses for the vDSOs */
-#define VDSO32_LBASE 0x0
-#define VDSO64_LBASE 0x0
-
/* Default map addresses for 32bit vDSO */
#define VDSO32_MBASE 0x100000
diff --git a/arch/powerpc/kernel/vdso32/vdso32.lds.S b/arch/powerpc/kernel/vdso32/vdso32.lds.S
index 7b476a6f2dba..2636b359c9ce 100644
--- a/arch/powerpc/kernel/vdso32/vdso32.lds.S
+++ b/arch/powerpc/kernel/vdso32/vdso32.lds.S
@@ -17,7 +17,7 @@ ENTRY(_start)
SECTIONS
{
PROVIDE(_vdso_datapage = . - PAGE_SIZE);
- . = VDSO32_LBASE + SIZEOF_HEADERS;
+ . = SIZEOF_HEADERS;
.hash : { *(.hash) } :text
.gnu.hash : { *(.gnu.hash) }
diff --git a/arch/powerpc/kernel/vdso64/vdso64.lds.S b/arch/powerpc/kernel/vdso64/vdso64.lds.S
index a543826cd857..f256525e633f 100644
--- a/arch/powerpc/kernel/vdso64/vdso64.lds.S
+++ b/arch/powerpc/kernel/vdso64/vdso64.lds.S
@@ -17,7 +17,7 @@ ENTRY(_start)
SECTIONS
{
PROVIDE(_vdso_datapage = . - PAGE_SIZE);
- . = VDSO64_LBASE + SIZEOF_HEADERS;
+ . = SIZEOF_HEADERS;
.hash : { *(.hash) } :text
.gnu.hash : { *(.gnu.hash) }
--
2.25.0
^ permalink raw reply related
* [PATCH v1 30/30] powerpc/vdso: Cleanup vdso.h
From: Christophe Leroy @ 2020-09-27 9:16 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <cover.1601197618.git.christophe.leroy@csgroup.eu>
Rename the guard define to _ASM_POWERPC_VDSO_H
And remove useless #ifdef __KERNEL__
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
arch/powerpc/include/asm/vdso.h | 10 +++-------
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/include/asm/vdso.h b/arch/powerpc/include/asm/vdso.h
index 2448419cb3e5..8542e9bbeead 100644
--- a/arch/powerpc/include/asm/vdso.h
+++ b/arch/powerpc/include/asm/vdso.h
@@ -1,8 +1,6 @@
/* SPDX-License-Identifier: GPL-2.0 */
-#ifndef __PPC64_VDSO_H__
-#define __PPC64_VDSO_H__
-
-#ifdef __KERNEL__
+#ifndef _ASM_POWERPC_VDSO_H
+#define _ASM_POWERPC_VDSO_H
/* Default map addresses for 32bit vDSO */
#define VDSO32_MBASE 0x100000
@@ -54,6 +52,4 @@ int vdso_getcpu_init(void);
#endif /* __ASSEMBLY__ */
-#endif /* __KERNEL__ */
-
-#endif /* __PPC64_VDSO_H__ */
+#endif /* _ASM_POWERPC_VDSO_H */
--
2.25.0
^ permalink raw reply related
* Re: [PATCH v2] i2c: cpm: Fix i2c_ram structure
From: Wolfram Sang @ 2020-09-27 13:15 UTC (permalink / raw)
To: nicolas.vincent; +Cc: linuxppc-dev, linux-i2c
In-Reply-To: <20200923140840.8700-1-nicolas.vincent@vossloh.com>
[-- Attachment #1: Type: text/plain, Size: 771 bytes --]
On Wed, Sep 23, 2020 at 04:08:40PM +0200, nico.vince@gmail.com wrote:
> From: Nicolas VINCENT <nicolas.vincent@vossloh.com>
>
> the i2c_ram structure is missing the sdmatmp field mentionned in
> datasheet for MPC8272 at paragraph 36.5. With this field missing, the
> hardware would write past the allocated memory done through
> cpm_muram_alloc for the i2c_ram structure and land in memory allocated
> for the buffers descriptors corrupting the cbd_bufaddr field. Since this
> field is only set during setup(), the first i2c transaction would work
> and the following would send data read from an arbitrary memory
> location.
>
> Signed-off-by: Nicolas VINCENT <nicolas.vincent@vossloh.com>
Fixes tag aded and applied to for-current, thanks everyone!
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v3 2/5] powerpc: apm82181: create shared dtsi for APM bluestone
From: Christian Lamparter @ 2020-09-27 17:42 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, Arnd Bergmann, Chris Blake, Paul Mackerras,
Andy Shevchenko, linuxppc-dev
In-Reply-To: <CAL_Jsq+x0jFh-2jVt9pVek6a2=UCv0z0sBJpuh5irxeQG+tbUg@mail.gmail.com>
On Tue, Sep 22, 2020 at 9:14 PM Rob Herring <robh@kernel.org> wrote:
>
> On Sat, Sep 19, 2020 at 2:23 PM Christian Lamparter <chunkeey@gmail.com> wrote:
> >
> > On 2020-09-15 03:05, Rob Herring wrote:
> > > On Sun, Sep 06, 2020 at 12:06:12AM +0200, Christian Lamparter wrote:
> > >> This patch adds an DTSI-File that can be used by various device-tree
> > >> files for APM82181-based devices.
> > >>
> > >> Some of the nodes (like UART, PCIE, SATA) are used by the uboot and
> > >> need to stick with the naming-conventions of the old times'.
> > >> I've added comments whenever this was the case.
> > >>
> > >> Signed-off-by: Chris Blake <chrisrblake93@gmail.com>
> > >> Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
> > >> ---
> > >> rfc v1 -> v2:
> > >> - removed PKA (this CryptoPU will need driver)
> > >> - stick with compatibles, nodes, ... from either
> > >> Bluestone (APM82181) or Canyonlands (PPC460EX).
> > >> - add labels for NAND and NOR to help with access.
> > >> v2 -> v3:
> > >> - nodename of pciex@d.... was changed to pcie@d..
> > >> due to upstream patch.
> > >> - use simple-bus on the ebc, opb and plb nodes
> > >> ---
> > >> arch/powerpc/boot/dts/apm82181.dtsi | 466 ++++++++++++++++++++++++++++
> > >> 1 file changed, 466 insertions(+)
> > >> create mode 100644 arch/powerpc/boot/dts/apm82181.dtsi
> > >>
> > >> diff --git a/arch/powerpc/boot/dts/apm82181.dtsi b/arch/powerpc/boot/dts/apm82181.dtsi
> > >> new file mode 100644
> > >> index 000000000000..60283430978d
> > >> --- /dev/null
> > >> +++ b/arch/powerpc/boot/dts/apm82181.dtsi
> > >> @@ -0,0 +1,466 @@
> > >> +// SPDX-License-Identifier: GPL-2.0-or-later
> > >> +/*
> > >> + * Device Tree template include for various APM82181 boards.
> > >> + *
> > >> + * The SoC is an evolution of the PPC460EX predecessor.
> > >> + * This is why dt-nodes from the canyonlands EBC, OPB, USB,
> > >> + * DMA, SATA, EMAC, ... ended up in here.
> > >> + *
> > >> + * Copyright (c) 2010, Applied Micro Circuits Corporation
> > >> + * Author: Tirumala R Marri <tmarri@apm.com>,
> > >> + * Christian Lamparter <chunkeey@gmail.com>,
> > >> + * Chris Blake <chrisrblake93@gmail.com>
> > >> + */
> > >> +
> > >> +#include <dt-bindings/dma/dw-dmac.h>
> > >> +#include <dt-bindings/input/input.h>
> > >> +#include <dt-bindings/interrupt-controller/irq.h>
> > >> +#include <dt-bindings/gpio/gpio.h>
> > >> +
> > >> +/ {
> > >> + #address-cells = <2>;
> > >> + #size-cells = <1>;
> > >> + dcr-parent = <&{/cpus/cpu@0}>;
> > >> +
> > >> + aliases {
> > >> + ethernet0 = &EMAC0; /* needed for BSP u-boot */
> > >> + };
> > >> +
> > >> + cpus {
> > >> + #address-cells = <1>;
> > >> + #size-cells = <0>;
> > >> +
> > >> + CPU0: cpu@0 {
> > >> + device_type = "cpu";
> > >> + model = "PowerPC,apm82181";
> > >
> > > This doesn't match the existing bluestone dts file.
> > >
> > > Please separate any restructuring from changes.
> >
> >
> > "I see" (I'm including your comment of the dt-binding as well).
> >
> > I'm getting the vibe that I better should not touch that bluestone.dts.
>
> I don't know about that.
k, understood.
>
> > An honestly, looking at the series and patches that the APM-engineers
> > posted back in the day, I can see why this well is so poisoned... and
> > stuff like SATA/AHBDMA/USB/GPIO/CPM/... was missing.
> >
> > As for the devices. In the spirit of Arnd Bergmann's post of
> > <https://lkml.org/lkml/2020/3/30/195>
> >
> > |It would be nice to move over the the bluestone .dts to the apm82181.dtsi file
> > |when that gets added, if only to ensure they use the same description for each
> > |node, but that shouldn't stop the addition of the new file if that is needed for
> > |distros to make use of a popular device.
> > |I see a couple of additional files in openwrt.
> >
> > I mean I don't have the bluestone dev board, just the consumer devices.
>
> This stuff is old enough, I'd guess no one cares about a dev board.
> But we should figure that out and document that with any changes.
>
> > Would it be possible to support those? I can start from a "skeleton" apm82181.dtsi
> > This would just include CPU, Memory (SD-RAM+L2C+OCM), UIC (Interrupt-Controller),
> > the PLB+OBP+EBC Busses and UART. Just enough to make a board "boot from ram".
>
> This skeleton would be chunks moved over or duplicated? I don't think
> we want 2 of the same thing.
My Idea was copying the working apm82181.dtsi we have in OpenWrt
and stripping the nodes we added for SATA, USB, GPIO and the likes.
so the remaining nodes would be very close to what bluestone.dts had.
The main differences would be:
- It's a bit smaller since I made a separate patch for the NOR/NAND on the EBC.
Reason being that the SoC uses glue-logic for mapping NOR/NAND (and other
external peripherals like the GPIOs on the WD) into the memory and I thought
this needed some explanation as to why this weird thing works.
- it would already use the dt-bindings/interrupt-controller/irq.h macros
for LEVEL/EDGE cell values
- it contains valuable comments about the uboot. Because ethernet0 alias
and the /plb/obc/ebc node-name requirements).
- UART are using 16750 compatible (as per hardware docs)
>
> The order I would go is split into an apm82181.dtsi with 0 changes to
> the built dtb(s). Then make changes/additions you need. As far as
> changes to existing bindings, it's only an ABI if someone notices.
This will rewriting the history, as the development of apm82181.dtsi
did happen differently (basically, each device started with its own full dts.
But early on in 2016 we merged the common nodes and switched over
to the macros). This is fine though, I'll need some time to rebase and rewrite
the patches.
(Note: I've already wrote a patch for a the apm82181 dwc USB binding for
this: <https://www.spinics.net/lists/devicetree/msg378884.html>. Not sure
about uic, sata and dw-dma as these drivers each use a common binding.
I hope there's some leeway for this old stuff.)
Cheers,
Christian
^ permalink raw reply
* Re: [PATCH] rpadlpar_io:Add MODULE_DESCRIPTION entries to kernel modules
From: Oliver O'Halloran @ 2020-09-27 23:32 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Tyrel Datwyler, linux-pci, Linux Kernel Mailing List,
Mamatha Inamdar, Bjorn Helgaas, linuxppc-dev
In-Reply-To: <20200925194335.GA2453596@bjorn-Precision-5520>
On Sat, Sep 26, 2020 at 5:43 AM Bjorn Helgaas <helgaas@kernel.org> wrote:
>
> On Thu, Sep 24, 2020 at 04:41:39PM +1000, Oliver O'Halloran wrote:
> > On Thu, Sep 24, 2020 at 3:15 PM Mamatha Inamdar
> > <mamatha4@linux.vnet.ibm.com> wrote:
> > >
> > > This patch adds a brief MODULE_DESCRIPTION to rpadlpar_io kernel modules
> > > (descriptions taken from Kconfig file)
> > >
> > > Signed-off-by: Mamatha Inamdar <mamatha4@linux.vnet.ibm.com>
> > > ---
> > > drivers/pci/hotplug/rpadlpar_core.c | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/drivers/pci/hotplug/rpadlpar_core.c b/drivers/pci/hotplug/rpadlpar_core.c
> > > index f979b70..bac65ed 100644
> > > --- a/drivers/pci/hotplug/rpadlpar_core.c
> > > +++ b/drivers/pci/hotplug/rpadlpar_core.c
> > > @@ -478,3 +478,4 @@ static void __exit rpadlpar_io_exit(void)
> > > module_init(rpadlpar_io_init);
> > > module_exit(rpadlpar_io_exit);
> > > MODULE_LICENSE("GPL");
> > > +MODULE_DESCRIPTION("RPA Dynamic Logical Partitioning driver for I/O slots");
> >
> > RPA as a spec was superseded by PAPR in the early 2000s. Can we rename
> > this already?
> >
> > The only potential problem I can see is scripts doing: modprobe
> > rpadlpar_io or similar
> >
> > However, we should be able to fix that with a module alias.
>
> Is MODULE_DESCRIPTION() connected with how modprobe works?
I don't think so. The description is just there as an FYI.
> If this patch just improves documentation, without breaking users of
> modprobe, I'm fine with it, even if it would be nice to rename to PAPR
> or something in the future.
Right, the change in this patch is just a documentation fix and
shouldn't cause any problems.
I was suggesting renaming the module itself since the term "RPA" is
only used in this hotplug driver and some of the corresponding PHB add
/ remove handling in arch/powerpc/platforms/pseries/. We can make that
change in a follow up though.
> But, please use "git log --oneline drivers/pci/hotplug/rpadlpar*" and
> match the style, and also look through the rest of drivers/pci/ to see
> if we should do the same thing to any other modules.
>
> Bjorn
^ permalink raw reply
* Re: [PATCH] tpm: of: avoid __va() translation for event log address
From: Jarkko Sakkinen @ 2020-09-27 23:44 UTC (permalink / raw)
To: Jason Gunthorpe, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras
Cc: linux-integrity, linuxppc-dev, Ard Biesheuvel, Peter Huewe,
Linux Kernel Mailing List
In-Reply-To: <20200925120018.GH9916@ziepe.ca>
On Fri, Sep 25, 2020 at 09:00:18AM -0300, Jason Gunthorpe wrote:
> On Fri, Sep 25, 2020 at 01:29:20PM +0300, Jarkko Sakkinen wrote:
> > On Fri, Sep 25, 2020 at 09:00:56AM +0200, Ard Biesheuvel wrote:
> > > On Fri, 25 Sep 2020 at 07:56, Jarkko Sakkinen
> > > <jarkko.sakkinen@linux.intel.com> wrote:
> > > >
> > > > On Tue, Sep 22, 2020 at 11:41:28AM +0200, Ard Biesheuvel wrote:
> > > > > The TPM event log is provided to the OS by the firmware, by loading
> > > > > it into an area in memory and passing the physical address via a node
> > > > > in the device tree.
> > > > >
> > > > > Currently, we use __va() to access the memory via the kernel's linear
> > > > > map: however, it is not guaranteed that the linear map covers this
> > > > > particular address, as we may be running under HIGHMEM on a 32-bit
> > > > > architecture, or running firmware that uses a memory type for the
> > > > > event log that is omitted from the linear map (such as EfiReserved).
> > > >
> > > > Makes perfect sense to the level that I wonder if this should have a
> > > > fixes tag and/or needs to be backported to the stable kernels?
> > > >
> > >
> > > AIUI, the code was written specifically for ppc64, which is a
> > > non-highmem, non-EFI architecture. However, when we start reusing this
> > > driver for ARM, this issue could pop up.
> > >
> > > The code itself has been refactored a couple of times, so I think it
> > > will require different versions of the patch for different generations
> > > of stable kernels.
> > >
> > > So perhaps just add Cc: <stable@vger.kernel.org>, and wait and see how
> > > far back it applies cleanly?
> >
> > Yeah, I think I'll cc it with some note before the diffstat.
> >
> > I'm thinking to cap it to only 5.x kernels (at least first) unless it is
> > dead easy to backport below that.
>
> I have this vauge recollection of pointing at this before and being
> told that it had to be __va for some PPC reason?
>
> Do check with the PPC people first, I see none on the CC list.
>
> Jason
Thanks, added arch/powerpc maintainers.
/Jarkko
^ permalink raw reply
* Re: [PATCH -next] ocxl: simplify the return expression of free_function_dev()
From: Andrew Donnellan @ 2020-09-28 1:24 UTC (permalink / raw)
To: Qinglang Miao, Frederic Barrat, Arnd Bergmann, Greg Kroah-Hartman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20200921131047.92526-1-miaoqinglang@huawei.com>
On 21/9/20 11:10 pm, Qinglang Miao wrote:
> Simplify the return expression.
>
> Signed-off-by: Qinglang Miao <miaoqinglang@huawei.com>
Looks good
Acked-by: Andrew Donnellan <ajd@linux.ibm.com>
--
Andrew Donnellan OzLabs, ADL Canberra
ajd@linux.ibm.com IBM Australia Limited
^ permalink raw reply
* Re: [PATCH] tpm: of: avoid __va() translation for event log address
From: Christophe Leroy @ 2020-09-28 5:56 UTC (permalink / raw)
To: Jarkko Sakkinen, Jason Gunthorpe, Michael Ellerman,
Benjamin Herrenschmidt, Paul Mackerras
Cc: linux-integrity, linuxppc-dev, Ard Biesheuvel, Peter Huewe,
Linux Kernel Mailing List
In-Reply-To: <20200927234434.GA5283@linux.intel.com>
Le 28/09/2020 à 01:44, Jarkko Sakkinen a écrit :
> On Fri, Sep 25, 2020 at 09:00:18AM -0300, Jason Gunthorpe wrote:
>> On Fri, Sep 25, 2020 at 01:29:20PM +0300, Jarkko Sakkinen wrote:
>>> On Fri, Sep 25, 2020 at 09:00:56AM +0200, Ard Biesheuvel wrote:
>>>> On Fri, 25 Sep 2020 at 07:56, Jarkko Sakkinen
>>>> <jarkko.sakkinen@linux.intel.com> wrote:
>>>>>
>>>>> On Tue, Sep 22, 2020 at 11:41:28AM +0200, Ard Biesheuvel wrote:
>>>>>> The TPM event log is provided to the OS by the firmware, by loading
>>>>>> it into an area in memory and passing the physical address via a node
>>>>>> in the device tree.
>>>>>>
>>>>>> Currently, we use __va() to access the memory via the kernel's linear
>>>>>> map: however, it is not guaranteed that the linear map covers this
>>>>>> particular address, as we may be running under HIGHMEM on a 32-bit
>>>>>> architecture, or running firmware that uses a memory type for the
>>>>>> event log that is omitted from the linear map (such as EfiReserved).
>>>>>
>>>>> Makes perfect sense to the level that I wonder if this should have a
>>>>> fixes tag and/or needs to be backported to the stable kernels?
>>>>>
>>>>
>>>> AIUI, the code was written specifically for ppc64, which is a
>>>> non-highmem, non-EFI architecture. However, when we start reusing this
>>>> driver for ARM, this issue could pop up.
>>>>
>>>> The code itself has been refactored a couple of times, so I think it
>>>> will require different versions of the patch for different generations
>>>> of stable kernels.
>>>>
>>>> So perhaps just add Cc: <stable@vger.kernel.org>, and wait and see how
>>>> far back it applies cleanly?
>>>
>>> Yeah, I think I'll cc it with some note before the diffstat.
>>>
>>> I'm thinking to cap it to only 5.x kernels (at least first) unless it is
>>> dead easy to backport below that.
>>
>> I have this vauge recollection of pointing at this before and being
>> told that it had to be __va for some PPC reason?
>>
>> Do check with the PPC people first, I see none on the CC list.
>>
>> Jason
>
> Thanks, added arch/powerpc maintainers.
>
As far as I can see, memremap() won't work on PPC32 at least:
IIUC, memremap() calls arch_memremap_wb()
arch_memremap_wb() calls ioremap_cache()
In case of failure, then ioremap_wt() and ioremap_wc() are tried.
All ioremap calls end up in __ioremap_caller() which will return NULL in case you try to ioremap RAM.
So the statement "So instead, use memremap(), which will reuse the linear mapping if
it is valid, or create another mapping otherwise." seems to be wrong, at least for PPC32.
Even for PPC64 which doesn't seem to have the RAM check, I can't see that it will "reuse the linear
mapping".
Christophe
^ permalink raw reply
* Re: [PATCH] tpm: of: avoid __va() translation for event log address
From: Ard Biesheuvel @ 2020-09-28 6:20 UTC (permalink / raw)
To: Christophe Leroy
Cc: Linux Kernel Mailing List, Jarkko Sakkinen, Jason Gunthorpe,
Paul Mackerras, linux-integrity,
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT), Peter Huewe
In-Reply-To: <9be9c7e7-c424-d241-2255-ad854221bd2e@csgroup.eu>
On Mon, 28 Sep 2020 at 07:56, Christophe Leroy
<christophe.leroy@csgroup.eu> wrote:
>
>
>
> Le 28/09/2020 à 01:44, Jarkko Sakkinen a écrit :
> > On Fri, Sep 25, 2020 at 09:00:18AM -0300, Jason Gunthorpe wrote:
> >> On Fri, Sep 25, 2020 at 01:29:20PM +0300, Jarkko Sakkinen wrote:
> >>> On Fri, Sep 25, 2020 at 09:00:56AM +0200, Ard Biesheuvel wrote:
> >>>> On Fri, 25 Sep 2020 at 07:56, Jarkko Sakkinen
> >>>> <jarkko.sakkinen@linux.intel.com> wrote:
> >>>>>
> >>>>> On Tue, Sep 22, 2020 at 11:41:28AM +0200, Ard Biesheuvel wrote:
> >>>>>> The TPM event log is provided to the OS by the firmware, by loading
> >>>>>> it into an area in memory and passing the physical address via a node
> >>>>>> in the device tree.
> >>>>>>
> >>>>>> Currently, we use __va() to access the memory via the kernel's linear
> >>>>>> map: however, it is not guaranteed that the linear map covers this
> >>>>>> particular address, as we may be running under HIGHMEM on a 32-bit
> >>>>>> architecture, or running firmware that uses a memory type for the
> >>>>>> event log that is omitted from the linear map (such as EfiReserved).
> >>>>>
> >>>>> Makes perfect sense to the level that I wonder if this should have a
> >>>>> fixes tag and/or needs to be backported to the stable kernels?
> >>>>>
> >>>>
> >>>> AIUI, the code was written specifically for ppc64, which is a
> >>>> non-highmem, non-EFI architecture. However, when we start reusing this
> >>>> driver for ARM, this issue could pop up.
> >>>>
> >>>> The code itself has been refactored a couple of times, so I think it
> >>>> will require different versions of the patch for different generations
> >>>> of stable kernels.
> >>>>
> >>>> So perhaps just add Cc: <stable@vger.kernel.org>, and wait and see how
> >>>> far back it applies cleanly?
> >>>
> >>> Yeah, I think I'll cc it with some note before the diffstat.
> >>>
> >>> I'm thinking to cap it to only 5.x kernels (at least first) unless it is
> >>> dead easy to backport below that.
> >>
> >> I have this vauge recollection of pointing at this before and being
> >> told that it had to be __va for some PPC reason?
> >>
> >> Do check with the PPC people first, I see none on the CC list.
> >>
> >> Jason
> >
> > Thanks, added arch/powerpc maintainers.
> >
>
> As far as I can see, memremap() won't work on PPC32 at least:
>
> IIUC, memremap() calls arch_memremap_wb()
> arch_memremap_wb() calls ioremap_cache()
> In case of failure, then ioremap_wt() and ioremap_wc() are tried.
>
> All ioremap calls end up in __ioremap_caller() which will return NULL in case you try to ioremap RAM.
>
> So the statement "So instead, use memremap(), which will reuse the linear mapping if
> it is valid, or create another mapping otherwise." seems to be wrong, at least for PPC32.
>
> Even for PPC64 which doesn't seem to have the RAM check, I can't see that it will "reuse the linear
> mapping".
>
It is there, please look again. Before any of the above happens,
memremap() will call try_ram_remap() for regions that are covered by a
IORESOURCE_SYSTEM_RAM, and map it using __va() if its PFN is valid and
it is not highmem.
So as far as I can tell, this change has no effect on PPC at all
unless its RAM is not described as IORESOURCE_SYSTEM_RAM.
^ permalink raw reply
* [PATCH] powerpc: net: bpf_jit_comp: Fix misuse of fallthrough
From: zhe.he @ 2020-09-28 9:00 UTC (permalink / raw)
To: gustavo, netdev, bpf, linuxppc-dev, linux-kernel, zhe.he
From: He Zhe <zhe.he@windriver.com>
The user defined label following "fallthrough" is not considered by GCC
and causes build failure.
kernel-source/include/linux/compiler_attributes.h:208:41: error: attribute
'fallthrough' not preceding a case label or default label [-Werror]
208 define fallthrough _attribute((fallthrough_))
^~~~~~~~~~~~~
Signed-off-by: He Zhe <zhe.he@windriver.com>
---
arch/powerpc/net/bpf_jit_comp.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/powerpc/net/bpf_jit_comp.c b/arch/powerpc/net/bpf_jit_comp.c
index 78d61f97371e..e809cb5a1631 100644
--- a/arch/powerpc/net/bpf_jit_comp.c
+++ b/arch/powerpc/net/bpf_jit_comp.c
@@ -475,7 +475,6 @@ static int bpf_jit_build_body(struct bpf_prog *fp, u32 *image,
case BPF_JMP | BPF_JSET | BPF_K:
case BPF_JMP | BPF_JSET | BPF_X:
true_cond = COND_NE;
- fallthrough;
cond_branch:
/* same targets, can avoid doing the test :) */
if (filter[i].jt == filter[i].jf) {
--
2.26.2
^ permalink raw reply related
* Re: [PATCH] powerpc/papr_scm: Add PAPR command family to pass-through command-set
From: Vaibhav Jain @ 2020-09-28 13:14 UTC (permalink / raw)
To: linuxppc-dev, linux-nvdimm
Cc: Santosh Sivaraj, Aneesh Kumar K . V, Verma, Vishal L,
Oliver O'Halloran, Dan Williams, Ira Weiny
In-Reply-To: <20200913211904.24472-1-vaibhav@linux.ibm.com>
Hi Dan, Ira and Vishal,
Can you please take a look at this patch. Without it the functionality
to report nvdimm health via ndctl breaks on 5.9
Thanks,
~ Vaibhav
Vaibhav Jain <vaibhav@linux.ibm.com> writes:
> Add NVDIMM_FAMILY_PAPR to the list of valid 'dimm_family_mask'
> acceptable by papr_scm. This is needed as since commit
> 92fe2aa859f5 ("libnvdimm: Validate command family indices") libnvdimm
> performs a validation of 'nd_cmd_pkg.nd_family' received as part of
> ND_CMD_CALL processing to ensure only known command families can use
> the general ND_CMD_CALL pass-through functionality.
>
> Without this change the ND_CMD_CALL pass-through targeting
> NVDIMM_FAMILY_PAPR error out with -EINVAL.
>
> Fixes: 92fe2aa859f5 ("libnvdimm: Validate command family indices")
> Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
> ---
> arch/powerpc/platforms/pseries/papr_scm.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/powerpc/platforms/pseries/papr_scm.c b/arch/powerpc/platforms/pseries/papr_scm.c
> index 5493bc847bd08..27268370dee00 100644
> --- a/arch/powerpc/platforms/pseries/papr_scm.c
> +++ b/arch/powerpc/platforms/pseries/papr_scm.c
> @@ -898,6 +898,9 @@ static int papr_scm_nvdimm_init(struct papr_scm_priv *p)
> p->bus_desc.of_node = p->pdev->dev.of_node;
> p->bus_desc.provider_name = kstrdup(p->pdev->name, GFP_KERNEL);
>
> + /* Set the dimm command family mask to accept PDSMs */
> + set_bit(NVDIMM_FAMILY_PAPR, &p->bus_desc.dimm_family_mask);
> +
> if (!p->bus_desc.provider_name)
> return -ENOMEM;
>
> --
> 2.26.2
>
^ permalink raw reply
* Re: [PATCH 1/5] Documentation: dt: binding: fsl: Add 'fsl,ippdexpcr1-alt-addr' property
From: Rob Herring @ 2020-09-28 13:56 UTC (permalink / raw)
To: Ran Wang
Cc: devicetree@vger.kernel.org, Biwen Li, Shawn Guo,
linux-kernel@vger.kernel.org, Leo Li,
linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <AM6PR04MB5413BB2F8D044B2312DAEC4FF1380@AM6PR04MB5413.eurprd04.prod.outlook.com>
On Wed, Sep 23, 2020 at 1:44 AM Ran Wang <ran.wang_1@nxp.com> wrote:
>
> Hi Rob,
>
> On Wednesday, September 23, 2020 10:33 AM, Rob Herring wrote:
> >
> > On Wed, Sep 16, 2020 at 04:18:27PM +0800, Ran Wang wrote:
> > > From: Biwen Li <biwen.li@nxp.com>
> > >
> > > The 'fsl,ippdexpcr1-alt-addr' property is used to handle an errata
> > > A-008646 on LS1021A
> > >
> > > Signed-off-by: Biwen Li <biwen.li@nxp.com>
> > > Signed-off-by: Ran Wang <ran.wang_1@nxp.com>
> > > ---
> > > Documentation/devicetree/bindings/soc/fsl/rcpm.txt | 19
> > > +++++++++++++++++++
> > > 1 file changed, 19 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > > b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > > index 5a33619..1be58a3 100644
> > > --- a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > > +++ b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > > @@ -34,6 +34,11 @@ Chassis Version Example Chips
> > > Optional properties:
> > > - little-endian : RCPM register block is Little Endian. Without it RCPM
> > > will be Big Endian (default case).
> > > + - fsl,ippdexpcr1-alt-addr : The property is related to a hardware issue
> > > + on SoC LS1021A and only needed on SoC LS1021A.
> > > + Must include 2 entries:
> > > + The first entry must be a link to the SCFG device node.
> > > + The 2nd entry must be offset of register IPPDEXPCR1 in SCFG.
> >
> > You don't need a DT change for this. You can find SCFG node by its compatible
> > string and then the offset should be known given this issue is only on 1 SoC.
>
> Did you mean that RCPM driver just to access IPPDEXPCR1 shadowed register in SCFG
> directly without fetching it's offset info. from DT?
Yes. There's only 1 possible value of the offset because there's only
one SoC, so the driver can hardcode the offset. And I assume there's
only one SCFG node, so you can find it by its compatible string
(of_find_compatible_node).
Rob
^ permalink raw reply
* Re: [PATCH] tpm: of: avoid __va() translation for event log address
From: Jarkko Sakkinen @ 2020-09-28 14:09 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Linux Kernel Mailing List, Jason Gunthorpe, Paul Mackerras,
linux-integrity, open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
Peter Huewe
In-Reply-To: <CAMj1kXGxNgixUEocma-9F3fYgdJJJADh=bvyrCziXkuArErWdA@mail.gmail.com>
On Mon, Sep 28, 2020 at 08:20:18AM +0200, Ard Biesheuvel wrote:
> On Mon, 28 Sep 2020 at 07:56, Christophe Leroy
> <christophe.leroy@csgroup.eu> wrote:
> >
> >
> >
> > Le 28/09/2020 à 01:44, Jarkko Sakkinen a écrit :
> > > On Fri, Sep 25, 2020 at 09:00:18AM -0300, Jason Gunthorpe wrote:
> > >> On Fri, Sep 25, 2020 at 01:29:20PM +0300, Jarkko Sakkinen wrote:
> > >>> On Fri, Sep 25, 2020 at 09:00:56AM +0200, Ard Biesheuvel wrote:
> > >>>> On Fri, 25 Sep 2020 at 07:56, Jarkko Sakkinen
> > >>>> <jarkko.sakkinen@linux.intel.com> wrote:
> > >>>>>
> > >>>>> On Tue, Sep 22, 2020 at 11:41:28AM +0200, Ard Biesheuvel wrote:
> > >>>>>> The TPM event log is provided to the OS by the firmware, by loading
> > >>>>>> it into an area in memory and passing the physical address via a node
> > >>>>>> in the device tree.
> > >>>>>>
> > >>>>>> Currently, we use __va() to access the memory via the kernel's linear
> > >>>>>> map: however, it is not guaranteed that the linear map covers this
> > >>>>>> particular address, as we may be running under HIGHMEM on a 32-bit
> > >>>>>> architecture, or running firmware that uses a memory type for the
> > >>>>>> event log that is omitted from the linear map (such as EfiReserved).
> > >>>>>
> > >>>>> Makes perfect sense to the level that I wonder if this should have a
> > >>>>> fixes tag and/or needs to be backported to the stable kernels?
> > >>>>>
> > >>>>
> > >>>> AIUI, the code was written specifically for ppc64, which is a
> > >>>> non-highmem, non-EFI architecture. However, when we start reusing this
> > >>>> driver for ARM, this issue could pop up.
> > >>>>
> > >>>> The code itself has been refactored a couple of times, so I think it
> > >>>> will require different versions of the patch for different generations
> > >>>> of stable kernels.
> > >>>>
> > >>>> So perhaps just add Cc: <stable@vger.kernel.org>, and wait and see how
> > >>>> far back it applies cleanly?
> > >>>
> > >>> Yeah, I think I'll cc it with some note before the diffstat.
> > >>>
> > >>> I'm thinking to cap it to only 5.x kernels (at least first) unless it is
> > >>> dead easy to backport below that.
> > >>
> > >> I have this vauge recollection of pointing at this before and being
> > >> told that it had to be __va for some PPC reason?
> > >>
> > >> Do check with the PPC people first, I see none on the CC list.
> > >>
> > >> Jason
> > >
> > > Thanks, added arch/powerpc maintainers.
> > >
> >
> > As far as I can see, memremap() won't work on PPC32 at least:
> >
> > IIUC, memremap() calls arch_memremap_wb()
> > arch_memremap_wb() calls ioremap_cache()
> > In case of failure, then ioremap_wt() and ioremap_wc() are tried.
> >
> > All ioremap calls end up in __ioremap_caller() which will return NULL in case you try to ioremap RAM.
> >
> > So the statement "So instead, use memremap(), which will reuse the linear mapping if
> > it is valid, or create another mapping otherwise." seems to be wrong, at least for PPC32.
> >
> > Even for PPC64 which doesn't seem to have the RAM check, I can't see that it will "reuse the linear
> > mapping".
> >
>
> It is there, please look again. Before any of the above happens,
> memremap() will call try_ram_remap() for regions that are covered by a
> IORESOURCE_SYSTEM_RAM, and map it using __va() if its PFN is valid and
> it is not highmem.
>
> So as far as I can tell, this change has no effect on PPC at all
> unless its RAM is not described as IORESOURCE_SYSTEM_RAM.
Any chance for someone to test this on PPC32?
/Jarkko
^ permalink raw reply
* Re: [PATCH v8 2/8] powerpc/vdso: Remove __kernel_datapage_offset and simplify __get_datapage()
From: Dmitry Safonov @ 2020-09-28 15:08 UTC (permalink / raw)
To: Christophe Leroy, Will Deacon, Michael Ellerman
Cc: nathanl, linux-arch, Arnd Bergmann, open list, Paul Mackerras,
Andy Lutomirski, Thomas Gleixner, Vincenzo Frascino, linuxppc-dev
In-Reply-To: <ad72ffd3-a552-cc98-7545-d30285fd5219@csgroup.eu>
On 9/27/20 8:43 AM, Christophe Leroy wrote:
>
>
> Le 21/09/2020 à 13:26, Will Deacon a écrit :
>> On Fri, Aug 28, 2020 at 12:14:28PM +1000, Michael Ellerman wrote:
>>> Dmitry Safonov <0x7f454c46@gmail.com> writes:
[..]
>>>> I'll cook a patch for vm_special_mapping if you don't mind :-)
>>>
>>> That would be great, thanks!
>>
>> I lost track of this one. Is there a patch kicking around to resolve
>> this,
>> or is the segfault expected behaviour?
>>
>
> IIUC dmitry said he will cook a patch. I have not seen any patch yet.
Yes, sorry about the delay - I was a bit busy with xfrm patches.
I'll send patches for .close() this week, working on them now.
> AFAIKS, among the architectures having VDSO sigreturn trampolines, only
> SH, X86 and POWERPC provide alternative trampoline on stack when VDSO is
> not there.
>
> All other architectures just having a VDSO don't expect VDSO to not be
> mapped.
>
> As far as nowadays stacks are mapped non-executable, getting a segfaut
> is expected behaviour. However, I think we should really make it
> cleaner. Today it segfaults because it is still pointing to the VDSO
> trampoline that has been unmapped. But should the user map some other
> code at the same address, we'll run in the weed on signal return instead
> of segfaulting.
+1.
> So VDSO unmapping should really be properly managed, the reference
> should be properly cleared in order to segfault in a controllable manner.
>
> Only powerpc has a hook to properly clear the VDSO pointer when VDSO is
> unmapped.
Thanks,
Dmitry
^ permalink raw reply
* Re: [PATCH] powerpc/papr_scm: Add PAPR command family to pass-through command-set
From: Ira Weiny @ 2020-09-28 15:45 UTC (permalink / raw)
To: Vaibhav Jain
Cc: Santosh Sivaraj, linux-nvdimm, Aneesh Kumar K . V,
Verma, Vishal L, Oliver O'Halloran, Dan Williams,
linuxppc-dev
In-Reply-To: <87pn662gc3.fsf@vajain21.in.ibm.com>
On Mon, Sep 28, 2020 at 06:44:52PM +0530, Vaibhav Jain wrote:
> Hi Dan, Ira and Vishal,
>
> Can you please take a look at this patch. Without it the functionality
> to report nvdimm health via ndctl breaks on 5.9
Sorry...
>
> Thanks,
> ~ Vaibhav
>
> Vaibhav Jain <vaibhav@linux.ibm.com> writes:
>
> > Add NVDIMM_FAMILY_PAPR to the list of valid 'dimm_family_mask'
> > acceptable by papr_scm. This is needed as since commit
> > 92fe2aa859f5 ("libnvdimm: Validate command family indices") libnvdimm
> > performs a validation of 'nd_cmd_pkg.nd_family' received as part of
> > ND_CMD_CALL processing to ensure only known command families can use
> > the general ND_CMD_CALL pass-through functionality.
> >
> > Without this change the ND_CMD_CALL pass-through targeting
> > NVDIMM_FAMILY_PAPR error out with -EINVAL.
> >
> > Fixes: 92fe2aa859f5 ("libnvdimm: Validate command family indices")
> > Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
LGTM
Reviewed-by: Ira Weiny <ira.weiny@intel.com>
> > ---
> > arch/powerpc/platforms/pseries/papr_scm.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/arch/powerpc/platforms/pseries/papr_scm.c b/arch/powerpc/platforms/pseries/papr_scm.c
> > index 5493bc847bd08..27268370dee00 100644
> > --- a/arch/powerpc/platforms/pseries/papr_scm.c
> > +++ b/arch/powerpc/platforms/pseries/papr_scm.c
> > @@ -898,6 +898,9 @@ static int papr_scm_nvdimm_init(struct papr_scm_priv *p)
> > p->bus_desc.of_node = p->pdev->dev.of_node;
> > p->bus_desc.provider_name = kstrdup(p->pdev->name, GFP_KERNEL);
> >
> > + /* Set the dimm command family mask to accept PDSMs */
> > + set_bit(NVDIMM_FAMILY_PAPR, &p->bus_desc.dimm_family_mask);
> > +
> > if (!p->bus_desc.provider_name)
> > return -ENOMEM;
> >
> > --
> > 2.26.2
> >
^ permalink raw reply
* Re: [PATCH] powerpc/papr_scm: Support dynamic enable/disable of performance statistics
From: Ira Weiny @ 2020-09-28 16:04 UTC (permalink / raw)
To: Vaibhav Jain
Cc: Santosh Sivaraj, linux-nvdimm, Aneesh Kumar K . V,
Oliver O'Halloran, Dan Williams, linuxppc-dev
In-Reply-To: <20200913212115.24958-1-vaibhav@linux.ibm.com>
On Mon, Sep 14, 2020 at 02:51:15AM +0530, Vaibhav Jain wrote:
> Collection of performance statistics of an NVDIMM can be dynamically
> enabled/disabled from the Hypervisor Management Console even when the
> guest lpar is running. The current implementation however will check if
> the performance statistics collection is supported during NVDIMM probe
> and if yes will assume that to be the case afterwards.
>
> Hence we update papr_scm to remove this assumption from the code by
> eliminating the 'stat_buffer_len' member from 'struct papr_scm_priv'
> that was used to cache the max buffer size needed to fetch NVDIMM
> performance stats from PHYP. With that struct member gone, various
> functions that depended on it are updated. Specifically
> perf_stats_show() is updated to query the PHYP first for the size of
> buffer needed to hold all performance statistics instead of relying on
> 'stat_buffer_len'
>
> Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
> ---
> arch/powerpc/platforms/pseries/papr_scm.c | 53 +++++++++++------------
> 1 file changed, 25 insertions(+), 28 deletions(-)
>
> diff --git a/arch/powerpc/platforms/pseries/papr_scm.c b/arch/powerpc/platforms/pseries/papr_scm.c
> index 27268370dee00..6697e1c3b9ebe 100644
> --- a/arch/powerpc/platforms/pseries/papr_scm.c
> +++ b/arch/powerpc/platforms/pseries/papr_scm.c
> @@ -112,9 +112,6 @@ struct papr_scm_priv {
>
> /* Health information for the dimm */
> u64 health_bitmap;
> -
> - /* length of the stat buffer as expected by phyp */
> - size_t stat_buffer_len;
> };
>
> static LIST_HEAD(papr_nd_regions);
> @@ -230,14 +227,15 @@ static int drc_pmem_query_n_bind(struct papr_scm_priv *p)
> * - If buff_stats == NULL the return value is the size in byes of the buffer
> * needed to hold all supported performance-statistics.
> * - If buff_stats != NULL and num_stats == 0 then we copy all known
> - * performance-statistics to 'buff_stat' and expect to be large enough to
> - * hold them.
> + * performance-statistics to 'buff_stat' and expect it to be large enough to
> + * hold them. The 'buff_size' args contains the size of the 'buff_stats'
> * - if buff_stats != NULL and num_stats > 0 then copy the requested
> * performance-statistics to buff_stats.
> */
> static ssize_t drc_pmem_query_stats(struct papr_scm_priv *p,
> struct papr_scm_perf_stats *buff_stats,
> - unsigned int num_stats)
> + unsigned int num_stats,
> + size_t buff_size)
> {
> unsigned long ret[PLPAR_HCALL_BUFSIZE];
> size_t size;
> @@ -261,12 +259,18 @@ static ssize_t drc_pmem_query_stats(struct papr_scm_priv *p,
> size = sizeof(struct papr_scm_perf_stats) +
> num_stats * sizeof(struct papr_scm_perf_stat);
> else
> - size = p->stat_buffer_len;
> + size = buff_size;
> } else {
> /* In case of no out buffer ignore the size */
> size = 0;
> }
>
> + /* verify that the buffer size needed is sufficient */
> + if (size > buff_size) {
> + __WARN();
> + return -EINVAL;
> + }
> +
> /* Do the HCALL asking PHYP for info */
> rc = plpar_hcall(H_SCM_PERFORMANCE_STATS, ret, p->drc_index,
> buff_stats ? virt_to_phys(buff_stats) : 0,
> @@ -277,6 +281,10 @@ static ssize_t drc_pmem_query_stats(struct papr_scm_priv *p,
> dev_err(&p->pdev->dev,
> "Unknown performance stats, Err:0x%016lX\n", ret[0]);
> return -ENOENT;
> + } else if (rc == H_AUTHORITY) {
> + dev_dbg(&p->pdev->dev,
> + "Performance stats in-accessible\n");
> + return -EPERM;
> } else if (rc != H_SUCCESS) {
> dev_err(&p->pdev->dev,
> "Failed to query performance stats, Err:%lld\n", rc);
> @@ -526,10 +534,6 @@ static int papr_pdsm_fuel_gauge(struct papr_scm_priv *p,
> struct papr_scm_perf_stat *stat;
> struct papr_scm_perf_stats *stats;
>
> - /* Silently fail if fetching performance metrics isn't supported */
> - if (!p->stat_buffer_len)
> - return 0;
> -
> /* Allocate request buffer enough to hold single performance stat */
> size = sizeof(struct papr_scm_perf_stats) +
> sizeof(struct papr_scm_perf_stat);
> @@ -543,9 +547,11 @@ static int papr_pdsm_fuel_gauge(struct papr_scm_priv *p,
> stat->stat_val = 0;
>
> /* Fetch the fuel gauge and populate it in payload */
> - rc = drc_pmem_query_stats(p, stats, 1);
> + rc = drc_pmem_query_stats(p, stats, 1, size);
> if (rc < 0) {
> dev_dbg(&p->pdev->dev, "Err(%d) fetching fuel gauge\n", rc);
> + /* Silently fail if unable to fetch performance metric */
> + rc = 0;
> goto free_stats;
> }
>
> @@ -786,23 +792,25 @@ static ssize_t perf_stats_show(struct device *dev,
> struct device_attribute *attr, char *buf)
> {
> int index;
> - ssize_t rc;
> + ssize_t rc, buff_len;
> struct seq_buf s;
> struct papr_scm_perf_stat *stat;
> struct papr_scm_perf_stats *stats;
> struct nvdimm *dimm = to_nvdimm(dev);
> struct papr_scm_priv *p = nvdimm_provider_data(dimm);
>
> - if (!p->stat_buffer_len)
> - return -ENOENT;
> + /* fetch the length of buffer needed to get all stats */
> + buff_len = drc_pmem_query_stats(p, NULL, 0, 0);
> + if (buff_len <= 0)
> + return buff_len;
Generally I can't find anything wrong with this patch technically but the
architecture of drc_pmem_query_stats() seems overly complicated.
IOW, I feel like you are overloading drc_pmem_query_stats() in an odd way which
makes it and the callers code confusing. Why can't you have a separate
function which returns the max buffer length and separate out the logic within
drc_pmem_query_stats() to make it clear how to call plpar_hcall() to get this
information?
Ira
>
> /* Allocate the buffer for phyp where stats are written */
> - stats = kzalloc(p->stat_buffer_len, GFP_KERNEL);
> + stats = kzalloc(buff_len, GFP_KERNEL);
> if (!stats)
> return -ENOMEM;
>
> /* Ask phyp to return all dimm perf stats */
> - rc = drc_pmem_query_stats(p, stats, 0);
> + rc = drc_pmem_query_stats(p, stats, 0, buff_len);
> if (rc)
> goto free_stats;
> /*
> @@ -891,7 +899,6 @@ static int papr_scm_nvdimm_init(struct papr_scm_priv *p)
> struct nd_region_desc ndr_desc;
> unsigned long dimm_flags;
> int target_nid, online_nid;
> - ssize_t stat_size;
>
> p->bus_desc.ndctl = papr_scm_ndctl;
> p->bus_desc.module = THIS_MODULE;
> @@ -962,16 +969,6 @@ static int papr_scm_nvdimm_init(struct papr_scm_priv *p)
> list_add_tail(&p->region_list, &papr_nd_regions);
> mutex_unlock(&papr_ndr_lock);
>
> - /* Try retriving the stat buffer and see if its supported */
> - stat_size = drc_pmem_query_stats(p, NULL, 0);
> - if (stat_size > 0) {
> - p->stat_buffer_len = stat_size;
> - dev_dbg(&p->pdev->dev, "Max perf-stat size %lu-bytes\n",
> - p->stat_buffer_len);
> - } else {
> - dev_info(&p->pdev->dev, "Dimm performance stats unavailable\n");
> - }
> -
> return 0;
>
> err: nvdimm_bus_unregister(p->bus);
> --
> 2.26.2
>
^ permalink raw reply
* Re: [PATCH v2 2/3] lkdtm/powerpc: Add SLB multihit test
From: Ganesh @ 2020-09-28 17:32 UTC (permalink / raw)
To: Kees Cook; +Cc: msuchanek, linuxppc-dev, mahesh, npiggin
In-Reply-To: <202009251244.A4396AFF@keescook>
On 9/26/20 1:27 AM, Kees Cook wrote:
> On Fri, Sep 25, 2020 at 04:01:22PM +0530, Ganesh Goudar wrote:
>> Add support to inject slb multihit errors, to test machine
>> check handling.
> Thank you for more tests in here!
>
>> Based on work by Mahesh Salgaonkar and Michal Suchánek.
>>
>> Cc: Mahesh Salgaonkar <mahesh@linux.ibm.com>
>> Cc: Michal Suchánek <msuchanek@suse.de>
> Should these be Co-developed-by: with S-o-b?
Sure, ill add.
>> Signed-off-by: Ganesh Goudar <ganeshgr@linux.ibm.com>
>> ---
>> drivers/misc/lkdtm/Makefile | 4 ++
>> drivers/misc/lkdtm/core.c | 3 +
>> drivers/misc/lkdtm/lkdtm.h | 3 +
>> drivers/misc/lkdtm/powerpc.c | 132 +++++++++++++++++++++++++++++++++++
>> 4 files changed, 142 insertions(+)
>> create mode 100644 drivers/misc/lkdtm/powerpc.c
>>
>> diff --git a/drivers/misc/lkdtm/Makefile b/drivers/misc/lkdtm/Makefile
>> index c70b3822013f..6a82f407fbcd 100644
>> --- a/drivers/misc/lkdtm/Makefile
>> +++ b/drivers/misc/lkdtm/Makefile
>> @@ -11,6 +11,10 @@ lkdtm-$(CONFIG_LKDTM) += usercopy.o
>> lkdtm-$(CONFIG_LKDTM) += stackleak.o
>> lkdtm-$(CONFIG_LKDTM) += cfi.o
>>
>> +ifeq ($(CONFIG_PPC64),y)
>> +lkdtm-$(CONFIG_LKDTM) += powerpc.o
>> +endif
> This can just be:
>
> lkdtm-$(CONFIG_PPC64) += powerpc.o
ok
>> +
>> KASAN_SANITIZE_stackleak.o := n
>> KCOV_INSTRUMENT_rodata.o := n
>>
>> diff --git a/drivers/misc/lkdtm/core.c b/drivers/misc/lkdtm/core.c
>> index a5e344df9166..8d5db42baa90 100644
>> --- a/drivers/misc/lkdtm/core.c
>> +++ b/drivers/misc/lkdtm/core.c
>> @@ -178,6 +178,9 @@ static const struct crashtype crashtypes[] = {
>> #ifdef CONFIG_X86_32
>> CRASHTYPE(DOUBLE_FAULT),
>> #endif
>> +#ifdef CONFIG_PPC64
>> + CRASHTYPE(PPC_SLB_MULTIHIT),
>> +#endif
>> };
>>
>>
>> diff --git a/drivers/misc/lkdtm/lkdtm.h b/drivers/misc/lkdtm/lkdtm.h
>> index 8878538b2c13..b305bd511ee5 100644
>> --- a/drivers/misc/lkdtm/lkdtm.h
>> +++ b/drivers/misc/lkdtm/lkdtm.h
>> @@ -104,4 +104,7 @@ void lkdtm_STACKLEAK_ERASING(void);
>> /* cfi.c */
>> void lkdtm_CFI_FORWARD_PROTO(void);
>>
>> +/* powerpc.c */
>> +void lkdtm_PPC_SLB_MULTIHIT(void);
>> +
>> #endif
>> diff --git a/drivers/misc/lkdtm/powerpc.c b/drivers/misc/lkdtm/powerpc.c
>> new file mode 100644
>> index 000000000000..d6db18444757
>> --- /dev/null
>> +++ b/drivers/misc/lkdtm/powerpc.c
>> @@ -0,0 +1,132 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +
> Please #include "lkdtm.h" here to get the correct pr_fmt heading (and
> any future header adjustments).
Sure
>> +#include <linux/slab.h>
>> +#include <linux/vmalloc.h>
>> +
>> +static inline unsigned long get_slb_index(void)
>> +{
>> + unsigned long index;
>> +
>> + index = get_paca()->stab_rr;
>> +
>> + /*
>> + * simple round-robin replacement of slb starting at SLB_NUM_BOLTED.
>> + */
>> + if (index < (mmu_slb_size - 1))
>> + index++;
>> + else
>> + index = SLB_NUM_BOLTED;
>> + get_paca()->stab_rr = index;
>> + return index;
>> +}
>> +
>> +#define slb_esid_mask(ssize) \
>> + (((ssize) == MMU_SEGSIZE_256M) ? ESID_MASK : ESID_MASK_1T)
>> +
>> +static inline unsigned long mk_esid_data(unsigned long ea, int ssize,
>> + unsigned long slot)
>> +{
>> + return (ea & slb_esid_mask(ssize)) | SLB_ESID_V | slot;
>> +}
>> +
>> +#define slb_vsid_shift(ssize) \
>> + ((ssize) == MMU_SEGSIZE_256M ? SLB_VSID_SHIFT : SLB_VSID_SHIFT_1T)
>> +
>> +static inline unsigned long mk_vsid_data(unsigned long ea, int ssize,
>> + unsigned long flags)
>> +{
>> + return (get_kernel_vsid(ea, ssize) << slb_vsid_shift(ssize)) | flags |
>> + ((unsigned long)ssize << SLB_VSID_SSIZE_SHIFT);
>> +}
>> +
>> +static void insert_slb_entry(char *p, int ssize)
>> +{
>> + unsigned long flags, entry;
>> +
>> + flags = SLB_VSID_KERNEL | mmu_psize_defs[MMU_PAGE_64K].sllp;
>> + preempt_disable();
>> +
>> + entry = get_slb_index();
>> + asm volatile("slbmte %0,%1" :
>> + : "r" (mk_vsid_data((unsigned long)p, ssize, flags)),
>> + "r" (mk_esid_data((unsigned long)p, ssize, entry))
>> + : "memory");
>> +
>> + entry = get_slb_index();
>> + asm volatile("slbmte %0,%1" :
>> + : "r" (mk_vsid_data((unsigned long)p, ssize, flags)),
>> + "r" (mk_esid_data((unsigned long)p, ssize, entry))
>> + : "memory");
>> + preempt_enable();
>> + p[0] = '!';
>> +}
> Can you add some comments to these helpers? It'll help people (me) with
> understanding what is actually being done here (and more importantly,
> what is _expected_ to happen).
Sure, ill add comments.
>> +
>> +static void inject_vmalloc_slb_multihit(void)
>> +{
>> + char *p;
>> +
>> + p = vmalloc(2048);
>> + if (!p)
>> + return;
>> +
>> + insert_slb_entry(p, MMU_SEGSIZE_1T);
>> + vfree(p);
>> +}
>> +
>> +static void inject_kmalloc_slb_multihit(void)
>> +{
>> + char *p;
>> +
>> + p = kmalloc(2048, GFP_KERNEL);
>> + if (!p)
>> + return;
>> +
>> + insert_slb_entry(p, MMU_SEGSIZE_1T);
>> + kfree(p);
>> +}
> It looks like the expected failure injection is actually the "p[0] = '!'" line in the
> "insert" helper? I would expect pr_info/pr_err wrappers, etc, as in
> other lkdtm tests.
Yes "p[0] = '!'" is the final step in this error injection, ill add
comments.
> If this is the negative test, what does the positive test look like?
> e.g. in other lkdtm tests, first a positive test is done, then a
> negative: first run a legit function, then run a function from a bad
> location.
Yes, this is negative test, As SLB search is very fundamental thing in
address translation and
used all the time, no positive test required here.
>> +
>> +static void insert_dup_slb_entry_0(void)
>> +{
>> + unsigned long test_address = 0xC000000000000000;
>> + volatile unsigned long *test_ptr;
>> + unsigned long entry, i = 0;
>> + unsigned long esid, vsid;
>> +
>> + test_ptr = (unsigned long *)test_address;
>> + preempt_disable();
>> +
>> + asm volatile("slbmfee %0,%1" : "=r" (esid) : "r" (i));
>> + asm volatile("slbmfev %0,%1" : "=r" (vsid) : "r" (i));
>> + entry = get_slb_index();
>> +
>> + /* for i !=0 we would need to mask out the old entry number */
>> + asm volatile("slbmte %0,%1" :
>> + : "r" (vsid),
>> + "r" (esid | entry)
>> + : "memory");
>> +
>> + asm volatile("slbmfee %0,%1" : "=r" (esid) : "r" (i));
>> + asm volatile("slbmfev %0,%1" : "=r" (vsid) : "r" (i));
>> + entry = get_slb_index();
>> +
>> + /* for i !=0 we would need to mask out the old entry number */
>> + asm volatile("slbmte %0,%1" :
>> + : "r" (vsid),
>> + "r" (esid | entry)
>> + : "memory");
>> +
>> + pr_info("lkdtm: %s accessing test address 0x%lx: 0x%lx\n",
>> + __func__, test_address, *test_ptr);
>> +
>> + preempt_enable();
>> +}
> What does this do?
It tries to inject error in address range where most important kernel
data structure may fall.
Mahesh and Michal Suchánek correct me if I am wrong.
>> +
>> +void lkdtm_PPC_SLB_MULTIHIT(void)
>> +{
>> + if (mmu_has_feature(MMU_FTR_HPTE_TABLE)) {
>> + inject_vmalloc_slb_multihit();
>> + inject_kmalloc_slb_multihit();
>> + insert_dup_slb_entry_0();
>> + }
>> + pr_info("Recovered from SLB multihit. (Ignore this message on non HPTE machines)");
> Is this bad? If so, I'd expect pr_err("FAIL: ...") Can HPTE machines be
> detected so that an XFAIL can be emitted instead?
Sure, ill add XFAIL print in non HPTE case. And in case of failure we
will not return
here, so if we hit this print line we are good.
> Since there are three (two?) distinct regions being tested, should these
> be separate tests? Right now there is no way to separate a vmalloc
> failure from a kmalloc failure, and no way to fail the first without
> hiding the result from the latter (or maybe the machine cannot survive
> this test? ... which should also be a comment.)
Sure, ill comment, And yes machine cannot survive these tests in case of
failure to handle.
> And finally, assuming a successful test (or testing from a separate
> thread later), so there any state that needs to be restored (or cleaned
> up before doing the "insert" calls)?
No, there is nothing to be restored here, Thanks!
> Thanks!
>
^ permalink raw reply
* Re: [PATCH v2 3/3] selftests/lkdtm: Enable selftest for SLB multihit
From: Ganesh @ 2020-09-28 17:33 UTC (permalink / raw)
To: Kees Cook; +Cc: msuchanek, linuxppc-dev, mahesh, npiggin
In-Reply-To: <202009251257.52EAF495@keescook>
[-- Attachment #1: Type: text/plain, Size: 879 bytes --]
On 9/26/20 1:29 AM, Kees Cook wrote:
> On Fri, Sep 25, 2020 at 04:01:23PM +0530, Ganesh Goudar wrote:
>> Add PPC_SLB_MULTIHIT to lkdtm selftest framework.
>>
>> Signed-off-by: Ganesh Goudar <ganeshgr@linux.ibm.com>
>> ---
>> tools/testing/selftests/lkdtm/tests.txt | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/tools/testing/selftests/lkdtm/tests.txt b/tools/testing/selftests/lkdtm/tests.txt
>> index 9d266e79c6a2..7eb3cf91c89e 100644
>> --- a/tools/testing/selftests/lkdtm/tests.txt
>> +++ b/tools/testing/selftests/lkdtm/tests.txt
>> @@ -70,3 +70,4 @@ USERCOPY_KERNEL
>> USERCOPY_KERNEL_DS
>> STACKLEAK_ERASING OK: the rest of the thread stack is properly erased
>> CFI_FORWARD_PROTO
>> +PPC_SLB_MULTIHIT Recovered
> Please squash this into the lkdtm patch -- I'd like test implementation
> and kselftest awareness to go in together.
Sure, Thanks.
>
[-- Attachment #2: Type: text/html, Size: 1532 bytes --]
^ permalink raw reply
* Re: [PATCH] rpadlpar_io:Add MODULE_DESCRIPTION entries to kernel modules
From: Tyrel Datwyler @ 2020-09-28 20:50 UTC (permalink / raw)
To: Oliver O'Halloran, Mamatha Inamdar
Cc: Bjorn Helgaas, linuxppc-dev, Linux Kernel Mailing List, linux-pci
In-Reply-To: <CAOSf1CEv3v940FR_we70qCBME0qFXPizPT8EFbf3XyK2-fPDrw@mail.gmail.com>
On 9/23/20 11:41 PM, Oliver O'Halloran wrote:
> On Thu, Sep 24, 2020 at 3:15 PM Mamatha Inamdar
> <mamatha4@linux.vnet.ibm.com> wrote:
>>
>> This patch adds a brief MODULE_DESCRIPTION to rpadlpar_io kernel modules
>> (descriptions taken from Kconfig file)
>>
>> Signed-off-by: Mamatha Inamdar <mamatha4@linux.vnet.ibm.com>
>> ---
>> drivers/pci/hotplug/rpadlpar_core.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/pci/hotplug/rpadlpar_core.c b/drivers/pci/hotplug/rpadlpar_core.c
>> index f979b70..bac65ed 100644
>> --- a/drivers/pci/hotplug/rpadlpar_core.c
>> +++ b/drivers/pci/hotplug/rpadlpar_core.c
>> @@ -478,3 +478,4 @@ static void __exit rpadlpar_io_exit(void)
>> module_init(rpadlpar_io_init);
>> module_exit(rpadlpar_io_exit);
>> MODULE_LICENSE("GPL");
>> +MODULE_DESCRIPTION("RPA Dynamic Logical Partitioning driver for I/O slots");
>
> RPA as a spec was superseded by PAPR in the early 2000s. Can we rename
> this already?
I seem to recall Michael and I discussed the naming briefly when I added the
maintainer entries for the drivers and that the PAPR acronym is almost as
meaningless to most as the original RPA. While, IBM no longer uses the term
pseries for Power hardware marketing it is the defacto platform identifier in
the Linux kernel tree for what we would call PAPR compliant. All in all I have
no problem with renaming, but maybe we should consider pseries_dlpar or even
simpler ibmdlpar.
>
> The only potential problem I can see is scripts doing: modprobe
> rpadlpar_io or similar
>
> However, we should be able to fix that with a module alias.
Agreed.
-Tyrel
>
> Oliver
>
^ permalink raw reply
* RE: [PATCH 1/5] Documentation: dt: binding: fsl: Add 'fsl,ippdexpcr1-alt-addr' property
From: Ran Wang @ 2020-09-29 0:34 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree@vger.kernel.org, Biwen Li, Shawn Guo,
linux-kernel@vger.kernel.org, Leo Li,
linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAL_Jsq+uzkr7CcvwQTe5vhpMPtdqL9v4EeqH5yZjMoT=JrDtDQ@mail.gmail.com>
Hi Rob,
On Monday, September 28, 2020 9:57 PM, Rob Herring wrote:
>
> On Wed, Sep 23, 2020 at 1:44 AM Ran Wang <ran.wang_1@nxp.com> wrote:
> >
> > Hi Rob,
> >
> > On Wednesday, September 23, 2020 10:33 AM, Rob Herring wrote:
> > >
> > > On Wed, Sep 16, 2020 at 04:18:27PM +0800, Ran Wang wrote:
> > > > From: Biwen Li <biwen.li@nxp.com>
> > > >
> > > > The 'fsl,ippdexpcr1-alt-addr' property is used to handle an errata
> > > > A-008646 on LS1021A
> > > >
> > > > Signed-off-by: Biwen Li <biwen.li@nxp.com>
> > > > Signed-off-by: Ran Wang <ran.wang_1@nxp.com>
> > > > ---
> > > > Documentation/devicetree/bindings/soc/fsl/rcpm.txt | 19
> > > > +++++++++++++++++++
> > > > 1 file changed, 19 insertions(+)
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > > > b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > > > index 5a33619..1be58a3 100644
> > > > --- a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > > > +++ b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > > > @@ -34,6 +34,11 @@ Chassis Version Example Chips
> > > > Optional properties:
> > > > - little-endian : RCPM register block is Little Endian. Without it RCPM
> > > > will be Big Endian (default case).
> > > > + - fsl,ippdexpcr1-alt-addr : The property is related to a hardware issue
> > > > + on SoC LS1021A and only needed on SoC LS1021A.
> > > > + Must include 2 entries:
> > > > + The first entry must be a link to the SCFG device node.
> > > > + The 2nd entry must be offset of register IPPDEXPCR1 in SCFG.
> > >
> > > You don't need a DT change for this. You can find SCFG node by its
> > > compatible string and then the offset should be known given this issue is
> only on 1 SoC.
> >
> > Did you mean that RCPM driver just to access IPPDEXPCR1 shadowed
> > register in SCFG directly without fetching it's offset info. from DT?
>
> Yes. There's only 1 possible value of the offset because there's only one SoC, so
> the driver can hardcode the offset. And I assume there's only one SCFG node,
> so you can find it by its compatible string (of_find_compatible_node).
Got it, let me update this in next version, thank you.
Regards,
Ran
> Rob
^ 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