From: Greg Kroah-Hartman Date: Sat, 23 Aug 2025 16:01:15 +0000 (+0200) Subject: 5.10-stable patches X-Git-Tag: v5.4.297~56 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=a9647623f65f54186ba700160d7f132fadde1139;p=thirdparty%2Fkernel%2Fstable-queue.git 5.10-stable patches added patches: ftrace-also-allocate-and-copy-hash-for-reading-of-filter-files.patch iio-pressure-bmp280-use-is_err-in-bmp280_common_probe.patch iio-proximity-isl29501-fix-buffered-read-on-big-endian-systems.patch most-core-drop-device-reference-after-usage-in-get_channel.patch usb-dwc3-ignore-late-xfernotready-event-to-prevent-halt-timeout.patch usb-quirks-add-delay_init-quick-for-another-sandisk-3.2gen1-flash-drive.patch usb-renesas-xhci-fix-external-rom-access-timeouts.patch usb-storage-add-unusual-devs-entry-for-novatek-ntk96550-based-camera.patch usb-storage-ignore-driver-cd-mode-for-realtek-multi-mode-wi-fi-dongles.patch usb-storage-realtek_cr-use-correct-byte-order-for-bcs-residue.patch --- diff --git a/queue-5.10/ftrace-also-allocate-and-copy-hash-for-reading-of-filter-files.patch b/queue-5.10/ftrace-also-allocate-and-copy-hash-for-reading-of-filter-files.patch new file mode 100644 index 0000000000..dd81a28b81 --- /dev/null +++ b/queue-5.10/ftrace-also-allocate-and-copy-hash-for-reading-of-filter-files.patch @@ -0,0 +1,75 @@ +From bfb336cf97df7b37b2b2edec0f69773e06d11955 Mon Sep 17 00:00:00 2001 +From: Steven Rostedt +Date: Fri, 22 Aug 2025 18:36:06 -0400 +Subject: ftrace: Also allocate and copy hash for reading of filter files + +From: Steven Rostedt + +commit bfb336cf97df7b37b2b2edec0f69773e06d11955 upstream. + +Currently the reader of set_ftrace_filter and set_ftrace_notrace just adds +the pointer to the global tracer hash to its iterator. Unlike the writer +that allocates a copy of the hash, the reader keeps the pointer to the +filter hashes. This is problematic because this pointer is static across +function calls that release the locks that can update the global tracer +hashes. This can cause UAF and similar bugs. + +Allocate and copy the hash for reading the filter files like it is done +for the writers. This not only fixes UAF bugs, but also makes the code a +bit simpler as it doesn't have to differentiate when to free the +iterator's hash between writers and readers. + +Cc: stable@vger.kernel.org +Cc: Masami Hiramatsu +Cc: Mathieu Desnoyers +Cc: Nathan Chancellor +Cc: Linus Torvalds +Link: https://lore.kernel.org/20250822183606.12962cc3@batman.local.home +Fixes: c20489dad156 ("ftrace: Assign iter->hash to filter or notrace hashes on seq read") +Closes: https://lore.kernel.org/all/20250813023044.2121943-1-wutengda@huaweicloud.com/ +Closes: https://lore.kernel.org/all/20250822192437.GA458494@ax162/ +Reported-by: Tengda Wu +Tested-by: Tengda Wu +Tested-by: Nathan Chancellor +Signed-off-by: Steven Rostedt (Google) +Signed-off-by: Greg Kroah-Hartman +--- + kernel/trace/ftrace.c | 19 ++++++++++--------- + 1 file changed, 10 insertions(+), 9 deletions(-) + +--- a/kernel/trace/ftrace.c ++++ b/kernel/trace/ftrace.c +@@ -3829,13 +3829,17 @@ ftrace_regex_open(struct ftrace_ops *ops + } else { + iter->hash = alloc_and_copy_ftrace_hash(size_bits, hash); + } ++ } else { ++ if (hash) ++ iter->hash = alloc_and_copy_ftrace_hash(hash->size_bits, hash); ++ else ++ iter->hash = EMPTY_HASH; ++ } + +- if (!iter->hash) { +- trace_parser_put(&iter->parser); +- goto out_unlock; +- } +- } else +- iter->hash = hash; ++ if (!iter->hash) { ++ trace_parser_put(&iter->parser); ++ goto out_unlock; ++ } + + ret = 0; + +@@ -5707,9 +5711,6 @@ int ftrace_regex_release(struct inode *i + ret = ftrace_hash_move_and_update_ops(iter->ops, orig_hash, + iter->hash, filter_hash); + mutex_unlock(&ftrace_lock); +- } else { +- /* For read only, the hash is the ops hash */ +- iter->hash = NULL; + } + + mutex_unlock(&iter->ops->func_hash->regex_lock); diff --git a/queue-5.10/iio-pressure-bmp280-use-is_err-in-bmp280_common_probe.patch b/queue-5.10/iio-pressure-bmp280-use-is_err-in-bmp280_common_probe.patch new file mode 100644 index 0000000000..e87d793f12 --- /dev/null +++ b/queue-5.10/iio-pressure-bmp280-use-is_err-in-bmp280_common_probe.patch @@ -0,0 +1,43 @@ +From 43c0f6456f801181a80b73d95def0e0fd134e1cc Mon Sep 17 00:00:00 2001 +From: Salah Triki +Date: Mon, 18 Aug 2025 10:27:30 +0100 +Subject: iio: pressure: bmp280: Use IS_ERR() in bmp280_common_probe() + +From: Salah Triki + +commit 43c0f6456f801181a80b73d95def0e0fd134e1cc upstream. + +`devm_gpiod_get_optional()` may return non-NULL error pointer on failure. +Check its return value using `IS_ERR()` and propagate the error if +necessary. + +Fixes: df6e71256c84 ("iio: pressure: bmp280: Explicitly mark GPIO optional") +Signed-off-by: Salah Triki +Reviewed-by: David Lechner +Link: https://patch.msgid.link/20250818092740.545379-2-salah.triki@gmail.com +Cc: +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman +--- + drivers/iio/pressure/bmp280-core.c | 9 +++++---- + 1 file changed, 5 insertions(+), 4 deletions(-) + +--- a/drivers/iio/pressure/bmp280-core.c ++++ b/drivers/iio/pressure/bmp280-core.c +@@ -1064,11 +1064,12 @@ int bmp280_common_probe(struct device *d + + /* Bring chip out of reset if there is an assigned GPIO line */ + gpiod = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH); ++ if (IS_ERR(gpiod)) ++ return dev_err_probe(dev, PTR_ERR(gpiod), "failed to get reset GPIO\n"); ++ + /* Deassert the signal */ +- if (gpiod) { +- dev_info(dev, "release reset\n"); +- gpiod_set_value(gpiod, 0); +- } ++ dev_info(dev, "release reset\n"); ++ gpiod_set_value(gpiod, 0); + + data->regmap = regmap; + ret = regmap_read(regmap, BMP280_REG_ID, &chip_id); diff --git a/queue-5.10/iio-proximity-isl29501-fix-buffered-read-on-big-endian-systems.patch b/queue-5.10/iio-proximity-isl29501-fix-buffered-read-on-big-endian-systems.patch new file mode 100644 index 0000000000..7a68584f3d --- /dev/null +++ b/queue-5.10/iio-proximity-isl29501-fix-buffered-read-on-big-endian-systems.patch @@ -0,0 +1,52 @@ +From de18e978d0cda23e4c102e18092b63a5b0b3a800 Mon Sep 17 00:00:00 2001 +From: David Lechner +Date: Tue, 22 Jul 2025 15:54:21 -0500 +Subject: iio: proximity: isl29501: fix buffered read on big-endian systems + +From: David Lechner + +commit de18e978d0cda23e4c102e18092b63a5b0b3a800 upstream. + +Fix passing a u32 value as a u16 buffer scan item. This works on little- +endian systems, but not on big-endian systems. + +A new local variable is introduced for getting the register value and +the array is changed to a struct to make the data layout more explicit +rather than just changing the type and having to recalculate the proper +length needed for the timestamp. + +Fixes: 1c28799257bc ("iio: light: isl29501: Add support for the ISL29501 ToF sensor.") +Signed-off-by: David Lechner +Link: https://patch.msgid.link/20250722-iio-use-more-iio_declare_buffer_with_ts-7-v2-1-d3ebeb001ed3@baylibre.com +Cc: +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman +--- + drivers/iio/proximity/isl29501.c | 14 ++++++++++---- + 1 file changed, 10 insertions(+), 4 deletions(-) + +--- a/drivers/iio/proximity/isl29501.c ++++ b/drivers/iio/proximity/isl29501.c +@@ -938,12 +938,18 @@ static irqreturn_t isl29501_trigger_hand + struct iio_dev *indio_dev = pf->indio_dev; + struct isl29501_private *isl29501 = iio_priv(indio_dev); + const unsigned long *active_mask = indio_dev->active_scan_mask; +- u32 buffer[4] __aligned(8) = {}; /* 1x16-bit + naturally aligned ts */ ++ u32 value; ++ struct { ++ u16 data; ++ aligned_s64 ts; ++ } scan = { }; + +- if (test_bit(ISL29501_DISTANCE_SCAN_INDEX, active_mask)) +- isl29501_register_read(isl29501, REG_DISTANCE, buffer); ++ if (test_bit(ISL29501_DISTANCE_SCAN_INDEX, active_mask)) { ++ isl29501_register_read(isl29501, REG_DISTANCE, &value); ++ scan.data = value; ++ } + +- iio_push_to_buffers_with_timestamp(indio_dev, buffer, pf->timestamp); ++ iio_push_to_buffers_with_timestamp(indio_dev, &scan, pf->timestamp); + iio_trigger_notify_done(indio_dev->trig); + + return IRQ_HANDLED; diff --git a/queue-5.10/most-core-drop-device-reference-after-usage-in-get_channel.patch b/queue-5.10/most-core-drop-device-reference-after-usage-in-get_channel.patch new file mode 100644 index 0000000000..b22824fea4 --- /dev/null +++ b/queue-5.10/most-core-drop-device-reference-after-usage-in-get_channel.patch @@ -0,0 +1,34 @@ +From b47b493d6387ae437098112936f32be27f73516c Mon Sep 17 00:00:00 2001 +From: Miaoqian Lin +Date: Mon, 4 Aug 2025 12:29:55 +0400 +Subject: most: core: Drop device reference after usage in get_channel() + +From: Miaoqian Lin + +commit b47b493d6387ae437098112936f32be27f73516c upstream. + +In get_channel(), the reference obtained by bus_find_device_by_name() +was dropped via put_device() before accessing the device's driver data +Move put_device() after usage to avoid potential issues. + +Fixes: 2485055394be ("staging: most: core: drop device reference") +Cc: stable +Signed-off-by: Miaoqian Lin +Link: https://lore.kernel.org/r/20250804082955.3621026-1-linmq006@gmail.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/most/core.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/most/core.c ++++ b/drivers/most/core.c +@@ -538,8 +538,8 @@ static struct most_channel *get_channel( + dev = bus_find_device_by_name(&mostbus, NULL, mdev); + if (!dev) + return NULL; +- put_device(dev); + iface = dev_get_drvdata(dev); ++ put_device(dev); + list_for_each_entry_safe(c, tmp, &iface->p->channel_list, list) { + if (!strcmp(dev_name(&c->dev), mdev_ch)) + return c; diff --git a/queue-5.10/series b/queue-5.10/series index 1e8819a499..9d6cbb9103 100644 --- a/queue-5.10/series +++ b/queue-5.10/series @@ -402,3 +402,13 @@ fs-buffer-fix-use-after-free-when-call-bh_read-helpe.patch move_mount-allow-to-add-a-mount-into-an-existing-gro.patch use-uniform-permission-checks-for-all-mount-propagat.patch fpga-zynq_fpga-fix-the-wrong-usage-of-dma_map_sgtable.patch +ftrace-also-allocate-and-copy-hash-for-reading-of-filter-files.patch +iio-pressure-bmp280-use-is_err-in-bmp280_common_probe.patch +iio-proximity-isl29501-fix-buffered-read-on-big-endian-systems.patch +most-core-drop-device-reference-after-usage-in-get_channel.patch +usb-quirks-add-delay_init-quick-for-another-sandisk-3.2gen1-flash-drive.patch +usb-renesas-xhci-fix-external-rom-access-timeouts.patch +usb-storage-add-unusual-devs-entry-for-novatek-ntk96550-based-camera.patch +usb-storage-realtek_cr-use-correct-byte-order-for-bcs-residue.patch +usb-storage-ignore-driver-cd-mode-for-realtek-multi-mode-wi-fi-dongles.patch +usb-dwc3-ignore-late-xfernotready-event-to-prevent-halt-timeout.patch diff --git a/queue-5.10/usb-dwc3-ignore-late-xfernotready-event-to-prevent-halt-timeout.patch b/queue-5.10/usb-dwc3-ignore-late-xfernotready-event-to-prevent-halt-timeout.patch new file mode 100644 index 0000000000..f23bec3f0c --- /dev/null +++ b/queue-5.10/usb-dwc3-ignore-late-xfernotready-event-to-prevent-halt-timeout.patch @@ -0,0 +1,46 @@ +From 58577118cc7cec9eb7c1836bf88f865ff2c5e3a3 Mon Sep 17 00:00:00 2001 +From: Kuen-Han Tsai +Date: Thu, 7 Aug 2025 17:06:55 +0800 +Subject: usb: dwc3: Ignore late xferNotReady event to prevent halt timeout + +From: Kuen-Han Tsai + +commit 58577118cc7cec9eb7c1836bf88f865ff2c5e3a3 upstream. + +During a device-initiated disconnect, the End Transfer command resets +the event filter, allowing a new xferNotReady event to be generated +before the controller is fully halted. Processing this late event +incorrectly triggers a Start Transfer, which prevents the controller +from halting and results in a DSTS.DEVCTLHLT bit polling timeout. + +Ignore the late xferNotReady event if the controller is already in a +disconnected state. + +Fixes: 72246da40f37 ("usb: Introduce DesignWare USB3 DRD Driver") +Cc: stable +Signed-off-by: Kuen-Han Tsai +Acked-by: Thinh Nguyen +Link: https://lore.kernel.org/r/20250807090700.2397190-1-khtsai@google.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/dwc3/gadget.c | 9 +++++++++ + 1 file changed, 9 insertions(+) + +--- a/drivers/usb/dwc3/gadget.c ++++ b/drivers/usb/dwc3/gadget.c +@@ -3107,6 +3107,15 @@ static void dwc3_gadget_endpoint_transfe + static void dwc3_gadget_endpoint_transfer_not_ready(struct dwc3_ep *dep, + const struct dwc3_event_depevt *event) + { ++ /* ++ * During a device-initiated disconnect, a late xferNotReady event can ++ * be generated after the End Transfer command resets the event filter, ++ * but before the controller is halted. Ignore it to prevent a new ++ * transfer from starting. ++ */ ++ if (!dep->dwc->connected) ++ return; ++ + dwc3_gadget_endpoint_frame_from_event(dep, event); + + /* diff --git a/queue-5.10/usb-quirks-add-delay_init-quick-for-another-sandisk-3.2gen1-flash-drive.patch b/queue-5.10/usb-quirks-add-delay_init-quick-for-another-sandisk-3.2gen1-flash-drive.patch new file mode 100644 index 0000000000..c0803c0e97 --- /dev/null +++ b/queue-5.10/usb-quirks-add-delay_init-quick-for-another-sandisk-3.2gen1-flash-drive.patch @@ -0,0 +1,31 @@ +From e664036cf36480414936cd91f4cfa2179a3d8367 Mon Sep 17 00:00:00 2001 +From: Miao Li +Date: Fri, 1 Aug 2025 16:27:28 +0800 +Subject: usb: quirks: Add DELAY_INIT quick for another SanDisk 3.2Gen1 Flash Drive + +From: Miao Li + +commit e664036cf36480414936cd91f4cfa2179a3d8367 upstream. + +Another SanDisk 3.2Gen1 Flash Drive also need DELAY_INIT quick, +or it will randomly work incorrectly on Huawei hisi platforms +when doing reboot test. + +Signed-off-by: Miao Li +Cc: stable +Link: https://lore.kernel.org/r/20250801082728.469406-1-limiao870622@163.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/core/quirks.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/usb/core/quirks.c ++++ b/drivers/usb/core/quirks.c +@@ -368,6 +368,7 @@ static const struct usb_device_id usb_qu + { USB_DEVICE(0x0781, 0x5591), .driver_info = USB_QUIRK_NO_LPM }, + + /* SanDisk Corp. SanDisk 3.2Gen1 */ ++ { USB_DEVICE(0x0781, 0x5596), .driver_info = USB_QUIRK_DELAY_INIT }, + { USB_DEVICE(0x0781, 0x55a3), .driver_info = USB_QUIRK_DELAY_INIT }, + + /* SanDisk Extreme 55AE */ diff --git a/queue-5.10/usb-renesas-xhci-fix-external-rom-access-timeouts.patch b/queue-5.10/usb-renesas-xhci-fix-external-rom-access-timeouts.patch new file mode 100644 index 0000000000..bd771b6efb --- /dev/null +++ b/queue-5.10/usb-renesas-xhci-fix-external-rom-access-timeouts.patch @@ -0,0 +1,72 @@ +From f9420f4757752f056144896024d5ea89e5a611f1 Mon Sep 17 00:00:00 2001 +From: Marek Vasut +Date: Sun, 3 Aug 2025 00:55:20 +0200 +Subject: usb: renesas-xhci: Fix External ROM access timeouts +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Marek Vasut + +commit f9420f4757752f056144896024d5ea89e5a611f1 upstream. + +Increase the External ROM access timeouts to prevent failures during +programming of External SPI EEPROM chips. The current timeouts are +too short for some SPI EEPROMs used with uPD720201 controllers. + +The current timeout for Chip Erase in renesas_rom_erase() is 100 ms , +the current timeout for Sector Erase issued by the controller before +Page Program in renesas_fw_download_image() is also 100 ms. Neither +timeout is sufficient for e.g. the Macronix MX25L5121E or MX25V5126F. + +MX25L5121E reference manual [1] page 35 section "ERASE AND PROGRAMMING +PERFORMANCE" and page 23 section "Table 8. AC CHARACTERISTICS (Temperature += 0°C to 70°C for Commercial grade, VCC = 2.7V ~ 3.6V)" row "tCE" indicate +that the maximum time required for Chip Erase opcode to complete is 2 s, +and for Sector Erase it is 300 ms . + +MX25V5126F reference manual [2] page 47 section "13. ERASE AND PROGRAMMING +PERFORMANCE (2.3V - 3.6V)" and page 42 section "Table 8. AC CHARACTERISTICS +(Temperature = -40°C to 85°C for Industrial grade, VCC = 2.3V - 3.6V)" row +"tCE" indicate that the maximum time required for Chip Erase opcode to +complete is 3.2 s, and for Sector Erase it is 400 ms . + +Update the timeouts such, that Chip Erase timeout is set to 5 seconds, +and Sector Erase timeout is set to 500 ms. Such lengthy timeouts ought +to be sufficient for majority of SPI EEPROM chips. + +[1] https://www.macronix.com/Lists/Datasheet/Attachments/8634/MX25L5121E,%203V,%20512Kb,%20v1.3.pdf +[2] https://www.macronix.com/Lists/Datasheet/Attachments/8750/MX25V5126F,%202.5V,%20512Kb,%20v1.1.pdf + +Fixes: 2478be82de44 ("usb: renesas-xhci: Add ROM loader for uPD720201") +Cc: stable +Signed-off-by: Marek Vasut +Link: https://lore.kernel.org/r/20250802225526.25431-1-marek.vasut+renesas@mailbox.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/host/xhci-pci-renesas.c | 7 ++++--- + 1 file changed, 4 insertions(+), 3 deletions(-) + +--- a/drivers/usb/host/xhci-pci-renesas.c ++++ b/drivers/usb/host/xhci-pci-renesas.c +@@ -47,8 +47,9 @@ + #define RENESAS_ROM_ERASE_MAGIC 0x5A65726F + #define RENESAS_ROM_WRITE_MAGIC 0x53524F4D + +-#define RENESAS_RETRY 10000 +-#define RENESAS_DELAY 10 ++#define RENESAS_RETRY 50000 /* 50000 * RENESAS_DELAY ~= 500ms */ ++#define RENESAS_CHIP_ERASE_RETRY 500000 /* 500000 * RENESAS_DELAY ~= 5s */ ++#define RENESAS_DELAY 10 + + static int renesas_fw_download_image(struct pci_dev *dev, + const u32 *fw, size_t step, bool rom) +@@ -409,7 +410,7 @@ static void renesas_rom_erase(struct pci + /* sleep a bit while ROM is erased */ + msleep(20); + +- for (i = 0; i < RENESAS_RETRY; i++) { ++ for (i = 0; i < RENESAS_CHIP_ERASE_RETRY; i++) { + retval = pci_read_config_byte(pdev, RENESAS_ROM_STATUS, + &status); + status &= RENESAS_ROM_STATUS_ERASE; diff --git a/queue-5.10/usb-storage-add-unusual-devs-entry-for-novatek-ntk96550-based-camera.patch b/queue-5.10/usb-storage-add-unusual-devs-entry-for-novatek-ntk96550-based-camera.patch new file mode 100644 index 0000000000..24e43b2cf0 --- /dev/null +++ b/queue-5.10/usb-storage-add-unusual-devs-entry-for-novatek-ntk96550-based-camera.patch @@ -0,0 +1,54 @@ +From 6ca8af3c8fb584f3424a827f554ff74f898c27cd Mon Sep 17 00:00:00 2001 +From: Mael GUERIN +Date: Wed, 6 Aug 2025 18:44:03 +0200 +Subject: USB: storage: Add unusual-devs entry for Novatek NTK96550-based camera + +From: Mael GUERIN + +commit 6ca8af3c8fb584f3424a827f554ff74f898c27cd upstream. + +Add the US_FL_BULK_IGNORE_TAG quirk for Novatek NTK96550-based camera +to fix USB resets after sending SCSI vendor commands due to CBW and +CSW tags difference, leading to undesired slowness while communicating +with the device. + +Please find below the copy of /sys/kernel/debug/usb/devices with my +device plugged in (listed as TechSys USB mass storage here, the +underlying chipset being the Novatek NTK96550-based camera): + +T: Bus=03 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 3 Spd=480 MxCh= 0 +D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 +P: Vendor=0603 ProdID=8611 Rev= 0.01 +S: Manufacturer=TechSys +S: Product=USB Mass Storage +S: SerialNumber=966110000000100 +C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=100mA +I:* If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage +E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms +E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms + +Signed-off-by: Mael GUERIN +Cc: stable +Acked-by: Alan Stern +Link: https://lore.kernel.org/r/20250806164406.43450-1-mael.guerin@murena.io +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/storage/unusual_devs.h | 7 +++++++ + 1 file changed, 7 insertions(+) + +--- a/drivers/usb/storage/unusual_devs.h ++++ b/drivers/usb/storage/unusual_devs.h +@@ -934,6 +934,13 @@ UNUSUAL_DEV( 0x05e3, 0x0723, 0x9451, 0x + USB_SC_DEVICE, USB_PR_DEVICE, NULL, + US_FL_SANE_SENSE ), + ++/* Added by Maël GUERIN */ ++UNUSUAL_DEV( 0x0603, 0x8611, 0x0000, 0xffff, ++ "Novatek", ++ "NTK96550-based camera", ++ USB_SC_SCSI, USB_PR_BULK, NULL, ++ US_FL_BULK_IGNORE_TAG ), ++ + /* + * Reported by Hanno Boeck + * Taken from the Lycoris Kernel diff --git a/queue-5.10/usb-storage-ignore-driver-cd-mode-for-realtek-multi-mode-wi-fi-dongles.patch b/queue-5.10/usb-storage-ignore-driver-cd-mode-for-realtek-multi-mode-wi-fi-dongles.patch new file mode 100644 index 0000000000..4559e2cd05 --- /dev/null +++ b/queue-5.10/usb-storage-ignore-driver-cd-mode-for-realtek-multi-mode-wi-fi-dongles.patch @@ -0,0 +1,79 @@ +From a3dc32c635bae0ae569f489e00de0e8f015bfc25 Mon Sep 17 00:00:00 2001 +From: Zenm Chen +Date: Thu, 14 Aug 2025 00:24:15 +0800 +Subject: USB: storage: Ignore driver CD mode for Realtek multi-mode Wi-Fi dongles + +From: Zenm Chen + +commit a3dc32c635bae0ae569f489e00de0e8f015bfc25 upstream. + +Many Realtek USB Wi-Fi dongles released in recent years have two modes: +one is driver CD mode which has Windows driver onboard, another one is +Wi-Fi mode. Add the US_FL_IGNORE_DEVICE quirk for these multi-mode devices. +Otherwise, usb_modeswitch may fail to switch them to Wi-Fi mode. + +Currently there are only two USB IDs known to be used by these multi-mode +Wi-Fi dongles: 0bda:1a2b and 0bda:a192. + +Information about Mercury MW310UH in /sys/kernel/debug/usb/devices. +T: Bus=02 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 12 Spd=480 MxCh= 0 +D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 +P: Vendor=0bda ProdID=a192 Rev= 2.00 +S: Manufacturer=Realtek +S: Product=DISK +C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=500mA +I:* If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=(none) +E: Ad=8a(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms +E: Ad=0b(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms + +Information about D-Link AX9U rev. A1 in /sys/kernel/debug/usb/devices. +T: Bus=03 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#= 55 Spd=480 MxCh= 0 +D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 +P: Vendor=0bda ProdID=1a2b Rev= 0.00 +S: Manufacturer=Realtek +S: Product=DISK +C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=500mA +I:* If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=(none) +E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms +E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms + +Cc: stable +Signed-off-by: Zenm Chen +Acked-by: Alan Stern +Link: https://lore.kernel.org/r/20250813162415.2630-1-zenmchen@gmail.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/storage/unusual_devs.h | 22 ++++++++++++++++++++++ + 1 file changed, 22 insertions(+) + +--- a/drivers/usb/storage/unusual_devs.h ++++ b/drivers/usb/storage/unusual_devs.h +@@ -1490,6 +1490,28 @@ UNUSUAL_DEV( 0x0bc2, 0x3332, 0x0000, 0x9 + USB_SC_DEVICE, USB_PR_DEVICE, NULL, + US_FL_NO_WP_DETECT ), + ++/* ++ * Reported by Zenm Chen ++ * Ignore driver CD mode, otherwise usb_modeswitch may fail to switch ++ * the device into Wi-Fi mode. ++ */ ++UNUSUAL_DEV( 0x0bda, 0x1a2b, 0x0000, 0xffff, ++ "Realtek", ++ "DISK", ++ USB_SC_DEVICE, USB_PR_DEVICE, NULL, ++ US_FL_IGNORE_DEVICE ), ++ ++/* ++ * Reported by Zenm Chen ++ * Ignore driver CD mode, otherwise usb_modeswitch may fail to switch ++ * the device into Wi-Fi mode. ++ */ ++UNUSUAL_DEV( 0x0bda, 0xa192, 0x0000, 0xffff, ++ "Realtek", ++ "DISK", ++ USB_SC_DEVICE, USB_PR_DEVICE, NULL, ++ US_FL_IGNORE_DEVICE ), ++ + UNUSUAL_DEV( 0x0d49, 0x7310, 0x0000, 0x9999, + "Maxtor", + "USB to SATA", diff --git a/queue-5.10/usb-storage-realtek_cr-use-correct-byte-order-for-bcs-residue.patch b/queue-5.10/usb-storage-realtek_cr-use-correct-byte-order-for-bcs-residue.patch new file mode 100644 index 0000000000..61442e8032 --- /dev/null +++ b/queue-5.10/usb-storage-realtek_cr-use-correct-byte-order-for-bcs-residue.patch @@ -0,0 +1,35 @@ +From 98da66a70ad2396e5a508c4245367797ebc052ce Mon Sep 17 00:00:00 2001 +From: Thorsten Blum +Date: Wed, 13 Aug 2025 16:52:49 +0200 +Subject: usb: storage: realtek_cr: Use correct byte order for bcs->Residue + +From: Thorsten Blum + +commit 98da66a70ad2396e5a508c4245367797ebc052ce upstream. + +Since 'bcs->Residue' has the data type '__le32', convert it to the +correct byte order of the CPU using this driver when assigning it to +the local variable 'residue'. + +Cc: stable +Fixes: 50a6cb932d5c ("USB: usb_storage: add ums-realtek driver") +Suggested-by: Alan Stern +Acked-by: Alan Stern +Signed-off-by: Thorsten Blum +Link: https://lore.kernel.org/r/20250813145247.184717-3-thorsten.blum@linux.dev +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/storage/realtek_cr.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/usb/storage/realtek_cr.c ++++ b/drivers/usb/storage/realtek_cr.c +@@ -252,7 +252,7 @@ static int rts51x_bulk_transport(struct + return USB_STOR_TRANSPORT_ERROR; + } + +- residue = bcs->Residue; ++ residue = le32_to_cpu(bcs->Residue); + if (bcs->Tag != us->tag) + return USB_STOR_TRANSPORT_ERROR; +