--- /dev/null
+From aa2e1e4563d3ab689ffa86ca1412ecbf9fd3b308 Mon Sep 17 00:00:00 2001
+From: Miaoqian Lin <linmq006@gmail.com>
+Date: Tue, 2 Sep 2025 17:03:58 +0800
+Subject: dmaengine: dw: dmamux: Fix device reference leak in rzn1_dmamux_route_allocate
+
+From: Miaoqian Lin <linmq006@gmail.com>
+
+commit aa2e1e4563d3ab689ffa86ca1412ecbf9fd3b308 upstream.
+
+The reference taken by of_find_device_by_node()
+must be released when not needed anymore.
+Add missing put_device() call to fix device reference leaks.
+
+Fixes: 134d9c52fca2 ("dmaengine: dw: dmamux: Introduce RZN1 DMA router support")
+Cc: stable@vger.kernel.org
+Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
+Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
+Link: https://lore.kernel.org/r/20250902090358.2423285-1-linmq006@gmail.com
+Signed-off-by: Vinod Koul <vkoul@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/dma/dw/rzn1-dmamux.c | 15 +++++++++++----
+ 1 file changed, 11 insertions(+), 4 deletions(-)
+
+--- a/drivers/dma/dw/rzn1-dmamux.c
++++ b/drivers/dma/dw/rzn1-dmamux.c
+@@ -48,12 +48,16 @@ static void *rzn1_dmamux_route_allocate(
+ u32 mask;
+ int ret;
+
+- if (dma_spec->args_count != RNZ1_DMAMUX_NCELLS)
+- return ERR_PTR(-EINVAL);
++ if (dma_spec->args_count != RNZ1_DMAMUX_NCELLS) {
++ ret = -EINVAL;
++ goto put_device;
++ }
+
+ map = kzalloc(sizeof(*map), GFP_KERNEL);
+- if (!map)
+- return ERR_PTR(-ENOMEM);
++ if (!map) {
++ ret = -ENOMEM;
++ goto put_device;
++ }
+
+ chan = dma_spec->args[0];
+ map->req_idx = dma_spec->args[4];
+@@ -94,12 +98,15 @@ static void *rzn1_dmamux_route_allocate(
+ if (ret)
+ goto clear_bitmap;
+
++ put_device(&pdev->dev);
+ return map;
+
+ clear_bitmap:
+ clear_bit(map->req_idx, dmamux->used_chans);
+ free_map:
+ kfree(map);
++put_device:
++ put_device(&pdev->dev);
+
+ return ERR_PTR(ret);
+ }
--- /dev/null
+From 5068b5254812433e841a40886e695633148d362d Mon Sep 17 00:00:00 2001
+From: Stephan Gerhold <stephan.gerhold@linaro.org>
+Date: Wed, 12 Feb 2025 18:03:54 +0100
+Subject: dmaengine: qcom: bam_dma: Fix DT error handling for num-channels/ees
+
+From: Stephan Gerhold <stephan.gerhold@linaro.org>
+
+commit 5068b5254812433e841a40886e695633148d362d upstream.
+
+When we don't have a clock specified in the device tree, we have no way to
+ensure the BAM is on. This is often the case for remotely-controlled or
+remotely-powered BAM instances. In this case, we need to read num-channels
+from the DT to have all the necessary information to complete probing.
+
+However, at the moment invalid device trees without clock and without
+num-channels still continue probing, because the error handling is missing
+return statements. The driver will then later try to read the number of
+channels from the registers. This is unsafe, because it relies on boot
+firmware and lucky timing to succeed. Unfortunately, the lack of proper
+error handling here has been abused for several Qualcomm SoCs upstream,
+causing early boot crashes in several situations [1, 2].
+
+Avoid these early crashes by erroring out when any of the required DT
+properties are missing. Note that this will break some of the existing DTs
+upstream (mainly BAM instances related to the crypto engine). However,
+clearly these DTs have never been tested properly, since the error in the
+kernel log was just ignored. It's safer to disable the crypto engine for
+these broken DTBs.
+
+[1]: https://lore.kernel.org/r/CY01EKQVWE36.B9X5TDXAREPF@fairphone.com/
+[2]: https://lore.kernel.org/r/20230626145959.646747-1-krzysztof.kozlowski@linaro.org/
+
+Cc: stable@vger.kernel.org
+Fixes: 48d163b1aa6e ("dmaengine: qcom: bam_dma: get num-channels and num-ees from dt")
+Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
+Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
+Link: https://lore.kernel.org/r/20250212-bam-dma-fixes-v1-8-f560889e65d8@linaro.org
+Signed-off-by: Vinod Koul <vkoul@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/dma/qcom/bam_dma.c | 8 ++++++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+--- a/drivers/dma/qcom/bam_dma.c
++++ b/drivers/dma/qcom/bam_dma.c
+@@ -1283,13 +1283,17 @@ static int bam_dma_probe(struct platform
+ if (!bdev->bamclk) {
+ ret = of_property_read_u32(pdev->dev.of_node, "num-channels",
+ &bdev->num_channels);
+- if (ret)
++ if (ret) {
+ dev_err(bdev->dev, "num-channels unspecified in dt\n");
++ return ret;
++ }
+
+ ret = of_property_read_u32(pdev->dev.of_node, "qcom,num-ees",
+ &bdev->num_ees);
+- if (ret)
++ if (ret) {
+ dev_err(bdev->dev, "num-ees unspecified in dt\n");
++ return ret;
++ }
+ }
+
+ ret = clk_prepare_enable(bdev->bamclk);
--- /dev/null
+From 7838fb5f119191403560eca2e23613380c0e425e Mon Sep 17 00:00:00 2001
+From: Alex Deucher <alexander.deucher@amd.com>
+Date: Thu, 4 Sep 2025 12:35:05 -0400
+Subject: drm/amdgpu: fix a memory leak in fence cleanup when unloading
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Alex Deucher <alexander.deucher@amd.com>
+
+commit 7838fb5f119191403560eca2e23613380c0e425e upstream.
+
+Commit b61badd20b44 ("drm/amdgpu: fix usage slab after free")
+reordered when amdgpu_fence_driver_sw_fini() was called after
+that patch, amdgpu_fence_driver_sw_fini() effectively became
+a no-op as the sched entities we never freed because the
+ring pointers were already set to NULL. Remove the NULL
+setting.
+
+Reported-by: Lin.Cao <lincao12@amd.com>
+Cc: Vitaly Prosyak <vitaly.prosyak@amd.com>
+Cc: Christian König <christian.koenig@amd.com>
+Fixes: b61badd20b44 ("drm/amdgpu: fix usage slab after free")
+Reviewed-by: Christian König <christian.koenig@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+(cherry picked from commit a525fa37aac36c4591cc8b07ae8957862415fbd5)
+Cc: stable@vger.kernel.org
+[ Adapt to conditional check ]
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 3 ---
+ 1 file changed, 3 deletions(-)
+
+--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c
++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c
+@@ -400,9 +400,6 @@ void amdgpu_ring_fini(struct amdgpu_ring
+ dma_fence_put(ring->vmid_wait);
+ ring->vmid_wait = NULL;
+ ring->me = 0;
+-
+- if (!ring->is_mes_queue)
+- ring->adev->rings[ring->idx] = NULL;
+ }
+
+ /**
--- /dev/null
+From cfa7b7659757f8d0fc4914429efa90d0d2577dd7 Mon Sep 17 00:00:00 2001
+From: Jani Nikula <jani.nikula@intel.com>
+Date: Fri, 5 Sep 2025 13:41:49 +0300
+Subject: drm/i915/power: fix size for for_each_set_bit() in abox iteration
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Jani Nikula <jani.nikula@intel.com>
+
+commit cfa7b7659757f8d0fc4914429efa90d0d2577dd7 upstream.
+
+for_each_set_bit() expects size to be in bits, not bytes. The abox mask
+iteration uses bytes, but it works by coincidence, because the local
+variable holding the mask is unsigned long, and the mask only ever has
+bit 2 as the highest bit. Using a smaller type could lead to subtle and
+very hard to track bugs.
+
+Fixes: 62afef2811e4 ("drm/i915/rkl: RKL uses ABOX0 for pixel transfers")
+Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
+Cc: Matt Roper <matthew.d.roper@intel.com>
+Cc: stable@vger.kernel.org # v5.9+
+Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
+Link: https://lore.kernel.org/r/20250905104149.1144751-1-jani.nikula@intel.com
+Signed-off-by: Jani Nikula <jani.nikula@intel.com>
+(cherry picked from commit 7ea3baa6efe4bb93d11e1c0e6528b1468d7debf6)
+Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>
+[ adapted struct intel_display *display parameters to struct drm_i915_private *dev_priv ]
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/i915/display/intel_display_power.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/drivers/gpu/drm/i915/display/intel_display_power.c
++++ b/drivers/gpu/drm/i915/display/intel_display_power.c
+@@ -1150,7 +1150,7 @@ static void icl_mbus_init(struct drm_i91
+ if (DISPLAY_VER(dev_priv) == 12)
+ abox_regs |= BIT(0);
+
+- for_each_set_bit(i, &abox_regs, sizeof(abox_regs))
++ for_each_set_bit(i, &abox_regs, BITS_PER_TYPE(abox_regs))
+ intel_de_rmw(dev_priv, MBUS_ABOX_CTL(i), mask, val);
+ }
+
+@@ -1603,11 +1603,11 @@ static void tgl_bw_buddy_init(struct drm
+ if (table[config].page_mask == 0) {
+ drm_dbg(&dev_priv->drm,
+ "Unknown memory configuration; disabling address buddy logic.\n");
+- for_each_set_bit(i, &abox_mask, sizeof(abox_mask))
++ for_each_set_bit(i, &abox_mask, BITS_PER_TYPE(abox_mask))
+ intel_de_write(dev_priv, BW_BUDDY_CTL(i),
+ BW_BUDDY_DISABLE);
+ } else {
+- for_each_set_bit(i, &abox_mask, sizeof(abox_mask)) {
++ for_each_set_bit(i, &abox_mask, BITS_PER_TYPE(abox_mask)) {
+ intel_de_write(dev_priv, BW_BUDDY_PAGE_MASK(i),
+ table[config].page_mask);
+
--- /dev/null
+From 8ea25274ebaf2f6be8be374633b2ed8348ec0e70 Mon Sep 17 00:00:00 2001
+From: Buday Csaba <buday.csaba@prolan.hu>
+Date: Thu, 7 Aug 2025 15:54:49 +0200
+Subject: net: mdiobus: release reset_gpio in mdiobus_unregister_device()
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Buday Csaba <buday.csaba@prolan.hu>
+
+commit 8ea25274ebaf2f6be8be374633b2ed8348ec0e70 upstream.
+
+reset_gpio is claimed in mdiobus_register_device(), but it is not
+released in mdiobus_unregister_device(). It is instead only
+released when the whole MDIO bus is unregistered.
+When a device uses the reset_gpio property, it becomes impossible
+to unregister it and register it again, because the GPIO remains
+claimed.
+This patch resolves that issue.
+
+Fixes: bafbdd527d56 ("phylib: Add device reset GPIO support") # see notes
+Reviewed-by: Andrew Lunn <andrew@lunn.ch>
+Cc: Csókás Bence <csokas.bence@prolan.hu>
+[ csokas.bence: Resolve rebase conflict and clarify msg ]
+Signed-off-by: Buday Csaba <buday.csaba@prolan.hu>
+Link: https://patch.msgid.link/20250807135449.254254-2-csokas.bence@prolan.hu
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+[ csokas.bence: Use the v1 patch on top of 6.12, as specified in notes ]
+Signed-off-by: Bence Csókás <csokas.bence@prolan.hu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/phy/mdio_bus.c | 4 +---
+ 1 file changed, 1 insertion(+), 3 deletions(-)
+
+--- a/drivers/net/phy/mdio_bus.c
++++ b/drivers/net/phy/mdio_bus.c
+@@ -97,6 +97,7 @@ int mdiobus_unregister_device(struct mdi
+ if (mdiodev->bus->mdio_map[mdiodev->addr] != mdiodev)
+ return -EINVAL;
+
++ gpiod_put(mdiodev->reset_gpio);
+ reset_control_put(mdiodev->reset_ctrl);
+
+ mdiodev->bus->mdio_map[mdiodev->addr] = NULL;
+@@ -814,9 +815,6 @@ void mdiobus_unregister(struct mii_bus *
+ if (!mdiodev)
+ continue;
+
+- if (mdiodev->reset_gpio)
+- gpiod_put(mdiodev->reset_gpio);
+-
+ mdiodev->device_remove(mdiodev);
+ mdiodev->device_free(mdiodev);
+ }
--- /dev/null
+From bca065733afd1e3a89a02f05ffe14e966cd5f78e Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan@kernel.org>
+Date: Thu, 24 Jul 2025 15:12:04 +0200
+Subject: phy: tegra: xusb: fix device and OF node leak at probe
+
+From: Johan Hovold <johan@kernel.org>
+
+commit bca065733afd1e3a89a02f05ffe14e966cd5f78e upstream.
+
+Make sure to drop the references taken to the PMC OF node and device by
+of_parse_phandle() and of_find_device_by_node() during probe.
+
+Note the holding a reference to the PMC device does not prevent the
+PMC regmap from going away (e.g. if the PMC driver is unbound) so there
+is no need to keep the reference.
+
+Fixes: 2d1021487273 ("phy: tegra: xusb: Add wake/sleepwalk for Tegra210")
+Cc: stable@vger.kernel.org # 5.14
+Cc: JC Kuo <jckuo@nvidia.com>
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
+Link: https://lore.kernel.org/r/20250724131206.2211-2-johan@kernel.org
+Signed-off-by: Vinod Koul <vkoul@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/phy/tegra/xusb-tegra210.c | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+--- a/drivers/phy/tegra/xusb-tegra210.c
++++ b/drivers/phy/tegra/xusb-tegra210.c
+@@ -3164,18 +3164,22 @@ tegra210_xusb_padctl_probe(struct device
+ }
+
+ pdev = of_find_device_by_node(np);
++ of_node_put(np);
+ if (!pdev) {
+ dev_warn(dev, "PMC device is not available\n");
+ goto out;
+ }
+
+- if (!platform_get_drvdata(pdev))
++ if (!platform_get_drvdata(pdev)) {
++ put_device(&pdev->dev);
+ return ERR_PTR(-EPROBE_DEFER);
++ }
+
+ padctl->regmap = dev_get_regmap(&pdev->dev, "usb_sleepwalk");
+ if (!padctl->regmap)
+ dev_info(dev, "failed to find PMC regmap\n");
+
++ put_device(&pdev->dev);
+ out:
+ return &padctl->base;
+ }
--- /dev/null
+From 64961557efa1b98f375c0579779e7eeda1a02c42 Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan@kernel.org>
+Date: Thu, 24 Jul 2025 15:12:05 +0200
+Subject: phy: ti: omap-usb2: fix device leak at unbind
+
+From: Johan Hovold <johan@kernel.org>
+
+commit 64961557efa1b98f375c0579779e7eeda1a02c42 upstream.
+
+Make sure to drop the reference to the control device taken by
+of_find_device_by_node() during probe when the driver is unbound.
+
+Fixes: 478b6c7436c2 ("usb: phy: omap-usb2: Don't use omap_get_control_dev()")
+Cc: stable@vger.kernel.org # 3.13
+Cc: Roger Quadros <rogerq@kernel.org>
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Link: https://lore.kernel.org/r/20250724131206.2211-3-johan@kernel.org
+Signed-off-by: Vinod Koul <vkoul@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/phy/ti/phy-omap-usb2.c | 13 +++++++++++++
+ 1 file changed, 13 insertions(+)
+
+--- a/drivers/phy/ti/phy-omap-usb2.c
++++ b/drivers/phy/ti/phy-omap-usb2.c
+@@ -363,6 +363,13 @@ static void omap_usb2_init_errata(struct
+ phy->flags |= OMAP_USB2_DISABLE_CHRG_DET;
+ }
+
++static void omap_usb2_put_device(void *_dev)
++{
++ struct device *dev = _dev;
++
++ put_device(dev);
++}
++
+ static int omap_usb2_probe(struct platform_device *pdev)
+ {
+ struct omap_usb *phy;
+@@ -373,6 +380,7 @@ static int omap_usb2_probe(struct platfo
+ struct device_node *control_node;
+ struct platform_device *control_pdev;
+ const struct usb_phy_data *phy_data;
++ int ret;
+
+ phy_data = device_get_match_data(&pdev->dev);
+ if (!phy_data)
+@@ -423,6 +431,11 @@ static int omap_usb2_probe(struct platfo
+ return -EINVAL;
+ }
+ phy->control_dev = &control_pdev->dev;
++
++ ret = devm_add_action_or_reset(&pdev->dev, omap_usb2_put_device,
++ phy->control_dev);
++ if (ret)
++ return ret;
+ } else {
+ if (of_property_read_u32_index(node,
+ "syscon-phy-power", 1,
--- /dev/null
+From e19bcea99749ce8e8f1d359f68ae03210694ad56 Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan@kernel.org>
+Date: Thu, 24 Jul 2025 15:12:06 +0200
+Subject: phy: ti-pipe3: fix device leak at unbind
+
+From: Johan Hovold <johan@kernel.org>
+
+commit e19bcea99749ce8e8f1d359f68ae03210694ad56 upstream.
+
+Make sure to drop the reference to the control device taken by
+of_find_device_by_node() during probe when the driver is unbound.
+
+Fixes: 918ee0d21ba4 ("usb: phy: omap-usb3: Don't use omap_get_control_dev()")
+Cc: stable@vger.kernel.org # 3.13
+Cc: Roger Quadros <rogerq@kernel.org>
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Link: https://lore.kernel.org/r/20250724131206.2211-4-johan@kernel.org
+Signed-off-by: Vinod Koul <vkoul@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/phy/ti/phy-ti-pipe3.c | 13 +++++++++++++
+ 1 file changed, 13 insertions(+)
+
+--- a/drivers/phy/ti/phy-ti-pipe3.c
++++ b/drivers/phy/ti/phy-ti-pipe3.c
+@@ -667,12 +667,20 @@ static int ti_pipe3_get_clk(struct ti_pi
+ return 0;
+ }
+
++static void ti_pipe3_put_device(void *_dev)
++{
++ struct device *dev = _dev;
++
++ put_device(dev);
++}
++
+ static int ti_pipe3_get_sysctrl(struct ti_pipe3 *phy)
+ {
+ struct device *dev = phy->dev;
+ struct device_node *node = dev->of_node;
+ struct device_node *control_node;
+ struct platform_device *control_pdev;
++ int ret;
+
+ phy->phy_power_syscon = syscon_regmap_lookup_by_phandle(node,
+ "syscon-phy-power");
+@@ -704,6 +712,11 @@ static int ti_pipe3_get_sysctrl(struct t
+ }
+
+ phy->control_dev = &control_pdev->dev;
++
++ ret = devm_add_action_or_reset(dev, ti_pipe3_put_device,
++ phy->control_dev);
++ if (ret)
++ return ret;
+ }
+
+ if (phy->mode == PIPE3_MODE_PCIE) {
dmaengine-ti-edma-fix-memory-allocation-size-for-que.patch
regulator-sy7636a-fix-lifecycle-of-power-good-gpio.patch
risc-v-remove-unnecessary-include-from-compat.h.patch
+xhci-dbc-fix-full-dbc-transfer-ring-after-several-reconnects.patch
+xhci-fix-memory-leak-regression-when-freeing-xhci-vdev-devices-depth-first.patch
+usb-gadget-dummy-hcd-fix-locking-bug-in-rt-enabled-kernels.patch
+usb-typec-tcpm-properly-deliver-cable-vdms-to-altmode-drivers.patch
+usb-gadget-midi2-fix-missing-ump-group-attributes-initialization.patch
+usb-gadget-midi2-fix-midi2-in-ep-max-packet-size.patch
+dmaengine-qcom-bam_dma-fix-dt-error-handling-for-num-channels-ees.patch
+dmaengine-dw-dmamux-fix-device-reference-leak-in-rzn1_dmamux_route_allocate.patch
+phy-tegra-xusb-fix-device-and-of-node-leak-at-probe.patch
+phy-ti-omap-usb2-fix-device-leak-at-unbind.patch
+phy-ti-pipe3-fix-device-leak-at-unbind.patch
+x86-cpu-topology-always-try-cpu_parse_topology_ext-on-amd-hygon.patch
+net-mdiobus-release-reset_gpio-in-mdiobus_unregister_device.patch
+drm-i915-power-fix-size-for-for_each_set_bit-in-abox-iteration.patch
+drm-amdgpu-fix-a-memory-leak-in-fence-cleanup-when-unloading.patch
--- /dev/null
+From 8d63c83d8eb922f6c316320f50c82fa88d099bea Mon Sep 17 00:00:00 2001
+From: Alan Stern <stern@rowland.harvard.edu>
+Date: Mon, 25 Aug 2025 12:00:22 -0400
+Subject: USB: gadget: dummy-hcd: Fix locking bug in RT-enabled kernels
+
+From: Alan Stern <stern@rowland.harvard.edu>
+
+commit 8d63c83d8eb922f6c316320f50c82fa88d099bea upstream.
+
+Yunseong Kim and the syzbot fuzzer both reported a problem in
+RT-enabled kernels caused by the way dummy-hcd mixes interrupt
+management and spin-locking. The pattern was:
+
+ local_irq_save(flags);
+ spin_lock(&dum->lock);
+ ...
+ spin_unlock(&dum->lock);
+ ... // calls usb_gadget_giveback_request()
+ local_irq_restore(flags);
+
+The code was written this way because usb_gadget_giveback_request()
+needs to be called with interrupts disabled and the private lock not
+held.
+
+While this pattern works fine in non-RT kernels, it's not good when RT
+is enabled. RT kernels handle spinlocks much like mutexes; in particular,
+spin_lock() may sleep. But sleeping is not allowed while local
+interrupts are disabled.
+
+To fix the problem, rewrite the code to conform to the pattern used
+elsewhere in dummy-hcd and other UDC drivers:
+
+ spin_lock_irqsave(&dum->lock, flags);
+ ...
+ spin_unlock(&dum->lock);
+ usb_gadget_giveback_request(...);
+ spin_lock(&dum->lock);
+ ...
+ spin_unlock_irqrestore(&dum->lock, flags);
+
+This approach satisfies the RT requirements.
+
+Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
+Cc: stable <stable@kernel.org>
+Fixes: b4dbda1a22d2 ("USB: dummy-hcd: disable interrupts during req->complete")
+Reported-by: Yunseong Kim <ysk@kzalloc.com>
+Closes: <https://lore.kernel.org/linux-usb/5b337389-73b9-4ee4-a83e-7e82bf5af87a@kzalloc.com/>
+Reported-by: syzbot+8baacc4139f12fa77909@syzkaller.appspotmail.com
+Closes: <https://lore.kernel.org/linux-usb/68ac2411.050a0220.37038e.0087.GAE@google.com/>
+Tested-by: syzbot+8baacc4139f12fa77909@syzkaller.appspotmail.com
+CC: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
+CC: stable@vger.kernel.org
+Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
+Link: https://lore.kernel.org/r/bb192ae2-4eee-48ee-981f-3efdbbd0d8f0@rowland.harvard.edu
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/gadget/udc/dummy_hcd.c | 8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+--- a/drivers/usb/gadget/udc/dummy_hcd.c
++++ b/drivers/usb/gadget/udc/dummy_hcd.c
+@@ -764,8 +764,7 @@ static int dummy_dequeue(struct usb_ep *
+ if (!dum->driver)
+ return -ESHUTDOWN;
+
+- local_irq_save(flags);
+- spin_lock(&dum->lock);
++ spin_lock_irqsave(&dum->lock, flags);
+ list_for_each_entry(iter, &ep->queue, queue) {
+ if (&iter->req != _req)
+ continue;
+@@ -775,15 +774,16 @@ static int dummy_dequeue(struct usb_ep *
+ retval = 0;
+ break;
+ }
+- spin_unlock(&dum->lock);
+
+ if (retval == 0) {
+ dev_dbg(udc_dev(dum),
+ "dequeued req %p from %s, len %d buf %p\n",
+ req, _ep->name, _req->length, _req->buf);
++ spin_unlock(&dum->lock);
+ usb_gadget_giveback_request(_ep, _req);
++ spin_lock(&dum->lock);
+ }
+- local_irq_restore(flags);
++ spin_unlock_irqrestore(&dum->lock, flags);
+ return retval;
+ }
+
--- /dev/null
+From 116e79c679a1530cf833d0ff3007061d7a716bd9 Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Fri, 5 Sep 2025 15:32:34 +0200
+Subject: usb: gadget: midi2: Fix MIDI2 IN EP max packet size
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit 116e79c679a1530cf833d0ff3007061d7a716bd9 upstream.
+
+The EP-IN of MIDI2 (altset 1) wasn't initialized in
+f_midi2_create_usb_configs() as it's an INT EP unlike others BULK
+EPs. But this leaves rather the max packet size unchanged no matter
+which speed is used, resulting in the very slow access.
+And the wMaxPacketSize values set there look legit for INT EPs, so
+let's initialize the MIDI2 EP-IN there for achieving the equivalent
+speed as well.
+
+Fixes: 8b645922b223 ("usb: gadget: Add support for USB MIDI 2.0 function driver")
+Cc: stable <stable@kernel.org>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Link: https://lore.kernel.org/r/20250905133240.20966-1-tiwai@suse.de
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/gadget/function/f_midi2.c | 10 ++++++++--
+ 1 file changed, 8 insertions(+), 2 deletions(-)
+
+--- a/drivers/usb/gadget/function/f_midi2.c
++++ b/drivers/usb/gadget/function/f_midi2.c
+@@ -1739,9 +1739,12 @@ static int f_midi2_create_usb_configs(st
+ case USB_SPEED_HIGH:
+ midi2_midi1_ep_out_desc.wMaxPacketSize = cpu_to_le16(512);
+ midi2_midi1_ep_in_desc.wMaxPacketSize = cpu_to_le16(512);
+- for (i = 0; i < midi2->num_eps; i++)
++ for (i = 0; i < midi2->num_eps; i++) {
+ midi2_midi2_ep_out_desc[i].wMaxPacketSize =
+ cpu_to_le16(512);
++ midi2_midi2_ep_in_desc[i].wMaxPacketSize =
++ cpu_to_le16(512);
++ }
+ fallthrough;
+ case USB_SPEED_FULL:
+ midi1_in_eps = midi2_midi1_ep_in_descs;
+@@ -1750,9 +1753,12 @@ static int f_midi2_create_usb_configs(st
+ case USB_SPEED_SUPER:
+ midi2_midi1_ep_out_desc.wMaxPacketSize = cpu_to_le16(1024);
+ midi2_midi1_ep_in_desc.wMaxPacketSize = cpu_to_le16(1024);
+- for (i = 0; i < midi2->num_eps; i++)
++ for (i = 0; i < midi2->num_eps; i++) {
+ midi2_midi2_ep_out_desc[i].wMaxPacketSize =
+ cpu_to_le16(1024);
++ midi2_midi2_ep_in_desc[i].wMaxPacketSize =
++ cpu_to_le16(1024);
++ }
+ midi1_in_eps = midi2_midi1_ep_in_ss_descs;
+ midi1_out_eps = midi2_midi1_ep_out_ss_descs;
+ break;
--- /dev/null
+From 21d8525d2e061cde034277d518411b02eac764e2 Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Thu, 4 Sep 2025 17:39:24 +0200
+Subject: usb: gadget: midi2: Fix missing UMP group attributes initialization
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit 21d8525d2e061cde034277d518411b02eac764e2 upstream.
+
+The gadget card driver forgot to call snd_ump_update_group_attrs()
+after adding FBs, and this leaves the UMP group attributes
+uninitialized. As a result, -ENODEV error is returned at opening a
+legacy rawmidi device as an inactive group.
+
+This patch adds the missing call to address the behavior above.
+
+Fixes: 8b645922b223 ("usb: gadget: Add support for USB MIDI 2.0 function driver")
+Cc: stable <stable@kernel.org>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Link: https://lore.kernel.org/r/20250904153932.13589-1-tiwai@suse.de
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/gadget/function/f_midi2.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/usb/gadget/function/f_midi2.c
++++ b/drivers/usb/gadget/function/f_midi2.c
+@@ -1601,6 +1601,7 @@ static int f_midi2_create_card(struct f_
+ strscpy(fb->info.name, ump_fb_name(b),
+ sizeof(fb->info.name));
+ }
++ snd_ump_update_group_attrs(ump);
+ }
+
+ for (i = 0; i < midi2->num_eps; i++) {
--- /dev/null
+From f34bfcc77b18375a87091c289c2eb53c249787b4 Mon Sep 17 00:00:00 2001
+From: RD Babiera <rdbabiera@google.com>
+Date: Thu, 21 Aug 2025 20:37:57 +0000
+Subject: usb: typec: tcpm: properly deliver cable vdms to altmode drivers
+
+From: RD Babiera <rdbabiera@google.com>
+
+commit f34bfcc77b18375a87091c289c2eb53c249787b4 upstream.
+
+tcpm_handle_vdm_request delivers messages to the partner altmode or the
+cable altmode depending on the SVDM response type, which is incorrect.
+The partner or cable should be chosen based on the received message type
+instead.
+
+Also add this filter to ADEV_NOTIFY_USB_AND_QUEUE_VDM, which is used when
+the Enter Mode command is responded to by a NAK on SOP or SOP' and when
+the Exit Mode command is responded to by an ACK on SOP.
+
+Fixes: 7e7877c55eb1 ("usb: typec: tcpm: add alt mode enter/exit/vdm support for sop'")
+Cc: stable@vger.kernel.org
+Signed-off-by: RD Babiera <rdbabiera@google.com>
+Reviewed-by: Badhri Jagan Sridharan <badhri@google.com>
+Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
+Link: https://lore.kernel.org/r/20250821203759.1720841-2-rdbabiera@google.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/typec/tcpm/tcpm.c | 12 ++++++++----
+ 1 file changed, 8 insertions(+), 4 deletions(-)
+
+--- a/drivers/usb/typec/tcpm/tcpm.c
++++ b/drivers/usb/typec/tcpm/tcpm.c
+@@ -2375,17 +2375,21 @@ static void tcpm_handle_vdm_request(stru
+ case ADEV_NONE:
+ break;
+ case ADEV_NOTIFY_USB_AND_QUEUE_VDM:
+- WARN_ON(typec_altmode_notify(adev, TYPEC_STATE_USB, NULL));
+- typec_altmode_vdm(adev, p[0], &p[1], cnt);
++ if (rx_sop_type == TCPC_TX_SOP_PRIME) {
++ typec_cable_altmode_vdm(adev, TYPEC_PLUG_SOP_P, p[0], &p[1], cnt);
++ } else {
++ WARN_ON(typec_altmode_notify(adev, TYPEC_STATE_USB, NULL));
++ typec_altmode_vdm(adev, p[0], &p[1], cnt);
++ }
+ break;
+ case ADEV_QUEUE_VDM:
+- if (response_tx_sop_type == TCPC_TX_SOP_PRIME)
++ if (rx_sop_type == TCPC_TX_SOP_PRIME)
+ typec_cable_altmode_vdm(adev, TYPEC_PLUG_SOP_P, p[0], &p[1], cnt);
+ else
+ typec_altmode_vdm(adev, p[0], &p[1], cnt);
+ break;
+ case ADEV_QUEUE_VDM_SEND_EXIT_MODE_ON_FAIL:
+- if (response_tx_sop_type == TCPC_TX_SOP_PRIME) {
++ if (rx_sop_type == TCPC_TX_SOP_PRIME) {
+ if (typec_cable_altmode_vdm(adev, TYPEC_PLUG_SOP_P,
+ p[0], &p[1], cnt)) {
+ int svdm_version = typec_get_cable_svdm_version(
--- /dev/null
+From cba4262a19afae21665ee242b3404bcede5a94d7 Mon Sep 17 00:00:00 2001
+From: K Prateek Nayak <kprateek.nayak@amd.com>
+Date: Mon, 1 Sep 2025 17:04:15 +0000
+Subject: x86/cpu/topology: Always try cpu_parse_topology_ext() on AMD/Hygon
+
+From: K Prateek Nayak <kprateek.nayak@amd.com>
+
+commit cba4262a19afae21665ee242b3404bcede5a94d7 upstream.
+
+Support for parsing the topology on AMD/Hygon processors using CPUID leaf 0xb
+was added in
+
+ 3986a0a805e6 ("x86/CPU/AMD: Derive CPU topology from CPUID function 0xB when available").
+
+In an effort to keep all the topology parsing bits in one place, this commit
+also introduced a pseudo dependency on the TOPOEXT feature to parse the CPUID
+leaf 0xb.
+
+The TOPOEXT feature (CPUID 0x80000001 ECX[22]) advertises the support for
+Cache Properties leaf 0x8000001d and the CPUID leaf 0x8000001e EAX for
+"Extended APIC ID" however support for 0xb was introduced alongside the x2APIC
+support not only on AMD [1], but also historically on x86 [2].
+
+Similar to 0xb, the support for extended CPU topology leaf 0x80000026 too does
+not depend on the TOPOEXT feature.
+
+The support for these leaves is expected to be confirmed by ensuring
+
+ leaf <= {extended_}cpuid_level
+
+and then parsing the level 0 of the respective leaf to confirm EBX[15:0]
+(LogProcAtThisLevel) is non-zero as stated in the definition of
+"CPUID_Fn0000000B_EAX_x00 [Extended Topology Enumeration]
+(Core::X86::Cpuid::ExtTopEnumEax0)" in Processor Programming Reference (PPR)
+for AMD Family 19h Model 01h Rev B1 Vol1 [3] Sec. 2.1.15.1 "CPUID Instruction
+Functions".
+
+This has not been a problem on baremetal platforms since support for TOPOEXT
+(Fam 0x15 and later) predates the support for CPUID leaf 0xb (Fam 0x17[Zen2]
+and later), however, for AMD guests on QEMU, the "x2apic" feature can be
+enabled independent of the "topoext" feature where QEMU expects topology and
+the initial APICID to be parsed using the CPUID leaf 0xb (especially when
+number of cores > 255) which is populated independent of the "topoext" feature
+flag.
+
+Unconditionally call cpu_parse_topology_ext() on AMD and Hygon processors to
+first parse the topology using the XTOPOLOGY leaves (0x80000026 / 0xb) before
+using the TOPOEXT leaf (0x8000001e).
+
+While at it, break down the single large comment in parse_topology_amd() to
+better highlight the purpose of each CPUID leaf.
+
+Fixes: 3986a0a805e6 ("x86/CPU/AMD: Derive CPU topology from CPUID function 0xB when available")
+Suggested-by: Naveen N Rao (AMD) <naveen@kernel.org>
+Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com>
+Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
+Cc: stable@vger.kernel.org # Only v6.9 and above; depends on x86 topology rewrite
+Link: https://lore.kernel.org/lkml/1529686927-7665-1-git-send-email-suravee.suthikulpanit@amd.com/ [1]
+Link: https://lore.kernel.org/lkml/20080818181435.523309000@linux-os.sc.intel.com/ [2]
+Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537 [3]
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kernel/cpu/topology_amd.c | 25 ++++++++++++++-----------
+ 1 file changed, 14 insertions(+), 11 deletions(-)
+
+--- a/arch/x86/kernel/cpu/topology_amd.c
++++ b/arch/x86/kernel/cpu/topology_amd.c
+@@ -174,24 +174,27 @@ static void topoext_fixup(struct topo_sc
+
+ static void parse_topology_amd(struct topo_scan *tscan)
+ {
+- bool has_topoext = false;
+-
+ /*
+- * If the extended topology leaf 0x8000_001e is available
+- * try to get SMT, CORE, TILE, and DIE shifts from extended
++ * Try to get SMT, CORE, TILE, and DIE shifts from extended
+ * CPUID leaf 0x8000_0026 on supported processors first. If
+ * extended CPUID leaf 0x8000_0026 is not supported, try to
+- * get SMT and CORE shift from leaf 0xb first, then try to
+- * get the CORE shift from leaf 0x8000_0008.
++ * get SMT and CORE shift from leaf 0xb. If either leaf is
++ * available, cpu_parse_topology_ext() will return true.
+ */
+- if (cpu_feature_enabled(X86_FEATURE_TOPOEXT))
+- has_topoext = cpu_parse_topology_ext(tscan);
++ bool has_xtopology = cpu_parse_topology_ext(tscan);
+
+- if (!has_topoext && !parse_8000_0008(tscan))
++ /*
++ * If XTOPOLOGY leaves (0x26/0xb) are not available, try to
++ * get the CORE shift from leaf 0x8000_0008 first.
++ */
++ if (!has_xtopology && !parse_8000_0008(tscan))
+ return;
+
+- /* Prefer leaf 0x8000001e if available */
+- if (parse_8000_001e(tscan, has_topoext))
++ /*
++ * Prefer leaf 0x8000001e if available to get the SMT shift and
++ * the initial APIC ID if XTOPOLOGY leaves are not available.
++ */
++ if (parse_8000_001e(tscan, has_xtopology))
+ return;
+
+ /* Try the NODEID MSR */
--- /dev/null
+From a5c98e8b1398534ae1feb6e95e2d3ee5215538ed Mon Sep 17 00:00:00 2001
+From: Mathias Nyman <mathias.nyman@linux.intel.com>
+Date: Tue, 2 Sep 2025 13:53:05 +0300
+Subject: xhci: dbc: Fix full DbC transfer ring after several reconnects
+
+From: Mathias Nyman <mathias.nyman@linux.intel.com>
+
+commit a5c98e8b1398534ae1feb6e95e2d3ee5215538ed upstream.
+
+Pending requests will be flushed on disconnect, and the corresponding
+TRBs will be turned into No-op TRBs, which are ignored by the xHC
+controller once it starts processing the ring.
+
+If the USB debug cable repeatedly disconnects before ring is started
+then the ring will eventually be filled with No-op TRBs.
+No new transfers can be queued when the ring is full, and driver will
+print the following error message:
+
+ "xhci_hcd 0000:00:14.0: failed to queue trbs"
+
+This is a normal case for 'in' transfers where TRBs are always enqueued
+in advance, ready to take on incoming data. If no data arrives, and
+device is disconnected, then ring dequeue will remain at beginning of
+the ring while enqueue points to first free TRB after last cancelled
+No-op TRB.
+s
+Solve this by reinitializing the rings when the debug cable disconnects
+and DbC is leaving the configured state.
+Clear the whole ring buffer and set enqueue and dequeue to the beginning
+of ring, and set cycle bit to its initial state.
+
+Cc: stable@vger.kernel.org
+Fixes: dfba2174dc42 ("usb: xhci: Add DbC support in xHCI driver")
+Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
+Link: https://lore.kernel.org/r/20250902105306.877476-3-mathias.nyman@linux.intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/host/xhci-dbgcap.c | 23 +++++++++++++++++++++--
+ 1 file changed, 21 insertions(+), 2 deletions(-)
+
+--- a/drivers/usb/host/xhci-dbgcap.c
++++ b/drivers/usb/host/xhci-dbgcap.c
+@@ -435,6 +435,25 @@ dbc_alloc_ctx(struct device *dev, gfp_t
+ return ctx;
+ }
+
++static int xhci_dbc_reinit_ep_rings(struct xhci_dbc *dbc)
++{
++ struct xhci_ring *in_ring = dbc->eps[BULK_IN].ring;
++ struct xhci_ring *out_ring = dbc->eps[BULK_OUT].ring;
++
++ if (!in_ring || !out_ring || !dbc->ctx) {
++ dev_warn(dbc->dev, "Can't re-init unallocated endpoints\n");
++ return -ENODEV;
++ }
++
++ xhci_dbc_ring_init(in_ring);
++ xhci_dbc_ring_init(out_ring);
++
++ /* set ep context enqueue, dequeue, and cycle to initial values */
++ xhci_dbc_init_ep_contexts(dbc);
++
++ return 0;
++}
++
+ static struct xhci_ring *
+ xhci_dbc_ring_alloc(struct device *dev, enum xhci_ring_type type, gfp_t flags)
+ {
+@@ -863,7 +882,7 @@ static enum evtreturn xhci_dbc_do_handle
+ dev_info(dbc->dev, "DbC cable unplugged\n");
+ dbc->state = DS_ENABLED;
+ xhci_dbc_flush_requests(dbc);
+-
++ xhci_dbc_reinit_ep_rings(dbc);
+ return EVT_DISC;
+ }
+
+@@ -873,7 +892,7 @@ static enum evtreturn xhci_dbc_do_handle
+ writel(portsc, &dbc->regs->portsc);
+ dbc->state = DS_ENABLED;
+ xhci_dbc_flush_requests(dbc);
+-
++ xhci_dbc_reinit_ep_rings(dbc);
+ return EVT_DISC;
+ }
+
--- /dev/null
+From edcbe06453ddfde21f6aa763f7cab655f26133cc Mon Sep 17 00:00:00 2001
+From: Mathias Nyman <mathias.nyman@linux.intel.com>
+Date: Tue, 2 Sep 2025 13:53:06 +0300
+Subject: xhci: fix memory leak regression when freeing xhci vdev devices depth first
+
+From: Mathias Nyman <mathias.nyman@linux.intel.com>
+
+commit edcbe06453ddfde21f6aa763f7cab655f26133cc upstream.
+
+Suspend-resume cycle test revealed a memory leak in 6.17-rc3
+
+Turns out the slot_id race fix changes accidentally ends up calling
+xhci_free_virt_device() with an incorrect vdev parameter.
+The vdev variable was reused for temporary purposes right before calling
+xhci_free_virt_device().
+
+Fix this by passing the correct vdev parameter.
+
+The slot_id race fix that caused this regression was targeted for stable,
+so this needs to be applied there as well.
+
+Fixes: 2eb03376151b ("usb: xhci: Fix slot_id resource race conflict")
+Reported-by: David Wang <00107082@163.com>
+Closes: https://lore.kernel.org/linux-usb/20250829181354.4450-1-00107082@163.com
+Suggested-by: Michal Pecio <michal.pecio@gmail.com>
+Suggested-by: David Wang <00107082@163.com>
+Cc: stable@vger.kernel.org
+Tested-by: David Wang <00107082@163.com>
+Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
+Link: https://lore.kernel.org/r/20250902105306.877476-4-mathias.nyman@linux.intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/host/xhci-mem.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/usb/host/xhci-mem.c
++++ b/drivers/usb/host/xhci-mem.c
+@@ -939,7 +939,7 @@ static void xhci_free_virt_devices_depth
+ out:
+ /* we are now at a leaf device */
+ xhci_debugfs_remove_slot(xhci, slot_id);
+- xhci_free_virt_device(xhci, vdev, slot_id);
++ xhci_free_virt_device(xhci, xhci->devs[slot_id], slot_id);
+ }
+
+ int xhci_alloc_virt_device(struct xhci_hcd *xhci, int slot_id,
projects / thirdparty / kernel / stable-queue.git / commitdiff
