| Message ID | 20190226170710.12709-1-mans@mansr.com (mailing list archive) |
|---|---|
| State | Mainlined |
| Commit | f8df5c2c3e2df5ffaf9fb5503da93d477a8c7db4 |
| Headers | show |
| Series | USB: serial: option: set driver_info for SIM5218 and compatibles | expand |
On Tue, Feb 26, 2019 at 05:07:10PM +0000, Mans Rullgard wrote: > The SIMCom SIM5218 and compatible devices have 5 USB interfaces, only 4 > of which are serial ports. The fifth is a network interface supported > by the qmi-wwan driver. Furthermore, the serial ports do not support > modem control signals. Add driver_info flags to reflect this. > > Signed-off-by: Mans Rullgard <mans@mansr.com> > --- > drivers/usb/serial/option.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c > index fb544340888b..af4cbfecc3ff 100644 > --- a/drivers/usb/serial/option.c > +++ b/drivers/usb/serial/option.c > @@ -1066,7 +1066,8 @@ static const struct usb_device_id option_ids[] = { > .driver_info = RSVD(3) }, > { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x6613)}, /* Onda H600/ZTE MF330 */ > { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x0023)}, /* ONYX 3G device */ > - { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x9000)}, /* SIMCom SIM5218 */ > + { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x9000), /* SIMCom SIM5218 */ > + .driver_info = NCTRL(0) | NCTRL(1) | NCTRL(2) | NCTRL(3) | RSVD(4) }, > /* Quectel products using Qualcomm vendor ID */ > { USB_DEVICE(QUALCOMM_VENDOR_ID, QUECTEL_PRODUCT_UC15)}, > { USB_DEVICE(QUALCOMM_VENDOR_ID, QUECTEL_PRODUCT_UC20), Could you please provide the output of usb-devices (or lsusb -v) for this device? Thanks, Johan
Johan Hovold <johan@kernel.org> writes: > On Tue, Feb 26, 2019 at 05:07:10PM +0000, Mans Rullgard wrote: >> The SIMCom SIM5218 and compatible devices have 5 USB interfaces, only 4 >> of which are serial ports. The fifth is a network interface supported >> by the qmi-wwan driver. Furthermore, the serial ports do not support >> modem control signals. Add driver_info flags to reflect this. >> >> Signed-off-by: Mans Rullgard <mans@mansr.com> >> --- >> drivers/usb/serial/option.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c >> index fb544340888b..af4cbfecc3ff 100644 >> --- a/drivers/usb/serial/option.c >> +++ b/drivers/usb/serial/option.c >> @@ -1066,7 +1066,8 @@ static const struct usb_device_id option_ids[] = { >> .driver_info = RSVD(3) }, >> { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x6613)}, /* Onda H600/ZTE MF330 */ >> { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x0023)}, /* ONYX 3G device */ >> - { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x9000)}, /* SIMCom SIM5218 */ >> + { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x9000), /* SIMCom SIM5218 */ >> + .driver_info = NCTRL(0) | NCTRL(1) | NCTRL(2) | NCTRL(3) | RSVD(4) }, >> /* Quectel products using Qualcomm vendor ID */ >> { USB_DEVICE(QUALCOMM_VENDOR_ID, QUECTEL_PRODUCT_UC15)}, >> { USB_DEVICE(QUALCOMM_VENDOR_ID, QUECTEL_PRODUCT_UC20), > > Could you please provide the output of usb-devices (or lsusb -v) for > this device? lsusb -v: Bus 001 Device 003: ID 05c6:9000 Qualcomm, Inc. SIMCom SIM5218 modem Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x05c6 Qualcomm, Inc. idProduct 0x9000 SIMCom SIM5218 modem bcdDevice 0.00 iManufacturer 3 SimTech, Incorporated iProduct 2 SimTech SIM5360 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 138 bNumInterfaces 5 bConfigurationValue 1 iConfiguration 1 SimTech Configuration bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 0 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 32 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 32 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 32 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 32 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 0 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 32 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 32 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 3 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 0 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 5 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 32 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 32 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 4 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 0 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 5 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 32 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 32 Device Qualifier (for other device speed): bLength 10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass 0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 bNumConfigurations 1 can't get debug descriptor: Resource temporarily unavailable Device Status: 0x0000 (Bus Powered)
Adding Bjørn. On Wed, Feb 27, 2019 at 11:57:16AM +0000, Måns Rullgård wrote: > Johan Hovold <johan@kernel.org> writes: > > > On Tue, Feb 26, 2019 at 05:07:10PM +0000, Mans Rullgard wrote: > >> The SIMCom SIM5218 and compatible devices have 5 USB interfaces, only 4 > >> of which are serial ports. The fifth is a network interface supported > >> by the qmi-wwan driver. Furthermore, the serial ports do not support > >> modem control signals. Add driver_info flags to reflect this. > >> > >> Signed-off-by: Mans Rullgard <mans@mansr.com> > >> --- > >> drivers/usb/serial/option.c | 3 ++- > >> 1 file changed, 2 insertions(+), 1 deletion(-) > >> > >> diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c > >> index fb544340888b..af4cbfecc3ff 100644 > >> --- a/drivers/usb/serial/option.c > >> +++ b/drivers/usb/serial/option.c > >> @@ -1066,7 +1066,8 @@ static const struct usb_device_id option_ids[] = { > >> .driver_info = RSVD(3) }, > >> { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x6613)}, /* Onda H600/ZTE MF330 */ > >> { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x0023)}, /* ONYX 3G device */ > >> - { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x9000)}, /* SIMCom SIM5218 */ > >> + { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x9000), /* SIMCom SIM5218 */ > >> + .driver_info = NCTRL(0) | NCTRL(1) | NCTRL(2) | NCTRL(3) | RSVD(4) }, > >> /* Quectel products using Qualcomm vendor ID */ > >> { USB_DEVICE(QUALCOMM_VENDOR_ID, QUECTEL_PRODUCT_UC15)}, > >> { USB_DEVICE(QUALCOMM_VENDOR_ID, QUECTEL_PRODUCT_UC20), > > > > Could you please provide the output of usb-devices (or lsusb -v) for > > this device? > > lsusb -v: > Bus 001 Device 003: ID 05c6:9000 Qualcomm, Inc. SIMCom SIM5218 modem > Device Descriptor: > bLength 18 > bDescriptorType 1 > bcdUSB 2.00 > bDeviceClass 0 > bDeviceSubClass 0 > bDeviceProtocol 0 > bMaxPacketSize0 64 > idVendor 0x05c6 Qualcomm, Inc. > idProduct 0x9000 SIMCom SIM5218 modem > bcdDevice 0.00 > iManufacturer 3 SimTech, Incorporated > iProduct 2 SimTech SIM5360 > iSerial 0 > bNumConfigurations 1 > Configuration Descriptor: > bLength 9 > bDescriptorType 2 > wTotalLength 138 > bNumInterfaces 5 > bConfigurationValue 1 > iConfiguration 1 SimTech Configuration > bmAttributes 0xe0 > Self Powered > Remote Wakeup > MaxPower 500mA > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 0 > bAlternateSetting 0 > bNumEndpoints 2 > bInterfaceClass 255 Vendor Specific Class > bInterfaceSubClass 255 Vendor Specific Subclass > bInterfaceProtocol 255 Vendor Specific Protocol > iInterface 0 > 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 32 > 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 32 > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 1 > bAlternateSetting 0 > bNumEndpoints 2 > bInterfaceClass 255 Vendor Specific Class > bInterfaceSubClass 255 Vendor Specific Subclass > bInterfaceProtocol 255 Vendor Specific Protocol > iInterface 0 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x82 EP 2 IN > bmAttributes 2 > Transfer Type Bulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0200 1x 512 bytes > bInterval 32 > 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 32 > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 2 > bAlternateSetting 0 > bNumEndpoints 2 > bInterfaceClass 255 Vendor Specific Class > bInterfaceSubClass 255 Vendor Specific Subclass > bInterfaceProtocol 255 Vendor Specific Protocol > iInterface 0 > 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 32 > 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 32 > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 3 > bAlternateSetting 0 > bNumEndpoints 3 > bInterfaceClass 255 Vendor Specific Class > bInterfaceSubClass 255 Vendor Specific Subclass > bInterfaceProtocol 255 Vendor Specific Protocol > iInterface 0 > 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 5 > 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 32 > 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 32 > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 4 > bAlternateSetting 0 > bNumEndpoints 3 > bInterfaceClass 255 Vendor Specific Class > bInterfaceSubClass 255 Vendor Specific Subclass > bInterfaceProtocol 255 Vendor Specific Protocol > iInterface 0 > 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 5 > 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 32 > 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 32 > Device Qualifier (for other device speed): > bLength 10 > bDescriptorType 6 > bcdUSB 2.00 > bDeviceClass 0 > bDeviceSubClass 0 > bDeviceProtocol 0 > bMaxPacketSize0 64 > bNumConfigurations 1 > can't get debug descriptor: Resource temporarily unavailable > Device Status: 0x0000 > (Bus Powered) So the patch looks fine to me. The fifth interface is QMI, but hasn't been available for use until now then, and this seems to have been the vendors idea from the start: http://www.microchip.ua/simcom/WCDMA/APPNOTES/SIMCom_3G_Linux_driver_Application%20Note_V1.00.pdf And you're seeing errors when opening ports 0-3 due to the DTR calls which I guess no one noticed or cared about before? Before you sent me the lsusb I searched for it and came across the below thread where Bjørn's having a go at SIMCom. In it there's output from a second device using the same id but with entirely different descriptors. https://forum.openwrt.org/t/lte-wireless-module-support-by-openwrt-led-on-tplink/13586?page=3 If this is a common theme with this vendor we may need to be extra careful when making changes. Johan
Johan Hovold <johan@kernel.org> writes: > Adding Bjørn. > > On Wed, Feb 27, 2019 at 11:57:16AM +0000, Måns Rullgård wrote: >> Johan Hovold <johan@kernel.org> writes: >> >> > On Tue, Feb 26, 2019 at 05:07:10PM +0000, Mans Rullgard wrote: >> >> The SIMCom SIM5218 and compatible devices have 5 USB interfaces, only 4 >> >> of which are serial ports. The fifth is a network interface supported >> >> by the qmi-wwan driver. Furthermore, the serial ports do not support >> >> modem control signals. Add driver_info flags to reflect this. >> >> >> >> Signed-off-by: Mans Rullgard <mans@mansr.com> >> >> --- >> >> drivers/usb/serial/option.c | 3 ++- >> >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> >> >> diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c >> >> index fb544340888b..af4cbfecc3ff 100644 >> >> --- a/drivers/usb/serial/option.c >> >> +++ b/drivers/usb/serial/option.c >> >> @@ -1066,7 +1066,8 @@ static const struct usb_device_id option_ids[] = { >> >> .driver_info = RSVD(3) }, >> >> { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x6613)}, /* Onda H600/ZTE MF330 */ >> >> { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x0023)}, /* ONYX 3G device */ >> >> - { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x9000)}, /* SIMCom SIM5218 */ >> >> + { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x9000), /* SIMCom SIM5218 */ >> >> + .driver_info = NCTRL(0) | NCTRL(1) | NCTRL(2) | NCTRL(3) | RSVD(4) }, >> >> /* Quectel products using Qualcomm vendor ID */ >> >> { USB_DEVICE(QUALCOMM_VENDOR_ID, QUECTEL_PRODUCT_UC15)}, >> >> { USB_DEVICE(QUALCOMM_VENDOR_ID, QUECTEL_PRODUCT_UC20), >> > >> > Could you please provide the output of usb-devices (or lsusb -v) for >> > this device? >> >> lsusb -v: >> [...] > So the patch looks fine to me. The fifth interface is QMI, but hasn't > been available for use until now then, and this seems to have been the > vendors idea from the start: > > http://www.microchip.ua/simcom/WCDMA/APPNOTES/SIMCom_3G_Linux_driver_Application%20Note_V1.00.pdf That document predates the qmi-wwan driver in the kernel. Note that this driver has an ID table entry for interface 4 of this device. Right now, whichever driver is probed first claims that interface. I haven't actually tried using the QMI interface, though. > And you're seeing errors when opening ports 0-3 due to the DTR calls > which I guess no one noticed or cared about before? Right, some userspace tools complain about this. > Before you sent me the lsusb I searched for it and came across the below > thread where Bjørn's having a go at SIMCom. In it there's output from a > second device using the same id but with entirely different descriptors. > > https://forum.openwrt.org/t/lte-wireless-module-support-by-openwrt-led-on-tplink/13586?page=3 > > If this is a common theme with this vendor we may need to be extra > careful when making changes. Isn't this a common theme with most USB vendors, especially wireless things? Regardless, setting the NCTRL flag should be harmless.
Måns Rullgård <mans@mansr.com> writes: > Johan Hovold <johan@kernel.org> writes: > >> Adding Bjørn. >> >> On Wed, Feb 27, 2019 at 11:57:16AM +0000, Måns Rullgård wrote: >>> Johan Hovold <johan@kernel.org> writes: >>> >>> > On Tue, Feb 26, 2019 at 05:07:10PM +0000, Mans Rullgard wrote: >>> >> The SIMCom SIM5218 and compatible devices have 5 USB interfaces, only 4 >>> >> of which are serial ports. The fifth is a network interface supported >>> >> by the qmi-wwan driver. Furthermore, the serial ports do not support >>> >> modem control signals. Add driver_info flags to reflect this. >>> >> >>> >> Signed-off-by: Mans Rullgard <mans@mansr.com> >>> >> --- >>> >> drivers/usb/serial/option.c | 3 ++- >>> >> 1 file changed, 2 insertions(+), 1 deletion(-) >>> >> >>> >> diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c >>> >> index fb544340888b..af4cbfecc3ff 100644 >>> >> --- a/drivers/usb/serial/option.c >>> >> +++ b/drivers/usb/serial/option.c >>> >> @@ -1066,7 +1066,8 @@ static const struct usb_device_id option_ids[] = { >>> >> .driver_info = RSVD(3) }, >>> >> { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x6613)}, /* Onda H600/ZTE MF330 */ >>> >> { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x0023)}, /* ONYX 3G device */ >>> >> - { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x9000)}, /* SIMCom SIM5218 */ >>> >> + { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x9000), /* SIMCom SIM5218 */ >>> >> + .driver_info = NCTRL(0) | NCTRL(1) | NCTRL(2) | NCTRL(3) | RSVD(4) }, >>> >> /* Quectel products using Qualcomm vendor ID */ >>> >> { USB_DEVICE(QUALCOMM_VENDOR_ID, QUECTEL_PRODUCT_UC15)}, >>> >> { USB_DEVICE(QUALCOMM_VENDOR_ID, QUECTEL_PRODUCT_UC20), >>> > >>> > Could you please provide the output of usb-devices (or lsusb -v) for >>> > this device? >>> >>> lsusb -v: >>> [...] > >> So the patch looks fine to me. The fifth interface is QMI, but hasn't >> been available for use until now then, and this seems to have been the >> vendors idea from the start: >> >> http://www.microchip.ua/simcom/WCDMA/APPNOTES/SIMCom_3G_Linux_driver_Application%20Note_V1.00.pdf > > That document predates the qmi-wwan driver in the kernel. Note that > this driver has an ID table entry for interface 4 of this device. Right > now, whichever driver is probed first claims that interface. I haven't > actually tried using the QMI interface, though. > >> And you're seeing errors when opening ports 0-3 due to the DTR calls >> which I guess no one noticed or cared about before? > > Right, some userspace tools complain about this. > >> Before you sent me the lsusb I searched for it and came across the below >> thread where Bjørn's having a go at SIMCom. In it there's output from a >> second device using the same id but with entirely different descriptors. >> >> https://forum.openwrt.org/t/lte-wireless-module-support-by-openwrt-led-on-tplink/13586?page=3 >> >> If this is a common theme with this vendor we may need to be extra >> careful when making changes. > > Isn't this a common theme with most USB vendors, especially wireless things? > > Regardless, setting the NCTRL flag should be harmless. Any further comments on this?
On Wed, Feb 27, 2019 at 02:32:58PM +0000, Måns Rullgård wrote: > Johan Hovold <johan@kernel.org> writes: > > > Adding Bjørn. > > > > On Wed, Feb 27, 2019 at 11:57:16AM +0000, Måns Rullgård wrote: > >> Johan Hovold <johan@kernel.org> writes: > >> > >> > On Tue, Feb 26, 2019 at 05:07:10PM +0000, Mans Rullgard wrote: > >> >> The SIMCom SIM5218 and compatible devices have 5 USB interfaces, only 4 > >> >> of which are serial ports. The fifth is a network interface supported > >> >> by the qmi-wwan driver. Furthermore, the serial ports do not support > >> >> modem control signals. Add driver_info flags to reflect this. > >> >> > >> >> Signed-off-by: Mans Rullgard <mans@mansr.com> > >> >> --- > >> >> drivers/usb/serial/option.c | 3 ++- > >> >> 1 file changed, 2 insertions(+), 1 deletion(-) > >> >> > >> >> diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c > >> >> index fb544340888b..af4cbfecc3ff 100644 > >> >> --- a/drivers/usb/serial/option.c > >> >> +++ b/drivers/usb/serial/option.c > >> >> @@ -1066,7 +1066,8 @@ static const struct usb_device_id option_ids[] = { > >> >> .driver_info = RSVD(3) }, > >> >> { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x6613)}, /* Onda H600/ZTE MF330 */ > >> >> { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x0023)}, /* ONYX 3G device */ > >> >> - { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x9000)}, /* SIMCom SIM5218 */ > >> >> + { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x9000), /* SIMCom SIM5218 */ > >> >> + .driver_info = NCTRL(0) | NCTRL(1) | NCTRL(2) | NCTRL(3) | RSVD(4) }, > >> >> /* Quectel products using Qualcomm vendor ID */ > >> >> { USB_DEVICE(QUALCOMM_VENDOR_ID, QUECTEL_PRODUCT_UC15)}, > >> >> { USB_DEVICE(QUALCOMM_VENDOR_ID, QUECTEL_PRODUCT_UC20), > >> > > >> > Could you please provide the output of usb-devices (or lsusb -v) for > >> > this device? > >> > >> lsusb -v: > >> [...] > > > So the patch looks fine to me. The fifth interface is QMI, but hasn't > > been available for use until now then, and this seems to have been the > > vendors idea from the start: > > > > http://www.microchip.ua/simcom/WCDMA/APPNOTES/SIMCom_3G_Linux_driver_Application%20Note_V1.00.pdf > > That document predates the qmi-wwan driver in the kernel. Note that > this driver has an ID table entry for interface 4 of this device. Right > now, whichever driver is probed first claims that interface. I haven't > actually tried using the QMI interface, though. I didn't say it was correct, just that the vendor proposed binding to it anyway. > > And you're seeing errors when opening ports 0-3 due to the DTR calls > > which I guess no one noticed or cared about before? > > Right, some userspace tools complain about this. Hmm. You shouldn't see any errors on open (they're not even logged), but I guess your user space tools complains on receiving -EPROTO instead of -EINVAL when trying to manage these signals directly? > > Before you sent me the lsusb I searched for it and came across the below > > thread where Bjørn's having a go at SIMCom. In it there's output from a > > second device using the same id but with entirely different descriptors. > > > > https://forum.openwrt.org/t/lte-wireless-module-support-by-openwrt-led-on-tplink/13586?page=3 > > > > If this is a common theme with this vendor we may need to be extra > > careful when making changes. > > Isn't this a common theme with most USB vendors, especially wireless things? > > Regardless, setting the NCTRL flag should be harmless. Well, there are devices that depend on getting these requests, at least for the QMI interface. But we can always revert if anyone complains. Now applied, thanks. Johan
Johan Hovold <johan@kernel.org> writes: > On Wed, Feb 27, 2019 at 02:32:58PM +0000, Måns Rullgård wrote: >> Johan Hovold <johan@kernel.org> writes: >> >> > Adding Bjørn. >> > >> > On Wed, Feb 27, 2019 at 11:57:16AM +0000, Måns Rullgård wrote: >> >> Johan Hovold <johan@kernel.org> writes: >> >> >> >> > On Tue, Feb 26, 2019 at 05:07:10PM +0000, Mans Rullgard wrote: >> >> >> The SIMCom SIM5218 and compatible devices have 5 USB interfaces, only 4 >> >> >> of which are serial ports. The fifth is a network interface supported >> >> >> by the qmi-wwan driver. Furthermore, the serial ports do not support >> >> >> modem control signals. Add driver_info flags to reflect this. >> >> >> >> >> >> Signed-off-by: Mans Rullgard <mans@mansr.com> >> >> >> --- >> >> >> drivers/usb/serial/option.c | 3 ++- >> >> >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> >> >> >> >> diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c >> >> >> index fb544340888b..af4cbfecc3ff 100644 >> >> >> --- a/drivers/usb/serial/option.c >> >> >> +++ b/drivers/usb/serial/option.c >> >> >> @@ -1066,7 +1066,8 @@ static const struct usb_device_id option_ids[] = { >> >> >> .driver_info = RSVD(3) }, >> >> >> { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x6613)}, /* Onda H600/ZTE MF330 */ >> >> >> { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x0023)}, /* ONYX 3G device */ >> >> >> - { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x9000)}, /* SIMCom SIM5218 */ >> >> >> + { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x9000), /* SIMCom SIM5218 */ >> >> >> + .driver_info = NCTRL(0) | NCTRL(1) | NCTRL(2) | NCTRL(3) | RSVD(4) }, >> >> >> /* Quectel products using Qualcomm vendor ID */ >> >> >> { USB_DEVICE(QUALCOMM_VENDOR_ID, QUECTEL_PRODUCT_UC15)}, >> >> >> { USB_DEVICE(QUALCOMM_VENDOR_ID, QUECTEL_PRODUCT_UC20), >> >> > >> >> > Could you please provide the output of usb-devices (or lsusb -v) for >> >> > this device? >> >> >> >> lsusb -v: >> >> [...] >> >> > So the patch looks fine to me. The fifth interface is QMI, but hasn't >> > been available for use until now then, and this seems to have been the >> > vendors idea from the start: >> > >> > http://www.microchip.ua/simcom/WCDMA/APPNOTES/SIMCom_3G_Linux_driver_Application%20Note_V1.00.pdf >> >> That document predates the qmi-wwan driver in the kernel. Note that >> this driver has an ID table entry for interface 4 of this device. Right >> now, whichever driver is probed first claims that interface. I haven't >> actually tried using the QMI interface, though. > > I didn't say it was correct, just that the vendor proposed binding to it > anyway. > >> > And you're seeing errors when opening ports 0-3 due to the DTR calls >> > which I guess no one noticed or cared about before? >> >> Right, some userspace tools complain about this. > > Hmm. You shouldn't see any errors on open (they're not even logged), but > I guess your user space tools complains on receiving -EPROTO instead of > -EINVAL when trying to manage these signals directly? Yes, one specific case is pyserial. On open, it attempts to set those signals and, depending on the error returned, either aborts or marks them as unavailable. >> > Before you sent me the lsusb I searched for it and came across the below >> > thread where Bjørn's having a go at SIMCom. In it there's output from a >> > second device using the same id but with entirely different descriptors. >> > >> > https://forum.openwrt.org/t/lte-wireless-module-support-by-openwrt-led-on-tplink/13586?page=3 >> > >> > If this is a common theme with this vendor we may need to be extra >> > careful when making changes. >> >> Isn't this a common theme with most USB vendors, especially wireless things? >> >> Regardless, setting the NCTRL flag should be harmless. > > Well, there are devices that depend on getting these requests, at least > for the QMI interface. But we can always revert if anyone complains. The QMI interface doesn't even pretend to be a uart. The other ones do, but there isn't actually any real uart behind them. For instance, it doesn't matter what baud rate one sets. > Now applied, thanks. Thanks.
On Tue, Mar 19, 2019 at 10:54:00AM +0000, Måns Rullgård wrote: > Johan Hovold <johan@kernel.org> writes: > >> Regardless, setting the NCTRL flag should be harmless. > > > > Well, there are devices that depend on getting these requests, at least > > for the QMI interface. But we can always revert if anyone complains. > > The QMI interface doesn't even pretend to be a uart. The other ones do, > but there isn't actually any real uart behind them. For instance, it > doesn't matter what baud rate one sets. Sure, but some devices still require "DTR" to be set for the QMI interface, so there not being any real uart is no guarantee that there is no firmware that expects these calls. Johan
Johan Hovold <johan@kernel.org> writes: > On Tue, Mar 19, 2019 at 10:54:00AM +0000, Måns Rullgård wrote: >> Johan Hovold <johan@kernel.org> writes: > >> >> Regardless, setting the NCTRL flag should be harmless. >> > >> > Well, there are devices that depend on getting these requests, at least >> > for the QMI interface. But we can always revert if anyone complains. >> >> The QMI interface doesn't even pretend to be a uart. The other ones do, >> but there isn't actually any real uart behind them. For instance, it >> doesn't matter what baud rate one sets. > > Sure, but some devices still require "DTR" to be set for the QMI > interface, so there not being any real uart is no guarantee that there > is no firmware that expects these calls. Now I'm thoroughly confused. The QMI interface has a completely separate driver that creates a network device (if I'm reading the code correctly).
On Tue, Mar 19, 2019 at 12:25:53PM +0000, Måns Rullgård wrote: > Johan Hovold <johan@kernel.org> writes: > > > On Tue, Mar 19, 2019 at 10:54:00AM +0000, Måns Rullgård wrote: > >> Johan Hovold <johan@kernel.org> writes: > > > >> >> Regardless, setting the NCTRL flag should be harmless. > >> > > >> > Well, there are devices that depend on getting these requests, at least > >> > for the QMI interface. But we can always revert if anyone complains. > >> > >> The QMI interface doesn't even pretend to be a uart. The other ones do, > >> but there isn't actually any real uart behind them. For instance, it > >> doesn't matter what baud rate one sets. > > > > Sure, but some devices still require "DTR" to be set for the QMI > > interface, so there not being any real uart is no guarantee that there > > is no firmware that expects these calls. > > Now I'm thoroughly confused. The QMI interface has a completely > separate driver that creates a network device (if I'm reading the code > correctly). I was just giving an example of firmware sometimes doing unexpected things. Johan
On Tue, Mar 19, 2019 at 01:27:19PM +0100, Johan Hovold wrote: > On Tue, Mar 19, 2019 at 12:25:53PM +0000, Måns Rullgård wrote: > > Johan Hovold <johan@kernel.org> writes: > > > > > On Tue, Mar 19, 2019 at 10:54:00AM +0000, Måns Rullgård wrote: > > >> Johan Hovold <johan@kernel.org> writes: > > > > > >> >> Regardless, setting the NCTRL flag should be harmless. > > >> > > > >> > Well, there are devices that depend on getting these requests, at least > > >> > for the QMI interface. But we can always revert if anyone complains. > > >> > > >> The QMI interface doesn't even pretend to be a uart. The other ones do, > > >> but there isn't actually any real uart behind them. For instance, it > > >> doesn't matter what baud rate one sets. > > > > > > Sure, but some devices still require "DTR" to be set for the QMI > > > interface, so there not being any real uart is no guarantee that there > > > is no firmware that expects these calls. > > > > Now I'm thoroughly confused. The QMI interface has a completely > > separate driver that creates a network device (if I'm reading the code > > correctly). > > I was just giving an example of firmware sometimes doing unexpected > things. See 93725149794d ("net: qmi_wwan: MDM9x30 specific power management") for some background. Johan
On Tue, 2019-03-19 at 13:43 +0100, Johan Hovold wrote: > On Tue, Mar 19, 2019 at 01:27:19PM +0100, Johan Hovold wrote: > > On Tue, Mar 19, 2019 at 12:25:53PM +0000, Måns Rullgård wrote: > > > Johan Hovold <johan@kernel.org> writes: > > > > > > > On Tue, Mar 19, 2019 at 10:54:00AM +0000, Måns Rullgård wrote: > > > > > Johan Hovold <johan@kernel.org> writes: > > > > > > > Regardless, setting the NCTRL flag should be harmless. > > > > > > > > > > > > Well, there are devices that depend on getting these > > > > > > requests, at least > > > > > > for the QMI interface. But we can always revert if anyone > > > > > > complains. > > > > > > > > > > The QMI interface doesn't even pretend to be a uart. The > > > > > other ones do, > > > > > but there isn't actually any real uart behind them. For > > > > > instance, it > > > > > doesn't matter what baud rate one sets. > > > > > > > > Sure, but some devices still require "DTR" to be set for the > > > > QMI > > > > interface, so there not being any real uart is no guarantee > > > > that there > > > > is no firmware that expects these calls. > > > > > > Now I'm thoroughly confused. The QMI interface has a completely > > > separate driver that creates a network device (if I'm reading the > > > code > > > correctly). > > > > I was just giving an example of firmware sometimes doing unexpected > > things. > > See 93725149794d ("net: qmi_wwan: MDM9x30 specific power management") > for some background. TLDR; some firmware uses the DTR signal as an indicator to come out of low-power mode. Without doing so you cannot talk to the modem over any of it's ports, QMI, net, or serial. Dan
Dan Williams <dcbw@redhat.com> writes: > On Tue, 2019-03-19 at 13:43 +0100, Johan Hovold wrote: >> On Tue, Mar 19, 2019 at 01:27:19PM +0100, Johan Hovold wrote: >> > On Tue, Mar 19, 2019 at 12:25:53PM +0000, Måns Rullgård wrote: >> > > Johan Hovold <johan@kernel.org> writes: >> > > >> > > > On Tue, Mar 19, 2019 at 10:54:00AM +0000, Måns Rullgård wrote: >> > > > > Johan Hovold <johan@kernel.org> writes: >> > > > > > > Regardless, setting the NCTRL flag should be harmless. >> > > > > > >> > > > > > Well, there are devices that depend on getting these >> > > > > > requests, at least >> > > > > > for the QMI interface. But we can always revert if anyone >> > > > > > complains. >> > > > > >> > > > > The QMI interface doesn't even pretend to be a uart. The >> > > > > other ones do, >> > > > > but there isn't actually any real uart behind them. For >> > > > > instance, it >> > > > > doesn't matter what baud rate one sets. >> > > > >> > > > Sure, but some devices still require "DTR" to be set for the >> > > > QMI >> > > > interface, so there not being any real uart is no guarantee >> > > > that there >> > > > is no firmware that expects these calls. >> > > >> > > Now I'm thoroughly confused. The QMI interface has a completely >> > > separate driver that creates a network device (if I'm reading the >> > > code >> > > correctly). >> > >> > I was just giving an example of firmware sometimes doing unexpected >> > things. >> >> See 93725149794d ("net: qmi_wwan: MDM9x30 specific power management") >> for some background. > > TLDR; some firmware uses the DTR signal as an indicator to come out of > low-power mode. Without doing so you cannot talk to the modem over any > of it's ports, QMI, net, or serial. I must be missing something, but how does a network interface have a DTR signal?
Måns Rullgård <mans@mansr.com> writes: > Dan Williams <dcbw@redhat.com> writes: > >> TLDR; some firmware uses the DTR signal as an indicator to come out of >> low-power mode. Without doing so you cannot talk to the modem over any >> of it's ports, QMI, net, or serial. > > I must be missing something, but how does a network interface have a DTR > signal? It does not. But the network function is (ab)using the Comm class USB control message "SetControlLineState" to signal "wake up" from the host to the device. Which is perfectly fine since the USB function in question is vendor specific. The vendor can define any USB control message to mean anything they want. Reusing a Comm class message probably made sense to the firmware engineer designing this. We can only note and adapt. It doesn't have anything to do with DTR. Bjørn
Bjørn Mork <bjorn@mork.no> writes: > Måns Rullgård <mans@mansr.com> writes: >> Dan Williams <dcbw@redhat.com> writes: >> >>> TLDR; some firmware uses the DTR signal as an indicator to come out of >>> low-power mode. Without doing so you cannot talk to the modem over any >>> of it's ports, QMI, net, or serial. >> >> I must be missing something, but how does a network interface have a DTR >> signal? > > It does not. But the network function is (ab)using the Comm class USB > control message "SetControlLineState" to signal "wake up" from the host > to the device. Which is perfectly fine since the USB function in > question is vendor specific. The vendor can define any USB control > message to mean anything they want. Reusing a Comm class message > probably made sense to the firmware engineer designing this. We can > only note and adapt. > > It doesn't have anything to do with DTR. Every time you think USB can't get any worse, it does.
Måns Rullgård <mans@mansr.com> writes:
> Every time you think USB can't get any worse, it does.
You can't blame vendor creativity on the bus spec. Look at what the
same vendors do to e.g. SCSI to make these firmwares appear as different
USB devices. The fact that some of then use "eject" as a signal to
reboot the firmware into some other mode is not a SCSI problem.
But I do agree that USB should have dropped "vendor specific" and
mandated class functions for everything. In theory. In practice, that
would probably have casued USB to lose to some other competing spec with
vendor specific as an option...
Bjørn
diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c index fb544340888b..af4cbfecc3ff 100644 --- a/drivers/usb/serial/option.c +++ b/drivers/usb/serial/option.c @@ -1066,7 +1066,8 @@ static const struct usb_device_id option_ids[] = { .driver_info = RSVD(3) }, { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x6613)}, /* Onda H600/ZTE MF330 */ { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x0023)}, /* ONYX 3G device */ - { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x9000)}, /* SIMCom SIM5218 */ + { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x9000), /* SIMCom SIM5218 */ + .driver_info = NCTRL(0) | NCTRL(1) | NCTRL(2) | NCTRL(3) | RSVD(4) }, /* Quectel products using Qualcomm vendor ID */ { USB_DEVICE(QUALCOMM_VENDOR_ID, QUECTEL_PRODUCT_UC15)}, { USB_DEVICE(QUALCOMM_VENDOR_ID, QUECTEL_PRODUCT_UC20),
The SIMCom SIM5218 and compatible devices have 5 USB interfaces, only 4 of which are serial ports. The fifth is a network interface supported by the qmi-wwan driver. Furthermore, the serial ports do not support modem control signals. Add driver_info flags to reflect this. Signed-off-by: Mans Rullgard <mans@mansr.com> --- drivers/usb/serial/option.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)