* Re: [PATCH] powerpc/85xx: fix oops when CONFIG_FSL_PMC=n
From: Michael Ellerman @ 2021-12-03 11:53 UTC (permalink / raw)
To: benh, chunkeey, gregkh, hurricos, chenhui.zhao, stable,
Xiaoming Ni, wangle6, linuxppc-dev, mpe, oss, paulus,
chenjianguo3, linux-kernel, liuwenliang, Yuantian.Tang,
paul.gortmaker
In-Reply-To: <20211126041153.16926-1-nixiaoming@huawei.com>
On Fri, 26 Nov 2021 12:11:53 +0800, Xiaoming Ni wrote:
> When CONFIG_FSL_PMC is set to n, no value is assigned to cpu_up_prepare
> in the mpc85xx_pm_ops structure. As a result, oops is triggered in
> smp_85xx_start_cpu().
>
> [ 0.627233] smp: Bringing up secondary CPUs ...
> [ 0.681659] kernel tried to execute user page (0) - exploit attempt? (uid: 0)
> [ 0.766618] BUG: Unable to handle kernel instruction fetch (NULL pointer?)
> [ 0.848899] Faulting instruction address: 0x00000000
> [ 0.908273] Oops: Kernel access of bad area, sig: 11 [#1]
> ...
> [ 1.758220] NIP [00000000] 0x0
> [ 1.794688] LR [c0021d2c] smp_85xx_kick_cpu+0xe8/0x568
> [ 1.856126] Call Trace:
> [ 1.885295] [c1051da8] [c0021cb8] smp_85xx_kick_cpu+0x74/0x568 (unreliable)
> [ 1.968633] [c1051de8] [c0011460] __cpu_up+0xc0/0x228
> [ 2.029038] [c1051e18] [c0031bbc] bringup_cpu+0x30/0x224
> [ 2.092572] [c1051e48] [c0031f3c] cpu_up.constprop.0+0x180/0x33c
> [ 2.164443] [c1051e88] [c00322e8] bringup_nonboot_cpus+0x88/0xc8
> [ 2.236326] [c1051eb8] [c07e67bc] smp_init+0x30/0x78
> [ 2.295698] [c1051ed8] [c07d9e28] kernel_init_freeable+0x118/0x2a8
> [ 2.369641] [c1051f18] [c00032d8] kernel_init+0x14/0x124
> [ 2.433176] [c1051f38] [c0010278] ret_from_kernel_thread+0x14/0x1c
>
> [...]
Applied to powerpc/fixes.
[1/1] powerpc/85xx: fix oops when CONFIG_FSL_PMC=n
https://git.kernel.org/powerpc/c/3dc709e518b47386e6af937eaec37bb36539edfd
cheers
^ permalink raw reply
* [PATCH] powerpc: Drop unused CONFIG_PPC_HAS_FEATURE_CALLS
From: Michael Ellerman @ 2021-12-03 11:57 UTC (permalink / raw)
To: linuxppc-dev
Since ~2002 we have had CONFIG_PPC_HAS_FEATURE_CALLS defined as a faux
CONFIG symbol, firstly in include/asm-ppc/machdep.h, and then later
copied over to powerpc when ppc and ppc64 were merged.
The last in-tree usage was removed in 2005 in commit
7bbd827750e6 ("[PATCH] ppc64: very basic desktop g5 sound support").
I haven't been able to find any meaningful references to it anywhere
else, so I suspect it has been unused for many years. It confuses
scripts/checkkconfigsymbols.py, and seems to serve no purpose, so drop
it.
Note that it's not in a uapi header, ie. it could only be used by
out-of-tree kernel modules, not general userspace code.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
If anything does use it, just let us know.
---
arch/powerpc/include/asm/machdep.h | 5 -----
1 file changed, 5 deletions(-)
diff --git a/arch/powerpc/include/asm/machdep.h b/arch/powerpc/include/asm/machdep.h
index e821037f74f0..75687e1f994a 100644
--- a/arch/powerpc/include/asm/machdep.h
+++ b/arch/powerpc/include/asm/machdep.h
@@ -10,11 +10,6 @@
#include <asm/setup.h>
-/* We export this macro for external modules like Alsa to know if
- * ppc_md.feature_call is implemented or not
- */
-#define CONFIG_PPC_HAS_FEATURE_CALLS
-
struct pt_regs;
struct pci_bus;
struct device_node;
--
2.31.1
^ permalink raw reply related
* Re: [PATCH v2] powerpc/pseries: read the lpar name from the firmware
From: Michael Ellerman @ 2021-12-03 12:28 UTC (permalink / raw)
To: Laurent Dufour, linuxppc-dev; +Cc: Nathan Lynch, linux-kernel
In-Reply-To: <20211201190642.49897-1-ldufour@linux.ibm.com>
Hi Laurent,
Just a few minor comments below ...
Laurent Dufour <ldufour@linux.ibm.com> writes:
> The LPAR name may be changed after the LPAR has been started in the HMC.
> In that case lparstat command is not reporting the updated value because it
> reads it from the device tree which is read at boot time.
>
> However this value could be read from RTAS.
>
> Adding this value in the /proc/powerpc/lparcfg output allows to read the
> updated value.
>
> Cc: Nathan Lynch <nathanl@linux.ibm.com>
> Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com>
> ---
> v2:
> address Nathan's comments.
> change title to partition_name aligning with existing partition_id
> ---
> arch/powerpc/platforms/pseries/lparcfg.c | 53 ++++++++++++++++++++++++
> 1 file changed, 53 insertions(+)
>
> diff --git a/arch/powerpc/platforms/pseries/lparcfg.c b/arch/powerpc/platforms/pseries/lparcfg.c
> index f71eac74ea92..0deca7b4cd81 100644
> --- a/arch/powerpc/platforms/pseries/lparcfg.c
> +++ b/arch/powerpc/platforms/pseries/lparcfg.c
> @@ -311,6 +311,58 @@ static void parse_mpp_x_data(struct seq_file *m)
> seq_printf(m, "coalesce_pool_spurr=%ld\n", mpp_x_data.pool_spurr_cycles);
> }
>
> +/*
> + * PAPR defines no maximum for the LPAR name, and defines that the maximum
> + * length of the get-system-parameter's output buffer is 4000 plus 2 bytes for
> + * the length. Limit LPAR's name size to 1024
> + */
> +#define SPLPAR_LPAR_NAME_MAXLEN 1026
Why not just allocate the full 4000? That's not much memory in the
scheme of things, and allocating less risks us needing to update this in
future. I realise that's a ridiculously long LPAR name, but still.
> +#define SPLPAR_LPAR_NAME_TOKEN 55
Can you add a comment saying where that value is defined, PAPR?
> +static void parse_lpar_name(struct seq_file *m)
Nitpick, but we're not really parsing it, we're just reading it from firmware.
> +{
> + int rc, len, token;
> + unsigned char *local_buffer;
> +
> + token = rtas_token("ibm,get-system-parameter");
> + if (token == RTAS_UNKNOWN_SERVICE)
> + return;
> +
> + local_buffer = kmalloc(SPLPAR_LPAR_NAME_MAXLEN, GFP_KERNEL);
> + if (!local_buffer)
> + return;
> +
> + do {
> + spin_lock(&rtas_data_buf_lock);
> +
> + memset(rtas_data_buf, 0, RTAS_DATA_BUF_SIZE);
> + rc = rtas_call(token, 3, 1, NULL, SPLPAR_LPAR_NAME_TOKEN,
> + __pa(rtas_data_buf), RTAS_DATA_BUF_SIZE);
> + memcpy(local_buffer, rtas_data_buf, SPLPAR_LPAR_NAME_MAXLEN);
Would be nice to skip the memcpy() if rc is non-zero.
> + spin_unlock(&rtas_data_buf_lock);
> + } while (rtas_busy_delay(rc));
> +
> + if (rc != 0) {
> + pr_err_once(
> + "%s %s Error calling get-system-parameter (0x%x)\n",
> + __FILE__, __func__, rc);
> + } else {
> + local_buffer[SPLPAR_LPAR_NAME_MAXLEN - 1] = '\0';
> + len = local_buffer[0] * 256 + local_buffer[1];
This is kind of a hand rolled be16_to_cpu().
And we also have the + 2 to skip the length in several places.
I feel like the code would be cleaner if we had a type for the result
buffer, eg something like:
union {
char raw_buffer[1026];
struct {
__be16 len;
char data[1024];
};
};
> + /*
> + * Forces an empty string in the weird case fw reports no data.
> + */
> + if (!len)
> + local_buffer[2] = '\0';
> +
> + seq_printf(m, "partition_name=%s\n", local_buffer + 2);
Then above you could use the data field rather than having to add the
"2" in both places.
> + }
> +
> + kfree(local_buffer);
> +}
> +
> +
> #define SPLPAR_CHARACTERISTICS_TOKEN 20
> #define SPLPAR_MAXLENGTH 1026*(sizeof(char))
>
> @@ -496,6 +548,7 @@ static int pseries_lparcfg_data(struct seq_file *m, void *v)
>
> if (firmware_has_feature(FW_FEATURE_SPLPAR)) {
> /* this call handles the ibm,get-system-parameter contents */
> + parse_lpar_name(m);
> parse_system_parameter_string(m);
> parse_ppp_data(m);
> parse_mpp_data(m);
> --
> 2.34.1
cheers
^ permalink raw reply
* Re: [PATCH v6 17/18] powerpc/64s: Move hash MMU support code under CONFIG_PPC_64S_HASH_MMU
From: Michael Ellerman @ 2021-12-03 12:34 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev; +Cc: Nicholas Piggin
In-Reply-To: <20211201144153.2456614-18-npiggin@gmail.com>
Nicholas Piggin <npiggin@gmail.com> writes:
> diff --git a/arch/powerpc/mm/book3s64/pgtable.c b/arch/powerpc/mm/book3s64/pgtable.c
> index 4d97d1525d49..d765d972566b 100644
> --- a/arch/powerpc/mm/book3s64/pgtable.c
> +++ b/arch/powerpc/mm/book3s64/pgtable.c
> @@ -534,7 +534,7 @@ static int __init pgtable_debugfs_setup(void)
> }
> arch_initcall(pgtable_debugfs_setup);
>
> -#ifdef CONFIG_ZONE_DEVICE
> +#if defined(CONFIG_ZONE_DEVICE) && defined(ARCH_HAS_MEMREMAP_COMPAT_ALIGN)
^
This needs "CONFIG_"
I fixed it up when applying.
cheers
^ permalink raw reply
* [PATCH] powerpc/ptdump: Fix DEBUG_WX since generic ptdump conversion
From: Michael Ellerman @ 2021-12-03 12:41 UTC (permalink / raw)
To: linuxppc-dev
In note_prot_wx() we bail out without reporting anything if
CONFIG_PPC_DEBUG_WX is disabled.
But CONFIG_PPC_DEBUG_WX was removed in the conversion to generic ptdump,
we now need to use CONFIG_DEBUG_WX instead.
Fixes: e084728393a5 ("powerpc/ptdump: Convert powerpc to GENERIC_PTDUMP")
Cc: stable@vger.kernel.org # v5.15+
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/mm/ptdump/ptdump.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/mm/ptdump/ptdump.c b/arch/powerpc/mm/ptdump/ptdump.c
index 031956d0ee84..be120e09aa3e 100644
--- a/arch/powerpc/mm/ptdump/ptdump.c
+++ b/arch/powerpc/mm/ptdump/ptdump.c
@@ -183,7 +183,7 @@ static void note_prot_wx(struct pg_state *st, unsigned long addr)
{
pte_t pte = __pte(st->current_flags);
- if (!IS_ENABLED(CONFIG_PPC_DEBUG_WX) || !st->check_wx)
+ if (!IS_ENABLED(CONFIG_DEBUG_WX) || !st->check_wx)
return;
if (!pte_write(pte) || !pte_exec(pte))
--
2.31.1
^ permalink raw reply related
* Re: [PATCH] powerpc/ptdump: Fix DEBUG_WX since generic ptdump conversion
From: Christophe Leroy @ 2021-12-03 12:55 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20211203124112.2912562-1-mpe@ellerman.id.au>
Le 03/12/2021 à 13:41, Michael Ellerman a écrit :
> In note_prot_wx() we bail out without reporting anything if
> CONFIG_PPC_DEBUG_WX is disabled.
>
> But CONFIG_PPC_DEBUG_WX was removed in the conversion to generic ptdump,
> we now need to use CONFIG_DEBUG_WX instead.
>
> Fixes: e084728393a5 ("powerpc/ptdump: Convert powerpc to GENERIC_PTDUMP")
> Cc: stable@vger.kernel.org # v5.15+
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> ---
Oops ... my mistake.
Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> arch/powerpc/mm/ptdump/ptdump.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/mm/ptdump/ptdump.c b/arch/powerpc/mm/ptdump/ptdump.c
> index 031956d0ee84..be120e09aa3e 100644
> --- a/arch/powerpc/mm/ptdump/ptdump.c
> +++ b/arch/powerpc/mm/ptdump/ptdump.c
> @@ -183,7 +183,7 @@ static void note_prot_wx(struct pg_state *st, unsigned long addr)
> {
> pte_t pte = __pte(st->current_flags);
>
> - if (!IS_ENABLED(CONFIG_PPC_DEBUG_WX) || !st->check_wx)
> + if (!IS_ENABLED(CONFIG_DEBUG_WX) || !st->check_wx)
> return;
>
> if (!pte_write(pte) || !pte_exec(pte))
>
^ permalink raw reply
* [PATCH v3] PCI hotplug: rpaphp: Error out on busy status from get-sensor-state
From: Mahesh Salgaonkar @ 2021-12-03 13:12 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nathan Lynch, Tyrel Datwyler, Oliver O'Halloran
When certain PHB HW failure causes phyp to recover PHB, it marks the PE
state as temporarily unavailable until recovery is complete. This also
triggers an EEH handler in Linux which needs to notify drivers, and perform
recovery. But before notifying the driver about the pci error it uses
get_adapter_state()->get-sesnor-state() operation of the hotplug_slot to
determine if the slot contains a device or not. if the slot is empty, the
recovery is skipped entirely.
However on certain PHB failures, the rtas call get-sesnor-state() returns
extended busy error (9902) until PHB is recovered by phyp. Once PHB is
recovered, the get-sensor-state() returns success with correct presence
status. The rtas call interface rtas_get_sensor() loops over the rtas call
on extended delay return code (9902) until the return value is either
success (0) or error (-1). This causes the EEH handler to get stuck for ~6
seconds before it could notify that the pci error has been detected and
stop any active operations. Hence with running I/O traffic, during this 6
seconds, the network driver continues its operation and hits a timeout
(netdev watchdog). On timeouts, network driver go into ffdc capture mode
and reset path assuming the PCI device is in fatal condition. This
sometimes causes EEH recovery to fail. This impacts the ssh connection and
leads to the system being inaccessible.
------------
[52732.244731] DEBUG: ibm_read_slot_reset_state2()
[52732.244762] DEBUG: ret = 0, rets[0]=5, rets[1]=1, rets[2]=4000, rets[3]=>
[52732.244798] DEBUG: in eeh_slot_presence_check
[52732.244804] DEBUG: error state check
[52732.244807] DEBUG: Is slot hotpluggable
[52732.244810] DEBUG: hotpluggable ops ?
[52732.244953] DEBUG: Calling ops->get_adapter_status
[52732.244958] DEBUG: calling rpaphp_get_sensor_state
[52736.564262] ------------[ cut here ]------------
[52736.564299] NETDEV WATCHDOG: enP64p1s0f3 (tg3): transmit queue 0 timed o>
[52736.564324] WARNING: CPU: 1442 PID: 0 at net/sched/sch_generic.c:478 dev>
[...]
[52736.564505] NIP [c000000000c32368] dev_watchdog+0x438/0x440
[52736.564513] LR [c000000000c32364] dev_watchdog+0x434/0x440
------------
To avoid this issue, fix the pci hotplug driver (rpaphp) to return an error
if the slot presence state can not be detected immediately. Current
implementation uses rtas_get_sensor() API which blocks the slot check state
until rtas call returns success. Change rpaphp_get_sensor_state() to invoke
rtas_call(get-sensor-state) directly and take actions based on rtas return
status. This patch now errors out immediately on busy return status from
rtas_call.
Please note that, only on certain PHB failures, the slot presence check
returns BUSY condition. In normal cases it returns immediately with a
correct presence state value. Hence this change has no impact on normal pci
dlpar operations.
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.ibm.com>
---
Change in V3:
- Invoke rtas_call(get-sensor-state) directly from
rpaphp_get_sensor_state() directly and do special handling.
- See v2 at
https://lists.ozlabs.org/pipermail/linuxppc-dev/2021-November/237336.html
Change in V2:
- Alternate approach to fix the EEH issue instead of delaying slot presence
check proposed at
https://lists.ozlabs.org/pipermail/linuxppc-dev/2021-November/236956.html
Also refer:
https://lists.ozlabs.org/pipermail/linuxppc-dev/2021-November/237027.html
---
drivers/pci/hotplug/rpaphp_pci.c | 64 ++++++++++++++++++++++++++++++++++----
1 file changed, 58 insertions(+), 6 deletions(-)
diff --git a/drivers/pci/hotplug/rpaphp_pci.c b/drivers/pci/hotplug/rpaphp_pci.c
index c380bdacd1466..57ec1a72b24aa 100644
--- a/drivers/pci/hotplug/rpaphp_pci.c
+++ b/drivers/pci/hotplug/rpaphp_pci.c
@@ -18,15 +18,65 @@
#include "../pci.h" /* for pci_add_new_bus */
#include "rpaphp.h"
+/*
+ * RTAS call get-sensor-state(DR_ENTITY_SENSE) return values as per PAPR:
+ * -1: Hardware Error
+ * -2: RTAS_BUSY
+ * -3: Invalid sensor. RTAS Parameter Error.
+ * -9000: Need DR entity to be powered up and unisolated before RTAS call
+ * -9001: Need DR entity to be powered up, but not unisolated, before RTAS call
+ * -9002: DR entity unusable
+ * 990x: Extended delay - where x is a number in the range of 0-5
+ */
+#define RTAS_HARDWARE_ERROR -1
+#define RTAS_INVALID_SENSOR -3
+#define SLOT_UNISOLATED -9000
+#define SLOT_NOT_UNISOLATED -9001
+#define SLOT_NOT_USABLE -9002
+
+static int rtas_to_errno(int rtas_rc)
+{
+ int rc;
+
+ switch (rtas_rc) {
+ case RTAS_HARDWARE_ERROR:
+ rc = -EIO;
+ break;
+ case RTAS_INVALID_SENSOR:
+ rc = -EINVAL;
+ break;
+ case SLOT_UNISOLATED:
+ case SLOT_NOT_UNISOLATED:
+ rc = -EFAULT;
+ break;
+ case SLOT_NOT_USABLE:
+ rc = -ENODEV;
+ break;
+ case RTAS_BUSY:
+ case RTAS_EXTENDED_DELAY_MIN...RTAS_EXTENDED_DELAY_MAX:
+ rc = -EBUSY;
+ break;
+ default:
+ err("%s: unexpected RTAS error %d\n", __func__, rtas_rc);
+ rc = -ERANGE;
+ break;
+ }
+ return rc;
+}
+
int rpaphp_get_sensor_state(struct slot *slot, int *state)
{
+ int token = rtas_token("get-sensor-state");
int rc;
int setlevel;
- rc = rtas_get_sensor(DR_ENTITY_SENSE, slot->index, state);
+ if (token == RTAS_UNKNOWN_SERVICE)
+ return -ENOENT;
+
+ rc = rtas_call(token, 2, 2, state, DR_ENTITY_SENSE, slot->index);
if (rc < 0) {
- if (rc == -EFAULT || rc == -EEXIST) {
+ if (rc == SLOT_UNISOLATED || rc == SLOT_NOT_UNISOLATED) {
dbg("%s: slot must be power up to get sensor-state\n",
__func__);
@@ -38,15 +88,17 @@ int rpaphp_get_sensor_state(struct slot *slot, int *state)
if (rc < 0) {
dbg("%s: power on slot[%s] failed rc=%d.\n",
__func__, slot->name, rc);
- } else {
- rc = rtas_get_sensor(DR_ENTITY_SENSE,
- slot->index, state);
+ return rc;
}
- } else if (rc == -ENODEV)
+ rc = rtas_call(token, 2, 2, state, DR_ENTITY_SENSE,
+ slot->index);
+ } else if (rc == SLOT_NOT_USABLE)
info("%s: slot is unusable\n", __func__);
else
err("%s failed to get sensor state\n", __func__);
}
+ if (rc)
+ rc = rtas_to_errno(rc);
return rc;
}
^ permalink raw reply related
* Re: Fail to boot 5.15 on mpc8347 with either debug_pagealloc or nobats
From: Christophe Leroy @ 2021-12-03 12:49 UTC (permalink / raw)
To: linuxppc-dev@lists.ozlabs.org, mbizon@freebox.fr
In-Reply-To: <f23763d551e65d4a225ba13c7898f83853c2aeaf.camel@freebox.fr>
Hi Maxime,
Le 03/12/2021 à 01:44, Maxime Bizon a écrit :
>
> Hello Christophe,
>
> I have a mpc8347 board booting 5.15 fine, but it does not boot with
> CONFIG_DEBUG_PAGEALLOC=y (and enabled) or "nobats".
>
> Those two options worked fine on my previous kernel (5.4)
>
>
> Nothing is output on serial console when I set those options, so I had
> to hack a bit:
>
> 1) to ease debugging, I used mem=256M, so only a few BATs are used
>
> 2) I hijacked BAT 7 and the vm space at b000xxxx (modules, unused for
> me) to set a constant mapping so my uart always works (patch attached
> in case)
>
>
> I got this:
>
> mmu_mapin_ram: base:0x0 top:0x10000000 border:0x600000
> mmu_mapin_ram: updated base:0x0 top:0x600000
> setbat index=0 virt=0xc0000000 phys=0x0 size=0x400000
> setbat index=1 virt=0xc0400000 phys=0x400000 size=0x200000
> [ 0.000000] kernel tried to execute exec-protected page (c0600944) - exploit attempt? (uid: 0)
> [ 0.000000] BUG: Unable to handle kernel instruction fetch
> [ 0.000000] Faulting instruction address: 0xc0600944
> [ 0.000000] Thread overran stack, or stack corrupted
> [ 0.000000] Oops: Kernel access of bad area, sig: 11 [#1]
> [ 0.000000] BE PAGE_SIZE=4K DEBUG_PAGEALLOC
> [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.15.0+ #237
> [ 0.000000] NIP: c0600944 LR: 00003390 CTR: 00000000
> [ 0.000000] REGS: c07bbf40 TRAP: 0400 Not tainted (5.15.0+)
> [ 0.000000] MSR: 20001032 <ME,IR,DR,RI> CR: 48222444 XER: 20000000
> [ 0.000000]
> [ 0.000000] GPR00: c0003364 c07bbff0 c0707580 c0600944 00001032 00000000 c077dc8c 00000000
> [ 0.000000] GPR08: c07d0000 00000001 c07d0000 ffffffff 88222444 00000000 3ff9c5f0 3fffd79c
> [ 0.000000] GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> [ 0.000000] GPR24: 00000000 00000000 40000000 3ff9c5d8 03ffb000 00000000 3fffe4d4 03ffb000
> [ 0.000000] NIP [c0600944] start_kernel+0x0/0x600
> [ 0.000000] LR [00003390] 0x3390
> [ 0.000000] Call Trace:
> [ 0.000000] [c07bbff0] [c0003364] start_here+0x4c/0x90 (unreliable)
> [ 0.000000] Instruction dump:
> [ 0.000000] 83e1000c 7c0803a6 38210010 4e800020 4e800020 4ba05bb8 4e800020 4e800020
> [ 0.000000] 4e800020 4e800020 4e800020 4e800020 <9421ffc0> 3c60c070 7c0802a6 38637580
> [ 0.000000] random: get_random_bytes called from oops_exit+0x44/0x84 with crng_init=0
> [ 0.000000] ---[ end trace 0000000000000000 ]---
> [ 0.000000]
> [ 0.000000] Kernel panic - not syncing: Fatal exception
> [ 0.000000] Rebooting in 30 seconds..
>
>
>
> It gets a page fault when jumping on start_kernel(), it seems the
> init.text section is not mapped, at least not in execute.
>
> debug_pagealloc_enabled changes behaviour of mmu_mapin_ram(), it will
> map only up to __init_begin with BATs, and use page mappings for the
> reminder.
>
> my debug prints confirm that it seems to do a correct job at it, I've
> also verified that __mapin_ram_chunk() was indeed mapping the while
> init.text area with prot=PAGE_KERNEL_TEXT
>
> but it's as if those page mappings had no effect at all, and I am not
> familiar with PPC MMU to dig further
>
> Simply changing mmu_mapin_ram() to not to enter the "if
> debug_pagealloc_enabled_or_kfence()" makes the kernel boot fine.
>
> If you have any guidance that would be appreciated
>
Thanks for the report.
This problem doesn't happen on powermac on QEMU.
I was able to reproduce this problem on an mpc8321 board.
It happens when CONFIG_MODULES is not defined, in that case the
Instruction TLB miss exception handler doesn't expect such exception at
all because all kernel text is expected to be mapped with IBATs.
However, due to DEBUGPAGE_ALLOC, only main text is mapped with BATs, not
inittext. That's a mistake. inittext should still be mapped with BATs.
When CONFIG_MODULES is set it works.
One way to fix it is to drop this CONFIG_MODULES #ifdefs in instruction
TLB miss handler (In kernel/head_book3s_32.S), but that would kill
performance for just the sake init.
Another way to fix it is to set an IBAT coverring up to _einittext. This
IBAT should be removed by mark_initmem_nx() at the end of init ... but
... it looks like we have a problem there as well: as we have not mapped
_sinittext by DBATs, mmu_mark_initmem_nx() is not called.
Also, as we are setting an IBAT, we shoudn't set the pages executable,
at least X bit should be cleared. But the way it is done, if we call
mark_initmem_nx() then mark_initmem_nx() would call set_memory_attr() to
clear X bit from the pages. At the end it's not a problem because the
kernel segments are marked NX, but it's not clean.
So at the end it seems to be a mess around DEBUGPAGE_ALLOC and
STRICT_KERNEL_RWX. All this being amplified by those 'nobats' and
'noltlbs' options that are pointless from a functionnal point of view.
I need to think a bit more about it to find the cleanest solution that
works for all platforms.
Christophe
^ permalink raw reply
* Re: [PATCH] powerpc/rtas: Introduce rtas_get_sensor_nonblocking() for pci hotplug driver.
From: Mahesh J Salgaonkar @ 2021-12-03 13:42 UTC (permalink / raw)
To: Nathan Lynch; +Cc: linuxppc-dev, Oliver O'Halloran
In-Reply-To: <87o862nt0q.fsf@linux.ibm.com>
On 2021-11-29 22:53:41 Mon, Nathan Lynch wrote:
> Mahesh Salgaonkar <mahesh@linux.ibm.com> writes:
> > When certain PHB HW failure causes phyp to recover PHB, it marks the PE
> > state as temporarily unavailable until recovery is complete. This also
> > triggers an EEH handler in Linux which needs to notify drivers, and perform
> > recovery. But before notifying the driver about the pci error it uses
> > get_adapter_state()->get-sesnor-state() operation of the hotplug_slot to
> > determine if the slot contains a device or not. if the slot is empty, the
> > recovery is skipped entirely.
> >
> > However on certain PHB failures, the rtas call get-sesnor-state() returns
> > extended busy error (9902) until PHB is recovered by phyp. Once PHB is
> > recovered, the get-sensor-state() returns success with correct presence
> > status. The rtas call interface rtas_get_sensor() loops over the rtas call
> > on extended delay return code (9902) until the return value is either
> > success (0) or error (-1). This causes the EEH handler to get stuck for ~6
> > seconds before it could notify that the pci error has been detected and
> > stop any active operations.
>
> I am curious whether you see any difference with "powerpc/rtas:
> rtas_busy_delay() improvements" which was recently applied. It will
> cause the the calling task to sleep in response to a 990x status instead
> of immediately retrying:
>
> https://git.kernel.org/powerpc/c/38f7b7067dae0c101be573106018e8af22a90fdf
>
> If that commit helps then maybe this change isn't needed.
I tried with above commit but it didn't help.
>
> Maybe it would be better to have rpaphp_get_sensor_state() invoke
> rtas_call("get-sensor-state", ...) directly and code whatever special
> behavior is needed there, instead of introducing a new exported API. The
Posted v3 with above approach.
https://lists.ozlabs.org/pipermail/linuxppc-dev/2021-December/237538.html
Thanks for your review.
-Mahesh.
--
Mahesh J Salgaonkar
^ permalink raw reply
* [PATCH 0/4] fsl-asoc-card: Add optional dt property for setting mclk-id
From: Ariel D'Alessandro @ 2021-12-03 13:49 UTC (permalink / raw)
To: alsa-devel, devicetree, linux-kernel, linux-omap, linuxppc-dev
Cc: ariel.dalessandro, kuninori.morimoto.gx, Xiubo.Lee, tony,
shengjiu.wang, tiwai, lgirdwood, robh+dt, perex, nicoleotsuka,
broonie, bcousson, michael, festevam
This is a follow up of patchset:
[RFC patch 0/5] Support BCLK input clock in tlv320aic31xx
Sound cards may allow using different main clock inputs. In the generic
fsl-asoc-card driver, these values are hardcoded for each specific card
configuration.
Let's make it more flexible, allowing setting mclk-id from the
device-tree node.
Ariel D'Alessandro (4):
dt-bindings: sound: Rename tlv320aic31xx-micbias as tlv320aic31xx
dt-bindings: tlv320aic31xx: Define PLL clock inputs
ASoC: fsl-asoc-card: Add optional dt property for setting mclk-id
ASoC: fsl-asoc-card: Remove BCLK default value for tlv320aic31xx card
.../devicetree/bindings/sound/fsl-asoc-card.txt | 1 +
.../devicetree/bindings/sound/tlv320aic31xx.txt | 2 +-
arch/arm/boot/dts/am43x-epos-evm.dts | 2 +-
include/dt-bindings/sound/tlv320aic31xx-micbias.h | 9 ---------
include/dt-bindings/sound/tlv320aic31xx.h | 14 ++++++++++++++
sound/soc/codecs/tlv320aic31xx.c | 2 +-
sound/soc/fsl/fsl-asoc-card.c | 7 ++++++-
7 files changed, 24 insertions(+), 13 deletions(-)
delete mode 100644 include/dt-bindings/sound/tlv320aic31xx-micbias.h
create mode 100644 include/dt-bindings/sound/tlv320aic31xx.h
--
2.30.2
^ permalink raw reply
* [PATCH 1/4] dt-bindings: sound: Rename tlv320aic31xx-micbias as tlv320aic31xx
From: Ariel D'Alessandro @ 2021-12-03 13:49 UTC (permalink / raw)
To: alsa-devel, devicetree, linux-kernel, linux-omap, linuxppc-dev
Cc: ariel.dalessandro, kuninori.morimoto.gx, Xiubo.Lee, tony,
shengjiu.wang, tiwai, lgirdwood, robh+dt, perex, nicoleotsuka,
broonie, bcousson, michael, festevam
In-Reply-To: <20211203134930.128703-1-ariel.dalessandro@collabora.com>
Let's use a more generic name, so other definitions for tlv320aic31xx
can be included.
Signed-off-by: Ariel D'Alessandro <ariel.dalessandro@collabora.com>
---
.../devicetree/bindings/sound/tlv320aic31xx.txt | 2 +-
arch/arm/boot/dts/am43x-epos-evm.dts | 2 +-
include/dt-bindings/sound/tlv320aic31xx-micbias.h | 9 ---------
include/dt-bindings/sound/tlv320aic31xx.h | 9 +++++++++
sound/soc/codecs/tlv320aic31xx.c | 2 +-
5 files changed, 12 insertions(+), 12 deletions(-)
delete mode 100644 include/dt-bindings/sound/tlv320aic31xx-micbias.h
create mode 100644 include/dt-bindings/sound/tlv320aic31xx.h
diff --git a/Documentation/devicetree/bindings/sound/tlv320aic31xx.txt b/Documentation/devicetree/bindings/sound/tlv320aic31xx.txt
index e372303697dc..bbad98d5b986 100644
--- a/Documentation/devicetree/bindings/sound/tlv320aic31xx.txt
+++ b/Documentation/devicetree/bindings/sound/tlv320aic31xx.txt
@@ -58,7 +58,7 @@ The pins can be used in referring sound node's audio-routing property.
Example:
#include <dt-bindings/gpio/gpio.h>
-#include <dt-bindings/sound/tlv320aic31xx-micbias.h>
+#include <dt-bindings/sound/tlv320aic31xx.h>
tlv320aic31xx: tlv320aic31xx@18 {
compatible = "ti,tlv320aic311x";
diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts b/arch/arm/boot/dts/am43x-epos-evm.dts
index 2f4d2e4e9b3e..4f9a7251a107 100644
--- a/arch/arm/boot/dts/am43x-epos-evm.dts
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -11,7 +11,7 @@
#include <dt-bindings/pinctrl/am43xx.h>
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/pwm/pwm.h>
-#include <dt-bindings/sound/tlv320aic31xx-micbias.h>
+#include <dt-bindings/sound/tlv320aic31xx.h>
/ {
model = "TI AM43x EPOS EVM";
diff --git a/include/dt-bindings/sound/tlv320aic31xx-micbias.h b/include/dt-bindings/sound/tlv320aic31xx-micbias.h
deleted file mode 100644
index c6895a18a455..000000000000
--- a/include/dt-bindings/sound/tlv320aic31xx-micbias.h
+++ /dev/null
@@ -1,9 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-#ifndef __DT_TLV320AIC31XX_MICBIAS_H
-#define __DT_TLV320AIC31XX_MICBIAS_H
-
-#define MICBIAS_2_0V 1
-#define MICBIAS_2_5V 2
-#define MICBIAS_AVDDV 3
-
-#endif /* __DT_TLV320AIC31XX_MICBIAS_H */
diff --git a/include/dt-bindings/sound/tlv320aic31xx.h b/include/dt-bindings/sound/tlv320aic31xx.h
new file mode 100644
index 000000000000..3a845fbba992
--- /dev/null
+++ b/include/dt-bindings/sound/tlv320aic31xx.h
@@ -0,0 +1,9 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __DT_TLV320AIC31XX_H
+#define __DT_TLV320AIC31XX_H
+
+#define MICBIAS_2_0V 1
+#define MICBIAS_2_5V 2
+#define MICBIAS_AVDDV 3
+
+#endif /* __DT_TLV320AIC31XX_H */
diff --git a/sound/soc/codecs/tlv320aic31xx.c b/sound/soc/codecs/tlv320aic31xx.c
index 4224b4b3cae6..f2222c37913e 100644
--- a/sound/soc/codecs/tlv320aic31xx.c
+++ b/sound/soc/codecs/tlv320aic31xx.c
@@ -32,7 +32,7 @@
#include <sound/soc.h>
#include <sound/initval.h>
#include <sound/tlv.h>
-#include <dt-bindings/sound/tlv320aic31xx-micbias.h>
+#include <dt-bindings/sound/tlv320aic31xx.h>
#include "tlv320aic31xx.h"
--
2.30.2
^ permalink raw reply related
* [PATCH 2/4] dt-bindings: tlv320aic31xx: Define PLL clock inputs
From: Ariel D'Alessandro @ 2021-12-03 13:49 UTC (permalink / raw)
To: alsa-devel, devicetree, linux-kernel, linux-omap, linuxppc-dev
Cc: ariel.dalessandro, kuninori.morimoto.gx, Xiubo.Lee, tony,
shengjiu.wang, tiwai, lgirdwood, robh+dt, perex, nicoleotsuka,
broonie, bcousson, michael, festevam
In-Reply-To: <20211203134930.128703-1-ariel.dalessandro@collabora.com>
Add constants for the different PLL clock inputs in tlv320aic31xx.
Signed-off-by: Ariel D'Alessandro <ariel.dalessandro@collabora.com>
---
include/dt-bindings/sound/tlv320aic31xx.h | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/include/dt-bindings/sound/tlv320aic31xx.h b/include/dt-bindings/sound/tlv320aic31xx.h
index 3a845fbba992..4a80238ab250 100644
--- a/include/dt-bindings/sound/tlv320aic31xx.h
+++ b/include/dt-bindings/sound/tlv320aic31xx.h
@@ -6,4 +6,9 @@
#define MICBIAS_2_5V 2
#define MICBIAS_AVDDV 3
+#define PLL_CLKIN_MCLK 0x00
+#define PLL_CLKIN_BCLK 0x01
+#define PLL_CLKIN_GPIO1 0x02
+#define PLL_CLKIN_DIN 0x03
+
#endif /* __DT_TLV320AIC31XX_H */
--
2.30.2
^ permalink raw reply related
* [PATCH 3/4] ASoC: fsl-asoc-card: Add optional dt property for setting mclk-id
From: Ariel D'Alessandro @ 2021-12-03 13:49 UTC (permalink / raw)
To: alsa-devel, devicetree, linux-kernel, linux-omap, linuxppc-dev
Cc: ariel.dalessandro, kuninori.morimoto.gx, Xiubo.Lee, tony,
shengjiu.wang, tiwai, lgirdwood, robh+dt, perex, nicoleotsuka,
broonie, bcousson, michael, festevam
In-Reply-To: <20211203134930.128703-1-ariel.dalessandro@collabora.com>
Sound cards may allow using different main clock inputs. In the generic
fsl-asoc-card driver, these values are hardcoded for each specific card
configuration.
Let's make it more flexible, allowing setting mclk-id from the
device-tree node. Otherwise, the default value for each card
configuration is used.
Signed-off-by: Ariel D'Alessandro <ariel.dalessandro@collabora.com>
---
Documentation/devicetree/bindings/sound/fsl-asoc-card.txt | 1 +
sound/soc/fsl/fsl-asoc-card.c | 6 ++++++
2 files changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt b/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt
index 23d83fa7609f..b219626a5403 100644
--- a/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt
+++ b/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt
@@ -82,6 +82,7 @@ Optional properties:
- dai-format : audio format, for details see simple-card.yaml.
- frame-inversion : dai-link uses frame clock inversion, for details see simple-card.yaml.
- bitclock-inversion : dai-link uses bit clock inversion, for details see simple-card.yaml.
+ - mclk-id : main clock id, specific for each card configuration.
Optional unless SSI is selected as a CPU DAI:
diff --git a/sound/soc/fsl/fsl-asoc-card.c b/sound/soc/fsl/fsl-asoc-card.c
index 90cbed496f98..bb962e04d40b 100644
--- a/sound/soc/fsl/fsl-asoc-card.c
+++ b/sound/soc/fsl/fsl-asoc-card.c
@@ -693,6 +693,12 @@ static int fsl_asoc_card_probe(struct platform_device *pdev)
goto asrc_fail;
}
+ /*
+ * Allow setting mclk-id from the device-tree node. Otherwise, the
+ * default value for each card configuration is used.
+ */
+ of_property_read_u32(np, "mclk-id", &priv->codec_priv.mclk_id);
+
/* Format info from DT is optional. */
snd_soc_daifmt_parse_clock_provider_as_phandle(np, NULL, &bitclkprovider, &frameprovider);
if (bitclkprovider || frameprovider) {
--
2.30.2
^ permalink raw reply related
* [PATCH 4/4] ASoC: fsl-asoc-card: Remove BCLK default value for tlv320aic31xx card
From: Ariel D'Alessandro @ 2021-12-03 13:49 UTC (permalink / raw)
To: alsa-devel, devicetree, linux-kernel, linux-omap, linuxppc-dev
Cc: ariel.dalessandro, kuninori.morimoto.gx, Xiubo.Lee, tony,
shengjiu.wang, tiwai, lgirdwood, robh+dt, perex, nicoleotsuka,
broonie, bcousson, michael, festevam
In-Reply-To: <20211203134930.128703-1-ariel.dalessandro@collabora.com>
Now that fsl-asoc-card support setting mclk-id through the device-tree
mclk-id property, let's remove the default BCLK configuration for this
card.
Signed-off-by: Ariel D'Alessandro <ariel.dalessandro@collabora.com>
---
sound/soc/fsl/fsl-asoc-card.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/sound/soc/fsl/fsl-asoc-card.c b/sound/soc/fsl/fsl-asoc-card.c
index bb962e04d40b..e92d90010d45 100644
--- a/sound/soc/fsl/fsl-asoc-card.c
+++ b/sound/soc/fsl/fsl-asoc-card.c
@@ -637,7 +637,6 @@ static int fsl_asoc_card_probe(struct platform_device *pdev)
priv->dai_link[2].dpcm_capture = 0;
priv->cpu_priv.sysclk_dir[TX] = SND_SOC_CLOCK_OUT;
priv->cpu_priv.sysclk_dir[RX] = SND_SOC_CLOCK_OUT;
- priv->codec_priv.mclk_id = AIC31XX_PLL_CLKIN_BCLK;
priv->card.dapm_routes = audio_map_tx;
priv->card.num_dapm_routes = ARRAY_SIZE(audio_map_tx);
} else if (of_device_is_compatible(np, "fsl,imx-audio-wm8962")) {
--
2.30.2
^ permalink raw reply related
* Re: [PATCH v2] powerpc/pseries: read the lpar name from the firmware
From: Laurent Dufour @ 2021-12-03 15:23 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev; +Cc: Nathan Lynch, linux-kernel
In-Reply-To: <87y251ooth.fsf@mpe.ellerman.id.au>
On 03/12/2021, 13:28:10, Michael Ellerman wrote:
> Hi Laurent,
>
> Just a few minor comments below ...
Thanks, Michael, for your _major_ comments.
I'll send a version 3 soon.
Laurent.
>
> Laurent Dufour <ldufour@linux.ibm.com> writes:
>> The LPAR name may be changed after the LPAR has been started in the HMC.
>> In that case lparstat command is not reporting the updated value because it
>> reads it from the device tree which is read at boot time.
>>
>> However this value could be read from RTAS.
>>
>> Adding this value in the /proc/powerpc/lparcfg output allows to read the
>> updated value.
>>
>> Cc: Nathan Lynch <nathanl@linux.ibm.com>
>> Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com>
>> ---
>> v2:
>> address Nathan's comments.
>> change title to partition_name aligning with existing partition_id
>> ---
>> arch/powerpc/platforms/pseries/lparcfg.c | 53 ++++++++++++++++++++++++
>> 1 file changed, 53 insertions(+)
>>
>> diff --git a/arch/powerpc/platforms/pseries/lparcfg.c b/arch/powerpc/platforms/pseries/lparcfg.c
>> index f71eac74ea92..0deca7b4cd81 100644
>> --- a/arch/powerpc/platforms/pseries/lparcfg.c
>> +++ b/arch/powerpc/platforms/pseries/lparcfg.c
>> @@ -311,6 +311,58 @@ static void parse_mpp_x_data(struct seq_file *m)
>> seq_printf(m, "coalesce_pool_spurr=%ld\n", mpp_x_data.pool_spurr_cycles);
>> }
>>
>> +/*
>> + * PAPR defines no maximum for the LPAR name, and defines that the maximum
>> + * length of the get-system-parameter's output buffer is 4000 plus 2 bytes for
>> + * the length. Limit LPAR's name size to 1024
>> + */
>> +#define SPLPAR_LPAR_NAME_MAXLEN 1026
>
> Why not just allocate the full 4000? That's not much memory in the
> scheme of things, and allocating less risks us needing to update this in
> future. I realise that's a ridiculously long LPAR name, but still.
>
>> +#define SPLPAR_LPAR_NAME_TOKEN 55
>
> Can you add a comment saying where that value is defined, PAPR?
>
>> +static void parse_lpar_name(struct seq_file *m)
>
> Nitpick, but we're not really parsing it, we're just reading it from firmware.
>
>> +{
>> + int rc, len, token;
>> + unsigned char *local_buffer;
>> +
>> + token = rtas_token("ibm,get-system-parameter");
>> + if (token == RTAS_UNKNOWN_SERVICE)
>> + return;
>> +
>> + local_buffer = kmalloc(SPLPAR_LPAR_NAME_MAXLEN, GFP_KERNEL);
>> + if (!local_buffer)
>> + return;
>> +
>> + do {
>> + spin_lock(&rtas_data_buf_lock);
>> +
>> + memset(rtas_data_buf, 0, RTAS_DATA_BUF_SIZE);
>> + rc = rtas_call(token, 3, 1, NULL, SPLPAR_LPAR_NAME_TOKEN,
>> + __pa(rtas_data_buf), RTAS_DATA_BUF_SIZE);
>> + memcpy(local_buffer, rtas_data_buf, SPLPAR_LPAR_NAME_MAXLEN);
>
> Would be nice to skip the memcpy() if rc is non-zero.
>
>> + spin_unlock(&rtas_data_buf_lock);
>> + } while (rtas_busy_delay(rc));
>> +
>> + if (rc != 0) {
>> + pr_err_once(
>> + "%s %s Error calling get-system-parameter (0x%x)\n",
>> + __FILE__, __func__, rc);
>> + } else {
>> + local_buffer[SPLPAR_LPAR_NAME_MAXLEN - 1] = '\0';
>> + len = local_buffer[0] * 256 + local_buffer[1];
>
> This is kind of a hand rolled be16_to_cpu().
>
> And we also have the + 2 to skip the length in several places.
>
> I feel like the code would be cleaner if we had a type for the result
> buffer, eg something like:
>
> union {
> char raw_buffer[1026];
> struct {
> __be16 len;
> char data[1024];
> };
> };
>
>> + /*
>> + * Forces an empty string in the weird case fw reports no data.
>> + */
>> + if (!len)
>> + local_buffer[2] = '\0';
>> +
>> + seq_printf(m, "partition_name=%s\n", local_buffer + 2);
>
> Then above you could use the data field rather than having to add the
> "2" in both places.
>
>> + }
>> +
>> + kfree(local_buffer);
>> +}
>> +
>> +
>> #define SPLPAR_CHARACTERISTICS_TOKEN 20
>> #define SPLPAR_MAXLENGTH 1026*(sizeof(char))
>>
>> @@ -496,6 +548,7 @@ static int pseries_lparcfg_data(struct seq_file *m, void *v)
>>
>> if (firmware_has_feature(FW_FEATURE_SPLPAR)) {
>> /* this call handles the ibm,get-system-parameter contents */
>> + parse_lpar_name(m);
>> parse_system_parameter_string(m);
>> parse_ppp_data(m);
>> parse_mpp_data(m);
>> --
>> 2.34.1
>
>
> cheers
>
^ permalink raw reply
* [PATCH v3] powerpc/pseries: read the lpar name from the firmware
From: Laurent Dufour @ 2021-12-03 15:43 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nathan Lynch, linux-kernel
The LPAR name may be changed after the LPAR has been started in the HMC.
In that case lparstat command is not reporting the updated value because it
reads it from the device tree which is read at boot time.
However this value could be read from RTAS.
Adding this value in the /proc/powerpc/lparcfg output allows to read the
updated value.
Cc: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com>
---
v3:
address Michael's comments.
v2:
address Nathan's comments.
change title to partition_name aligning with existing partition_id
---
arch/powerpc/platforms/pseries/lparcfg.c | 54 ++++++++++++++++++++++++
1 file changed, 54 insertions(+)
diff --git a/arch/powerpc/platforms/pseries/lparcfg.c b/arch/powerpc/platforms/pseries/lparcfg.c
index f71eac74ea92..5f6dbc23d7d2 100644
--- a/arch/powerpc/platforms/pseries/lparcfg.c
+++ b/arch/powerpc/platforms/pseries/lparcfg.c
@@ -311,6 +311,59 @@ static void parse_mpp_x_data(struct seq_file *m)
seq_printf(m, "coalesce_pool_spurr=%ld\n", mpp_x_data.pool_spurr_cycles);
}
+/*
+ * PAPR defines, in section "7.3.16 System Parameters Option", the token 55 to
+ * read the LPAR name.
+ */
+#define SPLPAR_LPAR_NAME_TOKEN 55
+static void read_lpar_name(struct seq_file *m)
+{
+ int rc, len, token;
+ union {
+ char raw_buffer[RTAS_DATA_BUF_SIZE];
+ struct {
+ __be16 len;
+ char name[RTAS_DATA_BUF_SIZE-2];
+ };
+ } *local_buffer;
+
+ token = rtas_token("ibm,get-system-parameter");
+ if (token == RTAS_UNKNOWN_SERVICE)
+ return;
+
+ local_buffer = kmalloc(sizeof(*local_buffer), GFP_KERNEL);
+ if (!local_buffer)
+ return;
+
+ do {
+ spin_lock(&rtas_data_buf_lock);
+ memset(rtas_data_buf, 0, RTAS_DATA_BUF_SIZE);
+ rc = rtas_call(token, 3, 1, NULL, SPLPAR_LPAR_NAME_TOKEN,
+ __pa(rtas_data_buf), RTAS_DATA_BUF_SIZE);
+ if (!rc)
+ memcpy(local_buffer->raw_buffer, rtas_data_buf,
+ RTAS_DATA_BUF_SIZE);
+ spin_unlock(&rtas_data_buf_lock);
+ } while (rtas_busy_delay(rc));
+
+ if (rc != 0) {
+ pr_err_once(
+ "%s %s Error calling get-system-parameter (0x%x)\n",
+ __FILE__, __func__, rc);
+ } else {
+ /* Force end of string */
+ len = be16_to_cpu(local_buffer->len);
+ if (len >= (RTAS_DATA_BUF_SIZE-2))
+ len = RTAS_DATA_BUF_SIZE-2;
+ local_buffer->name[len] = '\0';
+
+ seq_printf(m, "partition_name=%s\n", local_buffer->name);
+ }
+
+ kfree(local_buffer);
+}
+
+
#define SPLPAR_CHARACTERISTICS_TOKEN 20
#define SPLPAR_MAXLENGTH 1026*(sizeof(char))
@@ -496,6 +549,7 @@ static int pseries_lparcfg_data(struct seq_file *m, void *v)
if (firmware_has_feature(FW_FEATURE_SPLPAR)) {
/* this call handles the ibm,get-system-parameter contents */
+ read_lpar_name(m);
parse_system_parameter_string(m);
parse_ppp_data(m);
parse_mpp_data(m);
--
2.34.1
^ permalink raw reply related
* Re: [RFC patch 0/5] Support BCLK input clock in tlv320aic31xx
From: Ariel D'Alessandro @ 2021-12-03 17:25 UTC (permalink / raw)
To: Mark Brown, alsa-devel, linuxppc-dev, linux-kernel
Cc: bkylerussell, kuninori.morimoto.gx, Xiubo.Lee, shengjiu.wang,
tiwai, lgirdwood, perex, nicoleotsuka, michael, festevam
In-Reply-To: <163762561675.2471742.16439171676950432106.b4-ty@kernel.org>
Hi Mark,
On 11/22/21 9:00 PM, Mark Brown wrote:
> On Fri, 19 Nov 2021 12:32:43 -0300, Ariel D'Alessandro wrote:
>> The tlv320aic31xx codec allows using BCLK as the input clock for PLL,
>> deriving all the frequencies through a set of divisors.
>>
>> In this case, codec sysclk is determined by the hwparams sample
>> rate/format. So its frequency must be updated from the codec itself when
>> these are changed.
>>
>> [...]
>
> Applied to
>
> https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
>
> Thanks!
>
> [1/5] ASoC: tlv320aic31xx: Fix typo in BCLK clock name
> commit: 7016fd940adf2f4d86032339b546c6ecd737062f
> [2/5] ASoC: tlv320aic31xx: Add support for pll_r coefficient
> commit: 2664b24a8c51c21b24c2b37b7f10d6485c35b7c1
> [3/5] ASoC: tlv320aic31xx: Add divs for bclk as clk_in
> commit: 6e6752a9c78738e27bde6da5cefa393b589276bb
> [4/5] ASoC: tlv320aic31xx: Handle BCLK set as PLL input configuration
> commit: c5d22d5e12e776fee4e346dc098fe51d00c2f983
> [5/5] ASoC: fsl-asoc-card: Support fsl,imx-audio-tlv320aic31xx codec
> commit: 8c9b9cfb7724685ce705f511b882f30597596536
>
> All being well this means that it will be integrated into the linux-next
> tree (usually sometime in the next 24 hours) and sent to Linus during
> the next merge window (or sooner if it is a bug fix), however if
> problems are discovered then the patch may be dropped or reverted.
>
> You may get further e-mails resulting from automated or manual testing
> and review of the tree, please engage with people reporting problems and
> send followup patches addressing any issues that are reported if needed.
>
> If any updates are required or you are submitting further changes they
> should be sent as incremental updates against current git, existing
> patches will not be replaced.
Quick question:
I gotta send a fix for one of the patches. So, should it be a new
incremental patch or I can still send a patchset v2?
Also, I sent an incremental update patchset on top of this one:
[PATCH 0/4] fsl-asoc-card: Add optional dt property for setting mclk-id
I could merge altogether on a patchset v2. Please let me know, and sorry
the process it's not clear to me :-)
Thanks,
Ariel
^ permalink raw reply
* Re: [RFC patch 5/5] ASoC: fsl-asoc-card: Support fsl,imx-audio-tlv320aic31xx codec
From: Ariel D'Alessandro @ 2021-12-03 17:27 UTC (permalink / raw)
To: alsa-devel, linux-kernel, linuxppc-dev
Cc: bkylerussell, kuninori.morimoto.gx, Xiubo.Lee, shengjiu.wang,
tiwai, lgirdwood, perex, nicoleotsuka, broonie, michael, festevam
In-Reply-To: <20211119153248.419802-6-ariel.dalessandro@collabora.com>
On 11/19/21 12:32 PM, Ariel D'Alessandro wrote:
> Add entry for fsl,imx-audio-tlv320aic31xx audio codec. This codec is
> configured to use BCLK as clock input.
>
> Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
> Signed-off-by: Ariel D'Alessandro <ariel.dalessandro@collabora.com>
> ---
> sound/soc/fsl/fsl-asoc-card.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/sound/soc/fsl/fsl-asoc-card.c b/sound/soc/fsl/fsl-asoc-card.c
> index 6e6494f9f399..90cbed496f98 100644
> --- a/sound/soc/fsl/fsl-asoc-card.c
> +++ b/sound/soc/fsl/fsl-asoc-card.c
> @@ -26,6 +26,7 @@
> #include "../codecs/wm8962.h"
> #include "../codecs/wm8960.h"
> #include "../codecs/wm8994.h"
> +#include "../codecs/tlv320aic31xx.h"
>
> #define CS427x_SYSCLK_MCLK 0
>
> @@ -629,6 +630,16 @@ static int fsl_asoc_card_probe(struct platform_device *pdev)
> } else if (of_device_is_compatible(np, "fsl,imx-audio-tlv320aic32x4")) {
> codec_dai_name = "tlv320aic32x4-hifi";
> priv->dai_fmt |= SND_SOC_DAIFMT_CBP_CFP;
> + } else if (of_device_is_compatible(np, "fsl,imx-audio-tlv320aic31xx")) {
> + codec_dai_name = "tlv320dac31xx-hifi";
> + priv->dai_fmt |= SND_SOC_DAIFMT_CBS_CFS;
> + priv->dai_link[1].dpcm_capture = 0;
> + priv->dai_link[2].dpcm_capture = 0;
> + priv->cpu_priv.sysclk_dir[TX] = SND_SOC_CLOCK_OUT;
> + priv->cpu_priv.sysclk_dir[RX] = SND_SOC_CLOCK_OUT;
> + priv->codec_priv.mclk_id = AIC31XX_PLL_CLKIN_BCLK;
> + priv->card.dapm_routes = audio_map_tx;
> + priv->card.num_dapm_routes = ARRAY_SIZE(audio_map_tx);
> } else if (of_device_is_compatible(np, "fsl,imx-audio-wm8962")) {
> codec_dai_name = "wm8962";
> priv->codec_priv.mclk_id = WM8962_SYSCLK_MCLK;
> @@ -888,6 +899,7 @@ static const struct of_device_id fsl_asoc_card_dt_ids[] = {
> { .compatible = "fsl,imx-audio-cs42888", },
> { .compatible = "fsl,imx-audio-cs427x", },
> { .compatible = "fsl,imx-audio-tlv320aic32x4", },
> + { .compatible = "fsl,imx-audio-tlv320aic31xx", },
> { .compatible = "fsl,imx-audio-sgtl5000", },
> { .compatible = "fsl,imx-audio-wm8962", },
> { .compatible = "fsl,imx-audio-wm8960", },
The following config is missing and must be added.
diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index 8e05d092790e..14a06d9418a7 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -312,6 +312,7 @@ config SND_SOC_FSL_ASOC_CARD
select SND_SOC_FSL_SAI
select SND_SOC_FSL_SSI
+ select SND_SOC_TLV320AIC31XX
select SND_SOC_WM8994
select MFD_WM8994
help
Regards,
Ariel
^ permalink raw reply related
* Re: [RFC patch 0/5] Support BCLK input clock in tlv320aic31xx
From: Mark Brown @ 2021-12-03 17:34 UTC (permalink / raw)
To: Ariel D'Alessandro
Cc: alsa-devel, lgirdwood, kuninori.morimoto.gx, Xiubo.Lee,
linuxppc-dev, shengjiu.wang, tiwai, linux-kernel, perex,
nicoleotsuka, bkylerussell, michael, festevam
In-Reply-To: <6a2ff1f0-ebd9-be6d-9b2c-5704edd7c25d@collabora.com>
[-- Attachment #1: Type: text/plain, Size: 427 bytes --]
On Fri, Dec 03, 2021 at 02:25:17PM -0300, Ariel D'Alessandro wrote:
> On 11/22/21 9:00 PM, Mark Brown wrote:
> > If any updates are required or you are submitting further changes they
> > should be sent as incremental updates against current git, existing
> > patches will not be replaced.
> I gotta send a fix for one of the patches. So, should it be a new
> incremental patch or I can still send a patchset v2?
See above.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [RFC patch 0/5] Support BCLK input clock in tlv320aic31xx
From: Ariel D'Alessandro @ 2021-12-03 17:37 UTC (permalink / raw)
To: Mark Brown
Cc: alsa-devel, lgirdwood, kuninori.morimoto.gx, Xiubo.Lee,
linuxppc-dev, shengjiu.wang, tiwai, linux-kernel, perex,
nicoleotsuka, bkylerussell, michael, festevam
In-Reply-To: <YapVH3b9urxvngWG@sirena.org.uk>
Hi Mark,
On 12/3/21 2:34 PM, Mark Brown wrote:
> On Fri, Dec 03, 2021 at 02:25:17PM -0300, Ariel D'Alessandro wrote:
>> On 11/22/21 9:00 PM, Mark Brown wrote:
>
>>> If any updates are required or you are submitting further changes they
>>> should be sent as incremental updates against current git, existing
>>> patches will not be replaced.
>
>> I gotta send a fix for one of the patches. So, should it be a new
>> incremental patch or I can still send a patchset v2?
>
> See above.
Got it, thank you for confirming it.
^ permalink raw reply
* [PATCH 1/1] ASoC: fsl-asoc-card: Add missing Kconfig option for tlv320aic31xx
From: Ariel D'Alessandro @ 2021-12-03 17:50 UTC (permalink / raw)
To: alsa-devel, devicetree, linux-kernel, linux-omap, linuxppc-dev
Cc: ariel.dalessandro, kuninori.morimoto.gx, Xiubo.Lee, tony,
shengjiu.wang, tiwai, lgirdwood, robh+dt, perex, nicoleotsuka,
broonie, bcousson, michael, festevam
This is a follow up of patchsets:
[RFC patch 0/5] Support BCLK input clock in tlv320aic31xx
[PATCH 0/4] fsl-asoc-card: Add optional dt property for setting mclk-id
Patch "ASoC: fsl-asoc-card: Support fsl,imx-audio-tlv320aic31xx codec"
in "[RFC patch 0/5] Support BCLK input clock in tlv320aic31xx" missed a
Kconfig option. Sending incremental patch fix.
Regards,
Ariel
Ariel D'Alessandro (1):
ASoC: fsl-asoc-card: Add missing Kconfig option for tlv320aic31xx
sound/soc/fsl/Kconfig | 1 +
1 file changed, 1 insertion(+)
--
2.30.2
^ permalink raw reply
* [PATCH 1/1] ASoC: fsl-asoc-card: Add missing Kconfig option for tlv320aic31xx
From: Ariel D'Alessandro @ 2021-12-03 17:50 UTC (permalink / raw)
To: alsa-devel, devicetree, linux-kernel, linux-omap, linuxppc-dev
Cc: ariel.dalessandro, kuninori.morimoto.gx, Xiubo.Lee, tony,
shengjiu.wang, tiwai, lgirdwood, robh+dt, perex, nicoleotsuka,
broonie, bcousson, michael, festevam
In-Reply-To: <20211203175018.252641-1-ariel.dalessandro@collabora.com>
The following commit added support for tlv320aic31xx codec to
fsl-asoc-card, but missed the related Kconfig option. Fix this.
commit 8c9b9cfb7724685ce705f511b882f30597596536
Author: Ariel D'Alessandro <ariel.dalessandro@collabora.com>
Date: Fri Nov 19 12:32:48 2021 -0300
ASoC: fsl-asoc-card: Support fsl,imx-audio-tlv320aic31xx codec
Signed-off-by: Ariel D'Alessandro <ariel.dalessandro@collabora.com>
Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
---
sound/soc/fsl/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index 8e05d092790e..10fa38753453 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -311,6 +311,7 @@ config SND_SOC_FSL_ASOC_CARD
select SND_SOC_FSL_ESAI
select SND_SOC_FSL_SAI
select SND_SOC_FSL_SSI
+ select SND_SOC_TLV320AIC31XX
select SND_SOC_WM8994
select MFD_WM8994
help
--
2.30.2
^ permalink raw reply related
* Re: [PATCH 1/1] ASoC: fsl-asoc-card: Add missing Kconfig option for tlv320aic31xx
From: Mark Brown @ 2021-12-03 18:11 UTC (permalink / raw)
To: Ariel D'Alessandro
Cc: devicetree, alsa-devel, michael, kuninori.morimoto.gx, Xiubo.Lee,
tony, festevam, shengjiu.wang, tiwai, linux-kernel, lgirdwood,
nicoleotsuka, robh+dt, bcousson, perex, linux-omap, linuxppc-dev
In-Reply-To: <20211203175018.252641-1-ariel.dalessandro@collabora.com>
[-- Attachment #1: Type: text/plain, Size: 556 bytes --]
On Fri, Dec 03, 2021 at 02:50:17PM -0300, Ariel D'Alessandro wrote:
> This is a follow up of patchsets:
>
> [RFC patch 0/5] Support BCLK input clock in tlv320aic31xx
> [PATCH 0/4] fsl-asoc-card: Add optional dt property for setting mclk-id
Please don't send cover letters for single patches, if there is anything
that needs saying put it in the changelog of the patch or after the ---
if it's administrative stuff. This reduces mail volume and ensures that
any important information is recorded in the changelog rather than being
lost.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH RFC 1/4] mm: percpu: Generalize percpu related config
From: Catalin Marinas @ 2021-12-03 18:54 UTC (permalink / raw)
To: Kefeng Wang
Cc: linux-ia64, dave.hansen, linux-mips, linux-mm, paulus, hpa,
sparclinux, cl, will, linux-riscv, x86, mingo, dennis, aou, bp,
paul.walmsley, tglx, linux-arm-kernel, tsbogend, gregkh,
linux-kernel, palmer, tj, akpm, linuxppc-dev, davem
In-Reply-To: <20211121093557.139034-2-wangkefeng.wang@huawei.com>
On Sun, Nov 21, 2021 at 05:35:54PM +0800, Kefeng Wang wrote:
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index c4207cf9bb17..4ff73299f8a9 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -1135,6 +1135,10 @@ config NUMA
> select GENERIC_ARCH_NUMA
> select ACPI_NUMA if ACPI
> select OF_NUMA
> + select HAVE_SETUP_PER_CPU_AREA
> + select NEED_PER_CPU_EMBED_FIRST_CHUNK
> + select NEED_PER_CPU_PAGE_FIRST_CHUNK
> + select USE_PERCPU_NUMA_NODE_ID
> help
> Enable NUMA (Non-Uniform Memory Access) support.
>
> @@ -1151,22 +1155,6 @@ config NODES_SHIFT
> Specify the maximum number of NUMA Nodes available on the target
> system. Increases memory reserved to accommodate various tables.
>
> -config USE_PERCPU_NUMA_NODE_ID
> - def_bool y
> - depends on NUMA
> -
> -config HAVE_SETUP_PER_CPU_AREA
> - def_bool y
> - depends on NUMA
> -
> -config NEED_PER_CPU_EMBED_FIRST_CHUNK
> - def_bool y
> - depends on NUMA
> -
> -config NEED_PER_CPU_PAGE_FIRST_CHUNK
> - def_bool y
> - depends on NUMA
> -
> source "kernel/Kconfig.hz"
>
> config ARCH_SPARSEMEM_ENABLE
For arm64:
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* RE: bug: usb: gadget: FSL_UDC_CORE Corrupted request list leads to unrecoverable loop.
From: Leo Li @ 2021-12-04 0:40 UTC (permalink / raw)
To: jocke@infinera.com, regressions@leemhuis.info,
Eugene_Bordenkircher@selinc.com, linux-usb@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
Cc: gregkh@linuxfoundation.org, balbi@kernel.org
In-Reply-To: <f31008a0f4e71ff029aa611b0ebcfd83f10ec67f.camel@infinera.com>
> -----Original Message-----
> From: Joakim Tjernlund <Joakim.Tjernlund@infinera.com>
> Sent: Thursday, December 2, 2021 4:45 PM
> To: regressions@leemhuis.info; Leo Li <leoyang.li@nxp.com>;
> Eugene_Bordenkircher@selinc.com; linux-usb@vger.kernel.org; linuxppc-
> dev@lists.ozlabs.org
> Cc: gregkh@linuxfoundation.org; balbi@kernel.org
> Subject: Re: bug: usb: gadget: FSL_UDC_CORE Corrupted request list leads to
> unrecoverable loop.
>
> On Thu, 2021-12-02 at 20:35 +0000, Leo Li wrote:
> >
> > > -----Original Message-----
> > > From: Joakim Tjernlund <Joakim.Tjernlund@infinera.com>
> > > Sent: Wednesday, December 1, 2021 8:19 AM
> > > To: regressions@leemhuis.info; Leo Li <leoyang.li@nxp.com>;
> > > Eugene_Bordenkircher@selinc.com; linux-usb@vger.kernel.org;
> > > linuxppc- dev@lists.ozlabs.org
> > > Cc: gregkh@linuxfoundation.org; balbi@kernel.org
> > > Subject: Re: bug: usb: gadget: FSL_UDC_CORE Corrupted request list
> > > leads to unrecoverable loop.
> > >
> > > On Tue, 2021-11-30 at 12:56 +0100, Joakim Tjernlund wrote:
> > > > On Mon, 2021-11-29 at 23:48 +0000, Eugene Bordenkircher wrote:
> > > > > Agreed,
> > > > >
> > > > > We are happy pick up the torch on this, but I'd like to try and
> > > > > hear from
> > > Joakim first before we do. The patch set is his, so I'd like to
> > > give him the opportunity. I think he's the only one that can add a
> > > truly proper description as well because he mentioned that this
> > > includes a "few more fixes" than just the one we ran into. I'd
> > > rather hear from him than try to reverse engineer what was being
> addressed.
> > > > >
> > > > > Joakim, if you are still watching the thread, would you like to
> > > > > take a stab
> > > at it? If I don't hear from you in a couple days, we'll pick up the
> > > torch and do what we can.
> > > > >
> > > >
> > > > I am far away from this now and still on 4.19. I don't mind if you
> > > > tweak
> > > tweak the patches for better "upstreamability"
> > >
> > > Even better would be to migrate to the chipidea driver, I am told
> > > just a few tweaks are needed but this is probably something NXP
> > > should do as they have access to other SOC's using chipidea.
> >
> > I agree with this direction but the problem was with bandwidth. As this
> controller was only used on legacy platforms, it is harder to justify new effort
> on it now.
> >
>
> Legacy? All PPC is legacy and not supported now?
I'm not saying that they are not supported, but they are in maintenance only mode.
Regards,
Leo
^ 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