From mboxrd@z Thu Jan 1 00:00:00 1970 From: Reinhard Speyerer Subject: Re: [PATCH net] net: qmi_wwan: add support for Cinterion PLS8 Date: Fri, 24 Nov 2017 00:06:18 +0100 Message-ID: <20171123230617.6e4lc6b4qjgaqbc6@arcor.de> References: <1511444235-21710-1-git-send-email-oliver.graute@neuhaus.de> <878texks7h.fsf@miraculix.mork.no> <20171123151039.GF25252@graute-opti> <87zi7ckgja.fsf@miraculix.mork.no> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: netdev@vger.kernel.org, oliver.graute@gmail.com To: =?iso-8859-1?Q?Bj=F8rn?= Mork Return-path: Received: from vsmx012.vodafonemail.xion.oxcs.net ([153.92.174.90]:19057 "EHLO vsmx012.vodafonemail.xion.oxcs.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752423AbdKWXPn (ORCPT ); Thu, 23 Nov 2017 18:15:43 -0500 Content-Disposition: inline In-Reply-To: <87zi7ckgja.fsf@miraculix.mork.no> Sender: netdev-owner@vger.kernel.org List-ID: On Thu, Nov 23, 2017 at 07:15:37PM +0100, Bjørn Mork wrote: > Oliver Graute writes: > > On 23/11/17, Bjørn Mork wrote: > >> Oliver Graute 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