user/sven/linux.git, branch v6.17.10

Linux 6.17.10

2025-12-01T10:46:09Z

Link: https://lore.kernel.org/r/20251127150348.216197881@linuxfoundation.org Tested-by: Ronald Warsow Tested-by: Brett A C Sheffield Tested-by: Peter Schneider Tested-by: Linux Kernel Functional Testing Tested-by: Dileep Malepu Tested-by: Ron Economos Tested-by: Salvatore Bonaccorso Tested-by: Pavel Machek (CIP) Tested-by: Takeshi Ogasawara Tested-by: Mark Brown Tested-by: Florian Fainelli Signed-off-by: Greg Kroah-Hartman

Revert "gpio: swnode: don't use the swnode's name as the key for GPIO lookup"

2025-12-01T10:46:08Z

This reverts commit 25decf0469d4c91d90aa2e28d996aed276bfc622. This software node change doesn't actually fix any current issues with the kernel, it is an improvement to the lookup process rather than fixing a live bug. It also causes a couple of regressions with shipping laptops, which relied on the label based lookup. There is a fix for the regressions in mainline, the first 5 patches of [1]. However, those patches are fairly substantial changes and given the patch causing the regression doesn't actually fix a bug it seems better to just revert it in stable. CC: stable@vger.kernel.org # 6.12, 6.17 Link: https://lore.kernel.org/linux-sound/20251120-reset-gpios-swnodes-v7-0-a100493a0f4b@linaro.org/ [1] Closes: https://github.com/thesofproject/linux/issues/5599 Closes: https://github.com/thesofproject/linux/issues/5603 Acked-by: Bartosz Golaszewski Signed-off-by: Charles Keepax Signed-off-by: Greg Kroah-Hartman

sched_ext: fix flag check for deferred callbacks

2025-12-01T10:46:08Z

commit a3c4a0a42e61aad1056a3d33fd603c1ae66d4288 upstream. When scheduling the deferred balance callbacks, check SCX_RQ_BAL_CB_PENDING instead of SCX_RQ_BAL_PENDING. This way schedule_deferred() properly tests whether there is already a pending request for queue_balance_callback() to be invoked at the end of .balance(). Fixes: a8ad873113d3 ("sched_ext: defer queue_balance_callback() until after ops.dispatch") Signed-off-by: Emil Tsalapatis Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman

sched_ext: Fix scx_kick_pseqs corruption on concurrent scheduler loads

2025-12-01T10:46:08Z

commit 05e63305c85c88141500f0a2fb02afcfba9396e1 upstream. If we load a BPF scheduler while another scheduler is already running, alloc_kick_pseqs() would be called again, overwriting the previously allocated arrays. Fix by moving the alloc_kick_pseqs() call after the scx_enable_state() check, ensuring that the arrays are only allocated when a scheduler can actually be loaded. Fixes: 14c1da3895a11 ("sched_ext: Allocate scx_kick_cpus_pnt_seqs lazily using kvzalloc()") Signed-off-by: Andrea Righi Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman

drm/i915/dp: Add device specific quirk to limit eDP rate to HBR2

2025-12-01T10:46:08Z

commit 21c586d9233a1f258e8d437466c441d50885d30f upstream. Some ICL/TGL platforms with combo PHY ports suffer from signal integrity issues at HBR3. While certain systems include a Parade PS8461 mux to mitigate this, its presence cannot be reliably detected. Furthermore, broken or missing VBT entries make it unsafe to rely on VBT for enforcing link rate limits. To address this introduce a device specific quirk to cap the eDP link rate to HBR2 (540000 kHz). This will override any higher advertised rates from the sink or DPCD for specific devices. Currently, the quirk is added for Dell XPS 13 7390 2-in-1 which is reported in gitlab issue #5969 [1]. [1] https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/5969 v2: Align the quirk with the intended quirk name and refactor the condition to use min(). (Jani) v3: Use condition `rate > 540000`. Drop extra parentheses. (Ville) Cc: Jani Nikula Cc: Ville Syrjälä Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/5969 Reviewed-by: Ville Syrjälä Signed-off-by: Ankit Nautiyal Link: https://lore.kernel.org/r/20250710052041.1238567-3-ankit.k.nautiyal@intel.com Signed-off-by: Greg Kroah-Hartman

Revert "drm/i915/dp: Reject HBR3 when sink doesn't support TPS4"

2025-12-01T10:46:08Z

commit 8c9006283e4b767003b2d11182d6e90f8b184c3d upstream. This reverts commit 584cf613c24a4250d9be4819efc841aa2624d5b6. Commit 584cf613c24a ("drm/i915/dp: Reject HBR3 when sink doesn't support TPS4") introduced a blanket rejection of HBR3 link rate when the sink does not support TPS4. While this was intended to address instability observed on certain eDP panels [1], there seem to be edp panels that do not follow the specification. These eDP panels do not advertise TPS4 support, but require HBR3 to operate at their fixed native resolution [2]. As a result, the change causes blank screens on such panels. Apparently, Windows driver does not enforce this restriction, and the issue is not seen there. Therefore, revert the commit to restore functionality for such panels, and align behaviour with Windows driver. [1] https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/5969 [2] https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14517 v2: Update the commit message with better justification. (Ville) Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14517 Acked-by: Jani Nikula Reviewed-by: Ville Syrjälä Signed-off-by: Ankit Nautiyal Link: https://lore.kernel.org/r/20250710052041.1238567-2-ankit.k.nautiyal@intel.com Signed-off-by: Greg Kroah-Hartman

tty/vt: fix up incorrect backport to stable releases

2025-12-01T10:46:08Z

Below is a patch for 6.12.58+ and 6.17.8+ stable branches only. Upstream does not need this. Signed-off-by: Jari Ruusu Fixes: da7e8b382396 ("tty/vt: Add missing return value for VT_RESIZE in vt_ioctl()") Signed-off-by: Greg Kroah-Hartman

drm/amd/display: Prevent Gating DTBCLK before It Is Properly Latched

2025-12-01T10:46:07Z

[ Upstream commit cfa0904a35fd0231f4d05da0190f0a22ed881cce ] [why] 1. With allow_0_dtb_clk enabled, the time required to latch DTBCLK to 600 MHz depends on the SMU. If DTBCLK is not latched to 600 MHz before set_mode completes, gating DTBCLK causes the DP2 sink to lose its clock source. 2. The existing DTBCLK gating sequence ungates DTBCLK based on both pix_clk and ref_dtbclk, but gates DTBCLK when either pix_clk or ref_dtbclk is zero. pix_clk can be zero outside the set_mode sequence before DTBCLK is properly latched, which can lead to DTBCLK being gated by mistake. [how] Consider both pixel_clk and ref_dtbclk when determining when it is safe to gate DTBCLK; this is more accurate. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4701 Fixes: 5949e7c4890c ("drm/amd/display: Enable Dynamic DTBCLK Switch") Reviewed-by: Charlene Liu Reviewed-by: Aurabindo Pillai Signed-off-by: Fangzhi Zuo Signed-off-by: Roman Li Tested-by: Dan Wheeler Signed-off-by: Alex Deucher (cherry picked from commit d04eb0c402780ca037b62a6aecf23b863545ebca) Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

drm/amd/display: Insert dccg log for easy debug

2025-12-01T10:46:07Z

[ Upstream commit 35bcc9168f3ce6416cbf3f776758be0937f84cb3 ] [why] Log for sequence tracking Reviewed-by: Ovidiu (Ovi) Bunea Reviewed-by: Yihan Zhu Signed-off-by: Charlene Liu Signed-off-by: Ivan Lipski Tested-by: Dan Wheeler Signed-off-by: Alex Deucher Stable-dep-of: cfa0904a35fd ("drm/amd/display: Prevent Gating DTBCLK before It Is Properly Latched") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

mptcp: fix address removal logic in mptcp_pm_nl_rm_addr

2025-12-01T10:46:07Z

[ Upstream commit 92e239e36d600002559074994a545fcfac9afd2d ] Fix inverted WARN_ON_ONCE condition that prevented normal address removal counter updates. The current code only executes decrement logic when the counter is already 0 (abnormal state), while normal removals (counter > 0) are ignored. Signed-off-by: Gang Yan Fixes: 636113918508 ("mptcp: pm: remove '_nl' from mptcp_pm_nl_rm_addr_received") Cc: stable@vger.kernel.org Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20251118-net-mptcp-misc-fixes-6-18-rc6-v1-10-806d3781c95f@kernel.org Signed-off-by: Jakub Kicinski [ Context ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman