[PATCH 1/1] USB: option: add support for Telit LE920

[PATCH 1/1] USB: option: add support for Telit LE920

[Daniele Palmas]

From: danielepa <danielepa@L2011.(none)>

Add PID and special handling for Telit LE920

Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
---
 drivers/usb/serial/option.c |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 0d9dac9..384bb92 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -242,6 +242,7 @@ static void option_instat_callback(struct urb *urb);
 #define TELIT_PRODUCT_CC864_DUAL		0x1005
 #define TELIT_PRODUCT_CC864_SINGLE		0x1006
 #define TELIT_PRODUCT_DE910_DUAL		0x1010
+#define TELIT_PRODUCT_LE920			0x1200
 
 /* ZTE PRODUCTS */
 #define ZTE_VENDOR_ID				0x19d2
@@ -534,6 +535,11 @@ static const struct option_blacklist_info zte_1255_blacklist = {
 	.reserved = BIT(3) | BIT(4),
 };
 
+static const struct option_blacklist_info telit_le920_blacklist = {
+	.sendsetup = BIT(0),
+	.reserved = BIT(1) | BIT(5),
+};
+
 static const struct usb_device_id option_ids[] = {
 	{ USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_COLT) },
 	{ USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_RICOLA) },
@@ -784,6 +790,8 @@ static const struct usb_device_id option_ids[] = {
 	{ USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_CC864_DUAL) },
 	{ USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_CC864_SINGLE) },
 	{ USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_DE910_DUAL) },
+	{ USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_LE920),
+		.driver_info = (kernel_ulong_t)&telit_le920_blacklist },
 	{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_MF622, 0xff, 0xff, 0xff) }, /* ZTE WCDMA products */
 	{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0002, 0xff, 0xff, 0xff),
 		.driver_info = (kernel_ulong_t)&net_intf1_blacklist },
-- 
1.7.4.1

Re: [PATCH 1/1] USB: option: add support for Telit LE920

[Sergei Shtylyov]

Hello.

On 28-01-2013 19:47, Daniele Palmas wrote:

> From: danielepa <danielepa@L2011.(none)>

    Name/email should preferrably be the same as the one in your signoff. 
Besides, the email address is not valid here.

> Add PID and special handling for Telit LE920

> Signed-off-by: Daniele Palmas <dnlplm@gmail.com>

WBR, Sergei

Re: [PATCH 1/1] USB: option: add support for Telit LE920

[Dan Williams]

On Mon, 2013-01-28 at 16:47 +0100, Daniele Palmas wrote:
> From: danielepa <danielepa@L2011.(none)>
> 
> Add PID and special handling for Telit LE920

Any idea what interfaces 1 and 5 are?  Is one perhaps a pseudo-ethernet
interface that could be used instead of PPP?  What's the lsusb -v output
for the device?

Dan

> Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
> ---
>  drivers/usb/serial/option.c |    8 ++++++++
>  1 files changed, 8 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
> index 0d9dac9..384bb92 100644
> --- a/drivers/usb/serial/option.c
> +++ b/drivers/usb/serial/option.c
> @@ -242,6 +242,7 @@ static void option_instat_callback(struct urb *urb);
>  #define TELIT_PRODUCT_CC864_DUAL		0x1005
>  #define TELIT_PRODUCT_CC864_SINGLE		0x1006
>  #define TELIT_PRODUCT_DE910_DUAL		0x1010
> +#define TELIT_PRODUCT_LE920			0x1200
>  
>  /* ZTE PRODUCTS */
>  #define ZTE_VENDOR_ID				0x19d2
> @@ -534,6 +535,11 @@ static const struct option_blacklist_info zte_1255_blacklist = {
>  	.reserved = BIT(3) | BIT(4),
>  };
>  
> +static const struct option_blacklist_info telit_le920_blacklist = {
> +	.sendsetup = BIT(0),
> +	.reserved = BIT(1) | BIT(5),
> +};
> +
>  static const struct usb_device_id option_ids[] = {
>  	{ USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_COLT) },
>  	{ USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_RICOLA) },
> @@ -784,6 +790,8 @@ static const struct usb_device_id option_ids[] = {
>  	{ USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_CC864_DUAL) },
>  	{ USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_CC864_SINGLE) },
>  	{ USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_DE910_DUAL) },
> +	{ USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_LE920),
> +		.driver_info = (kernel_ulong_t)&telit_le920_blacklist },
>  	{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_MF622, 0xff, 0xff, 0xff) }, /* ZTE WCDMA products */
>  	{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0002, 0xff, 0xff, 0xff),
>  		.driver_info = (kernel_ulong_t)&net_intf1_blacklist },

Re: [PATCH 1/1] USB: option: add support for Telit LE920

[Bjørn Mork]

Dan Williams <dcbw@redhat.com> writes:
> On Mon, 2013-01-28 at 16:47 +0100, Daniele Palmas wrote:
>> From: danielepa <danielepa@L2011.(none)>
>> 
>> Add PID and special handling for Telit LE920
>
> Any idea what interfaces 1 and 5 are?  Is one perhaps a pseudo-ethernet
> interface that could be used instead of PPP?  What's the lsusb -v output
> for the device?

Daniele has already posted a patch adding intf #5 to qmi_wwan, so I
assume that is verified to be a QMI/rmnet interface.

But I was wondering about #1 too, if that indeed is a vendor specific
interface providing a non-serial, non-rmnet function.  What could that
be?


Bjørn

Re: [PATCH 1/1] USB: option: add support for Telit LE920

[Dan Williams]

On Tue, 2013-01-29 at 11:19 -0600, Dan Williams wrote:
> On Mon, 2013-01-28 at 16:47 +0100, Daniele Palmas wrote:
> > From: danielepa <danielepa@L2011.(none)>
> > 
> > Add PID and special handling for Telit LE920
> 
> Any idea what interfaces 1 and 5 are?  Is one perhaps a pseudo-ethernet
> interface that could be used instead of PPP?  What's the lsusb -v output
> for the device?

Nevermind, I see the QMI patch for the device now on netdev.

Dan

> Dan
> 
> > Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
> > ---
> >  drivers/usb/serial/option.c |    8 ++++++++
> >  1 files changed, 8 insertions(+), 0 deletions(-)
> > 
> > diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
> > index 0d9dac9..384bb92 100644
> > --- a/drivers/usb/serial/option.c
> > +++ b/drivers/usb/serial/option.c
> > @@ -242,6 +242,7 @@ static void option_instat_callback(struct urb *urb);
> >  #define TELIT_PRODUCT_CC864_DUAL		0x1005
> >  #define TELIT_PRODUCT_CC864_SINGLE		0x1006
> >  #define TELIT_PRODUCT_DE910_DUAL		0x1010
> > +#define TELIT_PRODUCT_LE920			0x1200
> >  
> >  /* ZTE PRODUCTS */
> >  #define ZTE_VENDOR_ID				0x19d2
> > @@ -534,6 +535,11 @@ static const struct option_blacklist_info zte_1255_blacklist = {
> >  	.reserved = BIT(3) | BIT(4),
> >  };
> >  
> > +static const struct option_blacklist_info telit_le920_blacklist = {
> > +	.sendsetup = BIT(0),
> > +	.reserved = BIT(1) | BIT(5),
> > +};
> > +
> >  static const struct usb_device_id option_ids[] = {
> >  	{ USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_COLT) },
> >  	{ USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_RICOLA) },
> > @@ -784,6 +790,8 @@ static const struct usb_device_id option_ids[] = {
> >  	{ USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_CC864_DUAL) },
> >  	{ USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_CC864_SINGLE) },
> >  	{ USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_DE910_DUAL) },
> > +	{ USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_LE920),
> > +		.driver_info = (kernel_ulong_t)&telit_le920_blacklist },
> >  	{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_MF622, 0xff, 0xff, 0xff) }, /* ZTE WCDMA products */
> >  	{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0002, 0xff, 0xff, 0xff),
> >  		.driver_info = (kernel_ulong_t)&net_intf1_blacklist },
> 
> 
> --
> 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

Re: [PATCH 1/1] USB: option: add support for Telit LE920

[Daniele Palmas]

Hello,

2013/1/29 Bjørn Mork <bjorn@mork.no>:
> Dan Williams <dcbw@redhat.com> writes:
>> On Mon, 2013-01-28 at 16:47 +0100, Daniele Palmas wrote:
>>> From: danielepa <danielepa@L2011.(none)>
>>>
>>> Add PID and special handling for Telit LE920
>>
>> Any idea what interfaces 1 and 5 are?  Is one perhaps a pseudo-ethernet
>> interface that could be used instead of PPP?  What's the lsusb -v output
>> for the device?
>
> Daniele has already posted a patch adding intf #5 to qmi_wwan, so I
> assume that is verified to be a QMI/rmnet interface.
>
> But I was wondering about #1 too, if that indeed is a vendor specific
> interface providing a non-serial, non-rmnet function.  What could that
> be?
>
>
> Bjørn

The output of lsusb for interface #1 is the following:

Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass     66
      bInterfaceProtocol      1
      iInterface              0

It should be an adb device, so probably it is not needed to blacklist
it. Should I resend a new patch with only interface #5 reserved?

Thanks,
Daniele

Re: [PATCH 1/1] USB: option: add support for Telit LE920

[Bjørn Mork]

Daniele Palmas <dnlplm@gmail.com> writes:

> The output of lsusb for interface #1 is the following:
>
> Interface Descriptor:
>       bLength                 9
>       bDescriptorType         4
>       bInterfaceNumber        1
>       bAlternateSetting       0
>       bNumEndpoints           2
>       bInterfaceClass       255 Vendor Specific Class
>       bInterfaceSubClass     66
>       bInterfaceProtocol      1
>       iInterface              0
>
> It should be an adb device, so probably it is not needed to blacklist
> it. Should I resend a new patch with only interface #5 reserved?

You could have used USB_DEVICE_AND_INTERFACE_INFO() matching on all
ff/ff/ff to avoid blacklisting the adb interface, but IMHO the patch is
fine as it is.

This being an Android device raises another question though: Are these
interface numbers static?  I assume you can e.g. disable adb?  What
happens to the descriptors then?  Does the device change pid, or are the
interfaces renumbered?


Bjørn

Re: [PATCH 1/1] USB: option: add support for Telit LE920

[Daniele Palmas]

2013/1/30 Bjørn Mork <bjorn@mork.no>:
> Daniele Palmas <dnlplm@gmail.com> writes:
>
>> The output of lsusb for interface #1 is the following:
>>
>> Interface Descriptor:
>>       bLength                 9
>>       bDescriptorType         4
>>       bInterfaceNumber        1
>>       bAlternateSetting       0
>>       bNumEndpoints           2
>>       bInterfaceClass       255 Vendor Specific Class
>>       bInterfaceSubClass     66
>>       bInterfaceProtocol      1
>>       iInterface              0
>>
>> It should be an adb device, so probably it is not needed to blacklist
>> it. Should I resend a new patch with only interface #5 reserved?
>
> You could have used USB_DEVICE_AND_INTERFACE_INFO() matching on all
> ff/ff/ff to avoid blacklisting the adb interface, but IMHO the patch is
> fine as it is.
>

Thanks, next time I'll follow that way.

> This being an Android device raises another question though: Are these
> interface numbers static?  I assume you can e.g. disable adb?  What
> happens to the descriptors then?  Does the device change pid, or are the
> interfaces renumbered?
>

This is the device:

http://www.telit.com/en/products/lte.php?p_id=421&p_ac=show&p=130

It is not an Android device, but an AT command based modem. I don't
really know why there is an adb interface, but I am quite sure that
you cannot disable it and the interface numbers should be static.

However, if I find that this is not true, I will take care of sending
a new set of patches for addressing the issue.

Regards,
Daniele