April 2025 - Linux-stable-mirror

by Greg Kroah-Hartman

I'm announcing the release of the 6.1.133 kernel. All users of the 6.1 kernel series must upgrade. The updated 6.1.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-6.1.y and can be browsed at the normal kernel.org git web browser: https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h ------------ Makefile | 2 arch/arm/boot/dts/imx6qdl-apalis.dtsi | 10 - arch/arm/mm/fault.c | 8 drivers/counter/microchip-tcb-capture.c | 19 ++ drivers/counter/stm32-lptimer-cnt.c | 24 +- drivers/gpu/drm/amd/display/dc/dcn315/dcn315_resource.c | 2 drivers/hid/hid-plantronics.c | 144 +++++++--------- drivers/media/i2c/et8ek8/et8ek8_driver.c | 4 drivers/memstick/host/rtsx_usb_ms.c | 1 drivers/net/usb/qmi_wwan.c | 2 drivers/net/usb/usbnet.c | 21 +- drivers/tty/serial/8250/8250_dma.c | 2 drivers/tty/serial/8250/8250_pci.c | 46 +++++ drivers/usb/gadget/function/uvc_v4l2.c | 12 + drivers/usb/typec/ucsi/ucsi.c | 13 - net/atm/mpc.c | 2 net/ipv6/netfilter/nf_socket_ipv6.c | 23 ++ sound/pci/hda/patch_realtek.c | 1 sound/usb/mixer_quirks.c | 51 +++++ 19 files changed, 278 insertions(+), 109 deletions(-) Abhishek Tamboli (1): usb: gadget: uvc: Fix ERR_PTR dereference in uvc_v4l2.c Alex Hung (1): drm/amd/display: Check denominator crb_pipes before used Andrei Kuchynski (1): usb: typec: ucsi: Fix NULL pointer access Cameron Williams (2): tty: serial: 8250: Add some more device IDs tty: serial: 8250: Add Brainboxes XC devices Dhruv Deshpande (1): ALSA: hda/realtek: Support mute LED on HP Laptop 15s-du3xxx Dominique Martinet (1): net: usb: usbnet: restore usb%d name exception for local mac addresses Fabio Porcedda (2): net: usb: qmi_wwan: add Telit Cinterion FN990B composition net: usb: qmi_wwan: add Telit Cinterion FE990B composition Fabrice Gasnier (1): counter: stm32-lptimer-cnt: fix error handling when enabling Greg Kroah-Hartman (1): Linux 6.1.133 John Keeping (1): serial: 8250_dma: terminate correct DMA in tx_dma_flush() Kees Cook (2): ARM: 9350/1: fault: Implement copy_from_kernel_nofault_allowed() ARM: 9351/1: fault: Add "cut here" line for prefetch aborts Luo Qiu (1): memstick: rtsx_usb_ms: Fix slab-use-after-free in rtsx_usb_ms_drv_remove Maxim Mikityanskiy (1): netfilter: socket: Lookup orig tuple for IPv6 SNAT Minjoong Kim (1): atm: Fix NULL pointer dereference Stefan Eichenberger (1): ARM: dts: imx6qdl-apalis: Fix poweroff on Apalis iMX6 Terry Junge (2): ALSA: usb-audio: Add quirk for Plantronics headsets to fix control names HID: hid-plantronics: Add mic mute mapping and generalize quirks Uwe Kleine-König (1): media: i2c: et8ek8: Don't strip remove function when driver is builtin William Breathitt Gray (1): counter: microchip-tcb-capture: Fix undefined counter channel state on probe Yanjun Yang (1): ARM: Remove address checking for MMUless devices

7 months, 3 weeks

2
2
0 0

[PATCH v4 1/2] HID: amd_sfh: Fix SRA sensor when it's the only sensor

by Mario Limonciello

From: Mario Limonciello <mario.limonciello(a)amd.com> On systems that only have an SRA sensor connected to SFH the sensor doesn't get enabled due to a bad optimization condition of breaking the sensor walk loop. This optimization is unnecessary in the first place because if there is only one device then the loop only runs once. Drop the condition and explicitly mark sensor as enabled. Reported-by: Yijun Shen <Yijun.Shen(a)dell.com> Tested-By: Yijun Shen <Yijun_Shen(a)Dell.com> Fixes: d1c444b47100d ("HID: amd_sfh: Add support to export device operating states") Cc: stable(a)vger.kernel.org Signed-off-by: Mario Limonciello <mario.limonciello(a)amd.com> --- v2: * Add tag --- drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_init.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_init.c b/drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_init.c index 25f0ebfcbd5f5..c1bdf1e0d44af 100644 --- a/drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_init.c +++ b/drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_init.c @@ -134,9 +134,6 @@ static int amd_sfh1_1_hid_client_init(struct amd_mp2_dev *privdata) for (i = 0; i < cl_data->num_hid_devices; i++) { cl_data->sensor_sts[i] = SENSOR_DISABLED; - if (cl_data->num_hid_devices == 1 && cl_data->sensor_idx[0] == SRA_IDX) - break; - if (cl_data->sensor_idx[i] == SRA_IDX) { info.sensor_idx = cl_data->sensor_idx[i]; writel(0, privdata->mmio + amd_get_p2c_val(privdata, 0)); @@ -145,8 +142,10 @@ static int amd_sfh1_1_hid_client_init(struct amd_mp2_dev *privdata) (privdata, cl_data->sensor_idx[i], ENABLE_SENSOR); cl_data->sensor_sts[i] = (status == 0) ? SENSOR_ENABLED : SENSOR_DISABLED; - if (cl_data->sensor_sts[i] == SENSOR_ENABLED) + if (cl_data->sensor_sts[i] == SENSOR_ENABLED) { + cl_data->is_any_sensor_enabled = true; privdata->dev_en.is_sra_present = true; + } continue; } -- 2.43.0

7 months, 3 weeks

1
0
0 0

[PATCH] e1000e: Add error handling for e1e_rphy_locked()

by Wentao Liang

The e1000_suspend_workarounds_ich8lan() calls e1e_rphy_locked to disable the SMB release, but does not check its return value. A proper implementation can be found in e1000_resume_workarounds_pchlan() from /source/drivers/net/ethernet/intel/e1000e/ich8lan.c. Add an error check for e1e_rphy_locked(). Log the error message and jump to 'release' label if the e1e_rphy_locked() fails. Fixes: 2fbe4526e5aa ("e1000e: initial support for i217") Cc: stable(a)vger.kernel.org # v3.5+ Signed-off-by: Wentao Liang <vulab(a)iscas.ac.cn> --- drivers/net/ethernet/intel/e1000e/ich8lan.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/intel/e1000e/ich8lan.c b/drivers/net/ethernet/intel/e1000e/ich8lan.c index 2f9655cf5dd9..d16e3aa50809 100644 --- a/drivers/net/ethernet/intel/e1000e/ich8lan.c +++ b/drivers/net/ethernet/intel/e1000e/ich8lan.c @@ -5497,7 +5497,11 @@ void e1000_suspend_workarounds_ich8lan(struct e1000_hw *hw) e1e_wphy_locked(hw, I217_SxCTRL, phy_reg); /* Disable the SMB release on LCD reset. */ - e1e_rphy_locked(hw, I217_MEMPWR, &phy_reg); + ret_val = e1e_rphy_locked(hw, I217_MEMPWR, &phy_reg); + if (ret_val) { + e_dbg("Fail to Disable the SMB release on LCD reset."); + goto release; + } phy_reg &= ~I217_MEMPWR_DISABLE_SMB_RELEASE; e1e_wphy_locked(hw, I217_MEMPWR, phy_reg); } -- 2.42.0.windows.2

7 months, 3 weeks

2
1
0 0

[PATCH 1/2] drm/xe/dma_buf: stop relying on placement in unmap

by Matthew Auld

The is_vram() is checking the current placement, however if we consider exported VRAM with dynamic dma-buf, it looks possible for the xe driver to async evict the memory, notifying the importer, however importer does not have to call unmap_attachment() immediately, but rather just as "soon as possible", like when the dma-resv idles. Following from this we would then pipeline the move, attaching the fence to the manager, and then update the current placement. But when the unmap_attachment() runs at some later point we might see that is_vram() is now false, and take the complete wrong path when dma-unmapping the sg, leading to explosions. To fix this check if the sgl was mapping a struct page. v2: - The attachment can be mapped multiple times it seems, so we can't really rely on encoding something in the attachment->priv. Instead see if the page_link has an encoded struct page. For vram we expect this to be NULL. Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/4563 Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Signed-off-by: Matthew Auld <matthew.auld(a)intel.com> Cc: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> Cc: Matthew Brost <matthew.brost(a)intel.com> Cc: <stable(a)vger.kernel.org> # v6.8+ --- drivers/gpu/drm/xe/xe_dma_buf.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/gpu/drm/xe/xe_dma_buf.c b/drivers/gpu/drm/xe/xe_dma_buf.c index f67803e15a0e..f7a20264ea33 100644 --- a/drivers/gpu/drm/xe/xe_dma_buf.c +++ b/drivers/gpu/drm/xe/xe_dma_buf.c @@ -145,10 +145,7 @@ static void xe_dma_buf_unmap(struct dma_buf_attachment *attach, struct sg_table *sgt, enum dma_data_direction dir) { - struct dma_buf *dma_buf = attach->dmabuf; - struct xe_bo *bo = gem_to_xe_bo(dma_buf->priv); - - if (!xe_bo_is_vram(bo)) { + if (sg_page(sgt->sgl)) { dma_unmap_sgtable(attach->dev, sgt, dir, 0); sg_free_table(sgt); kfree(sgt); -- 2.49.0

7 months, 3 weeks

4
6
0 0

Improving Linux Commit Backporting

by Manthey, Norbert

Dear Linux Stable Maintainers, while maintaining downstream Linux releases, we noticed that we have to backport some patches manually, because they are not picked up by your automated backporting. Some of these backports can be done with improved cherry-pick tooling. We have implemented a script/tool "git- fuzzy-pick" which we would like to share. Besides picking more commits, the tool also supports executing a validation script right after picking, e.g. compiling the modified source file. Picking stats and details are presented below. We would like to discuss whether you can integrate this improved tool into into your daily workflows. We already found the stable-tools repository [1] with some scripts that help automate backporting. To contribute git-fuzzy-pick there, we would need you to declare a license for the current state of this repository. To test backporting performance, we tried to backport stable-candidate patches from 6.12 to 6.1. Specifically, on tag 6.1.125 we executed the command stable show-missing-stable v6.12.12..v6.12.17 to collect patches considered for backporting. This results in 431 backport candidates. When using git-fuzzy-pick, we can pick 9 patches more than with default cherry-picking. All modifications have been validated by attempting to build the object files of the modified C source files with make using the kernels “allyesconfig” configuration. 196 Cherry-picked with --strategy=recursive --Xpatience -x 1 Applied with patch -p1 ... --fuzz=1 8 Applied with patch -p1 ... --fuzz=2 Please let us know how to best share the tool with you! Long term, we would like to integrate it into your backporting workflow, so that more kernel commits can be applied automatically. Best, Norbert [1] https://kernel.googlesource.com/pub/scm/linux/kernel/git/sashal/stable-tool…

7 months, 3 weeks

4
7
0 0

[REGRESSION] Chrome and VSCode breakage with the commit b9b588f22a0c

by Takashi Iwai

[ resent due to a wrong address for regression reporting, sorry! ] Hi, we received a bug report showing the regression on 6.13.1 kernel against 6.13.0. The symptom is that Chrome and VSCode stopped working with Gnome Scaling, as reported on openSUSE Tumbleweed bug tracker https://bugzilla.suse.com/show_bug.cgi?id=1236943 Quoting from there: """ I use the latest TW on Gnome with a 4K display and 150% scaling. Everything has been working fine, but recently both Chrome and VSCode (installed from official non-openSUSE channels) stopped working with Scaling. .... I am using VSCode with: `--enable-features=UseOzonePlatform --enable-features=WaylandWindowDecorations --ozone-platform-hint=auto` and for Chrome, I select `Preferred Ozone platform` == `Wayland`. """ Surprisingly, the bisection pointed to the backport of the commit b9b588f22a0c049a14885399e27625635ae6ef91 ("libfs: Use d_children list to iterate simple_offset directories"). Indeed, the revert of this patch on the latest 6.13.4 was confirmed to fix the issue. Also, the reporter verified that the latest 6.14-rc release is still affected, too. For now I have no concrete idea how the patch could break the behavior of a graphical application like the above. Let us know if you need something for debugging. (Or at easiest, join to the bugzilla entry and ask there; or open another bug report at whatever you like.) BTW, I'll be traveling tomorrow, so my reply will be delayed. thanks, Takashi #regzbot introduced: b9b588f22a0c049a14885399e27625635ae6ef91 #regzbot monitor: https://bugzilla.suse.com/show_bug.cgi?id=1236943

7 months, 3 weeks

6
29
0 0

6.1-stable fix

by Jens Axboe

Hi, Ran into an issue testing 6.1, which I discovered was introduced by a backport that was done. Here's the fix for it, please add it to the 6.1-stable mix. Thanks! -- Jens Axboe

7 months, 3 weeks

2
3
0 0

[PATCH 1/2] drm/simpledrm: Do not upcast in release helpers

by Thomas Zimmermann

The res pointer passed to simpledrm_device_release_clocks() and simpledrm_device_release_regulators() points to an instance of struct simpledrm_device. No need to upcast from struct drm_device. The upcast is harmless, as DRM device is the first field in struct simpledrm_device. Signed-off-by: Thomas Zimmermann <tzimmermann(a)suse.de> Fixes: 11e8f5fd223b ("drm: Add simpledrm driver") Cc: <stable(a)vger.kernel.org> # v5.14+ --- drivers/gpu/drm/sysfb/simpledrm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/sysfb/simpledrm.c b/drivers/gpu/drm/sysfb/simpledrm.c index cfb1fe07704d7..78672422bcada 100644 --- a/drivers/gpu/drm/sysfb/simpledrm.c +++ b/drivers/gpu/drm/sysfb/simpledrm.c @@ -275,7 +275,7 @@ static struct simpledrm_device *simpledrm_device_of_dev(struct drm_device *dev) static void simpledrm_device_release_clocks(void *res) { - struct simpledrm_device *sdev = simpledrm_device_of_dev(res); + struct simpledrm_device *sdev = res; unsigned int i; for (i = 0; i < sdev->clk_count; ++i) { @@ -373,7 +373,7 @@ static int simpledrm_device_init_clocks(struct simpledrm_device *sdev) static void simpledrm_device_release_regulators(void *res) { - struct simpledrm_device *sdev = simpledrm_device_of_dev(res); + struct simpledrm_device *sdev = res; unsigned int i; for (i = 0; i < sdev->regulator_count; ++i) { -- 2.49.0

7 months, 3 weeks

3
2
0 0

[PATCH v3 1/2] HID: amd_sfh: Fix SRA sensor when it's the only sensor

by Mario Limonciello

From: Mario Limonciello <mario.limonciello(a)amd.com> On systems that only have an SRA sensor connected to SFH the sensor doesn't get enabled due to a bad optimization condition of breaking the sensor walk loop. This optimization is unnecessary in the first place because if there is only one device then the loop only runs once. Drop the condition and explicitly mark sensor as enabled. Reported-by: Yijun Shen <Yijun.Shen(a)dell.com> Tested-By: Yijun Shen <Yijun_Shen(a)Dell.com> Fixes: d1c444b47100d ("HID: amd_sfh: Add support to export device operating states") Cc: stable(a)vger.kernel.org Signed-off-by: Mario Limonciello <mario.limonciello(a)amd.com> --- v2: * Add tag --- drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_init.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_init.c b/drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_init.c index 25f0ebfcbd5f5..c1bdf1e0d44af 100644 --- a/drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_init.c +++ b/drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_init.c @@ -134,9 +134,6 @@ static int amd_sfh1_1_hid_client_init(struct amd_mp2_dev *privdata) for (i = 0; i < cl_data->num_hid_devices; i++) { cl_data->sensor_sts[i] = SENSOR_DISABLED; - if (cl_data->num_hid_devices == 1 && cl_data->sensor_idx[0] == SRA_IDX) - break; - if (cl_data->sensor_idx[i] == SRA_IDX) { info.sensor_idx = cl_data->sensor_idx[i]; writel(0, privdata->mmio + amd_get_p2c_val(privdata, 0)); @@ -145,8 +142,10 @@ static int amd_sfh1_1_hid_client_init(struct amd_mp2_dev *privdata) (privdata, cl_data->sensor_idx[i], ENABLE_SENSOR); cl_data->sensor_sts[i] = (status == 0) ? SENSOR_ENABLED : SENSOR_DISABLED; - if (cl_data->sensor_sts[i] == SENSOR_ENABLED) + if (cl_data->sensor_sts[i] == SENSOR_ENABLED) { + cl_data->is_any_sensor_enabled = true; privdata->dev_en.is_sra_present = true; + } continue; } -- 2.43.0

7 months, 3 weeks

1
0
0 0

[PATCH 1/1] x86/cpu/topology: Don't limit CPUs to 1 for Xen PV guests due to disabled APIC

by Petr Vaněk

Xen PV guests in DomU have APIC disabled by design, which causes topology_apply_cmdline_limits_early() to limit the number of possible CPUs to 1, regardless of the configured number of vCPUs. This is a regression introduced in version 6.9 in commit 7c0edad3643f ("x86/cpu/topology: Rework possible CPU management") which added an early check that limits CPUs if apic_is_disabled, without accounting for the fact that Xen PV guests always disable APIC even when SMP is supported. This patch fixes the issue by skipping the apic_is_disabled check for Xen PV guests, allowing them to boot with the full set of configured vCPUs. Fixes: 7c0edad3643f ("x86/cpu/topology: Rework possible CPU management") Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: x86(a)kernel.org Cc: xen-devel(a)lists.xenproject.org Cc: stable(a)vger.kernel.org # 6.9+ Signed-off-by: Petr Vaněk <arkamar(a)atlas.cz> --- arch/x86/kernel/cpu/topology.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/cpu/topology.c b/arch/x86/kernel/cpu/topology.c index 01456236a6dd..10aa7f471ec9 100644 --- a/arch/x86/kernel/cpu/topology.c +++ b/arch/x86/kernel/cpu/topology.c @@ -428,8 +428,13 @@ void __init topology_apply_cmdline_limits_early(void) { unsigned int possible = nr_cpu_ids; - /* 'maxcpus=0' 'nosmp' 'nolapic' */ - if (!setup_max_cpus || apic_is_disabled) + /* 'maxcpus=0' 'nosmp' 'nolapic' + * + * The apic_is_disabled check is ignored for Xen PV domains because Xen + * disables ACPI in unprivileged PV DomU guests, which would otherwise limit + * CPUs to 1, even if multiple vCPUs were configured. + */ + if (!setup_max_cpus || (!xen_pv_domain() && apic_is_disabled)) possible = 1; /* 'possible_cpus=N' */ -- 2.48.1

7 months, 3 weeks

2
3
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror April 2025