* [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 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 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-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.