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

FAILED: patch "[PATCH] usb: dwc3: qcom: Don't leave BCR asserted" failed to apply to 6.6-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.6-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.6.y git checkout FETCH_HEAD git cherry-pick -x ef8abc0ba49ce717e6bc4124e88e59982671f3b5 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025072115-flyer-refresh-17c6@gregkh' --subject-prefix 'PATCH 6.6.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From ef8abc0ba49ce717e6bc4124e88e59982671f3b5 Mon Sep 17 00:00:00 2001 From: Krishna Kurapati <krishna.kurapati(a)oss.qualcomm.com> Date: Wed, 9 Jul 2025 18:59:00 +0530 Subject: [PATCH] usb: dwc3: qcom: Don't leave BCR asserted Leaving the USB BCR asserted prevents the associated GDSC to turn on. This blocks any subsequent attempts of probing the device, e.g. after a probe deferral, with the following showing in the log: [ 1.332226] usb30_prim_gdsc status stuck at 'off' Leave the BCR deasserted when exiting the driver to avoid this issue. Cc: stable <stable(a)kernel.org> Fixes: a4333c3a6ba9 ("usb: dwc3: Add Qualcomm DWC3 glue driver") Acked-by: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com> Reviewed-by: Konrad Dybcio <konrad.dybcio(a)oss.qualcomm.com> Signed-off-by: Krishna Kurapati <krishna.kurapati(a)oss.qualcomm.com> Link: https://lore.kernel.org/r/20250709132900.3408752-1-krishna.kurapati@oss.qua… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c index 7334de85ad10..ca7e1c02773a 100644 --- a/drivers/usb/dwc3/dwc3-qcom.c +++ b/drivers/usb/dwc3/dwc3-qcom.c @@ -680,12 +680,12 @@ static int dwc3_qcom_probe(struct platform_device *pdev) ret = reset_control_deassert(qcom->resets); if (ret) { dev_err(&pdev->dev, "failed to deassert resets, err=%d\n", ret); - goto reset_assert; + return ret; } ret = clk_bulk_prepare_enable(qcom->num_clocks, qcom->clks); if (ret < 0) - goto reset_assert; + return ret; r = platform_get_resource(pdev, IORESOURCE_MEM, 0); if (!r) { @@ -755,8 +755,6 @@ static int dwc3_qcom_probe(struct platform_device *pdev) dwc3_core_remove(&qcom->dwc); clk_disable: clk_bulk_disable_unprepare(qcom->num_clocks, qcom->clks); -reset_assert: - reset_control_assert(qcom->resets); return ret; } @@ -771,7 +769,6 @@ static void dwc3_qcom_remove(struct platform_device *pdev) clk_bulk_disable_unprepare(qcom->num_clocks, qcom->clks); dwc3_qcom_interconnect_exit(qcom); - reset_control_assert(qcom->resets); } static int dwc3_qcom_pm_suspend(struct device *dev)

3 months, 2 weeks

2
1
0 0

FAILED: patch "[PATCH] usb: dwc3: qcom: Don't leave BCR asserted" failed to apply to 6.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.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-6.15.y git checkout FETCH_HEAD git cherry-pick -x ef8abc0ba49ce717e6bc4124e88e59982671f3b5 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025072114-domelike-overstuff-fe4f@gregkh' --subject-prefix 'PATCH 6.15.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From ef8abc0ba49ce717e6bc4124e88e59982671f3b5 Mon Sep 17 00:00:00 2001 From: Krishna Kurapati <krishna.kurapati(a)oss.qualcomm.com> Date: Wed, 9 Jul 2025 18:59:00 +0530 Subject: [PATCH] usb: dwc3: qcom: Don't leave BCR asserted Leaving the USB BCR asserted prevents the associated GDSC to turn on. This blocks any subsequent attempts of probing the device, e.g. after a probe deferral, with the following showing in the log: [ 1.332226] usb30_prim_gdsc status stuck at 'off' Leave the BCR deasserted when exiting the driver to avoid this issue. Cc: stable <stable(a)kernel.org> Fixes: a4333c3a6ba9 ("usb: dwc3: Add Qualcomm DWC3 glue driver") Acked-by: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com> Reviewed-by: Konrad Dybcio <konrad.dybcio(a)oss.qualcomm.com> Signed-off-by: Krishna Kurapati <krishna.kurapati(a)oss.qualcomm.com> Link: https://lore.kernel.org/r/20250709132900.3408752-1-krishna.kurapati@oss.qua… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c index 7334de85ad10..ca7e1c02773a 100644 --- a/drivers/usb/dwc3/dwc3-qcom.c +++ b/drivers/usb/dwc3/dwc3-qcom.c @@ -680,12 +680,12 @@ static int dwc3_qcom_probe(struct platform_device *pdev) ret = reset_control_deassert(qcom->resets); if (ret) { dev_err(&pdev->dev, "failed to deassert resets, err=%d\n", ret); - goto reset_assert; + return ret; } ret = clk_bulk_prepare_enable(qcom->num_clocks, qcom->clks); if (ret < 0) - goto reset_assert; + return ret; r = platform_get_resource(pdev, IORESOURCE_MEM, 0); if (!r) { @@ -755,8 +755,6 @@ static int dwc3_qcom_probe(struct platform_device *pdev) dwc3_core_remove(&qcom->dwc); clk_disable: clk_bulk_disable_unprepare(qcom->num_clocks, qcom->clks); -reset_assert: - reset_control_assert(qcom->resets); return ret; } @@ -771,7 +769,6 @@ static void dwc3_qcom_remove(struct platform_device *pdev) clk_bulk_disable_unprepare(qcom->num_clocks, qcom->clks); dwc3_qcom_interconnect_exit(qcom); - reset_control_assert(qcom->resets); } static int dwc3_qcom_pm_suspend(struct device *dev)

3 months, 2 weeks

2
1
0 0

FAILED: patch "[PATCH] usb: musb: fix gadget state on disconnect" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-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.4.y git checkout FETCH_HEAD git cherry-pick -x 67a59f82196c8c4f50c83329f0577acfb1349b50 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025072133-unwatched-pushy-6a36@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 67a59f82196c8c4f50c83329f0577acfb1349b50 Mon Sep 17 00:00:00 2001 From: Drew Hamilton <drew.hamilton(a)zetier.com> Date: Tue, 1 Jul 2025 11:41:26 -0400 Subject: [PATCH] usb: musb: fix gadget state on disconnect When unplugging the USB cable or disconnecting a gadget in usb peripheral mode with echo "" > /sys/kernel/config/usb_gadget/<your_gadget>/UDC, /sys/class/udc/musb-hdrc.0/state does not change from USB_STATE_CONFIGURED. Testing on dwc2/3 shows they both update the state to USB_STATE_NOTATTACHED. Add calls to usb_gadget_set_state in musb_g_disconnect and musb_gadget_stop to fix both cases. Fixes: 49401f4169c0 ("usb: gadget: introduce gadget state tracking") Cc: stable(a)vger.kernel.org Co-authored-by: Yehowshua Immanuel <yehowshua.immanuel(a)twosixtech.com> Signed-off-by: Yehowshua Immanuel <yehowshua.immanuel(a)twosixtech.com> Signed-off-by: Drew Hamilton <drew.hamilton(a)zetier.com> Link: https://lore.kernel.org/r/20250701154126.8543-1-drew.hamilton@zetier.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c index 6869c58367f2..caf4d4cd4b75 100644 --- a/drivers/usb/musb/musb_gadget.c +++ b/drivers/usb/musb/musb_gadget.c @@ -1913,6 +1913,7 @@ static int musb_gadget_stop(struct usb_gadget *g) * gadget driver here and have everything work; * that currently misbehaves. */ + usb_gadget_set_state(g, USB_STATE_NOTATTACHED); /* Force check of devctl register for PM runtime */ pm_runtime_mark_last_busy(musb->controller); @@ -2019,6 +2020,7 @@ void musb_g_disconnect(struct musb *musb) case OTG_STATE_B_PERIPHERAL: case OTG_STATE_B_IDLE: musb_set_state(musb, OTG_STATE_B_IDLE); + usb_gadget_set_state(&musb->g, USB_STATE_NOTATTACHED); break; case OTG_STATE_B_SRP_INIT: break;

3 months, 2 weeks

2
1
0 0

[PATCH 5.4.y 0/3] Backport CVE-2023-33288 fix to stable kernel v5.4.y

by skulkarni＠mvista.com

From: Shubham Kulkarni <skulkarni(a)mvista.com> Hi Greg/All, This patch series backports the fix for CVE-2023-33288 along with its 2 dependency commits to 5.4 stable kernel. These patches are already part of stable kernel v5.10.y and I have referred to those commits to generate this series for v5.4. [CVE-2023-33288 - kernel: use-after-free in bq24190_remove in drivers/power/supply/bq24190_charger.c] Patch 1: Dependency Patch #1 - mainline commit 1a37a0397116 (v5.9-rc1) Patch 2: Dependency Patch #2 - v5.10.y commit 18359b8e30c4 (v5.10.177) Patch 3: CVE-2023-33288 fix - v5.10.y commit 2b346876b931 (v5.10.177) --- Dinghao Liu (1): power: supply: bq24190_charger: Fix runtime PM imbalance on error Minghao Chi (1): power: supply: bq24190_charger: using pm_runtime_resume_and_get instead of pm_runtime_get_sync Zheng Wang (1): power: supply: bq24190: Fix use after free bug in bq24190_remove due to race condition drivers/power/supply/bq24190_charger.c | 60 +++++++++----------------- 1 file changed, 21 insertions(+), 39 deletions(-) -- 2.25.1

3 months, 2 weeks

2
6
0 0

Backport a5a441ae283d ("ice/ptp: fix crosstimestamp reporting")

by Markus Blöchl

Hi Greg, please consider backporting a5a441ae283d ("ice/ptp: fix crosstimestamp reporting") into linux-6.12.y It fixes a regression from the series around d4bea547ebb57 ("ice/ptp: Remove convert_art_to_tsc()") which affected multiple drivers and occasionally caused phc2sys to fail on ioctl(fd, PTP_SYS_OFFSET_PRECISE, ...). This was the initial fix for ice but apparently tagging it for stable was forgotten during submission. A similar fix for e1000e can be found here: Link: https://lore.kernel.org/lkml/20250709-e1000e_crossts-v2-1-2aae94384c59@bloc… The hunk was moved around slightly in the upstream commit 92456e795ac6 ("ice: Add unified ice_capture_crosststamp"). Let me know if you therefore want a separate patch, I just didn't want to to steal the credits here. Thanks a lot! Markus --

3 months, 2 weeks

2
1
0 0

[PATCH] Fix SMB311 posix special file creation to servers which do not advertise reparse support

by Ahmet Eray Karadag

From: Steve French <stfrench(a)microsoft.com> Some servers (including Samba), support the SMB3.1.1 POSIX Extensions (which use reparse points for handling special files) but do not properly advertise file system attribute FILE_SUPPORTS_REPARSE_POINTS. Although we don't check for this attribute flag when querying special file information, we do check it when creating special files which causes them to fail unnecessarily. If we have negotiated SMB3.1.1 POSIX Extensions with the server we can expect the server to support creating special files via reparse points, and even if the server fails the operation due to really forbidding creating special files, then it should be no problem and is more likely to return a more accurate rc in any case (e.g. EACCES instead of EOPNOTSUPP). Allow creating special files as long as the server supports either reparse points or the SMB3.1.1 POSIX Extensions (note that if the "sfu" mount option is specified it uses a different way of storing special files that does not rely on reparse points). Cc: <stable(a)vger.kernel.org> Fixes: 6c06be908ca19 ("cifs: Check if server supports reparse points before using them") Acked-by: Ralph Boehme <slow(a)samba.org> Acked-by: Paulo Alcantara (Red Hat) <pc(a)manguebit.org> Signed-off-by: Steve French <stfrench(a)microsoft.com> Signed-off-by: Ahmet Eray Karadag <eraykrdg1(a)gmail.com> --- fs/smb/client/smb2inode.c | 3 ++- fs/smb/client/smb2ops.c | 3 ++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/fs/smb/client/smb2inode.c b/fs/smb/client/smb2inode.c index 2a3e46b8e15a..a11a2a693c51 100644 --- a/fs/smb/client/smb2inode.c +++ b/fs/smb/client/smb2inode.c @@ -1346,7 +1346,8 @@ struct inode *smb2_get_reparse_inode(struct cifs_open_info_data *data, * empty object on the server. */ if (!(le32_to_cpu(tcon->fsAttrInfo.Attributes) & FILE_SUPPORTS_REPARSE_POINTS)) - return ERR_PTR(-EOPNOTSUPP); + if (!tcon->posix_extensions) + return ERR_PTR(-EOPNOTSUPP); oparms = CIFS_OPARMS(cifs_sb, tcon, full_path, SYNCHRONIZE | DELETE | diff --git a/fs/smb/client/smb2ops.c b/fs/smb/client/smb2ops.c index cb659256d219..938a8a7c5d21 100644 --- a/fs/smb/client/smb2ops.c +++ b/fs/smb/client/smb2ops.c @@ -5260,7 +5260,8 @@ static int smb2_make_node(unsigned int xid, struct inode *inode, if (cifs_sb->mnt_cifs_flags & CIFS_MOUNT_UNX_EMUL) { rc = cifs_sfu_make_node(xid, inode, dentry, tcon, full_path, mode, dev); - } else if (le32_to_cpu(tcon->fsAttrInfo.Attributes) & FILE_SUPPORTS_REPARSE_POINTS) { + } else if ((le32_to_cpu(tcon->fsAttrInfo.Attributes) & FILE_SUPPORTS_REPARSE_POINTS) + || (tcon->posix_extensions)) { rc = smb2_mknod_reparse(xid, inode, dentry, tcon, full_path, mode, dev); } -- 2.34.1

3 months, 2 weeks

3
2
0 0

[PATCH 1/2] nvmem: layouts: u-boot-env: remove crc32 endianness conversion

by srini＠kernel.org

From: "Michael C. Pratt" <mcpratt(a)pm.me> On 11 Oct 2022, it was reported that the crc32 verification of the u-boot environment failed only on big-endian systems for the u-boot-env nvmem layout driver with the following error. Invalid calculated CRC32: 0x88cd6f09 (expected: 0x096fcd88) This problem has been present since the driver was introduced, and before it was made into a layout driver. The suggested fix at the time was to use further endianness conversion macros in order to have both the stored and calculated crc32 values to compare always represented in the system's endianness. This was not accepted due to sparse warnings and some disagreement on how to handle the situation. Later on in a newer revision of the patch, it was proposed to use cpu_to_le32() for both values to compare instead of le32_to_cpu() and store the values as __le32 type to remove compilation errors. The necessity of this is based on the assumption that the use of crc32() requires endianness conversion because the algorithm uses little-endian, however, this does not prove to be the case and the issue is unrelated. Upon inspecting the current kernel code, there already is an existing use of le32_to_cpu() in this driver, which suggests there already is special handling for big-endian systems, however, it is big-endian systems that have the problem. This, being the only functional difference between architectures in the driver combined with the fact that the suggested fix was to use the exact same endianness conversion for the values brings up the possibility that it was not necessary to begin with, as the same endianness conversion for two values expected to be the same is expected to be equivalent to no conversion at all. After inspecting the u-boot environment of devices of both endianness and trying to remove the existing endianness conversion, the problem is resolved in an equivalent way as the other suggested fixes. Ultimately, it seems that u-boot is agnostic to endianness at least for the purpose of environment variables. In other words, u-boot reads and writes the stored crc32 value with the same endianness that the crc32 value is calculated with in whichever endianness a certain architecture runs on. Therefore, the u-boot-env driver does not need to convert endianness. Remove the usage of endianness macros in the u-boot-env driver, and change the type of local variables to maintain the same return type. If there is a special situation in the case of endianness, it would be a corner case and should be handled by a unique "compatible". Even though it is not necessary to use endianness conversion macros here, it may be useful to use them in the future for consistent error printing. Fixes: d5542923f200 ("nvmem: add driver handling U-Boot environment variables") Reported-by: INAGAKI Hiroshi <musashino.open(a)gmail.com> Link: https://lore.kernel.org/all/20221011024928.1807-1-musashino.open@gmail.com Cc: stable(a)vger.kernel.org # 6.12.x Cc: stable(a)vger.kernel.org # 6.6.x: f4cf4e5: Revert "nvmem: add new config option" Cc: stable(a)vger.kernel.org # 6.6.x: 7f38b70: of: device: Export of_device_make_bus_id() Cc: stable(a)vger.kernel.org # 6.6.x: 4a1a402: nvmem: Move of_nvmem_layout_get_container() in another header Cc: stable(a)vger.kernel.org # 6.6.x: fc29fd8: nvmem: core: Rework layouts to become regular devices Cc: stable(a)vger.kernel.org # 6.6.x: 0331c61: nvmem: core: Expose cells through sysfs Cc: stable(a)vger.kernel.org # 6.6.x: 401df0d: nvmem: layouts: refactor .add_cells() callback arguments Cc: stable(a)vger.kernel.org # 6.6.x: 6d0ca4a: nvmem: layouts: store owner from modules with nvmem_layout_driver_register() Cc: stable(a)vger.kernel.org # 6.6.x: 5f15811: nvmem: layouts: add U-Boot env layout Cc: stable(a)vger.kernel.org # 6.6.x Signed-off-by: Michael C. Pratt <mcpratt(a)pm.me> Signed-off-by: Srinivas Kandagatla <srini(a)kernel.org> --- drivers/nvmem/layouts/u-boot-env.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/nvmem/layouts/u-boot-env.c b/drivers/nvmem/layouts/u-boot-env.c index 436426d4e8f9..8571aac56295 100644 --- a/drivers/nvmem/layouts/u-boot-env.c +++ b/drivers/nvmem/layouts/u-boot-env.c @@ -92,7 +92,7 @@ int u_boot_env_parse(struct device *dev, struct nvmem_device *nvmem, size_t crc32_data_offset; size_t crc32_data_len; size_t crc32_offset; - __le32 *crc32_addr; + uint32_t *crc32_addr; size_t data_offset; size_t data_len; size_t dev_size; @@ -143,8 +143,8 @@ int u_boot_env_parse(struct device *dev, struct nvmem_device *nvmem, goto err_kfree; } - crc32_addr = (__le32 *)(buf + crc32_offset); - crc32 = le32_to_cpu(*crc32_addr); + crc32_addr = (uint32_t *)(buf + crc32_offset); + crc32 = *crc32_addr; crc32_data_len = dev_size - crc32_data_offset; data_len = dev_size - data_offset; -- 2.43.0

3 months, 2 weeks

4
6
0 0

[6.6.y] ipv6: make addrconf_wq single threaded

by Brett A C Sheffield

TL;DR - please backport dfd2ee086a63c730022cb095576a8b3a5a752109 "ipv6: make addrconf_wq single threaded" to 6.6.y (only). When testing the stable and LTS kernels this week I noticed one of our tests was failing on the 6.6.y kernels and passing on both newer and older stable kernels as well as mainline. It is not a perfect test. Running the test in a tight loop, it would occasionally fail on other kernels after thousands of iterations (6k-10k). However, on 6.6.y it usually fails on the first or second run, so I thought it was worth digging a bit. I've bisected the behaviour change back to: 86bfbb7ce4f67a88df2639198169b685668e7349 "sched/fair: Add lag based placement" The regression is later fixed by completely unrelated commit: dfd2ee086a63c730022cb095576a8b3a5a752109 "ipv6: make addrconf_wq single threaded" ie. a change to the scheduler caused the change in behaviour, and changing ipv6 addrconf to use a single-threaded workqueue seems to have "fixed" it. The original test is creating three tap interfaces, binding a socket to each and sending a packet on each. It's a simple test just to check that binding a socket to an interface works with our API. I wrote a simplified test, which just: - creates a single TAP interface, disables DAD, and brings it up - times how long before a single IPv6 packet can be sent without error These are the results for the commit (e0c2ff903c32) before the change: 2025-07-18 07:01:33-00:00 6.5.0-rc2-00017-ge0c2ff903c32 8 bytes sent after 1 tries (0.00002s) 2025-07-18 07:01:35-00:00 6.5.0-rc2-00017-ge0c2ff903c32 8 bytes sent after 1 tries (0.00002s) 2025-07-18 07:01:37-00:00 6.5.0-rc2-00017-ge0c2ff903c32 8 bytes sent after 1 tries (0.00003s) 2025-07-18 07:01:39-00:00 6.5.0-rc2-00017-ge0c2ff903c32 8 bytes sent after 1 tries (0.00002s) 2025-07-18 07:01:40-00:00 6.5.0-rc2-00017-ge0c2ff903c32 8 bytes sent after 2306 tries (0.00296s) 2025-07-18 07:01:47-00:00 6.5.0-rc2-00017-ge0c2ff903c32 8 bytes sent after 1 tries (0.00002s) 2025-07-18 07:01:49-00:00 6.5.0-rc2-00017-ge0c2ff903c32 8 bytes sent after 1 tries (0.00003s) 2025-07-18 07:01:50-00:00 6.5.0-rc2-00017-ge0c2ff903c32 8 bytes sent after 1 tries (0.00002s) 2025-07-18 07:01:52-00:00 6.5.0-rc2-00017-ge0c2ff903c32 8 bytes sent after 1 tries (0.00002s) 2025-07-18 07:01:53-00:00 6.5.0-rc2-00017-ge0c2ff903c32 8 bytes sent after 1 tries (0.00002s) 2025-07-18 07:01:59-00:00 6.5.0-rc2-00017-ge0c2ff903c32 8 bytes sent after 1 tries (0.00002s) 2025-07-18 07:02:00-00:00 6.5.0-rc2-00017-ge0c2ff903c32 8 bytes sent after 1 tries (0.00002s) 2025-07-18 07:02:01-00:00 6.5.0-rc2-00017-ge0c2ff903c32 8 bytes sent after 1 tries (0.00003s) 2025-07-18 07:05:03-00:00 6.5.0-rc2-00017-ge0c2ff903c32 8 bytes sent after 1 tries (0.00003s) 2025-07-18 07:05:05-00:00 6.5.0-rc2-00017-ge0c2ff903c32 8 bytes sent after 2042 tries (0.00266s) 2025-07-18 07:05:07-00:00 6.5.0-rc2-00017-ge0c2ff903c32 8 bytes sent after 1 tries (0.00002s) 2025-07-18 07:05:09-00:00 6.5.0-rc2-00017-ge0c2ff903c32 8 bytes sent after 1 tries (0.00002s) 2025-07-18 07:05:11-00:00 6.5.0-rc2-00017-ge0c2ff903c32 8 bytes sent after 1 tries (0.00003s) 2025-07-18 07:05:12-00:00 6.5.0-rc2-00017-ge0c2ff903c32 8 bytes sent after 1 tries (0.00004s) 2025-07-18 07:05:15-00:00 6.5.0-rc2-00017-ge0c2ff903c32 8 bytes sent after 1 tries (0.00002s) ie. sending mostly succeeds on the first attempt after TAP creation, with occasional outliers. With 86bfbb7ce4f6 applied, it's not so good: 2025-07-18 09:25:00-00:00 6.5.0-rc2-00018-g86bfbb7ce4f6 8 bytes sent after 2184 tries (0.00285s) 2025-07-18 09:25:02-00:00 6.5.0-rc2-00018-g86bfbb7ce4f6 8 bytes sent after 2597 tries (0.00336s) 2025-07-18 09:25:03-00:00 6.5.0-rc2-00018-g86bfbb7ce4f6 8 bytes sent after 2579 tries (0.00332s) 2025-07-18 09:25:05-00:00 6.5.0-rc2-00018-g86bfbb7ce4f6 8 bytes sent after 2045 tries (0.00261s) 2025-07-18 09:25:06-00:00 6.5.0-rc2-00018-g86bfbb7ce4f6 8 bytes sent after 2333 tries (0.00305s) 2025-07-18 09:25:08-00:00 6.5.0-rc2-00018-g86bfbb7ce4f6 8 bytes sent after 2847 tries (0.00355s) 2025-07-18 09:25:09-00:00 6.5.0-rc2-00018-g86bfbb7ce4f6 8 bytes sent after 2267 tries (0.00306s) 2025-07-18 09:25:11-00:00 6.5.0-rc2-00018-g86bfbb7ce4f6 8 bytes sent after 2731 tries (0.00343s) 2025-07-18 09:25:12-00:00 6.5.0-rc2-00018-g86bfbb7ce4f6 8 bytes sent after 2506 tries (0.00327s) 2025-07-18 09:25:14-00:00 6.5.0-rc2-00018-g86bfbb7ce4f6 8 bytes sent after 2554 tries (0.00338s) If we apply dfd2ee086a63 here, we see: 2025-07-18 07:06:19-00:00 6.5.0-rc2-00019-gdf3c40c549d8 8 bytes sent after 1 tries (0.00003s) 2025-07-18 07:06:22-00:00 6.5.0-rc2-00019-gdf3c40c549d8 8 bytes sent after 1 tries (0.00005s) 2025-07-18 07:06:25-00:00 6.5.0-rc2-00019-gdf3c40c549d8 8 bytes sent after 1 tries (0.00003s) 2025-07-18 07:06:27-00:00 6.5.0-rc2-00019-gdf3c40c549d8 8 bytes sent after 44 tries (0.00013s) 2025-07-18 07:06:32-00:00 6.5.0-rc2-00019-gdf3c40c549d8 8 bytes sent after 1 tries (0.00003s) 2025-07-18 07:06:34-00:00 6.5.0-rc2-00019-gdf3c40c549d8 8 bytes sent after 42 tries (0.00013s) 2025-07-18 07:06:36-00:00 6.5.0-rc2-00019-gdf3c40c549d8 8 bytes sent after 1 tries (0.00003s) 2025-07-18 07:06:39-00:00 6.5.0-rc2-00019-gdf3c40c549d8 8 bytes sent after 32 tries (0.00014s) 2025-07-18 07:06:41-00:00 6.5.0-rc2-00019-gdf3c40c549d8 8 bytes sent after 1 tries (0.00003s) 2025-07-18 07:06:43-00:00 6.5.0-rc2-00019-gdf3c40c549d8 8 bytes sent after 67 tries (0.00012s) 2025-07-18 07:06:45-00:00 6.5.0-rc2-00019-gdf3c40c549d8 8 bytes sent after 1 tries (0.00003s) 2025-07-18 07:06:47-00:00 6.5.0-rc2-00019-gdf3c40c549d8 8 bytes sent after 44 tries (0.00013s) 6.6.98: 2025-07-18 07:09:58-00:00 6.6.98 8 bytes sent after 2107 tries (0.00273s) 2025-07-18 07:10:03-00:00 6.6.98 8 bytes sent after 2597 tries (0.00350s) 2025-07-18 07:10:05-00:00 6.6.98 8 bytes sent after 1 tries (0.00002s) 2025-07-18 07:10:07-00:00 6.6.98 8 bytes sent after 1 tries (0.00003s) 2025-07-18 07:10:10-00:00 6.6.98 8 bytes sent after 2714 tries (0.00343s) 2025-07-18 07:10:12-00:00 6.6.98 8 bytes sent after 2635 tries (0.00330s) 2025-07-18 07:10:15-00:00 6.6.98 8 bytes sent after 1939 tries (0.00247s) 2025-07-18 07:10:17-00:00 6.6.98 8 bytes sent after 1 tries (0.00003s) 2025-07-18 07:10:20-00:00 6.6.98 8 bytes sent after 1 tries (0.00002s) 2025-07-18 07:10:22-00:00 6.6.98 8 bytes sent after 2688 tries (0.00343s) 2025-07-18 07:10:24-00:00 6.6.98 8 bytes sent after 2586 tries (0.00334s) 2025-07-18 07:10:26-00:00 6.6.98 8 bytes sent after 2526 tries (0.00335s) 2025-07-18 07:10:28-00:00 6.6.98 8 bytes sent after 2411 tries (0.00311s) 6.6.98 with dfd2ee086a63 applied goes back to much more consistent behaviour: 2025-07-18 08:29:52-00:00 6.6.98-00001-g9a37684fd14f 8 bytes sent after 81 tries (0.00015s) 2025-07-18 08:29:55-00:00 6.6.98-00001-g9a37684fd14f 8 bytes sent after 46 tries (0.00013s) 2025-07-18 08:29:57-00:00 6.6.98-00001-g9a37684fd14f 8 bytes sent after 54 tries (0.00012s) 2025-07-18 08:29:59-00:00 6.6.98-00001-g9a37684fd14f 8 bytes sent after 44 tries (0.00013s) 2025-07-18 08:30:00-00:00 6.6.98-00001-g9a37684fd14f 8 bytes sent after 71 tries (0.00014s) 2025-07-18 08:30:02-00:00 6.6.98-00001-g9a37684fd14f 8 bytes sent after 44 tries (0.00014s) 2025-07-18 08:30:04-00:00 6.6.98-00001-g9a37684fd14f 8 bytes sent after 73 tries (0.00013s) 2025-07-18 08:30:05-00:00 6.6.98-00001-g9a37684fd14f 8 bytes sent after 46 tries (0.00014s) 2025-07-18 08:30:07-00:00 6.6.98-00001-g9a37684fd14f 8 bytes sent after 73 tries (0.00013s) 2025-07-18 08:30:09-00:00 6.6.98-00001-g9a37684fd14f 8 bytes sent after 46 tries (0.00013s) 6.12.39: 2025-07-18 07:20:21-00:00 6.12.39 8 bytes sent after 100 tries (0.00015s) 2025-07-18 07:20:24-00:00 6.12.39 8 bytes sent after 54 tries (0.00014s) 2025-07-18 07:20:26-00:00 6.12.39 8 bytes sent after 1 tries (0.00003s) 2025-07-18 07:20:27-00:00 6.12.39 8 bytes sent after 53 tries (0.00014s) 2025-07-18 07:20:28-00:00 6.12.39 8 bytes sent after 1 tries (0.00002s) 2025-07-18 07:20:30-00:00 6.12.39 8 bytes sent after 56 tries (0.00013s) 2025-07-18 07:20:31-00:00 6.12.39 8 bytes sent after 1 tries (0.00003s) 2025-07-18 07:20:32-00:00 6.12.39 8 bytes sent after 94 tries (0.00012s) 2025-07-18 07:20:33-00:00 6.12.39 8 bytes sent after 1 tries (0.00002s) 2025-07-18 07:20:34-00:00 6.12.39 8 bytes sent after 60 tries (0.00013s) mainline: 2025-07-18 06:57:42-00:00 6.16.0-rc6 8 bytes sent after 1 tries (0.0000s) 2025-07-18 06:57:44-00:00 6.16.0-rc6 8 bytes sent after 31 tries (0.0001s) 2025-07-18 06:57:46-00:00 6.16.0-rc6 8 bytes sent after 70 tries (0.0001s) 2025-07-18 06:57:48-00:00 6.16.0-rc6 8 bytes sent after 69 tries (0.0001s) 2025-07-18 06:57:49-00:00 6.16.0-rc6 8 bytes sent after 3 tries (0.0000s) 2025-07-18 06:57:51-00:00 6.16.0-rc6 8 bytes sent after 68 tries (0.0001s) 2025-07-18 06:59:31-00:00 6.16.0-rc6 8 bytes sent after 1 tries (0.00003s) 2025-07-18 06:59:35-00:00 6.16.0-rc6 8 bytes sent after 34 tries (0.00014s) 2025-07-18 06:59:36-00:00 6.16.0-rc6 8 bytes sent after 1 tries (0.00003s) 2025-07-18 06:59:38-00:00 6.16.0-rc6 8 bytes sent after 1 tries (0.00003s) 2025-07-18 06:59:49-00:00 6.16.0-rc6 8 bytes sent after 73 tries (0.00014s) 2025-07-18 06:59:51-00:00 6.16.0-rc6 8 bytes sent after 52 tries (0.00012s) 2025-07-18 06:59:51-00:00 6.16.0-rc6 8 bytes sent after 50 tries (0.00012s) As dfd2ee086a63c730022cb095576a8b3a5a752109 is a single line change and clearly brings behaviour back in line with other kernels we should backport this to 6.6.y. Cheers, Brett

3 months, 2 weeks

2
2
0 0

Re: Patch "drm/nouveau: check ioctl command codes better" has been added to the 6.15-stable tree

by Arnd Bergmann

On Mon, Jul 21, 2025, at 14:49, Sasha Levin wrote: > This is a note to let you know that I've just added the patch titled > > drm/nouveau: check ioctl command codes better > > to the 6.15-stable tree which can be found at: > > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… > > The filename of the patch is: > drm-nouveau-check-ioctl-command-codes-better.patch > and it can be found in the queue-6.15 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, > please let <stable(a)vger.kernel.org> know about it. I got a regression report for this patch today, please don't backport it yet. Arnd

3 months, 2 weeks

2
1
0 0

FAILED: patch "[PATCH] usb: musb: fix gadget state on disconnect" 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 67a59f82196c8c4f50c83329f0577acfb1349b50 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025072132-slum-strum-0148@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 67a59f82196c8c4f50c83329f0577acfb1349b50 Mon Sep 17 00:00:00 2001 From: Drew Hamilton <drew.hamilton(a)zetier.com> Date: Tue, 1 Jul 2025 11:41:26 -0400 Subject: [PATCH] usb: musb: fix gadget state on disconnect When unplugging the USB cable or disconnecting a gadget in usb peripheral mode with echo "" > /sys/kernel/config/usb_gadget/<your_gadget>/UDC, /sys/class/udc/musb-hdrc.0/state does not change from USB_STATE_CONFIGURED. Testing on dwc2/3 shows they both update the state to USB_STATE_NOTATTACHED. Add calls to usb_gadget_set_state in musb_g_disconnect and musb_gadget_stop to fix both cases. Fixes: 49401f4169c0 ("usb: gadget: introduce gadget state tracking") Cc: stable(a)vger.kernel.org Co-authored-by: Yehowshua Immanuel <yehowshua.immanuel(a)twosixtech.com> Signed-off-by: Yehowshua Immanuel <yehowshua.immanuel(a)twosixtech.com> Signed-off-by: Drew Hamilton <drew.hamilton(a)zetier.com> Link: https://lore.kernel.org/r/20250701154126.8543-1-drew.hamilton@zetier.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c index 6869c58367f2..caf4d4cd4b75 100644 --- a/drivers/usb/musb/musb_gadget.c +++ b/drivers/usb/musb/musb_gadget.c @@ -1913,6 +1913,7 @@ static int musb_gadget_stop(struct usb_gadget *g) * gadget driver here and have everything work; * that currently misbehaves. */ + usb_gadget_set_state(g, USB_STATE_NOTATTACHED); /* Force check of devctl register for PM runtime */ pm_runtime_mark_last_busy(musb->controller); @@ -2019,6 +2020,7 @@ void musb_g_disconnect(struct musb *musb) case OTG_STATE_B_PERIPHERAL: case OTG_STATE_B_IDLE: musb_set_state(musb, OTG_STATE_B_IDLE); + usb_gadget_set_state(&musb->g, USB_STATE_NOTATTACHED); break; case OTG_STATE_B_SRP_INIT: break;

3 months, 2 weeks

2
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror