* Re: [PATCH 2/3] powerpc/cpuhp: BUG -> WARN conversion in offline path
From: Christophe Leroy @ 2021-09-20 14:26 UTC (permalink / raw)
To: Nathan Lynch, linuxppc-dev; +Cc: tyreld, ldufour, aneesh.kumar, danielhb413
In-Reply-To: <20210920135504.1792219-3-nathanl@linux.ibm.com>
Le 20/09/2021 à 15:55, Nathan Lynch a écrit :
> If, due to bugs elsewhere, we get into unregister_cpu_online() with a CPU
> that isn't marked hotpluggable, we can emit a warning and return an
> appropriate error instead of crashing.
Is it only a bug situation, or is it something that can happen in real
life ?
If it can happen in real life, kernels with panic_on_warn will still be
impacted.
>
> Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
> ---
> arch/powerpc/kernel/sysfs.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c
> index defecb3b1b15..08d8072d6e7a 100644
> --- a/arch/powerpc/kernel/sysfs.c
> +++ b/arch/powerpc/kernel/sysfs.c
> @@ -928,7 +928,8 @@ static int unregister_cpu_online(unsigned int cpu)
> struct device_attribute *attrs, *pmc_attrs;
> int i, nattrs;
>
> - BUG_ON(!c->hotpluggable);
> + if (WARN_RATELIMIT(!c->hotpluggable, "cpu %d can't be offlined\n", cpu))
> + return -EBUSY;
>
> #ifdef CONFIG_PPC64
> if (cpu_has_feature(CPU_FTR_SMT))
>
^ permalink raw reply
* Re: [PATCH 2/3] powerpc/cpuhp: BUG -> WARN conversion in offline path
From: Nathan Lynch @ 2021-09-20 14:39 UTC (permalink / raw)
To: Christophe Leroy, linuxppc-dev; +Cc: danielhb413, tyreld, ldufour, aneesh.kumar
In-Reply-To: <47f36467-ae04-6472-741a-0851506a2d73@csgroup.eu>
Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> Le 20/09/2021 à 15:55, Nathan Lynch a écrit :
>> If, due to bugs elsewhere, we get into unregister_cpu_online() with a CPU
>> that isn't marked hotpluggable, we can emit a warning and return an
>> appropriate error instead of crashing.
>
> Is it only a bug situation, or is it something that can happen in real
> life ?
>
> If it can happen in real life, kernels with panic_on_warn will still be
> impacted.
I only found this by inspection, and it can happen only due to a bug in
CPU device registration at boot. The flag must not be set if the
platform or CPU can't support going offline.
^ permalink raw reply
* Re: Build regressions/improvements in v5.15-rc2
From: Geert Uytterhoeven @ 2021-09-20 14:52 UTC (permalink / raw)
To: linux-kernel; +Cc: linuxppc-dev, linux-scsi
In-Reply-To: <20210920115603.3455841-1-geert@linux-m68k.org>
On Mon, 20 Sep 2021, Geert Uytterhoeven wrote:
> JFYI, when comparing v5.15-rc2[1] to v5.15-rc1[3], the summaries are:
> - build errors: +9/-49
+ /kisskb/src/arch/sparc/lib/iomap.c: error: redefinition of 'pci_iounmap': => 22:6
sparc64/sparc64-allnoconfig
+ /kisskb/src/drivers/iio/test/iio-test-format.c: error: the frame size of 2128 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]: => 98:1
powerpc-gcc{5,9,11}/powerpc-allyesconfig
+ /kisskb/src/drivers/scsi/lpfc/lpfc_init.c: error: 'struct lpfc_sli4_hba' has no member named 'c_stat': => 8280:28
+ /kisskb/src/drivers/scsi/lpfc/lpfc_scsi.c: error: 'start' undeclared (first use in this function): => 5587:2
powerpc-gcc5/skiroot_defconfig
+ /kisskb/src/drivers/thunderbolt/test.c: error: the frame size of 3104 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]: => 2207:1
powerpc-gcc5/powerpc-allyesconfig
+ /kisskb/src/drivers/tty/serial/cpm_uart/cpm_uart_core.c: error: 'udbg_cpm_getc' defined but not used [-Werror=unused-function]: => 1109:12
+ /kisskb/src/drivers/tty/serial/cpm_uart/cpm_uart_core.c: error: 'udbg_cpm_putc' defined but not used [-Werror=unused-function]: => 1095:13
powerpc-gcc5/ppc32_allmodconfig
+ /kisskb/src/drivers/usb/gadget/udc/fsl_qe_udc.c: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]: 1496:12, 970:13, 842:13 => 842:13, 970:13, 1496:33, 1496:12, 970:41, 842:41
+ /kisskb/src/drivers/usb/gadget/udc/fsl_qe_udc.c: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]: 1497:27, 843:28, 971:28 => 971:28, 843:56, 971:56, 843:28, 1497:27, 1497:48
powerpc-gcc{5,9,11}/ppc64_book3e_allmodconfig
> [1] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/e4e737bb5c170df6135a127739a9e6148ee3da82/ (90 out of 182 configs)
> [3] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/6880fa6c56601bb8ed59df6c30fd390cc5f6dd8f/ (all 182 configs)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v3] lib/zlib_inflate/inffast: Check config in C to avoid unused function warning
From: Nathan Chancellor @ 2021-09-20 15:45 UTC (permalink / raw)
To: Paul Menzel
Cc: llvm, Zhen Lei, Nick Desaulniers, linux-kernel, Paul Mackerras,
Andrew Morton, linuxppc-dev
In-Reply-To: <20210920084332.5752-1-pmenzel@molgen.mpg.de>
On Mon, Sep 20, 2021 at 10:43:33AM +0200, Paul Menzel wrote:
> Building Linux for ppc64le with Ubuntu clang version 12.0.0-3ubuntu1~21.04.1
> shows the warning below.
>
> arch/powerpc/boot/inffast.c:20:1: warning: unused function 'get_unaligned16' [-Wunused-function]
> get_unaligned16(const unsigned short *p)
> ^
> 1 warning generated.
>
> Fix it, by moving the check from the preprocessor to C, so the compiler
> sees the use.
>
> Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Tested-by: Nathan Chancellor <nathan@kernel.org>
> ---
> v2: Use IS_ENABLED
> v3: Use if statement over ternary operator as requested by Christophe
>
> lib/zlib_inflate/inffast.c | 13 ++++++-------
> 1 file changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/lib/zlib_inflate/inffast.c b/lib/zlib_inflate/inffast.c
> index f19c4fbe1be7..2843f9bb42ac 100644
> --- a/lib/zlib_inflate/inffast.c
> +++ b/lib/zlib_inflate/inffast.c
> @@ -253,13 +253,12 @@ void inflate_fast(z_streamp strm, unsigned start)
>
> sfrom = (unsigned short *)(from);
> loops = len >> 1;
> - do
> -#ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
> - *sout++ = *sfrom++;
> -#else
> - *sout++ = get_unaligned16(sfrom++);
> -#endif
> - while (--loops);
> + do {
> + if (IS_ENABLED(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS))
> + *sout++ = *sfrom++;
> + else
> + *sout++ = get_unaligned16(sfrom++);
> + } while (--loops);
> out = (unsigned char *)sout;
> from = (unsigned char *)sfrom;
> } else { /* dist == 1 or dist == 2 */
> --
> 2.33.0
>
^ permalink raw reply
* [Bug 213803] G5 kernel build (v5.14-rc2) fails at linking stage - ld: arch/powerpc/mm/pgtable.o: in function `.__ptep_set_access_flags': /usr/src/linux-stable/./arch/powerpc/include/asm/book3s/64/pgtable.h:824: undefined reference to `.radix__ptep_set_access_flags'
From: bugzilla-daemon @ 2021-09-20 16:20 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-213803-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=213803
Erhard F. (erhard_f@mailbox.org) changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |CODE_FIX
--- Comment #2 from Erhard F. (erhard_f@mailbox.org) ---
The fix went into v5.15-rc2.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* [PATCH] pseries/eeh: fix the kdump kernel crash during eeh_pseries_init
From: Mahesh Salgaonkar @ 2021-09-20 16:33 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Wen Xiong, Oliver O'Halloran
On pseries lpar when an empty slot is assigned to partition OR on single
lpar mode, kdump kernel crashes during issuing PHB reset. In the kdump
scenario, we traverse all PHBs and issue reset using the pe_config_addr of
first child device present under each PHB. However the code assumes that
none of the PHB slot can be empty and uses list_first_entry() to get first
child device under PHB. Since list_first_entry() expect list to be not
empty, it returns invalid pci_dn entry and ends up accessing NULL phb
pointer under pci_dn->phb causing kdump kernel crash.
This patch fixes the below kdump kernel crash by skipping the empty slot:
[ 0.003655] audit: initializing netlink subsys (disabled)
[ 0.003765] thermal_sys: Registered thermal governor 'fair_share'
[ 0.003767] thermal_sys: Registered thermal governor 'step_wise'
[ 0.003783] cpuidle: using governor menu
[ 0.003977] pstore: Registered nvram as persistent store backend
[ 0.004590] Issue PHB reset ...
[ 0.004794] audit: type=2000 audit(1631267818.000:1): state=initialized audit_enabled=0 res=1
[ 2.233957] BUG: Kernel NULL pointer dereference on read at 0x00000268
[ 2.233966] Faulting instruction address: 0xc000000008101fb0
[ 2.233972] Oops: Kernel access of bad area, sig: 7 [#1]
[ 2.233977] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
[ 2.233984] Modules linked in:
[ 2.233989] CPU: 7 PID: 1 Comm: swapper/7 Not tainted 5.14.0 #1
[ 2.233996] NIP: c000000008101fb0 LR: c000000009284ccc CTR: c000000008029d70
[ 2.234003] REGS: c00000001161b840 TRAP: 0300 Not tainted (5.14.0)
[ 2.234008] MSR: 8000000002009033 <SF,VEC,EE,ME,IR,DR,RI,LE> CR: 28000224 XER: 20040002
[ 2.234022] CFAR: c000000008101f0c DAR: 0000000000000268 DSISR: 00080000 IRQMASK: 0
[ 2.234022] GPR00: c000000009284ccc c00000001161bae0 c000000009c6d800 000000000000004d
[ 2.234022] GPR04: 0000000000000004 0000000000000002 c00000001161bb4c 0000000000000000
[ 2.234022] GPR08: 0000000000000000 0000000000000000 0000000000000001 c000000008e59a80
[ 2.234022] GPR12: c000000008029d70 c000000009ff0400 c00000000801285c 0000000000000000
[ 2.234022] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 2.234022] GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 2.234022] GPR24: c00000000926338c c000000009248860 c0000000092f1048 c000000011079c00
[ 2.234022] GPR28: c000000009785af8 c000000009d4b920 0000000000000000 0000000000000000
[ 2.234091] NIP [c000000008101fb0] pseries_eeh_get_pe_config_addr+0x100/0x1b0
[ 2.234100] LR [c000000009284ccc] __machine_initcall_pseries_eeh_pseries_init+0x2cc/0x350
[ 2.234108] Call Trace:
[ 2.234111] [c00000001161bae0] [c00000001161bb80] 0xc00000001161bb80 (unreliable)
[ 2.234120] [c00000001161bb80] [c000000009284ccc] __machine_initcall_pseries_eeh_pseries_init+0x2cc/0x350
[ 2.234128] [c00000001161bc00] [c000000008012210] do_one_initcall+0x60/0x2d0
[ 2.234136] [c00000001161bcd0] [c000000009264990] kernel_init_freeable+0x350/0x3f8
[ 2.234145] [c00000001161bda0] [c000000008012890] kernel_init+0x3c/0x17c
[ 2.234151] [c00000001161be10] [c00000000800cdd4] ret_from_kernel_thread+0x5c/0x64
[ 2.234159] Instruction dump:
[ 2.234163] eba1ffe8 ebc1fff0 ebe1fff8 4e800020 7c0802a6 7ce33b78 39400001 7fe7fb78
[ 2.234174] 38a00002 38800004 38c1006c f80100b0 <e91e0268> 79090020 79080022 4bf48edd
[ 2.234187] ---[ end trace bee3ba4dca6761d3 ]---
[ 2.235907]
[ 3.235914] Kernel panic - not syncing: Fatal exception
Fixes: 5a090f7c363fd ("powerpc/pseries: PCIE PHB reset")
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.ibm.com>
---
arch/powerpc/platforms/pseries/eeh_pseries.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/powerpc/platforms/pseries/eeh_pseries.c b/arch/powerpc/platforms/pseries/eeh_pseries.c
index bc15200852b7c..8780e7d33a0f5 100644
--- a/arch/powerpc/platforms/pseries/eeh_pseries.c
+++ b/arch/powerpc/platforms/pseries/eeh_pseries.c
@@ -867,6 +867,10 @@ static int __init eeh_pseries_init(void)
if (is_kdump_kernel() || reset_devices) {
pr_info("Issue PHB reset ...\n");
list_for_each_entry(phb, &hose_list, list_node) {
+ /* Skip the empty slot */
+ if (list_empty(&PCI_DN(phb->dn)->child_list))
+ continue;
+
pdn = list_first_entry(&PCI_DN(phb->dn)->child_list, struct pci_dn, list);
config_addr = pseries_eeh_get_pe_config_addr(pdn);
^ permalink raw reply related
* [PATCH 4.4 103/133] hvsi: dont panic on tty_register_driver failure
From: Greg Kroah-Hartman @ 2021-09-20 16:43 UTC (permalink / raw)
To: linux-kernel
Cc: Sasha Levin, Greg Kroah-Hartman, Jiri Slaby, linuxppc-dev, stable
In-Reply-To: <20210920163912.603434365@linuxfoundation.org>
From: Jiri Slaby <jslaby@suse.cz>
[ Upstream commit 7ccbdcc4d08a6d7041e4849219bbb12ffa45db4c ]
The alloc_tty_driver failure is handled gracefully in hvsi_init. But
tty_register_driver is not. panic is called if that one fails.
So handle the failure of tty_register_driver gracefully too. This will
keep at least the console functional as it was enabled earlier by
console_initcall in hvsi_console_init. Instead of shooting down the
whole system.
This means, we disable interrupts and restore hvsi_wait back to
poll_for_state().
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20210723074317.32690-3-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/tty/hvc/hvsi.c | 19 ++++++++++++++++---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/hvc/hvsi.c b/drivers/tty/hvc/hvsi.c
index a75146f600cb..3e29f5f0d4ca 100644
--- a/drivers/tty/hvc/hvsi.c
+++ b/drivers/tty/hvc/hvsi.c
@@ -1051,7 +1051,7 @@ static const struct tty_operations hvsi_ops = {
static int __init hvsi_init(void)
{
- int i;
+ int i, ret;
hvsi_driver = alloc_tty_driver(hvsi_count);
if (!hvsi_driver)
@@ -1082,12 +1082,25 @@ static int __init hvsi_init(void)
}
hvsi_wait = wait_for_state; /* irqs active now */
- if (tty_register_driver(hvsi_driver))
- panic("Couldn't register hvsi console driver\n");
+ ret = tty_register_driver(hvsi_driver);
+ if (ret) {
+ pr_err("Couldn't register hvsi console driver\n");
+ goto err_free_irq;
+ }
printk(KERN_DEBUG "HVSI: registered %i devices\n", hvsi_count);
return 0;
+err_free_irq:
+ hvsi_wait = poll_for_state;
+ for (i = 0; i < hvsi_count; i++) {
+ struct hvsi_struct *hp = &hvsi_ports[i];
+
+ free_irq(hp->virq, hp);
+ }
+ tty_driver_kref_put(hvsi_driver);
+
+ return ret;
}
device_initcall(hvsi_init);
--
2.30.2
^ permalink raw reply related
* [PATCH 4.9 127/175] hvsi: dont panic on tty_register_driver failure
From: Greg Kroah-Hartman @ 2021-09-20 16:42 UTC (permalink / raw)
To: linux-kernel
Cc: Sasha Levin, Greg Kroah-Hartman, Jiri Slaby, linuxppc-dev, stable
In-Reply-To: <20210920163918.068823680@linuxfoundation.org>
From: Jiri Slaby <jslaby@suse.cz>
[ Upstream commit 7ccbdcc4d08a6d7041e4849219bbb12ffa45db4c ]
The alloc_tty_driver failure is handled gracefully in hvsi_init. But
tty_register_driver is not. panic is called if that one fails.
So handle the failure of tty_register_driver gracefully too. This will
keep at least the console functional as it was enabled earlier by
console_initcall in hvsi_console_init. Instead of shooting down the
whole system.
This means, we disable interrupts and restore hvsi_wait back to
poll_for_state().
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20210723074317.32690-3-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/tty/hvc/hvsi.c | 19 ++++++++++++++++---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/hvc/hvsi.c b/drivers/tty/hvc/hvsi.c
index 96ce6bd1cc6f..4b6f93067ae4 100644
--- a/drivers/tty/hvc/hvsi.c
+++ b/drivers/tty/hvc/hvsi.c
@@ -1051,7 +1051,7 @@ static const struct tty_operations hvsi_ops = {
static int __init hvsi_init(void)
{
- int i;
+ int i, ret;
hvsi_driver = alloc_tty_driver(hvsi_count);
if (!hvsi_driver)
@@ -1082,12 +1082,25 @@ static int __init hvsi_init(void)
}
hvsi_wait = wait_for_state; /* irqs active now */
- if (tty_register_driver(hvsi_driver))
- panic("Couldn't register hvsi console driver\n");
+ ret = tty_register_driver(hvsi_driver);
+ if (ret) {
+ pr_err("Couldn't register hvsi console driver\n");
+ goto err_free_irq;
+ }
printk(KERN_DEBUG "HVSI: registered %i devices\n", hvsi_count);
return 0;
+err_free_irq:
+ hvsi_wait = poll_for_state;
+ for (i = 0; i < hvsi_count; i++) {
+ struct hvsi_struct *hp = &hvsi_ports[i];
+
+ free_irq(hp->virq, hp);
+ }
+ tty_driver_kref_put(hvsi_driver);
+
+ return ret;
}
device_initcall(hvsi_init);
--
2.30.2
^ permalink raw reply related
* [PATCH 4.14 154/217] hvsi: dont panic on tty_register_driver failure
From: Greg Kroah-Hartman @ 2021-09-20 16:42 UTC (permalink / raw)
To: linux-kernel
Cc: Sasha Levin, Greg Kroah-Hartman, Jiri Slaby, linuxppc-dev, stable
In-Reply-To: <20210920163924.591371269@linuxfoundation.org>
From: Jiri Slaby <jslaby@suse.cz>
[ Upstream commit 7ccbdcc4d08a6d7041e4849219bbb12ffa45db4c ]
The alloc_tty_driver failure is handled gracefully in hvsi_init. But
tty_register_driver is not. panic is called if that one fails.
So handle the failure of tty_register_driver gracefully too. This will
keep at least the console functional as it was enabled earlier by
console_initcall in hvsi_console_init. Instead of shooting down the
whole system.
This means, we disable interrupts and restore hvsi_wait back to
poll_for_state().
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20210723074317.32690-3-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/tty/hvc/hvsi.c | 19 ++++++++++++++++---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/hvc/hvsi.c b/drivers/tty/hvc/hvsi.c
index 2e578d6433af..7d7fdfc578a9 100644
--- a/drivers/tty/hvc/hvsi.c
+++ b/drivers/tty/hvc/hvsi.c
@@ -1051,7 +1051,7 @@ static const struct tty_operations hvsi_ops = {
static int __init hvsi_init(void)
{
- int i;
+ int i, ret;
hvsi_driver = alloc_tty_driver(hvsi_count);
if (!hvsi_driver)
@@ -1082,12 +1082,25 @@ static int __init hvsi_init(void)
}
hvsi_wait = wait_for_state; /* irqs active now */
- if (tty_register_driver(hvsi_driver))
- panic("Couldn't register hvsi console driver\n");
+ ret = tty_register_driver(hvsi_driver);
+ if (ret) {
+ pr_err("Couldn't register hvsi console driver\n");
+ goto err_free_irq;
+ }
printk(KERN_DEBUG "HVSI: registered %i devices\n", hvsi_count);
return 0;
+err_free_irq:
+ hvsi_wait = poll_for_state;
+ for (i = 0; i < hvsi_count; i++) {
+ struct hvsi_struct *hp = &hvsi_ports[i];
+
+ free_irq(hp->virq, hp);
+ }
+ tty_driver_kref_put(hvsi_driver);
+
+ return ret;
}
device_initcall(hvsi_init);
--
2.30.2
^ permalink raw reply related
* [PATCH 4.19 198/293] hvsi: dont panic on tty_register_driver failure
From: Greg Kroah-Hartman @ 2021-09-20 16:42 UTC (permalink / raw)
To: linux-kernel
Cc: Sasha Levin, Greg Kroah-Hartman, Jiri Slaby, linuxppc-dev, stable
In-Reply-To: <20210920163933.258815435@linuxfoundation.org>
From: Jiri Slaby <jslaby@suse.cz>
[ Upstream commit 7ccbdcc4d08a6d7041e4849219bbb12ffa45db4c ]
The alloc_tty_driver failure is handled gracefully in hvsi_init. But
tty_register_driver is not. panic is called if that one fails.
So handle the failure of tty_register_driver gracefully too. This will
keep at least the console functional as it was enabled earlier by
console_initcall in hvsi_console_init. Instead of shooting down the
whole system.
This means, we disable interrupts and restore hvsi_wait back to
poll_for_state().
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20210723074317.32690-3-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/tty/hvc/hvsi.c | 19 ++++++++++++++++---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/hvc/hvsi.c b/drivers/tty/hvc/hvsi.c
index 66f95f758be0..73226337f561 100644
--- a/drivers/tty/hvc/hvsi.c
+++ b/drivers/tty/hvc/hvsi.c
@@ -1038,7 +1038,7 @@ static const struct tty_operations hvsi_ops = {
static int __init hvsi_init(void)
{
- int i;
+ int i, ret;
hvsi_driver = alloc_tty_driver(hvsi_count);
if (!hvsi_driver)
@@ -1069,12 +1069,25 @@ static int __init hvsi_init(void)
}
hvsi_wait = wait_for_state; /* irqs active now */
- if (tty_register_driver(hvsi_driver))
- panic("Couldn't register hvsi console driver\n");
+ ret = tty_register_driver(hvsi_driver);
+ if (ret) {
+ pr_err("Couldn't register hvsi console driver\n");
+ goto err_free_irq;
+ }
printk(KERN_DEBUG "HVSI: registered %i devices\n", hvsi_count);
return 0;
+err_free_irq:
+ hvsi_wait = poll_for_state;
+ for (i = 0; i < hvsi_count; i++) {
+ struct hvsi_struct *hp = &hvsi_ports[i];
+
+ free_irq(hp->virq, hp);
+ }
+ tty_driver_kref_put(hvsi_driver);
+
+ return ret;
}
device_initcall(hvsi_init);
--
2.30.2
^ permalink raw reply related
* [PATCH 5.4 107/260] hvsi: dont panic on tty_register_driver failure
From: Greg Kroah-Hartman @ 2021-09-20 16:42 UTC (permalink / raw)
To: linux-kernel
Cc: Sasha Levin, Greg Kroah-Hartman, Jiri Slaby, linuxppc-dev, stable
In-Reply-To: <20210920163931.123590023@linuxfoundation.org>
From: Jiri Slaby <jslaby@suse.cz>
[ Upstream commit 7ccbdcc4d08a6d7041e4849219bbb12ffa45db4c ]
The alloc_tty_driver failure is handled gracefully in hvsi_init. But
tty_register_driver is not. panic is called if that one fails.
So handle the failure of tty_register_driver gracefully too. This will
keep at least the console functional as it was enabled earlier by
console_initcall in hvsi_console_init. Instead of shooting down the
whole system.
This means, we disable interrupts and restore hvsi_wait back to
poll_for_state().
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20210723074317.32690-3-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/tty/hvc/hvsi.c | 19 ++++++++++++++++---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/hvc/hvsi.c b/drivers/tty/hvc/hvsi.c
index 66f95f758be0..73226337f561 100644
--- a/drivers/tty/hvc/hvsi.c
+++ b/drivers/tty/hvc/hvsi.c
@@ -1038,7 +1038,7 @@ static const struct tty_operations hvsi_ops = {
static int __init hvsi_init(void)
{
- int i;
+ int i, ret;
hvsi_driver = alloc_tty_driver(hvsi_count);
if (!hvsi_driver)
@@ -1069,12 +1069,25 @@ static int __init hvsi_init(void)
}
hvsi_wait = wait_for_state; /* irqs active now */
- if (tty_register_driver(hvsi_driver))
- panic("Couldn't register hvsi console driver\n");
+ ret = tty_register_driver(hvsi_driver);
+ if (ret) {
+ pr_err("Couldn't register hvsi console driver\n");
+ goto err_free_irq;
+ }
printk(KERN_DEBUG "HVSI: registered %i devices\n", hvsi_count);
return 0;
+err_free_irq:
+ hvsi_wait = poll_for_state;
+ for (i = 0; i < hvsi_count; i++) {
+ struct hvsi_struct *hp = &hvsi_ports[i];
+
+ free_irq(hp->virq, hp);
+ }
+ tty_driver_kref_put(hvsi_driver);
+
+ return ret;
}
device_initcall(hvsi_init);
--
2.30.2
^ permalink raw reply related
* [PATCH] powerpc/pseries: delete scanlog
From: Nathan Lynch @ 2021-09-20 17:32 UTC (permalink / raw)
To: linuxppc-dev; +Cc: tyreld
Remove the pseries scanlog driver.
This code supports functions from Power4-era servers that are not present
on targets currently supported by arch/powerpc. System manuals from this
time have this description:
Scan Dump data is a set of chip data that the service processor gathers
after a system malfunction. It consists of chip scan rings, chip trace
arrays, and Scan COM (SCOM) registers. This data is stored in the
scan-log partition of the system’s Nonvolatile Random Access
Memory (NVRAM).
PowerVM partition firmware development doesn't recognize the associated
function call or property, and they don't see any references to them in
their codebase. It seems to have been specific to non-virtualized pseries.
References:
Historical Linux commit from February 2003 (interesting to note this seems
to be the source of non-GPL exports for rtas_call etc):
https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/?id=f92e361842d5251e50562b09664082dcbd0548bb
IntelliStation and pSeries docs which refer to the feature:
http://ps-2.retropc.se/basil.holloway/ALL%20PDF/380635.pdf
http://ps-2.kev009.com/rs6000/manuals/p/p615-6C3-6E3/6C3_and_6E3_Users_Guide_SA38-0629.pdf
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Reviewed-by: Tyrel Datwyler <tyreld@linux.ibm.com>
---
arch/powerpc/configs/ppc64_defconfig | 1 -
arch/powerpc/configs/pseries_defconfig | 1 -
arch/powerpc/platforms/pseries/Kconfig | 4 -
arch/powerpc/platforms/pseries/Makefile | 1 -
arch/powerpc/platforms/pseries/scanlog.c | 195 -----------------------
5 files changed, 202 deletions(-)
delete mode 100644 arch/powerpc/platforms/pseries/scanlog.c
diff --git a/arch/powerpc/configs/ppc64_defconfig b/arch/powerpc/configs/ppc64_defconfig
index 0ad2291337a7..846815007fef 100644
--- a/arch/powerpc/configs/ppc64_defconfig
+++ b/arch/powerpc/configs/ppc64_defconfig
@@ -26,7 +26,6 @@ CONFIG_PPC64=y
CONFIG_NR_CPUS=2048
CONFIG_PPC_SPLPAR=y
CONFIG_DTL=y
-CONFIG_SCANLOG=m
CONFIG_PPC_SMLPAR=y
CONFIG_IBMEBUS=y
CONFIG_PPC_SVM=y
diff --git a/arch/powerpc/configs/pseries_defconfig b/arch/powerpc/configs/pseries_defconfig
index b183629f1bcf..42a72e6d5b35 100644
--- a/arch/powerpc/configs/pseries_defconfig
+++ b/arch/powerpc/configs/pseries_defconfig
@@ -38,7 +38,6 @@ CONFIG_MODULE_SRCVERSION_ALL=y
CONFIG_PARTITION_ADVANCED=y
CONFIG_PPC_SPLPAR=y
CONFIG_DTL=y
-CONFIG_SCANLOG=m
CONFIG_PPC_SMLPAR=y
CONFIG_IBMEBUS=y
CONFIG_PAPR_SCM=m
diff --git a/arch/powerpc/platforms/pseries/Kconfig b/arch/powerpc/platforms/pseries/Kconfig
index 5e037df2a3a1..bf9b612a929b 100644
--- a/arch/powerpc/platforms/pseries/Kconfig
+++ b/arch/powerpc/platforms/pseries/Kconfig
@@ -61,10 +61,6 @@ config PSERIES_ENERGY
Provides: /sys/devices/system/cpu/pseries_(de)activation_hint_list
and /sys/devices/system/cpu/cpuN/pseries_(de)activation_hint
-config SCANLOG
- tristate "Scanlog dump interface"
- depends on RTAS_PROC && PPC_PSERIES
-
config IO_EVENT_IRQ
bool "IO Event Interrupt support"
depends on PPC_PSERIES
diff --git a/arch/powerpc/platforms/pseries/Makefile b/arch/powerpc/platforms/pseries/Makefile
index 4cda0ef87be0..2f9ae0c113e3 100644
--- a/arch/powerpc/platforms/pseries/Makefile
+++ b/arch/powerpc/platforms/pseries/Makefile
@@ -8,7 +8,6 @@ obj-y := lpar.o hvCall.o nvram.o reconfig.o \
firmware.o power.o dlpar.o mobility.o rng.o \
pci.o pci_dlpar.o eeh_pseries.o msi.o
obj-$(CONFIG_SMP) += smp.o
-obj-$(CONFIG_SCANLOG) += scanlog.o
obj-$(CONFIG_KEXEC_CORE) += kexec.o
obj-$(CONFIG_PSERIES_ENERGY) += pseries_energy.o
diff --git a/arch/powerpc/platforms/pseries/scanlog.c b/arch/powerpc/platforms/pseries/scanlog.c
deleted file mode 100644
index 2879c4f0ceb7..000000000000
--- a/arch/powerpc/platforms/pseries/scanlog.c
+++ /dev/null
@@ -1,195 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-or-later
-/*
- * c 2001 PPC 64 Team, IBM Corp
- *
- * scan-log-data driver for PPC64 Todd Inglett <tinglett@vnet.ibm.com>
- *
- * When ppc64 hardware fails the service processor dumps internal state
- * of the system. After a reboot the operating system can access a dump
- * of this data using this driver. A dump exists if the device-tree
- * /chosen/ibm,scan-log-data property exists.
- *
- * This driver exports /proc/powerpc/scan-log-dump which can be read.
- * The driver supports only sequential reads.
- *
- * The driver looks at a write to the driver for the single word "reset".
- * If given, the driver will reset the scanlog so the platform can free it.
- */
-
-#include <linux/module.h>
-#include <linux/types.h>
-#include <linux/errno.h>
-#include <linux/proc_fs.h>
-#include <linux/init.h>
-#include <linux/delay.h>
-#include <linux/slab.h>
-#include <linux/uaccess.h>
-#include <asm/rtas.h>
-#include <asm/prom.h>
-
-#define MODULE_VERS "1.0"
-#define MODULE_NAME "scanlog"
-
-/* Status returns from ibm,scan-log-dump */
-#define SCANLOG_COMPLETE 0
-#define SCANLOG_HWERROR -1
-#define SCANLOG_CONTINUE 1
-
-
-static unsigned int ibm_scan_log_dump; /* RTAS token */
-static unsigned int *scanlog_buffer; /* The data buffer */
-
-static ssize_t scanlog_read(struct file *file, char __user *buf,
- size_t count, loff_t *ppos)
-{
- unsigned int *data = scanlog_buffer;
- int status;
- unsigned long len, off;
- unsigned int wait_time;
-
- if (count > RTAS_DATA_BUF_SIZE)
- count = RTAS_DATA_BUF_SIZE;
-
- if (count < 1024) {
- /* This is the min supported by this RTAS call. Rather
- * than do all the buffering we insist the user code handle
- * larger reads. As long as cp works... :)
- */
- printk(KERN_ERR "scanlog: cannot perform a small read (%ld)\n", count);
- return -EINVAL;
- }
-
- if (!access_ok(buf, count))
- return -EFAULT;
-
- for (;;) {
- wait_time = 500; /* default wait if no data */
- spin_lock(&rtas_data_buf_lock);
- memcpy(rtas_data_buf, data, RTAS_DATA_BUF_SIZE);
- status = rtas_call(ibm_scan_log_dump, 2, 1, NULL,
- (u32) __pa(rtas_data_buf), (u32) count);
- memcpy(data, rtas_data_buf, RTAS_DATA_BUF_SIZE);
- spin_unlock(&rtas_data_buf_lock);
-
- pr_debug("scanlog: status=%d, data[0]=%x, data[1]=%x, " \
- "data[2]=%x\n", status, data[0], data[1], data[2]);
- switch (status) {
- case SCANLOG_COMPLETE:
- pr_debug("scanlog: hit eof\n");
- return 0;
- case SCANLOG_HWERROR:
- pr_debug("scanlog: hardware error reading data\n");
- return -EIO;
- case SCANLOG_CONTINUE:
- /* We may or may not have data yet */
- len = data[1];
- off = data[2];
- if (len > 0) {
- if (copy_to_user(buf, ((char *)data)+off, len))
- return -EFAULT;
- return len;
- }
- /* Break to sleep default time */
- break;
- default:
- /* Assume extended busy */
- wait_time = rtas_busy_delay_time(status);
- if (!wait_time) {
- printk(KERN_ERR "scanlog: unknown error " \
- "from rtas: %d\n", status);
- return -EIO;
- }
- }
- /* Apparently no data yet. Wait and try again. */
- msleep_interruptible(wait_time);
- }
- /*NOTREACHED*/
-}
-
-static ssize_t scanlog_write(struct file * file, const char __user * buf,
- size_t count, loff_t *ppos)
-{
- char stkbuf[20];
- int status;
-
- if (count > 19) count = 19;
- if (copy_from_user (stkbuf, buf, count)) {
- return -EFAULT;
- }
- stkbuf[count] = 0;
-
- if (buf) {
- if (strncmp(stkbuf, "reset", 5) == 0) {
- pr_debug("scanlog: reset scanlog\n");
- status = rtas_call(ibm_scan_log_dump, 2, 1, NULL, 0, 0);
- pr_debug("scanlog: rtas returns %d\n", status);
- }
- }
- return count;
-}
-
-static int scanlog_open(struct inode * inode, struct file * file)
-{
- unsigned int *data = scanlog_buffer;
-
- if (data[0] != 0) {
- /* This imperfect test stops a second copy of the
- * data (or a reset while data is being copied)
- */
- return -EBUSY;
- }
-
- data[0] = 0; /* re-init so we restart the scan */
-
- return 0;
-}
-
-static int scanlog_release(struct inode * inode, struct file * file)
-{
- unsigned int *data = scanlog_buffer;
-
- data[0] = 0;
- return 0;
-}
-
-static const struct proc_ops scanlog_proc_ops = {
- .proc_read = scanlog_read,
- .proc_write = scanlog_write,
- .proc_open = scanlog_open,
- .proc_release = scanlog_release,
- .proc_lseek = noop_llseek,
-};
-
-static int __init scanlog_init(void)
-{
- struct proc_dir_entry *ent;
- int err = -ENOMEM;
-
- ibm_scan_log_dump = rtas_token("ibm,scan-log-dump");
- if (ibm_scan_log_dump == RTAS_UNKNOWN_SERVICE)
- return -ENODEV;
-
- /* Ideally we could allocate a buffer < 4G */
- scanlog_buffer = kzalloc(RTAS_DATA_BUF_SIZE, GFP_KERNEL);
- if (!scanlog_buffer)
- goto err;
-
- ent = proc_create("powerpc/rtas/scan-log-dump", 0400, NULL,
- &scanlog_proc_ops);
- if (!ent)
- goto err;
- return 0;
-err:
- kfree(scanlog_buffer);
- return err;
-}
-
-static void __exit scanlog_cleanup(void)
-{
- remove_proc_entry("powerpc/rtas/scan-log-dump", NULL);
- kfree(scanlog_buffer);
-}
-
-module_init(scanlog_init);
-module_exit(scanlog_cleanup);
-MODULE_LICENSE("GPL");
--
2.31.1
^ permalink raw reply related
* Re: [PATCH] agp: define proper stubs for empty helpers
From: Sam Ravnborg @ 2021-09-20 16:17 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-fbdev, linux-parisc, Arnd Bergmann, Helge Deller,
linux-kernel, dri-devel, James E.J. Bottomley, Paul Mackerras,
sparclinux, linuxppc-dev, David S. Miller
In-Reply-To: <20210920121728.94045-1-arnd@kernel.org>
On Mon, Sep 20, 2021 at 02:17:19PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> The empty unmap_page_from_agp() macro causes a warning when
> building with 'make W=1' on a couple of architectures:
>
> drivers/char/agp/generic.c: In function 'agp_generic_destroy_page':
> drivers/char/agp/generic.c:1265:28: error: suggest braces around empty body in an 'if' statement [-Werror=empty-body]
> 1265 | unmap_page_from_agp(page);
>
> Change the definitions to a 'do { } while (0)' construct to
> make these more reliable.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Looks good.
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Sam
^ permalink raw reply
* Re: [PATCH] agp: define proper stubs for empty helpers
From: Helge Deller @ 2021-09-20 18:01 UTC (permalink / raw)
To: Arnd Bergmann, linux-fbdev, James E.J. Bottomley,
Michael Ellerman, David S. Miller
Cc: linux-parisc, Arnd Bergmann, linux-kernel, dri-devel,
Paul Mackerras, sparclinux, linuxppc-dev
In-Reply-To: <20210920121728.94045-1-arnd@kernel.org>
On 9/20/21 2:17 PM, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> The empty unmap_page_from_agp() macro causes a warning when
> building with 'make W=1' on a couple of architectures:
>
> drivers/char/agp/generic.c: In function 'agp_generic_destroy_page':
> drivers/char/agp/generic.c:1265:28: error: suggest braces around empty body in an 'if' statement [-Werror=empty-body]
> 1265 | unmap_page_from_agp(page);
>
> Change the definitions to a 'do { } while (0)' construct to
> make these more reliable.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Helge Deller <deller@gmx.de> # parisc
Thanks,
Helge
> ---
> arch/parisc/include/asm/agp.h | 4 ++--
> arch/powerpc/include/asm/agp.h | 4 ++--
> arch/sparc/include/asm/agp.h | 6 +++---
> 3 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/arch/parisc/include/asm/agp.h b/arch/parisc/include/asm/agp.h
> index cb04470e63d0..14ae54cfd368 100644
> --- a/arch/parisc/include/asm/agp.h
> +++ b/arch/parisc/include/asm/agp.h
> @@ -8,8 +8,8 @@
> *
> */
>
> -#define map_page_into_agp(page) /* nothing */
> -#define unmap_page_from_agp(page) /* nothing */
> +#define map_page_into_agp(page) do { } while (0)
> +#define unmap_page_from_agp(page) do { } while (0)
> #define flush_agp_cache() mb()
>
> /* GATT allocation. Returns/accepts GATT kernel virtual address. */
> diff --git a/arch/powerpc/include/asm/agp.h b/arch/powerpc/include/asm/agp.h
> index b29b1186f819..6b6485c988dd 100644
> --- a/arch/powerpc/include/asm/agp.h
> +++ b/arch/powerpc/include/asm/agp.h
> @@ -5,8 +5,8 @@
>
> #include <asm/io.h>
>
> -#define map_page_into_agp(page)
> -#define unmap_page_from_agp(page)
> +#define map_page_into_agp(page) do {} while (0)
> +#define unmap_page_from_agp(page) do {} while (0)
> #define flush_agp_cache() mb()
>
> /* GATT allocation. Returns/accepts GATT kernel virtual address. */
> diff --git a/arch/sparc/include/asm/agp.h b/arch/sparc/include/asm/agp.h
> index efe0d6a12e5a..2d0ff84cee3f 100644
> --- a/arch/sparc/include/asm/agp.h
> +++ b/arch/sparc/include/asm/agp.h
> @@ -4,9 +4,9 @@
>
> /* dummy for now */
>
> -#define map_page_into_agp(page)
> -#define unmap_page_from_agp(page)
> -#define flush_agp_cache() mb()
> +#define map_page_into_agp(page) do { } while (0)
> +#define unmap_page_from_agp(page) do { } while (0)
> +#define flush_agp_cache() mb()
>
> /* GATT allocation. Returns/accepts GATT kernel virtual address. */
> #define alloc_gatt_pages(order) \
>
^ permalink raw reply
* Re: [PATCH v3 5/8] x86/sme: Replace occurrences of sme_active() with cc_platform_has()
From: Kirill A. Shutemov @ 2021-09-20 19:23 UTC (permalink / raw)
To: Tom Lendacky
Cc: Sathyanarayanan Kuppuswamy, linux-efi, Brijesh Singh, kvm,
Peter Zijlstra, Dave Hansen, dri-devel, platform-driver-x86,
Will Deacon, linux-s390, Andi Kleen, Joerg Roedel, x86, amd-gfx,
Christoph Hellwig, Ingo Molnar, linux-graphics-maintainer,
Tianyu Lan, Borislav Petkov, Andy Lutomirski, Thomas Gleixner,
kexec, linux-kernel, iommu, linux-fsdevel, linuxppc-dev
In-Reply-To: <367624d43d35d61d5c97a8b289d9ddae223636e9.1631141919.git.thomas.lendacky@amd.com>
On Wed, Sep 08, 2021 at 05:58:36PM -0500, Tom Lendacky wrote:
> diff --git a/arch/x86/mm/mem_encrypt_identity.c b/arch/x86/mm/mem_encrypt_identity.c
> index 470b20208430..eff4d19f9cb4 100644
> --- a/arch/x86/mm/mem_encrypt_identity.c
> +++ b/arch/x86/mm/mem_encrypt_identity.c
> @@ -30,6 +30,7 @@
> #include <linux/kernel.h>
> #include <linux/mm.h>
> #include <linux/mem_encrypt.h>
> +#include <linux/cc_platform.h>
>
> #include <asm/setup.h>
> #include <asm/sections.h>
> @@ -287,7 +288,7 @@ void __init sme_encrypt_kernel(struct boot_params *bp)
> unsigned long pgtable_area_len;
> unsigned long decrypted_base;
>
> - if (!sme_active())
> + if (!cc_platform_has(CC_ATTR_HOST_MEM_ENCRYPT))
> return;
>
> /*
This change break boot for me (in KVM on Intel host). It only reproduces
with allyesconfig. More reasonable config works fine, but I didn't try to
find exact cause in config.
Convertion to cc_platform_has() in __startup_64() in 8/8 has the same
effect.
I believe it caused by sme_me_mask access from __startup_64() without
fixup_pointer() magic. I think __startup_64() requires special treatement
and we should avoid cc_platform_has() there (or have a special version of
the helper). Note that only AMD requires these cc_platform_has() to return
true.
--
Kirill A. Shutemov
^ permalink raw reply
* [PATCH] ASoC: fsl: Constify static snd_soc_ops
From: Rikard Falkeborn @ 2021-09-20 19:39 UTC (permalink / raw)
To: Nicolin Chen, Xiubo Li, Jaroslav Kysela, Takashi Iwai, Shawn Guo,
Sascha Hauer
Cc: alsa-devel, Fabio Estevam, linuxppc-dev, Liam Girdwood,
Rikard Falkeborn, linux-kernel, Mark Brown, NXP Linux Team,
Pengutronix Kernel Team, Shengjiu Wang, linux-arm-kernel
These are only assigned to the ops field in the snd_soc_dai_link struct
which is a pointer to const struct snd_soc_ops. Make them const to allow
the compiler to put them in read-only memory.
Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com>
---
sound/soc/fsl/imx-audmix.c | 4 ++--
sound/soc/fsl/imx-card.c | 4 ++--
sound/soc/fsl/imx-hdmi.c | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/sound/soc/fsl/imx-audmix.c b/sound/soc/fsl/imx-audmix.c
index a364e2415de0..0d637929bfef 100644
--- a/sound/soc/fsl/imx-audmix.c
+++ b/sound/soc/fsl/imx-audmix.c
@@ -132,12 +132,12 @@ static int imx_audmix_be_hw_params(struct snd_pcm_substream *substream,
return ret;
}
-static struct snd_soc_ops imx_audmix_fe_ops = {
+static const struct snd_soc_ops imx_audmix_fe_ops = {
.startup = imx_audmix_fe_startup,
.hw_params = imx_audmix_fe_hw_params,
};
-static struct snd_soc_ops imx_audmix_be_ops = {
+static const struct snd_soc_ops imx_audmix_be_ops = {
.hw_params = imx_audmix_be_hw_params,
};
diff --git a/sound/soc/fsl/imx-card.c b/sound/soc/fsl/imx-card.c
index 58fd0639a069..05dff2dc1d19 100644
--- a/sound/soc/fsl/imx-card.c
+++ b/sound/soc/fsl/imx-card.c
@@ -442,12 +442,12 @@ static int imx_aif_startup(struct snd_pcm_substream *substream)
return ret;
}
-static struct snd_soc_ops imx_aif_ops = {
+static const struct snd_soc_ops imx_aif_ops = {
.hw_params = imx_aif_hw_params,
.startup = imx_aif_startup,
};
-static struct snd_soc_ops imx_aif_ops_be = {
+static const struct snd_soc_ops imx_aif_ops_be = {
.hw_params = imx_aif_hw_params,
};
diff --git a/sound/soc/fsl/imx-hdmi.c b/sound/soc/fsl/imx-hdmi.c
index 34a0dceae621..2b663c39edb2 100644
--- a/sound/soc/fsl/imx-hdmi.c
+++ b/sound/soc/fsl/imx-hdmi.c
@@ -59,7 +59,7 @@ static int imx_hdmi_hw_params(struct snd_pcm_substream *substream,
return 0;
}
-static struct snd_soc_ops imx_hdmi_ops = {
+static const struct snd_soc_ops imx_hdmi_ops = {
.hw_params = imx_hdmi_hw_params,
};
--
2.33.0
^ permalink raw reply related
* Re: [PATCH v4 1/3] powerpc/bitops: Use immediate operand when possible
From: Segher Boessenkool @ 2021-09-20 21:23 UTC (permalink / raw)
To: Christophe Leroy; +Cc: Paul Mackerras, linuxppc-dev, linux-kernel
In-Reply-To: <db9d01d5c543c5add4b2beadb03d39e99c7ada2c.1632126669.git.christophe.leroy@csgroup.eu>
Hi!
On Mon, Sep 20, 2021 at 10:31:17AM +0200, Christophe Leroy wrote:
> Today we get the following code generation for bitops like
> set or clear bit:
>
> c0009fe0: 39 40 08 00 li r10,2048
> c0009fe4: 7c e0 40 28 lwarx r7,0,r8
> c0009fe8: 7c e7 53 78 or r7,r7,r10
> c0009fec: 7c e0 41 2d stwcx. r7,0,r8
>
> c000d568: 39 00 18 00 li r8,6144
> c000d56c: 7c c0 38 28 lwarx r6,0,r7
> c000d570: 7c c6 40 78 andc r6,r6,r8
> c000d574: 7c c0 39 2d stwcx. r6,0,r7
>
> Most set bits are constant on lower 16 bits, so it can easily
> be replaced by the "immediate" version of the operation. Allow
> GCC to choose between the normal or immediate form.
You can also handle the second sixteen bits (the "shifted" half), by
using oris etc. The "%eN" output modifier prints an "s" for this:
/* If the low 16 bits are 0, but some other bit is set, write 's'. */
But this doesn't handle non-constant arguments, so you're likely better
off using what you have noe.
> For clear bits, on 32 bits 'rlwinm' can be used instead of 'andc' for
> when all bits to be cleared are consecutive.
Or when all you want to keep are consecutive (you do handle that now :-) )
> On 64 bits we don't have any equivalent single operation for clearing,
> single bits or a few bits, we'd need two 'rldicl' so it is not
> worth it, the li/andc sequence is doing the same.
You can use rlwinm whenever you want to clear all top 32 bits.
A sometimes nice idiom is ori x,x,N ; xori x,x,N to clear the bits N
(or oris/xoris). But it's two insns no matter what (but no spare
register is needed).
> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> +static inline unsigned long test_and_clear_bits(unsigned long mask, volatile unsigned long *_p)
> +{
> + unsigned long old, t;
> + unsigned long *p = (unsigned long *)_p;
> +
> + if (IS_ENABLED(CONFIG_PPC32) &&
> + __builtin_constant_p(mask) && is_rlwinm_mask_valid(mask)) {
is_rlwinm_mask_valid(~mask)? So that test_and_clear_bits(0, ...) will
work with rlwinm, and test_and_clear_bits(0xffffffff, ...) will not make
gas scream bloody murder ("illegal bitmask"). Tha mask you pass to the
instruction is ~mask after all.
Looks great except that one nit. Thanks :-)
Reviewed-by: Segher Boessenkool <segher@kernel.crashing.org>
Segher
^ permalink raw reply
* Re: [PATCH 1/3] powerpc/pseries/cpuhp: cache node corrections
From: Daniel Henrique Barboza @ 2021-09-20 23:59 UTC (permalink / raw)
To: Nathan Lynch, linuxppc-dev; +Cc: tyreld, ldufour, aneesh.kumar
In-Reply-To: <20210920135504.1792219-2-nathanl@linux.ibm.com>
On 9/20/21 10:55, Nathan Lynch wrote:
> On pseries, cache nodes in the device tree can be added and removed by the
> CPU DLPAR code as well as the partition migration (mobility) code. PowerVM
> partitions in dedicated processor mode typically have L2 and L3 cache
> nodes.
>
> The CPU DLPAR code has the following shortcomings:
>
> * Cache nodes returned as siblings of a new CPU node by
> ibm,configure-connector are silently discarded; only the CPU node is
> added to the device tree.
>
> * Cache nodes which become unreferenced in the processor removal path are
> not removed from the device tree. This can lead to duplicate nodes when
> the post-migration device tree update code replaces cache nodes.
>
> This is long-standing behavior. Presumably it has gone mostly unnoticed
> because the two bugs have the property of obscuring each other in common
> simple scenarios (e.g. remove a CPU and add it back). Likely you'd notice
> only if you cared to inspect the device tree or the sysfs cacheinfo
> information.
>
> Booted with two processors:
>
> $ pwd
> /sys/firmware/devicetree/base/cpus
> $ ls -1d */
> l2-cache@2010/
> l2-cache@2011/
> l3-cache@3110/
> l3-cache@3111/
> PowerPC,POWER9@0/
> PowerPC,POWER9@8/
> $ lsprop */l2-cache
> l2-cache@2010/l2-cache
> 00003110 (12560)
> l2-cache@2011/l2-cache
> 00003111 (12561)
> PowerPC,POWER9@0/l2-cache
> 00002010 (8208)
> PowerPC,POWER9@8/l2-cache
> 00002011 (8209)
> $ ls /sys/devices/system/cpu/cpu0/cache/
> index0 index1 index2 index3
>
> After DLPAR-adding PowerPC,POWER9@10, we see that its associated cache
> nodes are absent, its threads' L2+L3 cacheinfo is unpopulated, and it is
> missing a cache level in its sched domain hierarchy:
>
> $ ls -1d */
> l2-cache@2010/
> l2-cache@2011/
> l3-cache@3110/
> l3-cache@3111/
> PowerPC,POWER9@0/
> PowerPC,POWER9@10/
> PowerPC,POWER9@8/
> $ lsprop PowerPC\,POWER9@10/l2-cache
> PowerPC,POWER9@10/l2-cache
> 00002012 (8210)
> $ ls /sys/devices/system/cpu/cpu16/cache/
> index0 index1
> $ grep . /sys/kernel/debug/sched/domains/cpu{0,8,16}/domain*/name
> /sys/kernel/debug/sched/domains/cpu0/domain0/name:SMT
> /sys/kernel/debug/sched/domains/cpu0/domain1/name:CACHE
> /sys/kernel/debug/sched/domains/cpu0/domain2/name:DIE
> /sys/kernel/debug/sched/domains/cpu8/domain0/name:SMT
> /sys/kernel/debug/sched/domains/cpu8/domain1/name:CACHE
> /sys/kernel/debug/sched/domains/cpu8/domain2/name:DIE
> /sys/kernel/debug/sched/domains/cpu16/domain0/name:SMT
> /sys/kernel/debug/sched/domains/cpu16/domain1/name:DIE
>
> When removing PowerPC,POWER9@8, we see that its cache nodes are left
> behind:
>
> $ ls -1d */
> l2-cache@2010/
> l2-cache@2011/
> l3-cache@3110/
> l3-cache@3111/
> PowerPC,POWER9@0/
>
> When DLPAR is combined with VM migration, we can get duplicate nodes. E.g.
> removing one processor, then migrating, adding a processor, and then
> migrating again can result in warnings from the OF core during
> post-migration device tree updates:
>
> Duplicate name in cpus, renamed to "l2-cache@2011#1"
> Duplicate name in cpus, renamed to "l3-cache@3111#1"
>
> and nodes with duplicated phandles in the tree, making lookup behavior
> unpredictable:
>
> $ lsprop l[23]-cache@*/ibm,phandle
> l2-cache@2010/ibm,phandle
> 00002010 (8208)
> l2-cache@2011#1/ibm,phandle
> 00002011 (8209)
> l2-cache@2011/ibm,phandle
> 00002011 (8209)
> l3-cache@3110/ibm,phandle
> 00003110 (12560)
> l3-cache@3111#1/ibm,phandle
> 00003111 (12561)
> l3-cache@3111/ibm,phandle
> 00003111 (12561)
>
> Address these issues by:
>
> * Correctly processing siblings of the node returned from
> dlpar_configure_connector().
> * Removing cache nodes in the CPU remove path when it can be determined
> that they are not associated with other CPUs or caches.
>
> Use the of_changeset API in both cases, which allows us to keep the error
> handling in this code from becoming more complex while ensuring that the
> device tree cannot become inconsistent.
>
> Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
> Fixes: ac71380 ("powerpc/pseries: Add CPU dlpar remove functionality")
> Fixes: 90edf18 ("powerpc/pseries: Add CPU dlpar add functionality")
> ---
> arch/powerpc/platforms/pseries/hotplug-cpu.c | 72 +++++++++++++++++++-
> 1 file changed, 70 insertions(+), 2 deletions(-)
Tested with a QEMU pseries guest, multiple CPU add/removals of the same CPU,
and no issues found with these new pseries_cpuhp* functions.
Code LGTM as well.
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Tested-by: Daniel Henrique Barboza <danielhb413@gmail.com>
>
> diff --git a/arch/powerpc/platforms/pseries/hotplug-cpu.c b/arch/powerpc/platforms/pseries/hotplug-cpu.c
> index d646c22e94ab..87a0fbe9cf12 100644
> --- a/arch/powerpc/platforms/pseries/hotplug-cpu.c
> +++ b/arch/powerpc/platforms/pseries/hotplug-cpu.c
> @@ -521,6 +521,27 @@ static bool valid_cpu_drc_index(struct device_node *parent, u32 drc_index)
> return found;
> }
>
> +static int pseries_cpuhp_attach_nodes(struct device_node *dn)
> +{
> + struct of_changeset cs;
> + int ret;
> +
> + /*
> + * This device node is unattached but may have siblings; open-code the
> + * traversal.
> + */
> + for (of_changeset_init(&cs); dn != NULL; dn = dn->sibling) {
> + ret = of_changeset_attach_node(&cs, dn);
> + if (ret)
> + goto out;
> + }
> +
> + ret = of_changeset_apply(&cs);
> +out:
> + of_changeset_destroy(&cs);
> + return ret;
> +}
> +
> static ssize_t dlpar_cpu_add(u32 drc_index)
> {
> struct device_node *dn, *parent;
> @@ -563,7 +584,7 @@ static ssize_t dlpar_cpu_add(u32 drc_index)
> return -EINVAL;
> }
>
> - rc = dlpar_attach_node(dn, parent);
> + rc = pseries_cpuhp_attach_nodes(dn);
>
> /* Regardless we are done with parent now */
> of_node_put(parent);
> @@ -600,6 +621,53 @@ static ssize_t dlpar_cpu_add(u32 drc_index)
> return rc;
> }
>
> +static unsigned int pseries_cpuhp_cache_use_count(const struct device_node *cachedn)
> +{
> + unsigned int use_count = 0;
> + struct device_node *dn;
> +
> + WARN_ON(!of_node_is_type(cachedn, "cache"));
> +
> + for_each_of_cpu_node(dn) {
> + if (of_find_next_cache_node(dn) == cachedn)
> + use_count++;
> + }
> +
> + for_each_node_by_type(dn, "cache") {
> + if (of_find_next_cache_node(dn) == cachedn)
> + use_count++;
> + }
> +
> + return use_count;
> +}
> +
> +static int pseries_cpuhp_detach_nodes(struct device_node *cpudn)
> +{
> + struct device_node *dn;
> + struct of_changeset cs;
> + int ret = 0;
> +
> + of_changeset_init(&cs);
> + ret = of_changeset_detach_node(&cs, cpudn);
> + if (ret)
> + goto out;
> +
> + dn = cpudn;
> + while ((dn = of_find_next_cache_node(dn))) {
> + if (pseries_cpuhp_cache_use_count(dn) > 1)
> + break;
> +
> + ret = of_changeset_detach_node(&cs, dn);
> + if (ret)
> + goto out;
> + }
> +
> + ret = of_changeset_apply(&cs);
> +out:
> + of_changeset_destroy(&cs);
> + return ret;
> +}
> +
> static ssize_t dlpar_cpu_remove(struct device_node *dn, u32 drc_index)
> {
> int rc;
> @@ -621,7 +689,7 @@ static ssize_t dlpar_cpu_remove(struct device_node *dn, u32 drc_index)
> return rc;
> }
>
> - rc = dlpar_detach_node(dn);
> + rc = pseries_cpuhp_detach_nodes(dn);
> if (rc) {
> int saved_rc = rc;
>
>
^ permalink raw reply
* Re: [PATCH 2/3] powerpc/cpuhp: BUG -> WARN conversion in offline path
From: Daniel Henrique Barboza @ 2021-09-21 0:05 UTC (permalink / raw)
To: Nathan Lynch, linuxppc-dev; +Cc: tyreld, ldufour, aneesh.kumar
In-Reply-To: <20210920135504.1792219-3-nathanl@linux.ibm.com>
On 9/20/21 10:55, Nathan Lynch wrote:
> If, due to bugs elsewhere, we get into unregister_cpu_online() with a CPU
> that isn't marked hotpluggable, we can emit a warning and return an
> appropriate error instead of crashing.
>
> Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
> ---
As mentioned by Christophe this will not solve the crash for kernels with
panic_on_warn, but at least it will panic with a clearer message on those
and will not panic for everyone else.
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
> arch/powerpc/kernel/sysfs.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c
> index defecb3b1b15..08d8072d6e7a 100644
> --- a/arch/powerpc/kernel/sysfs.c
> +++ b/arch/powerpc/kernel/sysfs.c
> @@ -928,7 +928,8 @@ static int unregister_cpu_online(unsigned int cpu)
> struct device_attribute *attrs, *pmc_attrs;
> int i, nattrs;
>
> - BUG_ON(!c->hotpluggable);
> + if (WARN_RATELIMIT(!c->hotpluggable, "cpu %d can't be offlined\n", cpu))
> + return -EBUSY;
>
> #ifdef CONFIG_PPC64
> if (cpu_has_feature(CPU_FTR_SMT))
>
^ permalink raw reply
* Re: [PATCH 3/3] powerpc/pseries/cpuhp: delete add/remove_by_count code
From: Daniel Henrique Barboza @ 2021-09-21 0:18 UTC (permalink / raw)
To: Nathan Lynch, linuxppc-dev; +Cc: tyreld, ldufour, aneesh.kumar
In-Reply-To: <20210920135504.1792219-4-nathanl@linux.ibm.com>
On 9/20/21 10:55, Nathan Lynch wrote:
> The core DLPAR code supports two actions (add and remove) and three
> subtypes of action:
>
> * By DRC index: the action is attempted on a single specified resource.
> This is the usual case for processors.
> * By indexed count: the action is attempted on a range of resources
> beginning at the specified index. This is implemented only by the memory
> DLPAR code.
> * By count: the lower layer (CPU or memory) is responsible for locating the
> specified number of resources to which the action can be applied.
>
> I cannot find any evidence of the "by count" subtype being used by drmgr or
> qemu for processors. And when I try to exercise this code, the add case
> does not work:
Just to clarify: did you check both CPU and memory cases and found out that the
'by count' subtype isn't used with CPUs, but drmgr has some cases in which
'by count' is used with LMBs?
I'm asking because I worked with a part of the LMB removal code a few months ago,
and got stuck in a situation in which the 'by count' and 'by indexed count' are
similar enough to feel repetitive, but distinct enough to not be easily reduced
into a single function. If drmgr wasn't using the 'by count' subtypes for LMBs
that would be a good chance for more code redux.
>
> $ ppc64_cpu --smt ; nproc
> SMT=8
> 24
> $ printf "cpu remove count 2" > /sys/kernel/dlpar
> $ nproc
> 8
> $ printf "cpu add count 2" > /sys/kernel/dlpar
> -bash: printf: write error: Invalid argument
> $ dmesg | tail -2
> pseries-hotplug-cpu: Failed to find enough CPUs (1 of 2) to add
> dlpar: Could not handle DLPAR request "cpu add count 2"
> $ nproc
> 8
> $ drmgr -c cpu -a -q 2 # this uses the by-index method
> Validating CPU DLPAR capability...yes.
> CPU 1
> CPU 17
> $ nproc
> 24
>
> This is because find_drc_info_cpus_to_add() does not increment drc_index
> appropriately during its search.
>
> This is not hard to fix. But the _by_count() functions also have the
> property that they attempt to roll back all prior operations if the entire
> request cannot be satisfied, even though the rollback itself can encounter
> errors. It's not possible to provide transaction-like behavior at this
> level, and it's undesirable to have code that can only pretend to do that.
> Any users of these functions cannot know what the state of the system is in
> the error case. And the error paths are, to my knowledge, impossible to
> test without adding custom error injection code.
>
> Summary:
>
> * This code has not worked reliably since its introduction.
> * There is no evidence that it is used.
> * It contains questionable rollback behaviors in error paths which are
> difficult to test.
>
> So let's remove it.
>
> Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
> Fixes: ac71380071d1 ("powerpc/pseries: Add CPU dlpar remove functionality")
> Fixes: 90edf184b9b7 ("powerpc/pseries: Add CPU dlpar add functionality")
> Fixes: b015f6bc9547 ("powerpc/pseries: Add cpu DLPAR support for drc-info property")
> ---
Tested with a QEMU pseries guest, no issues found.
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Tested-by: Daniel Henrique Barboza <danielhb413@gmail.com>
> arch/powerpc/platforms/pseries/hotplug-cpu.c | 218 +------------------
> 1 file changed, 2 insertions(+), 216 deletions(-)
>
> diff --git a/arch/powerpc/platforms/pseries/hotplug-cpu.c b/arch/powerpc/platforms/pseries/hotplug-cpu.c
> index 87a0fbe9cf12..768997261ce8 100644
> --- a/arch/powerpc/platforms/pseries/hotplug-cpu.c
> +++ b/arch/powerpc/platforms/pseries/hotplug-cpu.c
> @@ -741,216 +741,6 @@ static int dlpar_cpu_remove_by_index(u32 drc_index)
> return rc;
> }
>
> -static int find_dlpar_cpus_to_remove(u32 *cpu_drcs, int cpus_to_remove)
> -{
> - struct device_node *dn;
> - int cpus_found = 0;
> - int rc;
> -
> - /* We want to find cpus_to_remove + 1 CPUs to ensure we do not
> - * remove the last CPU.
> - */
> - for_each_node_by_type(dn, "cpu") {
> - cpus_found++;
> -
> - if (cpus_found > cpus_to_remove) {
> - of_node_put(dn);
> - break;
> - }
> -
> - /* Note that cpus_found is always 1 ahead of the index
> - * into the cpu_drcs array, so we use cpus_found - 1
> - */
> - rc = of_property_read_u32(dn, "ibm,my-drc-index",
> - &cpu_drcs[cpus_found - 1]);
> - if (rc) {
> - pr_warn("Error occurred getting drc-index for %pOFn\n",
> - dn);
> - of_node_put(dn);
> - return -1;
> - }
> - }
> -
> - if (cpus_found < cpus_to_remove) {
> - pr_warn("Failed to find enough CPUs (%d of %d) to remove\n",
> - cpus_found, cpus_to_remove);
> - } else if (cpus_found == cpus_to_remove) {
> - pr_warn("Cannot remove all CPUs\n");
> - }
> -
> - return cpus_found;
> -}
> -
> -static int dlpar_cpu_remove_by_count(u32 cpus_to_remove)
> -{
> - u32 *cpu_drcs;
> - int cpus_found;
> - int cpus_removed = 0;
> - int i, rc;
> -
> - pr_debug("Attempting to hot-remove %d CPUs\n", cpus_to_remove);
> -
> - cpu_drcs = kcalloc(cpus_to_remove, sizeof(*cpu_drcs), GFP_KERNEL);
> - if (!cpu_drcs)
> - return -EINVAL;
> -
> - cpus_found = find_dlpar_cpus_to_remove(cpu_drcs, cpus_to_remove);
> - if (cpus_found <= cpus_to_remove) {
> - kfree(cpu_drcs);
> - return -EINVAL;
> - }
> -
> - for (i = 0; i < cpus_to_remove; i++) {
> - rc = dlpar_cpu_remove_by_index(cpu_drcs[i]);
> - if (rc)
> - break;
> -
> - cpus_removed++;
> - }
> -
> - if (cpus_removed != cpus_to_remove) {
> - pr_warn("CPU hot-remove failed, adding back removed CPUs\n");
> -
> - for (i = 0; i < cpus_removed; i++)
> - dlpar_cpu_add(cpu_drcs[i]);
> -
> - rc = -EINVAL;
> - } else {
> - rc = 0;
> - }
> -
> - kfree(cpu_drcs);
> - return rc;
> -}
> -
> -static int find_drc_info_cpus_to_add(struct device_node *cpus,
> - struct property *info,
> - u32 *cpu_drcs, u32 cpus_to_add)
> -{
> - struct of_drc_info drc;
> - const __be32 *value;
> - u32 count, drc_index;
> - int cpus_found = 0;
> - int i, j;
> -
> - if (!info)
> - return -1;
> -
> - value = of_prop_next_u32(info, NULL, &count);
> - if (value)
> - value++;
> -
> - for (i = 0; i < count; i++) {
> - of_read_drc_info_cell(&info, &value, &drc);
> - if (strncmp(drc.drc_type, "CPU", 3))
> - break;
> -
> - drc_index = drc.drc_index_start;
> - for (j = 0; j < drc.num_sequential_elems; j++) {
> - if (dlpar_cpu_exists(cpus, drc_index))
> - continue;
> -
> - cpu_drcs[cpus_found++] = drc_index;
> -
> - if (cpus_found == cpus_to_add)
> - return cpus_found;
> -
> - drc_index += drc.sequential_inc;
> - }
> - }
> -
> - return cpus_found;
> -}
> -
> -static int find_drc_index_cpus_to_add(struct device_node *cpus,
> - u32 *cpu_drcs, u32 cpus_to_add)
> -{
> - int cpus_found = 0;
> - int index, rc;
> - u32 drc_index;
> -
> - /* Search the ibm,drc-indexes array for possible CPU drcs to
> - * add. Note that the format of the ibm,drc-indexes array is
> - * the number of entries in the array followed by the array
> - * of drc values so we start looking at index = 1.
> - */
> - index = 1;
> - while (cpus_found < cpus_to_add) {
> - rc = of_property_read_u32_index(cpus, "ibm,drc-indexes",
> - index++, &drc_index);
> -
> - if (rc)
> - break;
> -
> - if (dlpar_cpu_exists(cpus, drc_index))
> - continue;
> -
> - cpu_drcs[cpus_found++] = drc_index;
> - }
> -
> - return cpus_found;
> -}
> -
> -static int dlpar_cpu_add_by_count(u32 cpus_to_add)
> -{
> - struct device_node *parent;
> - struct property *info;
> - u32 *cpu_drcs;
> - int cpus_added = 0;
> - int cpus_found;
> - int i, rc;
> -
> - pr_debug("Attempting to hot-add %d CPUs\n", cpus_to_add);
> -
> - cpu_drcs = kcalloc(cpus_to_add, sizeof(*cpu_drcs), GFP_KERNEL);
> - if (!cpu_drcs)
> - return -EINVAL;
> -
> - parent = of_find_node_by_path("/cpus");
> - if (!parent) {
> - pr_warn("Could not find CPU root node in device tree\n");
> - kfree(cpu_drcs);
> - return -1;
> - }
> -
> - info = of_find_property(parent, "ibm,drc-info", NULL);
> - if (info)
> - cpus_found = find_drc_info_cpus_to_add(parent, info, cpu_drcs, cpus_to_add);
> - else
> - cpus_found = find_drc_index_cpus_to_add(parent, cpu_drcs, cpus_to_add);
> -
> - of_node_put(parent);
> -
> - if (cpus_found < cpus_to_add) {
> - pr_warn("Failed to find enough CPUs (%d of %d) to add\n",
> - cpus_found, cpus_to_add);
> - kfree(cpu_drcs);
> - return -EINVAL;
> - }
> -
> - for (i = 0; i < cpus_to_add; i++) {
> - rc = dlpar_cpu_add(cpu_drcs[i]);
> - if (rc)
> - break;
> -
> - cpus_added++;
> - }
> -
> - if (cpus_added < cpus_to_add) {
> - pr_warn("CPU hot-add failed, removing any added CPUs\n");
> -
> - for (i = 0; i < cpus_added; i++)
> - dlpar_cpu_remove_by_index(cpu_drcs[i]);
> -
> - rc = -EINVAL;
> - } else {
> - rc = 0;
> - }
> -
> - kfree(cpu_drcs);
> - return rc;
> -}
> -
> int dlpar_cpu(struct pseries_hp_errorlog *hp_elog)
> {
> u32 count, drc_index;
> @@ -963,9 +753,7 @@ int dlpar_cpu(struct pseries_hp_errorlog *hp_elog)
>
> switch (hp_elog->action) {
> case PSERIES_HP_ELOG_ACTION_REMOVE:
> - if (hp_elog->id_type == PSERIES_HP_ELOG_ID_DRC_COUNT)
> - rc = dlpar_cpu_remove_by_count(count);
> - else if (hp_elog->id_type == PSERIES_HP_ELOG_ID_DRC_INDEX) {
> + if (hp_elog->id_type == PSERIES_HP_ELOG_ID_DRC_INDEX) {
> rc = dlpar_cpu_remove_by_index(drc_index);
> /*
> * Setting the isolation state of an UNISOLATED/CONFIGURED
> @@ -979,9 +767,7 @@ int dlpar_cpu(struct pseries_hp_errorlog *hp_elog)
> rc = -EINVAL;
> break;
> case PSERIES_HP_ELOG_ACTION_ADD:
> - if (hp_elog->id_type == PSERIES_HP_ELOG_ID_DRC_COUNT)
> - rc = dlpar_cpu_add_by_count(count);
> - else if (hp_elog->id_type == PSERIES_HP_ELOG_ID_DRC_INDEX)
> + if (hp_elog->id_type == PSERIES_HP_ELOG_ID_DRC_INDEX)
> rc = dlpar_cpu_add(drc_index);
> else
> rc = -EINVAL;
>
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Replace zero-length array with flexible array member
From: Gustavo A. R. Silva @ 2021-09-21 0:05 UTC (permalink / raw)
To: Len Baker, Paul Mackerras, Michael Ellerman,
Benjamin Herrenschmidt
Cc: Kees Cook, linux-kernel, kvm-ppc, Gustavo A. R. Silva,
linux-hardening, linuxppc-dev
In-Reply-To: <20210918142138.17709-1-len.baker@gmx.com>
On 9/18/21 09:21, Len Baker wrote:
> There is a regular need in the kernel to provide a way to declare having
> a dynamically sized set of trailing elements in a structure. Kernel code
> should always use "flexible array members" [1] for these cases. The
> older style of one-element or zero-length arrays should no longer be
> used[2].
>
> Also, make use of the struct_size() helper in kzalloc().
>
> [1] https://en.wikipedia.org/wiki/Flexible_array_member
> [2] https://www.kernel.org/doc/html/latest/process/deprecated.html#zero-length-and-one-element-arrays
>
> Signed-off-by: Len Baker <len.baker@gmx.com>
Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Thanks
--
Gustavo
> ---
> arch/powerpc/include/asm/kvm_host.h | 2 +-
> arch/powerpc/kvm/book3s_64_vio.c | 3 +--
> 2 files changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h
> index 080a7feb7731..3aed653373a5 100644
> --- a/arch/powerpc/include/asm/kvm_host.h
> +++ b/arch/powerpc/include/asm/kvm_host.h
> @@ -190,7 +190,7 @@ struct kvmppc_spapr_tce_table {
> u64 size; /* window size in pages */
> struct list_head iommu_tables;
> struct mutex alloc_lock;
> - struct page *pages[0];
> + struct page *pages[];
> };
>
> /* XICS components, defined in book3s_xics.c */
> diff --git a/arch/powerpc/kvm/book3s_64_vio.c b/arch/powerpc/kvm/book3s_64_vio.c
> index 6365087f3160..d42b4b6d4a79 100644
> --- a/arch/powerpc/kvm/book3s_64_vio.c
> +++ b/arch/powerpc/kvm/book3s_64_vio.c
> @@ -295,8 +295,7 @@ long kvm_vm_ioctl_create_spapr_tce(struct kvm *kvm,
> return ret;
>
> ret = -ENOMEM;
> - stt = kzalloc(sizeof(*stt) + npages * sizeof(struct page *),
> - GFP_KERNEL);
> + stt = kzalloc(struct_size(stt, pages, npages), GFP_KERNEL);
> if (!stt)
> goto fail_acct;
>
> --
> 2.25.1
>
^ permalink raw reply
* Re: [PATCH] powerpc/476: Fix sparse report
From: Alistair Popple @ 2021-09-21 0:38 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Christophe Leroy
Cc: linuxppc-dev, linux-kernel, kernel test robot
In-Reply-To: <aa6055769b92a5d8685b8d0adab99c48a0b0ef4b.1631956926.git.christophe.leroy@csgroup.eu>
Thanks, looks reasonable.
Reviewed-by: Alistair Popple <alistair@popple.id.au>
On Saturday, 18 September 2021 7:22:32 PM AEST Christophe Leroy wrote:
> arch/powerpc/platforms/44x/ppc476.c:236:17: warning: cast removes address space '__iomem' of expression
> arch/powerpc/platforms/44x/ppc476.c:241:34: warning: incorrect type in argument 1 (different address spaces)
> arch/powerpc/platforms/44x/ppc476.c:241:34: expected void const volatile [noderef] __iomem *addr
> arch/powerpc/platforms/44x/ppc476.c:241:34: got unsigned char [usertype] *
> arch/powerpc/platforms/44x/ppc476.c:243:17: warning: incorrect type in argument 1 (different address spaces)
> arch/powerpc/platforms/44x/ppc476.c:243:17: expected void volatile [noderef] __iomem *addr
> arch/powerpc/platforms/44x/ppc476.c:243:17: got unsigned char [usertype] *[assigned] fpga
>
> Mark 'fpga' pointer as __iomem.
>
> Reported-by: kernel test robot <lkp@intel.com>
> Fixes: ab9a4183fddf ("powerpc: Update currituck pci/usb fixup for new board revision")
> Cc: Alistair Popple <alistair@popple.id.au>
> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> ---
> arch/powerpc/platforms/44x/ppc476.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/platforms/44x/ppc476.c b/arch/powerpc/platforms/44x/ppc476.c
> index 07f7e3ce67b5..fb7db5cedd4e 100644
> --- a/arch/powerpc/platforms/44x/ppc476.c
> +++ b/arch/powerpc/platforms/44x/ppc476.c
> @@ -219,7 +219,7 @@ static int board_rev = -1;
> static int __init ppc47x_get_board_rev(void)
> {
> int reg;
> - u8 *fpga;
> + u8 __iomem *fpga;
> struct device_node *np = NULL;
>
> if (of_machine_is_compatible("ibm,currituck")) {
> @@ -233,7 +233,7 @@ static int __init ppc47x_get_board_rev(void)
> if (!np)
> goto fail;
>
> - fpga = (u8 *) of_iomap(np, 0);
> + fpga = of_iomap(np, 0);
> of_node_put(np);
> if (!fpga)
> goto fail;
>
^ permalink raw reply
* Re: [PATCH 3/3] powerpc/pseries/cpuhp: delete add/remove_by_count code
From: Nathan Lynch @ 2021-09-21 0:43 UTC (permalink / raw)
To: Daniel Henrique Barboza, linuxppc-dev; +Cc: tyreld, ldufour, aneesh.kumar
In-Reply-To: <19c1f412-ef08-f1ea-8c6b-45921bd1f627@gmail.com>
Daniel Henrique Barboza <danielhb413@gmail.com> writes:
> On 9/20/21 10:55, Nathan Lynch wrote:
>> The core DLPAR code supports two actions (add and remove) and three
>> subtypes of action:
>>
>> * By DRC index: the action is attempted on a single specified resource.
>> This is the usual case for processors.
>> * By indexed count: the action is attempted on a range of resources
>> beginning at the specified index. This is implemented only by the memory
>> DLPAR code.
>> * By count: the lower layer (CPU or memory) is responsible for locating the
>> specified number of resources to which the action can be applied.
>>
>> I cannot find any evidence of the "by count" subtype being used by drmgr or
>> qemu for processors. And when I try to exercise this code, the add case
>> does not work:
>
>
> Just to clarify: did you check both CPU and memory cases and found out that the
> 'by count' subtype isn't used with CPUs, but drmgr has some cases in which
> 'by count' is used with LMBs?
Yes, drmgr uses both the 'by count' and the 'by index' methods for
memory currently on PowerVM.
> I'm asking because I worked with a part of the LMB removal code a few months ago,
> and got stuck in a situation in which the 'by count' and 'by indexed count' are
> similar enough to feel repetitive, but distinct enough to not be easily reduced
> into a single function. If drmgr wasn't using the 'by count' subtypes for LMBs
> that would be a good chance for more code redux.
The 'by count' method is definitely used for memory on PowerVM. I was
under the impression that the 'by indexed count' method was used by qemu
for memory sometimes; I'm pretty sure it's not used on PowerVM.
>> Summary:
>>
>> * This code has not worked reliably since its introduction.
>> * There is no evidence that it is used.
>> * It contains questionable rollback behaviors in error paths which are
>> difficult to test.
>>
>> So let's remove it.
>>
>> Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
>> Fixes: ac71380071d1 ("powerpc/pseries: Add CPU dlpar remove functionality")
>> Fixes: 90edf184b9b7 ("powerpc/pseries: Add CPU dlpar add functionality")
>> Fixes: b015f6bc9547 ("powerpc/pseries: Add cpu DLPAR support for drc-info property")
>> ---
>
> Tested with a QEMU pseries guest, no issues found.
>
>
> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
> Tested-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Thanks!
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/perf: Expose instruction and data address registers as part of extended regs
From: Athira Rajeev @ 2021-09-21 3:01 UTC (permalink / raw)
To: Michael Ellerman
Cc: Madhavan Srinivasan, rnsastry, kajoljain,
Arnaldo Carvalho de Melo, Jiri Olsa, linuxppc-dev
In-Reply-To: <87ilyviusy.fsf@mpe.ellerman.id.au>
> On 20-Sep-2021, at 12:43 PM, Michael Ellerman <mpe@ellerman.id.au> wrote:
>
> Athira Rajeev <atrajeev@linux.vnet.ibm.com> writes:
>>> On 08-Sep-2021, at 10:47 AM, Michael Ellerman <mpe@ellerman.id.au> wrote:
>>>
>>> Athira Rajeev <atrajeev@linux.vnet.ibm.com> writes:
>>>> Patch adds support to include Sampled Instruction Address Register
>>>> (SIAR) and Sampled Data Address Register (SDAR) SPRs as part of extended
>>>> registers. Update the definition of PERF_REG_PMU_MASK_300/31 and
>>>> PERF_REG_EXTENDED_MAX to include these SPR's.
>>>>
>>>> Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
>>>> ---
>>>> arch/powerpc/include/uapi/asm/perf_regs.h | 12 +++++++-----
>>>> arch/powerpc/perf/perf_regs.c | 4 ++++
>>>> 2 files changed, 11 insertions(+), 5 deletions(-)
>>>>
>>> ...
>>>> diff --git a/arch/powerpc/perf/perf_regs.c b/arch/powerpc/perf/perf_regs.c
>>>> index b931eed..51d31b6 100644
>>>> --- a/arch/powerpc/perf/perf_regs.c
>>>> +++ b/arch/powerpc/perf/perf_regs.c
>>>> @@ -90,7 +90,11 @@ static u64 get_ext_regs_value(int idx)
>>>> return mfspr(SPRN_SIER2);
>>>> case PERF_REG_POWERPC_SIER3:
>>>> return mfspr(SPRN_SIER3);
>>>> + case PERF_REG_POWERPC_SDAR:
>>>> + return mfspr(SPRN_SDAR);
>>>> #endif
>>>> + case PERF_REG_POWERPC_SIAR:
>>>> + return mfspr(SPRN_SIAR);
>>>> default: return 0;
>>>> }
>>>
>>> This file is built for all powerpc configs that have PERF_EVENTS. Which
>>> includes CPUs that don't have SDAR or SIAR.
>>>
>>> Don't we need checks in perf_reg_value() like we do for SIER?
>>
>> Hi Michael,
>>
>> Thanks for the review.
>>
>> SIER is part of PERF_REG_PMU_MASK and hence check is needed to see if platform supports SIER.
>> Incase of extended regs, they are part of PERF_REG_EXTENDED_MASK and this mask is
>> filled with supported registers while registering the PMU ( ie during init_power9/10_pmu ). So these registers will be added
>> only for supported platforms. The validity of extended mask is also done in PMU common code
>> ( In kernel/events/core.c with PERF_REG_EXTENDED_MASK check ). So an unsupported platform requesting for extended
>> registers won’t get it.
>
> Right, I'd forgotten how that works.
>
> But I think part of the reason I didn't remember is that
> PERF_REG_PMU_MASK_31 doesn't mention those regs by name, it's just a hex
> constant, ie:
>
> -#define PERF_REG_PMU_MASK_31 (0xfffULL << PERF_REG_POWERPC_MMCR0)
> +#define PERF_REG_PMU_MASK_31 (0x3fffULL << PERF_REG_POWERPC_MMCR0)
>
> Presumably you tested that the added 0x3 there sets the right bits for
> SDAR and SIAR, but it's 1) not obvious and 2) fragile.
>
> So I'd like it better if we constructed the PERF_REG_PMU_MASK_31, and
> other similar masks, by or'ing together the actual register value
> constants.
>
> eg. something like:
>
> #define PERF_REG_PMU_MASK_31 \
> ((1ul << PERF_REG_POWERPC_MMCR0) | (1ul << PERF_REG_POWERPC_MMCR1) | \
> (1ul << PERF_REG_POWERPC_MMCR2) | (1ul << PERF_REG_POWERPC_MMCR3) | \
> (1ul << PERF_REG_POWERPC_SIER2) | (1ul << PERF_REG_POWERPC_SIER3) | \
> (1ul << PERF_REG_POWERPC_PMC1) | (1ul << PERF_REG_POWERPC_PMC2) | \
> (1ul << PERF_REG_POWERPC_PMC3) | (1ul << PERF_REG_POWERPC_PMC4) | \
> (1ul << PERF_REG_POWERPC_PMC5) | (1ul << PERF_REG_POWERPC_PMC6))
>
>
> Also PERF_REG_EXTENDED_MAX should be part of the enum, just like
> PERF_REG_POWERPC_MAX.
Sure Michael,
I will address these changes in next version
Thanks
Athira
>
> cheers
^ permalink raw reply
* [PATCH] powerpc/paravirt: correct preempt debug splat in vcpu_is_preempted()
From: Nathan Lynch @ 2021-09-21 3:12 UTC (permalink / raw)
To: linuxppc-dev; +Cc: srikar, npiggin
vcpu_is_preempted() can be used outside of preempt-disabled critical
sections, yielding warnings such as:
BUG: using smp_processor_id() in preemptible [00000000] code: systemd-udevd/185
caller is rwsem_spin_on_owner+0x1cc/0x2d0
CPU: 1 PID: 185 Comm: systemd-udevd Not tainted 5.15.0-rc2+ #33
Call Trace:
[c000000012907ac0] [c000000000aa30a8] dump_stack_lvl+0xac/0x108 (unreliable)
[c000000012907b00] [c000000001371f70] check_preemption_disabled+0x150/0x160
[c000000012907b90] [c0000000001e0e8c] rwsem_spin_on_owner+0x1cc/0x2d0
[c000000012907be0] [c0000000001e1408] rwsem_down_write_slowpath+0x478/0x9a0
[c000000012907ca0] [c000000000576cf4] filename_create+0x94/0x1e0
[c000000012907d10] [c00000000057ac08] do_symlinkat+0x68/0x1a0
[c000000012907d70] [c00000000057ae18] sys_symlink+0x58/0x70
[c000000012907da0] [c00000000002e448] system_call_exception+0x198/0x3c0
[c000000012907e10] [c00000000000c54c] system_call_common+0xec/0x250
The result of vcpu_is_preempted() is always subject to invalidation by
events inside and outside of Linux; it's just a best guess at a point in
time. Use raw_smp_processor_id() to avoid such warnings.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Fixes: ca3f969dcb11 ("powerpc/paravirt: Use is_kvm_guest() in vcpu_is_preempted()")
---
arch/powerpc/include/asm/paravirt.h | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/paravirt.h b/arch/powerpc/include/asm/paravirt.h
index bcb7b5f917be..e429aca566de 100644
--- a/arch/powerpc/include/asm/paravirt.h
+++ b/arch/powerpc/include/asm/paravirt.h
@@ -97,7 +97,14 @@ static inline bool vcpu_is_preempted(int cpu)
#ifdef CONFIG_PPC_SPLPAR
if (!is_kvm_guest()) {
- int first_cpu = cpu_first_thread_sibling(smp_processor_id());
+ int first_cpu;
+
+ /*
+ * This is only a guess at best, and this function may be
+ * called with preemption enabled. Using raw_smp_processor_id()
+ * does not damage accuracy.
+ */
+ first_cpu = cpu_first_thread_sibling(raw_smp_processor_id());
/*
* Preemption can only happen at core granularity. This CPU
--
2.31.1
^ permalink raw reply related
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