- Linux-stable-mirror - lists.linaro.org

[PATCH] mux: mmio: fix regmap leak on probe failure

by Johan Hovold

The mmio regmap that may be allocated during probe is never freed. Switch to using the device managed allocator so that the regmap is released on probe failures (e.g. probe deferral) and on driver unbind. Fixes: 61de83fd8256 ("mux: mmio: Do not use syscon helper to build regmap") Cc: stable(a)vger.kernel.org # 6.16 Cc: Andrew Davis <afd(a)ti.com> Signed-off-by: Johan Hovold <johan(a)kernel.org> --- drivers/mux/mmio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mux/mmio.c b/drivers/mux/mmio.c index 9993ce38a818..5b0171d19d43 100644 --- a/drivers/mux/mmio.c +++ b/drivers/mux/mmio.c @@ -58,7 +58,7 @@ static int mux_mmio_probe(struct platform_device *pdev) if (IS_ERR(base)) regmap = ERR_PTR(-ENODEV); else - regmap = regmap_init_mmio(dev, base, &mux_mmio_regmap_cfg); + regmap = devm_regmap_init_mmio(dev, base, &mux_mmio_regmap_cfg); /* Fallback to checking the parent node on "real" errors. */ if (IS_ERR(regmap) && regmap != ERR_PTR(-EPROBE_DEFER)) { regmap = dev_get_regmap(dev->parent, NULL); -- 2.51.2

16 hours, 52 minutes

2
1
0 0

[PATCH v2] drm/amdgpu: Forward VMID reservation errors

by Natalie Vock

Otherwise userspace may be fooled into believing it has a reserved VMID when in reality it doesn't, ultimately leading to GPU hangs when SPM is used. Fixes: 80e709ee6ecc ("drm/amdgpu: add option params to enforce process isolation between graphics and compute") Cc: stable(a)vger.kernel.org Signed-off-by: Natalie Vock <natalie.vock(a)gmx.de> --- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c index 61820166efbf6..1479742556991 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c @@ -2921,8 +2921,7 @@ int amdgpu_vm_ioctl(struct drm_device *dev, void *data, struct drm_file *filp) switch (args->in.op) { case AMDGPU_VM_OP_RESERVE_VMID: /* We only have requirement to reserve vmid from gfxhub */ - amdgpu_vmid_alloc_reserved(adev, vm, AMDGPU_GFXHUB(0)); - break; + return amdgpu_vmid_alloc_reserved(adev, vm, AMDGPU_GFXHUB(0)); case AMDGPU_VM_OP_UNRESERVE_VMID: amdgpu_vmid_free_reserved(adev, vm, AMDGPU_GFXHUB(0)); break; -- 2.51.2

16 hours, 59 minutes

3
2
0 0

+ mm-page_alloc-make-percpu_pagelist_high_fraction-reads-lock-free.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm/page_alloc: make percpu_pagelist_high_fraction reads lock-free has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-page_alloc-make-percpu_pagelist_high_fraction-reads-lock-free.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: Aboorva Devarajan <aboorvad(a)linux.ibm.com> Subject: mm/page_alloc: make percpu_pagelist_high_fraction reads lock-free Date: Mon, 1 Dec 2025 11:30:09 +0530 When page isolation loops indefinitely during memory offline, reading /proc/sys/vm/percpu_pagelist_high_fraction blocks on pcp_batch_high_lock, causing hung task warnings. Make procfs reads lock-free since percpu_pagelist_high_fraction is a simple integer with naturally atomic reads, writers still serialize via the mutex. This prevents hung task warnings when reading the procfs file during long-running memory offline operations. Link: https://lkml.kernel.org/r/20251201060009.1420792-1-aboorvad@linux.ibm.com Signed-off-by: Aboorva Devarajan <aboorvad(a)linux.ibm.com> Cc: Brendan Jackman <jackmanb(a)google.com> Cc: Johannes Weiner <hannes(a)cmpxchg.org> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Suren Baghdasaryan <surenb(a)google.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: Zi Yan <ziy(a)nvidia.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/page_alloc.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) --- a/mm/page_alloc.c~mm-page_alloc-make-percpu_pagelist_high_fraction-reads-lock-free +++ a/mm/page_alloc.c @@ -6611,11 +6611,14 @@ static int percpu_pagelist_high_fraction int old_percpu_pagelist_high_fraction; int ret; + if (!write) + return proc_dointvec_minmax(table, write, buffer, length, ppos); + mutex_lock(&pcp_batch_high_lock); old_percpu_pagelist_high_fraction = percpu_pagelist_high_fraction; ret = proc_dointvec_minmax(table, write, buffer, length, ppos); - if (!write || ret < 0) + if (ret < 0) goto out; /* Sanity checking to avoid pcp imbalance */ _ Patches currently in -mm which might be from aboorvad(a)linux.ibm.com are mm-page_alloc-make-percpu_pagelist_high_fraction-reads-lock-free.patch

17 hours, 13 minutes

1
0
0 0

[PATCH v1] Revert "drm: bridge: ti-sn65dsi83: Add error recovery mechanism"

by Francesco Dolcini

From: Francesco Dolcini <francesco.dolcini(a)toradex.com> This reverts commit ad5c6ecef27e ("drm: bridge: ti-sn65dsi83: Add error recovery mechanism"). The reverted commit introduces a regression on Verdin AM62, and potentially on more devices, not being able to generate a clock that the TI SN65DSI83 PLL can lock to, with the display periodically blinking. Verdin AM62 SoM has a Toshiba TC358778 DPI to DSI bridge, that can be connected to an LVDS display over a TI SN65DSI83 bridge. Before this change despite the TI SN65DSI83 reporting with a debug print a PLL locking error the display was working fine with no visible glitches. The reasons for this issue was investigated without getting to a final conclusion: - the DPI clock was measure and it is stable/accurate - the DSI clock was not possible to measure, but this setup is used with other display/bridges with no known issues - the DSI clock is configured in continuous mode - the actual DSI clock generated from the TC358778 is generate with a PLL from a 25MHz reference clock - it's not clear why some frequencies are working and some are not, for example 50000000, 68750000, 72750000, 75000000 frequencies are fine, while 69750000, 71100000, 72500000 are not Given that the safest approach is to just revert the commit, till a proper solution for error recovery that is not introducing regression is figured out. Reported-by: João Paulo Gonçalves <jpaulo.silvagoncalves(a)gmail.com> Closes: https://lore.kernel.org/all/bhkn6hley4xrol5o3ytn343h4unkwsr26p6s6ltcwexnrsj… Fixes: ad5c6ecef27e ("drm: bridge: ti-sn65dsi83: Add error recovery mechanism") Cc: stable(a)vger.kernel.org Signed-off-by: Francesco Dolcini <francesco.dolcini(a)toradex.com> --- Cc: Herve Codina <herve.codina(a)bootlin.com> Cc: Tomi Valkeinen <tomi.valkeinen(a)ideasonboard.com> Cc: Luca Ceresoli <luca.ceresoli(a)bootlin.com> Cc: Maxime Ripard <mripard(a)kernel.org> Cc: Emanuele Ghidoli <emanuele.ghidoli(a)toradex.com> --- drivers/gpu/drm/bridge/ti-sn65dsi83.c | 136 -------------------------- 1 file changed, 136 deletions(-) diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c b/drivers/gpu/drm/bridge/ti-sn65dsi83.c index 033c44326552..cf627aff569b 100644 --- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c +++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c @@ -35,12 +35,9 @@ #include <linux/of_graph.h> #include <linux/regmap.h> #include <linux/regulator/consumer.h> -#include <linux/timer.h> -#include <linux/workqueue.h> #include <drm/drm_atomic_helper.h> #include <drm/drm_bridge.h> -#include <drm/drm_bridge_helper.h> #include <drm/drm_mipi_dsi.h> #include <drm/drm_of.h> #include <drm/drm_print.h> @@ -161,9 +158,6 @@ struct sn65dsi83 { bool lvds_dual_link_even_odd_swap; int lvds_vod_swing_conf[2]; int lvds_term_conf[2]; - int irq; - struct delayed_work monitor_work; - struct work_struct reset_work; }; static const struct regmap_range sn65dsi83_readable_ranges[] = { @@ -369,100 +363,6 @@ static u8 sn65dsi83_get_dsi_div(struct sn65dsi83 *ctx) return dsi_div - 1; } -static int sn65dsi83_reset_pipe(struct sn65dsi83 *sn65dsi83) -{ - struct drm_modeset_acquire_ctx ctx; - int err; - - /* - * Reset active outputs of the related CRTC. - * - * This way, drm core will reconfigure each components in the CRTC - * outputs path. In our case, this will force the previous component to - * go back in LP11 mode and so allow the reconfiguration of SN65DSI83 - * bridge. - * - * Keep the lock during the whole operation to be atomic. - */ - - drm_modeset_acquire_init(&ctx, 0); - - dev_warn(sn65dsi83->dev, "reset the pipe\n"); - -retry: - err = drm_bridge_helper_reset_crtc(&sn65dsi83->bridge, &ctx); - if (err == -EDEADLK) { - drm_modeset_backoff(&ctx); - goto retry; - } - - drm_modeset_drop_locks(&ctx); - drm_modeset_acquire_fini(&ctx); - - return 0; -} - -static void sn65dsi83_reset_work(struct work_struct *ws) -{ - struct sn65dsi83 *ctx = container_of(ws, struct sn65dsi83, reset_work); - int ret; - - /* Reset the pipe */ - ret = sn65dsi83_reset_pipe(ctx); - if (ret) { - dev_err(ctx->dev, "reset pipe failed %pe\n", ERR_PTR(ret)); - return; - } - if (ctx->irq) - enable_irq(ctx->irq); -} - -static void sn65dsi83_handle_errors(struct sn65dsi83 *ctx) -{ - unsigned int irq_stat; - int ret; - - /* - * Schedule a reset in case of: - * - the bridge doesn't answer - * - the bridge signals an error - */ - - ret = regmap_read(ctx->regmap, REG_IRQ_STAT, &irq_stat); - if (ret || irq_stat) { - /* - * IRQ acknowledged is not always possible (the bridge can be in - * a state where it doesn't answer anymore). To prevent an - * interrupt storm, disable interrupt. The interrupt will be - * after the reset. - */ - if (ctx->irq) - disable_irq_nosync(ctx->irq); - - schedule_work(&ctx->reset_work); - } -} - -static void sn65dsi83_monitor_work(struct work_struct *work) -{ - struct sn65dsi83 *ctx = container_of(to_delayed_work(work), - struct sn65dsi83, monitor_work); - - sn65dsi83_handle_errors(ctx); - - schedule_delayed_work(&ctx->monitor_work, msecs_to_jiffies(1000)); -} - -static void sn65dsi83_monitor_start(struct sn65dsi83 *ctx) -{ - schedule_delayed_work(&ctx->monitor_work, msecs_to_jiffies(1000)); -} - -static void sn65dsi83_monitor_stop(struct sn65dsi83 *ctx) -{ - cancel_delayed_work_sync(&ctx->monitor_work); -} - static void sn65dsi83_atomic_pre_enable(struct drm_bridge *bridge, struct drm_atomic_state *state) { @@ -650,15 +550,6 @@ static void sn65dsi83_atomic_enable(struct drm_bridge *bridge, regmap_read(ctx->regmap, REG_IRQ_STAT, &pval); if (pval) dev_err(ctx->dev, "Unexpected link status 0x%02x\n", pval); - - if (ctx->irq) { - /* Enable irq to detect errors */ - regmap_write(ctx->regmap, REG_IRQ_GLOBAL, REG_IRQ_GLOBAL_IRQ_EN); - regmap_write(ctx->regmap, REG_IRQ_EN, 0xff); - } else { - /* Use the polling task */ - sn65dsi83_monitor_start(ctx); - } } static void sn65dsi83_atomic_disable(struct drm_bridge *bridge, @@ -667,15 +558,6 @@ static void sn65dsi83_atomic_disable(struct drm_bridge *bridge, struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge); int ret; - if (ctx->irq) { - /* Disable irq */ - regmap_write(ctx->regmap, REG_IRQ_EN, 0x0); - regmap_write(ctx->regmap, REG_IRQ_GLOBAL, 0x0); - } else { - /* Stop the polling task */ - sn65dsi83_monitor_stop(ctx); - } - /* Put the chip in reset, pull EN line low, and assure 10ms reset low timing. */ gpiod_set_value_cansleep(ctx->enable_gpio, 0); usleep_range(10000, 11000); @@ -925,14 +807,6 @@ static int sn65dsi83_host_attach(struct sn65dsi83 *ctx) return 0; } -static irqreturn_t sn65dsi83_irq(int irq, void *data) -{ - struct sn65dsi83 *ctx = data; - - sn65dsi83_handle_errors(ctx); - return IRQ_HANDLED; -} - static int sn65dsi83_probe(struct i2c_client *client) { const struct i2c_device_id *id = i2c_client_get_device_id(client); @@ -946,8 +820,6 @@ static int sn65dsi83_probe(struct i2c_client *client) return PTR_ERR(ctx); ctx->dev = dev; - INIT_WORK(&ctx->reset_work, sn65dsi83_reset_work); - INIT_DELAYED_WORK(&ctx->monitor_work, sn65dsi83_monitor_work); if (dev->of_node) { model = (enum sn65dsi83_model)(uintptr_t) @@ -972,14 +844,6 @@ static int sn65dsi83_probe(struct i2c_client *client) if (IS_ERR(ctx->regmap)) return dev_err_probe(dev, PTR_ERR(ctx->regmap), "failed to get regmap\n"); - if (client->irq) { - ctx->irq = client->irq; - ret = devm_request_threaded_irq(ctx->dev, ctx->irq, NULL, sn65dsi83_irq, - IRQF_ONESHOT, dev_name(ctx->dev), ctx); - if (ret) - return dev_err_probe(dev, ret, "failed to request irq\n"); - } - dev_set_drvdata(dev, ctx); i2c_set_clientdata(client, ctx); -- 2.47.3

17 hours, 13 minutes

4
3
0 0

[PATCH] crypto: iaa - Fix out-of-bounds index in find_empty_iaa_compression_mode

by Thorsten Blum

The local variable 'i' is initialized with -EINVAL, but the for loop immediately overwrites it and -EINVAL is never returned. If no empty compression mode can be found, the function would return the out-of-bounds index IAA_COMP_MODES_MAX, which would cause an invalid array access in add_iaa_compression_mode(). Fix both issues by returning either a valid index or -EINVAL. Cc: stable(a)vger.kernel.org Fixes: b190447e0fa3 ("crypto: iaa - Add compression mode management along with fixed mode") Signed-off-by: Thorsten Blum <thorsten.blum(a)linux.dev> --- drivers/crypto/intel/iaa/iaa_crypto_main.c | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/drivers/crypto/intel/iaa/iaa_crypto_main.c b/drivers/crypto/intel/iaa/iaa_crypto_main.c index 23f585219fb4..8ee2a55ec449 100644 --- a/drivers/crypto/intel/iaa/iaa_crypto_main.c +++ b/drivers/crypto/intel/iaa/iaa_crypto_main.c @@ -221,15 +221,13 @@ static struct iaa_compression_mode *iaa_compression_modes[IAA_COMP_MODES_MAX]; static int find_empty_iaa_compression_mode(void) { - int i = -EINVAL; + int i; - for (i = 0; i < IAA_COMP_MODES_MAX; i++) { - if (iaa_compression_modes[i]) - continue; - break; - } + for (i = 0; i < IAA_COMP_MODES_MAX; i++) + if (!iaa_compression_modes[i]) + return i; - return i; + return -EINVAL; } static struct iaa_compression_mode *find_iaa_compression_mode(const char *name, int *idx) -- Thorsten Blum <thorsten.blum(a)linux.dev> GPG: 1D60 735E 8AEF 3BE4 73B6 9D84 7336 78FD 8DFE EAD4

17 hours, 26 minutes

2
1
0 0

+ x86-kexec-add-a-sanity-check-on-previous-kernels-ima-kexec-buffer.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: x86/kexec: add a sanity check on previous kernel's ima kexec buffer has been added to the -mm mm-hotfixes-unstable branch. Its filename is x86-kexec-add-a-sanity-check-on-previous-kernels-ima-kexec-buffer.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: Harshit Mogalapalli <harshit.m.mogalapalli(a)oracle.com> Subject: x86/kexec: add a sanity check on previous kernel's ima kexec buffer Date: Wed, 12 Nov 2025 11:30:02 -0800 When the second-stage kernel is booted via kexec with a limiting command line such as "mem=<size>", the physical range that contains the carried over IMA measurement list may fall outside the truncated RAM leading to a kernel panic. BUG: unable to handle page fault for address: ffff97793ff47000 RIP: ima_restore_measurement_list+0xdc/0x45a #PF: error_code(0x0000) �� not-present page Other architectures already validate the range with page_is_ram(), as done in commit: cbf9c4b9617b ("of: check previous kernel's ima-kexec-buffer against memory bounds") do a similar check on x86. Link: https://lkml.kernel.org/r/20251112193005.3772542-1-harshit.m.mogalapalli@or… Fixes: b69a2afd5afc ("x86/kexec: Carry forward IMA measurement log on kexec") Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli(a)oracle.com> Reported-by: Paul Webb <paul.x.webb(a)oracle.com> Reviewed-by: Jonathan McDowell <noodles(a)meta.com> Cc: Alexander Graf <graf(a)amazon.com> Cc: Ard Biesheuvel <ardb(a)kernel.org> Cc: Borislav Betkov <bp(a)alien8.de> Cc: guoweikang <guoweikang.kernel(a)gmail.com> Cc: Henry Willard <henry.willard(a)oracle.com> Cc: "H. Peter Anvin" <hpa(a)zytor.com> Cc: Ingo Molnar <mingo(a)redhat.com> Cc: Jiri Bohac <jbohac(a)suse.cz> Cc: Joel Granados <joel.granados(a)kernel.org> Cc: Mike Rapoport <rppt(a)kernel.org> Cc: Mimi Zohar <zohar(a)linux.ibm.com> Cc: Sohil Mehta <sohil.mehta(a)intel.com> Cc: Sourabh Jain <sourabhjain(a)linux.ibm.com> Cc: Thomas Gleinxer <tglx(a)linutronix.de> Cc: Yifei Liu <yifei.l.liu(a)oracle.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- arch/x86/kernel/setup.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) --- a/arch/x86/kernel/setup.c~x86-kexec-add-a-sanity-check-on-previous-kernels-ima-kexec-buffer +++ a/arch/x86/kernel/setup.c @@ -439,9 +439,23 @@ int __init ima_free_kexec_buffer(void) int __init ima_get_kexec_buffer(void **addr, size_t *size) { + unsigned long start_pfn, end_pfn; + if (!ima_kexec_buffer_size) return -ENOENT; + /* + * Calculate the PFNs for the buffer and ensure + * they are with in addressable memory. + */ + start_pfn = PFN_DOWN(ima_kexec_buffer_phys); + end_pfn = PFN_DOWN(ima_kexec_buffer_phys + ima_kexec_buffer_size - 1); + if (!pfn_range_is_mapped(start_pfn, end_pfn)) { + pr_warn("IMA buffer at 0x%llx, size = 0x%zx beyond memory\n", + ima_kexec_buffer_phys, ima_kexec_buffer_size); + return -EINVAL; + } + *addr = __va(ima_kexec_buffer_phys); *size = ima_kexec_buffer_size; _ Patches currently in -mm which might be from harshit.m.mogalapalli(a)oracle.com are x86-kexec-add-a-sanity-check-on-previous-kernels-ima-kexec-buffer.patch

17 hours, 33 minutes

1
0
0 0

FAILED: patch "[PATCH] xhci: dbgtty: fix device unregister" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-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-5.15.y git checkout FETCH_HEAD git cherry-pick -x 1f73b8b56cf35de29a433aee7bfff26cea98be3f # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025120110-deuce-arrange-e66c@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 1f73b8b56cf35de29a433aee7bfff26cea98be3f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=C5=81ukasz=20Bartosik?= <ukaszb(a)chromium.org> Date: Wed, 19 Nov 2025 21:29:09 +0000 Subject: [PATCH] xhci: dbgtty: fix device unregister MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit When DbC is disconnected then xhci_dbc_tty_unregister_device() is called. However if there is any user space process blocked on write to DbC terminal device then it will never be signalled and thus stay blocked indifinitely. This fix adds a tty_vhangup() call in xhci_dbc_tty_unregister_device(). The tty_vhangup() wakes up any blocked writers and causes subsequent write attempts to DbC terminal device to fail. Cc: stable <stable(a)kernel.org> Fixes: dfba2174dc42 ("usb: xhci: Add DbC support in xHCI driver") Signed-off-by: Łukasz Bartosik <ukaszb(a)chromium.org> Link: https://patch.msgid.link/20251119212910.1245694-1-ukaszb@google.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/usb/host/xhci-dbgtty.c b/drivers/usb/host/xhci-dbgtty.c index b7f95565524d..57cdda4e09c8 100644 --- a/drivers/usb/host/xhci-dbgtty.c +++ b/drivers/usb/host/xhci-dbgtty.c @@ -550,6 +550,12 @@ static void xhci_dbc_tty_unregister_device(struct xhci_dbc *dbc) if (!port->registered) return; + /* + * Hang up the TTY. This wakes up any blocked + * writers and causes subsequent writes to fail. + */ + tty_vhangup(port->port.tty); + tty_unregister_device(dbc_tty_driver, port->minor); xhci_dbc_tty_exit_port(port); port->registered = false;

17 hours, 42 minutes

1
0
0 0

FAILED: patch "[PATCH] xhci: dbgtty: fix device unregister" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-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-5.10.y git checkout FETCH_HEAD git cherry-pick -x 1f73b8b56cf35de29a433aee7bfff26cea98be3f # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025120110-coastal-litigator-8952@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 1f73b8b56cf35de29a433aee7bfff26cea98be3f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=C5=81ukasz=20Bartosik?= <ukaszb(a)chromium.org> Date: Wed, 19 Nov 2025 21:29:09 +0000 Subject: [PATCH] xhci: dbgtty: fix device unregister MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit When DbC is disconnected then xhci_dbc_tty_unregister_device() is called. However if there is any user space process blocked on write to DbC terminal device then it will never be signalled and thus stay blocked indifinitely. This fix adds a tty_vhangup() call in xhci_dbc_tty_unregister_device(). The tty_vhangup() wakes up any blocked writers and causes subsequent write attempts to DbC terminal device to fail. Cc: stable <stable(a)kernel.org> Fixes: dfba2174dc42 ("usb: xhci: Add DbC support in xHCI driver") Signed-off-by: Łukasz Bartosik <ukaszb(a)chromium.org> Link: https://patch.msgid.link/20251119212910.1245694-1-ukaszb@google.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/usb/host/xhci-dbgtty.c b/drivers/usb/host/xhci-dbgtty.c index b7f95565524d..57cdda4e09c8 100644 --- a/drivers/usb/host/xhci-dbgtty.c +++ b/drivers/usb/host/xhci-dbgtty.c @@ -550,6 +550,12 @@ static void xhci_dbc_tty_unregister_device(struct xhci_dbc *dbc) if (!port->registered) return; + /* + * Hang up the TTY. This wakes up any blocked + * writers and causes subsequent writes to fail. + */ + tty_vhangup(port->port.tty); + tty_unregister_device(dbc_tty_driver, port->minor); xhci_dbc_tty_exit_port(port); port->registered = false;

17 hours, 42 minutes

1
0
0 0

FAILED: patch "[PATCH] xhci: fix stale flag preventig URBs after link state error is" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-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-5.10.y git checkout FETCH_HEAD git cherry-pick -x b69dfcab6894b1fed5362a364411502a7469fce3 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025120146-coaster-huff-141a@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From b69dfcab6894b1fed5362a364411502a7469fce3 Mon Sep 17 00:00:00 2001 From: Mathias Nyman <mathias.nyman(a)linux.intel.com> Date: Fri, 7 Nov 2025 18:28:16 +0200 Subject: [PATCH] xhci: fix stale flag preventig URBs after link state error is cleared A usb device caught behind a link in ss.Inactive error state needs to be reset to recover. A VDEV_PORT_ERROR flag is used to track this state, preventing new transfers from being queued until error is cleared. This flag may be left uncleared if link goes to error state between two resets, and print the following message: "xhci_hcd 0000:00:14.0: Can't queue urb, port error, link inactive" Fix setting and clearing the flag. The flag is cleared after hub driver has successfully reset the device when hcd->reset_device is called. xhci-hcd issues an internal "reset device" command in this callback, and clear all flags once the command completes successfully. This command may complete with a context state error if slot was recently reset and is already in the defauilt state. This is treated as a success but flag was left uncleared. The link state field is also unreliable if port is currently in reset, so don't set the flag in active reset cases. Also clear the flag immediately when link is no longer in ss.Inactive state and port event handler detects a completed reset. This issue was discovered while debugging kernel bugzilla issue 220491. It is likely one small part of the problem, causing some of the failures, but root cause remains unknown Link: https://bugzilla.kernel.org/show_bug.cgi?id=220491 Fixes: b8c3b718087b ("usb: xhci: Don't try to recover an endpoint if port is in error state.") Cc: stable(a)vger.kernel.org Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com> Link: https://patch.msgid.link/20251107162819.1362579-2-mathias.nyman@linux.intel… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c index 8e209aa33ea7..5bdcf9ab2b99 100644 --- a/drivers/usb/host/xhci-ring.c +++ b/drivers/usb/host/xhci-ring.c @@ -1985,6 +1985,7 @@ static void xhci_cavium_reset_phy_quirk(struct xhci_hcd *xhci) static void handle_port_status(struct xhci_hcd *xhci, union xhci_trb *event) { + struct xhci_virt_device *vdev = NULL; struct usb_hcd *hcd; u32 port_id; u32 portsc, cmd_reg; @@ -2016,6 +2017,9 @@ static void handle_port_status(struct xhci_hcd *xhci, union xhci_trb *event) goto cleanup; } + if (port->slot_id) + vdev = xhci->devs[port->slot_id]; + /* We might get interrupts after shared_hcd is removed */ if (port->rhub == &xhci->usb3_rhub && xhci->shared_hcd == NULL) { xhci_dbg(xhci, "ignore port event for removed USB3 hcd\n"); @@ -2038,10 +2042,11 @@ static void handle_port_status(struct xhci_hcd *xhci, union xhci_trb *event) usb_hcd_resume_root_hub(hcd); } - if (hcd->speed >= HCD_USB3 && - (portsc & PORT_PLS_MASK) == XDEV_INACTIVE) { - if (port->slot_id && xhci->devs[port->slot_id]) - xhci->devs[port->slot_id]->flags |= VDEV_PORT_ERROR; + if (vdev && (portsc & PORT_PLS_MASK) == XDEV_INACTIVE) { + if (!(portsc & PORT_RESET)) + vdev->flags |= VDEV_PORT_ERROR; + } else if (vdev && portsc & PORT_RC) { + vdev->flags &= ~VDEV_PORT_ERROR; } if ((portsc & PORT_PLC) && (portsc & PORT_PLS_MASK) == XDEV_RESUME) { @@ -2099,7 +2104,7 @@ static void handle_port_status(struct xhci_hcd *xhci, union xhci_trb *event) * so the roothub behavior is consistent with external * USB 3.0 hub behavior. */ - if (port->slot_id && xhci->devs[port->slot_id]) + if (vdev) xhci_ring_device(xhci, port->slot_id); if (bus_state->port_remote_wakeup & (1 << hcd_portnum)) { xhci_test_and_clear_bit(xhci, port, PORT_PLC); diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c index 0cb45b95e4f5..a148a1280126 100644 --- a/drivers/usb/host/xhci.c +++ b/drivers/usb/host/xhci.c @@ -4007,6 +4007,7 @@ static int xhci_discover_or_reset_device(struct usb_hcd *hcd, xhci_get_slot_state(xhci, virt_dev->out_ctx)); xhci_dbg(xhci, "Not freeing device rings.\n"); /* Don't treat this as an error. May change my mind later. */ + virt_dev->flags = 0; ret = 0; goto command_cleanup; case COMP_SUCCESS:

17 hours, 42 minutes

1
0
0 0

FAILED: patch "[PATCH] xhci: fix stale flag preventig URBs after link state error is" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-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-5.15.y git checkout FETCH_HEAD git cherry-pick -x b69dfcab6894b1fed5362a364411502a7469fce3 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025120145-worrier-sasquatch-788e@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From b69dfcab6894b1fed5362a364411502a7469fce3 Mon Sep 17 00:00:00 2001 From: Mathias Nyman <mathias.nyman(a)linux.intel.com> Date: Fri, 7 Nov 2025 18:28:16 +0200 Subject: [PATCH] xhci: fix stale flag preventig URBs after link state error is cleared A usb device caught behind a link in ss.Inactive error state needs to be reset to recover. A VDEV_PORT_ERROR flag is used to track this state, preventing new transfers from being queued until error is cleared. This flag may be left uncleared if link goes to error state between two resets, and print the following message: "xhci_hcd 0000:00:14.0: Can't queue urb, port error, link inactive" Fix setting and clearing the flag. The flag is cleared after hub driver has successfully reset the device when hcd->reset_device is called. xhci-hcd issues an internal "reset device" command in this callback, and clear all flags once the command completes successfully. This command may complete with a context state error if slot was recently reset and is already in the defauilt state. This is treated as a success but flag was left uncleared. The link state field is also unreliable if port is currently in reset, so don't set the flag in active reset cases. Also clear the flag immediately when link is no longer in ss.Inactive state and port event handler detects a completed reset. This issue was discovered while debugging kernel bugzilla issue 220491. It is likely one small part of the problem, causing some of the failures, but root cause remains unknown Link: https://bugzilla.kernel.org/show_bug.cgi?id=220491 Fixes: b8c3b718087b ("usb: xhci: Don't try to recover an endpoint if port is in error state.") Cc: stable(a)vger.kernel.org Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com> Link: https://patch.msgid.link/20251107162819.1362579-2-mathias.nyman@linux.intel… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c index 8e209aa33ea7..5bdcf9ab2b99 100644 --- a/drivers/usb/host/xhci-ring.c +++ b/drivers/usb/host/xhci-ring.c @@ -1985,6 +1985,7 @@ static void xhci_cavium_reset_phy_quirk(struct xhci_hcd *xhci) static void handle_port_status(struct xhci_hcd *xhci, union xhci_trb *event) { + struct xhci_virt_device *vdev = NULL; struct usb_hcd *hcd; u32 port_id; u32 portsc, cmd_reg; @@ -2016,6 +2017,9 @@ static void handle_port_status(struct xhci_hcd *xhci, union xhci_trb *event) goto cleanup; } + if (port->slot_id) + vdev = xhci->devs[port->slot_id]; + /* We might get interrupts after shared_hcd is removed */ if (port->rhub == &xhci->usb3_rhub && xhci->shared_hcd == NULL) { xhci_dbg(xhci, "ignore port event for removed USB3 hcd\n"); @@ -2038,10 +2042,11 @@ static void handle_port_status(struct xhci_hcd *xhci, union xhci_trb *event) usb_hcd_resume_root_hub(hcd); } - if (hcd->speed >= HCD_USB3 && - (portsc & PORT_PLS_MASK) == XDEV_INACTIVE) { - if (port->slot_id && xhci->devs[port->slot_id]) - xhci->devs[port->slot_id]->flags |= VDEV_PORT_ERROR; + if (vdev && (portsc & PORT_PLS_MASK) == XDEV_INACTIVE) { + if (!(portsc & PORT_RESET)) + vdev->flags |= VDEV_PORT_ERROR; + } else if (vdev && portsc & PORT_RC) { + vdev->flags &= ~VDEV_PORT_ERROR; } if ((portsc & PORT_PLC) && (portsc & PORT_PLS_MASK) == XDEV_RESUME) { @@ -2099,7 +2104,7 @@ static void handle_port_status(struct xhci_hcd *xhci, union xhci_trb *event) * so the roothub behavior is consistent with external * USB 3.0 hub behavior. */ - if (port->slot_id && xhci->devs[port->slot_id]) + if (vdev) xhci_ring_device(xhci, port->slot_id); if (bus_state->port_remote_wakeup & (1 << hcd_portnum)) { xhci_test_and_clear_bit(xhci, port, PORT_PLC); diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c index 0cb45b95e4f5..a148a1280126 100644 --- a/drivers/usb/host/xhci.c +++ b/drivers/usb/host/xhci.c @@ -4007,6 +4007,7 @@ static int xhci_discover_or_reset_device(struct usb_hcd *hcd, xhci_get_slot_state(xhci, virt_dev->out_ctx)); xhci_dbg(xhci, "Not freeing device rings.\n"); /* Don't treat this as an error. May change my mind later. */ + virt_dev->flags = 0; ret = 0; goto command_cleanup; case COMP_SUCCESS:

17 hours, 42 minutes

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror