From: Greg Kroah-Hartman Date: Tue, 7 Apr 2026 15:19:38 +0000 (+0200) Subject: 5.15-stable patches X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=c4fe4aa9679ad7cac71487cf824738ac054c09f5;p=thirdparty%2Fkernel%2Fstable-queue.git 5.15-stable patches added patches: alsa-caiaq-fix-stack-out-of-bounds-read-in-init_card.patch alsa-ctxfi-fix-missing-spdifi1-index-handling.patch bluetooth-smp-derive-legacy-responder-stk-authentication-from-mitm-state.patch bluetooth-smp-force-responder-mitm-requirements-before-building-the-pairing-response.patch drm-ast-dp501-fix-initialization-of-scu2c.patch hwmon-occ-fix-division-by-zero-in-occ_show_power_1.patch iommu-do-not-call-drivers-for-empty-gathers.patch mips-fix-the-gcc-version-check-for-__multi3-workaround.patch usb-core-add-no_lpm-quirk-for-razer-kiyo-pro-webcam.patch usb-serial-io_edgeport-add-support-for-blackbox-ic135a.patch usb-serial-option-add-meig-smart-srm825wn.patch usb-serial-option-add-support-for-rolling-wireless-rw135r-gl.patch --- diff --git a/queue-5.15/alsa-caiaq-fix-stack-out-of-bounds-read-in-init_card.patch b/queue-5.15/alsa-caiaq-fix-stack-out-of-bounds-read-in-init_card.patch new file mode 100644 index 0000000000..363a3648e0 --- /dev/null +++ b/queue-5.15/alsa-caiaq-fix-stack-out-of-bounds-read-in-init_card.patch @@ -0,0 +1,59 @@ +From 45424e871abf2a152e247a9cff78359f18dd95c0 Mon Sep 17 00:00:00 2001 +From: Berk Cem Goksel +Date: Sun, 29 Mar 2026 16:38:25 +0300 +Subject: ALSA: caiaq: fix stack out-of-bounds read in init_card + +From: Berk Cem Goksel + +commit 45424e871abf2a152e247a9cff78359f18dd95c0 upstream. + +The loop creates a whitespace-stripped copy of the card shortname +where `len < sizeof(card->id)` is used for the bounds check. Since +sizeof(card->id) is 16 and the local id buffer is also 16 bytes, +writing 16 non-space characters fills the entire buffer, +overwriting the terminating nullbyte. + +When this non-null-terminated string is later passed to +snd_card_set_id() -> copy_valid_id_string(), the function scans +forward with `while (*nid && ...)` and reads past the end of the +stack buffer, reading the contents of the stack. + +A USB device with a product name containing many non-ASCII, non-space +characters (e.g. multibyte UTF-8) will reliably trigger this as follows: + + BUG: KASAN: stack-out-of-bounds in copy_valid_id_string + sound/core/init.c:696 [inline] + BUG: KASAN: stack-out-of-bounds in snd_card_set_id_no_lock+0x698/0x74c + sound/core/init.c:718 + +The off-by-one has been present since commit bafeee5b1f8d ("ALSA: +snd_usb_caiaq: give better shortname") from June 2009 (v2.6.31-rc1), +which first introduced this whitespace-stripping loop. The original +code never accounted for the null terminator when bounding the copy. + +Fix this by changing the loop bound to `sizeof(card->id) - 1`, +ensuring at least one byte remains as the null terminator. + +Fixes: bafeee5b1f8d ("ALSA: snd_usb_caiaq: give better shortname") +Cc: stable@vger.kernel.org +Cc: Andrey Konovalov +Reported-by: Berk Cem Goksel +Signed-off-by: Berk Cem Goksel +Link: https://patch.msgid.link/20260329133825.581585-1-berkcgoksel@gmail.com +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + sound/usb/caiaq/device.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/sound/usb/caiaq/device.c ++++ b/sound/usb/caiaq/device.c +@@ -488,7 +488,7 @@ static int init_card(struct snd_usb_caia + memset(id, 0, sizeof(id)); + + for (c = card->shortname, len = 0; +- *c && len < sizeof(card->id); c++) ++ *c && len < sizeof(card->id) - 1; c++) + if (*c != ' ') + id[len++] = *c; + diff --git a/queue-5.15/alsa-ctxfi-fix-missing-spdifi1-index-handling.patch b/queue-5.15/alsa-ctxfi-fix-missing-spdifi1-index-handling.patch new file mode 100644 index 0000000000..1d5ff39307 --- /dev/null +++ b/queue-5.15/alsa-ctxfi-fix-missing-spdifi1-index-handling.patch @@ -0,0 +1,34 @@ +From b045ab3dff97edae6d538eeff900a34c098761f8 Mon Sep 17 00:00:00 2001 +From: Takashi Iwai +Date: Sun, 29 Mar 2026 11:12:37 +0200 +Subject: ALSA: ctxfi: Fix missing SPDIFI1 index handling + +From: Takashi Iwai + +commit b045ab3dff97edae6d538eeff900a34c098761f8 upstream. + +SPDIF1 DAIO type isn't properly handled in daio_device_index() for +hw20k2, and it returned -EINVAL, which ended up with the out-of-bounds +array access. Follow the hw20k1 pattern and return the proper index +for this type, too. + +Reported-and-tested-by: Karsten Hohmeier +Closes: https://lore.kernel.org/20260315155004.15633-1-linux@hohmatik.de +Cc: +Link: https://patch.msgid.link/20260329091240.420194-1-tiwai@suse.de +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + sound/pci/ctxfi/ctdaio.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/sound/pci/ctxfi/ctdaio.c ++++ b/sound/pci/ctxfi/ctdaio.c +@@ -119,6 +119,7 @@ static unsigned int daio_device_index(en + switch (type) { + case SPDIFOO: return 0; + case SPDIFIO: return 0; ++ case SPDIFI1: return 1; + case LINEO1: return 4; + case LINEO2: return 7; + case LINEO3: return 5; diff --git a/queue-5.15/bluetooth-smp-derive-legacy-responder-stk-authentication-from-mitm-state.patch b/queue-5.15/bluetooth-smp-derive-legacy-responder-stk-authentication-from-mitm-state.patch new file mode 100644 index 0000000000..56550f971e --- /dev/null +++ b/queue-5.15/bluetooth-smp-derive-legacy-responder-stk-authentication-from-mitm-state.patch @@ -0,0 +1,45 @@ +From 20756fec2f0108cb88e815941f1ffff88dc286fe Mon Sep 17 00:00:00 2001 +From: Oleh Konko +Date: Tue, 31 Mar 2026 11:52:13 +0000 +Subject: Bluetooth: SMP: derive legacy responder STK authentication from MITM state + +From: Oleh Konko + +commit 20756fec2f0108cb88e815941f1ffff88dc286fe upstream. + +The legacy responder path in smp_random() currently labels the stored +STK as authenticated whenever pending_sec_level is BT_SECURITY_HIGH. +That reflects what the local service requested, not what the pairing +flow actually achieved. + +For Just Works/Confirm legacy pairing, SMP_FLAG_MITM_AUTH stays clear +and the resulting STK should remain unauthenticated even if the local +side requested HIGH security. Use the established MITM state when +storing the responder STK so the key metadata matches the pairing result. + +This also keeps the legacy path aligned with the Secure Connections code, +which already treats JUST_WORKS/JUST_CFM as unauthenticated. + +Fixes: fff3490f4781 ("Bluetooth: Fix setting correct authentication information for SMP STK") +Cc: stable@vger.kernel.org +Signed-off-by: Oleh Konko +Signed-off-by: Luiz Augusto von Dentz +Signed-off-by: Greg Kroah-Hartman +--- + net/bluetooth/smp.c | 5 +---- + 1 file changed, 1 insertion(+), 4 deletions(-) + +--- a/net/bluetooth/smp.c ++++ b/net/bluetooth/smp.c +@@ -1017,10 +1017,7 @@ static u8 smp_random(struct smp_chan *sm + + smp_s1(smp->tk, smp->prnd, smp->rrnd, stk); + +- if (hcon->pending_sec_level == BT_SECURITY_HIGH) +- auth = 1; +- else +- auth = 0; ++ auth = test_bit(SMP_FLAG_MITM_AUTH, &smp->flags) ? 1 : 0; + + /* Even though there's no _RESPONDER suffix this is the + * responder STK we're adding for later lookup (the initiator diff --git a/queue-5.15/bluetooth-smp-force-responder-mitm-requirements-before-building-the-pairing-response.patch b/queue-5.15/bluetooth-smp-force-responder-mitm-requirements-before-building-the-pairing-response.patch new file mode 100644 index 0000000000..ce204ddc6b --- /dev/null +++ b/queue-5.15/bluetooth-smp-force-responder-mitm-requirements-before-building-the-pairing-response.patch @@ -0,0 +1,55 @@ +From d05111bfe37bfd8bd4d2dfe6675d6bdeef43f7c7 Mon Sep 17 00:00:00 2001 +From: Oleh Konko +Date: Tue, 31 Mar 2026 11:52:12 +0000 +Subject: Bluetooth: SMP: force responder MITM requirements before building the pairing response + +From: Oleh Konko + +commit d05111bfe37bfd8bd4d2dfe6675d6bdeef43f7c7 upstream. + +smp_cmd_pairing_req() currently builds the pairing response from the +initiator auth_req before enforcing the local BT_SECURITY_HIGH +requirement. If the initiator omits SMP_AUTH_MITM, the response can +also omit it even though the local side still requires MITM. + +tk_request() then sees an auth value without SMP_AUTH_MITM and may +select JUST_CFM, making method selection inconsistent with the pairing +policy the responder already enforces. + +When the local side requires HIGH security, first verify that MITM can +be achieved from the IO capabilities and then force SMP_AUTH_MITM in the +response in both rsp.auth_req and auth. This keeps the responder auth bits +and later method selection aligned. + +Fixes: 2b64d153a0cc ("Bluetooth: Add MITM mechanism to LE-SMP") +Cc: stable@vger.kernel.org +Suggested-by: Luiz Augusto von Dentz +Signed-off-by: Oleh Konko +Signed-off-by: Luiz Augusto von Dentz +Signed-off-by: Greg Kroah-Hartman +--- + net/bluetooth/smp.c | 6 +++++- + 1 file changed, 5 insertions(+), 1 deletion(-) + +--- a/net/bluetooth/smp.c ++++ b/net/bluetooth/smp.c +@@ -1817,7 +1817,7 @@ static u8 smp_cmd_pairing_req(struct l2c + if (sec_level > conn->hcon->pending_sec_level) + conn->hcon->pending_sec_level = sec_level; + +- /* If we need MITM check that it can be achieved */ ++ /* If we need MITM check that it can be achieved. */ + if (conn->hcon->pending_sec_level >= BT_SECURITY_HIGH) { + u8 method; + +@@ -1825,6 +1825,10 @@ static u8 smp_cmd_pairing_req(struct l2c + req->io_capability); + if (method == JUST_WORKS || method == JUST_CFM) + return SMP_AUTH_REQUIREMENTS; ++ ++ /* Force MITM bit if it isn't set by the initiator. */ ++ auth |= SMP_AUTH_MITM; ++ rsp.auth_req |= SMP_AUTH_MITM; + } + + key_size = min(req->max_key_size, rsp.max_key_size); diff --git a/queue-5.15/drm-ast-dp501-fix-initialization-of-scu2c.patch b/queue-5.15/drm-ast-dp501-fix-initialization-of-scu2c.patch new file mode 100644 index 0000000000..35d0c66e1b --- /dev/null +++ b/queue-5.15/drm-ast-dp501-fix-initialization-of-scu2c.patch @@ -0,0 +1,41 @@ +From 2f42c1a6161646cbd29b443459fd635d29eda634 Mon Sep 17 00:00:00 2001 +From: Thomas Zimmermann +Date: Fri, 27 Mar 2026 14:32:53 +0100 +Subject: drm/ast: dp501: Fix initialization of SCU2C + +From: Thomas Zimmermann + +commit 2f42c1a6161646cbd29b443459fd635d29eda634 upstream. + +Ast's DP501 initialization reads the register SCU2C at offset 0x1202c +and tries to set it to source data from VGA. But writes the update to +offset 0x0, with unknown results. Write the result to SCU instead. + +The bug only happens in ast_init_analog(). There's similar code in +ast_init_dvo(), which works correctly. + +Signed-off-by: Thomas Zimmermann +Fixes: 83c6620bae3f ("drm/ast: initial DP501 support (v0.2)") +Reviewed-by: Jocelyn Falempe +Cc: Dave Airlie +Cc: Thomas Zimmermann +Cc: Jocelyn Falempe +Cc: dri-devel@lists.freedesktop.org +Cc: # v3.16+ +Link: https://patch.msgid.link/20260327133532.79696-2-tzimmermann@suse.de +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/ast/ast_dp501.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/gpu/drm/ast/ast_dp501.c ++++ b/drivers/gpu/drm/ast/ast_dp501.c +@@ -484,7 +484,7 @@ static void ast_init_analog(struct drm_d + /* Finally, clear bits [17:16] of SCU2c */ + data = ast_read32(ast, 0x1202c); + data &= 0xfffcffff; +- ast_write32(ast, 0, data); ++ ast_write32(ast, 0x1202c, data); + + /* Disable DVO */ + ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xa3, 0xcf, 0x00); diff --git a/queue-5.15/hwmon-occ-fix-division-by-zero-in-occ_show_power_1.patch b/queue-5.15/hwmon-occ-fix-division-by-zero-in-occ_show_power_1.patch new file mode 100644 index 0000000000..e3be3d9d97 --- /dev/null +++ b/queue-5.15/hwmon-occ-fix-division-by-zero-in-occ_show_power_1.patch @@ -0,0 +1,76 @@ +From 39e2a5bf970402a8530a319cf06122e216ba57b8 Mon Sep 17 00:00:00 2001 +From: Sanman Pradhan +Date: Thu, 26 Mar 2026 22:45:23 +0000 +Subject: hwmon: (occ) Fix division by zero in occ_show_power_1() + +From: Sanman Pradhan + +commit 39e2a5bf970402a8530a319cf06122e216ba57b8 upstream. + +In occ_show_power_1() case 1, the accumulator is divided by +update_tag without checking for zero. If no samples have been +collected yet (e.g. during early boot when the sensor block is +included but hasn't been updated), update_tag is zero, causing +a kernel divide-by-zero crash. + +The 2019 fix in commit 211186cae14d ("hwmon: (occ) Fix division by +zero issue") only addressed occ_get_powr_avg() used by +occ_show_power_2() and occ_show_power_a0(). This separate code +path in occ_show_power_1() was missed. + +Fix this by reusing the existing occ_get_powr_avg() helper, which +already handles the zero-sample case and uses mul_u64_u32_div() +to multiply before dividing for better precision. Move the helper +above occ_show_power_1() so it is visible at the call site. + +Fixes: c10e753d43eb ("hwmon (occ): Add sensor types and versions") +Cc: stable@vger.kernel.org +Signed-off-by: Sanman Pradhan +Link: https://lore.kernel.org/r/20260326224510.294619-2-sanman.pradhan@hpe.com +[groeck: Fix alignment problems reported by checkpatch] +Signed-off-by: Guenter Roeck +Signed-off-by: Greg Kroah-Hartman +--- + drivers/hwmon/occ/common.c | 17 ++++++++--------- + 1 file changed, 8 insertions(+), 9 deletions(-) + +--- a/drivers/hwmon/occ/common.c ++++ b/drivers/hwmon/occ/common.c +@@ -419,6 +419,12 @@ static ssize_t occ_show_freq_2(struct de + return sysfs_emit(buf, "%u\n", val); + } + ++static u64 occ_get_powr_avg(u64 accum, u32 samples) ++{ ++ return (samples == 0) ? 0 : ++ mul_u64_u32_div(accum, 1000000UL, samples); ++} ++ + static ssize_t occ_show_power_1(struct device *dev, + struct device_attribute *attr, char *buf) + { +@@ -440,9 +446,8 @@ static ssize_t occ_show_power_1(struct d + val = get_unaligned_be16(&power->sensor_id); + break; + case 1: +- val = get_unaligned_be32(&power->accumulator) / +- get_unaligned_be32(&power->update_tag); +- val *= 1000000ULL; ++ val = occ_get_powr_avg(get_unaligned_be32(&power->accumulator), ++ get_unaligned_be32(&power->update_tag)); + break; + case 2: + val = (u64)get_unaligned_be32(&power->update_tag) * +@@ -458,12 +463,6 @@ static ssize_t occ_show_power_1(struct d + return sysfs_emit(buf, "%llu\n", val); + } + +-static u64 occ_get_powr_avg(u64 accum, u32 samples) +-{ +- return (samples == 0) ? 0 : +- mul_u64_u32_div(accum, 1000000UL, samples); +-} +- + static ssize_t occ_show_power_2(struct device *dev, + struct device_attribute *attr, char *buf) + { diff --git a/queue-5.15/iommu-do-not-call-drivers-for-empty-gathers.patch b/queue-5.15/iommu-do-not-call-drivers-for-empty-gathers.patch new file mode 100644 index 0000000000..96e8d093fe --- /dev/null +++ b/queue-5.15/iommu-do-not-call-drivers-for-empty-gathers.patch @@ -0,0 +1,54 @@ +From 90c5def10bea574b101b7a520c015ca81742183f Mon Sep 17 00:00:00 2001 +From: Jason Gunthorpe +Date: Mon, 2 Mar 2026 18:22:52 -0400 +Subject: iommu: Do not call drivers for empty gathers + +From: Jason Gunthorpe + +commit 90c5def10bea574b101b7a520c015ca81742183f upstream. + +An empty gather is coded with start=U64_MAX, end=0 and several drivers go +on to convert that to a size with: + + end - start + 1 + +Which gives 2 for an empty gather. This then causes Weird Stuff to +happen (for example an UBSAN splat in VT-d) that is hopefully harmless, +but maybe not. + +Prevent drivers from being called right in iommu_iotlb_sync(). + +Auditing shows that AMD, Intel, Mediatek and RSIC-V drivers all do things +on these empty gathers. + +Further, there are several callers that can trigger empty gathers, +especially in unusual conditions. For example iommu_map_nosync() will call +a 0 size unmap on some error paths. Also in VFIO, iommupt and other +places. + +Cc: stable@vger.kernel.org +Reported-by: Janusz Krzysztofik +Closes: https://lore.kernel.org/r/11145826.aFP6jjVeTY@jkrzyszt-mobl2.ger.corp.intel.com +Signed-off-by: Jason Gunthorpe +Reviewed-by: Lu Baolu +Reviewed-by: Samiullah Khawaja +Reviewed-by: Robin Murphy +Reviewed-by: Vasant Hegde +Signed-off-by: Joerg Roedel +Signed-off-by: Greg Kroah-Hartman +--- + include/linux/iommu.h | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/include/linux/iommu.h ++++ b/include/linux/iommu.h +@@ -517,7 +517,8 @@ static inline void iommu_flush_iotlb_all + static inline void iommu_iotlb_sync(struct iommu_domain *domain, + struct iommu_iotlb_gather *iotlb_gather) + { +- if (domain->ops->iotlb_sync) ++ if (domain->ops->iotlb_sync && ++ likely(iotlb_gather->start < iotlb_gather->end)) + domain->ops->iotlb_sync(domain, iotlb_gather); + + iommu_iotlb_gather_init(iotlb_gather); diff --git a/queue-5.15/mips-fix-the-gcc-version-check-for-__multi3-workaround.patch b/queue-5.15/mips-fix-the-gcc-version-check-for-__multi3-workaround.patch new file mode 100644 index 0000000000..79dca823dc --- /dev/null +++ b/queue-5.15/mips-fix-the-gcc-version-check-for-__multi3-workaround.patch @@ -0,0 +1,57 @@ +From ec8bf18814915460d9c617b556bf024efef26613 Mon Sep 17 00:00:00 2001 +From: "Maciej W. Rozycki" +Date: Mon, 30 Mar 2026 02:54:09 +0100 +Subject: MIPS: Fix the GCC version check for `__multi3' workaround + +From: Maciej W. Rozycki + +commit ec8bf18814915460d9c617b556bf024efef26613 upstream. + +It was only GCC 10 that fixed a MIPS64r6 code generation issue with a +`__multi3' libcall inefficiently produced to perform 64-bit widening +multiplication while suitable machine instructions exist to do such a +calculation. The fix went in with GCC commit 48b2123f6336 ("re PR +target/82981 (unnecessary __multi3 call for mips64r6 linux kernel)"). + +Adjust our code accordingly, removing build failures such as: + +mips64-linux-ld: lib/math/div64.o: in function `mul_u64_add_u64_div_u64': +div64.c:(.text+0x84): undefined reference to `__multi3' + +with the GCC versions affected. + +Fixes: ebabcf17bcd7 ("MIPS: Implement __multi3 for GCC7 MIPS64r6 builds") +Reported-by: kernel test robot +Closes: https://lore.kernel.org/oe-kbuild-all/202601140146.hMLODc6v-lkp@intel.com/ +Signed-off-by: Maciej W. Rozycki +Cc: stable@vger.kernel.org # v4.15+ +Reviewed-by: David Laight +Signed-off-by: Greg Kroah-Hartman +--- + arch/mips/lib/multi3.c | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +--- a/arch/mips/lib/multi3.c ++++ b/arch/mips/lib/multi3.c +@@ -4,12 +4,12 @@ + #include "libgcc.h" + + /* +- * GCC 7 & older can suboptimally generate __multi3 calls for mips64r6, so for ++ * GCC 9 & older can suboptimally generate __multi3 calls for mips64r6, so for + * that specific case only we implement that intrinsic here. + * + * See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82981 + */ +-#if defined(CONFIG_64BIT) && defined(CONFIG_CPU_MIPSR6) && (__GNUC__ < 8) ++#if defined(CONFIG_64BIT) && defined(CONFIG_CPU_MIPSR6) && (__GNUC__ < 10) + + /* multiply 64-bit values, low 64-bits returned */ + static inline long long notrace dmulu(long long a, long long b) +@@ -51,4 +51,4 @@ ti_type notrace __multi3(ti_type a, ti_t + } + EXPORT_SYMBOL(__multi3); + +-#endif /* 64BIT && CPU_MIPSR6 && GCC7 */ ++#endif /* 64BIT && CPU_MIPSR6 && GCC9 */ diff --git a/queue-5.15/series b/queue-5.15/series index b2b72b139e..cce65d09d1 100644 --- a/queue-5.15/series +++ b/queue-5.15/series @@ -442,3 +442,15 @@ hwmon-occ-fix-missing-newline-in-occ_show_extended.patch riscv-kgdb-fix-several-debug-register-assignment-bug.patch drm-ioc32-stop-speculation-on-the-drm_compat_ioctl-path.patch wifi-wilc1000-fix-u8-overflow-in-ssid-scan-buffer-size-calculation.patch +usb-serial-option-add-meig-smart-srm825wn.patch +alsa-caiaq-fix-stack-out-of-bounds-read-in-init_card.patch +alsa-ctxfi-fix-missing-spdifi1-index-handling.patch +bluetooth-smp-derive-legacy-responder-stk-authentication-from-mitm-state.patch +bluetooth-smp-force-responder-mitm-requirements-before-building-the-pairing-response.patch +mips-fix-the-gcc-version-check-for-__multi3-workaround.patch +iommu-do-not-call-drivers-for-empty-gathers.patch +hwmon-occ-fix-division-by-zero-in-occ_show_power_1.patch +drm-ast-dp501-fix-initialization-of-scu2c.patch +usb-serial-io_edgeport-add-support-for-blackbox-ic135a.patch +usb-serial-option-add-support-for-rolling-wireless-rw135r-gl.patch +usb-core-add-no_lpm-quirk-for-razer-kiyo-pro-webcam.patch diff --git a/queue-5.15/usb-core-add-no_lpm-quirk-for-razer-kiyo-pro-webcam.patch b/queue-5.15/usb-core-add-no_lpm-quirk-for-razer-kiyo-pro-webcam.patch new file mode 100644 index 0000000000..6d6e4a40af --- /dev/null +++ b/queue-5.15/usb-core-add-no_lpm-quirk-for-razer-kiyo-pro-webcam.patch @@ -0,0 +1,50 @@ +From 8b7a42ecdcdeb55580d9345412f7f8fc5aca3f6c Mon Sep 17 00:00:00 2001 +From: JP Hein +Date: Mon, 30 Mar 2026 17:38:04 -0700 +Subject: USB: core: add NO_LPM quirk for Razer Kiyo Pro webcam + +From: JP Hein + +commit 8b7a42ecdcdeb55580d9345412f7f8fc5aca3f6c upstream. + +The Razer Kiyo Pro (1532:0e05) is a USB 3.0 UVC webcam whose firmware +does not handle USB Link Power Management transitions reliably. When LPM +is active, the device can enter a state where it fails to respond to +control transfers, producing EPIPE (-32) errors on UVC probe control +SET_CUR requests. In the worst case, the stalled endpoint triggers an +xHCI stop-endpoint command that times out, causing the host controller +to be declared dead and every USB device on the bus to be disconnected. + +This has been reported as Ubuntu Launchpad Bug #2061177. The failure +mode is: + + 1. UVC probe control SET_CUR returns -32 (EPIPE) + 2. xHCI host not responding to stop endpoint command + 3. xHCI host controller not responding, assume dead + 4. All USB devices on the affected xHCI controller disconnect + +Disabling LPM prevents the firmware from entering the problematic low- +power states that precede the stall. This is the same approach used for +other webcams with similar firmware issues (e.g., Logitech HD Webcam C270). + +Cc: stable +Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2061177 +Signed-off-by: JP Hein +Link: https://patch.msgid.link/20260331003806.212565-2-jp@jphein.com +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/core/quirks.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/drivers/usb/core/quirks.c ++++ b/drivers/usb/core/quirks.c +@@ -476,6 +476,8 @@ static const struct usb_device_id usb_qu + /* Razer - Razer Blade Keyboard */ + { USB_DEVICE(0x1532, 0x0116), .driver_info = + USB_QUIRK_LINEAR_UFRAME_INTR_BINTERVAL }, ++ /* Razer - Razer Kiyo Pro Webcam */ ++ { USB_DEVICE(0x1532, 0x0e05), .driver_info = USB_QUIRK_NO_LPM }, + + /* Lenovo ThinkPad OneLink+ Dock twin hub controllers (VIA Labs VL812) */ + { USB_DEVICE(0x17ef, 0x1018), .driver_info = USB_QUIRK_RESET_RESUME }, diff --git a/queue-5.15/usb-serial-io_edgeport-add-support-for-blackbox-ic135a.patch b/queue-5.15/usb-serial-io_edgeport-add-support-for-blackbox-ic135a.patch new file mode 100644 index 0000000000..585ac45ecd --- /dev/null +++ b/queue-5.15/usb-serial-io_edgeport-add-support-for-blackbox-ic135a.patch @@ -0,0 +1,57 @@ +From 0e01c3416eb863ee7f156a9d7e7421ec0a9f68a0 Mon Sep 17 00:00:00 2001 +From: Frej Drejhammar +Date: Sun, 22 Feb 2026 18:00:42 +0100 +Subject: USB: serial: io_edgeport: add support for Blackbox IC135A + +From: Frej Drejhammar + +commit 0e01c3416eb863ee7f156a9d7e7421ec0a9f68a0 upstream. + +The Blackbox 724-746-5500 USB Director USB-RS-232 HUB, part number +IC135A, is a rebadged Edgeport/4 with its own USB device id. + +Signed-off-by: Frej Drejhammar +Cc: stable@vger.kernel.org +Signed-off-by: Johan Hovold +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/serial/io_edgeport.c | 3 +++ + drivers/usb/serial/io_usbvend.h | 1 + + 2 files changed, 4 insertions(+) + +--- a/drivers/usb/serial/io_edgeport.c ++++ b/drivers/usb/serial/io_edgeport.c +@@ -73,6 +73,7 @@ static const struct usb_device_id edgepo + { USB_DEVICE(USB_VENDOR_ID_ION, ION_DEVICE_ID_EDGEPORT_22I) }, + { USB_DEVICE(USB_VENDOR_ID_ION, ION_DEVICE_ID_EDGEPORT_412_4) }, + { USB_DEVICE(USB_VENDOR_ID_ION, ION_DEVICE_ID_EDGEPORT_COMPATIBLE) }, ++ { USB_DEVICE(USB_VENDOR_ID_ION, ION_DEVICE_ID_BLACKBOX_IC135A) }, + { } + }; + +@@ -121,6 +122,7 @@ static const struct usb_device_id id_tab + { USB_DEVICE(USB_VENDOR_ID_ION, ION_DEVICE_ID_EDGEPORT_8R) }, + { USB_DEVICE(USB_VENDOR_ID_ION, ION_DEVICE_ID_EDGEPORT_8RR) }, + { USB_DEVICE(USB_VENDOR_ID_ION, ION_DEVICE_ID_EDGEPORT_412_8) }, ++ { USB_DEVICE(USB_VENDOR_ID_ION, ION_DEVICE_ID_BLACKBOX_IC135A) }, + { USB_DEVICE(USB_VENDOR_ID_NCR, NCR_DEVICE_ID_EPIC_0202) }, + { USB_DEVICE(USB_VENDOR_ID_NCR, NCR_DEVICE_ID_EPIC_0203) }, + { USB_DEVICE(USB_VENDOR_ID_NCR, NCR_DEVICE_ID_EPIC_0310) }, +@@ -470,6 +472,7 @@ static void get_product_info(struct edge + case ION_DEVICE_ID_EDGEPORT_2_DIN: + case ION_DEVICE_ID_EDGEPORT_4_DIN: + case ION_DEVICE_ID_EDGEPORT_16_DUAL_CPU: ++ case ION_DEVICE_ID_BLACKBOX_IC135A: + product_info->IsRS232 = 1; + break; + +--- a/drivers/usb/serial/io_usbvend.h ++++ b/drivers/usb/serial/io_usbvend.h +@@ -211,6 +211,7 @@ + + // + // Definitions for other product IDs ++#define ION_DEVICE_ID_BLACKBOX_IC135A 0x0801 // OEM device (rebranded Edgeport/4) + #define ION_DEVICE_ID_MT4X56USB 0x1403 // OEM device + #define ION_DEVICE_ID_E5805A 0x1A01 // OEM device (rebranded Edgeport/4) + diff --git a/queue-5.15/usb-serial-option-add-meig-smart-srm825wn.patch b/queue-5.15/usb-serial-option-add-meig-smart-srm825wn.patch new file mode 100644 index 0000000000..eb16abeaef --- /dev/null +++ b/queue-5.15/usb-serial-option-add-meig-smart-srm825wn.patch @@ -0,0 +1,67 @@ +From e8d0ed37bd51da52da6225d278e330c2f18a6198 Mon Sep 17 00:00:00 2001 +From: Ernestas Kulik +Date: Tue, 24 Mar 2026 13:07:16 +0200 +Subject: USB: serial: option: add MeiG Smart SRM825WN + +From: Ernestas Kulik + +commit e8d0ed37bd51da52da6225d278e330c2f18a6198 upstream. + +Add support for the SDX62-based MeiG Smart SRM825WN module. + +If#= 0: RNDIS +If#= 1: RNDIS +If#= 2: Diag +If#= 3: AT +If#= 4: AT +If#= 5: NMEA + +T: Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 19 Spd=480 MxCh= 0 +D: Ver= 2.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 +P: Vendor=2dee ProdID=4d38 Rev= 5.04 +S: Manufacturer=MEIG +S: Product=LTE-A Module +S: SerialNumber=da47a175 +C:* #Ifs= 6 Cfg#= 1 Atr=80 MxPwr=500mA +A: FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=03 +I:* If#= 0 Alt= 0 #EPs= 1 Cls=e0(wlcon) Sub=01 Prot=03 Driver=rndis_host +E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=32ms +I:* If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=rndis_host +E: Ad=8e(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms +E: Ad=0f(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms +I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option +E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms +E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms +I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option +E: Ad=84(I) Atr=03(Int.) MxPS= 10 Ivl=32ms +E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms +E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms +I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option +E: Ad=86(I) Atr=03(Int.) MxPS= 10 Ivl=32ms +E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms +E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms +I:* If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=60 Driver=option +E: Ad=88(I) Atr=03(Int.) MxPS= 10 Ivl=32ms +E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms +E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms + +Signed-off-by: Ernestas Kulik +Cc: stable@vger.kernel.org +Signed-off-by: Johan Hovold +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/serial/option.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/drivers/usb/serial/option.c ++++ b/drivers/usb/serial/option.c +@@ -2441,6 +2441,9 @@ static const struct usb_device_id option + { USB_DEVICE_AND_INTERFACE_INFO(0x2dee, 0x4d22, 0xff, 0xff, 0x30) }, /* MeiG Smart SRM815 and SRM825L */ + { USB_DEVICE_AND_INTERFACE_INFO(0x2dee, 0x4d22, 0xff, 0xff, 0x40) }, /* MeiG Smart SRM825L */ + { USB_DEVICE_AND_INTERFACE_INFO(0x2dee, 0x4d22, 0xff, 0xff, 0x60) }, /* MeiG Smart SRM825L */ ++ { USB_DEVICE_AND_INTERFACE_INFO(0x2dee, 0x4d38, 0xff, 0xff, 0x30) }, /* MeiG Smart SRM825WN (Diag) */ ++ { USB_DEVICE_AND_INTERFACE_INFO(0x2dee, 0x4d38, 0xff, 0xff, 0x40) }, /* MeiG Smart SRM825WN (AT) */ ++ { USB_DEVICE_AND_INTERFACE_INFO(0x2dee, 0x4d38, 0xff, 0xff, 0x60) }, /* MeiG Smart SRM825WN (NMEA) */ + { USB_DEVICE_INTERFACE_CLASS(0x2df3, 0x9d03, 0xff) }, /* LongSung M5710 */ + { USB_DEVICE_INTERFACE_CLASS(0x305a, 0x1404, 0xff) }, /* GosunCn GM500 RNDIS */ + { USB_DEVICE_INTERFACE_CLASS(0x305a, 0x1405, 0xff) }, /* GosunCn GM500 MBIM */ diff --git a/queue-5.15/usb-serial-option-add-support-for-rolling-wireless-rw135r-gl.patch b/queue-5.15/usb-serial-option-add-support-for-rolling-wireless-rw135r-gl.patch new file mode 100644 index 0000000000..c172187166 --- /dev/null +++ b/queue-5.15/usb-serial-option-add-support-for-rolling-wireless-rw135r-gl.patch @@ -0,0 +1,49 @@ +From 01e8d0f742222f1e68f48180d5480097adf7ae9f Mon Sep 17 00:00:00 2001 +From: Wanquan Zhong +Date: Mon, 16 Mar 2026 19:55:12 +0800 +Subject: USB: serial: option: add support for Rolling Wireless RW135R-GL + +From: Wanquan Zhong + +commit 01e8d0f742222f1e68f48180d5480097adf7ae9f upstream. + +Add VID/PID 33f8:1003 for the Rolling Wireless RW135R-GL M.2 module, +which is used in laptop debug cards with MBIM interface for +Linux/Chrome OS. The device supports mbim, pipe functionalities. + +Here are the outputs of usb-devices: +T: Bus=04 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#= 2 Spd=5000 MxCh= 0 +D: Ver= 3.20 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs= 1 +P: Vendor=33f8 ProdID=1003 Rev=05.15 +S: Manufacturer=Rolling Wireless S.a.r.l. +S: Product=Rolling RW135R-GL Module +S: SerialNumber=12345678 +C: #Ifs= 3 Cfg#= 1 Atr=a0 MxPwr=896mA +I: If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim +E: Ad=81(I) Atr=03(Int.) MxPS= 64 Ivl=32ms +I: If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim +E: Ad=0f(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms +E: Ad=8e(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms +I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=40 Driver=option +E: Ad=01(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms +E: Ad=82(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms +E: Ad=83(I) Atr=03(Int.) MxPS= 10 Ivl=32ms + +Signed-off-by: Wanquan Zhong +Cc: stable@vger.kernel.org +Signed-off-by: Johan Hovold +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/serial/option.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/usb/serial/option.c ++++ b/drivers/usb/serial/option.c +@@ -2464,6 +2464,7 @@ static const struct usb_device_id option + { USB_DEVICE_INTERFACE_CLASS(0x33f8, 0x0302, 0xff) }, /* Rolling RW101R-GL (laptop MBIM) */ + { USB_DEVICE_INTERFACE_CLASS(0x33f8, 0x0802, 0xff), /* Rolling RW350-GL (laptop MBIM) */ + .driver_info = RSVD(5) }, ++ { USB_DEVICE_INTERFACE_CLASS(0x33f8, 0x1003, 0xff) }, /* Rolling RW135R-GL (laptop MBIM) */ + { USB_DEVICE_AND_INTERFACE_INFO(0x3731, 0x0100, 0xff, 0xff, 0x30) }, /* NetPrisma LCUK54-WWD for Global */ + { USB_DEVICE_AND_INTERFACE_INFO(0x3731, 0x0100, 0xff, 0x00, 0x40) }, + { USB_DEVICE_AND_INTERFACE_INFO(0x3731, 0x0100, 0xff, 0xff, 0x40) },