Add support for the Quectel RG660QB 5G module (USB ID 2c7c:013d).
Its QMI interface (interface 4) uses class/subclass/protocol ff/ff/ff
like the other recent Quectel modules, so match it the same way.

The remaining interfaces are handled by the option driver.

Tested with an early sample of the module on a Quectel 5G EVB connected
over USB 3 to a Raspberry Pi 5: qmicli talks to the module via
/dev/cdc-wdm0.

Assisted-by: LLM
Signed-off-by: Sebastian Sjoholm <sebastian.sjoholm@gmail.com>
---
 drivers/net/usb/qmi_wwan.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 8178a8758..c940af5b0 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -1084,6 +1084,7 @@ static const struct usb_device_id products[] = {
 	},
 	{QMI_MATCH_FF_FF_FF(0x2c7c, 0x0122)},	/* Quectel RG650V */
 	{QMI_MATCH_FF_FF_FF(0x2c7c, 0x0125)},	/* Quectel EC25, EC20 R2.0  Mini PCIe */
+	{QMI_MATCH_FF_FF_FF(0x2c7c, 0x013d)},	/* Quectel RG660QB */
 	{QMI_MATCH_FF_FF_FF(0x2c7c, 0x0306)},	/* Quectel EP06/EG06/EM06 */
 	{QMI_MATCH_FF_FF_FF(0x2c7c, 0x0512)},	/* Quectel EG12/EM12 */
 	{QMI_MATCH_FF_FF_FF(0x2c7c, 0x0620)},	/* Quectel EM160R-GL */
-- 
2.43.0

Thank you for your contribution! Sashiko AI review found 1 potential
issue(s) to consider:

Critical: 0 · High: 0 · Medium: 1 · Low: 0

- [Medium] Inaccurate commit message / incomplete composite-device
  support: the patch adds only the qmi_wwan match for Quectel RG660QB…

--

net: usb: qmi_wwan: add Quectel RG660QB

This adds a single qmi_wwan match for the Quectel RG660QB 5G module
(2c7c:013d) using QMI_MATCH_FF_FF_FF, i.e. the vendor-specific ff/ff/ff
QMI function only.  The commit message states that the remaining
interfaces of the device are handled by the option driver.

> diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
> index fdfdcf24ddcf8..f51cf9cb9421c 100644
> --- a/drivers/net/usb/qmi_wwan.c
> +++ b/drivers/net/usb/qmi_wwan.c
> @@ -1084,6 +1084,7 @@ static const struct usb_device_id products[] = {
>  	},
>  	{QMI_MATCH_FF_FF_FF(0x2c7c, 0x0122)},	/* Quectel RG650V */
>  	{QMI_MATCH_FF_FF_FF(0x2c7c, 0x0125)},	/* Quectel EC25, EC20 R2.0  Mini PCIe */
> +	{QMI_MATCH_FF_FF_FF(0x2c7c, 0x013d)},	/* Quectel RG660QB */

[Severity: Medium]
The commit message says:

    The remaining interfaces are handled by the option driver.

Is that true for this tree?  Grepping drivers/usb/serial/option.c at this
commit returns no entry for product id 0x013d, and every match in
option_ids[] in the Quectel block is per-product-id, so there is no
vendor-wide wildcard that could pick 2c7c:013d up:

drivers/usb/serial/option.c:option_ids[] {
	...
	{ USB_DEVICE_AND_INTERFACE_INFO(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_RG650V, 0xff, 0xff, 0x30) },
	{ USB_DEVICE_AND_INTERFACE_INFO(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_RG650V, 0xff, 0, 0) },
	...
}

The sibling modules referenced in the neighbouring qmi_wwan lines carry
that extra pair of option.c rows (RG650V for 0x0122, and 0x0620 for
EM160R-GL), but nothing equivalent is added here for 0x013d.

Since the other functions of the module also use vendor-specific class
0xff, cdc_acm will not claim them either, and qcserial only matches
0x05c6/0x1199.  Does that leave the AT/DM/NMEA/PPP interfaces of the
RG660QB unbound, with no /dev/ttyUSB* nodes appearing?

Should this either come with a companion option.c patch adding the
0x013d entries, or have the sentence about the option driver dropped or
reworded so the commit message matches what the tree actually contains?

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260903180044.6179-1-sebastian.sjoholm%40gmail.com