* [powerpc:merge] BUILD SUCCESS 78c312324391ee996944e1196123b0060888e189
From: kernel test robot @ 2020-12-01 4:33 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git merge
branch HEAD: 78c312324391ee996944e1196123b0060888e189 Automatic merge of 'master' into merge (2020-11-30 12:10)
elapsed time: 723m
configs tested: 141
configs skipped: 4
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm defconfig
arm allmodconfig
arm sama5_defconfig
sh espt_defconfig
sh edosk7705_defconfig
arm jornada720_defconfig
arm cm_x300_defconfig
mips ip27_defconfig
mips pic32mzda_defconfig
arm imx_v6_v7_defconfig
arm mvebu_v5_defconfig
s390 zfcpdump_defconfig
mips gcw0_defconfig
arm pxa255-idp_defconfig
arm multi_v7_defconfig
s390 debug_defconfig
powerpc ep88xc_defconfig
arm aspeed_g5_defconfig
arm mmp2_defconfig
sh secureedge5410_defconfig
arm lpc32xx_defconfig
arm clps711x_defconfig
arm corgi_defconfig
powerpc mpc834x_itxgp_defconfig
sh r7785rp_defconfig
powerpc sam440ep_defconfig
mips workpad_defconfig
arm gemini_defconfig
mips cu1000-neo_defconfig
ia64 generic_defconfig
powerpc kilauea_defconfig
powerpc adder875_defconfig
sh j2_defconfig
powerpc katmai_defconfig
arc tb10x_defconfig
m68k m5475evb_defconfig
powerpc asp8347_defconfig
arm palmz72_defconfig
h8300 defconfig
m68k stmark2_defconfig
m68k multi_defconfig
powerpc fsp2_defconfig
mips capcella_defconfig
powerpc ppc44x_defconfig
arm imote2_defconfig
h8300 h8s-sim_defconfig
powerpc bluestone_defconfig
powerpc lite5200b_defconfig
powerpc canyonlands_defconfig
m68k m5272c3_defconfig
powerpc ebony_defconfig
mips malta_kvm_defconfig
arm netwinder_defconfig
powerpc tqm8555_defconfig
mips nlm_xlp_defconfig
arm pxa_defconfig
powerpc xes_mpc85xx_defconfig
xtensa iss_defconfig
powerpc mpc7448_hpc2_defconfig
arm multi_v4t_defconfig
mips cu1830-neo_defconfig
arm colibri_pxa270_defconfig
powerpc stx_gp3_defconfig
arm simpad_defconfig
arm zx_defconfig
arm realview_defconfig
powerpc ppc6xx_defconfig
powerpc kmeter1_defconfig
mips maltasmvp_defconfig
m68k defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allyesconfig
m68k allmodconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
c6x allyesconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a004-20201130
i386 randconfig-a002-20201130
i386 randconfig-a003-20201130
i386 randconfig-a005-20201130
i386 randconfig-a006-20201130
i386 randconfig-a001-20201130
x86_64 randconfig-a014-20201130
x86_64 randconfig-a015-20201130
x86_64 randconfig-a016-20201130
x86_64 randconfig-a011-20201130
x86_64 randconfig-a012-20201130
x86_64 randconfig-a013-20201130
i386 randconfig-a013-20201130
i386 randconfig-a012-20201130
i386 randconfig-a011-20201130
i386 randconfig-a016-20201130
i386 randconfig-a015-20201130
i386 randconfig-a014-20201130
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
riscv allmodconfig
x86_64 rhel
x86_64 allyesconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 kexec
clang tested configs:
x86_64 randconfig-a002-20201130
x86_64 randconfig-a006-20201130
x86_64 randconfig-a005-20201130
x86_64 randconfig-a004-20201130
x86_64 randconfig-a001-20201130
x86_64 randconfig-a003-20201130
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [powerpc:next-test] BUILD SUCCESS 61fb396f48fcf49892b6801f2e98f40a413da1dc
From: kernel test robot @ 2020-12-01 4:33 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next-test
branch HEAD: 61fb396f48fcf49892b6801f2e98f40a413da1dc powerpc/64: Fix an EMIT_BUG_ENTRY in head_64.S
elapsed time: 723m
configs tested: 169
configs skipped: 4
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm defconfig
arm allmodconfig
arm sama5_defconfig
sh espt_defconfig
sh edosk7705_defconfig
arm jornada720_defconfig
mips malta_kvm_defconfig
mips db1xxx_defconfig
powerpc mpc8560_ads_defconfig
arm milbeaut_m10v_defconfig
arm neponset_defconfig
sh ecovec24_defconfig
arm cm_x300_defconfig
mips ip27_defconfig
mips pic32mzda_defconfig
arm imx_v6_v7_defconfig
arm mvebu_v5_defconfig
powerpc maple_defconfig
xtensa xip_kc705_defconfig
sh apsh4a3a_defconfig
c6x dsk6455_defconfig
powerpc ppc64e_defconfig
openrisc simple_smp_defconfig
s390 zfcpdump_defconfig
mips gcw0_defconfig
arm pxa255-idp_defconfig
arm multi_v7_defconfig
s390 debug_defconfig
powerpc ep88xc_defconfig
arm aspeed_g5_defconfig
arm mmp2_defconfig
sh secureedge5410_defconfig
arm lpc32xx_defconfig
powerpc mpc5200_defconfig
mips tb0287_defconfig
arm mvebu_v7_defconfig
powerpc canyonlands_defconfig
mips gpr_defconfig
arc nsimosci_defconfig
arm clps711x_defconfig
arm corgi_defconfig
powerpc mpc834x_itxgp_defconfig
sh r7785rp_defconfig
powerpc sam440ep_defconfig
mips workpad_defconfig
arm gemini_defconfig
mips cu1000-neo_defconfig
ia64 generic_defconfig
powerpc kilauea_defconfig
powerpc adder875_defconfig
sh j2_defconfig
powerpc katmai_defconfig
arc tb10x_defconfig
sh polaris_defconfig
arm rpc_defconfig
x86_64 alldefconfig
arm h5000_defconfig
powerpc cell_defconfig
arm trizeps4_defconfig
mips fuloong2e_defconfig
m68k apollo_defconfig
arm spitz_defconfig
arm vf610m4_defconfig
arm lpd270_defconfig
nios2 10m50_defconfig
um x86_64_defconfig
powerpc skiroot_defconfig
powerpc mpc836x_mds_defconfig
powerpc fsp2_defconfig
mips capcella_defconfig
powerpc ppc44x_defconfig
arm imote2_defconfig
xtensa allyesconfig
h8300 h8s-sim_defconfig
powerpc bluestone_defconfig
powerpc lite5200b_defconfig
m68k m5272c3_defconfig
powerpc ebony_defconfig
arm netwinder_defconfig
powerpc tqm8555_defconfig
mips nlm_xlp_defconfig
powerpc motionpro_defconfig
mips allyesconfig
riscv defconfig
sh hp6xx_defconfig
sh lboxre2_defconfig
arm pxa_defconfig
powerpc xes_mpc85xx_defconfig
xtensa iss_defconfig
powerpc mpc7448_hpc2_defconfig
arm multi_v4t_defconfig
mips cu1830-neo_defconfig
arm colibri_pxa270_defconfig
powerpc stx_gp3_defconfig
arm simpad_defconfig
arm zx_defconfig
arm realview_defconfig
powerpc ppc6xx_defconfig
powerpc kmeter1_defconfig
mips maltasmvp_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
c6x allyesconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a004-20201130
i386 randconfig-a002-20201130
i386 randconfig-a003-20201130
i386 randconfig-a005-20201130
i386 randconfig-a006-20201130
i386 randconfig-a001-20201130
x86_64 randconfig-a014-20201130
x86_64 randconfig-a015-20201130
x86_64 randconfig-a016-20201130
x86_64 randconfig-a011-20201130
x86_64 randconfig-a012-20201130
x86_64 randconfig-a013-20201130
i386 randconfig-a013-20201130
i386 randconfig-a012-20201130
i386 randconfig-a011-20201130
i386 randconfig-a016-20201130
i386 randconfig-a015-20201130
i386 randconfig-a014-20201130
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv rv32_defconfig
riscv allmodconfig
x86_64 rhel
x86_64 allyesconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 kexec
clang tested configs:
x86_64 randconfig-a002-20201130
x86_64 randconfig-a006-20201130
x86_64 randconfig-a005-20201130
x86_64 randconfig-a004-20201130
x86_64 randconfig-a001-20201130
x86_64 randconfig-a003-20201130
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: CONFIG_PPC_VAS depends on 64k pages...?
From: Sukadev Bhattiprolu @ 2020-12-01 5:52 UTC (permalink / raw)
To: Christophe Leroy; +Cc: daniel, haren, linuxppc-dev, Will Springer, abali
In-Reply-To: <2b234a7e-e9f6-d02b-a20f-74c0cc1df8d3@csgroup.eu>
Christophe Leroy [christophe.leroy@csgroup.eu] wrote:
> Hi,
>
> Le 19/11/2020 à 11:58, Will Springer a écrit :
> > I learned about the POWER9 gzip accelerator a few months ago when the
> > support hit upstream Linux 5.8. However, for some reason the Kconfig
> > dictates that VAS depends on a 64k page size, which is problematic as I
> > run Void Linux, which uses a 4k-page kernel.
> >
> > Some early poking by others indicated there wasn't an obvious page size
> > dependency in the code, and suggested I try modifying the config to switch
> > it on. I did so, but was stopped by a minor complaint of an "unexpected DT
> > configuration" by the VAS code. I wasn't equipped to figure out exactly what
> > this meant, even after finding the offending condition, so after writing a
> > very drawn-out forum post asking for help, I dropped the subject.
> >
> > Fast forward to today, when I was reminded of the whole thing again, and
> > decided to debug a bit further. Apparently the VAS platform device
> > (derived from the DT node) has 5 resources on my 4k kernel, instead of 4
> > (which evidently works for others who have had success on 64k kernels). I
> > have no idea what this means in practice (I don't know how to introspect
> > it), but after making a tiny patch[1], everything came up smoothly and I
> > was doing blazing-fast gzip (de)compression in no time.
> >
> > Everything seems to work fine on 4k pages. So, what's up? Are there
> > pitfalls lurking around that I've yet to stumble over? More reasonably,
> > I'm curious as to why the feature supposedly depends on 64k pages, or if
> > there's anything else I should be concerned about.
Will,
The reason I put in that config check is because we were only able to
test 64K pages at that point.
It is interesting that it is working for you. Following code in skiboot
https://github.com/open-power/skiboot/blob/master/hw/vas.c should restrict
it to 64K pages. IIRC there is also a corresponding change in some NX
registers that should also be configured to allow 4K pages.
static int init_north_ctl(struct proc_chip *chip)
{
uint64_t val = 0ULL;
val = SETFIELD(VAS_64K_MODE_MASK, val, true);
val = SETFIELD(VAS_ACCEPT_PASTE_MASK, val, true);
val = SETFIELD(VAS_ENABLE_WC_MMIO_BAR, val, true);
val = SETFIELD(VAS_ENABLE_UWC_MMIO_BAR, val, true);
val = SETFIELD(VAS_ENABLE_RMA_MMIO_BAR, val, true);
return vas_scom_write(chip, VAS_MISC_N_CTL, val);
}
I am copying Bulent Albali and Haren Myneni who have been working with
VAS/NX for their thoughts/experience.
> >
>
> Maybe ask Sukadev who did the implementation and is maintaining it ?
>
> > I do have to say I'm quite satisfied with the results of the NX
> > accelerator, though. Being able to shuffle data to a RaptorCS box over gigE
> > and get compressed data back faster than most software gzip could ever
> > hope to achieve is no small feat, let alone the instantaneous results locally.
> > :)
> >
> > Cheers,
> > Will Springer [she/her]
> >
> > [1]: https://github.com/Skirmisher/void-packages/blob/vas-4k-pages/srcpkgs/linux5.9/patches/ppc-vas-on-4k.patch
> >
>
>
> Christophe
^ permalink raw reply
* Re: [PATCH v2] powerpc: Allow relative pointers in bug table entries
From: Christophe Leroy @ 2020-12-01 6:25 UTC (permalink / raw)
To: Jordan Niethe, linuxppc-dev
In-Reply-To: <20201201005203.15210-1-jniethe5@gmail.com>
Le 01/12/2020 à 01:52, Jordan Niethe a écrit :
> This enables GENERIC_BUG_RELATIVE_POINTERS on Power so that 32-bit
> offsets are stored in the bug entries rather than 64-bit pointers.
> While this doesn't save space for 32-bit machines, use it anyway so
> there is only one code path.
>
> Signed-off-by: Jordan Niethe <jniethe5@gmail.com>
Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Tested-by: Christophe Leroy <christophe.leroy@csgroup.eu> # on PPC32
> ---
> v2: Remove non-relative pointers code
> ---
> arch/powerpc/Kconfig | 4 ++++
> arch/powerpc/include/asm/bug.h | 8 ++++----
> arch/powerpc/xmon/xmon.c | 4 ++--
> 3 files changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index e9f13fe08492..294108e0e5c6 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -311,6 +311,10 @@ config GENERIC_BUG
> default y
> depends on BUG
>
> +config GENERIC_BUG_RELATIVE_POINTERS
> + def_bool y
> + depends on GENERIC_BUG
> +
> config SYS_SUPPORTS_APM_EMULATION
> default y if PMAC_APM_EMU
> bool
> diff --git a/arch/powerpc/include/asm/bug.h b/arch/powerpc/include/asm/bug.h
> index 338f36cd9934..ba0500872cce 100644
> --- a/arch/powerpc/include/asm/bug.h
> +++ b/arch/powerpc/include/asm/bug.h
> @@ -12,7 +12,7 @@
> #ifdef CONFIG_DEBUG_BUGVERBOSE
> .macro EMIT_BUG_ENTRY addr,file,line,flags
> .section __bug_table,"aw"
> -5001: PPC_LONG \addr, 5002f
> +5001: .4byte \addr - 5001b, 5002f - 5001b
> .short \line, \flags
> .org 5001b+BUG_ENTRY_SIZE
> .previous
> @@ -23,7 +23,7 @@
> #else
> .macro EMIT_BUG_ENTRY addr,file,line,flags
> .section __bug_table,"aw"
> -5001: PPC_LONG \addr
> +5001: .4byte \addr - 5001b
> .short \flags
> .org 5001b+BUG_ENTRY_SIZE
> .previous
> @@ -36,14 +36,14 @@
> #ifdef CONFIG_DEBUG_BUGVERBOSE
> #define _EMIT_BUG_ENTRY \
> ".section __bug_table,\"aw\"\n" \
> - "2:\t" PPC_LONG "1b, %0\n" \
> + "2:\t.4byte 1b - 2b, %0 - 2b\n" \
> "\t.short %1, %2\n" \
> ".org 2b+%3\n" \
> ".previous\n"
> #else
> #define _EMIT_BUG_ENTRY \
> ".section __bug_table,\"aw\"\n" \
> - "2:\t" PPC_LONG "1b\n" \
> + "2:\t.4byte 1b - 2b\n" \
> "\t.short %2\n" \
> ".org 2b+%3\n" \
> ".previous\n"
> diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
> index 55c43a6c9111..9704c81aff7d 100644
> --- a/arch/powerpc/xmon/xmon.c
> +++ b/arch/powerpc/xmon/xmon.c
> @@ -1745,9 +1745,9 @@ static void print_bug_trap(struct pt_regs *regs)
>
> #ifdef CONFIG_DEBUG_BUGVERBOSE
> printf("kernel BUG at %s:%u!\n",
> - bug->file, bug->line);
> + (char *)bug + bug->file_disp, bug->line);
> #else
> - printf("kernel BUG at %px!\n", (void *)bug->bug_addr);
> + printf("kernel BUG at %px!\n", (void *)bug + bug->bug_addr_disp);
> #endif
> #endif /* CONFIG_BUG */
> }
>
^ permalink raw reply
* [PATCH kernel v2] powerpc/pci: Remove LSI mappings on device teardown
From: Alexey Kardashevskiy @ 2020-12-01 7:39 UTC (permalink / raw)
To: linuxppc-dev
Cc: Alexey Kardashevskiy, Frederic Barrat, Oliver O'Halloran,
Cédric Le Goater
From: Oliver O'Halloran <oohall@gmail.com>
When a passthrough IO adapter is removed from a pseries machine using hash
MMU and the XIVE interrupt mode, the POWER hypervisor expects the guest OS
to clear all page table entries related to the adapter. If some are still
present, the RTAS call which isolates the PCI slot returns error 9001
"valid outstanding translations" and the removal of the IO adapter fails.
This is because when the PHBs are scanned, Linux maps automatically the
INTx interrupts in the Linux interrupt number space but these are never
removed.
This problem can be fixed by adding the corresponding unmap operation when
the device is removed. There's no pcibios_* hook for the remove case, but
the same effect can be achieved using a bus notifier.
Because INTx are shared among PHBs (and potentially across the system),
this adds tracking of virq to unmap them only when the last user is gone.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
[aik: added refcounter]
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
Doing this in the generic irq code is just too much for my small brain :-/
---
arch/powerpc/kernel/pci-common.c | 71 ++++++++++++++++++++++++++++++++
1 file changed, 71 insertions(+)
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index be108616a721..0acf17f17253 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -353,6 +353,55 @@ struct pci_controller *pci_find_controller_for_domain(int domain_nr)
return NULL;
}
+struct pci_intx_virq {
+ int virq;
+ struct kref kref;
+ struct list_head list_node;
+};
+
+static LIST_HEAD(intx_list);
+static DEFINE_MUTEX(intx_mutex);
+
+static void ppc_pci_intx_release(struct kref *kref)
+{
+ struct pci_intx_virq *vi = container_of(kref, struct pci_intx_virq, kref);
+
+ list_del(&vi->list_node);
+ irq_dispose_mapping(vi->virq);
+ kfree(vi);
+}
+
+static int ppc_pci_unmap_irq_line(struct notifier_block *nb,
+ unsigned long action, void *data)
+{
+ struct pci_dev *pdev = to_pci_dev(data);
+
+ if (action == BUS_NOTIFY_DEL_DEVICE) {
+ struct pci_intx_virq *vi;
+
+ mutex_lock(&intx_mutex);
+ list_for_each_entry(vi, &intx_list, list_node) {
+ if (vi->virq == pdev->irq) {
+ kref_put(&vi->kref, ppc_pci_intx_release);
+ break;
+ }
+ }
+ mutex_unlock(&intx_mutex);
+ }
+
+ return NOTIFY_DONE;
+}
+
+static struct notifier_block ppc_pci_unmap_irq_notifier = {
+ .notifier_call = ppc_pci_unmap_irq_line,
+};
+
+static int ppc_pci_register_irq_notifier(void)
+{
+ return bus_register_notifier(&pci_bus_type, &ppc_pci_unmap_irq_notifier);
+}
+arch_initcall(ppc_pci_register_irq_notifier);
+
/*
* Reads the interrupt pin to determine if interrupt is use by card.
* If the interrupt is used, then gets the interrupt line from the
@@ -361,6 +410,12 @@ struct pci_controller *pci_find_controller_for_domain(int domain_nr)
static int pci_read_irq_line(struct pci_dev *pci_dev)
{
int virq;
+ struct pci_intx_virq *vi, *vitmp;
+
+ /* Preallocate vi as rewind is complex if this fails after mapping */
+ vi = kzalloc(sizeof(struct pci_intx_virq), GFP_KERNEL);
+ if (!vi)
+ return -1;
pr_debug("PCI: Try to map irq for %s...\n", pci_name(pci_dev));
@@ -401,6 +456,22 @@ static int pci_read_irq_line(struct pci_dev *pci_dev)
pci_dev->irq = virq;
+ mutex_lock(&intx_mutex);
+ list_for_each_entry(vitmp, &intx_list, list_node) {
+ if (vitmp->virq == virq) {
+ kref_get(&vitmp->kref);
+ kfree(vi);
+ vi = NULL;
+ break;
+ }
+ }
+ if (vi) {
+ vi->virq = virq;
+ kref_init(&vi->kref);
+ list_add_tail(&vi->list_node, &intx_list);
+ }
+ mutex_unlock(&intx_mutex);
+
return 0;
}
--
2.17.1
^ permalink raw reply related
* [PATCH] selftests/powerpc: Fix uninitialized variable warning
From: Harish @ 2020-12-01 9:24 UTC (permalink / raw)
To: mpe; +Cc: Harish, linuxppc-dev
Patch fixes uninitialized variable warning in bad_accesses test
which causes the selftests build to fail in older distibutions
bad_accesses.c: In function ‘bad_access’:
bad_accesses.c:52:9: error: ‘x’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
printf("Bad - no SEGV! (%c)\n", x);
^
cc1: all warnings being treated as errors
Signed-off-by: Harish <harish@linux.ibm.com>
---
tools/testing/selftests/powerpc/mm/bad_accesses.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/powerpc/mm/bad_accesses.c b/tools/testing/selftests/powerpc/mm/bad_accesses.c
index fd747b2ffcfc..65d2148b05dc 100644
--- a/tools/testing/selftests/powerpc/mm/bad_accesses.c
+++ b/tools/testing/selftests/powerpc/mm/bad_accesses.c
@@ -38,7 +38,7 @@ static void segv_handler(int n, siginfo_t *info, void *ctxt_v)
int bad_access(char *p, bool write)
{
- char x;
+ char x = 0;
fault_code = 0;
fault_addr = 0;
--
2.26.2
^ permalink raw reply related
* [PATCH] powerpc/perf: Invoke per-CPU variable access with disabled interrupts
From: Athira Rajeev @ 2020-12-01 9:28 UTC (permalink / raw)
To: mpe; +Cc: bigeasy, maddy, linuxppc-dev
The power_pmu_event_init() callback access per-cpu variable
(cpu_hw_events) to check for event constraints and Branch Stack
(BHRB). Current usage is to disable preemption when accessing the
per-cpu variable, but this does not prevent timer callback from
interrupting event_init. Fix this by using 'local_irq_save/restore'
to make sure the code path is invoked with disabled interrupts.
This change is tested in mambo simulator to ensure that, if a timer
interrupt comes in during the per-cpu access in event_init, it will be
soft masked and replayed later. For testing purpose, introduced a
udelay() in power_pmu_event_init() to make sure a timer interrupt arrives
while in per-cpu variable access code between local_irq_save/resore.
As expected the timer interrupt was replayed later during local_irq_restore
called from power_pmu_event_init. This was confirmed by adding
breakpoint in mambo and checking the backtrace when timer_interrupt
was hit.
Reported-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
---
arch/powerpc/perf/core-book3s.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index 3c8c6ce..e38648f0 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -1909,7 +1909,7 @@ static bool is_event_blacklisted(u64 ev)
static int power_pmu_event_init(struct perf_event *event)
{
u64 ev;
- unsigned long flags;
+ unsigned long flags, irq_flags;
struct perf_event *ctrs[MAX_HWEVENTS];
u64 events[MAX_HWEVENTS];
unsigned int cflags[MAX_HWEVENTS];
@@ -2017,7 +2017,9 @@ static int power_pmu_event_init(struct perf_event *event)
if (check_excludes(ctrs, cflags, n, 1))
return -EINVAL;
- cpuhw = &get_cpu_var(cpu_hw_events);
+ local_irq_save(irq_flags);
+ cpuhw = this_cpu_ptr(&cpu_hw_events);
+
err = power_check_constraints(cpuhw, events, cflags, n + 1);
if (has_branch_stack(event)) {
@@ -2028,13 +2030,13 @@ static int power_pmu_event_init(struct perf_event *event)
event->attr.branch_sample_type);
if (bhrb_filter == -1) {
- put_cpu_var(cpu_hw_events);
+ local_irq_restore(irq_flags);
return -EOPNOTSUPP;
}
cpuhw->bhrb_filter = bhrb_filter;
}
- put_cpu_var(cpu_hw_events);
+ local_irq_restore(irq_flags);
if (err)
return -EINVAL;
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH kernel v2] powerpc/pci: Remove LSI mappings on device teardown
From: Cédric Le Goater @ 2020-12-01 9:31 UTC (permalink / raw)
To: Alexey Kardashevskiy, linuxppc-dev; +Cc: Frederic Barrat, Oliver O'Halloran
In-Reply-To: <20201201073919.5600-1-aik@ozlabs.ru>
On 12/1/20 8:39 AM, Alexey Kardashevskiy wrote:
> From: Oliver O'Halloran <oohall@gmail.com>
>
> When a passthrough IO adapter is removed from a pseries machine using hash
> MMU and the XIVE interrupt mode, the POWER hypervisor expects the guest OS
> to clear all page table entries related to the adapter. If some are still
> present, the RTAS call which isolates the PCI slot returns error 9001
> "valid outstanding translations" and the removal of the IO adapter fails.
> This is because when the PHBs are scanned, Linux maps automatically the
> INTx interrupts in the Linux interrupt number space but these are never
> removed.
>
> This problem can be fixed by adding the corresponding unmap operation when
> the device is removed. There's no pcibios_* hook for the remove case, but
> the same effect can be achieved using a bus notifier.
>
> Because INTx are shared among PHBs (and potentially across the system),
> this adds tracking of virq to unmap them only when the last user is gone.
>
> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
> [aik: added refcounter]
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Looks good to me and the system survives all the PCI hotplug tests I used
to do on my first attempts to fix this issue.
One comment below,
> ---
>
>
> Doing this in the generic irq code is just too much for my small brain :-/
may be more cleanups are required in the PCI/MSI/IRQ PPC layers before
considering your first approach. You think too much in advance !
>
> ---
> arch/powerpc/kernel/pci-common.c | 71 ++++++++++++++++++++++++++++++++
> 1 file changed, 71 insertions(+)
>
> diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
> index be108616a721..0acf17f17253 100644
> --- a/arch/powerpc/kernel/pci-common.c
> +++ b/arch/powerpc/kernel/pci-common.c
> @@ -353,6 +353,55 @@ struct pci_controller *pci_find_controller_for_domain(int domain_nr)
> return NULL;
> }
>
> +struct pci_intx_virq {
> + int virq;
> + struct kref kref;
> + struct list_head list_node;
> +};
> +
> +static LIST_HEAD(intx_list);
> +static DEFINE_MUTEX(intx_mutex);
> +
> +static void ppc_pci_intx_release(struct kref *kref)
> +{
> + struct pci_intx_virq *vi = container_of(kref, struct pci_intx_virq, kref);
> +
> + list_del(&vi->list_node);
> + irq_dispose_mapping(vi->virq);
> + kfree(vi);
> +}
> +
> +static int ppc_pci_unmap_irq_line(struct notifier_block *nb,
> + unsigned long action, void *data)
> +{
> + struct pci_dev *pdev = to_pci_dev(data);
> +
> + if (action == BUS_NOTIFY_DEL_DEVICE) {
> + struct pci_intx_virq *vi;
> +
> + mutex_lock(&intx_mutex);
> + list_for_each_entry(vi, &intx_list, list_node) {
> + if (vi->virq == pdev->irq) {
> + kref_put(&vi->kref, ppc_pci_intx_release);
> + break;
> + }
> + }
> + mutex_unlock(&intx_mutex);
> + }
> +
> + return NOTIFY_DONE;
> +}
> +
> +static struct notifier_block ppc_pci_unmap_irq_notifier = {
> + .notifier_call = ppc_pci_unmap_irq_line,
> +};
> +
> +static int ppc_pci_register_irq_notifier(void)
> +{
> + return bus_register_notifier(&pci_bus_type, &ppc_pci_unmap_irq_notifier);
> +}
> +arch_initcall(ppc_pci_register_irq_notifier);
> +
> /*
> * Reads the interrupt pin to determine if interrupt is use by card.
> * If the interrupt is used, then gets the interrupt line from the
> @@ -361,6 +410,12 @@ struct pci_controller *pci_find_controller_for_domain(int domain_nr)
> static int pci_read_irq_line(struct pci_dev *pci_dev)
> {
> int virq;
> + struct pci_intx_virq *vi, *vitmp;
> +
> + /* Preallocate vi as rewind is complex if this fails after mapping */
AFAICT, we only need to call irq_dispose_mapping() if allocation fails.
If so, it would be simpler to isolate the code in a pci_intx_register(virq)
helper and call it from pci_read_irq_line().
> + vi = kzalloc(sizeof(struct pci_intx_virq), GFP_KERNEL);
> + if (!vi)
> + return -1;
>
> pr_debug("PCI: Try to map irq for %s...\n", pci_name(pci_dev));
>
> @@ -401,6 +456,22 @@ static int pci_read_irq_line(struct pci_dev *pci_dev)
>
> pci_dev->irq = virq;
>
> + mutex_lock(&intx_mutex);
> + list_for_each_entry(vitmp, &intx_list, list_node) {
> + if (vitmp->virq == virq) {
> + kref_get(&vitmp->kref);
> + kfree(vi);
> + vi = NULL;
> + break;
> + }
> + }
> + if (vi) {
> + vi->virq = virq;
> + kref_init(&vi->kref);
> + list_add_tail(&vi->list_node, &intx_list);
> + }
> + mutex_unlock(&intx_mutex);
> +
> return 0;
> }
>
>
^ permalink raw reply
* Re: [PATCH kernel v2] powerpc/pci: Remove LSI mappings on device teardown
From: Frederic Barrat @ 2020-12-01 9:49 UTC (permalink / raw)
To: Alexey Kardashevskiy, linuxppc-dev
Cc: Oliver O'Halloran, Cédric Le Goater
In-Reply-To: <20201201073919.5600-1-aik@ozlabs.ru>
On 01/12/2020 08:39, Alexey Kardashevskiy wrote:
> From: Oliver O'Halloran <oohall@gmail.com>
>
> When a passthrough IO adapter is removed from a pseries machine using hash
> MMU and the XIVE interrupt mode, the POWER hypervisor expects the guest OS
> to clear all page table entries related to the adapter. If some are still
> present, the RTAS call which isolates the PCI slot returns error 9001
> "valid outstanding translations" and the removal of the IO adapter fails.
> This is because when the PHBs are scanned, Linux maps automatically the
> INTx interrupts in the Linux interrupt number space but these are never
> removed.
>
> This problem can be fixed by adding the corresponding unmap operation when
> the device is removed. There's no pcibios_* hook for the remove case, but
> the same effect can be achieved using a bus notifier.
>
> Because INTx are shared among PHBs (and potentially across the system),
> this adds tracking of virq to unmap them only when the last user is gone.
>
> Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
> [aik: added refcounter]
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> ---
>
>
> Doing this in the generic irq code is just too much for my small brain :-/
>
>
> ---
> arch/powerpc/kernel/pci-common.c | 71 ++++++++++++++++++++++++++++++++
> 1 file changed, 71 insertions(+)
>
> diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
> index be108616a721..0acf17f17253 100644
> --- a/arch/powerpc/kernel/pci-common.c
> +++ b/arch/powerpc/kernel/pci-common.c
> @@ -353,6 +353,55 @@ struct pci_controller *pci_find_controller_for_domain(int domain_nr)
> return NULL;
> }
>
> +struct pci_intx_virq {
> + int virq;
> + struct kref kref;
> + struct list_head list_node;
> +};
> +
> +static LIST_HEAD(intx_list);
> +static DEFINE_MUTEX(intx_mutex);
> +
> +static void ppc_pci_intx_release(struct kref *kref)
> +{
> + struct pci_intx_virq *vi = container_of(kref, struct pci_intx_virq, kref);
> +
> + list_del(&vi->list_node);
> + irq_dispose_mapping(vi->virq);
> + kfree(vi);
> +}
> +
> +static int ppc_pci_unmap_irq_line(struct notifier_block *nb,
> + unsigned long action, void *data)
> +{
> + struct pci_dev *pdev = to_pci_dev(data);
> +
> + if (action == BUS_NOTIFY_DEL_DEVICE) {
> + struct pci_intx_virq *vi;
> +
> + mutex_lock(&intx_mutex);
> + list_for_each_entry(vi, &intx_list, list_node) {
> + if (vi->virq == pdev->irq) {
> + kref_put(&vi->kref, ppc_pci_intx_release);
> + break;
> + }
> + }
> + mutex_unlock(&intx_mutex);
> + }
> +
> + return NOTIFY_DONE;
> +}
> +
> +static struct notifier_block ppc_pci_unmap_irq_notifier = {
> + .notifier_call = ppc_pci_unmap_irq_line,
> +};
> +
> +static int ppc_pci_register_irq_notifier(void)
> +{
> + return bus_register_notifier(&pci_bus_type, &ppc_pci_unmap_irq_notifier);
> +}
> +arch_initcall(ppc_pci_register_irq_notifier);
> +
> /*
> * Reads the interrupt pin to determine if interrupt is use by card.
> * If the interrupt is used, then gets the interrupt line from the
> @@ -361,6 +410,12 @@ struct pci_controller *pci_find_controller_for_domain(int domain_nr)
> static int pci_read_irq_line(struct pci_dev *pci_dev)
> {
> int virq;
> + struct pci_intx_virq *vi, *vitmp;
> +
> + /* Preallocate vi as rewind is complex if this fails after mapping */
Seems ok to me as the failure is unexpected.
But then we need to free that memory on all the error paths below.
Fred
> + vi = kzalloc(sizeof(struct pci_intx_virq), GFP_KERNEL);
> + if (!vi)
> + return -1;
>
> pr_debug("PCI: Try to map irq for %s...\n", pci_name(pci_dev));
>
> @@ -401,6 +456,22 @@ static int pci_read_irq_line(struct pci_dev *pci_dev)
>
> pci_dev->irq = virq;
>
> + mutex_lock(&intx_mutex);
> + list_for_each_entry(vitmp, &intx_list, list_node) {
> + if (vitmp->virq == virq) {
> + kref_get(&vitmp->kref);
> + kfree(vi);
> + vi = NULL;
> + break;
> + }
> + }
> + if (vi) {
> + vi->virq = virq;
> + kref_init(&vi->kref);
> + list_add_tail(&vi->list_node, &intx_list);
> + }
> + mutex_unlock(&intx_mutex);
> +
> return 0;
> }
>
>
^ permalink raw reply
* [PATCH] powerpc/mm: Don't see NULL pointer dereference as a KUAP fault
From: Christophe Leroy @ 2020-12-01 10:01 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
Sometimes, NULL pointer dereferences are expected. Even when they
are accidental they are unlikely an exploit attempt because the
first page is never mapped.
The exemple below shows what we get when invoking the "show task"
sysrq handler, by writing 't' in /proc/sysrq-trigger
[ 1117.202054] ------------[ cut here ]------------
[ 1117.202102] Bug: fault blocked by AP register !
[ 1117.202261] WARNING: CPU: 0 PID: 377 at arch/powerpc/include/asm/nohash/32/kup-8xx.h:66 do_page_fault+0x4a8/0x5ec
[ 1117.202310] Modules linked in:
[ 1117.202428] CPU: 0 PID: 377 Comm: sh Tainted: G W 5.10.0-rc5-s3k-dev-01340-g83f53be2de31-dirty #4175
[ 1117.202499] NIP: c0012048 LR: c0012048 CTR: 00000000
[ 1117.202573] REGS: cacdbb88 TRAP: 0700 Tainted: G W (5.10.0-rc5-s3k-dev-01340-g83f53be2de31-dirty)
[ 1117.202625] MSR: 00021032 <ME,IR,DR,RI> CR: 24082222 XER: 20000000
[ 1117.202899]
[ 1117.202899] GPR00: c0012048 cacdbc40 c2929290 00000023 c092e554 00000001 c09865e8 c092e640
[ 1117.202899] GPR08: 00001032 00000000 00000000 00014efc 28082224 100d166a 100a0920 00000000
[ 1117.202899] GPR16: 100cac0c 100b0000 1080c3fc 1080d685 100d0000 100d0000 00000000 100a0900
[ 1117.202899] GPR24: 100d0000 c07892ec 00000000 c0921510 c21f4440 0000005c c0000000 cacdbc80
[ 1117.204362] NIP [c0012048] do_page_fault+0x4a8/0x5ec
[ 1117.204461] LR [c0012048] do_page_fault+0x4a8/0x5ec
[ 1117.204509] Call Trace:
[ 1117.204609] [cacdbc40] [c0012048] do_page_fault+0x4a8/0x5ec (unreliable)
[ 1117.204771] [cacdbc70] [c00112f0] handle_page_fault+0x8/0x34
[ 1117.204911] --- interrupt: 301 at copy_from_kernel_nofault+0x70/0x1c0
[ 1117.204979] NIP: c010dbec LR: c010dbac CTR: 00000001
[ 1117.205053] REGS: cacdbc80 TRAP: 0301 Tainted: G W (5.10.0-rc5-s3k-dev-01340-g83f53be2de31-dirty)
[ 1117.205104] MSR: 00009032 <EE,ME,IR,DR,RI> CR: 28082224 XER: 00000000
[ 1117.205416] DAR: 0000005c DSISR: c0000000
[ 1117.205416] GPR00: c0045948 cacdbd38 c2929290 00000001 00000017 00000017 00000027 0000000f
[ 1117.205416] GPR08: c09926ec 00000000 00000000 3ffff000 24082224
[ 1117.206106] NIP [c010dbec] copy_from_kernel_nofault+0x70/0x1c0
[ 1117.206202] LR [c010dbac] copy_from_kernel_nofault+0x30/0x1c0
[ 1117.206258] --- interrupt: 301
[ 1117.206372] [cacdbd38] [c004bbb0] kthread_probe_data+0x44/0x70 (unreliable)
[ 1117.206561] [cacdbd58] [c0045948] print_worker_info+0xe0/0x194
[ 1117.206717] [cacdbdb8] [c00548ac] sched_show_task+0x134/0x168
[ 1117.206851] [cacdbdd8] [c005a268] show_state_filter+0x70/0x100
[ 1117.206989] [cacdbe08] [c039baa0] sysrq_handle_showstate+0x14/0x24
[ 1117.207122] [cacdbe18] [c039bf18] __handle_sysrq+0xac/0x1d0
[ 1117.207257] [cacdbe48] [c039c0c0] write_sysrq_trigger+0x4c/0x74
[ 1117.207407] [cacdbe68] [c01fba48] proc_reg_write+0xb4/0x114
[ 1117.207550] [cacdbe88] [c0179968] vfs_write+0x12c/0x478
[ 1117.207686] [cacdbf08] [c0179e60] ksys_write+0x78/0x128
[ 1117.207826] [cacdbf38] [c00110d0] ret_from_syscall+0x0/0x34
[ 1117.207938] --- interrupt: c01 at 0xfd4e784
[ 1117.208008] NIP: 0fd4e784 LR: 0fe0f244 CTR: 10048d38
[ 1117.208083] REGS: cacdbf48 TRAP: 0c01 Tainted: G W (5.10.0-rc5-s3k-dev-01340-g83f53be2de31-dirty)
[ 1117.208134] MSR: 0000d032 <EE,PR,ME,IR,DR,RI> CR: 44002222 XER: 00000000
[ 1117.208470]
[ 1117.208470] GPR00: 00000004 7fc34090 77bfb4e0 00000001 1080fa40 00000002 7400000f fefefeff
[ 1117.208470] GPR08: 7f7f7f7f 10048d38 1080c414 7fc343c0 00000000
[ 1117.209104] NIP [0fd4e784] 0xfd4e784
[ 1117.209180] LR [0fe0f244] 0xfe0f244
[ 1117.209236] --- interrupt: c01
[ 1117.209274] Instruction dump:
[ 1117.209353] 714a4000 418200f0 73ca0001 40820084 73ca0032 408200f8 73c90040 4082ff60
[ 1117.209727] 0fe00000 3c60c082 386399f4 48013b65 <0fe00000> 80010034 3860000b 7c0803a6
[ 1117.210102] ---[ end trace 1927c0323393af3e ]---
So, avoid the big KUAP warning by bailing out of bad_kernel_fault()
before calling bad_kuap_fault() when address references the first
page.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
arch/powerpc/mm/fault.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
index 0add963a849b..be2b4318206f 100644
--- a/arch/powerpc/mm/fault.c
+++ b/arch/powerpc/mm/fault.c
@@ -198,6 +198,10 @@ static bool bad_kernel_fault(struct pt_regs *regs, unsigned long error_code,
{
int is_exec = TRAP(regs) == 0x400;
+ // Kernel fault on first page is likely a NULL pointer dereference
+ if (address < PAGE_SIZE)
+ return true;
+
/* NX faults set DSISR_PROTFAULT on the 8xx, DSISR_NOEXEC_OR_G on others */
if (is_exec && (error_code & (DSISR_NOEXEC_OR_G | DSISR_KEYFAULT |
DSISR_PROTFAULT))) {
--
2.25.0
^ permalink raw reply related
* Re: [PATCH v2] clk: renesas: r9a06g032: Drop __packed for portability
From: Stephen Rothwell @ 2020-12-01 10:03 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Stephen Boyd, Michael Turquette, linux-kernel, Gareth Williams,
linux-renesas-soc, Paul Mackerras, linuxppc-dev, linux-clk
In-Reply-To: <20201130085743.1656317-1-geert+renesas@glider.be>
[-- Attachment #1: Type: text/plain, Size: 1969 bytes --]
Hi Geert,
On Mon, 30 Nov 2020 09:57:43 +0100 Geert Uytterhoeven <geert+renesas@glider.be> wrote:
>
> The R9A06G032 clock driver uses an array of packed structures to reduce
> kernel size. However, this array contains pointers, which are no longer
> aligned naturally, and cannot be relocated on PPC64. Hence when
> compile-testing this driver on PPC64 with CONFIG_RELOCATABLE=y (e.g.
> PowerPC allyesconfig), the following warnings are produced:
>
> WARNING: 136 bad relocations
> c000000000616be3 R_PPC64_UADDR64 .rodata+0x00000000000cf338
> c000000000616bfe R_PPC64_UADDR64 .rodata+0x00000000000cf370
> ...
>
> Fix this by dropping the __packed attribute from the r9a06g032_clkdesc
> definition, trading a small size increase for portability.
>
> This increases the 156-entry clock table by 1 byte per entry, but due to
> the compiler generating more efficient code for unpacked accesses, the
> net size increase is only 76 bytes (gcc 9.3.0 on arm32).
>
> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> Fixes: 4c3d88526eba2143 ("clk: renesas: Renesas R9A06G032 clock driver")
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> v2:
> - Fix authorship.
> ---
> drivers/clk/renesas/r9a06g032-clocks.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clk/renesas/r9a06g032-clocks.c b/drivers/clk/renesas/r9a06g032-clocks.c
> index d900f6bf53d0b944..892e91b92f2c80f5 100644
> --- a/drivers/clk/renesas/r9a06g032-clocks.c
> +++ b/drivers/clk/renesas/r9a06g032-clocks.c
> @@ -55,7 +55,7 @@ struct r9a06g032_clkdesc {
> u16 sel, g1, r1, g2, r2;
> } dual;
> };
> -} __packed;
> +};
>
> #define I_GATE(_clk, _rst, _rdy, _midle, _scon, _mirack, _mistat) \
> { .gate = _clk, .reset = _rst, \
> --
> 2.25.1
>
Tested-by: Stephen Rothwell <sfr@canb.auug.org.au> # PowerPC allyesconfig build
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 0/5] drop unused BACKLIGHT_GENERIC option
From: Daniel Thompson @ 2020-12-01 10:05 UTC (permalink / raw)
To: Andrey Zhizhikin
Cc: alexandre.belloni, tony, linux-kernel, James.Bottomley,
thierry.reding, paulus, sam, linux-omap, deller, linux, krzk,
jonathanh, ludovic.desroches, catalin.marinas, linux-mips, will,
mripard, linux-tegra, lee.jones, wens, linux-arm-kernel,
jernej.skrabec, tsbogend, linux-parisc, emil.l.velikov,
nicolas.ferre, linuxppc-dev
In-Reply-To: <20201130152137.24909-1-andrey.zhizhikin@leica-geosystems.com>
On Mon, Nov 30, 2020 at 03:21:32PM +0000, Andrey Zhizhikin wrote:
> Since the removal of generic_bl driver from the source tree in commit
> 7ecdea4a0226 ("backlight: generic_bl: Remove this driver as it is
> unused") BACKLIGHT_GENERIC config option became obsolete as well and
> therefore subject to clean-up from all configuration files.
>
> This series introduces patches to address this removal, separated by
> architectures in the kernel tree.
>
> Andrey Zhizhikin (5):
> ARM: configs: drop unused BACKLIGHT_GENERIC option
> arm64: defconfig: drop unused BACKLIGHT_GENERIC option
> MIPS: configs: drop unused BACKLIGHT_GENERIC option
> parisc: configs: drop unused BACKLIGHT_GENERIC option
> powerpc/configs: drop unused BACKLIGHT_GENERIC option
Whole series:
Acked-by: Daniel Thompson <daniel.thompson@linaro.org>
Daniel.
^ permalink raw reply
* Re: [RFC PATCH] powerpc: show registers when unwinding interrupt frames
From: Christophe Leroy @ 2020-12-01 10:29 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev
In-Reply-To: <20201107023305.2384874-1-npiggin@gmail.com>
Le 07/11/2020 à 03:33, Nicholas Piggin a écrit :
> It's often useful to know the register state for interrupts in
> the stack frame. In the below example (with this patch applied),
> the important information is the state of the page fault.
>
> A blatant case like this probably rather should have the page
> fault regs passed down to the warning, but quite often there are
> less obvious cases where an interrupt shows up that might give
> some more clues.
>
> The downside is longer and more complex bug output.
Do we want all interrupts, including system call ?
I don't find the dump of the syscall interrupt so usefull, do you ?
See below an (unexpected?) KUAP warning due to an expected NULL pointer dereference in
copy_from_kernel_nofault() called from kthread_probe_data()
[ 1117.202054] ------------[ cut here ]------------
[ 1117.202102] Bug: fault blocked by AP register !
[ 1117.202261] WARNING: CPU: 0 PID: 377 at arch/powerpc/include/asm/nohash/32/kup-8xx.h:66
do_page_fault+0x4a8/0x5ec
[ 1117.202310] Modules linked in:
[ 1117.202428] CPU: 0 PID: 377 Comm: sh Tainted: G W
5.10.0-rc5-s3k-dev-01340-g83f53be2de31-dirty #4175
[ 1117.202499] NIP: c0012048 LR: c0012048 CTR: 00000000
[ 1117.202573] REGS: cacdbb88 TRAP: 0700 Tainted: G W
(5.10.0-rc5-s3k-dev-01340-g83f53be2de31-dirty)
[ 1117.202625] MSR: 00021032 <ME,IR,DR,RI> CR: 24082222 XER: 20000000
[ 1117.202899]
[ 1117.202899] GPR00: c0012048 cacdbc40 c2929290 00000023 c092e554 00000001 c09865e8 c092e640
[ 1117.202899] GPR08: 00001032 00000000 00000000 00014efc 28082224 100d166a 100a0920 00000000
[ 1117.202899] GPR16: 100cac0c 100b0000 1080c3fc 1080d685 100d0000 100d0000 00000000 100a0900
[ 1117.202899] GPR24: 100d0000 c07892ec 00000000 c0921510 c21f4440 0000005c c0000000 cacdbc80
[ 1117.204362] NIP [c0012048] do_page_fault+0x4a8/0x5ec
[ 1117.204461] LR [c0012048] do_page_fault+0x4a8/0x5ec
[ 1117.204509] Call Trace:
[ 1117.204609] [cacdbc40] [c0012048] do_page_fault+0x4a8/0x5ec (unreliable)
[ 1117.204771] [cacdbc70] [c00112f0] handle_page_fault+0x8/0x34
[ 1117.204911] --- interrupt: 301 at copy_from_kernel_nofault+0x70/0x1c0
[ 1117.204979] NIP: c010dbec LR: c010dbac CTR: 00000001
[ 1117.205053] REGS: cacdbc80 TRAP: 0301 Tainted: G W
(5.10.0-rc5-s3k-dev-01340-g83f53be2de31-dirty)
[ 1117.205104] MSR: 00009032 <EE,ME,IR,DR,RI> CR: 28082224 XER: 00000000
[ 1117.205416] DAR: 0000005c DSISR: c0000000
[ 1117.205416] GPR00: c0045948 cacdbd38 c2929290 00000001 00000017 00000017 00000027 0000000f
[ 1117.205416] GPR08: c09926ec 00000000 00000000 3ffff000 24082224
[ 1117.206106] NIP [c010dbec] copy_from_kernel_nofault+0x70/0x1c0
[ 1117.206202] LR [c010dbac] copy_from_kernel_nofault+0x30/0x1c0
[ 1117.206258] --- interrupt: 301
[ 1117.206372] [cacdbd38] [c004bbb0] kthread_probe_data+0x44/0x70 (unreliable)
[ 1117.206561] [cacdbd58] [c0045948] print_worker_info+0xe0/0x194
[ 1117.206717] [cacdbdb8] [c00548ac] sched_show_task+0x134/0x168
[ 1117.206851] [cacdbdd8] [c005a268] show_state_filter+0x70/0x100
[ 1117.206989] [cacdbe08] [c039baa0] sysrq_handle_showstate+0x14/0x24
[ 1117.207122] [cacdbe18] [c039bf18] __handle_sysrq+0xac/0x1d0
[ 1117.207257] [cacdbe48] [c039c0c0] write_sysrq_trigger+0x4c/0x74
[ 1117.207407] [cacdbe68] [c01fba48] proc_reg_write+0xb4/0x114
[ 1117.207550] [cacdbe88] [c0179968] vfs_write+0x12c/0x478
[ 1117.207686] [cacdbf08] [c0179e60] ksys_write+0x78/0x128
[ 1117.207826] [cacdbf38] [c00110d0] ret_from_syscall+0x0/0x34
[ 1117.207938] --- interrupt: c01 at 0xfd4e784
[ 1117.208008] NIP: 0fd4e784 LR: 0fe0f244 CTR: 10048d38
[ 1117.208083] REGS: cacdbf48 TRAP: 0c01 Tainted: G W
(5.10.0-rc5-s3k-dev-01340-g83f53be2de31-dirty)
[ 1117.208134] MSR: 0000d032 <EE,PR,ME,IR,DR,RI> CR: 44002222 XER: 00000000
[ 1117.208470]
[ 1117.208470] GPR00: 00000004 7fc34090 77bfb4e0 00000001 1080fa40 00000002 7400000f fefefeff
[ 1117.208470] GPR08: 7f7f7f7f 10048d38 1080c414 7fc343c0 00000000
[ 1117.209104] NIP [0fd4e784] 0xfd4e784
[ 1117.209180] LR [0fe0f244] 0xfe0f244
[ 1117.209236] --- interrupt: c01
[ 1117.209274] Instruction dump:
[ 1117.209353] 714a4000 418200f0 73ca0001 40820084 73ca0032 408200f8 73c90040 4082ff60
[ 1117.209727] 0fe00000 3c60c082 386399f4 48013b65 <0fe00000> 80010034 3860000b 7c0803a6
[ 1117.210102] ---[ end trace 1927c0323393af3e ]---
Christophe
>
> Bug: Write fault blocked by AMR!
> WARNING: CPU: 0 PID: 72 at arch/powerpc/include/asm/book3s/64/kup-radix.h:164 __do_page_fault+0x880/0xa90
> Modules linked in:
> CPU: 0 PID: 72 Comm: systemd-gpt-aut Not tainted
> NIP: c00000000006e2f0 LR: c00000000006e2ec CTR: 0000000000000000
> REGS: c00000000a4f3420 TRAP: 0700
> MSR: 8000000000021033 <SF,ME,IR,DR,RI,LE> CR: 28002840 XER: 20040000
> CFAR: c000000000128be0 IRQMASK: 3
> GPR00: c00000000006e2ec c00000000a4f36c0 c0000000014f0700 0000000000000020
> GPR04: 0000000000000001 c000000001290f50 0000000000000001 c000000001290f80
> GPR08: c000000001612b08 0000000000000000 0000000000000000 00000000ffffe0f7
> GPR12: 0000000048002840 c0000000016e0000 c00c000000021c80 c000000000fd6f60
> GPR16: 0000000000000000 c00000000a104698 0000000000000003 c0000000087f0000
> GPR20: 0000000000000100 c0000000070330b8 0000000000000000 0000000000000004
> GPR24: 0000000002000000 0000000000000300 0000000002000000 c00000000a5b0c00
> GPR28: 0000000000000000 000000000a000000 00007fffb2a90038 c00000000a4f3820
> NIP [c00000000006e2f0] __do_page_fault+0x880/0xa90
> LR [c00000000006e2ec] __do_page_fault+0x87c/0xa90
> Call Trace:
> [c00000000a4f36c0] [c00000000006e2ec] __do_page_fault+0x87c/0xa90 (unreliable)
> [c00000000a4f3780] [c000000000e1c034] do_page_fault+0x34/0x90
> [c00000000a4f37b0] [c000000000008908] data_access_common_virt+0x158/0x1b0
> --- interrupt: 300 at __copy_tofrom_user_base+0x9c/0x5a4
> NIP: c00000000009b028 LR: c000000000802978 CTR: 0000000000000800
> REGS: c00000000a4f3820 TRAP: 0300
> MSR: 800000000280b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 24004840 XER: 00000000
> CFAR: c00000000009aff4 DAR: 00007fffb2a90038 DSISR: 0a000000 IRQMASK: 0
> GPR00: 0000000000000000 c00000000a4f3ac0 c0000000014f0700 00007fffb2a90028
> GPR04: c000000008720010 0000000000010000 0000000000000000 0000000000000000
> GPR08: 0000000000000000 0000000000000000 0000000000000000 0000000000000001
> GPR12: 0000000000004000 c0000000016e0000 c00c000000021c80 c000000000fd6f60
> GPR16: 0000000000000000 c00000000a104698 0000000000000003 c0000000087f0000
> GPR20: 0000000000000100 c0000000070330b8 0000000000000000 0000000000000004
> GPR24: c00000000a4f3c80 c000000008720000 0000000000010000 0000000000000000
> GPR28: 0000000000010000 0000000008720000 0000000000010000 c000000001515b98
> NIP [c00000000009b028] __copy_tofrom_user_base+0x9c/0x5a4
> LR [c000000000802978] copyout+0x68/0xc0
> --- interrupt: 300
> [c00000000a4f3af0] [c0000000008074b8] copy_page_to_iter+0x188/0x540
> [c00000000a4f3b50] [c00000000035c678] generic_file_buffered_read+0x358/0xd80
> [c00000000a4f3c40] [c0000000004c1e90] blkdev_read_iter+0x50/0x80
> [c00000000a4f3c60] [c00000000045733c] new_sync_read+0x12c/0x1c0
> [c00000000a4f3d00] [c00000000045a1f0] vfs_read+0x1d0/0x240
> [c00000000a4f3d50] [c00000000045a7f4] ksys_read+0x84/0x140
> [c00000000a4f3da0] [c000000000033a60] system_call_exception+0x100/0x280
> [c00000000a4f3e10] [c00000000000c508] system_call_common+0xf8/0x2f8
> Instruction dump:
> eae10078 3be0000b 4bfff890 60420000 792917e1 4182ff18 3c82ffab 3884a5e0
> 3c62ffab 3863a6e8 480ba891 60000000 <0fe00000> 3be0000b 4bfff860 e93c0938
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> ---
> arch/powerpc/kernel/process.c | 20 ++++++++++++++------
> 1 file changed, 14 insertions(+), 6 deletions(-)
>
> diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
> index ea36a29c8b01..799f00b32f74 100644
> --- a/arch/powerpc/kernel/process.c
> +++ b/arch/powerpc/kernel/process.c
> @@ -1475,12 +1475,10 @@ static void print_msr_bits(unsigned long val)
> #define LAST_VOLATILE 12
> #endif
>
> -void show_regs(struct pt_regs * regs)
> +static void __show_regs(struct pt_regs *regs)
> {
> int i, trap;
>
> - show_regs_print_info(KERN_DEFAULT);
> -
> printk("NIP: "REG" LR: "REG" CTR: "REG"\n",
> regs->nip, regs->link, regs->ctr);
> printk("REGS: %px TRAP: %04lx %s (%s)\n",
> @@ -1522,6 +1520,12 @@ void show_regs(struct pt_regs * regs)
> printk("NIP ["REG"] %pS\n", regs->nip, (void *)regs->nip);
> printk("LR ["REG"] %pS\n", regs->link, (void *)regs->link);
> }
> +}
> +
> +void show_regs(struct pt_regs *regs)
> +{
> + show_regs_print_info(KERN_DEFAULT);
> + __show_regs(regs);
> show_stack(current, (unsigned long *) regs->gpr[1], KERN_DEFAULT);
> if (!user_mode(regs))
> show_instructions(regs);
> @@ -2192,10 +2196,14 @@ void show_stack(struct task_struct *tsk, unsigned long *stack,
> && stack[STACK_FRAME_MARKER] == STACK_FRAME_REGS_MARKER) {
> struct pt_regs *regs = (struct pt_regs *)
> (sp + STACK_FRAME_OVERHEAD);
> +
> lr = regs->link;
> - printk("%s--- interrupt: %lx at %pS\n LR = %pS\n",
> - loglvl, regs->trap,
> - (void *)regs->nip, (void *)lr);
> + printk("%s--- interrupt: %lx at %pS\n",
> + loglvl, regs->trap, (void *)regs->nip);
> + __show_regs(regs);
> + printk("%s--- interrupt: %lx\n",
> + loglvl, regs->trap);
> +
> firstframe = 1;
> }
>
>
^ permalink raw reply
* [RFC PATCH] powerpc/papr_scm: Implement scm async flush
From: Shivaprasad G Bhat @ 2020-12-01 12:18 UTC (permalink / raw)
To: ellerman; +Cc: aneesh.kumar, linuxppc-dev, kvm-ppc, linux-nvdimm
Tha patch implements SCM async-flush hcall and sets the
ND_REGION_ASYNC capability when the platform device tree
has "ibm,async-flush-required" set.
The below demonstration shows the map_sync behavior when
ibm,async-flush-required is present in device tree.
(https://github.com/avocado-framework-tests/avocado-misc-tests/blob/master/memory/ndctl.py.data/map_sync.c)
The pmem0 is from nvdimm without async-flush-required,
and pmem1 is from nvdimm with async-flush-required, mounted as
/dev/pmem0 on /mnt1 type xfs (rw,relatime,attr2,dax=always,inode64,logbufs=8,logbsize=32k,noquota)
/dev/pmem1 on /mnt2 type xfs (rw,relatime,attr2,dax=always,inode64,logbufs=8,logbsize=32k,noquota)
#./mapsync /mnt1/newfile ----> Without async-flush-required
#./mapsync /mnt2/newfile ----> With async-flush-required
Failed to mmap with Operation not supported
Signed-off-by: Shivaprasad G Bhat <sbhat@linux.ibm.com>
---
The HCALL semantics are in review, not final.
Documentation/powerpc/papr_hcalls.rst | 14 ++++++++++
arch/powerpc/include/asm/hvcall.h | 3 +-
arch/powerpc/platforms/pseries/papr_scm.c | 39 +++++++++++++++++++++++++++++
3 files changed, 55 insertions(+), 1 deletion(-)
diff --git a/Documentation/powerpc/papr_hcalls.rst b/Documentation/powerpc/papr_hcalls.rst
index 48fcf1255a33..cc310814f24c 100644
--- a/Documentation/powerpc/papr_hcalls.rst
+++ b/Documentation/powerpc/papr_hcalls.rst
@@ -275,6 +275,20 @@ Health Bitmap Flags:
Given a DRC Index collect the performance statistics for NVDIMM and copy them
to the resultBuffer.
+**H_SCM_ASYNC_FLUSH**
+
+| Input: *drcIndex*
+| Out: *continue-token*
+| Return Value: *H_SUCCESS, H_Parameter, H_P2, H_BUSY*
+
+Given a DRC Index Flush the data to backend NVDIMM device.
+
+The hcall returns H_BUSY when the flush takes longer time and the hcall needs
+to be issued multiple times in order to be completely serviced. The
+*continue-token* from the output to be passed in the argument list in
+subsequent hcalls to the hypervisor until the hcall is completely serviced
+at which point H_SUCCESS is returned by the hypervisor.
+
References
==========
.. [1] "Power Architecture Platform Reference"
diff --git a/arch/powerpc/include/asm/hvcall.h b/arch/powerpc/include/asm/hvcall.h
index c1fbccb04390..4a13074bc782 100644
--- a/arch/powerpc/include/asm/hvcall.h
+++ b/arch/powerpc/include/asm/hvcall.h
@@ -306,7 +306,8 @@
#define H_SCM_HEALTH 0x400
#define H_SCM_PERFORMANCE_STATS 0x418
#define H_RPT_INVALIDATE 0x448
-#define MAX_HCALL_OPCODE H_RPT_INVALIDATE
+#define H_SCM_ASYNC_FLUSH 0x4A0
+#define MAX_HCALL_OPCODE H_SCM_ASYNC_FLUSH
/* Scope args for H_SCM_UNBIND_ALL */
#define H_UNBIND_SCOPE_ALL (0x1)
diff --git a/arch/powerpc/platforms/pseries/papr_scm.c b/arch/powerpc/platforms/pseries/papr_scm.c
index 835163f54244..1f8c5153cb3d 100644
--- a/arch/powerpc/platforms/pseries/papr_scm.c
+++ b/arch/powerpc/platforms/pseries/papr_scm.c
@@ -93,6 +93,7 @@ struct papr_scm_priv {
uint64_t block_size;
int metadata_size;
bool is_volatile;
+ bool async_flush_required;
uint64_t bound_addr;
@@ -117,6 +118,38 @@ struct papr_scm_priv {
size_t stat_buffer_len;
};
+static int papr_scm_pmem_flush(struct nd_region *nd_region, struct bio *bio)
+{
+ unsigned long ret[PLPAR_HCALL_BUFSIZE];
+ struct papr_scm_priv *p = nd_region_provider_data(nd_region);
+ int64_t rc;
+ uint64_t token = 0;
+
+ do {
+ rc = plpar_hcall(H_SCM_ASYNC_FLUSH, ret, p->drc_index, token);
+
+ /* Check if we are stalled for some time */
+ token = ret[0];
+ if (H_IS_LONG_BUSY(rc)) {
+ msleep(get_longbusy_msecs(rc));
+ rc = H_BUSY;
+ } else if (rc == H_BUSY) {
+ cond_resched();
+ }
+
+ } while (rc == H_BUSY);
+
+ if (rc)
+ dev_err(&p->pdev->dev, "flush error: %lld\n", rc);
+ else
+ dev_dbg(&p->pdev->dev, "flush drc 0x%x complete\n",
+ p->drc_index);
+
+ dev_dbg(&p->pdev->dev, "Flush call complete\n");
+
+ return rc;
+}
+
static LIST_HEAD(papr_nd_regions);
static DEFINE_MUTEX(papr_ndr_lock);
@@ -943,6 +976,11 @@ static int papr_scm_nvdimm_init(struct papr_scm_priv *p)
ndr_desc.num_mappings = 1;
ndr_desc.nd_set = &p->nd_set;
+ if (p->async_flush_required) {
+ set_bit(ND_REGION_ASYNC, &ndr_desc.flags);
+ ndr_desc.flush = papr_scm_pmem_flush;
+ }
+
if (p->is_volatile)
p->region = nvdimm_volatile_region_create(p->bus, &ndr_desc);
else {
@@ -1088,6 +1126,7 @@ static int papr_scm_probe(struct platform_device *pdev)
p->block_size = block_size;
p->blocks = blocks;
p->is_volatile = !of_property_read_bool(dn, "ibm,cache-flush-required");
+ p->async_flush_required = of_property_read_bool(dn, "ibm,async-flush-required");
/* We just need to ensure that set cookies are unique across */
uuid_parse(uuid_str, (uuid_t *) uuid);
^ permalink raw reply related
* Re: [RFC PATCH] powerpc/papr_scm: Implement scm async flush
From: Pankaj Gupta @ 2020-12-01 12:47 UTC (permalink / raw)
To: Shivaprasad G Bhat
Cc: Dave Jiang <dave.jiang@intel.com>, Jason Gunthorpe <jgg@ziepe.ca>, Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>, Johannes Thumshirn <jthumshirn@suse.de>, Logan Gunthorpe,
ellerman, linuxppc-dev, kvm-ppc, linux-nvdimm
In-Reply-To: <160682501436.2579014.14501834468510806255.stgit@lep8c.aus.stglabs.ibm.com>
> Tha patch implements SCM async-flush hcall and sets the
> ND_REGION_ASYNC capability when the platform device tree
> has "ibm,async-flush-required" set.
So, you are reusing the existing ND_REGION_ASYNC flag for the
hypercall based async flush with device tree discovery?
Out of curiosity, does virtio based flush work in ppc? Was just thinking
if we can reuse virtio based flush present in virtio-pmem? Or anything
else we are trying to achieve here?
Thanks,
Pankaj
>
> The below demonstration shows the map_sync behavior when
> ibm,async-flush-required is present in device tree.
> (https://github.com/avocado-framework-tests/avocado-misc-tests/blob/master/memory/ndctl.py.data/map_sync.c)
>
> The pmem0 is from nvdimm without async-flush-required,
> and pmem1 is from nvdimm with async-flush-required, mounted as
> /dev/pmem0 on /mnt1 type xfs (rw,relatime,attr2,dax=always,inode64,logbufs=8,logbsize=32k,noquota)
> /dev/pmem1 on /mnt2 type xfs (rw,relatime,attr2,dax=always,inode64,logbufs=8,logbsize=32k,noquota)
>
> #./mapsync /mnt1/newfile ----> Without async-flush-required
> #./mapsync /mnt2/newfile ----> With async-flush-required
> Failed to mmap with Operation not supported
>
> Signed-off-by: Shivaprasad G Bhat <sbhat@linux.ibm.com>
> ---
> The HCALL semantics are in review, not final.
Any link of the discussion?
>
> Documentation/powerpc/papr_hcalls.rst | 14 ++++++++++
> arch/powerpc/include/asm/hvcall.h | 3 +-
> arch/powerpc/platforms/pseries/papr_scm.c | 39 +++++++++++++++++++++++++++++
> 3 files changed, 55 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/powerpc/papr_hcalls.rst b/Documentation/powerpc/papr_hcalls.rst
> index 48fcf1255a33..cc310814f24c 100644
> --- a/Documentation/powerpc/papr_hcalls.rst
> +++ b/Documentation/powerpc/papr_hcalls.rst
> @@ -275,6 +275,20 @@ Health Bitmap Flags:
> Given a DRC Index collect the performance statistics for NVDIMM and copy them
> to the resultBuffer.
>
> +**H_SCM_ASYNC_FLUSH**
> +
> +| Input: *drcIndex*
> +| Out: *continue-token*
> +| Return Value: *H_SUCCESS, H_Parameter, H_P2, H_BUSY*
> +
> +Given a DRC Index Flush the data to backend NVDIMM device.
> +
> +The hcall returns H_BUSY when the flush takes longer time and the hcall needs
> +to be issued multiple times in order to be completely serviced. The
> +*continue-token* from the output to be passed in the argument list in
> +subsequent hcalls to the hypervisor until the hcall is completely serviced
> +at which point H_SUCCESS is returned by the hypervisor.
> +
> References
> ==========
> .. [1] "Power Architecture Platform Reference"
> diff --git a/arch/powerpc/include/asm/hvcall.h b/arch/powerpc/include/asm/hvcall.h
> index c1fbccb04390..4a13074bc782 100644
> --- a/arch/powerpc/include/asm/hvcall.h
> +++ b/arch/powerpc/include/asm/hvcall.h
> @@ -306,7 +306,8 @@
> #define H_SCM_HEALTH 0x400
> #define H_SCM_PERFORMANCE_STATS 0x418
> #define H_RPT_INVALIDATE 0x448
> -#define MAX_HCALL_OPCODE H_RPT_INVALIDATE
> +#define H_SCM_ASYNC_FLUSH 0x4A0
> +#define MAX_HCALL_OPCODE H_SCM_ASYNC_FLUSH
>
> /* Scope args for H_SCM_UNBIND_ALL */
> #define H_UNBIND_SCOPE_ALL (0x1)
> diff --git a/arch/powerpc/platforms/pseries/papr_scm.c b/arch/powerpc/platforms/pseries/papr_scm.c
> index 835163f54244..1f8c5153cb3d 100644
> --- a/arch/powerpc/platforms/pseries/papr_scm.c
> +++ b/arch/powerpc/platforms/pseries/papr_scm.c
> @@ -93,6 +93,7 @@ struct papr_scm_priv {
> uint64_t block_size;
> int metadata_size;
> bool is_volatile;
> + bool async_flush_required;
>
> uint64_t bound_addr;
>
> @@ -117,6 +118,38 @@ struct papr_scm_priv {
> size_t stat_buffer_len;
> };
>
> +static int papr_scm_pmem_flush(struct nd_region *nd_region, struct bio *bio)
> +{
> + unsigned long ret[PLPAR_HCALL_BUFSIZE];
> + struct papr_scm_priv *p = nd_region_provider_data(nd_region);
> + int64_t rc;
> + uint64_t token = 0;
> +
> + do {
> + rc = plpar_hcall(H_SCM_ASYNC_FLUSH, ret, p->drc_index, token);
> +
> + /* Check if we are stalled for some time */
> + token = ret[0];
> + if (H_IS_LONG_BUSY(rc)) {
> + msleep(get_longbusy_msecs(rc));
> + rc = H_BUSY;
> + } else if (rc == H_BUSY) {
> + cond_resched();
> + }
> +
> + } while (rc == H_BUSY);
> +
> + if (rc)
> + dev_err(&p->pdev->dev, "flush error: %lld\n", rc);
> + else
> + dev_dbg(&p->pdev->dev, "flush drc 0x%x complete\n",
> + p->drc_index);
> +
> + dev_dbg(&p->pdev->dev, "Flush call complete\n");
> +
> + return rc;
> +}
> +
> static LIST_HEAD(papr_nd_regions);
> static DEFINE_MUTEX(papr_ndr_lock);
>
> @@ -943,6 +976,11 @@ static int papr_scm_nvdimm_init(struct papr_scm_priv *p)
> ndr_desc.num_mappings = 1;
> ndr_desc.nd_set = &p->nd_set;
>
> + if (p->async_flush_required) {
> + set_bit(ND_REGION_ASYNC, &ndr_desc.flags);
> + ndr_desc.flush = papr_scm_pmem_flush;
> + }
> +
> if (p->is_volatile)
> p->region = nvdimm_volatile_region_create(p->bus, &ndr_desc);
> else {
> @@ -1088,6 +1126,7 @@ static int papr_scm_probe(struct platform_device *pdev)
> p->block_size = block_size;
> p->blocks = blocks;
> p->is_volatile = !of_property_read_bool(dn, "ibm,cache-flush-required");
> + p->async_flush_required = of_property_read_bool(dn, "ibm,async-flush-required");
>
> /* We just need to ensure that set cookies are unique across */
> uuid_parse(uuid_str, (uuid_t *) uuid);
>
> _______________________________________________
> Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
> To unsubscribe send an email to linux-nvdimm-leave@lists.01.org
^ permalink raw reply
* Re: [RFC PATCH] powerpc/papr_scm: Implement scm async flush
From: Aneesh Kumar K.V @ 2020-12-01 12:57 UTC (permalink / raw)
To: Pankaj Gupta, Shivaprasad G Bhat
Cc: ellerman, linuxppc-dev, kvm-ppc, linux-nvdimm
In-Reply-To: <CAM9Jb+iPV470063QYq145znYW8CmqjNgdL=q6=3JXUJJt+z5gw@mail.gmail.com>
On 12/1/20 6:17 PM, Pankaj Gupta wrote:
>> Tha patch implements SCM async-flush hcall and sets the
>> ND_REGION_ASYNC capability when the platform device tree
>> has "ibm,async-flush-required" set.
>
> So, you are reusing the existing ND_REGION_ASYNC flag for the
> hypercall based async flush with device tree discovery?
>
> Out of curiosity, does virtio based flush work in ppc? Was just thinking
> if we can reuse virtio based flush present in virtio-pmem? Or anything
> else we are trying to achieve here?
>
Not with PAPR based pmem driver papr_scm.ko. The devices there are
considered platform device and we use hypercalls to configure the
device. On similar fashion we are now using hypercall to flush the host
based caches.
-aneesh
^ permalink raw reply
* Re: [RFC PATCH] powerpc/papr_scm: Implement scm async flush
From: Pankaj Gupta @ 2020-12-01 13:02 UTC (permalink / raw)
To: Aneesh Kumar K.V
Cc: ellerman, linuxppc-dev, kvm-ppc, Shivaprasad G Bhat, linux-nvdimm
In-Reply-To: <20035bbc-a1e0-82fd-105d-999e1afff029@linux.ibm.com>
> >> Tha patch implements SCM async-flush hcall and sets the
> >> ND_REGION_ASYNC capability when the platform device tree
> >> has "ibm,async-flush-required" set.
> >
> > So, you are reusing the existing ND_REGION_ASYNC flag for the
> > hypercall based async flush with device tree discovery?
> >
> > Out of curiosity, does virtio based flush work in ppc? Was just thinking
> > if we can reuse virtio based flush present in virtio-pmem? Or anything
> > else we are trying to achieve here?
> >
>
>
> Not with PAPR based pmem driver papr_scm.ko. The devices there are
> considered platform device and we use hypercalls to configure the
> device. On similar fashion we are now using hypercall to flush the host
> based caches.
o.k. Thanks for answering.
Best regards,
Pankaj
>
> -aneesh
^ permalink raw reply
* Re: [PATCH v2 2/2] kbuild: Disable CONFIG_LD_ORPHAN_WARN for ld.lld 10.0.1
From: Masahiro Yamada @ 2020-12-01 13:31 UTC (permalink / raw)
To: Kees Cook
Cc: Michal Marek, kernelci . org bot, Linux Kbuild mailing list,
Catalin Marinas, Mark Brown,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT), Nick Desaulniers,
Russell King, LKML, linuxppc-dev, Arvind Sankar, Ingo Molnar,
Borislav Petkov, clang-built-linux, Nathan Chancellor,
Will Deacon, Thomas Gleixner, Linux ARM
In-Reply-To: <202011241421.A2F3062A70@keescook>
On Wed, Nov 25, 2020 at 7:22 AM Kees Cook <keescook@chromium.org> wrote:
>
> On Thu, Nov 19, 2020 at 01:13:27PM -0800, Nick Desaulniers wrote:
> > On Thu, Nov 19, 2020 at 12:57 PM Nathan Chancellor
> > <natechancellor@gmail.com> wrote:
> > >
> > > ld.lld 10.0.1 spews a bunch of various warnings about .rela sections,
> > > along with a few others. Newer versions of ld.lld do not have these
> > > warnings. As a result, do not add '--orphan-handling=warn' to
> > > LDFLAGS_vmlinux if ld.lld's version is not new enough.
> > >
> > > Link: https://github.com/ClangBuiltLinux/linux/issues/1187
> > > Link: https://github.com/ClangBuiltLinux/linux/issues/1193
> > > Reported-by: Arvind Sankar <nivedita@alum.mit.edu>
> > > Reported-by: kernelci.org bot <bot@kernelci.org>
> > > Reported-by: Mark Brown <broonie@kernel.org>
> > > Reviewed-by: Kees Cook <keescook@chromium.org>
> > > Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
> >
> > Thanks for the additions in v2.
> > Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
>
> I'm going to carry this for a few days in -next, and if no one screams,
> ask Linus to pull it for v5.10-rc6.
>
> Thanks!
>
> --
> Kees Cook
Sorry for the delay.
Applied to linux-kbuild.
But, I already see this in linux-next.
Please let me know if I should drop it from my tree.
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* Re: [PATCH v2 1/2] kbuild: Hoist '--orphan-handling' into Kconfig
From: Masahiro Yamada @ 2020-12-01 13:28 UTC (permalink / raw)
To: Kees Cook
Cc: Michal Marek, Linux Kbuild mailing list, Catalin Marinas, X86 ML,
Nick Desaulniers, Russell King, Linux Kernel Mailing List,
linuxppc-dev, Arvind Sankar, Ingo Molnar, Borislav Petkov,
clang-built-linux, Nathan Chancellor, Will Deacon,
Thomas Gleixner, linux-arm-kernel
In-Reply-To: <202011201607.75FA476@keescook>
On Sat, Nov 21, 2020 at 9:08 AM Kees Cook <keescook@chromium.org> wrote:
>
> On Thu, Nov 19, 2020 at 01:46:56PM -0700, Nathan Chancellor wrote:
> > Currently, '--orphan-handling=warn' is spread out across four different
> > architectures in their respective Makefiles, which makes it a little
> > unruly to deal with in case it needs to be disabled for a specific
> > linker version (in this case, ld.lld 10.0.1).
> >
> > To make it easier to control this, hoist this warning into Kconfig and
> > the main Makefile so that disabling it is simpler, as the warning will
> > only be enabled in a couple places (main Makefile and a couple of
> > compressed boot folders that blow away LDFLAGS_vmlinx) and making it
> > conditional is easier due to Kconfig syntax. One small additional
> > benefit of this is saving a call to ld-option on incremental builds
> > because we will have already evaluated it for CONFIG_LD_ORPHAN_WARN.
> >
> > To keep the list of supported architectures the same, introduce
> > CONFIG_ARCH_WANT_LD_ORPHAN_WARN, which an architecture can select to
> > gain this automatically after all of the sections are specified and size
> > asserted. A special thanks to Kees Cook for the help text on this
> > config.
> >
> > Link: https://github.com/ClangBuiltLinux/linux/issues/1187
> > Acked-by: Kees Cook <keescook@chromium.org>
> > Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
> > Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
> > Tested-by: Nick Desaulniers <ndesaulniers@google.com>
> > Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
>
> Masahiro, do you want to take these to get them to Linus for v5.10? I
> can send them if you'd prefer.
>
Sorry for the delay.
Applied to linux-kbuild.
> -Kees
>
> --
> Kees Cook
>
> --
> You received this message because you are subscribed to the Google Groups "Clang Built Linux" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to clang-built-linux+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/clang-built-linux/202011201607.75FA476%40keescook.
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* Re: [RFC PATCH 01/14] ftrace: Fix updating FTRACE_FL_TRAMP
From: Naveen N. Rao @ 2020-12-01 13:46 UTC (permalink / raw)
To: Steven Rostedt; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20201130212346.31e2a8b7@oasis.local.home>
Steven Rostedt wrote:
> On Thu, 26 Nov 2020 23:38:38 +0530
> "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com> wrote:
>
>> On powerpc, kprobe-direct.tc triggered FTRACE_WARN_ON() in
>> ftrace_get_addr_new() followed by the below message:
>> Bad trampoline accounting at: 000000004222522f (wake_up_process+0xc/0x20) (f0000001)
>>
>> The set of steps leading to this involved:
>> - modprobe ftrace-direct-too
>> - enable_probe
>> - modprobe ftrace-direct
>> - rmmod ftrace-direct <-- trigger
>>
>> The problem turned out to be that we were not updating flags in the
>> ftrace record properly. From the above message about the trampoline
>> accounting being bad, it can be seen that the ftrace record still has
>> FTRACE_FL_TRAMP set though ftrace-direct module is going away. This
>> happens because we are checking if any ftrace_ops has the
>> FTRACE_FL_TRAMP flag set _before_ updating the filter hash.
>>
>> The fix for this is to look for any _other_ ftrace_ops that also needs
>> FTRACE_FL_TRAMP.
>
> I'm applying this now and sending this for -rc and stable.
>
> The code worked on x86 because x86 has a way to make all users use
> trampolines, so this was never an issue (everything has a trampoline).
> I modified the kernel so that x86 would not create its own trampoline
> (see the weak function arch_ftrace_update_trampoline(), and I was able
> to reproduce the bug.
Good to know that you were able to reproduce this.
>
> I'm adding:
>
> Cc: stable@vger.kernel.org
> Fixes: a124692b698b0 ("ftrace: Enable trampoline when rec count returns back to one")
That looks good to me. Thanks for picking the two patches and for your
review on the others!
- Naveen
^ permalink raw reply
* Re: [PATCH v8 05/12] mm: HUGE_VMAP arch support cleanup
From: Catalin Marinas @ 2020-12-01 14:21 UTC (permalink / raw)
To: Nicholas Piggin
Cc: linux-arch, H. Peter Anvin, Ingo Molnar, Will Deacon, x86,
linux-kernel, Christoph Hellwig, linux-mm, Zefan Li,
Borislav Petkov, Jonathan Cameron, Andrew Morton, linuxppc-dev,
Thomas Gleixner, linux-arm-kernel
In-Reply-To: <20201128152559.999540-6-npiggin@gmail.com>
On Sun, Nov 29, 2020 at 01:25:52AM +1000, Nicholas Piggin wrote:
> This changes the awkward approach where architectures provide init
> functions to determine which levels they can provide large mappings for,
> to one where the arch is queried for each call.
>
> This removes code and indirection, and allows constant-folding of dead
> code for unsupported levels.
>
> This also adds a prot argument to the arch query. This is unused
> currently but could help with some architectures (e.g., some powerpc
> processors can't map uncacheable memory with large pages).
>
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: x86@kernel.org
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> ---
> arch/arm64/include/asm/vmalloc.h | 8 +++
> arch/arm64/mm/mmu.c | 10 +--
For arm64:
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* Re: [PATCH 1/5] ARM: configs: drop unused BACKLIGHT_GENERIC option
From: Catalin Marinas @ 2020-12-01 14:40 UTC (permalink / raw)
To: ZHIZHIKIN Andrey
Cc: alexandre.belloni@bootlin.com, tony@atomide.com,
linux-kernel@vger.kernel.org,
James.Bottomley@HansenPartnership.com, thierry.reding@gmail.com,
paulus@samba.org, sam@ravnborg.org, daniel.thompson@linaro.org,
linux-omap@vger.kernel.org, Arnd Bergmann, deller@gmx.de,
linux@armlinux.org.uk, Krzysztof Kozlowski, jonathanh@nvidia.com,
ludovic.desroches@microchip.com, arm, linux-mips@vger.kernel.org,
will@kernel.org, mripard@kernel.org, linux-tegra@vger.kernel.org,
lee.jones@linaro.org, wens@csie.org,
linux-arm-kernel@lists.infradead.org, jernej.skrabec@siol.net,
tsbogend@alpha.franken.de, linux-parisc@vger.kernel.org,
emil.l.velikov@gmail.com, nicolas.ferre@microchip.com,
Olof Johansson, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <AM6PR06MB4691EC52BA41B86AB16EE14FA6F50@AM6PR06MB4691.eurprd06.prod.outlook.com>
On Mon, Nov 30, 2020 at 07:50:25PM +0000, ZHIZHIKIN Andrey wrote:
> From Krzysztof Kozlowski <krzk@kernel.org>:
> > On Mon, Nov 30, 2020 at 03:21:33PM +0000, Andrey Zhizhikin wrote:
> > > Commit 7ecdea4a0226 ("backlight: generic_bl: Remove this driver as it is
> > > unused") removed geenric_bl driver from the tree, together with
> > > corresponding config option.
> > >
> > > Remove BACKLIGHT_GENERIC config item from all ARM configurations.
> > >
> > > Fixes: 7ecdea4a0226 ("backlight: generic_bl: Remove this driver as it
> > > is unused")
> > > Cc: Sam Ravnborg <sam@ravnborg.org>
> > > Signed-off-by: Andrey Zhizhikin
> > > <andrey.zhizhikin@leica-geosystems.com>
> > > ---
> > > arch/arm/configs/at91_dt_defconfig | 1 -
> > > arch/arm/configs/cm_x300_defconfig | 1 -
> > > arch/arm/configs/colibri_pxa300_defconfig | 1 -
> > > arch/arm/configs/jornada720_defconfig | 1 -
> > > arch/arm/configs/magician_defconfig | 1 -
> > > arch/arm/configs/mini2440_defconfig | 1 -
> > > arch/arm/configs/omap2plus_defconfig | 1 -
> > > arch/arm/configs/pxa3xx_defconfig | 1 -
> > > arch/arm/configs/qcom_defconfig | 1 -
> > > arch/arm/configs/sama5_defconfig | 1 -
> > > arch/arm/configs/sunxi_defconfig | 1 -
> > > arch/arm/configs/tegra_defconfig | 1 -
> > > arch/arm/configs/u8500_defconfig | 1 -
> > > 13 files changed, 13 deletions(-)
> >
> > You need to send it to arm-soc maintainers, otherwise no one might feel
> > responsible enough to pick it up.
>
> Good point, thanks a lot!
>
> I was not aware of the fact that there is a separate ML that should
> receive patches targeted ARM SOCs. Can you (or anyone else) please
> share it, so I can re-send it there as well?
It's not a mailing list as such (with archives etc.), just an alias to
the arm-soc maintainers: arm@kernel.org.
> > Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
> >
> > +CC Arnd and Olof,
> >
> > Dear Arnd and Olof,
> >
> > Maybe it is worth to add arm-soc entry to the MAINTAINERS file?
> > Otherwise how one could get your email address? Not mentioning the
> > secret-soc address. :)
I tried to convince them before, it didn't work. I guess they don't like
to be spammed ;). Or rather, SoC-specific patches, even to defconfig,
should go through the specific SoC maintainers. However, there are
occasional defconfig patches which are more generic or affecting
multiple SoCs. I just ignore them as the arm64 defconfig is usually
handled by the arm-soc folk (when I need a defconfig change, I go for
arch/arm64/Kconfig directly ;)).
Anyway, I still think that we should add a MAINTAINERS entry for
arch/arm64/configs/defconfig and arch/arm64/Kconfig.platforms.
--
Catalin
^ permalink raw reply
* [PATCH] powerpc/feature-fixups: use a semicolon rather than a comma
From: Daniel Axtens @ 2020-12-01 14:43 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nick Piggin, Daniel Axtens
In a bunch of our security flushes, we use a comma rather than
a semicolon to 'terminate' an assignment. Nothing breaks, but
checkpatch picks it up if you copy it into another flush.
Switch to semicolons for ending statements.
Cc: Nick Piggin <npiggin@gmail.com>
Cc: Russell Currey <ruscur@russell.cc>
Signed-off-by: Daniel Axtens <dja@axtens.net>
---
arch/powerpc/lib/feature-fixups.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/lib/feature-fixups.c b/arch/powerpc/lib/feature-fixups.c
index 321c12a9ef6b..47821055b94c 100644
--- a/arch/powerpc/lib/feature-fixups.c
+++ b/arch/powerpc/lib/feature-fixups.c
@@ -124,7 +124,7 @@ static void do_stf_entry_barrier_fixups(enum stf_barrier_type types)
long *start, *end;
int i;
- start = PTRRELOC(&__start___stf_entry_barrier_fixup),
+ start = PTRRELOC(&__start___stf_entry_barrier_fixup);
end = PTRRELOC(&__stop___stf_entry_barrier_fixup);
instrs[0] = 0x60000000; /* nop */
@@ -176,7 +176,7 @@ static void do_stf_exit_barrier_fixups(enum stf_barrier_type types)
long *start, *end;
int i;
- start = PTRRELOC(&__start___stf_exit_barrier_fixup),
+ start = PTRRELOC(&__start___stf_exit_barrier_fixup);
end = PTRRELOC(&__stop___stf_exit_barrier_fixup);
instrs[0] = 0x60000000; /* nop */
@@ -344,7 +344,7 @@ void do_rfi_flush_fixups(enum l1d_flush_type types)
long *start, *end;
int i;
- start = PTRRELOC(&__start___rfi_flush_fixup),
+ start = PTRRELOC(&__start___rfi_flush_fixup);
end = PTRRELOC(&__stop___rfi_flush_fixup);
instrs[0] = 0x60000000; /* nop */
@@ -417,7 +417,7 @@ void do_barrier_nospec_fixups(bool enable)
{
void *start, *end;
- start = PTRRELOC(&__start___barrier_nospec_fixup),
+ start = PTRRELOC(&__start___barrier_nospec_fixup);
end = PTRRELOC(&__stop___barrier_nospec_fixup);
do_barrier_nospec_fixups_range(enable, start, end);
--
2.25.1
^ permalink raw reply related
* [PATCH] selftests/powerpc: update .gitignore
From: Daniel Axtens @ 2020-12-01 14:44 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Daniel Axtens
I did an in-place build of the self-tests and found that it left
the tree dirty.
Add missed test binaries to .gitignore
Signed-off-by: Daniel Axtens <dja@axtens.net>
---
tools/testing/selftests/powerpc/nx-gzip/.gitignore | 3 +++
tools/testing/selftests/powerpc/security/.gitignore | 1 +
tools/testing/selftests/powerpc/signal/.gitignore | 1 +
tools/testing/selftests/powerpc/syscalls/.gitignore | 1 +
4 files changed, 6 insertions(+)
create mode 100644 tools/testing/selftests/powerpc/nx-gzip/.gitignore
diff --git a/tools/testing/selftests/powerpc/nx-gzip/.gitignore b/tools/testing/selftests/powerpc/nx-gzip/.gitignore
new file mode 100644
index 000000000000..886d522d52df
--- /dev/null
+++ b/tools/testing/selftests/powerpc/nx-gzip/.gitignore
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0-only
+gunz_test
+gzfht_test
diff --git a/tools/testing/selftests/powerpc/security/.gitignore b/tools/testing/selftests/powerpc/security/.gitignore
index 4257a1f156bb..93614b125ded 100644
--- a/tools/testing/selftests/powerpc/security/.gitignore
+++ b/tools/testing/selftests/powerpc/security/.gitignore
@@ -1,3 +1,4 @@
# SPDX-License-Identifier: GPL-2.0-only
rfi_flush
entry_flush
+spectre_v2
diff --git a/tools/testing/selftests/powerpc/signal/.gitignore b/tools/testing/selftests/powerpc/signal/.gitignore
index 405b5364044c..ce3375cd8e73 100644
--- a/tools/testing/selftests/powerpc/signal/.gitignore
+++ b/tools/testing/selftests/powerpc/signal/.gitignore
@@ -3,3 +3,4 @@ signal
signal_tm
sigfuz
sigreturn_vdso
+sig_sc_double_restart
diff --git a/tools/testing/selftests/powerpc/syscalls/.gitignore b/tools/testing/selftests/powerpc/syscalls/.gitignore
index b00cab225476..a1e19ccdef84 100644
--- a/tools/testing/selftests/powerpc/syscalls/.gitignore
+++ b/tools/testing/selftests/powerpc/syscalls/.gitignore
@@ -1,2 +1,3 @@
# SPDX-License-Identifier: GPL-2.0-only
ipc_unmuxed
+rtas_filter
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v6 0/5] PCI: Unify ECAM constants in native PCI Express drivers
From: Lorenzo Pieralisi @ 2020-12-01 15:34 UTC (permalink / raw)
To: Bjorn Helgaas, Krzysztof Wilczyński
Cc: Heiko Stuebner, Shawn Lin, Paul Mackerras, Thomas Petazzoni,
Jonathan Chocron, Toan Le, Will Deacon, Rob Herring,
Lorenzo Pieralisi, Michal Simek, linux-rockchip,
bcm-kernel-feedback-list, Jonathan Derrick, linux-pci, Ray Jui,
Florian Fainelli, linux-rpi-kernel, Jonathan Cameron,
linux-arm-kernel, Scott Branden, Zhou Wang, Robert Richter,
linuxppc-dev, Nicolas Saenz Julienne
In-Reply-To: <20201129230743.3006978-1-kw@linux.com>
On Sun, 29 Nov 2020 23:07:38 +0000, Krzysztof Wilczyński wrote:
> Unify ECAM-related constants into a single set of standard constants
> defining memory address shift values for the byte-level address that can
> be used when accessing the PCI Express Configuration Space, and then
> move native PCI Express controller drivers to use newly introduced
> definitions retiring any driver-specific ones.
>
> The ECAM ("Enhanced Configuration Access Mechanism") is defined by the
> PCI Express specification (see PCI Express Base Specification, Revision
> 5.0, Version 1.0, Section 7.2.2, p. 676), thus most hardware should
> implement it the same way.
>
> [...]
Applied to pci/ecam, thanks!
[1/5] PCI: Unify ECAM constants in native PCI Express drivers
https://git.kernel.org/lpieralisi/pci/c/f3c07cf692
[2/5] PCI: thunder-pem: Add constant for custom ".bus_shift" initialiser
https://git.kernel.org/lpieralisi/pci/c/3c38579263
[3/5] PCI: iproc: Convert to use the new ECAM constants
https://git.kernel.org/lpieralisi/pci/c/333ec9d3cc
[4/5] PCI: vmd: Update type of the __iomem pointers
https://git.kernel.org/lpieralisi/pci/c/89094c12ea
[5/5] PCI: xgene: Removed unused ".bus_shift" initialisers from pci-xgene.c
https://git.kernel.org/lpieralisi/pci/c/3dc62532a5
Thanks,
Lorenzo
^ 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