August 2025 - Linux-stable-mirror

[PATCH AUTOSEL 6.1 01/51] usb: xhci: print xhci->xhc_state when queue_command failed

by Sasha Levin

From: Su Hui <suhui(a)nfschina.com> [ Upstream commit 7919407eca2ef562fa6c98c41cfdf6f6cdd69d92 ] When encounters some errors like these: xhci_hcd 0000:4a:00.2: xHCI dying or halted, can't queue_command xhci_hcd 0000:4a:00.2: FIXME: allocate a command ring segment usb usb5-port6: couldn't allocate usb_device It's hard to know whether xhc_state is dying or halted. So it's better to print xhc_state's value which can help locate the resaon of the bug. Signed-off-by: Su Hui <suhui(a)nfschina.com> Link: https://lore.kernel.org/r/20250725060117.1773770-1-suhui@nfschina.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- LLM Generated explanations, may be completely bogus: **Backport Status: YES** This commit is suitable for backporting to stable kernel trees for the following reasons: 1. **Enhanced Debugging for Real-World Issues**: The commit improves debugging of USB xHCI host controller failures by printing the actual `xhc_state` value when `queue_command` fails. The commit message shows real error messages users encounter ("xHCI dying or halted, can't queue_command"), demonstrating this is a real-world debugging problem. 2. **Minimal and Safe Change**: The change is extremely small and safe - it only modifies a debug print statement from: ```c xhci_dbg(xhci, "xHCI dying or halted, can't queue_command\n"); ``` to: ```c xhci_dbg(xhci, "xHCI dying or halted, can't queue_command. state: 0x%x\n", xhci->xhc_state); ``` 3. **No Functional Changes**: This is a pure diagnostic improvement. It doesn't change any logic, control flow, or data structures. It only adds the state value (0x%x format) to an existing debug message. 4. **Important for Troubleshooting**: The xHCI driver is critical for USB functionality, and when it fails with "dying or halted" states, knowing the exact state helps diagnose whether: - `XHCI_STATE_DYING` (0x1) - controller is dying - `XHCI_STATE_HALTED` (0x2) - controller is halted - Both states (0x3) - controller has both flags set This distinction is valuable for debugging hardware issues, driver bugs, or system problems. 5. **Zero Risk of Regression**: Adding a parameter to a debug print statement has no risk of introducing regressions. The worst case is the debug message prints the state value. 6. **Follows Stable Rules**: This meets stable kernel criteria as it: - Fixes a real debugging limitation - Is obviously correct - Has been tested (signed-off and accepted by Greg KH) - Is small (single line change) - Doesn't add new features, just improves existing diagnostics The commit helps system administrators and developers diagnose USB issues more effectively by providing the actual state value rather than just saying "dying or halted", making it a valuable debugging enhancement for stable kernels. drivers/usb/host/xhci-ring.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c index 0862fdd3e568..c4880b22f359 100644 --- a/drivers/usb/host/xhci-ring.c +++ b/drivers/usb/host/xhci-ring.c @@ -4421,7 +4421,8 @@ static int queue_command(struct xhci_hcd *xhci, struct xhci_command *cmd, if ((xhci->xhc_state & XHCI_STATE_DYING) || (xhci->xhc_state & XHCI_STATE_HALTED)) { - xhci_dbg(xhci, "xHCI dying or halted, can't queue_command\n"); + xhci_dbg(xhci, "xHCI dying or halted, can't queue_command. state: 0x%x\n", + xhci->xhc_state); return -ESHUTDOWN; } -- 2.39.5

2 months, 2 weeks

3
53
0 0

[PATCH AUTOSEL 6.16-6.6] apparmor: shift ouid when mediating hard links in userns

by Sasha Levin

From: Gabriel Totev <gabriel.totev(a)zetier.com> [ Upstream commit c5bf96d20fd787e4909b755de4705d52f3458836 ] When using AppArmor profiles inside an unprivileged container, the link operation observes an unshifted ouid. (tested with LXD and Incus) For example, root inside container and uid 1000000 outside, with `owner /root/link l,` profile entry for ln: /root$ touch chain && ln chain link ==> dmesg apparmor="DENIED" operation="link" class="file" namespace="root//lxd-feet_<var-snap-lxd-common-lxd>" profile="linkit" name="/root/link" pid=1655 comm="ln" requested_mask="l" denied_mask="l" fsuid=1000000 ouid=0 [<== should be 1000000] target="/root/chain" Fix by mapping inode uid of old_dentry in aa_path_link() rather than using it directly, similarly to how it's mapped in __file_path_perm() later in the file. Signed-off-by: Gabriel Totev <gabriel.totev(a)zetier.com> Signed-off-by: John Johansen <john.johansen(a)canonical.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- LLM Generated explanations, may be completely bogus: **Backport Status: YES** This commit should be backported to stable kernel trees for the following reasons: 1. **Clear Bug Fix**: This fixes a real bug where AppArmor incorrectly reports the unshifted uid when mediating hard link operations inside user namespaces/containers. The commit message provides a concrete example showing ouid=0 instead of the expected ouid=1000000 in container logs. 2. **Security Impact**: This is a security-relevant bug that causes AppArmor policy enforcement to behave incorrectly in containerized environments. The owner-based AppArmor rules (like `owner /root/link l,`) won't work correctly because the uid comparison is done with the wrong (unshifted) value. 3. **Minimal and Contained Fix**: The change is small and surgical - it only modifies the aa_path_link() function to properly map the inode uid through the mount's idmapping, following the exact same pattern already used in __file_path_perm(): - Uses `i_uid_into_vfsuid(mnt_idmap(target.mnt), inode)` to get the vfsuid - Converts it back with `vfsuid_into_kuid(vfsuid)` for the path_cond structure 4. **No New Features or Architecture Changes**: This is purely a bug fix that makes aa_path_link() consistent with how __file_path_perm() already handles uid mapping. No new functionality is added. 5. **Container/User Namespace Compatibility**: With the widespread use of containers (LXD, Incus, Docker with userns), this bug affects many production systems. The fix ensures AppArmor policies work correctly in these environments. 6. **Low Risk**: The change follows an established pattern in the codebase (from __file_path_perm) and only affects the specific case of hard link permission checks in user namespaces. The risk of regression is minimal. 7. **Clear Testing**: The commit message indicates this was tested with LXD and Incus containers, showing the issue is reproducible and the fix validated. The code change is straightforward - replacing direct access to `d_backing_inode(old_dentry)->i_uid` with proper idmapping-aware conversion that respects user namespace uid shifts. This makes aa_path_link() consistent with other AppArmor file operations that already handle idmapped mounts correctly. security/apparmor/file.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/security/apparmor/file.c b/security/apparmor/file.c index d52a5b14dad4..62bc46e03758 100644 --- a/security/apparmor/file.c +++ b/security/apparmor/file.c @@ -423,9 +423,11 @@ int aa_path_link(const struct cred *subj_cred, { struct path link = { .mnt = new_dir->mnt, .dentry = new_dentry }; struct path target = { .mnt = new_dir->mnt, .dentry = old_dentry }; + struct inode *inode = d_backing_inode(old_dentry); + vfsuid_t vfsuid = i_uid_into_vfsuid(mnt_idmap(target.mnt), inode); struct path_cond cond = { - d_backing_inode(old_dentry)->i_uid, - d_backing_inode(old_dentry)->i_mode + .uid = vfsuid_into_kuid(vfsuid), + .mode = inode->i_mode, }; char *buffer = NULL, *buffer2 = NULL; struct aa_profile *profile; -- 2.39.5

2 months, 2 weeks

3
17
0 0

[PATCH] soc: qcom: icc-bwmon: Fix handling dev_pm_opp_find_bw_*() errors

by Krzysztof Kozlowski

The ISR calls dev_pm_opp_find_bw_ceil(), which can return EINVAL, ERANGE or ENODEV, and if that one fails with ERANGE, then it tries again with floor dev_pm_opp_find_bw_floor(). Code misses error checks for two cases: 1. First dev_pm_opp_find_bw_ceil() failed with error different than ERANGE, 2. Any error from second dev_pm_opp_find_bw_floor(). In an unlikely case these error happened, the code would further dereference the ERR pointer. Close that possibility and make the code more obvious that all errors are correctly handled. Reported by Smatch: icc-bwmon.c:693 bwmon_intr_thread() error: 'target_opp' dereferencing possible ERR_PTR() Fixes: b9c2ae6cac40 ("soc: qcom: icc-bwmon: Add bandwidth monitoring driver") Cc: <stable(a)vger.kernel.org> Reported-by: Dan Carpenter <dan.carpenter(a)linaro.org> Closes: https://lore.kernel.org/r/aJTNEQsRFjrFknG9@stanley.mountain/ Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> --- Some unreleased smatch, though, because I cannot reproduce the warning, but I imagine Dan keeps the tastiests reports for later. :) --- drivers/soc/qcom/icc-bwmon.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/soc/qcom/icc-bwmon.c b/drivers/soc/qcom/icc-bwmon.c index 3dfa448bf8cf..597f9025e422 100644 --- a/drivers/soc/qcom/icc-bwmon.c +++ b/drivers/soc/qcom/icc-bwmon.c @@ -656,6 +656,9 @@ static irqreturn_t bwmon_intr_thread(int irq, void *dev_id) if (IS_ERR(target_opp) && PTR_ERR(target_opp) == -ERANGE) target_opp = dev_pm_opp_find_bw_floor(bwmon->dev, &bw_kbps, 0); + if (IS_ERR(target_opp)) + return IRQ_HANDLED; + bwmon->target_kbps = bw_kbps; bw_kbps--; -- 2.48.1

2 months, 2 weeks

3
5
0 0

[PATCH 6.1.y] tls: separate no-async decryption request handling from async

by William Liu

From: Sabrina Dubroca <sd(a)queasysnail.net> [ Upstream commit 41532b785e9d79636b3815a64ddf6a096647d011 ] If we're not doing async, the handling is much simpler. There's no reference counting, we just need to wait for the completion to wake us up and return its result. We should preferably also use a separate crypto_wait. I'm not seeing a UAF as I did in the past, I think aec7961 ("tls: fix race between async notify and socket close") took care of it. This will make the next fix easier. Signed-off-by: Sabrina Dubroca <sd(a)queasysnail.net> Link: https://lore.kernel.org/r/47bde5f649707610eaef9f0d679519966fc31061.17091326… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> [ William: The original patch did not apply cleanly due to deletions of non-existent lines in 6.1.y. The UAF the author stopped seeing can still be reproduced on systems without AVX in conjunction with cryptd. Also removed an extraneous statement after a return statement that is adjacent to diff. ] Link: https://lore.kernel.org/netdev/he2K1yz_u7bZ-CnYcTSQ4OxuLuHZXN6xZRgp6_ICSWnq… Signed-off-by: William Liu <will(a)willsroot.io> --- Tested with original repro and all tests in selftests/net/tls.c --- net/tls/tls_sw.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c index 6ac3dcbe87b5..e1e3207168e3 100644 --- a/net/tls/tls_sw.c +++ b/net/tls/tls_sw.c @@ -274,9 +274,15 @@ static int tls_do_decryption(struct sock *sk, DEBUG_NET_WARN_ON_ONCE(atomic_read(&ctx->decrypt_pending) < 1); atomic_inc(&ctx->decrypt_pending); } else { + DECLARE_CRYPTO_WAIT(wait); + aead_request_set_callback(aead_req, CRYPTO_TFM_REQ_MAY_BACKLOG, - crypto_req_done, &ctx->async_wait); + crypto_req_done, &wait); + ret = crypto_aead_decrypt(aead_req); + if (ret == -EINPROGRESS || ret == -EBUSY) + ret = crypto_wait_req(ret, &wait); + return ret; } ret = crypto_aead_decrypt(aead_req); @@ -289,7 +295,6 @@ static int tls_do_decryption(struct sock *sk, /* all completions have run, we're not doing async anymore */ darg->async = false; return ret; - ret = ret ?: -EINPROGRESS; } atomic_dec(&ctx->decrypt_pending); -- 2.43.0

2 months, 2 weeks

1
0
0 0

[PATCH 6.12] mfd: cros_ec: Separate charge-control probing from USB-PD

by linux＠weissschuh.net

From: Thomas Weißschuh <linux(a)weissschuh.net> [ Upstream commit e40fc1160d491c3bcaf8e940ae0dde0a7c5e8e14 ] The charge-control subsystem in the ChromeOS EC is not strictly tied to its USB-PD subsystem. Since commit 7613bc0d116a ("mfd: cros_ec: Don't load charger with UCSI") the presence of EC_FEATURE_UCSI_PPM would inhibit the probing of the charge-control driver. Furthermore recent versions of the EC firmware in Framework laptops hard-disable EC_FEATURE_USB_PD to avoid probing cros-usbpd-charger, which then also breaks cros-charge-control. Instead use the dedicated EC_FEATURE_CHARGER. Cc: stable(a)vger.kernel.org Link: https://github.com/FrameworkComputer/EmbeddedController/commit/1d7bcf1d5013… Fixes: 555b5fcdb844 ("mfd: cros_ec: Register charge control subdevice") Signed-off-by: Thomas Weißschuh <linux(a)weissschuh.net> Reviewed-by: Tzung-Bi Shih <tzungbi(a)kernel.org> Tested-by: Tom Vincent <linux(a)tlvince.com> Link: https://lore.kernel.org/r/20250521-cros-ec-mfd-chctl-probe-v1-1-6ebfe3a6efa… Signed-off-by: Lee Jones <lee(a)kernel.org> --- drivers/mfd/cros_ec_dev.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/mfd/cros_ec_dev.c b/drivers/mfd/cros_ec_dev.c index f3dc812b359f..78c48dc624e8 100644 --- a/drivers/mfd/cros_ec_dev.c +++ b/drivers/mfd/cros_ec_dev.c @@ -87,7 +87,6 @@ static const struct mfd_cell cros_ec_sensorhub_cells[] = { }; static const struct mfd_cell cros_usbpd_charger_cells[] = { - { .name = "cros-charge-control", }, { .name = "cros-usbpd-charger", }, { .name = "cros-usbpd-logger", }, }; @@ -108,6 +107,10 @@ static const struct mfd_cell cros_ec_keyboard_leds_cells[] = { { .name = "cros-keyboard-leds", }, }; +static const struct mfd_cell cros_ec_charge_control_cells[] = { + { .name = "cros-charge-control", }, +}; + static const struct cros_feature_to_cells cros_subdevices[] = { { .id = EC_FEATURE_CEC, @@ -144,6 +147,11 @@ static const struct cros_feature_to_cells cros_subdevices[] = { .mfd_cells = cros_ec_keyboard_leds_cells, .num_cells = ARRAY_SIZE(cros_ec_keyboard_leds_cells), }, + { + .id = EC_FEATURE_CHARGER, + .mfd_cells = cros_ec_charge_control_cells, + .num_cells = ARRAY_SIZE(cros_ec_charge_control_cells), + }, }; static const struct mfd_cell cros_ec_platform_cells[] = { -- 2.50.1

2 months, 2 weeks

1
0
0 0

+ mm-memory-failure-fix-infinite-uce-for-vm_pfnmap-pfn.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm/memory-failure: fix infinite UCE for VM_PFNMAP pfn has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-memory-failure-fix-infinite-uce-for-vm_pfnmap-pfn.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Jinjiang Tu <tujinjiang(a)huawei.com> Subject: mm/memory-failure: fix infinite UCE for VM_PFNMAP pfn Date: Fri, 15 Aug 2025 15:32:09 +0800 When memory_failure() is called for a already hwpoisoned pfn, kill_accessing_process() will be called to kill current task. However, if the vma of the accessing vaddr is VM_PFNMAP, walk_page_range() will skip the vma in walk_page_test() and return 0. Before commit aaf99ac2ceb7 ("mm/hwpoison: do not send SIGBUS to processes with recovered clean pages"), kill_accessing_process() will return EFAULT. For x86, the current task will be killed in kill_me_maybe(). However, after this commit, kill_accessing_process() simplies return 0, that means UCE is handled properly, but it doesn't actually. In such case, the user task will trigger UCE infinitely. To fix it, add .test_walk callback for hwpoison_walk_ops to scan all vmas. Link: https://lkml.kernel.org/r/20250815073209.1984582-1-tujinjiang@huawei.com Fixes: aaf99ac2ceb7 ("mm/hwpoison: do not send SIGBUS to processes with recovered clean pages") Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> Acked-by: David Hildenbrand <david(a)redhat.com> Acked-by: Miaohe Lin <linmiaohe(a)huawei.com> Reviewed-by: Jane Chu <jane.chu(a)oracle.com> Cc: Kefeng Wang <wangkefeng.wang(a)huawei.com> Cc: Naoya Horiguchi <nao.horiguchi(a)gmail.com> Cc: Oscar Salvador <osalvador(a)suse.de> Cc: Shuai Xue <xueshuai(a)linux.alibaba.com> Cc: Zi Yan <ziy(a)nvidia.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/memory-failure.c | 8 ++++++++ 1 file changed, 8 insertions(+) --- a/mm/memory-failure.c~mm-memory-failure-fix-infinite-uce-for-vm_pfnmap-pfn +++ a/mm/memory-failure.c @@ -853,9 +853,17 @@ static int hwpoison_hugetlb_range(pte_t #define hwpoison_hugetlb_range NULL #endif +static int hwpoison_test_walk(unsigned long start, unsigned long end, + struct mm_walk *walk) +{ + /* We also want to consider pages mapped into VM_PFNMAP. */ + return 0; +} + static const struct mm_walk_ops hwpoison_walk_ops = { .pmd_entry = hwpoison_pte_range, .hugetlb_entry = hwpoison_hugetlb_range, + .test_walk = hwpoison_test_walk, .walk_lock = PGWALK_RDLOCK, }; _ Patches currently in -mm which might be from tujinjiang(a)huawei.com are mm-memory-failure-fix-infinite-uce-for-vm_pfnmap-pfn.patch mm-memory_hotplug-fix-hwpoisoned-large-folio-handling-in-do_migrate_range.patch

2 months, 2 weeks

1
0
0 0

+ init-handle-bootloader-identifier-in-kernel-parameters-v4.patch added to mm-nonmm-unstable branch

by Andrew Morton

The patch titled Subject: init-handle-bootloader-identifier-in-kernel-parameters-v4 has been added to the -mm mm-nonmm-unstable branch. Its filename is init-handle-bootloader-identifier-in-kernel-parameters-v4.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-nonmm-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Huacai Chen <chenhuacai(a)loongson.cn> Subject: init-handle-bootloader-identifier-in-kernel-parameters-v4 Date: Fri, 15 Aug 2025 17:01:20 +0800 use strstarts() Link: https://lkml.kernel.org/r/20250815090120.1569947-1-chenhuacai@loongson.cn Signed-off-by: Huacai Chen <chenhuacai(a)loongson.cn> Cc: Al Viro <viro(a)zeniv.linux.org.uk> Cc: Christian Brauner <brauner(a)kernel.org> Cc: Jan Kara <jack(a)suse.cz> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- init/main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/init/main.c~init-handle-bootloader-identifier-in-kernel-parameters-v4 +++ a/init/main.c @@ -559,7 +559,7 @@ static int __init unknown_bootoption(cha /* Handle bootloader identifier */ for (int i = 0; bootloader[i]; i++) { - if (!strncmp(param, bootloader[i], strlen(bootloader[i]))) + if (strstarts(param, bootloader[i])) return 0; } _ Patches currently in -mm which might be from chenhuacai(a)loongson.cn are init-handle-bootloader-identifier-in-kernel-parameters.patch init-handle-bootloader-identifier-in-kernel-parameters-v4.patch

2 months, 2 weeks

1
0
0 0

[PATCH v5 RESEND] x86/cpu/intel: Fix the constant_tsc model check for Pentium 4

by Suchit Karunakaran

Pentium 4's which are INTEL_P4_PRESCOTT (model 0x03) and later have a constant TSC. This was correctly captured until commit fadb6f569b10 ("x86/cpu/intel: Limit the non-architectural constant_tsc model checks"). In that commit, an error was introduced while selecting the last P4 model (0x06) as the upper bound. Model 0x06 was transposed to INTEL_P4_WILLAMETTE, which is just plain wrong. That was presumably a simple typo, probably just copying and pasting the wrong P4 model. Fix the constant TSC logic to cover all later P4 models. End at INTEL_P4_CEDARMILL which accurately corresponds to the last P4 model. Fixes: fadb6f569b10 ("x86/cpu/intel: Limit the non-architectural constant_tsc model checks") Cc: <stable(a)vger.kernel.org> # v6.15 Reviewed-by: Sohil Mehta <sohil.mehta(a)intel.com> Signed-off-by: Suchit Karunakaran <suchitkarunakaran(a)gmail.com> --- Changes since v4: - Updated the patch based on review suggestions Changes since v3: - Refined changelog Changes since v2: - Improved commit message Changes since v1: - Fixed incorrect logic arch/x86/kernel/cpu/intel.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c index 076eaa41b8c8..98ae4c37c93e 100644 --- a/arch/x86/kernel/cpu/intel.c +++ b/arch/x86/kernel/cpu/intel.c @@ -262,7 +262,7 @@ static void early_init_intel(struct cpuinfo_x86 *c) if (c->x86_power & (1 << 8)) { set_cpu_cap(c, X86_FEATURE_CONSTANT_TSC); set_cpu_cap(c, X86_FEATURE_NONSTOP_TSC); - } else if ((c->x86_vfm >= INTEL_P4_PRESCOTT && c->x86_vfm <= INTEL_P4_WILLAMETTE) || + } else if ((c->x86_vfm >= INTEL_P4_PRESCOTT && c->x86_vfm <= INTEL_P4_CEDARMILL) || (c->x86_vfm >= INTEL_CORE_YONAH && c->x86_vfm <= INTEL_IVYBRIDGE)) { set_cpu_cap(c, X86_FEATURE_CONSTANT_TSC); } -- 2.50.1

2 months, 2 weeks

1
0
0 0

[BACKPORT REQUEST] mfd: cros_ec: Separate charge-control probing from USB-PD

by Thomas Weißschuh

Dear stable team, I'd like to have the following commit backported to v6.16 and v6.15: e40fc1160d49 ("mfd: cros_ec: Separate charge-control probing from USB-PD") It fixes probing issues for the cros-charge-control driver, for details see the commit message. As far as I can see, the commit also was marked for -stable backporting from the beginning. Somehow this doesn't seem to have worked. Thanks for your consideration, Thomas

2 months, 3 weeks

2
1
0 0

FAILED: patch "[PATCH] PCI/ACPI: Fix runtime PM ref imbalance on Hot-Plug Capable" failed to apply to 6.6-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.6-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.6.y git checkout FETCH_HEAD git cherry-pick -x 6cff20ce3b92ffbf2fc5eb9e5a030b3672aa414a # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025081509-uncrown-janitor-adad@gregkh' --subject-prefix 'PATCH 6.6.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 6cff20ce3b92ffbf2fc5eb9e5a030b3672aa414a Mon Sep 17 00:00:00 2001 From: Lukas Wunner <lukas(a)wunner.de> Date: Sun, 13 Jul 2025 16:31:01 +0200 Subject: [PATCH] PCI/ACPI: Fix runtime PM ref imbalance on Hot-Plug Capable ports pci_bridge_d3_possible() is called from both pcie_portdrv_probe() and pcie_portdrv_remove() to determine whether runtime power management shall be enabled (on probe) or disabled (on remove) on a PCIe port. The underlying assumption is that pci_bridge_d3_possible() always returns the same value, else a runtime PM reference imbalance would occur. That assumption is not given if the PCIe port is inaccessible on remove due to hot-unplug: pci_bridge_d3_possible() calls pciehp_is_native(), which accesses Config Space to determine whether the port is Hot-Plug Capable. An inaccessible port returns "all ones", which is converted to "all zeroes" by pcie_capability_read_dword(). Hence the port no longer seems Hot-Plug Capable on remove even though it was on probe. The resulting runtime PM ref imbalance causes warning messages such as: pcieport 0000:02:04.0: Runtime PM usage count underflow! Avoid the Config Space access (and thus the runtime PM ref imbalance) by caching the Hot-Plug Capable bit in struct pci_dev. The struct already contains an "is_hotplug_bridge" flag, which however is not only set on Hot-Plug Capable PCIe ports, but also Conventional PCI Hot-Plug bridges and ACPI slots. The flag identifies bridges which are allocated additional MMIO and bus number resources to allow for hierarchy expansion. The kernel is somewhat sloppily using "is_hotplug_bridge" in a number of places to identify Hot-Plug Capable PCIe ports, even though the flag encompasses other devices. Subsequent commits replace these occurrences with the new flag to clearly delineate Hot-Plug Capable PCIe ports from other kinds of hotplug bridges. Document the existing "is_hotplug_bridge" and the new "is_pciehp" flag and document the (non-obvious) requirement that pci_bridge_d3_possible() always returns the same value across the entire lifetime of a bridge, including its hot-removal. Fixes: 5352a44a561d ("PCI: pciehp: Make pciehp_is_native() stricter") Reported-by: Laurent Bigonville <bigon(a)bigon.be> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220216 Reported-by: Mario Limonciello <mario.limonciello(a)amd.com> Closes: https://lore.kernel.org/r/20250609020223.269407-3-superm1@kernel.org/ Link: https://lore.kernel.org/all/20250620025535.3425049-3-superm1@kernel.org/T/#u Signed-off-by: Lukas Wunner <lukas(a)wunner.de> Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com> Acked-by: Rafael J. Wysocki <rafael(a)kernel.org> Cc: stable(a)vger.kernel.org # v4.18+ Link: https://patch.msgid.link/fe5dcc3b2e62ee1df7905d746bde161eb1b3291c.175239010… diff --git a/drivers/pci/pci-acpi.c b/drivers/pci/pci-acpi.c index b78e0e417324..efe478e5073e 100644 --- a/drivers/pci/pci-acpi.c +++ b/drivers/pci/pci-acpi.c @@ -816,13 +816,11 @@ int pci_acpi_program_hp_params(struct pci_dev *dev) bool pciehp_is_native(struct pci_dev *bridge) { const struct pci_host_bridge *host; - u32 slot_cap; if (!IS_ENABLED(CONFIG_HOTPLUG_PCI_PCIE)) return false; - pcie_capability_read_dword(bridge, PCI_EXP_SLTCAP, &slot_cap); - if (!(slot_cap & PCI_EXP_SLTCAP_HPC)) + if (!bridge->is_pciehp) return false; if (pcie_ports_native) diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index e9448d55113b..23d8fe98ddf9 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -3030,8 +3030,12 @@ static const struct dmi_system_id bridge_d3_blacklist[] = { * pci_bridge_d3_possible - Is it possible to put the bridge into D3 * @bridge: Bridge to check * - * This function checks if it is possible to move the bridge to D3. * Currently we only allow D3 for some PCIe ports and for Thunderbolt. + * + * Return: Whether it is possible to move the bridge to D3. + * + * The return value is guaranteed to be constant across the entire lifetime + * of the bridge, including its hot-removal. */ bool pci_bridge_d3_possible(struct pci_dev *bridge) { diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index 4b8693ec9e4c..cf50be63bf5f 100644 --- a/drivers/pci/probe.c +++ b/drivers/pci/probe.c @@ -1678,7 +1678,7 @@ void set_pcie_hotplug_bridge(struct pci_dev *pdev) pcie_capability_read_dword(pdev, PCI_EXP_SLTCAP, &reg32); if (reg32 & PCI_EXP_SLTCAP_HPC) - pdev->is_hotplug_bridge = 1; + pdev->is_hotplug_bridge = pdev->is_pciehp = 1; } static void set_pcie_thunderbolt(struct pci_dev *dev) diff --git a/include/linux/pci.h b/include/linux/pci.h index 05e68f35f392..d56d0dd80afb 100644 --- a/include/linux/pci.h +++ b/include/linux/pci.h @@ -328,6 +328,11 @@ struct rcec_ea; * determined (e.g., for Root Complex Integrated * Endpoints without the relevant Capability * Registers). + * @is_hotplug_bridge: Hotplug bridge of any kind (e.g. PCIe Hot-Plug Capable, + * Conventional PCI Hot-Plug, ACPI slot). + * Such bridges are allocated additional MMIO and bus + * number resources to allow for hierarchy expansion. + * @is_pciehp: PCIe Hot-Plug Capable bridge. */ struct pci_dev { struct list_head bus_list; /* Node in per-bus list */ @@ -451,6 +456,7 @@ struct pci_dev { unsigned int is_physfn:1; unsigned int is_virtfn:1; unsigned int is_hotplug_bridge:1; + unsigned int is_pciehp:1; unsigned int shpc_managed:1; /* SHPC owned by shpchp */ unsigned int is_thunderbolt:1; /* Thunderbolt controller */ /*

2 months, 3 weeks

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror August 2025