* [PATCH net] net: qmi_wwan: add support for Cinterion PLS8
@ 2017-11-23 13:37 Oliver Graute
2017-11-23 14:03 ` Bjørn Mork
0 siblings, 1 reply; 10+ messages in thread
From: Oliver Graute @ 2017-11-23 13:37 UTC (permalink / raw)
To: bjorn; +Cc: netdev, Oliver Graute
When the PLS8 devices show up with PID 0x0061 they will expose both a
QMI port and a WWAN interface.
Signed-off-by: Oliver Graute <oliver.graute@neuhaus.de>
---
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 720a3a2..b7ee59d 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -1221,6 +1221,7 @@ static int qmi_wwan_resume(struct usb_interface *intf)
{QMI_FIXED_INTF(0x0b3c, 0xc00a, 6)}, /* Olivetti Olicard 160 */
{QMI_FIXED_INTF(0x0b3c, 0xc00b, 4)}, /* Olivetti Olicard 500 */
{QMI_FIXED_INTF(0x1e2d, 0x0060, 4)}, /* Cinterion PLxx */
+ {QMI_FIXED_INTF(0x1e2d, 0x0061, 3)}, /* Cinterion PLS8 */
{QMI_FIXED_INTF(0x1e2d, 0x0053, 4)}, /* Cinterion PHxx,PXxx */
{QMI_FIXED_INTF(0x1e2d, 0x0082, 4)}, /* Cinterion PHxx,PXxx (2 RmNet) */
{QMI_FIXED_INTF(0x1e2d, 0x0082, 5)}, /* Cinterion PHxx,PXxx (2 RmNet) */
--
1.9.1
^ permalink raw reply related [flat|nested] 10+ messages in thread* Re: [PATCH net] net: qmi_wwan: add support for Cinterion PLS8 2017-11-23 13:37 [PATCH net] net: qmi_wwan: add support for Cinterion PLS8 Oliver Graute @ 2017-11-23 14:03 ` Bjørn Mork 2017-11-23 15:10 ` Oliver Graute 0 siblings, 1 reply; 10+ messages in thread From: Bjørn Mork @ 2017-11-23 14:03 UTC (permalink / raw) To: Oliver Graute; +Cc: netdev, Oliver Graute Oliver Graute <oliver.graute@gmail.com> writes: > When the PLS8 devices show up with PID 0x0061 they will expose both a > QMI port and a WWAN interface. Please remove the indentation. > Signed-off-by: Oliver Graute <oliver.graute@neuhaus.de> > --- > 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 720a3a2..b7ee59d 100644 > --- a/drivers/net/usb/qmi_wwan.c > +++ b/drivers/net/usb/qmi_wwan.c > @@ -1221,6 +1221,7 @@ static int qmi_wwan_resume(struct usb_interface *intf) > {QMI_FIXED_INTF(0x0b3c, 0xc00a, 6)}, /* Olivetti Olicard 160 */ > {QMI_FIXED_INTF(0x0b3c, 0xc00b, 4)}, /* Olivetti Olicard 500 */ > {QMI_FIXED_INTF(0x1e2d, 0x0060, 4)}, /* Cinterion PLxx */ > + {QMI_FIXED_INTF(0x1e2d, 0x0061, 3)}, /* Cinterion PLS8 */ > {QMI_FIXED_INTF(0x1e2d, 0x0053, 4)}, /* Cinterion PHxx,PXxx */ > {QMI_FIXED_INTF(0x1e2d, 0x0082, 4)}, /* Cinterion PHxx,PXxx (2 RmNet) */ > {QMI_FIXED_INTF(0x1e2d, 0x0082, 5)}, /* Cinterion PHxx,PXxx (2 RmNet) */ Are you sure this is correct? The Windows drivers I found for this device appear to think all functions use even interface numbers only, presumably because of a control+data interface layout? And the first 5 functions are supposedly all serial: [Strings] VENDOR_NAME = "Gemalto M2M GmbH" SRC_DSK = "Gemalto M2M GmbH ALSx PLSx LTE USB Driver Disk" DEVICE_NAME = "Gemalto M2M ALSx PLSx LTE USB Modem" SERVICE_DISPLAY_NAME = "Gemalto M2M ALSx PLSx LTE USB Modem Device" USB_VID = "VID_1E2D" USB_PID = "PID_0061" .. [Models] %DEVICE_NAME% = Modem,USB\%USB_VID%&%USB_PID%&MI_00 [Strings] VENDOR_NAME = "Gemalto M2M GmbH" SRC_DSK = "Gemalto M2M GmbH ALSx PLSx LTE USB Driver Disk" DEVICE_NAME_1 = "Gemalto M2M ALSx PLSx LTE USB serial Port 1" DEVICE_NAME_2 = "Gemalto M2M ALSx PLSx LTE USB serial Port 2" DEVICE_NAME_3 = "Gemalto M2M ALSx PLSx LTE USB serial Port 3" DEVICE_NAME_4 = "Gemalto M2M ALSx PLSx LTE USB serial Port 4" SERVICE_DISPLAY_NAME = "Gemalto M2M ALSx PLSx LTE USB Device for serial Communication" USB_VID = "VID_1E2D" USB_PID = "PID_0061" .. [SerialPort] %DEVICE_NAME_1%=PortInstall, USB\%USB_VID%&%USB_PID%&MI_02 %DEVICE_NAME_2%=PortInstall, USB\%USB_VID%&%USB_PID%&MI_04 %DEVICE_NAME_3%=PortInstall, USB\%USB_VID%&%USB_PID%&MI_06 %DEVICE_NAME_4%=PortInstall, USB\%USB_VID%&%USB_PID%&MI_08 The network functions should be on interfaces 10 and 12 according to this driver info: [Strings] VENDOR_NAME = "Gemalto M2M GmbH" SRC_DSK = "Gemalto M2M GmbH ALSx PLSx LTE USB Driver Disk" DEVICE_NAME_1 = "Gemalto M2M ALSx PLSx LTE USB MB Wireless Ethernet Adapter" DEVICE_NAME_2 = "Gemalto M2M ALSx PLSx LTE USB MB Wireless Ethernet Adapter (2nd context)" SERVICE_DISPLAY_NAME = "Gemalto M2M ALSx PLSx LTE USB MB NDIS Miniport" USB_VID = "VID_1E2D" USB_PID = "PID_0061" .. [Models.NTx86.6.1] %DEVICE_NAME_1%=wwan.NTx86.6.1,USB\%USB_VID%&%USB_PID%&MI_0A %DEVICE_NAME_2%=wwan.NTx86.6.1,USB\%USB_VID%&%USB_PID%&MI_0C But I don't know anything about this device. Maybe the layout is configurable without changing the device ID? Do you have any more information you can provide, like for example a verbose lsusb output or the relevant part of /sys/kernel/debug/usb/devices? Bjørn ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH net] net: qmi_wwan: add support for Cinterion PLS8 2017-11-23 14:03 ` Bjørn Mork @ 2017-11-23 15:10 ` Oliver Graute 2017-11-23 18:15 ` Bjørn Mork 0 siblings, 1 reply; 10+ messages in thread From: Oliver Graute @ 2017-11-23 15:10 UTC (permalink / raw) To: netdev On 23/11/17, Bjørn Mork wrote: > Oliver Graute <oliver.graute@gmail.com> writes: > > > When the PLS8 devices show up with PID 0x0061 they will expose both a > > QMI port and a WWAN interface. > > > Please remove the indentation. will do after we clarifed if this patch is really needed > Are you sure this is correct? The Windows drivers I found for this > device appear to think all functions use even interface numbers only, > presumably because of a control+data interface layout? honestly not. I have this change for some time in use with older kernel to get this PLS8 module working. Its pop-ups as usb0 network interface and with 5 /dev/ttyACM interfaces. Its gets an IP address from the provider. back then I also added this two lines: +++ V/drivers/usb/serial/option.c 2015-01-26 15:28:09.676671843 +0100 @@ -338,6 +338,7 @@ static void option_instat_callback(struc #define CINTERION_PRODUCT_PH8 0x0053 #define CINTERION_PRODUCT_AHXX 0x0055 #define CINTERION_PRODUCT_PLXX 0x0060 +#define CINTERION_PRODUCT_PLS8 0x0061 @@ -1251,6 +1252,7 @@ static const struct usb_device_id option { USB_DEVICE(CINTERION_VENDOR_ID, CINTERION_PRODUCT_PLXX), + { USB_DEVICE(CINTERION_VENDOR_ID, CINTERION_PRODUCT_PLS8), > But I don't know anything about this device. Maybe the layout is > configurable without changing the device ID? Do you have any more > information you can provide, like for example a verbose lsusb output or > the relevant part of /sys/kernel/debug/usb/devices? here the output of lsusb -vvv Bus 002 Device 002: ID 1e2d:0061 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x1e2d idProduct 0x0061 bcdDevice 2.32 iManufacturer 1 Cinterion iProduct 2 LTE Modem iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 497 bNumInterfaces 14 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 20mA Interface Association: bLength 8 bDescriptorType 11 bFirstInterface 0 bInterfaceCount 2 bFunctionClass 2 Communications bFunctionSubClass 2 Abstract (modem) bFunctionProtocol 1 AT-commands (v.25ter) iFunction 5 CDC Serial Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 2 Communications bInterfaceSubClass 2 Abstract (modem) bInterfaceProtocol 1 AT-commands (v.25ter) iInterface 3 CDC Abstract Control Model (ACM) CDC Header: bcdCDC 1.20 CDC Call Management: bmCapabilities 0x03 call management use DataInterface bDataInterface 1 CDC ACM: bmCapabilities 0x02 line coding and serial state CDC Union: bMasterInterface 0 bSlaveInterface 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 9 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 10 CDC Data bInterfaceSubClass 0 Unused bInterfaceProtocol 0 iInterface 4 CDC ACM Data Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Association: bLength 8 bDescriptorType 11 bFirstInterface 2 bInterfaceCount 2 bFunctionClass 2 Communications bFunctionSubClass 2 Abstract (modem) bFunctionProtocol 1 AT-commands (v.25ter) iFunction 5 CDC Serial Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 2 Communications bInterfaceSubClass 2 Abstract (modem) bInterfaceProtocol 1 AT-commands (v.25ter) iInterface 3 CDC Abstract Control Model (ACM) CDC Header: bcdCDC 1.20 CDC Call Management: bmCapabilities 0x03 call management use DataInterface bDataInterface 3 CDC ACM: bmCapabilities 0x02 line coding and serial state CDC Union: bMasterInterface 2 bSlaveInterface 3 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 9 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 3 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 10 CDC Data bInterfaceSubClass 0 Unused bInterfaceProtocol 0 iInterface 4 CDC ACM Data Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Association: bLength 8 bDescriptorType 11 bFirstInterface 4 bInterfaceCount 2 bFunctionClass 2 Communications bFunctionSubClass 2 Abstract (modem) bFunctionProtocol 1 AT-commands (v.25ter) iFunction 5 CDC Serial Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 4 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 2 Communications bInterfaceSubClass 2 Abstract (modem) bInterfaceProtocol 1 AT-commands (v.25ter) iInterface 3 CDC Abstract Control Model (ACM) CDC Header: bcdCDC 1.20 CDC Call Management: bmCapabilities 0x03 call management use DataInterface bDataInterface 5 CDC ACM: bmCapabilities 0x02 line coding and serial state CDC Union: bMasterInterface 4 bSlaveInterface 5 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x86 EP 6 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 9 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 5 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 10 CDC Data bInterfaceSubClass 0 Unused bInterfaceProtocol 0 iInterface 4 CDC ACM Data Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x85 EP 5 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Association: bLength 8 bDescriptorType 11 bFirstInterface 6 bInterfaceCount 2 bFunctionClass 2 Communications bFunctionSubClass 2 Abstract (modem) bFunctionProtocol 1 AT-commands (v.25ter) iFunction 5 CDC Serial Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 6 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 2 Communications bInterfaceSubClass 2 Abstract (modem) bInterfaceProtocol 1 AT-commands (v.25ter) iInterface 3 CDC Abstract Control Model (ACM) CDC Header: bcdCDC 1.20 CDC Call Management: bmCapabilities 0x03 call management use DataInterface bDataInterface 7 CDC ACM: bmCapabilities 0x02 line coding and serial state CDC Union: bMasterInterface 6 bSlaveInterface 7 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x88 EP 8 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 9 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 7 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 10 CDC Data bInterfaceSubClass 0 Unused bInterfaceProtocol 0 iInterface 4 CDC ACM Data Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x87 EP 7 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x04 EP 4 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Association: bLength 8 bDescriptorType 11 bFirstInterface 8 bInterfaceCount 2 bFunctionClass 2 Communications bFunctionSubClass 2 Abstract (modem) bFunctionProtocol 1 AT-commands (v.25ter) iFunction 6 CDC Serial (DIAG) Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 8 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 2 Communications bInterfaceSubClass 2 Abstract (modem) bInterfaceProtocol 1 AT-commands (v.25ter) iInterface 7 CDC Abstract Control Model (ACM) for DIAG CDC Header: bcdCDC 1.10 CDC Call Management: bmCapabilities 0x00 bDataInterface 0 CDC ACM: bmCapabilities 0x00 CDC Union: bMasterInterface 8 bSlaveInterface 9 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x8a EP 10 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 9 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 9 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 10 CDC Data bInterfaceSubClass 0 Unused bInterfaceProtocol 0 iInterface 8 CDC ACM Data for DIAG Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x89 EP 9 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x05 EP 5 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Association: bLength 8 bDescriptorType 11 bFirstInterface 10 bInterfaceCount 2 bFunctionClass 2 Communications bFunctionSubClass 6 Ethernet Networking bFunctionProtocol 0 iFunction 9 CDC Ethernet (RmNet) Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 10 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 2 Communications bInterfaceSubClass 6 Ethernet Networking bInterfaceProtocol 0 iInterface 10 CDC Ethernet Control Model (ECM) for RmNet CDC Header: bcdCDC 1.20 CDC Ethernet: iMacAddress 12 DEADBEEF0000 bmEthernetStatistics 0x00000000 wMaxSegmentSize 1514 wNumberMCFilters 0x0000 bNumberPowerFilters 0 CDC Union: bMasterInterface 10 bSlaveInterface 11 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x8c EP 12 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 9 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 11 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 10 CDC Data bInterfaceSubClass 0 Unused bInterfaceProtocol 0 iInterface 11 CDC Ethernet Data for RmNet Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 11 bAlternateSetting 1 bNumEndpoints 2 bInterfaceClass 10 CDC Data bInterfaceSubClass 0 Unused bInterfaceProtocol 0 iInterface 11 CDC Ethernet Data for RmNet Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x8b EP 11 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x06 EP 6 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Association: bLength 8 bDescriptorType 11 bFirstInterface 12 bInterfaceCount 2 bFunctionClass 2 Communications bFunctionSubClass 6 Ethernet Networking bFunctionProtocol 0 iFunction 9 CDC Ethernet (RmNet) Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 12 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 2 Communications bInterfaceSubClass 6 Ethernet Networking bInterfaceProtocol 0 iInterface 10 CDC Ethernet Control Model (ECM) for RmNet CDC Header: bcdCDC 1.20 CDC Ethernet: iMacAddress 13 DEADBEEF0001 bmEthernetStatistics 0x00000000 wMaxSegmentSize 1514 wNumberMCFilters 0x0000 bNumberPowerFilters 0 CDC Union: bMasterInterface 12 bSlaveInterface 13 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x8e EP 14 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 9 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 13 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 10 CDC Data bInterfaceSubClass 0 Unused bInterfaceProtocol 0 iInterface 11 CDC Ethernet Data for RmNet Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 13 bAlternateSetting 1 bNumEndpoints 2 bInterfaceClass 10 CDC Data bInterfaceSubClass 0 Unused bInterfaceProtocol 0 iInterface 11 CDC Ethernet Data for RmNet Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x8d EP 13 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x07 EP 7 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Device Qualifier (for other device speed): bLength 10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 bNumConfigurations 1 Device Status: 0x0000 (Bus Powered) Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 1 Single TT bMaxPacketSize0 64 idVendor 0x1d6b Linux Foundation idProduct 0x0002 2.0 root hub bcdDevice 3.09 iManufacturer 3 Linux 3.9.11 ehci_hcd iProduct 2 EHCI Host Controller iSerial 1 ci_hdrc.0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 25 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 Unused bInterfaceProtocol 0 Full speed (or root) hub iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0004 1x 4 bytes bInterval 12 Hub Descriptor: bLength 9 bDescriptorType 41 nNbrPorts 1 wHubCharacteristic 0x0009 Per-port power switching Per-port overcurrent protection TT think time 8 FS bits bPwrOn2PwrGood 10 * 2 milli seconds bHubContrCurrent 0 milli Ampere DeviceRemovable 0x00 PortPwrCtrlMask 0xff Hub Port Status: Port 1: 0000.0100 power Device Status: 0x0001 Self Powered Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 1 Single TT bMaxPacketSize0 64 idVendor 0x1d6b Linux Foundation idProduct 0x0002 2.0 root hub bcdDevice 3.09 iManufacturer 3 Linux 3.9.11 ehci_hcd iProduct 2 EHCI Host Controller iSerial 1 ci_hdrc.1 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 25 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 Unused bInterfaceProtocol 0 Full speed (or root) hub iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0004 1x 4 bytes bInterval 12 Hub Descriptor: bLength 9 bDescriptorType 41 nNbrPorts 1 wHubCharacteristic 0x0009 Per-port power switching Per-port overcurrent protection TT think time 8 FS bits bPwrOn2PwrGood 10 * 2 milli seconds bHubContrCurrent 0 milli Ampere DeviceRemovable 0x00 PortPwrCtrlMask 0xff Hub Port Status: Port 1: 0000.0503 highspeed power enable connect Device Status: 0x0001 Self Powered Best Regards, Oliver ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH net] net: qmi_wwan: add support for Cinterion PLS8 2017-11-23 15:10 ` Oliver Graute @ 2017-11-23 18:15 ` Bjørn Mork 2017-11-23 23:06 ` Reinhard Speyerer ` (2 more replies) 0 siblings, 3 replies; 10+ messages in thread From: Bjørn Mork @ 2017-11-23 18:15 UTC (permalink / raw) To: netdev Oliver Graute <oliver.graute@gmail.com> writes: > On 23/11/17, Bjørn Mork wrote: >> Oliver Graute <oliver.graute@gmail.com> writes: >> >> > When the PLS8 devices show up with PID 0x0061 they will expose both a >> > QMI port and a WWAN interface. >> >> >> Please remove the indentation. > > will do after we clarifed if this patch is really needed > >> Are you sure this is correct? The Windows drivers I found for this >> device appear to think all functions use even interface numbers only, >> presumably because of a control+data interface layout? > > honestly not. I have this change for some time in use with older kernel > to get this PLS8 module working. Its pop-ups as usb0 network interface and > with 5 /dev/ttyACM interfaces. Its gets an IP address from the provider. > > back then I also added this two lines: > > +++ V/drivers/usb/serial/option.c 2015-01-26 15:28:09.676671843 +0100 > @@ -338,6 +338,7 @@ static void option_instat_callback(struc > #define CINTERION_PRODUCT_PH8 0x0053 > #define CINTERION_PRODUCT_AHXX 0x0055 > #define CINTERION_PRODUCT_PLXX 0x0060 > +#define CINTERION_PRODUCT_PLS8 0x0061 > > @@ -1251,6 +1252,7 @@ static const struct usb_device_id option > { USB_DEVICE(CINTERION_VENDOR_ID, CINTERION_PRODUCT_PLXX), > + { USB_DEVICE(CINTERION_VENDOR_ID, CINTERION_PRODUCT_PLS8), This should not be necessary and is wrong given the descriptors in your lsusb outout. All the serial functions look like proper CDC ACM functions which should Just Work with the cdc-acm class driver. No need for any device specific entry for those. >> But I don't know anything about this device. Maybe the layout is >> configurable without changing the device ID? Do you have any more >> information you can provide, like for example a verbose lsusb output or >> the relevant part of /sys/kernel/debug/usb/devices? > > here the output of lsusb -vvv > > Bus 002 Device 002: ID 1e2d:0061 > Device Descriptor: > bLength 18 > bDescriptorType 1 > bcdUSB 2.00 > bDeviceClass 0 (Defined at Interface level) > bDeviceSubClass 0 > bDeviceProtocol 0 > bMaxPacketSize0 64 > idVendor 0x1e2d > idProduct 0x0061 > bcdDevice 2.32 > iManufacturer 1 Cinterion > iProduct 2 LTE Modem > iSerial 0 > bNumConfigurations 1 > Configuration Descriptor: > bLength 9 > bDescriptorType 2 > wTotalLength 497 > bNumInterfaces 14 > bConfigurationValue 1 > iConfiguration 0 > bmAttributes 0xe0 > Self Powered > Remote Wakeup > MaxPower 20mA > Interface Association: > bLength 8 > bDescriptorType 11 > bFirstInterface 0 > bInterfaceCount 2 > bFunctionClass 2 Communications > bFunctionSubClass 2 Abstract (modem) > bFunctionProtocol 1 AT-commands (v.25ter) > iFunction 5 CDC Serial > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 0 > bAlternateSetting 0 > bNumEndpoints 1 > bInterfaceClass 2 Communications > bInterfaceSubClass 2 Abstract (modem) > bInterfaceProtocol 1 AT-commands (v.25ter) > iInterface 3 CDC Abstract Control Model (ACM) > CDC Header: > bcdCDC 1.20 > CDC Call Management: > bmCapabilities 0x03 > call management > use DataInterface > bDataInterface 1 > CDC ACM: > bmCapabilities 0x02 > line coding and serial state > CDC Union: > bMasterInterface 0 > bSlaveInterface 1 OK, this is consistent with the Windows driver files, so I believe your patch could work. The USB interface it identified as QMI is in fact a CDC ACM data interface. > Interface Association: > bLength 8 > bDescriptorType 11 > bFirstInterface 10 > bInterfaceCount 2 > bFunctionClass 2 Communications > bFunctionSubClass 6 Ethernet Networking > bFunctionProtocol 0 > iFunction 9 CDC Ethernet (RmNet) > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 10 > bAlternateSetting 0 > bNumEndpoints 1 > bInterfaceClass 2 Communications > bInterfaceSubClass 6 Ethernet Networking > bInterfaceProtocol 0 > iInterface 10 CDC Ethernet Control Model (ECM) for RmNet > CDC Header: > bcdCDC 1.20 > CDC Ethernet: > iMacAddress 12 DEADBEEF0000 Nice mac address :-) This is also consistent with the Windows drivers. And being a proper CDC ECM class function, it should Just Work with the cdc_ether driver. Except for the "RmNet" part, which I guess is the reason you want to add this device to qmi_wwan. Which is fine, *if* we can be reasonably certain that it does support QMI. The description string is a strong indication, but it would be even better to know this was tested. But adding this to qmi_wwan is not enough. You also need to add a blacklist entry to cdc_ether. Both should use a device+class match, similar to the Novatel entries. This will make the interface numbering irrelevant, and will allow a single entry to match both QMI/rmnet functions. Bjørn ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH net] net: qmi_wwan: add support for Cinterion PLS8 2017-11-23 18:15 ` Bjørn Mork @ 2017-11-23 23:06 ` Reinhard Speyerer 2017-11-24 12:04 ` Oliver Graute 2017-11-24 18:25 ` Bjørn Mork 2017-11-24 12:02 ` Oliver Graute 2017-12-01 12:20 ` Oliver Graute 2 siblings, 2 replies; 10+ messages in thread From: Reinhard Speyerer @ 2017-11-23 23:06 UTC (permalink / raw) To: Bjørn Mork; +Cc: netdev, oliver.graute On Thu, Nov 23, 2017 at 07:15:37PM +0100, Bjørn Mork wrote: > Oliver Graute <oliver.graute@gmail.com> writes: > > On 23/11/17, Bjørn Mork wrote: > >> Oliver Graute <oliver.graute@gmail.com> writes: > >> > >> > When the PLS8 devices show up with PID 0x0061 they will expose both a > >> > QMI port and a WWAN interface. > >> > >> > >> Please remove the indentation. > > > > will do after we clarifed if this patch is really needed > > > >> Are you sure this is correct? The Windows drivers I found for this > >> device appear to think all functions use even interface numbers only, > >> presumably because of a control+data interface layout? > > > > honestly not. I have this change for some time in use with older kernel > > to get this PLS8 module working. Its pop-ups as usb0 network interface and > > with 5 /dev/ttyACM interfaces. Its gets an IP address from the provider. > > > > back then I also added this two lines: > > > > +++ V/drivers/usb/serial/option.c 2015-01-26 15:28:09.676671843 +0100 > > @@ -338,6 +338,7 @@ static void option_instat_callback(struc > > #define CINTERION_PRODUCT_PH8 0x0053 > > #define CINTERION_PRODUCT_AHXX 0x0055 > > #define CINTERION_PRODUCT_PLXX 0x0060 > > +#define CINTERION_PRODUCT_PLS8 0x0061 > > > > @@ -1251,6 +1252,7 @@ static const struct usb_device_id option > > { USB_DEVICE(CINTERION_VENDOR_ID, CINTERION_PRODUCT_PLXX), > > + { USB_DEVICE(CINTERION_VENDOR_ID, CINTERION_PRODUCT_PLS8), > > This should not be necessary and is wrong given the descriptors in your > lsusb outout. All the serial functions look like proper CDC ACM > functions which should Just Work with the cdc-acm class driver. No need > for any device specific entry for those. > > >> But I don't know anything about this device. Maybe the layout is > >> configurable without changing the device ID? Do you have any more > >> information you can provide, like for example a verbose lsusb output or > >> the relevant part of /sys/kernel/debug/usb/devices? > > > > here the output of lsusb -vvv > > > > Bus 002 Device 002: ID 1e2d:0061 > > Device Descriptor: > > bLength 18 > > bDescriptorType 1 > > bcdUSB 2.00 > > bDeviceClass 0 (Defined at Interface level) > > bDeviceSubClass 0 > > bDeviceProtocol 0 > > bMaxPacketSize0 64 > > idVendor 0x1e2d > > idProduct 0x0061 > > bcdDevice 2.32 > > iManufacturer 1 Cinterion > > iProduct 2 LTE Modem > > iSerial 0 > > bNumConfigurations 1 > > Configuration Descriptor: > > bLength 9 > > bDescriptorType 2 > > wTotalLength 497 > > bNumInterfaces 14 > > bConfigurationValue 1 > > iConfiguration 0 > > bmAttributes 0xe0 > > Self Powered > > Remote Wakeup > > MaxPower 20mA > > Interface Association: > > bLength 8 > > bDescriptorType 11 > > bFirstInterface 0 > > bInterfaceCount 2 > > bFunctionClass 2 Communications > > bFunctionSubClass 2 Abstract (modem) > > bFunctionProtocol 1 AT-commands (v.25ter) > > iFunction 5 CDC Serial > > Interface Descriptor: > > bLength 9 > > bDescriptorType 4 > > bInterfaceNumber 0 > > bAlternateSetting 0 > > bNumEndpoints 1 > > bInterfaceClass 2 Communications > > bInterfaceSubClass 2 Abstract (modem) > > bInterfaceProtocol 1 AT-commands (v.25ter) > > iInterface 3 CDC Abstract Control Model (ACM) > > CDC Header: > > bcdCDC 1.20 > > CDC Call Management: > > bmCapabilities 0x03 > > call management > > use DataInterface > > bDataInterface 1 > > CDC ACM: > > bmCapabilities 0x02 > > line coding and serial state > > CDC Union: > > bMasterInterface 0 > > bSlaveInterface 1 > > > > OK, this is consistent with the Windows driver files, so I believe your > patch could work. The USB interface it identified as QMI is in fact a > CDC ACM data interface. > > > > Interface Association: > > bLength 8 > > bDescriptorType 11 > > bFirstInterface 10 > > bInterfaceCount 2 > > bFunctionClass 2 Communications > > bFunctionSubClass 6 Ethernet Networking > > bFunctionProtocol 0 > > iFunction 9 CDC Ethernet (RmNet) > > Interface Descriptor: > > bLength 9 > > bDescriptorType 4 > > bInterfaceNumber 10 > > bAlternateSetting 0 > > bNumEndpoints 1 > > bInterfaceClass 2 Communications > > bInterfaceSubClass 6 Ethernet Networking > > bInterfaceProtocol 0 > > iInterface 10 CDC Ethernet Control Model (ECM) for RmNet > > CDC Header: > > bcdCDC 1.20 > > CDC Ethernet: > > iMacAddress 12 DEADBEEF0000 > > Nice mac address :-) > > This is also consistent with the Windows drivers. And being a proper > CDC ECM class function, it should Just Work with the cdc_ether driver. > Except for the "RmNet" part, which I guess is the reason you want to > add this device to qmi_wwan. Which is fine, *if* we can be reasonably > certain that it does support QMI. The description string is a strong > indication, but it would be even better to know this was tested. > > But adding this to qmi_wwan is not enough. You also need to add a > blacklist entry to cdc_ether. Both should use a device+class match, > similar to the Novatel entries. This will make the interface numbering > irrelevant, and will allow a single entry to match both QMI/rmnet > functions. Hi Bjørn, before posting this problem report https://developer.gemalto.com/threads/ipv6dualstack-problems-pls8-e-revision-03017 in the Gemalto developer forum I tested the qmi_wwan/cdc_ether changes you suggested above and apart from having two working QMI interfaces the IPv6/dualstack problems observed with AT^SWWAN/cdc_ether were also gone when using WDSStartNetworkInterface and the QMI interface in raw IP mode instead. Unfortunately Gemalto does no seems to be willing to provide an alternative USB composition which includes QMI interfaces for the PLS8. Therefore applying the above changes to qmi_wwan/cdc_ether might make the PLS8 network interfaces stop working when Gemalto decides to replace their f_rmnet gadget in CDCECM mode with a f_ecm gadget when releasing a firmware update. Regards, Reinhard ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH net] net: qmi_wwan: add support for Cinterion PLS8 2017-11-23 23:06 ` Reinhard Speyerer @ 2017-11-24 12:04 ` Oliver Graute 2017-11-24 18:25 ` Bjørn Mork 1 sibling, 0 replies; 10+ messages in thread From: Oliver Graute @ 2017-11-24 12:04 UTC (permalink / raw) To: netdev On 24/11/17, Reinhard Speyerer wrote: > before posting this problem report > https://developer.gemalto.com/threads/ipv6dualstack-problems-pls8-e-revision-03017 > in the Gemalto developer forum I tested the qmi_wwan/cdc_ether changes > you suggested above and apart from having two working QMI interfaces > the IPv6/dualstack problems observed with AT^SWWAN/cdc_ether were > also gone when using WDSStartNetworkInterface and the QMI interface in > raw IP mode instead. thx for sharing this information. IPv6 with PLS8-E is also a topic on our side Best Regards, Oliver ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH net] net: qmi_wwan: add support for Cinterion PLS8 2017-11-23 23:06 ` Reinhard Speyerer 2017-11-24 12:04 ` Oliver Graute @ 2017-11-24 18:25 ` Bjørn Mork 2017-11-26 15:16 ` Reinhard Speyerer 1 sibling, 1 reply; 10+ messages in thread From: Bjørn Mork @ 2017-11-24 18:25 UTC (permalink / raw) To: Reinhard Speyerer; +Cc: netdev, oliver.graute Reinhard Speyerer <rspmn@arcor.de> writes: > before posting this problem report > https://developer.gemalto.com/threads/ipv6dualstack-problems-pls8-e-revision-03017 > in the Gemalto developer forum I tested the qmi_wwan/cdc_ether changes > you suggested above and apart from having two working QMI interfaces > the IPv6/dualstack problems observed with AT^SWWAN/cdc_ether were > also gone when using WDSStartNetworkInterface and the QMI interface in > raw IP mode instead. Right. I did not know about the "carrier off" issue. But messed up ethernet headers is a well known problem with all these Qualcomm based modems. Switching them to raw IP mode is often the only way to make them work consistently. Having seen this problem with multiple vendors, where some even have borrowed our workarounds for their own out-of-tree drivers, makes me pretty sure that it isn't easily fixable. It's a Qualcomm bug, and I guess no one is allowed to even look at the code. Much less change it. Which makes sense given the mess it must be... > Unfortunately Gemalto does no seems to be willing to provide an > alternative USB composition which includes QMI interfaces for the > PLS8. Therefore applying the above changes to qmi_wwan/cdc_ether might > make the PLS8 network interfaces stop working when Gemalto decides to > replace their f_rmnet gadget in CDCECM mode with a f_ecm gadget when > releasing a firmware update. I don't think this is necessarily a problem. Only the QMI control channel will stop working should this happen. The qmi_wwan driver will provide the same network device support as cdc_ether, using CDC ECM framing. And to be honest, such a redesign of the modem application for a mature product is very unlikely, isn't it? Why would Gemalto want to do all that extra work, taking the risks involved? For what possible purpose? This is probably the reason they don't want to mess with alternative USB compositions either. In any case, I think it is worth adding this device to qmi_wwan if it works with current firmwares and you, or anyone else, finds it useful. And it does sound like that based on the IPv6 issues you mention.. But I'll leave the decision to you or anyone else with such a device. Bjørn ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH net] net: qmi_wwan: add support for Cinterion PLS8 2017-11-24 18:25 ` Bjørn Mork @ 2017-11-26 15:16 ` Reinhard Speyerer 0 siblings, 0 replies; 10+ messages in thread From: Reinhard Speyerer @ 2017-11-26 15:16 UTC (permalink / raw) To: Bjørn Mork; +Cc: netdev, oliver.graute On Fri, Nov 24, 2017 at 07:25:19PM +0100, Bjørn Mork wrote: > Reinhard Speyerer <rspmn@arcor.de> writes: > > > before posting this problem report > > https://developer.gemalto.com/threads/ipv6dualstack-problems-pls8-e-revision-03017 > > in the Gemalto developer forum I tested the qmi_wwan/cdc_ether changes > > you suggested above and apart from having two working QMI interfaces > > the IPv6/dualstack problems observed with AT^SWWAN/cdc_ether were > > also gone when using WDSStartNetworkInterface and the QMI interface in > > raw IP mode instead. > > Right. I did not know about the "carrier off" issue. But messed up > ethernet headers is a well known problem with all these Qualcomm based > modems. Switching them to raw IP mode is often the only way to make them > work consistently. > > Having seen this problem with multiple vendors, where some even have > borrowed our workarounds for their own out-of-tree drivers, makes me > pretty sure that it isn't easily fixable. It's a Qualcomm bug, and I > guess no one is allowed to even look at the code. Much less change it. > Which makes sense given the mess it must be... > > > Unfortunately Gemalto does no seems to be willing to provide an > > alternative USB composition which includes QMI interfaces for the > > PLS8. Therefore applying the above changes to qmi_wwan/cdc_ether might > > make the PLS8 network interfaces stop working when Gemalto decides to > > replace their f_rmnet gadget in CDCECM mode with a f_ecm gadget when > > releasing a firmware update. > > I don't think this is necessarily a problem. Only the QMI control > channel will stop working should this happen. The qmi_wwan driver will > provide the same network device support as cdc_ether, using CDC ECM > framing. > > And to be honest, such a redesign of the modem application for a mature > product is very unlikely, isn't it? Why would Gemalto want to do all > that extra work, taking the risks involved? For what possible purpose? > This is probably the reason they don't want to mess with alternative USB > compositions either. > > In any case, I think it is worth adding this device to qmi_wwan if it > works with current firmwares and you, or anyone else, finds it useful. > And it does sound like that based on the IPv6 issues you mention.. > > But I'll leave the decision to you or anyone else with such a device. Hi Bjørn, given that the PLS8 USB PID 0x0061 is also used by firmware version 02.x which has been relased quite some time ago I'm afraid switching it from cdc_ether to qmi_wwan in the mainline Linux kernel now might break too many existing/working setups even if only for the changed interface name. Since Gemalto also seems to have moved away from supporting USB compositions with a QMI interface with newer firmware versions in general they might as well reserve the right to reject problem reports submitted to them when not using their AT^SWWAN/CDCECM setup. Therefore I will not submit patches which switch PLS8 with USB PID 0x0061 from the cdc_ether to the qmi_wwan driver. If there are other PLS8 users who don't share my concerns: please feel free to submit the patches yourself. Let's hope that Gemalto is able to fix the AT^SWWAN/CDCECM-specific IPv6/dualstack problems in their forthcoming PLS8 firmware version 04.x or provides an alternative USB composition if the effort for fixing the bugs would be too high. Regards, Reinhard ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH net] net: qmi_wwan: add support for Cinterion PLS8 2017-11-23 18:15 ` Bjørn Mork 2017-11-23 23:06 ` Reinhard Speyerer @ 2017-11-24 12:02 ` Oliver Graute 2017-12-01 12:20 ` Oliver Graute 2 siblings, 0 replies; 10+ messages in thread From: Oliver Graute @ 2017-11-24 12:02 UTC (permalink / raw) To: netdev On 23/11/17, Bjørn Mork wrote: > > This is also consistent with the Windows drivers. And being a proper > CDC ECM class function, it should Just Work with the cdc_ether driver. > Except for the "RmNet" part, which I guess is the reason you want to > add this device to qmi_wwan. Which is fine, *if* we can be reasonably > certain that it does support QMI. The description string is a strong > indication, but it would be even better to know this was tested. > > But adding this to qmi_wwan is not enough. You also need to add a > blacklist entry to cdc_ether. Both should use a device+class match, > similar to the Novatel entries. This will make the interface numbering > irrelevant, and will allow a single entry to match both QMI/rmnet > functions. ok I tried it this way: +++ b/drivers/net/usb/cdc_ether.c @@ -562,6 +562,7 @@ static void usbnet_cdc_zte_status(struct usbnet *dev, struct urb *urb) #define MICROSOFT_VENDOR_ID 0x045e #define UBLOX_VENDOR_ID 0x1546 #define TPLINK_VENDOR_ID 0x2357 +#define CINTERION_VENDOR_ID 0x1e2d static const struct usb_device_id products[] = { /* BLACKLIST !! @@ -821,6 +822,13 @@ static void usbnet_cdc_zte_status(struct usbnet *dev, struct urb *urb) .driver_info = 0, }, +/* Cinterion PLS8 - handled by qmi_wwan */ +{ + USB_DEVICE_AND_INTERFACE_INFO(CINTERION_VENDOR_ID, 0x0061, USB_CLASS_COMM, + USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE), + .driver_info = 0, +}, + /* WHITELIST!!! * * CDC Ether uses two interfaces, not necessarily consecutive. diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c index 720a3a2..93e102e 100644 --- a/drivers/net/usb/qmi_wwan.c +++ b/drivers/net/usb/qmi_wwan.c @@ -1221,6 +1221,7 @@ static int qmi_wwan_resume(struct usb_interface *intf) {QMI_FIXED_INTF(0x0b3c, 0xc00a, 6)}, /* Olivetti Olicard 160 */ {QMI_FIXED_INTF(0x0b3c, 0xc00b, 4)}, /* Olivetti Olicard 500 */ {QMI_FIXED_INTF(0x1e2d, 0x0060, 4)}, /* Cinterion PLxx */ + {QMI_FIXED_INTF(0x1e2d, 0x0061, 3)}, /* Cinterion PLS8 LTE */ {QMI_FIXED_INTF(0x1e2d, 0x0053, 4)}, /* Cinterion PHxx,PXxx */ {QMI_FIXED_INTF(0x1e2d, 0x0082, 4)}, /* Cinterion PHxx,PXxx (2 RmNet) */ {QMI_FIXED_INTF(0x1e2d, 0x0082, 5)}, /* Cinterion PHxx,PXxx (2 RmNet) */ but now I'am missing an ttyACM4 interface and the edc_ether registering is not working anymore. [ 124.310611] usb 2-1: new high-speed USB device number 2 using ci_hdrc [ 124.457029] usb 2-1: New USB device found, idVendor=1e2d, idProduct=0061 [ 124.463938] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 124.471307] usb 2-1: Product: LTE Modem [ 124.475278] usb 2-1: Manufacturer: Cinterion [ 124.536219] cdc_acm 2-1:1.0: ttyACM0: USB ACM device [ 124.563155] cdc_acm 2-1:1.2: ttyACM1: USB ACM device [ 124.589625] cdc_acm 2-1:1.4: ttyACM2: USB ACM device [ 124.613517] cdc_acm 2-1:1.6: ttyACM3: USB ACM device in my working old setup with kernel 3.9.11 it looks like this: [ 129.710622] usb 2-1: new high-speed USB device number 2 using ci_hdrc [ 129.873985] usb 2-1: New USB device found, idVendor=1e2d, idProduct=0061 [ 129.888573] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 129.902973] usb 2-1: Product: LTE Modem [ 129.906927] usb 2-1: Manufacturer: Cinterion [ 129.928389] cdc_acm 2-1:1.0: ttyACM0: USB ACM device [ 129.959324] cdc_acm 2-1:1.2: ttyACM1: USB ACM device [ 129.992714] cdc_acm 2-1:1.4: ttyACM2: USB ACM device [ 130.019416] cdc_acm 2-1:1.6: ttyACM3: USB ACM device [ 130.045248] cdc_acm 2-1:1.8: This device cannot do calls on its own. It is not a modem. [ 130.073929] cdc_acm 2-1:1.8: ttyACM4: USB ACM device [ 130.100982] cdc_ether 2-1:1.10 usb0: register 'cdc_ether' at usb-ci_hdrc.1-1, CDC Ethernet Device, de:ad:be:ef:00:00 [ 130.136438] cdc_ether 2-1:1.12 usb1: register 'cdc_ether' at usb-ci_hdrc.1-1, CDC Ethernet Device, de:ad:be:ef:00:01 Any clue what I'am doing wrong here? Best regards, Oliver ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH net] net: qmi_wwan: add support for Cinterion PLS8 2017-11-23 18:15 ` Bjørn Mork 2017-11-23 23:06 ` Reinhard Speyerer 2017-11-24 12:02 ` Oliver Graute @ 2017-12-01 12:20 ` Oliver Graute 2 siblings, 0 replies; 10+ messages in thread From: Oliver Graute @ 2017-12-01 12:20 UTC (permalink / raw) To: netdev; +Cc: bjorn On 23/11/17, Bjørn Mork wrote: > This is also consistent with the Windows drivers. And being a proper > CDC ECM class function, it should Just Work with the cdc_ether driver. > Except for the "RmNet" part, which I guess is the reason you want to > add this device to qmi_wwan. Which is fine, *if* we can be reasonably > certain that it does support QMI. The description string is a strong > indication, but it would be even better to know this was tested. > > But adding this to qmi_wwan is not enough. You also need to add a > blacklist entry to cdc_ether. Both should use a device+class match, > similar to the Novatel entries. This will make the interface numbering > irrelevant, and will allow a single entry to match both QMI/rmnet > functions. I tried the following changes but I still can't get the PLS8 to work with kernel 4.14. Here some more information what I have and what I did. The Module is in this Revsion: Cinterion PLS8-E REVISION 02.011 A-REVISION 01.010.19 --- a/drivers/net/usb/qmi_wwan.c +++ b/drivers/net/usb/qmi_wwan.c @@ -779,6 +779,7 @@ static const struct usb_device_id products[] = { {QMI_FIXED_INTF(0x0b3c, 0xc00a, 6)}, /* Olivetti Olicard 160 */ {QMI_FIXED_INTF(0x0b3c, 0xc00b, 4)}, /* Olivetti Olicard 500 */ {QMI_FIXED_INTF(0x1e2d, 0x0060, 4)}, /* Cinterion PLxx */ + {QMI_FIXED_INTF(0x1e2d, 0x0061, 3)}, /* Cinterion PLS8 */ {QMI_FIXED_INTF(0x1e2d, 0x0053, 4)}, /* Cinterion PHxx,PXxx */ {QMI_FIXED_INTF(0x413c, 0x81a2, 8)}, /* Dell Wireless 5806 Gobi(TM) 4G LTE Mobile Broadband Card */ {QMI_FIXED_INTF(0x413c, 0x81a3, 8)}, /* Dell Wireless 5570 HSPA+ (42Mbps) Mobile Broadband Card */ I tried the value 4 instead of 3. here but both won't work. In my working old setup with Kernel 3.9.11 the value is 3. and this was the only change back then. +++ b/drivers/net/usb/cdc_ether.c @@ -562,6 +562,7 @@ static void usbnet_cdc_zte_status(struct usbnet *dev, struct urb *urb) #define MICROSOFT_VENDOR_ID 0x045e #define UBLOX_VENDOR_ID 0x1546 #define TPLINK_VENDOR_ID 0x2357 +#define CINTERION_VENDOR_ID 0x1e2d static const struct usb_device_id products[] = { /* BLACKLIST !! @@ -821,6 +822,13 @@ static void usbnet_cdc_zte_status(struct usbnet *dev, struct urb *urb) .driver_info = 0, }, +/* Cinterion PLS8 - handled by qmi_wwan */ +{ + USB_DEVICE_AND_INTERFACE_INFO(CINTERION_VENDOR_ID, 0x0061, USB_CLASS_COMM, + USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE), + .driver_info = 0, +}, This change wasn't necessary in my old setup with the PLS8. Can you explain me why its needed now? This is the output I get with dmesg. [ 747.989455] usb 2-1: USB disconnect, device number 11 [ 748.694818] usb 2-1: new high-speed USB device number 12 using ci_hdrc [ 748.856821] usb 2-1: New USB device found, idVendor=1e2d, idProduct=0061 [ 748.863712] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 748.871112] usb 2-1: Product: LTE Modem [ 748.875109] usb 2-1: Manufacturer: Cinterion [ 748.895201] cdc_acm 2-1:1.0: ttyACM0: USB ACM device [ 748.915099] cdc_acm 2-1:1.2: ttyACM1: USB ACM device [ 748.933204] cdc_acm 2-1:1.4: ttyACM2: USB ACM device [ 748.952976] cdc_acm 2-1:1.6: ttyACM3: USB ACM device Then I try to connect to /dev/ttyACM1 to execute a "ati1" but without success. Best Regards, Oliver ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2017-12-01 12:22 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-11-23 13:37 [PATCH net] net: qmi_wwan: add support for Cinterion PLS8 Oliver Graute 2017-11-23 14:03 ` Bjørn Mork 2017-11-23 15:10 ` Oliver Graute 2017-11-23 18:15 ` Bjørn Mork 2017-11-23 23:06 ` Reinhard Speyerer 2017-11-24 12:04 ` Oliver Graute 2017-11-24 18:25 ` Bjørn Mork 2017-11-26 15:16 ` Reinhard Speyerer 2017-11-24 12:02 ` Oliver Graute 2017-12-01 12:20 ` Oliver Graute
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.