JIRA: https://issues.redhat.com/browse/RHEL-190876
commit 972a7b78722cd2faee75148278322d844f4274bb
Author: Mahesh Salgaonkar <mahesh@linux.ibm.com>
Date: Thu Aug 6 10:41:17 2026 +0530
powerpc/pseries: Limit PVR list to 16 entries for CAS negotiation
Current Power system firmware caps the PVR list array size at 16 entries
during CAS (Client Architecture Support) negotiation. Passing more than
capped size to older firmware could cause an undefined behaviour and
breaks compatibility.
Future Power system firmware releases will lift this restriction and
support greater than 16 array entries.
Ensure that when running on Power11 or below hardware, the number
of PVR entries passed during CAS negotiation does not exceed the
firmware-imposed limit of 16.
In prom_send_capabilities(), compute start_index to skip the oldest
leading pvrs[] entries when running on Power11 or below hardware, so
that the pointer passed to ibm,client-architecture-support points to
ibm_architecture_vec.pvrs[start_index], presenting exactly 16 entries to
firmware.
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.ibm.com>
Tested-by: Praveen K Pandey <praveen@linux.ibm.com>
Reviewed-by: Nikhil Kumar Singh <nikhilks@linux.ibm.com>
Reviewed-by: Amit Machhiwal <amachhiw@linux.ibm.com>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20260806051120.3703698-2-mahesh@linux.ibm.com
Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-190876
commit 96e266e3bcd6ed03f0be62c2fcf92bf1e3dc8a6a
Author: Amit Machhiwal <amachhiw@linux.ibm.com>
Date: Mon Oct 28 15:46:22 2024 +0530
KVM: PPC: Book3S HV: Add Power11 capability support for Nested PAPR guests
The Power11 architected and raw mode support in Linux was merged in commit
c2ed087ed3 ("powerpc: Add Power11 architected and raw mode"), and the
corresponding support in QEMU is pending in [1], which is currently in
its V6.
Currently, booting a KVM guest inside a pseries LPAR (Logical Partition)
on a kernel without P11 support results the guest boot in a Power10
compatibility mode (i.e., with logical PVR of Power10). However, booting
a KVM guest on a kernel with P11 support causes the following boot crash.
On a Power11 LPAR, the Power Hypervisor (L0) returns a support for both
Power10 and Power11 capabilities through H_GUEST_GET_CAPABILITIES hcall.
However, KVM currently supports only Power10 capabilities, resulting in
only Power10 capabilities being set as "nested capabilities" via an
H_GUEST_SET_CAPABILITIES hcall.
In the guest entry path, gs_msg_ops_kvmhv_nestedv2_config_fill_info() is
called by kvmhv_nestedv2_flush_vcpu() to fill the GSB (Guest State
Buffer) elements. The arch_compat is set to the logical PVR of Power11,
followed by an H_GUEST_SET_STATE hcall. This hcall returns
H_INVALID_ELEMENT_VALUE as a return code when setting a Power11 logical
PVR, as only Power10 capabilities were communicated as supported between
PHYP and KVM, utimately resulting in the KVM guest boot crash.
KVM: unknown exit, hardware reason ffffffffffffffea
NIP 000000007daf97e0 LR 000000007daf1aec CTR 000000007daf1ab4 XER 0000000020040000 CPU#0
MSR 8000000000103000 HID0 0000000000000000 HF 6c002000 iidx 3 didx 3
TB 00000000 00000000 DECR 0
GPR00 8000000000003000 000000007e580e20 000000007db26700 0000000000000000
GPR04 00000000041a0c80 000000007df7f000 0000000000200000 000000007df7f000
GPR08 000000007db6d5d8 000000007e65fa90 000000007db6d5d0 0000000000003000
GPR12 8000000000000001 0000000000000000 0000000000000000 0000000000000000
GPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR20 0000000000000000 0000000000000000 0000000000000000 000000007db21a30
GPR24 000000007db65000 0000000000000000 0000000000000000 0000000000000003
GPR28 000000007db6d5e0 000000007db22220 000000007daf27ac 000000007db75000
CR 20000404 [ E - - - - G - G ] RES 000@ffffffffffffffff
SRR0 000000007daf97e0 SRR1 8000000000102000 PVR 0000000000820200 VRSAVE 0000000000000000
SPRG0 0000000000000000 SPRG1 000000000000ff20 SPRG2 0000000000000000 SPRG3 0000000000000000
SPRG4 0000000000000000 SPRG5 0000000000000000 SPRG6 0000000000000000 SPRG7 0000000000000000
CFAR 0000000000000000
LPCR 0000000000020400
PTCR 0000000000000000 DAR 0000000000000000 DSISR 0000000000000000
Fix this by adding the Power11 capability support and the required
plumbing in place.
Note:
* Booting a Power11 KVM nested PAPR guest requires [1] in QEMU.
[1] https://lore.kernel.org/all/20240731055022.696051-1-adityag@linux.ibm.com/
Signed-off-by: Amit Machhiwal <amachhiw@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://patch.msgid.link/20241028101622.741573-1-amachhiw@linux.ibm.com
Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/3355
s390/cpum_cf: Handle CPU hotplug via prepare/dead callbacks
JIRA: https://redhat.atlassian.net/browse/RHEL-248146
commit 337bd95507a16063687cfc286ea90de5cca48c37
Author: Thomas Richter tmricht@linux.ibm.com
Date: Tue Aug 11 15:39:01 2026 +0200
```
s390/cpum_cf: Handle CPU hotplug via prepare/dead callbacks
The command 'perf stat -e cycles -- <command>' crashes the kernel
when CPUs are hotplug added during that run.
Root cause is the allocation of struct cpu_cf_events at first
event initialization. The allocation is dynamic and the first
event that has task context creates such a structure for
each online CPU. This is not sufficient. CPUs may be offline
during event creation and can be set online during the
perf run time. For example commands
# echo 0 > /sys/devices/system/cpu/cpu1/online
# perf stat -e cycles -i -- stress-ng -t10s --matrix X
# sleep 1
# echo 1 > /sys/devices/system/cpu/cpu1/online
create an event for CPUs 0,2-X. Since the events are created with
task-context, the scheduler will eventually schedule the program
on CPU1. This CPU has not created and initialized any per
CPU event infrastructure as that CPU was not online at the time
of the perf invocation. Thus when the scheduler runs stress-ng
on CPU1, the function cpumf_pmu_add() refers to a NULL pointer:
struct cpu_cf_events *cpuhw = this_cpu_cfhw();
This function call is invoked after the task stress-ng has been
made runnable on CPU1. And this_cpu_cfhw() returns NULL.
The result is a panic:
Unable to handle kernel pointer dereference in virtual kernel address space
Failing address: 0000000000000000 TEID: 0000000000000483
....
Krnl PSW : 0404d00180000000 000003ef8291fd0c (cpumf_pmu_add+0x3c/0x80)
....
Call Trace:
[<000003ef8291fd0c>] cpumf_pmu_add+0x3c/0x80
[<000003ef82bb5e3e>] event_sched_in+0xae/0x190
[<000003ef82bb60d6>] merge_sched_in+0x1b6/0x390
[<000003ef82bb65b8>] visit_groups_merge.constprop.0.isra.0+0x308/0x5b0
[<000003ef82bb689a>] pmu_groups_sched_in+0x3a/0x50
[<000003ef82bb6a30>] ctx_sched_in+0x180/0x260
[<000003ef82bb780c>] perf_event_context_sched_in+0x11c/0x2d0
[<000003ef82bb79ee>] __perf_event_task_sched_in+0x2e/0xc0
[<000003ef82994834>] finish_task_switch.isra.0+0x1a4/0x250
....
Last Breaking-Event-Address:
[<000003ef8291f1d8>] this_cpu_cfhw+0x38/0x40
The issue arises only in per-task context when the CPUMF facility is
used and the scheduler picks a random CPU for such a process to run on.
The scheduler enables the CPUMF infrastructure via PMU callback
functions pmu::add() and pmu::del().
Introduce a CPU hotplug prepare/dead callback pair which creates and
removes the per CPU counter data while the CPU is offline. Count the
users which track every CPU (cpu == -1), that is perf_event_open()
events with task context and /dev/hwctr device sessions, in the new
counter cpu_cf_root::tskcnt, protected by pmc_reserve_mutex.
This ensures the infrastructure is available when
new CPU is selected to run the per-task context process.
In cpum_cf_free_root() and cpum_cf_free_cpu() ensure the reference
pointer to data structures is set to NULL before the data is freed
to prevent interrupt handlers to access stale data.
[gor@linux.ibm.com: change commit message]
Fixes: 9b9cf3c77e ("s390/cpum_cf: rework PER_CPU_DEFINE of struct cpu_cf_events")
Cc: stable@vger.kernel.org # v6.5+
Suggested-by: Heiko Carstens <hca@linux.ibm.com>
Suggested-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Assisted-by: Claude:claude-sonnet-5
Signed-off-by: Thomas Richter <tmricht@linux.ibm.com>
Acked-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
```
Signed-off-by: Jan Polensky <jpolensk@redhat.com>
Approved-by: Steve Best <sbest@redhat.com>
Approved-by: Tony Camuso <tcamuso@redhat.com>
Approved-by: CKI KWF Bot <cki-ci-bot+kwf-gitlab-com@redhat.com>
Merged-by: CKI GitLab Kmaint Pipeline Bot <26919896-cki-kmaint-pipeline-bot@users.noreply.gitlab.com>
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/3302
JIRA: https://issues.redhat.com/browse/RHEL-143335
Update the i3c master driver with all features added up to upstream
v6.19 and most fixes up to v7.2-rc7.
ACPI support for i3c is taken from one patch series in linux-next.
---
This MR includes a partial backport for only the hunks affecting i3c
from a couple treewide patches upstream. All of these fixes are related
to excluded hunks.
Omitted-fix: fd1d6b9d13f3 (`xz: fix arm fdt compile error for kmalloc replacement`)
Omitted-fix: 96a7b71c4438 (`ubd: Use pointer-to-pointers for io_thread_req arrays`)
Omitted-fix: 795469820c63 (`kcsan: test: Adjust "expect" allocation type for kmalloc_obj`)
Omitted-fix: 5548dd7fa845 (`tools/testing: fix testing/vma and testing/radix-tree build`)
Omitted-fix: 405ca72dc589 (`landlock: Fix formatting`)
Omitted-fix: 4c0134639694 (`KVM: PPC: e500: Fix build error due to using kmalloc_obj() with wrong type`)
Omitted-fix: 2d2b5507e598 (`btrfs: replace kcalloc() calls to kzalloc_objs()`)
Omitted-fix: 9f4ab0787e7b (`btrfs: do more kmalloc_obj()/kmalloc_objs() conversions`)
Omitted-fix: 37f1f51fba1a (`btrfs: convert kmalloc_array to kmalloc_objs in btrfs_calc_avail_data_space()`)
Omitted-fix: 4c6d43db2a4d (`net: dst_metadata: fix false-positive memcpy overflow in tun_dst_unclone`)
Signed-off-by: Jennifer Berringer <jberring@redhat.com>
Approved-by: Mark Langsdorf <mlangsdo@redhat.com>
Approved-by: Mark Salter <msalter@redhat.com>
Approved-by: CKI KWF Bot <cki-ci-bot+kwf-gitlab-com@redhat.com>
Merged-by: CKI GitLab Kmaint Pipeline Bot <26919896-cki-kmaint-pipeline-bot@users.noreply.gitlab.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-248146
commit 337bd95507a16063687cfc286ea90de5cca48c37
Author: Thomas Richter <tmricht@linux.ibm.com>
Date: Tue Aug 11 15:39:01 2026 +0200
s390/cpum_cf: Handle CPU hotplug via prepare/dead callbacks
The command 'perf stat -e cycles -- <command>' crashes the kernel
when CPUs are hotplug added during that run.
Root cause is the allocation of struct cpu_cf_events at first
event initialization. The allocation is dynamic and the first
event that has task context creates such a structure for
each online CPU. This is not sufficient. CPUs may be offline
during event creation and can be set online during the
perf run time. For example commands
# echo 0 > /sys/devices/system/cpu/cpu1/online
# perf stat -e cycles -i -- stress-ng -t10s --matrix X
# sleep 1
# echo 1 > /sys/devices/system/cpu/cpu1/online
create an event for CPUs 0,2-X. Since the events are created with
task-context, the scheduler will eventually schedule the program
on CPU1. This CPU has not created and initialized any per
CPU event infrastructure as that CPU was not online at the time
of the perf invocation. Thus when the scheduler runs stress-ng
on CPU1, the function cpumf_pmu_add() refers to a NULL pointer:
struct cpu_cf_events *cpuhw = this_cpu_cfhw();
This function call is invoked after the task stress-ng has been
made runnable on CPU1. And this_cpu_cfhw() returns NULL.
The result is a panic:
Unable to handle kernel pointer dereference in virtual kernel address space
Failing address: 0000000000000000 TEID: 0000000000000483
....
Krnl PSW : 0404d00180000000 000003ef8291fd0c (cpumf_pmu_add+0x3c/0x80)
....
Call Trace:
[<000003ef8291fd0c>] cpumf_pmu_add+0x3c/0x80
[<000003ef82bb5e3e>] event_sched_in+0xae/0x190
[<000003ef82bb60d6>] merge_sched_in+0x1b6/0x390
[<000003ef82bb65b8>] visit_groups_merge.constprop.0.isra.0+0x308/0x5b0
[<000003ef82bb689a>] pmu_groups_sched_in+0x3a/0x50
[<000003ef82bb6a30>] ctx_sched_in+0x180/0x260
[<000003ef82bb780c>] perf_event_context_sched_in+0x11c/0x2d0
[<000003ef82bb79ee>] __perf_event_task_sched_in+0x2e/0xc0
[<000003ef82994834>] finish_task_switch.isra.0+0x1a4/0x250
....
Last Breaking-Event-Address:
[<000003ef8291f1d8>] this_cpu_cfhw+0x38/0x40
The issue arises only in per-task context when the CPUMF facility is
used and the scheduler picks a random CPU for such a process to run on.
The scheduler enables the CPUMF infrastructure via PMU callback
functions pmu::add() and pmu::del().
Introduce a CPU hotplug prepare/dead callback pair which creates and
removes the per CPU counter data while the CPU is offline. Count the
users which track every CPU (cpu == -1), that is perf_event_open()
events with task context and /dev/hwctr device sessions, in the new
counter cpu_cf_root::tskcnt, protected by pmc_reserve_mutex.
This ensures the infrastructure is available when
new CPU is selected to run the per-task context process.
In cpum_cf_free_root() and cpum_cf_free_cpu() ensure the reference
pointer to data structures is set to NULL before the data is freed
to prevent interrupt handlers to access stale data.
[gor@linux.ibm.com: change commit message]
Fixes: 9b9cf3c77e ("s390/cpum_cf: rework PER_CPU_DEFINE of struct cpu_cf_events")
Cc: stable@vger.kernel.org # v6.5+
Suggested-by: Heiko Carstens <hca@linux.ibm.com>
Suggested-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Assisted-by: Claude:claude-sonnet-5
Signed-off-by: Thomas Richter <tmricht@linux.ibm.com>
Acked-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Jan Polensky <jpolensk@redhat.com>
JIRA: INTERNAL
Upstream Status: RHEL only
Now that we have forked from CentOS Stream, we need to switch the
release number to use the zstream scheme and update our default disttag
to match that used by the brew build environment for RHEL 10.3.
Signed-off-by: Shivani Chandanshive <schandan@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-227151
CVE: CVE-2026-53153
commit 98733f3f0becb1ae0701d021c1748e974e5fa55c
Author: Shakeel Butt <shakeel.butt@linux.dev>
Date: Mon Jun 1 09:15:01 2026 -0700
mm/list_lru: drain before clearing xarray entry on reparent
memcg_reparent_list_lrus() clears the dying memcg's xarray entry with
xas_store(&xas, NULL) before reparenting its per-node lists into the
parent. This opens a window where a concurrent list_lru_del() arriving
for the dying memcg sees xa_load() == NULL, walks to the parent in
lock_list_lru_of_memcg(), takes the parent's per-node lock, and calls
list_del_init() on an item still physically linked on the dying memcg's
list.
If another in-flight thread holds the dying memcg's per-node lock at the
same moment (another list_lru_del, or a list_lru_walk_one running an
isolate callback), both threads modify ->next/->prev pointers on the same
physical list under different locks. Adjacent items can corrupt each
other's links.
Fix it by reversing the order: reparent each per-node list and mark the
child's list lru dead and then clear the xarray entry. Any concurrent
list_lru op that finds the still-set xarray entry either takes the dying
memcg's per-node lock (synchronizing with the drain) or sees LONG_MIN and
walks to the parent, where the items now live.
Link: https://lore.kernel.org/20260601161501.1444829-1-shakeel.butt@linux.dev
Fixes: fb56fdf8b9a2 ("mm/list_lru: split the lock to per-cgroup scope")
Signed-off-by: Shakeel Butt <shakeel.butt@linux.dev>
Reported-by: Chris Mason <clm@fb.com>
Reviewed-by: Kairui Song <kasong@tencent.com>
Acked-by: Muchun Song <muchun.song@linux.dev>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Roman Gushchin <roman.gushchin@linux.dev>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Rafael Aquini <raquini@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-248519
commit 2b37415618bfc6a83d4aceb00fd8d6491096f2ed
Author: Ethan Nelson-Moore <enelsonmoore@gmail.com>
Date: Mon May 4 19:44:09 2026 -0700
watchdog: s32g_wdt: remove incorrect options in watchdog_info struct
The s32g_wdt driver uses two incorrect constants in the options field
of its watchdog_info struct. This bit mask should contain WDIOF_*
constants, but the driver uses two WDIOC_* ioctl constants (in addition
to correct WDIOF_* constants). This causes many incorrect bits to be
set in the bit mask. The functionality indicated by these ioctl
constants is supported by all drivers using the watchdog framework, so
this patch simply removes them.
Fixes: bd3f54ec559b ("watchdog: Add the Watchdog Timer for the NXP S32 platform")
Cc: stable@vger.kernel.org # 6.18+
Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
Acked-by: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260505024409.60301-1-enelsonmoore@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Jared Kangas <jkangas@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-248519
commit fc3afb5728e297994863f8a2a01b88a920bbf53e
Author: Xu Yang <xu.yang_2@nxp.com>
Date: Thu Jul 16 18:41:26 2026 +0800
usb: chipidea: fix usage_count leak when autosuspend_delay is negative
The probe() calls pm_runtime_use_autosuspend(), but remove() does not call
pm_runtime_dont_use_autosuspend(). This can lead to a usage_count leak if
autosuspend_delay is set to a negative value.
The pm_runtime_use_autosuspend() also notes that it's important to undo
this with pm_runtime_dont_use_autosuspend() at driver exit time.
Fixes: 1f874edcb7 ("usb: chipidea: add runtime power management support")
Cc: stable <stable@kernel.org>
Assisted-by: Claude:claude-sonnet-4.6
Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260716104126.2763454-1-xu.yang_2@oss.nxp.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jared Kangas <jkangas@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-248519
commit 8f6aa392653e52a45858cff5c063df550028836b
Author: Xu Yang <xu.yang_2@nxp.com>
Date: Mon Apr 27 15:57:55 2026 +0800
usb: chipidea: core: convert ci_role_switch to local variable
When a system contains multiple USB controllers, the global ci_role_switch
variable may be overwritten by subsequent driver initialization code.
This can cause issues in the following cases:
- The 2nd ci_hdrc_probe() sees ci_role_switch.fwnode as non-NULL even
though the "usb-role-switch" property is not present for the controller.
- When the ci_hdrc device is unbound and bound again, ci_role_switch
fwnode will not be reassigned, and the old value will be used instead.
Convert ci_role_switch to a local variable to fix these issues.
Fixes: 05559f10ed ("usb: chipidea: add role switch class support")
Cc: stable <stable@kernel.org>
Acked-by: Peter Chen <peter.chen@kernel.org>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
Link: https://patch.msgid.link/20260427075755.3611217-1-xu.yang_2@nxp.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jared Kangas <jkangas@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-248519
commit dd0c03d685225cb8fc60c477417d1b9c3b05ba9d
Author: Xu Yang <xu.yang_2@nxp.com>
Date: Mon Apr 27 15:56:53 2026 +0800
usb: chipidea: udc: support dynamic gadget add/remove
An asynchronous vbus_event_work() keep running when switch the role from
device to host. This affects EHCI host controller initialization.
USBCMD.RUNSTOP bit is set at ehci_run() and cleared by following
vbus_event_work() if bus_event_work() run after ehci_run().
The log below shows what happens:
[ 87.819925] ci_hdrc ci_hdrc.0: EHCI Host Controller
[ 87.819963] ci_hdrc ci_hdrc.0: new USB bus registered, assigned bus number 1
[ 87.955634] ci_hdrc ci_hdrc.0: USB 2.0, controller refused to start: -110
[ 87.955658] ci_hdrc ci_hdrc.0: startup error -110
[ 87.955682] ci_hdrc ci_hdrc.0: USB bus 1 deregistered
The problem is that the chipidea UDC driver call usb_udc_vbus_handler() to
pull down data line but it don't wait for completion before host controller
starts running.
Now UDC core can properly delete usb gadget device and make sure that vbus
work is cancelled or completed after usb_del_gadget_udc() is returned. But
the udc.c only call usb_del_gadget_udc() in ci_hdrc_gadget_destroy(). To
avoid above issue, add/remove the gadget device dynamically during USB role
switching.
To support dynamic gadget add/remove, do below steps:
- clear ci->gadget and ci->ci_hw_ep at initialization.
- assign udc_[start|stop]() to rdrv->[start|stop] and properly merge the
operations in udc_id_switch_for_[device|host]() to udc_[start|stop]()
Adjust the order ci_handle_vbus_change() and ci_role_start() to avoid NULL
pointer reference since ci_hdrc_gadget_init() doesn't add gadget anymore.
Acked-by: Peter Chen <peter.chen@kernel.org>
Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
Link: https://patch.msgid.link/20260427075653.3611180-2-xu.yang_2@nxp.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jared Kangas <jkangas@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-248519
commit b94b631d9f78e653855f7fb58dbcb86c2a856f6f
Author: Xu Yang <xu.yang_2@nxp.com>
Date: Thu Apr 2 15:14:56 2026 +0800
usb: chipidea: core: allow ci_irq_handler() handle both ID and VBUS change
For USB role switch-triggered IRQ, ID and VBUS change come together, for
example when switching from host to device mode. ID indicate a role switch
and VBUS is required to determine whether the device controller can start
operating. Currently, ci_irq_handler() handles only a single event per
invocation. This can cause an issue where switching to device mode results
in the device controller not working at all. Allowing ci_irq_handler() to
handle both ID and VBUS change in one call resolves this issue.
Meanwhile, this change also affects the VBUS event handling logic.
Previously, if an ID event indicated host mode the VBUS IRQ will be
ignored as the device disable BSE when stop() is called. With the new
behavior, if ID and VBUS IRQ occur together and the target mode is host,
the VBUS event is queued and ci_handle_vbus_change() will call
usb_gadget_vbus_connect(), after which USBMODE is switched to device mode,
causing host mode to stop working. To prevent this, an additional check is
added to skip handling VBUS event when current role is not device mode.
Suggested-by: Peter Chen <peter.chen@kernel.org>
Fixes: e1b5d2bed6 ("usb: chipidea: core: handle usb role switch in a common way")
Cc: stable@vger.kernel.org
Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
Link: https://patch.msgid.link/20260402071457.2516021-2-xu.yang_2@nxp.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jared Kangas <jkangas@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-248519
commit e27c946b589c53520409a0956b33d52ef7a0898f
Author: Luke Wang <ziniu.wang_1@nxp.com>
Date: Wed Jul 15 15:18:18 2026 +0800
mmc: sdhci-esdhc-imx: fix resume error handling
Check pm_runtime_force_resume() return value in resume. If it fails
(clock enable failure), return immediately since accessing hardware
registers on an unclocked device would cause a kernel panic.
The early return intentionally skips enable_irq() and
sdhci_disable_irq_wakeups() because the IRQ handler reads
SDHCI_INT_STATUS, which would also fault without clocks. The PM runtime
usage counter leak only affects this already-broken device instance and
is an acceptable tradeoff to preserve system stability.
Remove the return value check for mmc_gpio_set_cd_wake(host->mmc, false)
since disable_irq_wake() called internally always returns 0.
Also return 0 explicitly on the success path instead of propagating
stale return values.
Fixes: 676a83855614 ("mmc: host: sdhci-esdhc-imx: refactor the system PM logic")
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Luke Wang <ziniu.wang_1@nxp.com>
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
Signed-off-by: Jared Kangas <jkangas@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-248519
commit 6aa00a43bbd3d994558a55586351757cebbff236
Author: Luke Wang <ziniu.wang_1@nxp.com>
Date: Wed Jul 15 15:18:17 2026 +0800
mmc: sdhci-esdhc-imx: make non-fatal errors non-blocking in suspend
Make pinctrl_pm_select_sleep_state() and mmc_gpio_set_cd_wake() failures
non-fatal in the suspend path. These failures only mean slightly higher
power consumption or missing CD wakeup capability, but should not block
system suspend.
Also change the function to always return 0 on the success path instead
of propagating non-fatal warning return values.
Fixes: 676a83855614 ("mmc: host: sdhci-esdhc-imx: refactor the system PM logic")
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Luke Wang <ziniu.wang_1@nxp.com>
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
Signed-off-by: Jared Kangas <jkangas@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-248519
commit 8da5930144712412d85e7f868693d96ec5c2018c
Author: Luke Wang <ziniu.wang_1@nxp.com>
Date: Wed Jul 15 15:18:16 2026 +0800
mmc: sdhci-esdhc-imx: use pm_runtime_resume_and_get() in suspend
Replace pm_runtime_get_sync() with pm_runtime_resume_and_get() to
simplify error handling. pm_runtime_resume_and_get() automatically
drops the usage counter on failure, avoiding the need for a separate
pm_runtime_put_noidle() call. If it fails, the device is unclocked and
accessing hardware registers would cause a kernel panic, so return the
error immediately.
Fixes: 676a83855614 ("mmc: host: sdhci-esdhc-imx: refactor the system PM logic")
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Luke Wang <ziniu.wang_1@nxp.com>
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
Signed-off-by: Jared Kangas <jkangas@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-248519
commit 9d87eaf985cef9581b6ed99b461b38e8cd666480
Author: Luke Wang <ziniu.wang_1@nxp.com>
Date: Wed Jul 15 15:18:15 2026 +0800
mmc: sdhci-esdhc-imx: disable irq during suspend to fix unhandled interrupt
When using WIFI out-of-band wakeup, an "irq xxx: nobody cared" warning
occurs. This happens because the usdhc interrupt is not disabled during
system suspend when device_may_wakeup() returns false.
The sequence of events leading to this issue:
1. System enters suspend without disabling usdhc interrupt
(because device_may_wakeup() returns false for usdhc device)
2. WIFI out-of-band wakeup triggers system resume via GPIO interrupt
3. WIFI sends a Card interrupt before usdhc has fully resumed
4. usdhc is still in runtime suspend state and cannot handle the
interrupt properly
5. The unhandled interrupt triggers "nobody cared" warning
Fix this by unconditionally disabling the usdhc interrupt during suspend
and re-enabling it during resume, regardless of the wakeup capability.
This ensures no interrupts are processed during the suspend/resume
transition.
Fixes: 676a83855614 ("mmc: host: sdhci-esdhc-imx: refactor the system PM logic")
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Haibo Chen <haibo.chen@nxp.com>
Signed-off-by: Luke Wang <ziniu.wang_1@nxp.com>
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
Signed-off-by: Jared Kangas <jkangas@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-248519
commit 1db87818bde3d2295613660879378b43a70d31f8
Author: Luke Wang <ziniu.wang_1@nxp.com>
Date: Wed Jul 15 15:18:14 2026 +0800
mmc: sdhci-esdhc-imx: restore pinctrl before restoring ios timing on resume
SDIO devices such as WiFi may keep power during suspend, so the MMC
core skips full card re-initialization on resume and directly restores
the host controller's ios timing to match the card. For DDR mode,
pm_runtime_force_resume() sets DDR_EN before the pin configuration is
restored from sleep state.
This is related to the SoC IP integration: switching pinctrl setting
(changing alt from GPIO to USDHC) impacts the internal loopback path.
If pinctrl configures the pad to GPIO function, once DDR_EN is set, the
DLL delay will be fixed based on the GPIO function loopback path. When
the pinctrl is later changed to USDHC function, the internal loopback
path changes, making the original fixed sample point no longer suitable
for the current loopback path. This causes persistent read CRC errors on
subsequent data transfers.
SD/eMMC running in DDR mode are unaffected as they are fully
re-initialized from legacy timing after resume.
Fix this by restoring the pinctrl state based on current timing mode
using esdhc_change_pinstate() before pm_runtime_force_resume(). This
ensures the correct pin configuration (e.g., 100/200MHz for UHS modes)
is applied before DDR_EN is set. Only restore for non-wakeup devices
since wakeup devices kept their active pin state during suspend.
Fixes: 676a83855614 ("mmc: host: sdhci-esdhc-imx: refactor the system PM logic")
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Haibo Chen <haibo.chen@nxp.com>
Signed-off-by: Luke Wang <ziniu.wang_1@nxp.com>
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
Signed-off-by: Jared Kangas <jkangas@redhat.com>
JIRA: https://redhat.atlassian.net/browse/RHEL-248519
commit 5adc14cd4b905629d5b9163b3a416dcab24c7ce2
Author: Luke Wang <ziniu.wang_1@nxp.com>
Date: Wed Jul 15 15:18:13 2026 +0800
mmc: sdhci-esdhc-imx: fix esdhc_change_pinstate() to allow default state restore
esdhc_change_pinstate() checks for pins_100mhz and pins_200mhz at the
top of the function and returns -EINVAL if either is not defined. This
prevents the default case from ever being reached, which means devices
with a sleep pinctrl state but without high-speed pin states (100mhz/
200mhz) can never restore their default pin configuration.
Move the IS_ERR checks for pins_100mhz and pins_200mhz into their
respective switch cases.
Fixes: 676a83855614 ("mmc: host: sdhci-esdhc-imx: refactor the system PM logic")
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Luke Wang <ziniu.wang_1@nxp.com>
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
Signed-off-by: Jared Kangas <jkangas@redhat.com>
CKI KWF Bot
Bruno Goncalves
Scott Weaver
CKI Backport Bot
Shivani Chandanshive
Mamatha Inamdar
Jan Polensky
Jared Kangas
Rafael Aquini
Oleksii Baranov