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
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
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
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;
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 67a59f82196c8c4f50c83329f0577acfb1349b50
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025072132-fiscally-rearrange-1853@gregkh' --subject-prefix 'PATCH 5.10.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;
The patch below does not apply to the 6.1-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.1.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 '2025072131-crushing-unsworn-a3b0@gregkh' --subject-prefix 'PATCH 6.1.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;
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 67a59f82196c8c4f50c83329f0577acfb1349b50
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025072131-trailing-chaos-96f3@gregkh' --subject-prefix 'PATCH 6.6.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;
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 1fe16dc1a2f5057772e5391ec042ed7442966c9a
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025072125-spyglass-uncharted-ba31@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^..
Possible dependencies:
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 1fe16dc1a2f5057772e5391ec042ed7442966c9a Mon Sep 17 00:00:00 2001
From: Sean Nyekjaer <sean(a)geanix.com>
Date: Tue, 3 Jun 2025 14:25:44 +0200
Subject: [PATCH] iio: accel: fxls8962af: Fix use after free in
fxls8962af_fifo_flush
fxls8962af_fifo_flush() uses indio_dev->active_scan_mask (with
iio_for_each_active_channel()) without making sure the indio_dev
stays in buffer mode.
There is a race if indio_dev exits buffer mode in the middle of the
interrupt that flushes the fifo. Fix this by calling
synchronize_irq() to ensure that no interrupt is currently running when
disabling buffer mode.
Unable to handle kernel NULL pointer dereference at virtual address 00000000 when read
[...]
_find_first_bit_le from fxls8962af_fifo_flush+0x17c/0x290
fxls8962af_fifo_flush from fxls8962af_interrupt+0x80/0x178
fxls8962af_interrupt from irq_thread_fn+0x1c/0x7c
irq_thread_fn from irq_thread+0x110/0x1f4
irq_thread from kthread+0xe0/0xfc
kthread from ret_from_fork+0x14/0x2c
Fixes: 79e3a5bdd9ef ("iio: accel: fxls8962af: add hw buffered sampling")
Cc: stable(a)vger.kernel.org
Suggested-by: David Lechner <dlechner(a)baylibre.com>
Signed-off-by: Sean Nyekjaer <sean(a)geanix.com>
Link: https://patch.msgid.link/20250603-fxlsrace-v2-1-5381b36ba1db@geanix.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com>
diff --git a/drivers/iio/accel/fxls8962af-core.c b/drivers/iio/accel/fxls8962af-core.c
index 12598feaa693..b10a30960e1e 100644
--- a/drivers/iio/accel/fxls8962af-core.c
+++ b/drivers/iio/accel/fxls8962af-core.c
@@ -877,6 +877,8 @@ static int fxls8962af_buffer_predisable(struct iio_dev *indio_dev)
if (ret)
return ret;
+ synchronize_irq(data->irq);
+
ret = __fxls8962af_fifo_set_mode(data, false);
if (data->enable_event)
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 da9b2fc7b73d147d88abe1922de5ab72d72d7756
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025072124-runny-sublevel-69e9@gregkh' --subject-prefix 'PATCH 6.6.y' HEAD^..
Possible dependencies:
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From da9b2fc7b73d147d88abe1922de5ab72d72d7756 Mon Sep 17 00:00:00 2001
From: Paolo Abeni <pabeni(a)redhat.com>
Date: Mon, 14 Jul 2025 18:41:46 +0200
Subject: [PATCH] mptcp: reset fallback status gracefully at disconnect() time
mptcp_disconnect() clears the fallback bit unconditionally, without
touching the associated flags.
The bit clear is safe, as no fallback operation can race with that --
all subflow are already in TCP_CLOSE status thanks to the previous
FASTCLOSE -- but we need to consistently reset all the fallback related
status.
Also acquire the relevant lock, to avoid fouling static analyzers.
Fixes: b29fcfb54cd7 ("mptcp: full disconnect implementation")
Cc: stable(a)vger.kernel.org
Signed-off-by: Paolo Abeni <pabeni(a)redhat.com>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org>
Link: https://patch.msgid.link/20250714-net-mptcp-fallback-races-v1-3-391aff96332…
Signed-off-by: Jakub Kicinski <kuba(a)kernel.org>
diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
index bf92cee9b5ce..6a817a13b154 100644
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -3142,7 +3142,16 @@ static int mptcp_disconnect(struct sock *sk, int flags)
* subflow
*/
mptcp_destroy_common(msk, MPTCP_CF_FASTCLOSE);
+
+ /* The first subflow is already in TCP_CLOSE status, the following
+ * can't overlap with a fallback anymore
+ */
+ spin_lock_bh(&msk->fallback_lock);
+ msk->allow_subflows = true;
+ msk->allow_infinite_fallback = true;
WRITE_ONCE(msk->flags, 0);
+ spin_unlock_bh(&msk->fallback_lock);
+
msk->cb_flags = 0;
msk->recovery = false;
WRITE_ONCE(msk->can_ack, false);