[PATCH] powerpc/powernv: Enable CPU idle state detection for POWER11

Extend idle state detection to POWER11 by updating the PVR check. This ensures POWER11 correctly recognizes supported stop states, similar to POWER9 and POWER10. Reviewed-by: Mahesh Salgaonkar Signed-off-by: Aboorva Devarajan --- Without Patch: (Power11 - PowerNV systems) CPUidle driver: powe

Re: [PATCH] powerpc/boot: Fix build with gcc 15

On Thu, Apr 17, 2025 at 01:02:05PM +0200, Michal Suchánek wrote: > On Thu, Apr 17, 2025 at 11:37:09AM +0530, Mukesh Kumar Chaurasiya wrote: > > On Fri, Mar 07, 2025 at 10:20:52AM +0100, Michal Suchanek wrote: > > > Similar to x86 the ppc boot code does not build with GCC 15. > > > > > > Copy the f

linux-next: build warnings after merge of the powerpc-fixes tree

Hi all, After merging the powerpc-fixes tree, today's linux-next build (powerpc_ppc64_defconfig) produced these warnings: arch/powerpc/boot/wrapper: 237: [: 0: unexpected operator ld: warning: arch/powerpc/boot/zImage.epapr has a LOAD segment with RWX permissions arch/powerpc/boot/wrapper: 237:

[PATCH] fsl_msi: Translate bitmap to hwirq on fsl,mpic

On PPC_32 QorIQ, the hwirq bitmap is done with the cascade being the most significant bits and the srs on the cascade being the least. This has the effect of filling up one cascade before the next. Since each cascade has 32 srs and is tied to a single CPU and interrupt, this means no load balancin

[PATCH] fsl_pamu: Use 40-bits for addressing where appropriate

On 64-bit QorIQ platforms like T4240, the CPU supports 40-bit addressing and it's safe to move resources to the upper bounds of the 1TiB limit to make room for > 64GiB of memory. The PAMU driver does not account for this, however. Setup fsl,pamu driver to make use of the full 40-bit addressing spa

[PATCH] 85xx: Add several root nodes to probe

T4240 fails to hafve ifc, rapidio, and localbus probed. This matches other QorIQ platforms and ensures devices under these nodes get added as platform devices. Signed-off-by: Ben Collins Cc: Scott Wood Cc: Madhavan Srinivasan Cc: Michael Ellerman Cc: linuxppc-dev@lists.ozlabs.org Cc: linux-ke

[PATCH] powerpc/addnote: Fix overflow on 32-bit builds

The PUT_64[LB]E() macros need to cast the value to unsigned long long like the GET_64[LB]E() macros. Caused lots of warnings when compiled on 32-bit, and clobbered addresses (36-bit P4080). Signed-off-by: Ben Collins Cc: Madhavan Srinivasan Cc: Michael Ellerman Cc: linuxppc-dev@lists.ozlabs.org

[PATCH AUTOSEL 6.14 07/30] ASoC: fsl_asrc_dma: get codec or cpu dai from backend

From: Shengjiu Wang [ Upstream commit ef5c23ae9ab380fa756f257411024a9b4518d1b9 ] With audio graph card, original cpu dai is changed to codec device in backend, so if cpu dai is dummy device in backend, get the codec dai device, which is the real hardware device connected. The specific case is A

Re: linux-next: build warnings after merge of the powerpc-fixes tree

Hi Madhavan, On Tue, 22 Apr 2025 11:20:38 +0530 Madhavan Srinivasan wrote: > > I cant recreate this in both my x86_64 cross build and ppc64 build with dash. > I tried both ppc64_defconfig and pseries_le_defconfig compilation. > > x86_64 dash version : dash-0.5.12-3.fc40.x86_64 > powerpc dash ve

[PATCH AUTOSEL 6.12 07/23] ASoC: fsl_asrc_dma: get codec or cpu dai from backend

From: Shengjiu Wang [ Upstream commit ef5c23ae9ab380fa756f257411024a9b4518d1b9 ] With audio graph card, original cpu dai is changed to codec device in backend, so if cpu dai is dummy device in backend, get the codec dai device, which is the real hardware device connected. The specific case is A

[PATCH] fsldma: Support 40 bit DMA addresses where capable

On 64-bit QorIQ platforms like T4240, the CPU supports 40-bit addressing and memory configurations > 64GiB. The fsldma driver is limiting itself to only 64GiB in all Elo configurations. Setup fsldma driver to make use of the full 40-bit addressing space, specifically on the e5500 and e6500 CPUs.

Re: [PATCH] fsldma: Support 40 bit DMA addresses where capable

On Tue, Apr 22, 2025, at 04:49, Ben Collins wrote: > On 64-bit QorIQ platforms like T4240, the CPU supports 40-bit addressing > and memory configurations > 64GiB. The fsldma driver is limiting itself > to only 64GiB in all Elo configurations. > > Setup fsldma driver to make use of the full 40-bit a

[PATCH] kexec: Include kernel-end even without crashkernel

Certain versions of kexec don't even work without kernel-end being added to the device-tree. Add it even if crash-kernel is disabled. Signed-off-by: Ben Collins Cc: Madhavan Srinivasan Cc: Michael Ellerman Cc: linuxppc-dev@lists.ozlabs.org Cc: linux-ker...@vger.kernel.org --- arch/powerpc/kexe

Re: frozen PHB on IBM Power9 system in 6.15-rc2 (bisected)

On 4/17/25 17:10, Dan Horák wrote: Hi, I am seeing "frozen PHB" on Power9 bare-metal (PowerNV ppc64le) system leading to non-accessible nvme drives (they are behind a switch) in the 6.15-rc2 kernel (originally with kernel-6.15.0-0.rc2.22.fc43). I was able to bisect the issue to commit 62baf70c32

Re: linux-next: build warnings after merge of the powerpc-fixes tree

On 4/22/25 7:17 AM, Stephen Rothwell wrote: > Hi all, > > After merging the powerpc-fixes tree, today's linux-next build > (powerpc_ppc64_defconfig) produced these warnings: > > arch/powerpc/boot/wrapper: 237: [: 0: unexpected operator > ld: warning: arch/powerpc/boot/zImage.epapr has a LOAD s

Re: [PATCH] powerpc/pseries/msi: Avoid reading PCI device registers in reduced power states

Hello Gautam, Makes sense to track this observation separately. I tried it on fedora41 with kernel, 6.11.4-301.fc41.ppc64le, and this warning is there also. Traces: [ 105.121663] [ cut here ] [ 105.121664] WARNING: CPU: 0 PID: 16 at arch/powerpc/sysdev/xics/icp-hv.c:

Re: [PATCH bpf-next v2 05/11] bpf, arm64, powerpc: Add bpf_jit_bypass_spec_v1/v4()

kernel test robot writes: > All warnings (new ones prefixed by >>): > >>> kernel/bpf/core.c:3037:13: warning: no previous prototype for >>> 'bpf_jit_bypass_spec_v1' [-Wmissing-prototypes] > 3037 | bool __weak bpf_jit_bypass_spec_v1(void) > | ^~ >>> ke

[powerpc:merge] BUILD SUCCESS a34964eace718ce03010a3e8d29eb5a872a461e6

config-001-20250421gcc-11.5.0 arc randconfig-002-20250421gcc-13.3.0 arm allmodconfiggcc-14.2.0 arm allnoconfigclang-21 arm allyesconfiggcc-

[PATCH bpf-next v2 06/11] bpf, arm64, powerpc: Change nospec to include v1 barrier

This changes the semantics of BPF_NOSPEC (previously a v4-only barrier) to always emit a speculation barrier that works against both Spectre v1 AND v4. If mitigation is not needed on an architecture, the backend should set bpf_jit_bypass_spec_v4/v1(). As of now, this commit only has the user-visib

[PATCH bpf-next v2 03/11] bpf: Return -EFAULT on misconfigurations

Mark these cases as non-recoverable to later prevent them from being caught when they occur during speculative path verification. Eduard writes [1]: The only pace I'm aware of that might act upon specific error code from verifier syscall is libbpf. Looking through libbpf code, it seems that

[PATCH bpf-next v2 04/11] bpf: Return -EFAULT on internal errors

This prevents us from trying to recover from these on speculative paths in the future. Signed-off-by: Luis Gerhorst Reviewed-by: Eduard Zingerman Acked-by: Henriette Herzog Cc: Maximilian Ott Cc: Milan Stephan --- kernel/bpf/verifier.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions

Re: [PATCH] powerpc64/ftrace: fix module loading without patchable function entries

On Wed, 05 Feb 2025 00:18:21 +0100, Anthony Iliopoulos wrote: > get_stubs_size assumes that there must always be at least one patchable > function entry, which is not always the case (modules that export data > but no code), otherwise it returns -ENOEXEC and thus the section header > sh_size is set

Re: [PATCH] powerpc/boot: Check for ld-option support

On Tue, 01 Apr 2025 06:12:18 +0530, Madhavan Srinivasan wrote: > Commit 579aee9fc594 ("powerpc: suppress some linker warnings in recent linker > versions") > enabled support to add linker option "--no-warn-rwx-segments", > if the version is greater than 2.39. Similar build warning were > reported

Re: [RFC PATCH] powerpc: Add check to select PPC_RADIX_BROADCAST_TLBIE

On Mon, 07 Apr 2025 14:10:29 +0530, Madhavan Srinivasan wrote: > Commit 3d45a3d0d2e6 ("powerpc: Define config option for processors with > broadcast TLBIE") > added a config option PPC_RADIX_BROADCAST_TLBIE to support processors with > broadcast TLBIE. Since this option is relevant only for RADIX_

[PATCH bpf-next v2 09/11] selftests/bpf: Add test for Spectre v1 mitigation

This is based on the gadget from the description of commit 9183671af6db ("bpf: Fix leakage under speculation on mispredicted branches"). Signed-off-by: Luis Gerhorst --- .../selftests/bpf/progs/verifier_unpriv.c | 57 +++ 1 file changed, 57 insertions(+) diff --git a/tools/t

[PATCH bpf-next v2 07/11] bpf: Rename sanitize_stack_spill to nospec_result

This is made to clarify that this flag will cause a nospec to be added after this insn and can therefore be relied upon to reduce speculative path analysis. Signed-off-by: Luis Gerhorst Cc: Henriette Herzog Cc: Maximilian Ott Cc: Milan Stephan --- include/linux/bpf_verifier.h | 2 +- kernel/b

[PATCH bpf-next v2 10/11] bpf: Allow nospec-protected var-offset stack access

Insert a nospec before the access to prevent it from ever using an index that is subject to speculative scalar-confusion. The access itself can either happen directly in the BPF program (reads only, check_stack_read_var_off()) or in a helper (read/write, check_helper_mem_access()). This relies on

[PATCH bpf-next v2 11/11] bpf: Fall back to nospec for sanitization-failures

ALU sanitization was introduced to ensure that a subsequent ptr access can never go OOB, even under speculation. This is required because we currently allow speculative scalar confusion. Spec. scalar confusion is possible because Spectre v4 sanitization only adds a nospec after critical stores (e.g

[PATCH bpf-next v2 08/11] bpf: Fall back to nospec for Spectre v1

This implements the core of the series and causes the verifier to fall back to mitigating Spectre v1 using speculation barriers. The approach was presented at LPC'24 [1] and RAID'24 [2]. If we find any forbidden behavior on a speculative path, we insert a nospec (e.g., lfence speculation barrier o

[PATCH 2/2] ASoC: fsl_rpmsg: Allocate a smaller buffer size for capture stream

If both playback and capture streams have large buffer size in low power audio case, the total size will exceed the maximum buffer size for this sound card. Capture stream doesn't need so large buffer size in fact. So calculate a reasonable smaller buffer size and allocate it for capture stream.

[PATCH 1/2] ASoC: fsl_rpmsg: Configure CPU DAI for card that sits on rpmsg-micfil-channel

Sound card that sits on rpmsg-micfil-channel has different settings on CPU DAI. Signed-off-by: Chancel Liu --- sound/soc/fsl/fsl_rpmsg.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/sound/soc/fsl/fsl_rpmsg.c b/sound/soc/fsl/fsl_rpmsg.c index 6d67db4e0581..4e3ca05bedd6 100644 -

[PATCH bpf-next v2 00/11] bpf: Mitigate Spectre v1 using barriers

This improves the expressiveness of unprivileged BPF by inserting speculation barriers instead of rejecting the programs. The approach was previously presented at LPC'24 [1] and RAID'24 [2]. To mitigate the Spectre v1 (PHT) vulnerability, the kernel rejects potentially-dangerous unprivileged BPF

[PATCH bpf-next v2 05/11] bpf, arm64, powerpc: Add bpf_jit_bypass_spec_v1/v4()

JITs can set bpf_jit_bypass_spec_v1/v4() if they want the verifier to skip analysis/patching for the respective vulnerability. For v4, this will reduce the number of barriers the verifier inserts. For v1, it allows more programs to be accepted. The primary motivation for this is to not regress unp

Re: [PATCH v3 1/2] book3s64/radix: Fix compile errors when CONFIG_ARCH_WANT_OPTIMIZE_DAX_VMEMMAP=n

On Mon, 10 Mar 2025 07:44:09 -0500, Donet Tom wrote: > Fix compile errors when CONFIG_ARCH_WANT_OPTIMIZE_DAX_VMEMMAP=n > > Applied to powerpc/fixes. [1/2] book3s64/radix: Fix compile errors when CONFIG_ARCH_WANT_OPTIMIZE_DAX_VMEMMAP=n https://git.kernel.org/powerpc/c/29bdc1f1c1df80868fb3

[PATCH 1/2] powerpc: kvm: use generic transfer to guest mode work

There is generic entry framework to handle signals and check for reschedule etc before entering the guest. Use that framework for powerpc. Advantages: - Less code duplication. - powerpc kvm now understands NR and NR_lazy bits. - powerpc can enable HAVE_POSIX_CPU_TIMERS_TASK_WORK, currently the p

[PATCH 2/2] powerpc: enable to run posix cpu timers in task context

Now that all kvm entry to guest paths handle the task work using the generic framework, enable HAVE_POSIX_CPU_TIMERS_TASK_WORK which allows running posix cpu timers in task context instead of running them in hardirq. This would is a necessary step towards enabling PREEMPT_RT on powerNV systems. Si

[PATCH 0/2] powerpc: kvm: generic framework and run posix timers in task context

From: Gautam Menghani This is an effort to use the generic kvm infra which handles check for need_resched, handling signals etc. i.e xfer_to_guest_mode_handle_work. kvm guests boots and runs stress-ng CPU stressor on PowerVM and on PowerNV. preempt=full and preempt=lazy was tested on PowerNV

[PATCH bpf-next v2 01/11] selftests/bpf: Fix caps for __xlated/jited_unpriv

Currently, __xlated_unpriv and __jited_unpriv do not work because the BPF syscall will overwrite info.jited_prog_len and info.xlated_prog_len with 0 if the process is not bpf_capable(). This bug was not noticed before, because there is no test that actually uses __xlated_unpriv/__jited_unpriv. To

[PATCH bpf-next v2 02/11] bpf: Move insn if/else into do_check_insn()

This is required to catch the errors later and fall back to a nospec if on a speculative path. Eliminate the regs variable as it is only used once and insn_idx is not modified in-between the definition and usage. Still pass insn simply to match the other check_*() functions. As Eduard points out

Re: [PATCH 0/2] powerpc: kvm: generic framework and run posix timers in task context

On 4/21/25 15:58, Shrikanth Hegde wrote: From: Gautam Menghani I made a mistake while generating the patch. Sorry about that. i will fix it up in next version. Please consider the above as: From: Shrikanth Hegde This is an effort to use the generic kvm infra which handles check for n

[PATCH] powerpc: Replace strcpy() with strscpy() in proc_ppc64_init()

strcpy() is deprecated; use strscpy() instead. Don't cast the destination buffer from 'u8[]' to 'char *' to satisfy the __must_be_array() requirement of strscpy(). No functional changes intended. Link: https://github.com/KSPP/linux/issues/88 Cc: linux-harden...@vger.kernel.org Signed-off-by: Tho

Re: [PATCH] powerpc/pseries/msi: Avoid reading PCI device registers in reduced power states

Hi Venkat, Thanks for the report. I looked into this and found that the new warning you reported can be observed even on current distro kernels, and is not caused by the patch I've posted. I was able to observe the same warning with fedora distro kernel 6.13.7-200.fc41 [ 70.294478] icp_hv_set_