--- /dev/null
+From 45424e871abf2a152e247a9cff78359f18dd95c0 Mon Sep 17 00:00:00 2001
+From: Berk Cem Goksel <berkcgoksel@gmail.com>
+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 <berkcgoksel@gmail.com>
+
+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 <andreyknvl@gmail.com>
+Reported-by: Berk Cem Goksel <berkcgoksel@gmail.com>
+Signed-off-by: Berk Cem Goksel <berkcgoksel@gmail.com>
+Link: https://patch.msgid.link/20260329133825.581585-1-berkcgoksel@gmail.com
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+@@ -502,7 +502,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;
+
--- /dev/null
+From b045ab3dff97edae6d538eeff900a34c098761f8 Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Sun, 29 Mar 2026 11:12:37 +0200
+Subject: ALSA: ctxfi: Fix missing SPDIFI1 index handling
+
+From: Takashi Iwai <tiwai@suse.de>
+
+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 <linux@hohmatik.de>
+Closes: https://lore.kernel.org/20260315155004.15633-1-linux@hohmatik.de
+Cc: <stable@vger.kernel.org>
+Link: https://patch.msgid.link/20260329091240.420194-1-tiwai@suse.de
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
--- /dev/null
+From 20756fec2f0108cb88e815941f1ffff88dc286fe Mon Sep 17 00:00:00 2001
+From: Oleh Konko <security@1seal.org>
+Date: Tue, 31 Mar 2026 11:52:13 +0000
+Subject: Bluetooth: SMP: derive legacy responder STK authentication from MITM state
+
+From: Oleh Konko <security@1seal.org>
+
+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 <security@1seal.org>
+Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/bluetooth/smp.c | 5 +----
+ 1 file changed, 1 insertion(+), 4 deletions(-)
+
+--- a/net/bluetooth/smp.c
++++ b/net/bluetooth/smp.c
+@@ -1018,10 +1018,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
--- /dev/null
+From d05111bfe37bfd8bd4d2dfe6675d6bdeef43f7c7 Mon Sep 17 00:00:00 2001
+From: Oleh Konko <security@1seal.org>
+Date: Tue, 31 Mar 2026 11:52:12 +0000
+Subject: Bluetooth: SMP: force responder MITM requirements before building the pairing response
+
+From: Oleh Konko <security@1seal.org>
+
+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 <luiz.dentz@gmail.com>
+Signed-off-by: Oleh Konko <security@1seal.org>
+Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/bluetooth/smp.c | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+--- a/net/bluetooth/smp.c
++++ b/net/bluetooth/smp.c
+@@ -1818,7 +1818,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;
+
+@@ -1826,6 +1826,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);
--- /dev/null
+From 2f42c1a6161646cbd29b443459fd635d29eda634 Mon Sep 17 00:00:00 2001
+From: Thomas Zimmermann <tzimmermann@suse.de>
+Date: Fri, 27 Mar 2026 14:32:53 +0100
+Subject: drm/ast: dp501: Fix initialization of SCU2C
+
+From: Thomas Zimmermann <tzimmermann@suse.de>
+
+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 <tzimmermann@suse.de>
+Fixes: 83c6620bae3f ("drm/ast: initial DP501 support (v0.2)")
+Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
+Cc: Dave Airlie <airlied@redhat.com>
+Cc: Thomas Zimmermann <tzimmermann@suse.de>
+Cc: Jocelyn Falempe <jfalempe@redhat.com>
+Cc: dri-devel@lists.freedesktop.org
+Cc: <stable@vger.kernel.org> # v3.16+
+Link: https://patch.msgid.link/20260327133532.79696-2-tzimmermann@suse.de
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
--- /dev/null
+From 39e2a5bf970402a8530a319cf06122e216ba57b8 Mon Sep 17 00:00:00 2001
+From: Sanman Pradhan <psanman@juniper.net>
+Date: Thu, 26 Mar 2026 22:45:23 +0000
+Subject: hwmon: (occ) Fix division by zero in occ_show_power_1()
+
+From: Sanman Pradhan <psanman@juniper.net>
+
+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 <psanman@juniper.net>
+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 <linux@roeck-us.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+@@ -422,6 +422,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)
+ {
+@@ -443,9 +449,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) *
+@@ -461,12 +466,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)
+ {
--- /dev/null
+From 90c5def10bea574b101b7a520c015ca81742183f Mon Sep 17 00:00:00 2001
+From: Jason Gunthorpe <jgg@nvidia.com>
+Date: Mon, 2 Mar 2026 18:22:52 -0400
+Subject: iommu: Do not call drivers for empty gathers
+
+From: Jason Gunthorpe <jgg@nvidia.com>
+
+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 <janusz.krzysztofik@linux.intel.com>
+Closes: https://lore.kernel.org/r/11145826.aFP6jjVeTY@jkrzyszt-mobl2.ger.corp.intel.com
+Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
+Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
+Reviewed-by: Samiullah Khawaja <skhawaja@google.com>
+Reviewed-by: Robin Murphy <robin.murphy@arm.com>
+Reviewed-by: Vasant Hegde <vasant.hegde@amd.com>
+Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/linux/iommu.h | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/include/linux/iommu.h
++++ b/include/linux/iommu.h
+@@ -526,7 +526,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);
--- /dev/null
+From ec8bf18814915460d9c617b556bf024efef26613 Mon Sep 17 00:00:00 2001
+From: "Maciej W. Rozycki" <macro@orcam.me.uk>
+Date: Mon, 30 Mar 2026 02:54:09 +0100
+Subject: MIPS: Fix the GCC version check for `__multi3' workaround
+
+From: Maciej W. Rozycki <macro@orcam.me.uk>
+
+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 <lkp@intel.com>
+Closes: https://lore.kernel.org/oe-kbuild-all/202601140146.hMLODc6v-lkp@intel.com/
+Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
+Cc: stable@vger.kernel.org # v4.15+
+Reviewed-by: David Laight <david.laight.linux@gmail.com.
+Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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 */
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
--- /dev/null
+From 8b7a42ecdcdeb55580d9345412f7f8fc5aca3f6c Mon Sep 17 00:00:00 2001
+From: JP Hein <jp@jphein.com>
+Date: Mon, 30 Mar 2026 17:38:04 -0700
+Subject: USB: core: add NO_LPM quirk for Razer Kiyo Pro webcam
+
+From: JP Hein <jp@jphein.com>
+
+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 <stable@kernel.org>
+Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2061177
+Signed-off-by: JP Hein <jp@jphein.com>
+Link: https://patch.msgid.link/20260331003806.212565-2-jp@jphein.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/core/quirks.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/usb/core/quirks.c
++++ b/drivers/usb/core/quirks.c
+@@ -477,6 +477,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 },
--- /dev/null
+From 0e01c3416eb863ee7f156a9d7e7421ec0a9f68a0 Mon Sep 17 00:00:00 2001
+From: Frej Drejhammar <frej@stacken.kth.se>
+Date: Sun, 22 Feb 2026 18:00:42 +0100
+Subject: USB: serial: io_edgeport: add support for Blackbox IC135A
+
+From: Frej Drejhammar <frej@stacken.kth.se>
+
+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 <frej@stacken.kth.se>
+Cc: stable@vger.kernel.org
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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) },
+@@ -546,6 +548,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)
+
--- /dev/null
+From e8d0ed37bd51da52da6225d278e330c2f18a6198 Mon Sep 17 00:00:00 2001
+From: Ernestas Kulik <ernestas.k@iconn-networks.com>
+Date: Tue, 24 Mar 2026 13:07:16 +0200
+Subject: USB: serial: option: add MeiG Smart SRM825WN
+
+From: Ernestas Kulik <ernestas.k@iconn-networks.com>
+
+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 <ernestas.k@iconn-networks.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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 */
--- /dev/null
+From 01e8d0f742222f1e68f48180d5480097adf7ae9f Mon Sep 17 00:00:00 2001
+From: Wanquan Zhong <wanquan.zhong@fibocom.com>
+Date: Mon, 16 Mar 2026 19:55:12 +0800
+Subject: USB: serial: option: add support for Rolling Wireless RW135R-GL
+
+From: Wanquan Zhong <wanquan.zhong@fibocom.com>
+
+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 <wanquan.zhong@fibocom.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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) },
projects / thirdparty / kernel / stable-queue.git / commitdiff
