* [PATCH] USB: serial: option: adding support for ublox R410M
@ 2018-04-26 6:28 ` SZ Lin
0 siblings, 0 replies; 28+ messages in thread
From: SZ Lin (林上智) @ 2018-04-26 6:28 UTC (permalink / raw)
To: y
Cc: SZ Lin (林上智),
stable, Johan Hovold, Greg Kroah-Hartman, linux-usb,
linux-kernel
This patch adds support for ublox R410M PID 0x90b2 USB modem to option
driver, this module supports LTE Cat M1 / NB1.
Interface layout:
0: QCDM/DIAG
1: ADB
2: AT
3: RMNET
Signed-off-by: SZ Lin (林上智) <sz.lin@moxa.com>
Cc: stable <stable@vger.kernel.org>
---
Please refer to following lsusb output:
Bus 001 Device 003: ID 05c6:90b2 Qualcomm, Inc.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x05c6 Qualcomm, Inc.
idProduct 0x90b2
bcdDevice 0.00
iManufacturer 3 Qualcomm, Incorporated
iProduct 2 Qualcomm CDMA Technologies MSM
iSerial 4 fb854106
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 108
bNumInterfaces 4
bConfigurationValue 1
iConfiguration 1 Qualcomm 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 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 Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 1
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 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
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 0x83 EP 3 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 0x84 EP 4 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 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 0x85 EP 5 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 0x86 EP 6 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
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)
---
drivers/usb/serial/option.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index f0c3612467a3..184691caee64 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -233,6 +233,8 @@ static void option_instat_callback(struct urb *urb);
/* These Quectel products use Qualcomm's vendor ID */
#define QUECTEL_PRODUCT_UC20 0x9003
#define QUECTEL_PRODUCT_UC15 0x9090
+/* These ublox products use Qualcomm's vendor ID */
+#define UBLOX_PRODUCT_R410M 0x90b2
/* These Yuga products use Qualcomm's vendor ID */
#define YUGA_PRODUCT_CLM920_NC5 0x9625
@@ -1065,6 +1067,9 @@ static const struct usb_device_id option_ids[] = {
/* Yuga products use Qualcomm vendor ID */
{ USB_DEVICE(QUALCOMM_VENDOR_ID, YUGA_PRODUCT_CLM920_NC5),
.driver_info = RSVD(1) | RSVD(4) },
+ /* ublox products use Qualcomm vendor ID */
+ { USB_DEVICE(QUALCOMM_VENDOR_ID, UBLOX_PRODUCT_R410M),
+ .driver_info = RSVD(1) | RSVD(3) },
/* Quectel products using Quectel vendor ID */
{ USB_DEVICE(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_EC21),
.driver_info = RSVD(4) },
--
2.17.0
^ permalink raw reply related [flat|nested] 28+ messages in thread
* USB: serial: option: adding support for ublox R410M
@ 2018-04-26 6:28 ` SZ Lin
0 siblings, 0 replies; 28+ messages in thread
From: SZ Lin @ 2018-04-26 6:28 UTC (permalink / raw)
To: y
Cc: SZ Lin (林上智),
stable, Johan Hovold, Greg Kroah-Hartman, linux-usb,
linux-kernel
This patch adds support for ublox R410M PID 0x90b2 USB modem to option
driver, this module supports LTE Cat M1 / NB1.
Interface layout:
0: QCDM/DIAG
1: ADB
2: AT
3: RMNET
Signed-off-by: SZ Lin (林上智) <sz.lin@moxa.com>
Cc: stable <stable@vger.kernel.org>
---
Please refer to following lsusb output:
Bus 001 Device 003: ID 05c6:90b2 Qualcomm, Inc.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x05c6 Qualcomm, Inc.
idProduct 0x90b2
bcdDevice 0.00
iManufacturer 3 Qualcomm, Incorporated
iProduct 2 Qualcomm CDMA Technologies MSM
iSerial 4 fb854106
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 108
bNumInterfaces 4
bConfigurationValue 1
iConfiguration 1 Qualcomm 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 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 Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 1
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 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
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 0x83 EP 3 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 0x84 EP 4 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 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 0x85 EP 5 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 0x86 EP 6 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
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)
---
drivers/usb/serial/option.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index f0c3612467a3..184691caee64 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -233,6 +233,8 @@ static void option_instat_callback(struct urb *urb);
/* These Quectel products use Qualcomm's vendor ID */
#define QUECTEL_PRODUCT_UC20 0x9003
#define QUECTEL_PRODUCT_UC15 0x9090
+/* These ublox products use Qualcomm's vendor ID */
+#define UBLOX_PRODUCT_R410M 0x90b2
/* These Yuga products use Qualcomm's vendor ID */
#define YUGA_PRODUCT_CLM920_NC5 0x9625
@@ -1065,6 +1067,9 @@ static const struct usb_device_id option_ids[] = {
/* Yuga products use Qualcomm vendor ID */
{ USB_DEVICE(QUALCOMM_VENDOR_ID, YUGA_PRODUCT_CLM920_NC5),
.driver_info = RSVD(1) | RSVD(4) },
+ /* ublox products use Qualcomm vendor ID */
+ { USB_DEVICE(QUALCOMM_VENDOR_ID, UBLOX_PRODUCT_R410M),
+ .driver_info = RSVD(1) | RSVD(3) },
/* Quectel products using Quectel vendor ID */
{ USB_DEVICE(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_EC21),
.driver_info = RSVD(4) },
^ permalink raw reply related [flat|nested] 28+ messages in thread
* Re: [PATCH] USB: serial: option: adding support for ublox R410M
@ 2018-04-26 7:09 ` Johan Hovold
0 siblings, 0 replies; 28+ messages in thread
From: Johan Hovold @ 2018-04-26 7:09 UTC (permalink / raw)
To: SZ Lin (林上智)
Cc: stable, Johan Hovold, Greg Kroah-Hartman, linux-usb, linux-kernel
On Thu, Apr 26, 2018 at 02:28:31PM +0800, SZ Lin (林上智) wrote:
> This patch adds support for ublox R410M PID 0x90b2 USB modem to option
> driver, this module supports LTE Cat M1 / NB1.
>
> Interface layout:
> 0: QCDM/DIAG
> 1: ADB
> 2: AT
> 3: RMNET
>
> Signed-off-by: SZ Lin (林上智) <sz.lin@moxa.com>
> Cc: stable <stable@vger.kernel.org>
Applied, thanks.
Johan
^ permalink raw reply [flat|nested] 28+ messages in thread
* USB: serial: option: adding support for ublox R410M
@ 2018-04-26 7:09 ` Johan Hovold
0 siblings, 0 replies; 28+ messages in thread
From: Johan Hovold @ 2018-04-26 7:09 UTC (permalink / raw)
To: SZ Lin (林上智)
Cc: stable, Johan Hovold, Greg Kroah-Hartman, linux-usb, linux-kernel
On Thu, Apr 26, 2018 at 02:28:31PM +0800, SZ Lin (林上智) wrote:
> This patch adds support for ublox R410M PID 0x90b2 USB modem to option
> driver, this module supports LTE Cat M1 / NB1.
>
> Interface layout:
> 0: QCDM/DIAG
> 1: ADB
> 2: AT
> 3: RMNET
>
> Signed-off-by: SZ Lin (林上智) <sz.lin@moxa.com>
> Cc: stable <stable@vger.kernel.org>
Applied, thanks.
Johan
---
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH] USB: serial: option: adding support for ublox R410M
@ 2018-04-26 7:48 ` Lars Melin
0 siblings, 0 replies; 28+ messages in thread
From: Lars Melin @ 2018-04-26 7:48 UTC (permalink / raw)
To: Johan Hovold, SZ Lin (林上智)
Cc: stable, Greg Kroah-Hartman, linux-usb, linux-kernel
On 4/26/2018 14:09, Johan Hovold wrote:
> On Thu, Apr 26, 2018 at 02:28:31PM +0800, SZ Lin (林上智) wrote:
>> This patch adds support for ublox R410M PID 0x90b2 USB modem to option
>> driver, this module supports LTE Cat M1 / NB1.
>>
>> Interface layout:
>> 0: QCDM/DIAG
>> 1: ADB
>> 2: AT
>> 3: RMNET
>>
>> Signed-off-by: SZ Lin (林上智) <sz.lin@moxa.com>
>> Cc: stable <stable@vger.kernel.org>
>
> Applied, thanks.
>
> Johan
With a Qualcomm Device Management interface, shouldn't this modem be
driven by qcserial?
/Lars
^ permalink raw reply [flat|nested] 28+ messages in thread
* USB: serial: option: adding support for ublox R410M
@ 2018-04-26 7:48 ` Lars Melin
0 siblings, 0 replies; 28+ messages in thread
From: Lars Melin @ 2018-04-26 7:48 UTC (permalink / raw)
To: Johan Hovold, SZ Lin (林上智)
Cc: stable, Greg Kroah-Hartman, linux-usb, linux-kernel
On 4/26/2018 14:09, Johan Hovold wrote:
> On Thu, Apr 26, 2018 at 02:28:31PM +0800, SZ Lin (林上智) wrote:
>> This patch adds support for ublox R410M PID 0x90b2 USB modem to option
>> driver, this module supports LTE Cat M1 / NB1.
>>
>> Interface layout:
>> 0: QCDM/DIAG
>> 1: ADB
>> 2: AT
>> 3: RMNET
>>
>> Signed-off-by: SZ Lin (林上智) <sz.lin@moxa.com>
>> Cc: stable <stable@vger.kernel.org>
>
> Applied, thanks.
>
> Johan
With a Qualcomm Device Management interface, shouldn't this modem be
driven by qcserial?
/Lars
---
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH] USB: serial: option: adding support for ublox R410M
@ 2018-04-26 8:14 ` Johan Hovold
0 siblings, 0 replies; 28+ messages in thread
From: Johan Hovold @ 2018-04-26 8:14 UTC (permalink / raw)
To: Lars Melin
Cc: Johan Hovold, SZ Lin (林上智),
stable, Greg Kroah-Hartman, linux-usb, linux-kernel,
Bjørn Mork, Dan Williams
On Thu, Apr 26, 2018 at 02:48:54PM +0700, Lars Melin wrote:
> On 4/26/2018 14:09, Johan Hovold wrote:
> > On Thu, Apr 26, 2018 at 02:28:31PM +0800, SZ Lin (林上智) wrote:
> >> This patch adds support for ublox R410M PID 0x90b2 USB modem to option
> >> driver, this module supports LTE Cat M1 / NB1.
> >>
> >> Interface layout:
> >> 0: QCDM/DIAG
> >> 1: ADB
> >> 2: AT
> >> 3: RMNET
> >>
> >> Signed-off-by: SZ Lin (林上智) <sz.lin@moxa.com>
> >> Cc: stable <stable@vger.kernel.org>
> >
> > Applied, thanks.
> >
> > Johan
>
> With a Qualcomm Device Management interface, shouldn't this modem be
> driven by qcserial?
Hmm, we already have some QCDM interfaces handled by option and qcaux so
it's not that clear-cut.
Dan and Björn had a discussion about this a while back, so adding them
on CC. It seems to me that this device does not fit the intended use (or
Gobi 1000 layout) for qcserial, but I may be mistaken.
Thanks,
Johan
^ permalink raw reply [flat|nested] 28+ messages in thread
* USB: serial: option: adding support for ublox R410M
@ 2018-04-26 8:14 ` Johan Hovold
0 siblings, 0 replies; 28+ messages in thread
From: Johan Hovold @ 2018-04-26 8:14 UTC (permalink / raw)
To: Lars Melin
Cc: Johan Hovold, SZ Lin (林上智),
stable, Greg Kroah-Hartman, linux-usb, linux-kernel,
Bjørn Mork, Dan Williams
On Thu, Apr 26, 2018 at 02:48:54PM +0700, Lars Melin wrote:
> On 4/26/2018 14:09, Johan Hovold wrote:
> > On Thu, Apr 26, 2018 at 02:28:31PM +0800, SZ Lin (林上智) wrote:
> >> This patch adds support for ublox R410M PID 0x90b2 USB modem to option
> >> driver, this module supports LTE Cat M1 / NB1.
> >>
> >> Interface layout:
> >> 0: QCDM/DIAG
> >> 1: ADB
> >> 2: AT
> >> 3: RMNET
> >>
> >> Signed-off-by: SZ Lin (林上智) <sz.lin@moxa.com>
> >> Cc: stable <stable@vger.kernel.org>
> >
> > Applied, thanks.
> >
> > Johan
>
> With a Qualcomm Device Management interface, shouldn't this modem be
> driven by qcserial?
Hmm, we already have some QCDM interfaces handled by option and qcaux so
it's not that clear-cut.
Dan and Björn had a discussion about this a while back, so adding them
on CC. It seems to me that this device does not fit the intended use (or
Gobi 1000 layout) for qcserial, but I may be mistaken.
Thanks,
Johan
---
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH] USB: serial: option: adding support for ublox R410M
@ 2018-04-26 11:19 ` Bjørn Mork
0 siblings, 0 replies; 28+ messages in thread
From: Bjørn Mork @ 2018-04-26 11:19 UTC (permalink / raw)
To: Johan Hovold
Cc: Lars Melin, SZ Lin (林上智),
stable, Greg Kroah-Hartman, linux-usb, linux-kernel,
Dan Williams
Johan Hovold <johan@kernel.org> writes:
> On Thu, Apr 26, 2018 at 02:48:54PM +0700, Lars Melin wrote:
>> On 4/26/2018 14:09, Johan Hovold wrote:
>> > On Thu, Apr 26, 2018 at 02:28:31PM +0800, SZ Lin (林上智) wrote:
>> >> This patch adds support for ublox R410M PID 0x90b2 USB modem to option
>> >> driver, this module supports LTE Cat M1 / NB1.
>> >>
>> >> Interface layout:
>> >> 0: QCDM/DIAG
>> >> 1: ADB
>> >> 2: AT
>> >> 3: RMNET
>> >>
>> >> Signed-off-by: SZ Lin (林上智) <sz.lin@moxa.com>
>> >> Cc: stable <stable@vger.kernel.org>
>> >
>> > Applied, thanks.
>> >
>> > Johan
>>
>> With a Qualcomm Device Management interface, shouldn't this modem be
>> driven by qcserial?
>
> Hmm, we already have some QCDM interfaces handled by option and qcaux so
> it's not that clear-cut.
>
> Dan and Björn had a discussion about this a while back, so adding them
> on CC. It seems to me that this device does not fit the intended use (or
> Gobi 1000 layout) for qcserial, but I may be mistaken.
tl;dr; I don't think qcserial is relevant unless a device matches one of
the pre-defined layout schemes.
But I'm too new in this game to say anything about the initial
intentions...
My view of the present situation is that qcserial handles interface
layouts shared among many devices, while option handles interface
layouts which are unique per device, and vendor+class based function
mappings. But I could be wrong.
Anyway, Qualcomm based designs are definitely handled by both drivers.
Using qcserial only makes sense if the interface layout matches one of
the defined shared schemes, which currently are:
QCSERIAL_G2K = 0, /* Gobi 2000 */
QCSERIAL_G1K = 1, /* Gobi 1000 */
QCSERIAL_SWI = 2, /* Sierra Wireless */
QCSERIAL_HWI = 3, /* Huawei */
or if similar logic is added for a new vendor/shceme
And I see multi-vendor-id usage as the main reason for these
schemes. There isn't much reason if you can make it a single match
against a vendor-id.
The original Gobi devices are obviously multi-vendor, and Sierra
Wireless and Huwaei are OEMs making devices for a number of laptop
vendors. This causes traditional vendor-id matching to fail, as e.g. a
HP device can be made by either OEMs (or others). qcserial has become a
convenient way to map a long list of full device IDs to a specific OEM
layout.
Bjørn
^ permalink raw reply [flat|nested] 28+ messages in thread
* USB: serial: option: adding support for ublox R410M
@ 2018-04-26 11:19 ` Bjørn Mork
0 siblings, 0 replies; 28+ messages in thread
From: Bjørn Mork @ 2018-04-26 11:19 UTC (permalink / raw)
To: Johan Hovold
Cc: Lars Melin, SZ Lin (林上智),
stable, Greg Kroah-Hartman, linux-usb, linux-kernel,
Dan Williams
Johan Hovold <johan@kernel.org> writes:
> On Thu, Apr 26, 2018 at 02:48:54PM +0700, Lars Melin wrote:
>> On 4/26/2018 14:09, Johan Hovold wrote:
>> > On Thu, Apr 26, 2018 at 02:28:31PM +0800, SZ Lin (林上智) wrote:
>> >> This patch adds support for ublox R410M PID 0x90b2 USB modem to option
>> >> driver, this module supports LTE Cat M1 / NB1.
>> >>
>> >> Interface layout:
>> >> 0: QCDM/DIAG
>> >> 1: ADB
>> >> 2: AT
>> >> 3: RMNET
>> >>
>> >> Signed-off-by: SZ Lin (林上智) <sz.lin@moxa.com>
>> >> Cc: stable <stable@vger.kernel.org>
>> >
>> > Applied, thanks.
>> >
>> > Johan
>>
>> With a Qualcomm Device Management interface, shouldn't this modem be
>> driven by qcserial?
>
> Hmm, we already have some QCDM interfaces handled by option and qcaux so
> it's not that clear-cut.
>
> Dan and Björn had a discussion about this a while back, so adding them
> on CC. It seems to me that this device does not fit the intended use (or
> Gobi 1000 layout) for qcserial, but I may be mistaken.
tl;dr; I don't think qcserial is relevant unless a device matches one of
the pre-defined layout schemes.
But I'm too new in this game to say anything about the initial
intentions...
My view of the present situation is that qcserial handles interface
layouts shared among many devices, while option handles interface
layouts which are unique per device, and vendor+class based function
mappings. But I could be wrong.
Anyway, Qualcomm based designs are definitely handled by both drivers.
Using qcserial only makes sense if the interface layout matches one of
the defined shared schemes, which currently are:
QCSERIAL_G2K = 0, /* Gobi 2000 */
QCSERIAL_G1K = 1, /* Gobi 1000 */
QCSERIAL_SWI = 2, /* Sierra Wireless */
QCSERIAL_HWI = 3, /* Huawei */
or if similar logic is added for a new vendor/shceme
And I see multi-vendor-id usage as the main reason for these
schemes. There isn't much reason if you can make it a single match
against a vendor-id.
The original Gobi devices are obviously multi-vendor, and Sierra
Wireless and Huwaei are OEMs making devices for a number of laptop
vendors. This causes traditional vendor-id matching to fail, as e.g. a
HP device can be made by either OEMs (or others). qcserial has become a
convenient way to map a long list of full device IDs to a specific OEM
layout.
Bjørn
---
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH] USB: serial: option: adding support for ublox R410M
@ 2018-04-26 11:39 ` Lars Melin
0 siblings, 0 replies; 28+ messages in thread
From: Lars Melin @ 2018-04-26 11:39 UTC (permalink / raw)
To: Bjørn Mork, Johan Hovold
Cc: SZ Lin (林上智),
stable, Greg Kroah-Hartman, linux-usb, linux-kernel,
Dan Williams
On 4/26/2018 18:19, Bjørn Mork wrote:
> Anyway, Qualcomm based designs are definitely handled by both drivers.
> Using qcserial only makes sense if the interface layout matches one of
> the defined shared schemes, which currently are:
>
> QCSERIAL_G2K = 0, /* Gobi 2000 */
> QCSERIAL_G1K = 1, /* Gobi 1000 */
> QCSERIAL_SWI = 2, /* Sierra Wireless */
> QCSERIAL_HWI = 3, /* Huawei */
It seems to me that this Quectel device matches the interface layout for
Gobi1K:
* Gobi 1K USB layout:
* 0: DM/DIAG (use libqcdm from ModemManager for communication)
* 1: serial port (doesn't respond)
* 2: AT-capable modem port
* 3: QMI/net
*/
/Lars
^ permalink raw reply [flat|nested] 28+ messages in thread
* USB: serial: option: adding support for ublox R410M
@ 2018-04-26 11:39 ` Lars Melin
0 siblings, 0 replies; 28+ messages in thread
From: Lars Melin @ 2018-04-26 11:39 UTC (permalink / raw)
To: Bjørn Mork, Johan Hovold
Cc: SZ Lin (林上智),
stable, Greg Kroah-Hartman, linux-usb, linux-kernel,
Dan Williams
On 4/26/2018 18:19, Bjørn Mork wrote:
> Anyway, Qualcomm based designs are definitely handled by both drivers.
> Using qcserial only makes sense if the interface layout matches one of
> the defined shared schemes, which currently are:
>
> QCSERIAL_G2K = 0, /* Gobi 2000 */
> QCSERIAL_G1K = 1, /* Gobi 1000 */
> QCSERIAL_SWI = 2, /* Sierra Wireless */
> QCSERIAL_HWI = 3, /* Huawei */
It seems to me that this Quectel device matches the interface layout for
Gobi1K:
* Gobi 1K USB layout:
* 0: DM/DIAG (use libqcdm from ModemManager for communication)
* 1: serial port (doesn't respond)
* 2: AT-capable modem port
* 3: QMI/net
*/
/Lars
---
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH] USB: serial: option: adding support for ublox R410M
@ 2018-04-26 11:40 ` Lars Melin
0 siblings, 0 replies; 28+ messages in thread
From: Lars Melin @ 2018-04-26 11:40 UTC (permalink / raw)
To: Bjørn Mork, Johan Hovold
Cc: SZ Lin (林上智),
stable, Greg Kroah-Hartman, linux-usb, linux-kernel,
Dan Williams
On 4/26/2018 18:39, Lars Melin wrote:
> On 4/26/2018 18:19, Bjørn Mork wrote:
>> Anyway, Qualcomm based designs are definitely handled by both drivers.
>> Using qcserial only makes sense if the interface layout matches one of
>> the defined shared schemes, which currently are:
>>
>> QCSERIAL_G2K = 0, /* Gobi 2000 */
>> QCSERIAL_G1K = 1, /* Gobi 1000 */
>> QCSERIAL_SWI = 2, /* Sierra Wireless */
>> QCSERIAL_HWI = 3, /* Huawei */
>
> It seems to me that this Quectel device matches the interface layout for
> Gobi1K:
>
> * Gobi 1K USB layout:
> * 0: DM/DIAG (use libqcdm from ModemManager for communication)
> * 1: serial port (doesn't respond)
> * 2: AT-capable modem port
> * 3: QMI/net
> */
>
> /Lars
Ublox, not Quectel..
^ permalink raw reply [flat|nested] 28+ messages in thread
* USB: serial: option: adding support for ublox R410M
@ 2018-04-26 11:40 ` Lars Melin
0 siblings, 0 replies; 28+ messages in thread
From: Lars Melin @ 2018-04-26 11:40 UTC (permalink / raw)
To: Bjørn Mork, Johan Hovold
Cc: SZ Lin (林上智),
stable, Greg Kroah-Hartman, linux-usb, linux-kernel,
Dan Williams
On 4/26/2018 18:39, Lars Melin wrote:
> On 4/26/2018 18:19, Bjørn Mork wrote:
>> Anyway, Qualcomm based designs are definitely handled by both drivers.
>> Using qcserial only makes sense if the interface layout matches one of
>> the defined shared schemes, which currently are:
>>
>> QCSERIAL_G2K = 0, /* Gobi 2000 */
>> QCSERIAL_G1K = 1, /* Gobi 1000 */
>> QCSERIAL_SWI = 2, /* Sierra Wireless */
>> QCSERIAL_HWI = 3, /* Huawei */
>
> It seems to me that this Quectel device matches the interface layout for
> Gobi1K:
>
> * Gobi 1K USB layout:
> * 0: DM/DIAG (use libqcdm from ModemManager for communication)
> * 1: serial port (doesn't respond)
> * 2: AT-capable modem port
> * 3: QMI/net
> */
>
> /Lars
Ublox, not Quectel..
---
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH] USB: serial: option: adding support for ublox R410M
2018-04-26 11:40 ` Lars Melin
(?)
@ 2018-04-26 16:12 ` Johan Hovold
-1 siblings, 0 replies; 28+ messages in thread
From: Johan Hovold @ 2018-04-26 16:12 UTC (permalink / raw)
To: Lars Melin
Cc: Bjørn Mork, Johan Hovold, SZ Lin (林上智),
stable, Greg Kroah-Hartman, linux-usb, linux-kernel,
Dan Williams
On Thu, Apr 26, 2018 at 06:40:46PM +0700, Lars Melin wrote:
> On 4/26/2018 18:39, Lars Melin wrote:
> > On 4/26/2018 18:19, Bjørn Mork wrote:
> >> Anyway, Qualcomm based designs are definitely handled by both drivers.
> >> Using qcserial only makes sense if the interface layout matches one of
> >> the defined shared schemes, which currently are:
> >>
> >> QCSERIAL_G2K = 0, /* Gobi 2000 */
> >> QCSERIAL_G1K = 1, /* Gobi 1000 */
> >> QCSERIAL_SWI = 2, /* Sierra Wireless */
> >> QCSERIAL_HWI = 3, /* Huawei */
> >
> > It seems to me that this Quectel device matches the interface layout for
> > Gobi1K:
> >
> > * Gobi 1K USB layout:
> > * 0: DM/DIAG (use libqcdm from ModemManager for communication)
> > * 1: serial port (doesn't respond)
> > * 2: AT-capable modem port
> > * 3: QMI/net
> > */
> Ublox, not Quectel..
Yeah, but qcserial appears to select a different altsetting for the DM
port for Gobi 1000, an altsetting which this particular device does not
have.
I didn't re-read the full thread I referred to earlier, but I think in
it, Dan mentioned Gobi 1000 device requiring firmware to be loaded too.
So if it's not a G1K device, we probably shouldn't be using qcserial
even if the interface layout happens to match.
Thanks,
Johan
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH] USB: serial: option: adding support for ublox R410M
@ 2018-04-26 16:12 ` Johan Hovold
0 siblings, 0 replies; 28+ messages in thread
From: Johan Hovold @ 2018-04-26 16:12 UTC (permalink / raw)
To: Lars Melin
Cc: Bjørn Mork, Johan Hovold, SZ Lin (林上智),
stable, Greg Kroah-Hartman, linux-usb, linux-kernel,
Dan Williams
On Thu, Apr 26, 2018 at 06:40:46PM +0700, Lars Melin wrote:
> On 4/26/2018 18:39, Lars Melin wrote:
> > On 4/26/2018 18:19, Bj�rn Mork wrote:
> >> Anyway, Qualcomm based designs are definitely handled by both drivers.
> >> Using qcserial only makes sense if the interface layout matches one of
> >> the defined shared schemes, which currently are:
> >>
> >> ����QCSERIAL_G2K = 0,��� /* Gobi 2000 */
> >> ����QCSERIAL_G1K = 1,��� /* Gobi 1000 */
> >> ����QCSERIAL_SWI = 2,��� /* Sierra Wireless */
> >> ����QCSERIAL_HWI = 3,��� /* Huawei */
> >
> > It seems to me that this Quectel device matches the interface layout for
> > Gobi1K:
> >
> > �������� * Gobi 1K USB layout:
> > �������� * 0: DM/DIAG (use libqcdm from ModemManager for communication)
> > �������� * 1: serial port (doesn't respond)
> > �������� * 2: AT-capable modem port
> > �������� * 3: QMI/net
> > �������� */
> Ublox, not Quectel..
Yeah, but qcserial appears to select a different altsetting for the DM
port for Gobi 1000, an altsetting which this particular device does not
have.
I didn't re-read the full thread I referred to earlier, but I think in
it, Dan mentioned Gobi 1000 device requiring firmware to be loaded too.
So if it's not a G1K device, we probably shouldn't be using qcserial
even if the interface layout happens to match.
Thanks,
Johan
^ permalink raw reply [flat|nested] 28+ messages in thread
* USB: serial: option: adding support for ublox R410M
@ 2018-04-26 16:12 ` Johan Hovold
0 siblings, 0 replies; 28+ messages in thread
From: Johan Hovold @ 2018-04-26 16:12 UTC (permalink / raw)
To: Lars Melin
Cc: Bjørn Mork, Johan Hovold, SZ Lin (林上智),
stable, Greg Kroah-Hartman, linux-usb, linux-kernel,
Dan Williams
On Thu, Apr 26, 2018 at 06:40:46PM +0700, Lars Melin wrote:
> On 4/26/2018 18:39, Lars Melin wrote:
> > On 4/26/2018 18:19, Bjørn Mork wrote:
> >> Anyway, Qualcomm based designs are definitely handled by both drivers.
> >> Using qcserial only makes sense if the interface layout matches one of
> >> the defined shared schemes, which currently are:
> >>
> >> QCSERIAL_G2K = 0, /* Gobi 2000 */
> >> QCSERIAL_G1K = 1, /* Gobi 1000 */
> >> QCSERIAL_SWI = 2, /* Sierra Wireless */
> >> QCSERIAL_HWI = 3, /* Huawei */
> >
> > It seems to me that this Quectel device matches the interface layout for
> > Gobi1K:
> >
> > * Gobi 1K USB layout:
> > * 0: DM/DIAG (use libqcdm from ModemManager for communication)
> > * 1: serial port (doesn't respond)
> > * 2: AT-capable modem port
> > * 3: QMI/net
> > */
> Ublox, not Quectel..
Yeah, but qcserial appears to select a different altsetting for the DM
port for Gobi 1000, an altsetting which this particular device does not
have.
I didn't re-read the full thread I referred to earlier, but I think in
it, Dan mentioned Gobi 1000 device requiring firmware to be loaded too.
So if it's not a G1K device, we probably shouldn't be using qcserial
even if the interface layout happens to match.
Thanks,
Johan
---
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH] USB: serial: option: adding support for ublox R410M
@ 2018-04-26 16:22 ` Lars Melin
0 siblings, 0 replies; 28+ messages in thread
From: Lars Melin @ 2018-04-26 16:22 UTC (permalink / raw)
To: Johan Hovold
Cc: Bjørn Mork, SZ Lin (林上智),
stable, Greg Kroah-Hartman, linux-usb, linux-kernel,
Dan Williams
On 4/26/2018 23:12, Johan Hovold wrote:
> On Thu, Apr 26, 2018 at 06:40:46PM +0700, Lars Melin wrote:
>> On 4/26/2018 18:39, Lars Melin wrote:
>>> On 4/26/2018 18:19, Bjørn Mork wrote:
>>>> Anyway, Qualcomm based designs are definitely handled by both drivers.
>>>> Using qcserial only makes sense if the interface layout matches one of
>>>> the defined shared schemes, which currently are:
>>>>
>>>> QCSERIAL_G2K = 0, /* Gobi 2000 */
>>>> QCSERIAL_G1K = 1, /* Gobi 1000 */
>>>> QCSERIAL_SWI = 2, /* Sierra Wireless */
>>>> QCSERIAL_HWI = 3, /* Huawei */
>>>
>>> It seems to me that this Quectel device matches the interface layout for
>>> Gobi1K:
>>>
>>> * Gobi 1K USB layout:
>>> * 0: DM/DIAG (use libqcdm from ModemManager for communication)
>>> * 1: serial port (doesn't respond)
>>> * 2: AT-capable modem port
>>> * 3: QMI/net
>>> */
>
>> Ublox, not Quectel..
>
> Yeah, but qcserial appears to select a different altsetting for the DM
> port for Gobi 1000, an altsetting which this particular device does not
> have.
>
> I didn't re-read the full thread I referred to earlier, but I think in
> it, Dan mentioned Gobi 1000 device requiring firmware to be loaded too.
>
> So if it's not a G1K device, we probably shouldn't be using qcserial
> even if the interface layout happens to match.
>
> Thanks,
> Johan
Good point, I forgot about the required firmware loading for Gobi1K.
So this device should be handled by the option driver.
/Lars
^ permalink raw reply [flat|nested] 28+ messages in thread
* USB: serial: option: adding support for ublox R410M
@ 2018-04-26 16:22 ` Lars Melin
0 siblings, 0 replies; 28+ messages in thread
From: Lars Melin @ 2018-04-26 16:22 UTC (permalink / raw)
To: Johan Hovold
Cc: Bjørn Mork, SZ Lin (林上智),
stable, Greg Kroah-Hartman, linux-usb, linux-kernel,
Dan Williams
On 4/26/2018 23:12, Johan Hovold wrote:
> On Thu, Apr 26, 2018 at 06:40:46PM +0700, Lars Melin wrote:
>> On 4/26/2018 18:39, Lars Melin wrote:
>>> On 4/26/2018 18:19, Bjørn Mork wrote:
>>>> Anyway, Qualcomm based designs are definitely handled by both drivers.
>>>> Using qcserial only makes sense if the interface layout matches one of
>>>> the defined shared schemes, which currently are:
>>>>
>>>> QCSERIAL_G2K = 0, /* Gobi 2000 */
>>>> QCSERIAL_G1K = 1, /* Gobi 1000 */
>>>> QCSERIAL_SWI = 2, /* Sierra Wireless */
>>>> QCSERIAL_HWI = 3, /* Huawei */
>>>
>>> It seems to me that this Quectel device matches the interface layout for
>>> Gobi1K:
>>>
>>> * Gobi 1K USB layout:
>>> * 0: DM/DIAG (use libqcdm from ModemManager for communication)
>>> * 1: serial port (doesn't respond)
>>> * 2: AT-capable modem port
>>> * 3: QMI/net
>>> */
>
>> Ublox, not Quectel..
>
> Yeah, but qcserial appears to select a different altsetting for the DM
> port for Gobi 1000, an altsetting which this particular device does not
> have.
>
> I didn't re-read the full thread I referred to earlier, but I think in
> it, Dan mentioned Gobi 1000 device requiring firmware to be loaded too.
>
> So if it's not a G1K device, we probably shouldn't be using qcserial
> even if the interface layout happens to match.
>
> Thanks,
> Johan
Good point, I forgot about the required firmware loading for Gobi1K.
So this device should be handled by the option driver.
/Lars
---
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH] USB: serial: option: adding support for ublox R410M
2018-04-26 16:22 ` Lars Melin
(?)
@ 2018-04-26 16:29 ` Johan Hovold
-1 siblings, 0 replies; 28+ messages in thread
From: Johan Hovold @ 2018-04-26 16:29 UTC (permalink / raw)
To: Lars Melin
Cc: Johan Hovold, Bjørn Mork, SZ Lin (林上智),
stable, Greg Kroah-Hartman, linux-usb, linux-kernel,
Dan Williams
On Thu, Apr 26, 2018 at 11:22:25PM +0700, Lars Melin wrote:
> On 4/26/2018 23:12, Johan Hovold wrote:
> > On Thu, Apr 26, 2018 at 06:40:46PM +0700, Lars Melin wrote:
> >> On 4/26/2018 18:39, Lars Melin wrote:
> >>> On 4/26/2018 18:19, Bjørn Mork wrote:
> >>>> Anyway, Qualcomm based designs are definitely handled by both drivers.
> >>>> Using qcserial only makes sense if the interface layout matches one of
> >>>> the defined shared schemes, which currently are:
> >>>>
> >>>> QCSERIAL_G2K = 0, /* Gobi 2000 */
> >>>> QCSERIAL_G1K = 1, /* Gobi 1000 */
> >>>> QCSERIAL_SWI = 2, /* Sierra Wireless */
> >>>> QCSERIAL_HWI = 3, /* Huawei */
> >>>
> >>> It seems to me that this Quectel device matches the interface layout for
> >>> Gobi1K:
> > Yeah, but qcserial appears to select a different altsetting for the DM
> > port for Gobi 1000, an altsetting which this particular device does not
> > have.
> >
> > I didn't re-read the full thread I referred to earlier, but I think in
> > it, Dan mentioned Gobi 1000 device requiring firmware to be loaded too.
> >
> > So if it's not a G1K device, we probably shouldn't be using qcserial
> > even if the interface layout happens to match.
> Good point, I forgot about the required firmware loading for Gobi1K.
> So this device should be handled by the option driver.
Yeah, we probably should document all of this at some point. :)
I didn't include the patch in this weeks -rc updates, but I've queued it
up for the next batch.
Thanks everyone.
Johan
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH] USB: serial: option: adding support for ublox R410M
@ 2018-04-26 16:29 ` Johan Hovold
0 siblings, 0 replies; 28+ messages in thread
From: Johan Hovold @ 2018-04-26 16:29 UTC (permalink / raw)
To: Lars Melin
Cc: Johan Hovold, Bjørn Mork, SZ Lin (林上智),
stable, Greg Kroah-Hartman, linux-usb, linux-kernel,
Dan Williams
On Thu, Apr 26, 2018 at 11:22:25PM +0700, Lars Melin wrote:
> On 4/26/2018 23:12, Johan Hovold wrote:
> > On Thu, Apr 26, 2018 at 06:40:46PM +0700, Lars Melin wrote:
> >> On 4/26/2018 18:39, Lars Melin wrote:
> >>> On 4/26/2018 18:19, Bj�rn Mork wrote:
> >>>> Anyway, Qualcomm based designs are definitely handled by both drivers.
> >>>> Using qcserial only makes sense if the interface layout matches one of
> >>>> the defined shared schemes, which currently are:
> >>>>
> >>>> ����QCSERIAL_G2K = 0,��� /* Gobi 2000 */
> >>>> ����QCSERIAL_G1K = 1,��� /* Gobi 1000 */
> >>>> ����QCSERIAL_SWI = 2,��� /* Sierra Wireless */
> >>>> ����QCSERIAL_HWI = 3,��� /* Huawei */
> >>>
> >>> It seems to me that this Quectel device matches the interface layout for
> >>> Gobi1K:
> > Yeah, but qcserial appears to select a different altsetting for the DM
> > port for Gobi 1000, an altsetting which this particular device does not
> > have.
> >
> > I didn't re-read the full thread I referred to earlier, but I think in
> > it, Dan mentioned Gobi 1000 device requiring firmware to be loaded too.
> >
> > So if it's not a G1K device, we probably shouldn't be using qcserial
> > even if the interface layout happens to match.
> Good point, I forgot about the required firmware loading for Gobi1K.
> So this device should be handled by the option driver.
Yeah, we probably should document all of this at some point. :)
I didn't include the patch in this weeks -rc updates, but I've queued it
up for the next batch.
Thanks everyone.
Johan
^ permalink raw reply [flat|nested] 28+ messages in thread
* USB: serial: option: adding support for ublox R410M
@ 2018-04-26 16:29 ` Johan Hovold
0 siblings, 0 replies; 28+ messages in thread
From: Johan Hovold @ 2018-04-26 16:29 UTC (permalink / raw)
To: Lars Melin
Cc: Johan Hovold, Bjørn Mork, SZ Lin (林上智),
stable, Greg Kroah-Hartman, linux-usb, linux-kernel,
Dan Williams
On Thu, Apr 26, 2018 at 11:22:25PM +0700, Lars Melin wrote:
> On 4/26/2018 23:12, Johan Hovold wrote:
> > On Thu, Apr 26, 2018 at 06:40:46PM +0700, Lars Melin wrote:
> >> On 4/26/2018 18:39, Lars Melin wrote:
> >>> On 4/26/2018 18:19, Bjørn Mork wrote:
> >>>> Anyway, Qualcomm based designs are definitely handled by both drivers.
> >>>> Using qcserial only makes sense if the interface layout matches one of
> >>>> the defined shared schemes, which currently are:
> >>>>
> >>>> QCSERIAL_G2K = 0, /* Gobi 2000 */
> >>>> QCSERIAL_G1K = 1, /* Gobi 1000 */
> >>>> QCSERIAL_SWI = 2, /* Sierra Wireless */
> >>>> QCSERIAL_HWI = 3, /* Huawei */
> >>>
> >>> It seems to me that this Quectel device matches the interface layout for
> >>> Gobi1K:
> > Yeah, but qcserial appears to select a different altsetting for the DM
> > port for Gobi 1000, an altsetting which this particular device does not
> > have.
> >
> > I didn't re-read the full thread I referred to earlier, but I think in
> > it, Dan mentioned Gobi 1000 device requiring firmware to be loaded too.
> >
> > So if it's not a G1K device, we probably shouldn't be using qcserial
> > even if the interface layout happens to match.
> Good point, I forgot about the required firmware loading for Gobi1K.
> So this device should be handled by the option driver.
Yeah, we probably should document all of this at some point. :)
I didn't include the patch in this weeks -rc updates, but I've queued it
up for the next batch.
Thanks everyone.
Johan
---
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH] USB: serial: option: adding support for ublox R410M
@ 2018-04-26 19:12 ` Dan Williams
0 siblings, 0 replies; 28+ messages in thread
From: Dan Williams @ 2018-04-26 19:12 UTC (permalink / raw)
To: Johan Hovold, Lars Melin
Cc: Bjørn Mork, SZ Lin (林上智),
stable, Greg Kroah-Hartman, linux-usb, linux-kernel
On Thu, 2018-04-26 at 18:29 +0200, Johan Hovold wrote:
> On Thu, Apr 26, 2018 at 11:22:25PM +0700, Lars Melin wrote:
> > On 4/26/2018 23:12, Johan Hovold wrote:
> > > On Thu, Apr 26, 2018 at 06:40:46PM +0700, Lars Melin wrote:
> > > > On 4/26/2018 18:39, Lars Melin wrote:
> > > > > On 4/26/2018 18:19, Bjørn Mork wrote:
> > > > > > Anyway, Qualcomm based designs are definitely handled by
> > > > > > both drivers.
> > > > > > Using qcserial only makes sense if the interface layout
> > > > > > matches one of
> > > > > > the defined shared schemes, which currently are:
> > > > > >
> > > > > > QCSERIAL_G2K = 0, /* Gobi 2000 */
> > > > > > QCSERIAL_G1K = 1, /* Gobi 1000 */
> > > > > > QCSERIAL_SWI = 2, /* Sierra Wireless */
> > > > > > QCSERIAL_HWI = 3, /* Huawei */
> > > > >
> > > > > It seems to me that this Quectel device matches the interface
> > > > > layout for
> > > > > Gobi1K:
> > > Yeah, but qcserial appears to select a different altsetting for
> > > the DM
> > > port for Gobi 1000, an altsetting which this particular device
> > > does not
> > > have.
> > >
> > > I didn't re-read the full thread I referred to earlier, but I
> > > think in
> > > it, Dan mentioned Gobi 1000 device requiring firmware to be
> > > loaded too.
> > >
> > > So if it's not a G1K device, we probably shouldn't be using
> > > qcserial
> > > even if the interface layout happens to match.
> > Good point, I forgot about the required firmware loading for
> > Gobi1K.
> > So this device should be handled by the option driver.
>
> Yeah, we probably should document all of this at some point. :)
>
> I didn't include the patch in this weeks -rc updates, but I've queued
> it
> up for the next batch.
Option is likely the right driver for this device.
qcaux was mainly for mobile phones that have a TTY (often cdc-acm) as
the modem port and a secondary DIAG/DM port driven by qcaux. The DM
port doesn't have an interrupt endpoint thus it's not a normal modem
port requiring the larger buffers of option and its control signaling.
qcserial (as Bjorn mentioned) is only for actual Gobi-type devices with
the specific layouts and the firmware loading requirement where the 1K
and 2K devices start in a special 1-port mode waiting for firmware and
then become 4-port devices on firmware reboot.
Dan
^ permalink raw reply [flat|nested] 28+ messages in thread
* USB: serial: option: adding support for ublox R410M
@ 2018-04-26 19:12 ` Dan Williams
0 siblings, 0 replies; 28+ messages in thread
From: Dan Williams @ 2018-04-26 19:12 UTC (permalink / raw)
To: Johan Hovold, Lars Melin
Cc: Bjørn Mork, SZ Lin (林上智),
stable, Greg Kroah-Hartman, linux-usb, linux-kernel
On Thu, 2018-04-26 at 18:29 +0200, Johan Hovold wrote:
> On Thu, Apr 26, 2018 at 11:22:25PM +0700, Lars Melin wrote:
> > On 4/26/2018 23:12, Johan Hovold wrote:
> > > On Thu, Apr 26, 2018 at 06:40:46PM +0700, Lars Melin wrote:
> > > > On 4/26/2018 18:39, Lars Melin wrote:
> > > > > On 4/26/2018 18:19, Bjørn Mork wrote:
> > > > > > Anyway, Qualcomm based designs are definitely handled by
> > > > > > both drivers.
> > > > > > Using qcserial only makes sense if the interface layout
> > > > > > matches one of
> > > > > > the defined shared schemes, which currently are:
> > > > > >
> > > > > > QCSERIAL_G2K = 0, /* Gobi 2000 */
> > > > > > QCSERIAL_G1K = 1, /* Gobi 1000 */
> > > > > > QCSERIAL_SWI = 2, /* Sierra Wireless */
> > > > > > QCSERIAL_HWI = 3, /* Huawei */
> > > > >
> > > > > It seems to me that this Quectel device matches the interface
> > > > > layout for
> > > > > Gobi1K:
> > > Yeah, but qcserial appears to select a different altsetting for
> > > the DM
> > > port for Gobi 1000, an altsetting which this particular device
> > > does not
> > > have.
> > >
> > > I didn't re-read the full thread I referred to earlier, but I
> > > think in
> > > it, Dan mentioned Gobi 1000 device requiring firmware to be
> > > loaded too.
> > >
> > > So if it's not a G1K device, we probably shouldn't be using
> > > qcserial
> > > even if the interface layout happens to match.
> > Good point, I forgot about the required firmware loading for
> > Gobi1K.
> > So this device should be handled by the option driver.
>
> Yeah, we probably should document all of this at some point. :)
>
> I didn't include the patch in this weeks -rc updates, but I've queued
> it
> up for the next batch.
Option is likely the right driver for this device.
qcaux was mainly for mobile phones that have a TTY (often cdc-acm) as
the modem port and a secondary DIAG/DM port driven by qcaux. The DM
port doesn't have an interrupt endpoint thus it's not a normal modem
port requiring the larger buffers of option and its control signaling.
qcserial (as Bjorn mentioned) is only for actual Gobi-type devices with
the specific layouts and the firmware loading requirement where the 1K
and 2K devices start in a special 1-port mode waiting for firmware and
then become 4-port devices on firmware reboot.
Dan
---
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 28+ messages in thread
* RE: [PATCH] USB: serial: option: adding support for ublox R410M
@ 2018-04-27 2:14 ` SZ Lin
0 siblings, 0 replies; 28+ messages in thread
From: SZ Lin (林上智) @ 2018-04-27 2:14 UTC (permalink / raw)
To: Dan Williams, Johan Hovold, Lars Melin
Cc: Bjørn Mork, stable, Greg Kroah-Hartman, linux-usb, linux-kernel
<snip>
>
> Option is likely the right driver for this device.
>
> qcaux was mainly for mobile phones that have a TTY (often cdc-acm) as the modem port
> and a secondary DIAG/DM port driven by qcaux. The DM port doesn't have an interrupt
> endpoint thus it's not a normal modem port requiring the larger buffers of option and its
> control signaling.
>
> qcserial (as Bjorn mentioned) is only for actual Gobi-type devices with the specific layouts
> and the firmware loading requirement where the 1K and 2K devices start in a special
> 1-port mode waiting for firmware and then become 4-port devices on firmware reboot.
>
> Dan
Thank you all. I believe that many people are confused in selecting serial driver (option and qcserial)
for QUALCOMM based module. This thread has provided clearly and properly presented the different
between them.
SZ
^ permalink raw reply [flat|nested] 28+ messages in thread
* USB: serial: option: adding support for ublox R410M
@ 2018-04-27 2:14 ` SZ Lin
0 siblings, 0 replies; 28+ messages in thread
From: SZ Lin @ 2018-04-27 2:14 UTC (permalink / raw)
To: Dan Williams, Johan Hovold, Lars Melin
Cc: Bjørn Mork, stable, Greg Kroah-Hartman, linux-usb, linux-kernel
<snip>
>
> Option is likely the right driver for this device.
>
> qcaux was mainly for mobile phones that have a TTY (often cdc-acm) as the modem port
> and a secondary DIAG/DM port driven by qcaux. The DM port doesn't have an interrupt
> endpoint thus it's not a normal modem port requiring the larger buffers of option and its
> control signaling.
>
> qcserial (as Bjorn mentioned) is only for actual Gobi-type devices with the specific layouts
> and the firmware loading requirement where the 1K and 2K devices start in a special
> 1-port mode waiting for firmware and then become 4-port devices on firmware reboot.
>
> Dan
Thank you all. I believe that many people are confused in selecting serial driver (option and qcserial)
for QUALCOMM based module. This thread has provided clearly and properly presented the different
between them.
SZ
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH] USB: serial: option: adding support for ublox R410M
@ 2018-05-02 7:22 ` Johan Hovold
0 siblings, 0 replies; 28+ messages in thread
From: Johan Hovold @ 2018-05-02 7:22 UTC (permalink / raw)
To: Dan Williams
Cc: Johan Hovold, Lars Melin, Bjørn Mork,
SZ Lin (林上智),
stable, Greg Kroah-Hartman, linux-usb, linux-kernel
On Thu, Apr 26, 2018 at 02:12:32PM -0500, Dan Williams wrote:
> On Thu, 2018-04-26 at 18:29 +0200, Johan Hovold wrote:
> > On Thu, Apr 26, 2018 at 11:22:25PM +0700, Lars Melin wrote:
> > > On 4/26/2018 23:12, Johan Hovold wrote:
> > > > On Thu, Apr 26, 2018 at 06:40:46PM +0700, Lars Melin wrote:
> > > > > On 4/26/2018 18:39, Lars Melin wrote:
> > > > > > On 4/26/2018 18:19, Bjørn Mork wrote:
> > > > > > > Anyway, Qualcomm based designs are definitely handled by
> > > > > > > both drivers. Using qcserial only makes sense if the
> > > > > > > interface layout matches one of the defined shared
> > > > > > > schemes, which currently are:
> > > > > > >
> > > > > > > QCSERIAL_G2K = 0, /* Gobi 2000 */
> > > > > > > QCSERIAL_G1K = 1, /* Gobi 1000 */
> > > > > > > QCSERIAL_SWI = 2, /* Sierra Wireless */
> > > > > > > QCSERIAL_HWI = 3, /* Huawei */
> > > > > >
> > > > > > It seems to me that this Quectel device matches the
> > > > > > interface layout for Gobi1K:
> > > >
> > > > Yeah, but qcserial appears to select a different altsetting for
> > > > the DM port for Gobi 1000, an altsetting which this particular
> > > > device does not have.
> > > >
> > > > I didn't re-read the full thread I referred to earlier, but I
> > > > think in it, Dan mentioned Gobi 1000 device requiring firmware
> > > > to be loaded too.
> > > >
> > > > So if it's not a G1K device, we probably shouldn't be using
> > > > qcserial even if the interface layout happens to match.
> > >
> > > Good point, I forgot about the required firmware loading for
> > > Gobi1K.
> > > So this device should be handled by the option driver.
> >
> > Yeah, we probably should document all of this at some point. :)
> >
> > I didn't include the patch in this weeks -rc updates, but I've
> > queued it up for the next batch.
>
> Option is likely the right driver for this device.
>
> qcaux was mainly for mobile phones that have a TTY (often cdc-acm) as
> the modem port and a secondary DIAG/DM port driven by qcaux. The DM
> port doesn't have an interrupt endpoint thus it's not a normal modem
> port requiring the larger buffers of option and its control signaling.
>
> qcserial (as Bjorn mentioned) is only for actual Gobi-type devices with
> the specific layouts and the firmware loading requirement where the 1K
> and 2K devices start in a special 1-port mode waiting for firmware and
> then become 4-port devices on firmware reboot.
Thanks for that summary. I've applied SZ's patch now.
Johan
^ permalink raw reply [flat|nested] 28+ messages in thread
* USB: serial: option: adding support for ublox R410M
@ 2018-05-02 7:22 ` Johan Hovold
0 siblings, 0 replies; 28+ messages in thread
From: Johan Hovold @ 2018-05-02 7:22 UTC (permalink / raw)
To: Dan Williams
Cc: Johan Hovold, Lars Melin, Bjørn Mork,
SZ Lin (林上智),
stable, Greg Kroah-Hartman, linux-usb, linux-kernel
On Thu, Apr 26, 2018 at 02:12:32PM -0500, Dan Williams wrote:
> On Thu, 2018-04-26 at 18:29 +0200, Johan Hovold wrote:
> > On Thu, Apr 26, 2018 at 11:22:25PM +0700, Lars Melin wrote:
> > > On 4/26/2018 23:12, Johan Hovold wrote:
> > > > On Thu, Apr 26, 2018 at 06:40:46PM +0700, Lars Melin wrote:
> > > > > On 4/26/2018 18:39, Lars Melin wrote:
> > > > > > On 4/26/2018 18:19, Bjørn Mork wrote:
> > > > > > > Anyway, Qualcomm based designs are definitely handled by
> > > > > > > both drivers. Using qcserial only makes sense if the
> > > > > > > interface layout matches one of the defined shared
> > > > > > > schemes, which currently are:
> > > > > > >
> > > > > > > QCSERIAL_G2K = 0, /* Gobi 2000 */
> > > > > > > QCSERIAL_G1K = 1, /* Gobi 1000 */
> > > > > > > QCSERIAL_SWI = 2, /* Sierra Wireless */
> > > > > > > QCSERIAL_HWI = 3, /* Huawei */
> > > > > >
> > > > > > It seems to me that this Quectel device matches the
> > > > > > interface layout for Gobi1K:
> > > >
> > > > Yeah, but qcserial appears to select a different altsetting for
> > > > the DM port for Gobi 1000, an altsetting which this particular
> > > > device does not have.
> > > >
> > > > I didn't re-read the full thread I referred to earlier, but I
> > > > think in it, Dan mentioned Gobi 1000 device requiring firmware
> > > > to be loaded too.
> > > >
> > > > So if it's not a G1K device, we probably shouldn't be using
> > > > qcserial even if the interface layout happens to match.
> > >
> > > Good point, I forgot about the required firmware loading for
> > > Gobi1K.
> > > So this device should be handled by the option driver.
> >
> > Yeah, we probably should document all of this at some point. :)
> >
> > I didn't include the patch in this weeks -rc updates, but I've
> > queued it up for the next batch.
>
> Option is likely the right driver for this device.
>
> qcaux was mainly for mobile phones that have a TTY (often cdc-acm) as
> the modem port and a secondary DIAG/DM port driven by qcaux. The DM
> port doesn't have an interrupt endpoint thus it's not a normal modem
> port requiring the larger buffers of option and its control signaling.
>
> qcserial (as Bjorn mentioned) is only for actual Gobi-type devices with
> the specific layouts and the firmware loading requirement where the 1K
> and 2K devices start in a special 1-port mode waiting for firmware and
> then become 4-port devices on firmware reboot.
Thanks for that summary. I've applied SZ's patch now.
Johan
---
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~2018-05-02 7:22 UTC | newest]
Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-04-26 6:28 [PATCH] USB: serial: option: adding support for ublox R410M SZ Lin (林上智)
2018-04-26 6:28 ` SZ Lin
2018-04-26 7:09 ` [PATCH] " Johan Hovold
2018-04-26 7:09 ` Johan Hovold
2018-04-26 7:48 ` [PATCH] " Lars Melin
2018-04-26 7:48 ` Lars Melin
2018-04-26 8:14 ` [PATCH] " Johan Hovold
2018-04-26 8:14 ` Johan Hovold
2018-04-26 11:19 ` [PATCH] " Bjørn Mork
2018-04-26 11:19 ` Bjørn Mork
2018-04-26 11:39 ` [PATCH] " Lars Melin
2018-04-26 11:39 ` Lars Melin
2018-04-26 11:40 ` [PATCH] " Lars Melin
2018-04-26 11:40 ` Lars Melin
2018-04-26 16:12 ` [PATCH] " Johan Hovold
2018-04-26 16:12 ` Johan Hovold
2018-04-26 16:12 ` [PATCH] " Johan Hovold
2018-04-26 16:22 ` Lars Melin
2018-04-26 16:22 ` Lars Melin
2018-04-26 16:29 ` [PATCH] " Johan Hovold
2018-04-26 16:29 ` Johan Hovold
2018-04-26 16:29 ` [PATCH] " Johan Hovold
2018-04-26 19:12 ` Dan Williams
2018-04-26 19:12 ` Dan Williams
2018-04-27 2:14 ` [PATCH] " SZ Lin (林上智)
2018-04-27 2:14 ` SZ Lin
2018-05-02 7:22 ` [PATCH] " Johan Hovold
2018-05-02 7:22 ` Johan Hovold
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.