Re: 4.16 issue with mbim modem and ping with size > 14552 bytes

[Daniele Palmas]

2018-05-25 0:54 GMT+02:00 Daniele Palmas <dnl...@gmail.com>:
> Hi Greg,
>
> 2018-05-24 17:53 GMT+02:00 Greg KH <gre...@linuxfoundation.org>:
>> On Thu, May 24, 2018 at 05:04:49PM +0200, Daniele Palmas wrote:
>>> Hello,
>>>
>>> I have an issue with an USB mbim modem when trying to send with ping
>>> more than 14552 bytes: it looks like to me a kernel issue, but not at
>>> the cdc_mbim or cdc_ncm level, anyway not sure, so I'm reporting the
>>> issue.
>>>
>>> My kernel is 4.16. The device is the following:
>>
>> Does older kernels work, or is this something that has always been
>> there?
>>
>
> Not tested yet, I'm going to do.
>

So, ping with more than 14552 was working properly until v4.5-rc7:
starting from v4.5 I'm not even able to make a data connection with
mbim since things fail badly with the following:

[  259.551836] [ cut here ]
[  259.551848] WARNING: CPU: 2 PID: 0 at
/home/kernel/COD/linux/net/sched/sch_generic.c:303
dev_watchdog+0x237/0x240()
[  259.551860] NETDEV WATCHDOG: wwp0s20u7i2 (cdc_mbim): transmit queue
0 timed out
[  259.551861] Modules linked in: cdc_mbim cdc_wdm cdc_ncm usbnet mii
intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp kvm
snd_hda_codec_realtek snd_hda_codec_hdmi snd_hda_codec_generic
irqbypass crct10dif_pclmul snd_hda_intel snd_hda_codec snd_hda_core
crc32_pclmul snd_hwdep ghash_clmulni_intel aesni_intel aes_x86_64
snd_pcm snd_seq_midi lrw snd_seq_midi_event gf128mul input_leds
snd_rawmidi snd_seq glue_helper snd_seq_device ablk_helper snd_timer
cryptd snd soundcore shpchp serio_raw mac_hid lpc_ich 8250_fintek
mei_me mei parport_pc ppdev lp parport autofs4 hid_generic usbhid hid
i915 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect psmouse
sysimgblt ahci fb_sys_fops e1000e libahci drm ptp pps_core wmi fjes
video
[  259.551889] CPU: 2 PID: 0 Comm: swapper/2 Not tainted
4.5.0-040500-generic #201603140130
[  259.551890] Hardware name: LENOVO 10A6A0J5IX/SHARKBAY, BIOS
FBKT79AUS 04/17/2014
[  259.551891]  0286 108c91d75cf5b65f 88021eb03d98
813e0233
[  259.551893]  88021eb03de0 81d816a0 88021eb03dd0
81080e72
[  259.551894]   8800cee81880 0002
8800a19f8000
[  259.551895] Call Trace:
[  259.551896][] dump_stack+0x63/0x90
[  259.551903]  [] warn_slowpath_common+0x82/0xc0
[  259.551904]  [] warn_slowpath_fmt+0x5c/0x80
[  259.551907]  [] dev_watchdog+0x237/0x240
[  259.551909]  [] ? qdisc_rcu_free+0x40/0x40
[  259.551910]  [] call_timer_fn+0x35/0x120
[  259.551911]  [] ? qdisc_rcu_free+0x40/0x40
[  259.551912]  [] run_timer_softirq+0x246/0x2f0
[  259.551914]  [] __do_softirq+0xf6/0x280
[  259.551916]  [] irq_exit+0xa3/0xb0
[  259.551919]  [] smp_apic_timer_interrupt+0x42/0x50
[  259.551920]  [] apic_timer_interrupt+0x82/0x90
[  259.551922][] ? cpuidle_enter_state+0x11d/0x2c0
[  259.551925]  [] cpuidle_enter+0x17/0x20
[  259.551928]  [] call_cpuidle+0x2a/0x40
[  259.551929]  [] cpu_startup_entry+0x295/0x350
[  259.551931]  [] start_secondary+0x15e/0x190
[  259.551933] ---[ end trace 6f8d3c1a1b02644d ]---

but this is probably something different, cause with v4.16 data
connection works fine.

If this is not helpful I guess I need to bisect.

Thanks,
Daniele

>> I ask, as my mobile provider does horrible things to large packet sizes.
>> So much so that I have to set the mtu to 1280 just to get things to work
>> properly when tethering my phone through to my laptop.  So this might be
>> a network provider issue :)
>>
>
> Yeah, I thought the same, so I tried the same scenario with Windows 10
> but it is working fine.
>
> Thanks,
> Daniele
>
>> thanks,
>>
>> greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 4.16 issue with mbim modem and ping with size > 14552 bytes

[Daniele Palmas]

Hi Greg,

2018-05-24 17:53 GMT+02:00 Greg KH <gre...@linuxfoundation.org>:
> On Thu, May 24, 2018 at 05:04:49PM +0200, Daniele Palmas wrote:
>> Hello,
>>
>> I have an issue with an USB mbim modem when trying to send with ping
>> more than 14552 bytes: it looks like to me a kernel issue, but not at
>> the cdc_mbim or cdc_ncm level, anyway not sure, so I'm reporting the
>> issue.
>>
>> My kernel is 4.16. The device is the following:
>
> Does older kernels work, or is this something that has always been
> there?
>

Not tested yet, I'm going to do.

> I ask, as my mobile provider does horrible things to large packet sizes.
> So much so that I have to set the mtu to 1280 just to get things to work
> properly when tethering my phone through to my laptop.  So this might be
> a network provider issue :)
>

Yeah, I thought the same, so I tried the same scenario with Windows 10
but it is working fine.

Thanks,
Daniele

> thanks,
>
> greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

4.16 issue with mbim modem and ping with size > 14552 bytes

[Daniele Palmas]

Hello,

I have an issue with an USB mbim modem when trying to send with ping
more than 14552 bytes: it looks like to me a kernel issue, but not at
the cdc_mbim or cdc_ncm level, anyway not sure, so I'm reporting the
issue.

My kernel is 4.16. The device is the following:

root@L2122:~# ifconfig
wwp0s20u7i2 Link encap:Ethernet  HWaddr be:3d:f2:f4:0d:e9
  inet addr:2.193.7.73  Bcast:0.0.0.0  Mask:255.255.255.252
  inet6 addr: fe80::bc3d:f2ff:fef4:de9/64 Scope:Link
  UP BROADCAST RUNNING NOARP MULTICAST  MTU:1500  Metric:1
  RX packets:5 errors:0 dropped:0 overruns:0 frame:0
  TX packets:55 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:759 (759.0 B)  TX bytes:6275 (6.2 KB)

Sending ping sized 14552 no issue:

root@L2122:~# ping -s 14552 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 14552(14580) bytes of data.
1448 bytes from 8.8.8.8: icmp_seq=1 ttl=52 (truncated)
1448 bytes from 8.8.8.8: icmp_seq=2 ttl=52 (truncated)
1448 bytes from 8.8.8.8: icmp_seq=3 ttl=52 (truncated)
1448 bytes from 8.8.8.8: icmp_seq=4 ttl=52 (truncated)
1448 bytes from 8.8.8.8: icmp_seq=5 ttl=52 (truncated)
1448 bytes from 8.8.8.8: icmp_seq=6 ttl=52 (truncated)
1448 bytes from 8.8.8.8: icmp_seq=7 ttl=52 (truncated)
1448 bytes from 8.8.8.8: icmp_seq=8 ttl=52 (truncated)
^C
--- 8.8.8.8 ping statistics ---
8 packets transmitted, 8 received, 0% packet loss, time 7008ms
rtt min/avg/max/mdev = 54.887/83.154/102.563/18.502 ms

root@L2122:~# ifconfig
wwp0s20u7i2 Link encap:Ethernet  HWaddr be:3d:f2:f4:0d:e9
  inet addr:2.193.7.73  Bcast:0.0.0.0  Mask:255.255.255.252
  inet6 addr: fe80::bc3d:f2ff:fef4:de9/64 Scope:Link
  UP BROADCAST RUNNING NOARP MULTICAST  MTU:1500  Metric:1
  RX packets:15 errors:0 dropped:0 overruns:0 frame:0
  TX packets:161 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:12583 (12.5 KB)  TX bytes:125999 (125.9 KB)

If I try ping sized 14554, it does not work

root@L2122:~# ping -s 14554 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 14554(14582) bytes of data.
^C
--- 8.8.8.8 ping statistics ---
7 packets transmitted, 0 received, 100% packet loss, time 6122ms

and I see tx errors in the network interface

root@L2122:~# ifconfig
wwp0s20u7i2 Link encap:Ethernet  HWaddr be:3d:f2:f4:0d:e9
  inet addr:2.193.7.73  Bcast:0.0.0.0  Mask:255.255.255.252
  inet6 addr: fe80::bc3d:f2ff:fef4:de9/64 Scope:Link
  UP BROADCAST RUNNING NOARP MULTICAST  MTU:1500  Metric:1
  RX packets:20 errors:0 dropped:0 overruns:0 frame:0
  TX packets:190 errors:5 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:12943 (12.9 KB)  TX bytes:142476 (142.4 KB)

but the real problem is that the network interface seems not to be
working anymore:

root@L2122:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
^C
--- 8.8.8.8 ping statistics ---
10 packets transmitted, 0 received, 100% packet loss, time 9193ms

root@L2122:~#
root@L2122:~# ifconfig
wwp0s20u7i2 Link encap:Ethernet  HWaddr be:3d:f2:f4:0d:e9
  inet addr:2.193.7.73  Bcast:0.0.0.0  Mask:255.255.255.252
  inet6 addr: fe80::bc3d:f2ff:fef4:de9/64 Scope:Link
  UP BROADCAST RUNNING NOARP MULTICAST  MTU:1500  Metric:1
  RX packets:20 errors:0 dropped:0 overruns:0 frame:0
  TX packets:190 errors:20 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:12943 (12.9 KB)  TX bytes:142476 (142.4 KB)

Nothing relevant in the kernel log.

Anyone can suggest me how to debug this further?

Thanks in advance,
Daniele
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/1] usb: serial: option: add support for Telit ME910 PID 0x1101

[Daniele Palmas]

This patch adds support for PID 0x1101 of Telit ME910.

Signed-off-by: Daniele Palmas <dnl...@gmail.com>
---
Following lsusb output for 0x1101 composition

tty, tty, tty, rmnet

Bus 003 Device 015: ID 1bc7:1101 Telit Wireless Solutions
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize064
  idVendor   0x1bc7 Telit Wireless Solutions
  idProduct  0x1101
  bcdDevice0.00
  iManufacturer   3 Telit
  iProduct2 Telit ME910
  iSerial 4 5f97073d
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength  122
bNumInterfaces  4
bConfigurationValue 1
iConfiguration  1 Telit Configuration
bmAttributes 0xe0
  Self Powered
  Remote Wakeup
MaxPower  500mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass255 Vendor Specific Subclass
  bInterfaceProtocol255 Vendor Specific Protocol
  iInterface  0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01  EP 1 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber1
  bAlternateSetting   0
  bNumEndpoints   3
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass255 Vendor Specific Subclass
  bInterfaceProtocol255 Vendor Specific Protocol
  iInterface  0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82  EP 2 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   5
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83  EP 3 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02  EP 2 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber2
  bAlternateSetting   0
  bNumEndpoints   3
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass254
  bInterfaceProtocol255
  iInterface  0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84  EP 4 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   5
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x85  EP 5 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03  EP 3 OUT
bmAttributes2
  Transfe

[PATCH 1/1] usb: serial: option: add Telit ME910 support

[Daniele Palmas]

This patch adds support for Telit ME910 PID 0x1100.

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

0x1100 composition is:

tty + qdss + tty + rmnet

Following lsusb output:

Bus 003 Device 018: ID 1bc7:1100 Telit Wireless Solutions 
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0 
  bDeviceProtocol 0 
  bMaxPacketSize064
  idVendor   0x1bc7 Telit Wireless Solutions
  idProduct  0x1100 
  bcdDevice0.00
  iManufacturer   3 Telit
  iProduct2 Telit ME910
  iSerial 4 1f5fec
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength  108
bNumInterfaces  4
bConfigurationValue 1
iConfiguration  1 Telit Configuration
bmAttributes 0xe0
  Self Powered
  Remote Wakeup
MaxPower  500mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass255 Vendor Specific Subclass
  bInterfaceProtocol255 Vendor Specific Protocol
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01  EP 1 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber1
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass255 Vendor Specific Subclass
  bInterfaceProtocol255 Vendor Specific Protocol
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82  EP 2 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber2
  bAlternateSetting   0
  bNumEndpoints   3
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass255 Vendor Specific Subclass
  bInterfaceProtocol255 Vendor Specific Protocol
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83  EP 3 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   5
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84  EP 4 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02  EP 2 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber3
  bAlternateSetting   0
  bNumEndpoints   3
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass255 Vendor Specific Subclass
  bInterfaceProtocol255 Vendor Specific Protocol
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x85

Re: [PATCH] USB: Revert "cdc-wdm: fix "out-of-sync" due to missing notifications"

[Daniele Palmas]

Hi Bjørn,

2017-04-21 10:01 GMT+02:00 Bjørn Mork <bj...@mork.no>:
> This reverts commit 833415a3e781 ("cdc-wdm: fix "out-of-sync" due to
> missing notifications")
>
> There have been several reports of wdm_read returning unexpected EIO
> errors with QMI devices using the qmi_wwan driver. The reporters
> confirm that reverting prevents these errors. I have been unable to
> reproduce the bug myself, and have no explanation to offer either. But
> reverting is the safe choice here, given that the commit was an
> attempt to work around a firmware problem.  Living with a firmware
> problem is still better than adding driver bugs.
>
> Reported-by: Kasper Holtze <kas...@holtze.dk>
> Reported-by: Aleksander Morgado <aleksan...@aleksander.es>
> Reported-by: Daniele Palmas <dnl...@gmail.com>
> Cc: <sta...@vger.kernel.org> # v4.9+
> Fixes: 833415a3e781 ("cdc-wdm: fix "out-of-sync" due to missing 
> notifications")
> Signed-off-by: Bjørn Mork <bj...@mork.no>
> ---

Tested with a variety of Telit modems with recent and older QC
chipsets, verified working fine on my side.

Thanks a lot,
Daniele

>  drivers/usb/class/cdc-wdm.c | 103 
> ++--
>  1 file changed, 4 insertions(+), 99 deletions(-)
>
> diff --git a/drivers/usb/class/cdc-wdm.c b/drivers/usb/class/cdc-wdm.c
> index 8fda45a45bd3..08669fee6d7f 100644
> --- a/drivers/usb/class/cdc-wdm.c
> +++ b/drivers/usb/class/cdc-wdm.c
> @@ -58,7 +58,6 @@ MODULE_DEVICE_TABLE (usb, wdm_ids);
>  #define WDM_SUSPENDING 8
>  #define WDM_RESETTING  9
>  #define WDM_OVERFLOW   10
> -#define WDM_DRAIN_ON_OPEN  11
>
>  #define WDM_MAX16
>
> @@ -182,7 +181,7 @@ static void wdm_in_callback(struct urb *urb)
> "nonzero urb status received: -ESHUTDOWN\n");
> goto skip_error;
> case -EPIPE:
> -   dev_dbg(>intf->dev,
> +   dev_err(>intf->dev,
> "nonzero urb status received: -EPIPE\n");
> break;
> default:
> @@ -210,25 +209,6 @@ static void wdm_in_callback(struct urb *urb)
> desc->reslength = length;
> }
> }
> -
> -   /*
> -* Handling devices with the WDM_DRAIN_ON_OPEN flag set:
> -* If desc->resp_count is unset, then the urb was submitted
> -* without a prior notification.  If the device returned any
> -* data, then this implies that it had messages queued without
> -* notifying us.  Continue reading until that queue is flushed.
> -*/
> -   if (!desc->resp_count) {
> -   if (!length) {
> -   /* do not propagate the expected -EPIPE */
> -   desc->rerr = 0;
> -   goto unlock;
> -   }
> -   dev_dbg(>intf->dev, "got %d bytes without 
> notification\n", length);
> -   set_bit(WDM_RESPONDING, >flags);
> -   usb_submit_urb(desc->response, GFP_ATOMIC);
> -   }
> -
>  skip_error:
> set_bit(WDM_READ, >flags);
> wake_up(>wait);
> @@ -243,7 +223,6 @@ static void wdm_in_callback(struct urb *urb)
> service_outstanding_interrupt(desc);
> }
>
> -unlock:
> spin_unlock(>iuspin);
>  }
>
> @@ -686,17 +665,6 @@ static int wdm_open(struct inode *inode, struct file 
> *file)
> dev_err(>intf->dev,
> "Error submitting int urb - %d\n", rv);
> rv = usb_translate_errors(rv);
> -   } else if (test_bit(WDM_DRAIN_ON_OPEN, >flags)) {
> -   /*
> -* Some devices keep pending messages queued
> -* without resending notifications.  We must
> -* flush the message queue before we can
> -* assume a one-to-one relationship between
> -* notifications and messages in the queue
> -*/
> -   dev_dbg(>intf->dev, "draining queued data\n");
> -   set_bit(WDM_RESPONDING, >flags);
> -   rv = usb_submit_urb(desc->response, GFP_KERNEL);
> }
> } else {
> rv = 0;
> @@ -803,8 +771,7 @@ static void wdm_rxwork(struct work_struct *work)
>  /* --- hotplug --- */
>
&g

Re: [PATCH 1/1] drivers: net: usb: qmi_wwan: add QMI_QUIRK_SET_DTR for Telit PID 0x1201

[Daniele Palmas]

Hi Bjørn,

2017-04-21 12:30 GMT+02:00 Daniele Palmas <dnl...@gmail.com>:
> Hi Bjørn,
>
> 2017-04-19 19:28 GMT+02:00 Bjørn Mork <bj...@mork.no>:
>> Daniele Palmas <dnl...@gmail.com> writes:
>>
>>
>> Would you mind describing in detail how you trigger the EIOs?  What
>> software and command sequence are you using?  Does it reliably reproduce
>> the issue, or do you have to try several times?  What modem chipset and
>> firmware is used?
>>
>
> sorry for the delay, I'm using latest qmicli in master:
>
> danielepa@danielepa-OptiPlex-780:~/development/git/libqmi$ src/qmicli/qmicli 
> -V
>
> qmicli 1.19.0
>
> and I was able to reproduce the issue simply asking for something like
> the manufacturer with qmicli.
>
> But I'm currently retrying it and it has become even worse (do not ask
> me why...): qmicli returns a transaction timed out error and got
> stuck. Only when detaching the USB cable qmicli exits.
>
> danielepa@danielepa-OptiPlex-780:~/development/git/libqmi$ sudo
> src/qmicli/qmicli -d /dev/cdc-wdm0 --dms-get-manufacturer
> [21 apr 2017, 12:15:33] -Warning ** [/dev/cdc-wdm0] requested auto
> mode but no MBIM QMUX support available
> error: couldn't create client for the 'dms' service: CID allocation
> failed in the CTL client: Transaction timed out
>
> I'm not sure I'm seeing here only problems related to your commit, but
> reverting the commit makes things to work again.
>
> The modem is a Telit LE920A4. I will try to collect more debug info.
>

So, I applied your debug patch and this is what is happening:

[ 4294.935912] usb 2-2: new high-speed USB device number 18 using ehci-pci
[ 4295.101548] usb 2-2: New USB device found, idVendor=1bc7, idProduct=1201
[ 4295.101551] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 4295.101553] usb 2-2: Product: Android
[ 4295.101555] usb 2-2: Manufacturer: Android
[ 4295.101557] usb 2-2: SerialNumber: 0123456789ABCDEF
[ 4295.118159] option 2-2:1.0: GSM modem (1-port) converter detected
[ 4295.118280] usb 2-2: GSM modem (1-port) converter now attached to ttyUSB0
[ 4295.119265] qmi_wwan 2-2:1.2: cdc-wdm0: USB WDM device
[ 4295.120387] qmi_wwan 2-2:1.2 wwan0: register 'qmi_wwan' at
usb-:00:1d.7-2, WWAN/QMI device, fe:b2:dd:b6:d5:b3
[ 4295.120464] option 2-2:1.3: GSM modem (1-port) converter detected
[ 4295.120555] usb 2-2: GSM modem (1-port) converter now attached to ttyUSB1
[ 4295.120643] option 2-2:1.4: GSM modem (1-port) converter detected
[ 4295.120699] usb 2-2: GSM modem (1-port) converter now attached to ttyUSB2
[ 4295.120785] option 2-2:1.5: GSM modem (1-port) converter detected
[ 4295.120839] usb 2-2: GSM modem (1-port) converter now attached to ttyUSB3
[ 4295.120923] option 2-2:1.6: GSM modem (1-port) converter detected
[ 4295.120978] usb 2-2: GSM modem (1-port) converter now attached to ttyUSB4
[ 4306.730786] wdm_open: qmi_wwan 2-2:1.2: draining queued data
[ 4306.730955] wdm_write: qmi_wwan 2-2:1.2: Tx URB has been submitted index=2

Here qmicli is stuck. Then I disconnect the cable:

[ 4421.317327] usb 2-2: USB disconnect, device number 18
[ 4421.317541] option1 ttyUSB0: GSM modem (1-port) converter now
disconnected from ttyUSB0
[ 4421.317558] option 2-2:1.0: device disconnected
[ 4421.320113] qmi_wwan 2-2:1.2 wwan0: unregister 'qmi_wwan'
usb-:00:1d.7-2, WWAN/QMI device
[ 4421.321297] qmi_wwan 2-2:1.2: Unexpected error -71
[ 4421.321303] wdm_in_callback: qmi_wwan 2-2:1.2: rerr=-71,
status=-71, length=0, resp_count=0
[ 4421.325567] qmi_wwan 2-2:1.2: Error in flush path: -71
[ 4421.325579] wdm_release: qmi_wwan 2-2:1.2: wdm_release: cleanup
[ 4421.335695] option1 ttyUSB1: GSM modem (1-port) converter now
disconnected from ttyUSB1
[ 4421.335710] option 2-2:1.3: device disconnected
[ 4421.335838] option1 ttyUSB2: GSM modem (1-port) converter now
disconnected from ttyUSB2
[ 4421.335850] option 2-2:1.4: device disconnected
[ 4421.335972] option1 ttyUSB3: GSM modem (1-port) converter now
disconnected from ttyUSB3
[ 4421.335984] option 2-2:1.5: device disconnected
[ 4421.336175] option1 ttyUSB4: GSM modem (1-port) converter now
disconnected from ttyUSB4
[ 4421.336187] option 2-2:1.6: device disconnected

This is instead the output with the commit reverted:

[ 9868.397535] usb 2-2: new high-speed USB device number 19 using ehci-pci
[ 9868.563187] usb 2-2: New USB device found, idVendor=1bc7, idProduct=1201
[ 9868.563189] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 9868.563191] usb 2-2: Product: Android
[ 9868.563193] usb 2-2: Manufacturer: Android
[ 9868.563195] usb 2-2: SerialNumber: 0123456789ABCDEF
[ 9868.579788] option 2-2:1.0: GSM modem (1-port) converter detected
[ 9868.579920] usb 2-2: GSM modem (1-port) converter now attached to ttyUSB0
[ 9868.580559] option 2-2:1.3: GSM modem (1-port) converter detected
[ 9868.580629] usb 2-2: GSM modem (1-port) con

Re: [PATCH 1/1] drivers: net: usb: qmi_wwan: add QMI_QUIRK_SET_DTR for Telit PID 0x1201

[Daniele Palmas]

Hi Bjørn,

2017-04-19 19:28 GMT+02:00 Bjørn Mork <bj...@mork.no>:
> Daniele Palmas <dnl...@gmail.com> writes:
>
>> as a side note in latest kernels I had troubles with qmi devices
>> (e.g. I/O error when using qmicli).
>>
>> I found your suggestion in libqmi mailing list to revert commit
>>
>> 833415a3e781a26fe480a34d45086bdb4fe1e4c0
>> cdc-wdm: fix "out-of-sync" due to missing notifications
>
> I guess a revert of that commit should be done then..
>
> I have been stalling because I have been hoping to replace it with a
> better fix instead of a plain revert. I believe there are several issues
> playing badly together here.  That commit was _expected_ to cause
> spurious EPIPE errors, which would be translated to EIO if they were
> propagated.  But they should be filtered out rightaway, in theory. This
> works for me.  I can see the EPIPEs with debugging, but I have never
> seen any EIO from read.
>
> And there is the problem: I am unable to reproduce this problem.  I have
> previously tested this back and forth with several MDM9200 and MDM9235
> generation modems in QMI mode, as well as in MBIM mode.  And also with a
> number of other MBIM modems.  Aleksander reported that he could
> reproduce the issue using an MDM9x15 generation modem in QMI mode, but
> not with any MDM9x00 or MDM9x35 modem.  So I have now tried any way I
> can imagine to reproduce the issue with a Sierra Wireless EM7305, which
> is the only MDM9x15 modem I have. The firmware is SWI9X15C_05.05.58.00.
>
> But unfortunately the testing is still without "success".  It plain
> works for me, every time, using ModemManager, qmicli with or without
> proxy, or uqmi.
>
> Would you mind describing in detail how you trigger the EIOs?  What
> software and command sequence are you using?  Does it reliably reproduce
> the issue, or do you have to try several times?  What modem chipset and
> firmware is used?
>

sorry for the delay, I'm using latest qmicli in master:

danielepa@danielepa-OptiPlex-780:~/development/git/libqmi$ src/qmicli/qmicli -V

qmicli 1.19.0

and I was able to reproduce the issue simply asking for something like
the manufacturer with qmicli.

But I'm currently retrying it and it has become even worse (do not ask
me why...): qmicli returns a transaction timed out error and got
stuck. Only when detaching the USB cable qmicli exits.

danielepa@danielepa-OptiPlex-780:~/development/git/libqmi$ sudo
src/qmicli/qmicli -d /dev/cdc-wdm0 --dms-get-manufacturer
[21 apr 2017, 12:15:33] -Warning ** [/dev/cdc-wdm0] requested auto
mode but no MBIM QMUX support available
error: couldn't create client for the 'dms' service: CID allocation
failed in the CTL client: Transaction timed out

I'm not sure I'm seeing here only problems related to your commit, but
reverting the commit makes things to work again.

The modem is a Telit LE920A4. I will try to collect more debug info.

Thanks,
Daniele

>
>
>
> Bjørn
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/1] drivers: net: usb: qmi_wwan: add QMI_QUIRK_SET_DTR for Telit PID 0x1201

[Daniele Palmas]

Telit LE920A4 uses the same pid 0x1201 of LE920, but modem
implementation is different, since it requires DTR to be set for
answering to qmi messages.

This patch replaces QMI_FIXED_INTF with QMI_QUIRK_SET_DTR: tests on
LE920 have been performed in order to verify backward compatibility.

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

Hi Bjørn,

as a side note in latest kernels I had troubles with qmi devices
(e.g. I/O error when using qmicli).

I found your suggestion in libqmi mailing list to revert commit

833415a3e781a26fe480a34d45086bdb4fe1e4c0
cdc-wdm: fix "out-of-sync" due to missing notifications

and this seems to work.

Regards,
Daniele

---
 drivers/net/usb/qmi_wwan.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 156f7f8..2474618 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -908,7 +908,7 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x2357, 0x9000, 4)},/* TP-LINK MA260 */
{QMI_QUIRK_SET_DTR(0x1bc7, 0x1040, 2)}, /* Telit LE922A */
{QMI_FIXED_INTF(0x1bc7, 0x1200, 5)},/* Telit LE920 */
-   {QMI_FIXED_INTF(0x1bc7, 0x1201, 2)},/* Telit LE920 */
+   {QMI_QUIRK_SET_DTR(0x1bc7, 0x1201, 2)}, /* Telit LE920, LE920A4 */
{QMI_FIXED_INTF(0x1c9e, 0x9b01, 3)},/* XS Stick W100-2 from 4G 
Systems */
{QMI_FIXED_INTF(0x0b3c, 0xc000, 4)},/* Olivetti Olicard 100 */
{QMI_FIXED_INTF(0x0b3c, 0xc001, 4)},/* Olivetti Olicard 120 */
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/2] net: usb: qmi_wwan: add qmap mux protocol support

[Daniele Palmas]

Hi Subash,

2017-03-24 18:45 GMT+01:00 Subash Abhinov Kasiviswanathan
<subas...@codeaurora.org>:
> On 2017-03-24 07:22, Daniele Palmas wrote:
>>
>> This patch adds support for qmap mux protocol available in recent
>> Qualcomm based modems.
>>
>> The qmap mux protocol can be used for multiplexing data packets in
>> order to have multiple ip streams through the same physical device.
>>
>> Two new sysfs files are added for adding/removing the qmap mux based
>> interfaces (named qmimux):
>>
>> /sys/class/net//qmi/add_mux
>> /sys/class/net//qmi/del_mux
>>
>> Main patch author is Bjørn Mork <bj...@mork.no>
>>
>> An userspace implementation of the qmi requests needed to support
>> multiple ip streams is already available (namely libqmi since
>> version 1.18.0).
>>
>> The qmap mux feature has been recently implemented in Codeaurora
>> gobinet out-of-kernel driver that was the inspiration for this
>> development.
>>
>> Tests have been performed with Telit LE922A6 (PID 0x1040)
>>
>> Daniele Palmas (2):
>>   net: usb: qmi_wwan: add qmap mux protocol support
>>   Documentation: ABI: testing: sysfs-class-net-qmi: add new qmap mux
>> files description
>>
>>  Documentation/ABI/testing/sysfs-class-net-qmi |  27 +++
>>  drivers/net/usb/qmi_wwan.c| 317
>> +-
>>  2 files changed, 343 insertions(+), 1 deletion(-)
>
>
> Hi Daniele
>
> We are working on something similar
> https://www.mail-archive.com/netdev@vger.kernel.org/msg157677.html
>
> We are planning to upstream this as a platform agnostic driver without
> tying it to a particular physical transport here.
>
> We also add support for aggregation and flow control (control packet 0x80)
> apart from the multiplexing.
>

Thanks, I'll take a look at your patch series.

Regards,
Daniele

> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] Documentation: ABI: testing: sysfs-class-net-qmi: add new qmap mux files description

[Daniele Palmas]

Hi Sergei,

2017-03-24 17:31 GMT+01:00 Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>:
> Hello!
>
>
> On 03/24/2017 04:22 PM, Daniele Palmas wrote:
>
>> This patch updates the documentation related to the new files added for
>> qmap mux support.
>>
>> Signed-off-by: Daniele Palmas <dnl...@gmail.com>
>> ---
>>  Documentation/ABI/testing/sysfs-class-net-qmi | 27
>> +++
>>  1 file changed, 27 insertions(+)
>>
>> diff --git a/Documentation/ABI/testing/sysfs-class-net-qmi
>> b/Documentation/ABI/testing/sysfs-class-net-qmi
>> index fa5a00b..5191dc3 100644
>> --- a/Documentation/ABI/testing/sysfs-class-net-qmi
>> +++ b/Documentation/ABI/testing/sysfs-class-net-qmi
>> @@ -21,3 +21,30 @@ Description:
>> is responsible for coordination of driver and firmware
>> link framing mode, changing this setting to 'Y' if the
>> firmware is configured for 'raw-ip' mode.
>> +
>> +What:  /sys/class/net//qmi/add_mux
>> +Date:  March 2017
>> +KernelVersion: 4.11
>> +Contact:   Bjørn Mork <bj...@mork.no>
>> +Description:
>> +   Unsigned integer.
>> +
>> +   Write a number ranging from 1 to 127 to add a qmap mux
>> +   based network device, supported by recent Qualcomm based
>> +   modems.
>> +
>> +   The network device will be called qmimux.
>> +
>> +   Userspace is in charge of managing the qmux network device
>> +   activation and data stream setup  on them modem side by
>
>
>s/them/the/?
>

I will fix this if there will be a v2 series.

Thanks,
Daniele

>> +   using the proper QMI protocol requests.
>
> [...]
>
> MBR, Sergei
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/2] net: usb: qmi_wwan: add qmap mux protocol support

[Daniele Palmas]

This patch adds support for qmap mux protocol available in recent
Qualcomm based modems.

The qmap mux protocol can be used for multiplexing data packets in
order to have multiple ip streams through the same physical device.

Two new sysfs files are added for adding/removing the qmap mux based
interfaces (named qmimux):

/sys/class/net//qmi/add_mux
/sys/class/net//qmi/del_mux

Main patch author is Bjørn Mork <bj...@mork.no>

An userspace implementation of the qmi requests needed to support
multiple ip streams is already available (namely libqmi since
version 1.18.0).

The qmap mux feature has been recently implemented in Codeaurora
gobinet out-of-kernel driver that was the inspiration for this
development.

Tests have been performed with Telit LE922A6 (PID 0x1040)

Daniele Palmas (2):
  net: usb: qmi_wwan: add qmap mux protocol support
  Documentation: ABI: testing: sysfs-class-net-qmi: add new qmap mux
files description

 Documentation/ABI/testing/sysfs-class-net-qmi |  27 +++
 drivers/net/usb/qmi_wwan.c| 317 +-
 2 files changed, 343 insertions(+), 1 deletion(-)

-- 
2.8.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] net: usb: qmi_wwan: add qmap mux protocol support

[Daniele Palmas]

This patch adds support for qmap mux protocol available in recent
Qualcomm based modems.

The qmap mux protocol can be used for multiplexing data packets in
order to have multiple ip streams through the same physical device.

Two new sysfs files are added for adding/removing the qmap mux based
interfaces (named qmimux):

- /sys/class/net//qmi/add_mux
- /sys/class/net//qmi/del_mux

Main patch author is Bjørn Mork <bj...@mork.no>

Signed-off-by: Bjørn Mork <bj...@mork.no>
Signed-off-by: Daniele Palmas <dnl...@gmail.com>
---
 drivers/net/usb/qmi_wwan.c | 317 -
 1 file changed, 316 insertions(+), 1 deletion(-)

diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 8056745..55f2303 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -58,12 +58,198 @@ struct qmi_wwan_state {
 
 enum qmi_wwan_flags {
QMI_WWAN_FLAG_RAWIP = 1 << 0,
+   QMI_WWAN_FLAG_MUX = 1 << 1,
 };
 
 enum qmi_wwan_quirks {
QMI_WWAN_QUIRK_DTR = 1 << 0,/* needs "set DTR" request */
 };
 
+struct qmimux_hdr {
+   u8 pad;
+   u8 mux_id;
+   __be16 pkt_len;
+};
+
+struct qmimux_priv {
+   struct net_device *real_dev;
+   u8 mux_id;
+};
+
+static int qmimux_open(struct net_device *dev)
+{
+   struct qmimux_priv *priv = netdev_priv(dev);
+   struct net_device *real_dev = priv->real_dev;
+
+   if (!(priv->real_dev->flags & IFF_UP))
+   return -ENETDOWN;
+
+   if (netif_carrier_ok(real_dev))
+   netif_carrier_on(dev);
+   return 0;
+}
+
+static int qmimux_stop(struct net_device *dev)
+{
+   netif_carrier_off(dev);
+   return 0;
+}
+
+static netdev_tx_t qmimux_start_xmit(struct sk_buff *skb, struct net_device 
*dev)
+{
+   struct qmimux_priv *priv = netdev_priv(dev);
+   unsigned int len = skb->len;
+   struct qmimux_hdr *hdr;
+
+   hdr = (struct qmimux_hdr *)skb_push(skb, sizeof(struct qmimux_hdr));
+   hdr->pad = 0;
+   hdr->mux_id = priv->mux_id;
+   hdr->pkt_len = cpu_to_be16(len);
+   skb->dev = priv->real_dev;
+   return dev_queue_xmit(skb);
+}
+
+static const struct net_device_ops qmimux_netdev_ops = {
+   .ndo_open   = qmimux_open,
+   .ndo_stop   = qmimux_stop,
+   .ndo_start_xmit = qmimux_start_xmit,
+};
+
+static void qmimux_setup(struct net_device *dev)
+{
+   dev->header_ops  = NULL;  /* No header */
+   dev->type= ARPHRD_NONE;
+   dev->hard_header_len = 0;
+   dev->addr_len= 0;
+   dev->flags   = IFF_POINTOPOINT | IFF_NOARP | IFF_MULTICAST;
+   dev->netdev_ops  = _netdev_ops;
+   dev->destructor  = free_netdev;
+}
+
+static struct net_device *qmimux_find_dev(struct usbnet *dev, u8 mux_id)
+{
+   struct qmimux_priv *priv;
+   struct list_head *iter;
+   struct net_device *ldev;
+
+   rcu_read_lock();
+   netdev_for_each_upper_dev_rcu(dev->net, ldev, iter) {
+   priv = netdev_priv(ldev);
+   if (priv->mux_id == mux_id) {
+   rcu_read_unlock();
+   return ldev;
+   }
+   }
+   rcu_read_unlock();
+   return NULL;
+}
+
+static bool qmimux_has_slaves(struct usbnet *dev)
+{
+   return !list_empty(>net->adj_list.upper);
+}
+
+static int qmimux_rx_fixup(struct usbnet *dev, struct sk_buff *skb)
+{
+   unsigned int len, offset = sizeof(struct qmimux_hdr);
+   struct qmimux_hdr *hdr;
+   struct net_device *net;
+   struct sk_buff *skbn;
+
+   while (offset < skb->len) {
+   hdr = (struct qmimux_hdr *)skb->data;
+   len = be16_to_cpu(hdr->pkt_len);
+
+   /* drop the packet, bogus length */
+   if (offset + len > skb->len)
+   return 0;
+
+   /* control packet, we do not know what to do */
+   if (hdr->pad & 0x80)
+   goto skip;
+
+   net = qmimux_find_dev(dev, hdr->mux_id);
+   if (!net)
+   goto skip;
+   skbn = netdev_alloc_skb(net, len);
+   if (!skbn)
+   return 0;
+   skbn->dev = net;
+
+   switch (skb->data[offset] & 0xf0) {
+   case 0x40:
+   skbn->protocol = htons(ETH_P_IP);
+   break;
+   case 0x60:
+   skbn->protocol = htons(ETH_P_IPV6);
+   break;
+   default:
+   /* not ip - do not know what to do */
+   goto skip;
+   }
+
+   memcpy(skb_put(skbn, len), skb->data + offset, len);
+   if (netif_rx(skbn) != NET_RX_SUCCESS)
+   

[PATCH 2/2] Documentation: ABI: testing: sysfs-class-net-qmi: add new qmap mux files description

[Daniele Palmas]

This patch updates the documentation related to the new files added for
qmap mux support.

Signed-off-by: Daniele Palmas <dnl...@gmail.com>
---
 Documentation/ABI/testing/sysfs-class-net-qmi | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-class-net-qmi 
b/Documentation/ABI/testing/sysfs-class-net-qmi
index fa5a00b..5191dc3 100644
--- a/Documentation/ABI/testing/sysfs-class-net-qmi
+++ b/Documentation/ABI/testing/sysfs-class-net-qmi
@@ -21,3 +21,30 @@ Description:
is responsible for coordination of driver and firmware
link framing mode, changing this setting to 'Y' if the
firmware is configured for 'raw-ip' mode.
+
+What:  /sys/class/net//qmi/add_mux
+Date:  March 2017
+KernelVersion: 4.11
+Contact:   Bjørn Mork <bj...@mork.no>
+Description:
+   Unsigned integer.
+
+   Write a number ranging from 1 to 127 to add a qmap mux
+   based network device, supported by recent Qualcomm based
+   modems.
+
+   The network device will be called qmimux.
+
+   Userspace is in charge of managing the qmux network device
+   activation and data stream setup  on them modem side by
+   using the proper QMI protocol requests.
+
+What:  /sys/class/net//qmi/del_mux
+Date:  March 2017
+KernelVersion: 4.11
+Contact:   Bjørn Mork <bj...@mork.no>
+Description:
+   Unsigned integer.
+
+   Write a number ranging from 1 to 127 to delete a previously
+   created qmap mux based network device.
-- 
2.8.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/1] NET: usb: cdc_mbim: add quirk for supporting Telit LE922A

[Daniele Palmas]

Telit LE922A MBIM based composition does not work properly
with altsetting toggle done in cdc_ncm_bind_common.

This patch adds CDC_MBIM_FLAG_AVOID_ALTSETTING_TOGGLE quirk
to avoid this procedure that, instead, is mandatory for
other modems.

References:
https://www.spinics.net/lists/linux-usb/msg149249.html
https://www.spinics.net/lists/linux-usb/msg149819.html

Thanks to Bjørn for the productive discussion and feedback!

Daniele Palmas (1):
  NET: usb: cdc_mbim: add quirk for supporting Telit LE922A

 drivers/net/usb/cdc_mbim.c  | 21 +
 drivers/net/usb/cdc_ncm.c   | 14 +-
 include/linux/usb/cdc_ncm.h |  3 ++-
 3 files changed, 32 insertions(+), 6 deletions(-)

-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/1] NET: usb: cdc_mbim: add quirk for supporting Telit LE922A

[Daniele Palmas]

Telit LE922A MBIM based composition does not work properly
with altsetting toggle done in cdc_ncm_bind_common.

This patch adds CDC_MBIM_FLAG_AVOID_ALTSETTING_TOGGLE quirk
to avoid this procedure that, instead, is mandatory for
other modems.

Signed-off-by: Daniele Palmas <dnl...@gmail.com>
---
 drivers/net/usb/cdc_mbim.c  | 21 +
 drivers/net/usb/cdc_ncm.c   | 14 +-
 include/linux/usb/cdc_ncm.h |  3 ++-
 3 files changed, 32 insertions(+), 6 deletions(-)

diff --git a/drivers/net/usb/cdc_mbim.c b/drivers/net/usb/cdc_mbim.c
index 96a5028..3a98f37 100644
--- a/drivers/net/usb/cdc_mbim.c
+++ b/drivers/net/usb/cdc_mbim.c
@@ -602,6 +602,21 @@ static const struct driver_info cdc_mbim_info_ndp_to_end = 
{
.data = CDC_NCM_FLAG_NDP_TO_END,
 };
 
+/* Some modems (e.g. Telit LE922A6) do not work properly with altsetting
+ * toggle done in cdc_ncm_bind_common. CDC_MBIM_FLAG_AVOID_ALTSETTING_TOGGLE
+ * flag is used to avoid this procedure.
+ */
+static const struct driver_info cdc_mbim_info_avoid_altsetting_toggle = {
+   .description = "CDC MBIM",
+   .flags = FLAG_NO_SETINT | FLAG_MULTI_PACKET | FLAG_WWAN,
+   .bind = cdc_mbim_bind,
+   .unbind = cdc_mbim_unbind,
+   .manage_power = cdc_mbim_manage_power,
+   .rx_fixup = cdc_mbim_rx_fixup,
+   .tx_fixup = cdc_mbim_tx_fixup,
+   .data = CDC_MBIM_FLAG_AVOID_ALTSETTING_TOGGLE,
+};
+
 static const struct usb_device_id mbim_devs[] = {
/* This duplicate NCM entry is intentional. MBIM devices can
 * be disguised as NCM by default, and this is necessary to
@@ -626,6 +641,12 @@ static const struct usb_device_id mbim_devs[] = {
{ USB_VENDOR_AND_INTERFACE_INFO(0x12d1, USB_CLASS_COMM, 
USB_CDC_SUBCLASS_MBIM, USB_CDC_PROTO_NONE),
  .driver_info = (unsigned long)_mbim_info_ndp_to_end,
},
+
+   /* Telit LE922A6 in MBIM composition */
+   { USB_DEVICE_AND_INTERFACE_INFO(0x1bc7, 0x1041, USB_CLASS_COMM, 
USB_CDC_SUBCLASS_MBIM, USB_CDC_PROTO_NONE),
+ .driver_info = (unsigned long)_mbim_info_avoid_altsetting_toggle,
+   },
+
/* default entry */
{ USB_INTERFACE_INFO(USB_CLASS_COMM, USB_CDC_SUBCLASS_MBIM, 
USB_CDC_PROTO_NONE),
  .driver_info = (unsigned long)_mbim_info_zlp,
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index 877c951..afbfc0f 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -839,11 +839,18 @@ int cdc_ncm_bind_common(struct usbnet *dev, struct 
usb_interface *intf, u8 data_
 
iface_no = ctx->data->cur_altsetting->desc.bInterfaceNumber;
 
+   /* Device-specific flags */
+   ctx->drvflags = drvflags;
+
/* Reset data interface. Some devices will not reset properly
 * unless they are configured first.  Toggle the altsetting to
-* force a reset
+* force a reset.
+* Some other devices do not work properly with this procedure
+* that can be avoided using quirk CDC_MBIM_FLAG_AVOID_ALTSETTING_TOGGLE
 */
-   usb_set_interface(dev->udev, iface_no, data_altsetting);
+   if (!(ctx->drvflags & CDC_MBIM_FLAG_AVOID_ALTSETTING_TOGGLE))
+   usb_set_interface(dev->udev, iface_no, data_altsetting);
+
temp = usb_set_interface(dev->udev, iface_no, 0);
if (temp) {
dev_dbg(>dev, "set interface failed\n");
@@ -890,9 +897,6 @@ int cdc_ncm_bind_common(struct usbnet *dev, struct 
usb_interface *intf, u8 data_
/* finish setting up the device specific data */
cdc_ncm_setup(dev);
 
-   /* Device-specific flags */
-   ctx->drvflags = drvflags;
-
/* Allocate the delayed NDP if needed. */
if (ctx->drvflags & CDC_NCM_FLAG_NDP_TO_END) {
ctx->delayed_ndp16 = kzalloc(ctx->max_ndp_size, GFP_KERNEL);
diff --git a/include/linux/usb/cdc_ncm.h b/include/linux/usb/cdc_ncm.h
index 3a375d0..00d2324 100644
--- a/include/linux/usb/cdc_ncm.h
+++ b/include/linux/usb/cdc_ncm.h
@@ -81,7 +81,8 @@
 #define CDC_NCM_TIMER_INTERVAL_MAX (U32_MAX / NSEC_PER_USEC)
 
 /* Driver flags */
-#define CDC_NCM_FLAG_NDP_TO_END0x02/* NDP is placed at end 
of frame */
+#define CDC_NCM_FLAG_NDP_TO_END0x02/* NDP is 
placed at end of frame */
+#define CDC_MBIM_FLAG_AVOID_ALTSETTING_TOGGLE  0x04/* Avoid altsetting 
toggle during init */
 
 #define cdc_ncm_comm_intf_is_mbim(x)  ((x)->desc.bInterfaceSubClass == 
USB_CDC_SUBCLASS_MBIM && \
   (x)->desc.bInterfaceProtocol == 
USB_CDC_PROTO_NONE)
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/1] NET: usb: cdc_ncm: adding MBIM RESET_FUNCTION request and modifying ncm bind common code

[Daniele Palmas]

2016-12-05 14:04 GMT+01:00 Daniele Palmas <dnl...@gmail.com>:
> Hi,
>
> 2016-12-05 11:10 GMT+01:00 Bjørn Mork <bj...@mork.no>:
>> Daniele Palmas <dnl...@gmail.com> writes:
>>
>>> I went back to this and further checking revealed that MBIM function
>>> reset is not needed and the only problem is related to commit
>>> 48906f62c96cc2cd35753e59310cb70eb08cc6a5 cdc_ncm: toggle altsetting to
>>> force reset before setup, that, however, is mandatory for some Huawei
>>> modems.
>>
>> Interesting.  That does sound like an odd firmware bug to me. I have a
>> bit of a hard time understanding how this can be.  Using data interface
>> altsetting 0 to reset the function is documented in the NCM spec:
>>
>
> Agree, this is likely a firmware bug and it is also proved by all the
> other modems that accept the procedure without issues.
>
>> "
>>   7.2 Using Alternate Settings to Reset an NCM Function
>>
>>   To place the network aspects of a function in a known state, the host
>>   shall:
>>   • select alternate setting 0 of the NCM Data Interface (this is the
>> setting with no endpoints). This can be done explicitly using
>> SetInterface, or implicitly using SetConfiguration. See [USB30] for
>> details.
>>   • select the NCM operational parameters by sending commands to the NCM
>> Communication Interface, then
>>   • select the second alternate interface setting of the NCM Data
>> Interface (this is the setting with a bulk IN endpoint and a bulk
>> OUT endpoint).
>>
>>   Whenever alternate setting 0 is selected by the host, the function
>>   shall:
>>   • flush function buffers
>>   • reset the packet filter to its default state
>>   • clear all multicast address filters
>>   • clear all power filters set using
>> SetEthernetPowerManagementPatternFilter
>>   • reset statistics counters to zero
>>   • restore its Ethernet address to its default state
>>   • reset its IN NTB size to the value given by field dwNtbInMaxSize
>> from the NTB Parameter Struc- ture
>>   • reset the NTB format to NTB-16
>>   • reset the current Maximum Datagram Size to a function-specific
>> default. If SetMaxDatagramSize is not supported, then the maximum
>> datagram size shall be the same as the value in wMaxSegmentSize of
>> the Ethernet Networking Functional Descriptor. If SetMaxDatagramSize
>> is supported by the function, then the host must either query the
>> function to determine the current effective maximum datagram size,
>> or must explicitly set the maximum datagram size. If the host wishes
>> to set the Maximum Datagram Size, it may do so prior to selecting
>> the second alternate interface set- ting of the data
>> interface. Doing so will ensure that the change takes effect prior
>> to send or receiving data.
>>   • reset CRC mode so that the function will not append CRCs to
>> datagrams sent on the IN pipe
>>   • reset NTB sequence numbers to zero
>>
>>   When the host selects the second alternate interface setting of the
>>   NCM Data Interface, the function shall perform the following actions
>>   in the following order.
>>   • If connected to the network, the function shall send a
>> ConnectionSpeedChange notification to the host indicating the
>> current connection speed.
>>   • Whether connected or not, the function shall then send a
>> NetworkConnection notification to the host, with wValue indicating
>> the current state of network connectivity
>> "
>>
>> The addition of the "RESET" request in MBIM did not change these
>> requirements AFAICS.  Supporting NCM style "altsetting 0 reset" is
>> required by default inheritance.  The description of dual NCM/MBIM
>> functions in the MBIM spec further emphasizes this:
>>
>> "
>>   Regardless of the previous sequence of SET_INTERFACE commands targeting
>>   the Communication Interface, the host is able to put the function into
>>   a defined state by the following sequence:
>>
>>   1. SET_INTERFACE(Data Interface, 0)
>>   2. SET_INTERFACE(Communication Interface, desired alternate setting)
>>   3. Sending the required class commands for the targeted alternate
>> setting
>>   4. SET_INTERFACE(Data Interface, 1 if Communication Interface,0 and
>> Data Interface,2 Communication Interface 1)
>> "
>>
>>
>> This, along with the lack of *any* sort of discussion of the
>> relation/interf

Re: [PATCH 1/1] NET: usb: cdc_ncm: adding MBIM RESET_FUNCTION request and modifying ncm bind common code

[Daniele Palmas]

Hi,

2016-12-05 11:10 GMT+01:00 Bjørn Mork <bj...@mork.no>:
> Daniele Palmas <dnl...@gmail.com> writes:
>
>> I went back to this and further checking revealed that MBIM function
>> reset is not needed and the only problem is related to commit
>> 48906f62c96cc2cd35753e59310cb70eb08cc6a5 cdc_ncm: toggle altsetting to
>> force reset before setup, that, however, is mandatory for some Huawei
>> modems.
>
> Interesting.  That does sound like an odd firmware bug to me. I have a
> bit of a hard time understanding how this can be.  Using data interface
> altsetting 0 to reset the function is documented in the NCM spec:
>

Agree, this is likely a firmware bug and it is also proved by all the
other modems that accept the procedure without issues.

> "
>   7.2 Using Alternate Settings to Reset an NCM Function
>
>   To place the network aspects of a function in a known state, the host
>   shall:
>   • select alternate setting 0 of the NCM Data Interface (this is the
> setting with no endpoints). This can be done explicitly using
> SetInterface, or implicitly using SetConfiguration. See [USB30] for
> details.
>   • select the NCM operational parameters by sending commands to the NCM
> Communication Interface, then
>   • select the second alternate interface setting of the NCM Data
> Interface (this is the setting with a bulk IN endpoint and a bulk
> OUT endpoint).
>
>   Whenever alternate setting 0 is selected by the host, the function
>   shall:
>   • flush function buffers
>   • reset the packet filter to its default state
>   • clear all multicast address filters
>   • clear all power filters set using
> SetEthernetPowerManagementPatternFilter
>   • reset statistics counters to zero
>   • restore its Ethernet address to its default state
>   • reset its IN NTB size to the value given by field dwNtbInMaxSize
> from the NTB Parameter Struc- ture
>   • reset the NTB format to NTB-16
>   • reset the current Maximum Datagram Size to a function-specific
> default. If SetMaxDatagramSize is not supported, then the maximum
> datagram size shall be the same as the value in wMaxSegmentSize of
> the Ethernet Networking Functional Descriptor. If SetMaxDatagramSize
> is supported by the function, then the host must either query the
> function to determine the current effective maximum datagram size,
> or must explicitly set the maximum datagram size. If the host wishes
> to set the Maximum Datagram Size, it may do so prior to selecting
> the second alternate interface set- ting of the data
> interface. Doing so will ensure that the change takes effect prior
> to send or receiving data.
>   • reset CRC mode so that the function will not append CRCs to
> datagrams sent on the IN pipe
>   • reset NTB sequence numbers to zero
>
>   When the host selects the second alternate interface setting of the
>   NCM Data Interface, the function shall perform the following actions
>   in the following order.
>   • If connected to the network, the function shall send a
> ConnectionSpeedChange notification to the host indicating the
> current connection speed.
>   • Whether connected or not, the function shall then send a
> NetworkConnection notification to the host, with wValue indicating
> the current state of network connectivity
> "
>
> The addition of the "RESET" request in MBIM did not change these
> requirements AFAICS.  Supporting NCM style "altsetting 0 reset" is
> required by default inheritance.  The description of dual NCM/MBIM
> functions in the MBIM spec further emphasizes this:
>
> "
>   Regardless of the previous sequence of SET_INTERFACE commands targeting
>   the Communication Interface, the host is able to put the function into
>   a defined state by the following sequence:
>
>   1. SET_INTERFACE(Data Interface, 0)
>   2. SET_INTERFACE(Communication Interface, desired alternate setting)
>   3. Sending the required class commands for the targeted alternate
> setting
>   4. SET_INTERFACE(Data Interface, 1 if Communication Interface,0 and
> Data Interface,2 Communication Interface 1)
> "
>
>
> This, along with the lack of *any* sort of discussion of the
> relation/interfaction between "MBIM RESET" and "data interface
> altsetting 0" makes the MBIM RESET control request either ambigious or
> redundant.  Or both...
>
> FWIW, I've always considered RESET a symptom of the sloppy MBIM spec
> development.  It did not exactly work to their advantage that the first
> (and only?) published errata simply was an excuse to add new features
> (the "MBIM extended functional desc

Re: [PATCH 1/1] NET: usb: cdc_ncm: adding MBIM RESET_FUNCTION request and modifying ncm bind common code

[Daniele Palmas]

Hi,

2016-11-28 12:23 GMT+01:00 Daniele Palmas <dnl...@gmail.com>:
> 2016-11-26 22:17 GMT+01:00 Bjørn Mork <bj...@mork.no>:
>> Bjørn Mork <bj...@mork.no> writes:
>>
>>> Finally, I found my modems (or at least a number of them) again today.
>>> But I'm sorry to say, that the troublesome Huawei E3372h-153 is still
>>> giving us a hard time.  It does not work with your patch. The symptom is
>>> the same as earlier:  The modem returns MBIM frames with 32bit headers.
>>>
>>> So for now, I have to NAK this patch.
>>>
>>> I am sure we can find a good solution that makes all of these modems
>>> work, but I cannot support a patch that breaks previously working
>>> configurations. Sorry.  I'll do a few experiments and see if there is a
>>> simple fix for this.  Otherwise we'll probably have to do the quirk
>>> game.
>>
>>
>> This is a proof-of-concept only, but it appears to be working.  Please
>> test with your device(s) too.  It's still mostly your code, as you can
>> see.
>
> Sorry, this does not work :-(
>
> The problem is always in the altsetting toggle: if I comment that
> part, your patch is working fine.
>
> I'm now wondering if the safest thing is to add a very simple quirk in
> cdc_mbim that makes this toggle not to be applied with the buggy
> modems and then unconditionally add the RESET_FUNCTION request in
> cdc_mbim_bind after cdc_ncm_bind_common has been executed.
>

I went back to this and further checking revealed that MBIM function
reset is not needed and the only problem is related to commit
48906f62c96cc2cd35753e59310cb70eb08cc6a5 cdc_ncm: toggle altsetting to
force reset before setup, that, however, is mandatory for some Huawei
modems.

My proposal is to add something like
CDC_MBIM_FLAG_AVOID_ALTSETTING_TOGGLE quirk to avoid the toggle.

To have a conservative approach, I would add only Telit LE922 to this
quirk and keep also the usleep_range delay, since I do not have a
clear view on all the VIDs/PIDs affected by this quirk. Then other
modems, once tested, can be added to the quirk if the delay is not
enough.

If this approach, though ugly, has chances to be accepted I can write
a new patch.

Thanks,
Daniele

> Daniele
>
>>
>> If this turns out to work, then I believe we should refactor
>> cdc_ncm_init() and cdc_ncm_bind_common() to make the whole
>> initialisation sequence a bit cleaner.  And maybe also include
>> cdc_mbim_bind().  Ideally, the MBIM specific RESET should happen there
>> instead of "polluting" the NCM driver with MBIM specific code.
>>
>> But anyway:  The sequence that seems to work for both the  E3372h-153
>> and the EM7455 is
>>
>>  USB_CDC_GET_NTB_PARAMETERS
>>  USB_CDC_RESET_FUNCTION
>>  usb_set_interface(dev->udev, 'data interface no', 0);
>>  remaining parts of cdc_ncm_init(), excluding USB_CDC_GET_NTB_PARAMETERS
>>  usb_set_interface(dev->udev, 'data interface no', 'data alt setting');
>>
>> without any additional delay between the two usb_set_interface() calls.
>> So the major difference from your patch is that I moved the two control
>> requests out of cdc_ncm_init() to allow running them _before_ setting
>> the data interface to altsetting 0.
>>
>> But maybe I was just lucky.  This was barely proof tested.  Needs a lot
>> more testing and cleanups as suggested.  I'd appreciate it if you
>> continued that, as I don't really have any time for it...
>>
>> FWIW, I also ran a quick test with a D-Link DWM-156A7 (Mediatek MBIM
>> firmware) and a Huawei E367 (Qualcomm device with early Huawei MBIM
>> firmware, distinctly different from the E3372h-153 and most other
>> MBIM devices I've seen)
>>
>>
>>
>> Bjørn
>>
>> ---
>>  drivers/net/usb/cdc_ncm.c| 48 
>> 
>>  include/uapi/linux/usb/cdc.h |  1 +
>>  2 files changed, 32 insertions(+), 17 deletions(-)
>>
>> diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
>> index 877c9516e781..be019cbf1719 100644
>> --- a/drivers/net/usb/cdc_ncm.c
>> +++ b/drivers/net/usb/cdc_ncm.c
>> @@ -488,16 +488,6 @@ static int cdc_ncm_init(struct usbnet *dev)
>> u8 iface_no = ctx->control->cur_altsetting->desc.bInterfaceNumber;
>> int err;
>>
>> -   err = usbnet_read_cmd(dev, USB_CDC_GET_NTB_PARAMETERS,
>> - USB_TYPE_CLASS | USB_DIR_IN
>> - |USB_RECIP_INTERFACE,
>> - 0, iface_no, >ncm_parm,
>> - sizeof(ct

[PATCH 0/1] USB: serial: option: add support for Telit LE922A PIDs 0x1040, 0x1041

[Daniele Palmas]

  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x000a  1x 10 bytes
bInterval   9
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x87  EP 7 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x05  EP 5 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber6
  bAlternateSetting   0
  bNumEndpoints   3
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass  0 
  bInterfaceProtocol  0 
  iInterface  0 
  ** UNRECOGNIZED:  05 24 00 10 01
  ** UNRECOGNIZED:  05 24 01 00 00
  ** UNRECOGNIZED:  04 24 02 02
  ** UNRECOGNIZED:  05 24 06 00 00
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x8a  EP 10 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x000a  1x 10 bytes
bInterval   9
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x89  EP 9 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x06  EP 6 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber7
  bAlternateSetting   0
  bNumEndpoints   3
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass  0 
  bInterfaceProtocol  0 
  iInterface  0 
  ** UNRECOGNIZED:  05 24 00 10 01
  ** UNRECOGNIZED:  05 24 01 00 00
  ** UNRECOGNIZED:  04 24 02 02
  ** UNRECOGNIZED:  05 24 06 00 00
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x8c  EP 12 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x000a  1x 10 bytes
bInterval   9
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x8b  EP 11 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x07  EP 7 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
Device Qualifier (for other device speed):
  bLength10
  bDescriptorType 6
  bcdUSB   2.00
  bDeviceClass  239 Miscellaneous Device
  bDeviceSubClass 2 ?
  bDeviceProtocol 1 Interface Association
  bMaxPacketSize064
  bNumConfigurations  1
Device Status: 0x
  (Bus Powered)

Daniele Palmas (1):
  USB: serial: option: add support for Telit LE922A PIDs 0x1040, 0x1041

 drivers/usb/serial/option.c | 6 ++
 1 file changed, 6 insertions(+)

-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/1] USB: serial: option: add support for Telit LE922A PIDs 0x1040, 0x1041

[Daniele Palmas]

This patch adds support for PIDs 0x1040, 0x1041 of Telit LE922A.

Since the interface positions are the same than the ones used
for other Telit compositions, previous defined blacklists are used.

Signed-off-by: Daniele Palmas <dnl...@gmail.com>
---
 drivers/usb/serial/option.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 9894e34..33ae203 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -268,6 +268,8 @@ static void option_instat_callback(struct urb *urb);
 #define TELIT_PRODUCT_CC864_SINGLE 0x1006
 #define TELIT_PRODUCT_DE910_DUAL   0x1010
 #define TELIT_PRODUCT_UE910_V2 0x1012
+#define TELIT_PRODUCT_LE922_USBCFG10x1040
+#define TELIT_PRODUCT_LE922_USBCFG20x1041
 #define TELIT_PRODUCT_LE922_USBCFG00x1042
 #define TELIT_PRODUCT_LE922_USBCFG30x1043
 #define TELIT_PRODUCT_LE922_USBCFG50x1045
@@ -1210,6 +1212,10 @@ static const struct usb_device_id option_ids[] = {
{ USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_UE910_V2) },
{ USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_LE922_USBCFG0),
.driver_info = (kernel_ulong_t)_le922_blacklist_usbcfg0 },
+   { USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_LE922_USBCFG1),
+   .driver_info = (kernel_ulong_t)_le910_blacklist },
+   { USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_LE922_USBCFG2),
+   .driver_info = (kernel_ulong_t)_le922_blacklist_usbcfg3 },
{ USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_LE922_USBCFG3),
.driver_info = (kernel_ulong_t)_le922_blacklist_usbcfg3 },
{ USB_DEVICE_INTERFACE_CLASS(TELIT_VENDOR_ID, 
TELIT_PRODUCT_LE922_USBCFG5, 0xff),
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/1] NET: usb: cdc_ncm: adding MBIM RESET_FUNCTION request and modifying ncm bind common code

[Daniele Palmas]

2016-11-26 22:17 GMT+01:00 Bjørn Mork :
> Bjørn Mork  writes:
>
>> Finally, I found my modems (or at least a number of them) again today.
>> But I'm sorry to say, that the troublesome Huawei E3372h-153 is still
>> giving us a hard time.  It does not work with your patch. The symptom is
>> the same as earlier:  The modem returns MBIM frames with 32bit headers.
>>
>> So for now, I have to NAK this patch.
>>
>> I am sure we can find a good solution that makes all of these modems
>> work, but I cannot support a patch that breaks previously working
>> configurations. Sorry.  I'll do a few experiments and see if there is a
>> simple fix for this.  Otherwise we'll probably have to do the quirk
>> game.
>
>
> This is a proof-of-concept only, but it appears to be working.  Please
> test with your device(s) too.  It's still mostly your code, as you can
> see.

Sorry, this does not work :-(

The problem is always in the altsetting toggle: if I comment that
part, your patch is working fine.

I'm now wondering if the safest thing is to add a very simple quirk in
cdc_mbim that makes this toggle not to be applied with the buggy
modems and then unconditionally add the RESET_FUNCTION request in
cdc_mbim_bind after cdc_ncm_bind_common has been executed.

Daniele

>
> If this turns out to work, then I believe we should refactor
> cdc_ncm_init() and cdc_ncm_bind_common() to make the whole
> initialisation sequence a bit cleaner.  And maybe also include
> cdc_mbim_bind().  Ideally, the MBIM specific RESET should happen there
> instead of "polluting" the NCM driver with MBIM specific code.
>
> But anyway:  The sequence that seems to work for both the  E3372h-153
> and the EM7455 is
>
>  USB_CDC_GET_NTB_PARAMETERS
>  USB_CDC_RESET_FUNCTION
>  usb_set_interface(dev->udev, 'data interface no', 0);
>  remaining parts of cdc_ncm_init(), excluding USB_CDC_GET_NTB_PARAMETERS
>  usb_set_interface(dev->udev, 'data interface no', 'data alt setting');
>
> without any additional delay between the two usb_set_interface() calls.
> So the major difference from your patch is that I moved the two control
> requests out of cdc_ncm_init() to allow running them _before_ setting
> the data interface to altsetting 0.
>
> But maybe I was just lucky.  This was barely proof tested.  Needs a lot
> more testing and cleanups as suggested.  I'd appreciate it if you
> continued that, as I don't really have any time for it...
>
> FWIW, I also ran a quick test with a D-Link DWM-156A7 (Mediatek MBIM
> firmware) and a Huawei E367 (Qualcomm device with early Huawei MBIM
> firmware, distinctly different from the E3372h-153 and most other
> MBIM devices I've seen)
>
>
>
> Bjørn
>
> ---
>  drivers/net/usb/cdc_ncm.c| 48 
> 
>  include/uapi/linux/usb/cdc.h |  1 +
>  2 files changed, 32 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
> index 877c9516e781..be019cbf1719 100644
> --- a/drivers/net/usb/cdc_ncm.c
> +++ b/drivers/net/usb/cdc_ncm.c
> @@ -488,16 +488,6 @@ static int cdc_ncm_init(struct usbnet *dev)
> u8 iface_no = ctx->control->cur_altsetting->desc.bInterfaceNumber;
> int err;
>
> -   err = usbnet_read_cmd(dev, USB_CDC_GET_NTB_PARAMETERS,
> - USB_TYPE_CLASS | USB_DIR_IN
> - |USB_RECIP_INTERFACE,
> - 0, iface_no, >ncm_parm,
> - sizeof(ctx->ncm_parm));
> -   if (err < 0) {
> -   dev_err(>intf->dev, "failed GET_NTB_PARAMETERS\n");
> -   return err; /* GET_NTB_PARAMETERS is required */
> -   }
> -
> /* set CRC Mode */
> if (cdc_ncm_flags(dev) & USB_CDC_NCM_NCAP_CRC_MODE) {
> dev_dbg(>intf->dev, "Setting CRC mode off\n");
> @@ -837,12 +827,43 @@ int cdc_ncm_bind_common(struct usbnet *dev, struct 
> usb_interface *intf, u8 data_
> }
> }
>
> +   iface_no = ctx->control->cur_altsetting->desc.bInterfaceNumber;
> +   temp = usbnet_read_cmd(dev, USB_CDC_GET_NTB_PARAMETERS,
> +  USB_TYPE_CLASS | USB_DIR_IN
> +  | USB_RECIP_INTERFACE,
> +  0, iface_no, >ncm_parm,
> +  sizeof(ctx->ncm_parm));
> +   if (temp < 0) {
> +   dev_err(>intf->dev, "failed GET_NTB_PARAMETERS\n");
> +   goto error; /* GET_NTB_PARAMETERS is required */
> +   }
> +
> +   /* Some modems (e.g. Telit LE922A6) need to reset the MBIM function
> +* or they will fail to work properly.
> +* For details on RESET_FUNCTION request see document
> +* "USB Communication Class Subclass Specification for MBIM"
> +* RESET_FUNCTION should be harmless for all the other MBIM modems
> +*/
> +   if (cdc_ncm_comm_intf_is_mbim(ctx->control->cur_altsetting)) {
> +   temp 

Re: Issue with Telit LE922 and cdc_mbim

[Daniele Palmas]

2016-11-23 19:38 GMT+01:00 Bjørn Mork <bj...@mork.no>:
> Daniele Palmas <dnl...@gmail.com> writes:
>> 2016-11-23 15:49 GMT+01:00 Bjørn Mork <bj...@mork.no>:
>>> Daniele Palmas <dnl...@gmail.com> writes:
>>>> 2016-11-21 10:49 GMT+01:00 Bjørn Mork <bj...@mork.no>:
>>>>> Daniele Palmas <dnl...@gmail.com> writes:
>>>>>
>>>>>> it turned out that resetting the interface in cdc_ncm_init after
>>>>>> getting the NTB parameters removes the need for the sleep, making the
>>>>>> modem to work fine.
>>>>>
>>>>> Sounds very good, although I must admit that it isn't perfectly clear to
>>>>> me what kind of reset we're talking about here.  But no worries, the
>>>>> patch will make that clear :)
>>>>>
>>>>
>>>> Sorry for the confusion, I meant resetting the MBIM function with
>>>> RESET_FUNCTION request code.
>>>
>>> Yes, the patch did make that clear, as expected :)
>>>
>>>>>> I wonder if this is an acceptable solution and can be applied also for 
>>>>>> MC7455.
>>>>>
>>>>> Quite possible.  I will definitely test it.  If we can avoid an
>>>>> arbitrary and pointless delay, then that's great.  But I guess this also
>>>>> requires testing with a wide range of other MBIM devices to find out if
>>>>> we can apply it unconditionally without breaking anything. Avoiding
>>>>> device-specific or vendor-specific code is important in a class driver,
>>>>> if possible.
>>>>>
>>>>
>>>> Ok, unfortunately I can test only with Telit modems, so I'm not sure
>>>> if the change I did is harmless for all the other modems:
>>>> RESET_FUNCTION should not cause issues,
>>>
>>> Agreed.  Unfortunately, we cannot depend on sane firmware behaviour ;)
>>>
>>> I did a semi-quick test on a Sierra Wireless EM7455 and can confirm that
>>> your patch makes it work without the delay.  Very nice.
>>>
>>
>> Cool!
>>
>>> Do you happen to know if the Windows MBIM driver use  RESET_FUNCTION
>>> during initialisation?  That would make this feel much safer.
>>>
>>
>> Yes, Windows driver seems to send RESET_FUNCTION two times: after
>> getting NTB parameters and after setting NTB input size. But it seems
>> that only the first one is mandatory.
>>
>> Windows USB traces taken with TotalPhase Datacenter are available at
>>
>> https://drive.google.com/drive/folders/0B1kPnH2g8ISIZWJiV05qeWN5dVE
>>
>> file LE922win10_2.tdc
>
> This is comforting. It means that the risk introducing the
> RESET_FUNCTION call is close to zero.  The only remaining issue is
> whether we can safely remove the altsetting toggle.
>
>>> I see that your testing also included Intel based modems. That's good.
>>> It would still be nice to have test results from a few more MBIM
>>> implementations, in particular the more "difficult" ones. But I don't
>>
>> I agree, especially Huawei ones for which the alternate setting
>> toggling was introduced.
>
> I'll see what I can do about that. Looks like I have to dig through my
> mailbox.  It seems I didn't add any Reported-by tags on the relevant
> commits.  Wonder why...  Well, there you have the reason why you always
> should.  Now I got to do the work instead of just loading it on you :)
>
>>> know how much help I can promise here. At the moment I don't even know
>>> which box my modems are in.  Moved a month ago and am still living in a
>>> box.  Or more like a hundred boxes ;)
>>>
>>> The easiest way to get this thoroughly tested is of course to push it
>>> now, and try to respond quickly in case it breaks something. Don't know
>>> what others think about that?
>>>
>>>> but I also removed altsetting
>>>> toggling for all MBIM modems and maybe this is not acceptable.
>>>
>>> I wonder about that.  It was added specifically for modems which seemed
>>> to need it.  Don't remember if we ever tried RESET_FUNCTION as an
>>> alternative. Removing workaorunds which have proven to be necessary at
>>> some point in time is a bit risky.
>>>
>>
>> I totally agree, but the other way would be to add another quirk at
>> the cdc_mbim driver level, isn't it?
>
> Yes, so I'm definitely with you here - let's try without the quirk
> first.  I'm ready to say "commit it", if noone else objects.
>
>> If this is a preferred solution I can try to modify the patch
>> according to this path.
>
> No, the patch is fine as is.  Just one question: If keeping the
> altsetting toggle proves necessary, will that break the Qualcomm
> devices?  Yes, I could test that myself, but I'm lazy and I guess you
> already have tested it?

Unfortunately, yes: for Telit LE922A6 altsetting toggle seems to be
part of the problem.

Regards,
Daniele

>
>
> Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Issue with Telit LE922 and cdc_mbim

[Daniele Palmas]

Re-adding the list, sorry.

2016-11-23 15:49 GMT+01:00 Bjørn Mork <bj...@mork.no>:
> Daniele Palmas <dnl...@gmail.com> writes:
>> 2016-11-21 10:49 GMT+01:00 Bjørn Mork <bj...@mork.no>:
>>> Daniele Palmas <dnl...@gmail.com> writes:
>>>
>>>> it turned out that resetting the interface in cdc_ncm_init after
>>>> getting the NTB parameters removes the need for the sleep, making the
>>>> modem to work fine.
>>>
>>> Sounds very good, although I must admit that it isn't perfectly clear to
>>> me what kind of reset we're talking about here.  But no worries, the
>>> patch will make that clear :)
>>>
>>
>> Sorry for the confusion, I meant resetting the MBIM function with
>> RESET_FUNCTION request code.
>
> Yes, the patch did make that clear, as expected :)
>
>>>> I wonder if this is an acceptable solution and can be applied also for 
>>>> MC7455.
>>>
>>> Quite possible.  I will definitely test it.  If we can avoid an
>>> arbitrary and pointless delay, then that's great.  But I guess this also
>>> requires testing with a wide range of other MBIM devices to find out if
>>> we can apply it unconditionally without breaking anything. Avoiding
>>> device-specific or vendor-specific code is important in a class driver,
>>> if possible.
>>>
>>
>> Ok, unfortunately I can test only with Telit modems, so I'm not sure
>> if the change I did is harmless for all the other modems:
>> RESET_FUNCTION should not cause issues,
>
> Agreed.  Unfortunately, we cannot depend on sane firmware behaviour ;)
>
> I did a semi-quick test on a Sierra Wireless EM7455 and can confirm that
> your patch makes it work without the delay.  Very nice.
>

Cool!

> Do you happen to know if the Windows MBIM driver use  RESET_FUNCTION
> during initialisation?  That would make this feel much safer.
>

Yes, Windows driver seems to send RESET_FUNCTION two times: after
getting NTB parameters and after setting NTB input size. But it seems
that only the first one is mandatory.

Windows USB traces taken with TotalPhase Datacenter are available at

https://drive.google.com/drive/folders/0B1kPnH2g8ISIZWJiV05qeWN5dVE

file LE922win10_2.tdc

> I see that your testing also included Intel based modems. That's good.
> It would still be nice to have test results from a few more MBIM
> implementations, in particular the more "difficult" ones. But I don't

I agree, especially Huawei ones for which the alternate setting
toggling was introduced.

> know how much help I can promise here. At the moment I don't even know
> which box my modems are in.  Moved a month ago and am still living in a
> box.  Or more like a hundred boxes ;)
>
> The easiest way to get this thoroughly tested is of course to push it
> now, and try to respond quickly in case it breaks something. Don't know
> what others think about that?
>
>> but I also removed altsetting
>> toggling for all MBIM modems and maybe this is not acceptable.
>
> I wonder about that.  It was added specifically for modems which seemed
> to need it.  Don't remember if we ever tried RESET_FUNCTION as an
> alternative. Removing workaorunds which have proven to be necessary at
> some point in time is a bit risky.
>

I totally agree, but the other way would be to add another quirk at
the cdc_mbim driver level, isn't it?

If this is a preferred solution I can try to modify the patch
according to this path.

Thanks,
Daniele

>
> Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Issue with Telit LE922 and cdc_mbim

[Daniele Palmas]

Hi Bjørn,

2016-11-21 10:49 GMT+01:00 Bjørn Mork <bj...@mork.no>:
> Daniele Palmas <dnl...@gmail.com> writes:
>
>> it turned out that resetting the interface in cdc_ncm_init after
>> getting the NTB parameters removes the need for the sleep, making the
>> modem to work fine.
>
> Sounds very good, although I must admit that it isn't perfectly clear to
> me what kind of reset we're talking about here.  But no worries, the
> patch will make that clear :)
>

Sorry for the confusion, I meant resetting the MBIM function with
RESET_FUNCTION request code.

>> I wonder if this is an acceptable solution and can be applied also for 
>> MC7455.
>
> Quite possible.  I will definitely test it.  If we can avoid an
> arbitrary and pointless delay, then that's great.  But I guess this also
> requires testing with a wide range of other MBIM devices to find out if
> we can apply it unconditionally without breaking anything. Avoiding
> device-specific or vendor-specific code is important in a class driver,
> if possible.
>

Ok, unfortunately I can test only with Telit modems, so I'm not sure
if the change I did is harmless for all the other modems:
RESET_FUNCTION should not cause issues, but I also removed altsetting
toggling for all MBIM modems and maybe this is not acceptable.

Thanks,
Daniele

>
> Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/1] NET: usb: cdc_ncm: adding MBIM RESET_FUNCTION request and modifying ncm bind common code

[Daniele Palmas]

Some latest QC based modems seem not to properly accept altsetting
toggling in cdc_ncm_bind_common, making them to fail. The workaround
was to introduce an empirically decided pause to avoid the failure.

This patch introduces a different approach: for MBIM devices, instead
of toggling interfaces, the MBIM class-specific request code
RESET_FUNCTION is used in order to reset the function to its initial
state, removing the need for the pause.

Signed-off-by: Daniele Palmas <dnl...@gmail.com>
---
 drivers/net/usb/cdc_ncm.c| 39 +++
 include/uapi/linux/usb/cdc.h |  1 +
 2 files changed, 28 insertions(+), 12 deletions(-)

diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index 877c951..e8a7a76 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -498,6 +498,22 @@ static int cdc_ncm_init(struct usbnet *dev)
return err; /* GET_NTB_PARAMETERS is required */
}
 
+   /* Some modems (e.g. Telit LE922A6) need to reset the MBIM function
+* or they will fail to work properly.
+* For details on RESET_FUNCTION request see document
+* "USB Communication Class Subclass Specification for MBIM"
+* RESET_FUNCTION should be harmless for all the other MBIM modems
+*/
+   if (cdc_ncm_comm_intf_is_mbim(ctx->control->cur_altsetting)) {
+   err = usbnet_write_cmd(dev, USB_CDC_RESET_FUNCTION,
+  USB_TYPE_CLASS | USB_DIR_OUT
+  | USB_RECIP_INTERFACE,
+  0, iface_no, NULL, 0);
+   if (err < 0) {
+   dev_err(>intf->dev, "failed RESET_FUNCTION\n");
+   }
+   }
+
/* set CRC Mode */
if (cdc_ncm_flags(dev) & USB_CDC_NCM_NCAP_CRC_MODE) {
dev_dbg(>intf->dev, "Setting CRC mode off\n");
@@ -842,25 +858,24 @@ int cdc_ncm_bind_common(struct usbnet *dev, struct 
usb_interface *intf, u8 data_
/* Reset data interface. Some devices will not reset properly
 * unless they are configured first.  Toggle the altsetting to
 * force a reset
+* This is applied only to ncm devices, since it has been verified
+* to cause issues with some MBIM modems (e.g. Telit LE922A6).
+* MBIM devices reset is achieved using MBIM request RESET_FUNCTION
+* in cdc_ncm_init
 */
-   usb_set_interface(dev->udev, iface_no, data_altsetting);
-   temp = usb_set_interface(dev->udev, iface_no, 0);
-   if (temp) {
-   dev_dbg(>dev, "set interface failed\n");
-   goto error2;
+   if (!cdc_ncm_comm_intf_is_mbim(intf->cur_altsetting)) {
+   usb_set_interface(dev->udev, iface_no, data_altsetting);
+   temp = usb_set_interface(dev->udev, iface_no, 0);
+   if (temp) {
+   dev_dbg(>dev, "set interface failed\n");
+   goto error2;
+   }
}
 
/* initialize basic device settings */
if (cdc_ncm_init(dev))
goto error2;
 
-   /* Some firmwares need a pause here or they will silently fail
-* to set up the interface properly.  This value was decided
-* empirically on a Sierra Wireless MC7455 running 02.08.02.00
-* firmware.
-*/
-   usleep_range(1, 2);
-
/* configure data interface */
temp = usb_set_interface(dev->udev, iface_no, data_altsetting);
if (temp) {
diff --git a/include/uapi/linux/usb/cdc.h b/include/uapi/linux/usb/cdc.h
index e2bc417..30258fb 100644
--- a/include/uapi/linux/usb/cdc.h
+++ b/include/uapi/linux/usb/cdc.h
@@ -231,6 +231,7 @@ struct usb_cdc_mbim_extended_desc {
 
 #define USB_CDC_SEND_ENCAPSULATED_COMMAND  0x00
 #define USB_CDC_GET_ENCAPSULATED_RESPONSE  0x01
+#define USB_CDC_RESET_FUNCTION 0x05
 #define USB_CDC_REQ_SET_LINE_CODING0x20
 #define USB_CDC_REQ_GET_LINE_CODING0x21
 #define USB_CDC_REQ_SET_CONTROL_LINE_STATE 0x22
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/1] NET: usb: cdc_ncm: adding MBIM RESET_FUNCTION request and modifying ncm bind common code

[Daniele Palmas]

Some latest QC based modems seem not to properly accept altsetting
toggling in cdc_ncm_bind_common, making them to fail. The workaround
was to introduce an empirically decided pause to avoid the failure.

This patch introduces a different approach: for MBIM devices, instead
of toggling interfaces, the MBIM class-specific request code
RESET_FUNCTION is used in order to reset the function to its initial
state, removing the need for the pause.

Patch has been tested with a few Telit QC and Intel based MBIM modems.

Patch has also been tested with an Intel NCM based device, for
regression checking.

Daniele Palmas (1):
  NET: usb: cdc_ncm: adding MBIM RESET_FUNCTION request and modifying
ncm bind common code

 drivers/net/usb/cdc_ncm.c| 39 +++
 include/uapi/linux/usb/cdc.h |  1 +
 2 files changed, 28 insertions(+), 12 deletions(-)

-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Issue with Telit LE922 and cdc_mbim

[Daniele Palmas]

Hi Bjørn,

2016-11-16 9:50 GMT+01:00 Daniele Palmas <dnl...@gmail.com>:
> Hi Bjørn,
>
> 2016-11-15 19:56 GMT+01:00 Bjørn Mork <bj...@mork.no>:
>> Daniele Palmas <dnl...@gmail.com> writes:
>>
>>> The problem is in cdc_ncm, function cdc_ncm_bind_common, line
>>>
>>> usleep_range(1, 2);
>>>
>>> It seems that LE922 needs an higher timeout; changing the line to
>>>
>>> usleep_range(7, 8);
>>>
>>> makes the modem to work fine.
>>
>> Extremely interesting!  As you probably noticed, that delay was recently
>> added as a workaround for the same problem on Sierra Wireless EM7455
>> modems.  I believe these are based on the Qualcomm MDM9230.  Which
>> chipset is the LE922 based on?  Is it also one of the newer Qualcom
>> chips?
>
> Yes, it is based on one of latest QC chipsets.
>
>>
>>
>>> I will submit a patch for this.
>>
>> Thanks. It would also be great if you could trigger some investigation
>> into the actual firmware issue.  It looks like the firmware returns
>> control to the driver before it's actually ready at this point of
>> initialisation.
>>
>
> Yeah, for sure I will ask for some investigation also on the firmware
> side, even though I don't have many expectations for this.
>
> It seems that, if the modem is attached to the host and then turned
> on, the previous delay is not enough. And then there seems also to be
> constraints on the application side (e.g. ModemManager).
>
> Currently I'm not going to submit a patch until things are more clear.

it turned out that resetting the interface in cdc_ncm_init after
getting the NTB parameters removes the need for the sleep, making the
modem to work fine.

I wonder if this is an acceptable solution and can be applied also for MC7455.

Regards,
Daniele

>
> Thanks for your help,
> Daniele
>
>>
>>
>>
>> Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Issue with Telit LE922 and cdc_mbim

[Daniele Palmas]

Hi Bjørn,

2016-11-15 19:56 GMT+01:00 Bjørn Mork <bj...@mork.no>:
> Daniele Palmas <dnl...@gmail.com> writes:
>
>> The problem is in cdc_ncm, function cdc_ncm_bind_common, line
>>
>> usleep_range(1, 2);
>>
>> It seems that LE922 needs an higher timeout; changing the line to
>>
>> usleep_range(7, 8);
>>
>> makes the modem to work fine.
>
> Extremely interesting!  As you probably noticed, that delay was recently
> added as a workaround for the same problem on Sierra Wireless EM7455
> modems.  I believe these are based on the Qualcomm MDM9230.  Which
> chipset is the LE922 based on?  Is it also one of the newer Qualcom
> chips?

Yes, it is based on one of latest QC chipsets.

>
>
>> I will submit a patch for this.
>
> Thanks. It would also be great if you could trigger some investigation
> into the actual firmware issue.  It looks like the firmware returns
> control to the driver before it's actually ready at this point of
> initialisation.
>

Yeah, for sure I will ask for some investigation also on the firmware
side, even though I don't have many expectations for this.

It seems that, if the modem is attached to the host and then turned
on, the previous delay is not enough. And then there seems also to be
constraints on the application side (e.g. ModemManager).

Currently I'm not going to submit a patch until things are more clear.

Thanks for your help,
Daniele

>
>
>
> Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Issue with Telit LE922 and cdc_mbim

[Daniele Palmas]

Hi,

2016-11-14 14:51 GMT+01:00 Daniele Palmas <dnl...@gmail.com>:
> Hi,
>
> I'm struggling with Telit LE922 modem that presents an MBIM device.
> The modem works fine in Windows, while in Linux (tested with 4.9 rc1)
> data connection is not functional: using ifconfig I can see
>
> wwp0s20u8i2 Link encap:Ethernet  HWaddr e6:c0:3b:97:80:de
>   inet addr:176.246.94.9  Bcast:176.246.94.11  Mask:255.255.255.252
>   UP BROADCAST RUNNING NOARP MULTICAST  MTU:1500  Metric:1
>   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:1 errors:15 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000
>   RX bytes:0 (0.0 B)  TX bytes:40 (40.0 B)
>
> so the issue seems to be in tx.
>
> I'm using an USB hw sniffer for trying to understand the problem; this
> is an example of a NCM packet with Windows 10 driver:
>
> 4E 43 4D 48 0C 00 0B 02 48 00 38 00 45 00 00 28
> 78 E8 40 00 80 06 63 68 05 5C 7A E5 D8 3A C6 03
> E9 08 01 BB FB 36 F0 EA C6 8C D8 CB 50 10 80 00
> 9B 16 00 00 00 00 00 00 49 50 53 00 10 00 00 00
> 0C 00 28 00 00 00 00 00
>
> 16 bit NTB, with NDP at the end. So I enabled CDC_NCM_FLAG_NDP_TO_END,
> but still the device is not properly working.
>
> This is the first properly transmitted acked packet in Linux:
>
> 4E 43 4D 48 0C 00 00 00 80 00 34 00 46 C0 00 28
> 00 00 40 00 01 02 F4 F9 B0 F6 5E 09 E0 00 00 16
> 94 04 00 00 22 00 F9 02 00 00 00 01 04 00 00 00
> E0 00 00 FB 49 50 53 00 10 00 00 00 0C 00 28 00
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>
> that looks like quite similar than the Windows one (besides the final 
> padding).
>
> Then all the following out packets are nacked, e.g:
>
> 4E 43 4D 48 0C 00 01 00 D8 00 8C 00 45 00 00 3E
> 05 71 40 00 40 11 0C E8 B0 F6 5E 09 0A 85 0E D2
> B3 30 00 35 00 2A D3 57 58 6A 01 00 00 01 00 00
> 00 00 00 00 05 64 61 69 73 79 06 75 62 75 6E 74
> 75 03 63 6F 6D 00 00 01 00 01 00 00 45 00 00 3E
> 2A EC 40 00 40 11 91 8A B0 F6 5E 09 0A 84 64 B5
> B3 30 00 35 00 2A 7D 75 58 6A 01 00 00 01 00 00
> 00 00 00 00 05 64 61 69 73 79 06 75 62 75 6E 74
> 75 03 63 6F 6D 00 00 01 00 01 00 00 49 50 53 00
> 14 00 00 00 0C 00 3E 00 4C 00 3E 00 00 00 00 00
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00
>
> Those packets look good to me: the main difference with Windows is the
> presence of more than one datagram, but, as far as I understand, this
> should not be a problem since the modem reports:
>
> dwNtbInMaxSize=16384 dwNtbOutMaxSize=16384 wNdpOutPayloadRemainder=0
> wNdpOutDivisor=4 wNdpOutAlignment=4 wNtbOutMaxDatagrams=16 flags=0x20
>
> while in Windows it seems that always only one datagram is sent.
>
> My thought is that the problem is in the modem firmware: in some way,
> the first acked packet is breaking things inside the modem that is not
> able to receive packets anymore, but maybe there is some other
> problems in the tx packets created by the driver and I'm not able to
> catch it.
>

I was wrong, the problem is not with the first packet.

The problem is in cdc_ncm, function cdc_ncm_bind_common, line

usleep_range(1, 2);

It seems that LE922 needs an higher timeout; changing the line to

usleep_range(7, 8);

makes the modem to work fine.

I will submit a patch for this.

Regards,
Daniele

> Does someone have an hint about this?
>
> Is there a way to configure the cdc_mbim driver in order to have
> exactly the same packet format sent in Windows?
>
> USB traces taken with TotalPhase Datacenter are available at
>
> https://drive.google.com/open?id=0B1kPnH2g8ISIZWJiV05qeWN5dVE
>
> Thanks,
> Daniele
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Issue with Telit LE922 and cdc_mbim

[Daniele Palmas]

Hi,

I'm struggling with Telit LE922 modem that presents an MBIM device.
The modem works fine in Windows, while in Linux (tested with 4.9 rc1)
data connection is not functional: using ifconfig I can see

wwp0s20u8i2 Link encap:Ethernet  HWaddr e6:c0:3b:97:80:de
  inet addr:176.246.94.9  Bcast:176.246.94.11  Mask:255.255.255.252
  UP BROADCAST RUNNING NOARP MULTICAST  MTU:1500  Metric:1
  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
  TX packets:1 errors:15 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:0 (0.0 B)  TX bytes:40 (40.0 B)

so the issue seems to be in tx.

I'm using an USB hw sniffer for trying to understand the problem; this
is an example of a NCM packet with Windows 10 driver:

4E 43 4D 48 0C 00 0B 02 48 00 38 00 45 00 00 28
78 E8 40 00 80 06 63 68 05 5C 7A E5 D8 3A C6 03
E9 08 01 BB FB 36 F0 EA C6 8C D8 CB 50 10 80 00
9B 16 00 00 00 00 00 00 49 50 53 00 10 00 00 00
0C 00 28 00 00 00 00 00

16 bit NTB, with NDP at the end. So I enabled CDC_NCM_FLAG_NDP_TO_END,
but still the device is not properly working.

This is the first properly transmitted acked packet in Linux:

4E 43 4D 48 0C 00 00 00 80 00 34 00 46 C0 00 28
00 00 40 00 01 02 F4 F9 B0 F6 5E 09 E0 00 00 16
94 04 00 00 22 00 F9 02 00 00 00 01 04 00 00 00
E0 00 00 FB 49 50 53 00 10 00 00 00 0C 00 28 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

that looks like quite similar than the Windows one (besides the final padding).

Then all the following out packets are nacked, e.g:

4E 43 4D 48 0C 00 01 00 D8 00 8C 00 45 00 00 3E
05 71 40 00 40 11 0C E8 B0 F6 5E 09 0A 85 0E D2
B3 30 00 35 00 2A D3 57 58 6A 01 00 00 01 00 00
00 00 00 00 05 64 61 69 73 79 06 75 62 75 6E 74
75 03 63 6F 6D 00 00 01 00 01 00 00 45 00 00 3E
2A EC 40 00 40 11 91 8A B0 F6 5E 09 0A 84 64 B5
B3 30 00 35 00 2A 7D 75 58 6A 01 00 00 01 00 00
00 00 00 00 05 64 61 69 73 79 06 75 62 75 6E 74
75 03 63 6F 6D 00 00 01 00 01 00 00 49 50 53 00
14 00 00 00 0C 00 3E 00 4C 00 3E 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00

Those packets look good to me: the main difference with Windows is the
presence of more than one datagram, but, as far as I understand, this
should not be a problem since the modem reports:

dwNtbInMaxSize=16384 dwNtbOutMaxSize=16384 wNdpOutPayloadRemainder=0
wNdpOutDivisor=4 wNdpOutAlignment=4 wNtbOutMaxDatagrams=16 flags=0x20

while in Windows it seems that always only one datagram is sent.

My thought is that the problem is in the modem firmware: in some way,
the first acked packet is breaking things inside the modem that is not
able to receive packets anymore, but maybe there is some other
problems in the tx packets created by the driver and I'm not able to
catch it.

Does someone have an hint about this?

Is there a way to configure the cdc_mbim driver in order to have
exactly the same packet format sent in Windows?

USB traces taken with TotalPhase Datacenter are available at

https://drive.google.com/open?id=0B1kPnH2g8ISIZWJiV05qeWN5dVE

Thanks,
Daniele
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/1] USB: serial: usb-serial-simple: add support for another Infineon flashloader

[Daniele Palmas]

This patch adds support for Infineon flashloader 0x8087/0x0801.

The flashloader is used in Telit LE940B modem family with Telit
flashing application.

Following lsusb output for the composition:

Bus 004 Device 020: ID 8087:0801 Intel Corp. 
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   3.00
  bDeviceClass2 Communications
  bDeviceSubClass 0 
  bDeviceProtocol 0 
  bMaxPacketSize0 9
  idVendor   0x8087 Intel Corp.
  idProduct  0x0801 
  bcdDevice0.00
  iManufacturer   0 
  iProduct0 
  iSerial 0 
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   44
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0xc0
  Self Powered
MaxPower  124mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass10 CDC Data
  bInterfaceSubClass  0 Unused
  bInterfaceProtocol  0 
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83  EP 3 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0400  1x 1024 bytes
bInterval   0
bMaxBurst   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02  EP 2 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0400  1x 1024 bytes
bInterval   0
bMaxBurst   0
Binary Object Store Descriptor:
  bLength 5
  bDescriptorType15
  wTotalLength   22
  bNumDeviceCaps  2
  USB 2.0 Extension Device Capability:
bLength 7
bDescriptorType16
bDevCapabilityType  2
bmAttributes   0x0006
  Link Power Management (LPM) Supported
  SuperSpeed USB Device Capability:
bLength10
bDescriptorType16
bDevCapabilityType  3
bmAttributes 0x00
wSpeedsSupported   0x000e
  Device can operate at Full Speed (12Mbps)
  Device can operate at High Speed (480Mbps)
  Device can operate at SuperSpeed (5Gbps)
bFunctionalitySupport   1
  Lowest fully-functional device speed is Full Speed (12Mbps)
bU1DevExitLat  10 micro seconds
bU2DevExitLat2047 micro seconds
Device Status: 0x000d
  Self Powered
  U1 Enabled
  U2 Enabled

Daniele Palmas (1):
  USB: serial: usb-serial-simple: add support for another Infineon
flashloader

 drivers/usb/serial/usb-serial-simple.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/1] USB: serial: usb-serial-simple: add support for another Infineon flashloader

[Daniele Palmas]

This patch adds support for Infineon flashloader 0x8087/0x0801.

The flashloader is used in Telit LE940B modem family with Telit
flashing application.

Signed-off-by: Daniele Palmas <dnl...@gmail.com>
---
 drivers/usb/serial/usb-serial-simple.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/serial/usb-serial-simple.c 
b/drivers/usb/serial/usb-serial-simple.c
index a204782..e98b6e5 100644
--- a/drivers/usb/serial/usb-serial-simple.c
+++ b/drivers/usb/serial/usb-serial-simple.c
@@ -54,7 +54,8 @@ DEVICE(funsoft, FUNSOFT_IDS);
 /* Infineon Flashloader driver */
 #define FLASHLOADER_IDS()  \
{ USB_DEVICE_INTERFACE_CLASS(0x058b, 0x0041, USB_CLASS_CDC_DATA) }, \
-   { USB_DEVICE(0x8087, 0x0716) }
+   { USB_DEVICE(0x8087, 0x0716) }, \
+   { USB_DEVICE(0x8087, 0x0801) }
 DEVICE(flashloader, FLASHLOADER_IDS);
 
 /* Google Serial USB SubClass */
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/1] USB: serial: option: add support for Telit LE920A4

[Daniele Palmas]

  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0 
  bDeviceProtocol 0 
  bMaxPacketSize064
  bNumConfigurations  1
Device Status: 0x
  (Bus Powered)

Daniele Palmas (1):
  USB: serial: option: add support for Telit LE920A4

 drivers/usb/serial/option.c | 21 +
 1 file changed, 21 insertions(+)

-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Daniele Palmas]

This patch adds a set of compositions for Telit LE920A4.

Compositions in short are:

0x1207: tty + tty
0x1208: tty + adb + tty + tty
0x1211: tty + adb + ecm
0x1212: tty + adb
0x1213: ecm + tty
0x1214: tty + adb + ecm + tty

telit_le922_blacklist_usbcfg3 is reused for compositions 0x1211
and 0x1214 due to the same interfaces positions.

Signed-off-by: Daniele Palmas <dnl...@gmail.com>
---
 drivers/usb/serial/option.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 8e07536..7284b2b 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -274,6 +274,12 @@ static void option_instat_callback(struct urb *urb);
 #define TELIT_PRODUCT_LE9200x1200
 #define TELIT_PRODUCT_LE9100x1201
 #define TELIT_PRODUCT_LE910_USBCFG40x1206
+#define TELIT_PRODUCT_LE920A4_1207 0x1207
+#define TELIT_PRODUCT_LE920A4_1208 0x1208
+#define TELIT_PRODUCT_LE920A4_1211 0x1211
+#define TELIT_PRODUCT_LE920A4_1212 0x1212
+#define TELIT_PRODUCT_LE920A4_1213 0x1213
+#define TELIT_PRODUCT_LE920A4_1214 0x1214
 
 /* ZTE PRODUCTS */
 #define ZTE_VENDOR_ID  0x19d2
@@ -638,6 +644,11 @@ static const struct option_blacklist_info 
telit_le922_blacklist_usbcfg3 = {
.reserved = BIT(1) | BIT(2) | BIT(3),
 };
 
+static const struct option_blacklist_info telit_le920a4_blacklist_1 = {
+   .sendsetup = BIT(0),
+   .reserved = BIT(1),
+};
+
 static const struct option_blacklist_info cinterion_rmnet2_blacklist = {
.reserved = BIT(4) | BIT(5),
 };
@@ -1203,6 +1214,16 @@ static const struct usb_device_id option_ids[] = {
.driver_info = (kernel_ulong_t)_le922_blacklist_usbcfg3 },
{ USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_LE920),
.driver_info = (kernel_ulong_t)_le920_blacklist },
+   { USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_LE920A4_1207) },
+   { USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_LE920A4_1208),
+   .driver_info = (kernel_ulong_t)_le920a4_blacklist_1 },
+   { USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_LE920A4_1211),
+   .driver_info = (kernel_ulong_t)_le922_blacklist_usbcfg3 },
+   { USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_LE920A4_1212),
+   .driver_info = (kernel_ulong_t)_le920a4_blacklist_1 },
+   { USB_DEVICE_INTERFACE_CLASS(TELIT_VENDOR_ID, 
TELIT_PRODUCT_LE920A4_1213, 0xff) },
+   { USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_LE920A4_1214),
+   .driver_info = (kernel_ulong_t)_le922_blacklist_usbcfg3 },
{ 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)_intf1_blacklist },
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/1] USB: serial: option: add support for Telit LE910 PID 0x1206

[Daniele Palmas]

This patch adds support for 0x1206 PID of Telit LE910.

Since the interfaces positions are the same than the ones for
0x1043 PID of Telit LE922, telit_le922_blacklist_usbcfg3 is used.

Signed-off-by: Daniele Palmas <dnl...@gmail.com>
---
 drivers/usb/serial/option.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index d96d423..8e07536 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -273,6 +273,7 @@ static void option_instat_callback(struct urb *urb);
 #define TELIT_PRODUCT_LE922_USBCFG50x1045
 #define TELIT_PRODUCT_LE9200x1200
 #define TELIT_PRODUCT_LE9100x1201
+#define TELIT_PRODUCT_LE910_USBCFG40x1206
 
 /* ZTE PRODUCTS */
 #define ZTE_VENDOR_ID  0x19d2
@@ -1198,6 +1199,8 @@ static const struct usb_device_id option_ids[] = {
.driver_info = (kernel_ulong_t)_le922_blacklist_usbcfg0 },
{ USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_LE910),
.driver_info = (kernel_ulong_t)_le910_blacklist },
+   { USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_LE910_USBCFG4),
+   .driver_info = (kernel_ulong_t)_le922_blacklist_usbcfg3 },
{ USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_LE920),
.driver_info = (kernel_ulong_t)_le920_blacklist },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_MF622, 0xff, 
0xff, 0xff) }, /* ZTE WCDMA products */
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/1] USB: serial: option: add support for Telit LE910 PID 0x1206

[Daniele Palmas]

   9
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x89  EP 9 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x06  EP 6 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber7
  bAlternateSetting   0
  bNumEndpoints   3
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass  0 
  bInterfaceProtocol  0 
  iInterface  0 
  ** UNRECOGNIZED:  05 24 00 10 01
  ** UNRECOGNIZED:  05 24 01 00 00
  ** UNRECOGNIZED:  04 24 02 02
  ** UNRECOGNIZED:  05 24 06 00 00
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x8c  EP 12 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x000a  1x 10 bytes
bInterval   9
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x8b  EP 11 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x07  EP 7 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
Device Qualifier (for other device speed):
  bLength10
  bDescriptorType 6
  bcdUSB   2.00
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0 
  bDeviceProtocol 0 
  bMaxPacketSize064
  bNumConfigurations  1
Device Status: 0x
  (Bus Powered)


Daniele Palmas (1):
  USB: serial: option: add support for Telit LE910 PID 0x1206

 drivers/usb/serial/option.c | 3 +++
 1 file changed, 3 insertions(+)

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/1] net: usb: cdc_ncm: adding Telit LE910 V2 mobile broadband card

[Daniele Palmas]

Telit LE910 V2 is a mobile broadband card with no ARP capabilities:
the patch makes this device to use wwan_noarp_info struct

Signed-off-by: Daniele Palmas <dnl...@gmail.com>
---
 drivers/net/usb/cdc_ncm.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index 86ba30b..2fb31ed 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -1626,6 +1626,13 @@ static const struct usb_device_id cdc_devs[] = {
  .driver_info = (unsigned long) _info,
},
 
+   /* Telit LE910 V2 */
+   { USB_DEVICE_AND_INTERFACE_INFO(0x1bc7, 0x0036,
+   USB_CLASS_COMM,
+   USB_CDC_SUBCLASS_NCM, USB_CDC_PROTO_NONE),
+ .driver_info = (unsigned long)_noarp_info,
+   },
+
/* DW5812 LTE Verizon Mobile Broadband Card
 * Unlike DW5550 this device requires FLAG_NOARP
 */
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/1] net: usb: cdc_ncm: adding Telit LE910 V2 mobile broadband card

[Daniele Palmas]

bDescriptorType 5
bEndpointAddress 0x8b  EP 11 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   4
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber   11
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass10 CDC Data
  bInterfaceSubClass  0 Unused
  bInterfaceProtocol  0 
  iInterface 21 Data
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x8c  EP 12 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x0c  EP 12 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
Interface Association:
  bLength 8
  bDescriptorType11
  bFirstInterface12
  bInterfaceCount 2
  bFunctionClass  2 Communications
  bFunctionSubClass  13 
  bFunctionProtocol   0 
  iFunction  22 CDC NCM
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber   12
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass 2 Communications
  bInterfaceSubClass 13 
  bInterfaceProtocol  0 
  iInterface 23 CDC NCM
  CDC Header:
bcdCDC   1.20
  CDC Union:
bMasterInterface12
bSlaveInterface 13 
  CDC NCM:
bcdNcmVersion1.00
bmNetworkCapabilities 0x00
  CDC Ethernet:
iMacAddress 24 11121314
bmEthernetStatistics0x
wMaxSegmentSize   1514
wNumberMCFilters0x
bNumberPowerFilters  0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x8d  EP 13 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   4
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber   13
  bAlternateSetting   0
  bNumEndpoints   0
  bInterfaceClass10 CDC Data
  bInterfaceSubClass  0 Unused
  bInterfaceProtocol  1 
  iInterface 25 Data (OFF)
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber   13
  bAlternateSetting   1
  bNumEndpoints   2
  bInterfaceClass10 CDC Data
  bInterfaceSubClass  0 Unused
  bInterfaceProtocol  1 
  iInterface 26 Data (ON)
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x8e  EP 14 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x0e  EP 14 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
Device Qualifier (for other device speed):
  bLength10
  bDescriptorType 6
  bcdUSB   2.00
  bDeviceClass  239 Miscellaneous Device
  bDeviceSubClass 2 ?
  bDeviceProtocol 1 Interface Association
  bMaxPacketSize064
  bNumConfigurations  1
Device Status: 0x0001
  Self Powered

Daniele Palmas (1):
  net: usb: cdc_ncm: adding Telit LE910 V2 mobile broadband card

 drivers/net/usb/cdc_ncm.c | 7 +++
 1 file changed, 7 insertions(+)

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More

[PATCH v2 0/1] usb: serial: option: Adding support for Telit LE922 PID 0x1045

[Daniele Palmas]

  bNumEndpoints   0
  bInterfaceClass 1 Audio
  bInterfaceSubClass  2 Streaming
  bInterfaceProtocol  0 
  iInterface  0 
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber9
  bAlternateSetting   1
  bNumEndpoints   1
  bInterfaceClass 1 Audio
  bInterfaceSubClass  2 Streaming
  bInterfaceProtocol  0 
  iInterface  0 
  AudioStreaming Interface Descriptor:
bLength 7
bDescriptorType36
bDescriptorSubtype  1 (AS_GENERAL)
bTerminalLink   2
bDelay  1 frames
wFormatTag  1 PCM
  AudioStreaming Interface Descriptor:
bLength11
bDescriptorType36
bDescriptorSubtype  2 (FORMAT_TYPE)
bFormatType 1 (FORMAT_TYPE_I)
bNrChannels 1
bSubframeSize   2
bBitResolution 16
bSamFreqType1 Discrete
tSamFreq[ 0] 8000
  Endpoint Descriptor:
bLength 9
bDescriptorType 5
bEndpointAddress 0x8d  EP 13 IN
bmAttributes5
  Transfer TypeIsochronous
  Synch Type   Asynchronous
  Usage Type   Data
wMaxPacketSize 0x0010  1x 16 bytes
bInterval   4
bRefresh0
bSynchAddress   0
AudioControl Endpoint Descriptor:
  bLength 7
  bDescriptorType37
  bDescriptorSubtype  1 (EP_GENERAL)
  bmAttributes 0x01
Sampling Frequency
  bLockDelayUnits 1 Milliseconds
  wLockDelay  1 Milliseconds
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber   10
  bAlternateSetting   0
  bNumEndpoints   0
  bInterfaceClass 1 Audio
  bInterfaceSubClass  2 Streaming
  bInterfaceProtocol  0 
  iInterface  0 
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber   10
  bAlternateSetting   1
  bNumEndpoints   1
  bInterfaceClass 1 Audio
  bInterfaceSubClass  2 Streaming
  bInterfaceProtocol  0 
  iInterface  0 
  AudioStreaming Interface Descriptor:
bLength 7
bDescriptorType36
bDescriptorSubtype  1 (AS_GENERAL)
bTerminalLink   3
bDelay  1 frames
wFormatTag  1 PCM
  AudioStreaming Interface Descriptor:
bLength11
bDescriptorType36
bDescriptorSubtype  2 (FORMAT_TYPE)
bFormatType 1 (FORMAT_TYPE_I)
bNrChannels 1
bSubframeSize   2
bBitResolution 16
bSamFreqType1 Discrete
tSamFreq[ 0] 8000
  Endpoint Descriptor:
bLength 9
bDescriptorType 5
bEndpointAddress 0x08  EP 8 OUT
bmAttributes9
  Transfer TypeIsochronous
  Synch Type   Adaptive
  Usage Type   Data
wMaxPacketSize 0x0010  1x 16 bytes
bInterval   4
bRefresh0
bSynchAddress   0
AudioControl Endpoint Descriptor:
  bLength 7
  bDescriptorType37
  bDescriptorSubtype  1 (EP_GENERAL)
  bmAttributes 0x01
Sampling Frequency
  bLockDelayUnits 1 Milliseconds
  wLockDelay  1 Milliseconds
Binary Object Store Descriptor:
  bLength 5
  bDescriptorType15
  wTotalLength   22
  bNumDeviceCaps  2
  USB 2.0 Extension Device Capability:
bLength 7
bDescriptorType16
bDevCapabilityType  2
bmAttributes   0x0002
  Link Power Management (LPM) Supported
  SuperSpeed USB Device Capability:
bLength10
bDescriptorType16
bDevCapabilityType  3
bmAttributes 0x00
wSpeedsSupported   0x000f
  Device can operate at Low Speed (1Mbps)
  Device can operate at Full Speed (12Mbps)
  Device can operate at High Speed (480Mbps)
  Device can operate at SuperSpeed (5Gbps)
bFunctionalitySupport   1
  Lowest fully-functional device speed is Full Speed (12Mbps)
bU1DevExitLat   1 micro seconds
bU2DevExitLat 500 micro seconds
Device Status: 0x
  (Bus Powered)

Daniele

[PATCH v2 1/1] usb: serial: option: Adding support for Telit LE922 PID 0x1045

[Daniele Palmas]

This patch adds support for 0x1045 PID of Telit LE922.

Signed-off-by: Daniele Palmas <dnl...@gmail.com>
---
 drivers/usb/serial/option.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index db86e51..15d16f2 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -270,6 +270,7 @@ static void option_instat_callback(struct urb *urb);
 #define TELIT_PRODUCT_UE910_V2 0x1012
 #define TELIT_PRODUCT_LE922_USBCFG00x1042
 #define TELIT_PRODUCT_LE922_USBCFG30x1043
+#define TELIT_PRODUCT_LE922_USBCFG50x1045
 #define TELIT_PRODUCT_LE9200x1200
 #define TELIT_PRODUCT_LE9100x1201
 
@@ -1176,6 +1177,8 @@ static const struct usb_device_id option_ids[] = {
.driver_info = (kernel_ulong_t)_le922_blacklist_usbcfg0 },
{ USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_LE922_USBCFG3),
.driver_info = (kernel_ulong_t)_le922_blacklist_usbcfg3 },
+   { USB_DEVICE_INTERFACE_CLASS(TELIT_VENDOR_ID, 
TELIT_PRODUCT_LE922_USBCFG5, 0xff),
+   .driver_info = (kernel_ulong_t)_le922_blacklist_usbcfg0 },
{ USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_LE910),
.driver_info = (kernel_ulong_t)_le910_blacklist },
{ USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_LE920),
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/1] usb: serial: option: Adding support for Telit LE922 PID 0x1045

[Daniele Palmas]

Hi Johan,

2016-02-28 16:36 GMT+01:00 Johan Hovold <jo...@kernel.org>:
> On Fri, Feb 26, 2016 at 01:35:27PM +0100, Daniele Palmas wrote:
>> This patch adds support for 0x1045 PID of Telit LE922.
>>
>> Signed-off-by: Daniele Palmas <dnl...@gmail.com>
>> ---
>>  drivers/usb/serial/option.c | 8 
>>  1 file changed, 8 insertions(+)
>>
>> diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
>> index db86e51..4be2c7c 100644
>> --- a/drivers/usb/serial/option.c
>> +++ b/drivers/usb/serial/option.c
>> @@ -270,6 +270,7 @@ static void option_instat_callback(struct urb *urb);
>>  #define TELIT_PRODUCT_UE910_V2   0x1012
>>  #define TELIT_PRODUCT_LE922_USBCFG0  0x1042
>>  #define TELIT_PRODUCT_LE922_USBCFG3  0x1043
>> +#define TELIT_PRODUCT_LE922_USBCFG5  0x1045
>>  #define TELIT_PRODUCT_LE920  0x1200
>>  #define TELIT_PRODUCT_LE910  0x1201
>>
>> @@ -627,6 +628,11 @@ static const struct option_blacklist_info 
>> telit_le922_blacklist_usbcfg3 = {
>>   .reserved = BIT(1) | BIT(2) | BIT(3),
>>  };
>>
>> +static const struct option_blacklist_info telit_le922_blacklist_usbcfg5 = {
>> + .sendsetup = BIT(2),
>> + .reserved = BIT(0) | BIT(1) | BIT(3) | BIT(8) | BIT(9) | BIT(10),
>> +};
>> +
>>  static const struct usb_device_id option_ids[] = {
>>   { USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_COLT) },
>>   { USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_RICOLA) },
>> @@ -1176,6 +1182,8 @@ static const struct usb_device_id option_ids[] = {
>>   .driver_info = (kernel_ulong_t)_le922_blacklist_usbcfg0 
>> },
>>   { USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_LE922_USBCFG3),
>>   .driver_info = (kernel_ulong_t)_le922_blacklist_usbcfg3 
>> },
>> + { USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_LE922_USBCFG5),
>> + .driver_info = (kernel_ulong_t)_le922_blacklist_usbcfg5 
>> },
>
> Please use USB_DEVICE_INTERFACE_CLASS to keep the blacklist entry
> shorter (perhaps you can then even reuse an existing one).

Thanks for the review!

I will submit a v2 patch.

Regards,
Daniele

>
> Thanks,
> Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/1] usb: serial: option: Adding support for Telit LE922 PID 0x1045

[Daniele Palmas]

This patch adds support for 0x1045 PID of Telit LE922.

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

diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index db86e51..4be2c7c 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -270,6 +270,7 @@ static void option_instat_callback(struct urb *urb);
 #define TELIT_PRODUCT_UE910_V2 0x1012
 #define TELIT_PRODUCT_LE922_USBCFG00x1042
 #define TELIT_PRODUCT_LE922_USBCFG30x1043
+#define TELIT_PRODUCT_LE922_USBCFG50x1045
 #define TELIT_PRODUCT_LE9200x1200
 #define TELIT_PRODUCT_LE9100x1201
 
@@ -627,6 +628,11 @@ static const struct option_blacklist_info 
telit_le922_blacklist_usbcfg3 = {
.reserved = BIT(1) | BIT(2) | BIT(3),
 };
 
+static const struct option_blacklist_info telit_le922_blacklist_usbcfg5 = {
+   .sendsetup = BIT(2),
+   .reserved = BIT(0) | BIT(1) | BIT(3) | BIT(8) | BIT(9) | BIT(10),
+};
+
 static const struct usb_device_id option_ids[] = {
{ USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_COLT) },
{ USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_RICOLA) },
@@ -1176,6 +1182,8 @@ static const struct usb_device_id option_ids[] = {
.driver_info = (kernel_ulong_t)_le922_blacklist_usbcfg0 },
{ USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_LE922_USBCFG3),
.driver_info = (kernel_ulong_t)_le922_blacklist_usbcfg3 },
+   { USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_LE922_USBCFG5),
+   .driver_info = (kernel_ulong_t)_le922_blacklist_usbcfg5 },
{ USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_LE910),
.driver_info = (kernel_ulong_t)_le910_blacklist },
{ USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_LE920),
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/1] usb: serial: option: Adding support for Telit LE922 PID 0x1045

[Daniele Palmas]

  0 
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber9
  bAlternateSetting   1
  bNumEndpoints   1
  bInterfaceClass 1 Audio
  bInterfaceSubClass  2 Streaming
  bInterfaceProtocol  0 
  iInterface  0 
  AudioStreaming Interface Descriptor:
bLength 7
bDescriptorType36
bDescriptorSubtype  1 (AS_GENERAL)
bTerminalLink   2
bDelay  1 frames
wFormatTag  1 PCM
  AudioStreaming Interface Descriptor:
bLength11
bDescriptorType36
bDescriptorSubtype  2 (FORMAT_TYPE)
bFormatType 1 (FORMAT_TYPE_I)
bNrChannels 1
bSubframeSize   2
bBitResolution 16
bSamFreqType1 Discrete
tSamFreq[ 0] 8000
  Endpoint Descriptor:
bLength 9
bDescriptorType 5
bEndpointAddress 0x8d  EP 13 IN
bmAttributes5
  Transfer TypeIsochronous
  Synch Type   Asynchronous
  Usage Type   Data
wMaxPacketSize 0x0010  1x 16 bytes
bInterval   4
bRefresh0
bSynchAddress   0
AudioControl Endpoint Descriptor:
  bLength 7
  bDescriptorType37
  bDescriptorSubtype  1 (EP_GENERAL)
  bmAttributes 0x01
Sampling Frequency
  bLockDelayUnits 1 Milliseconds
  wLockDelay  1 Milliseconds
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber   10
  bAlternateSetting   0
  bNumEndpoints   0
  bInterfaceClass 1 Audio
  bInterfaceSubClass  2 Streaming
  bInterfaceProtocol  0 
  iInterface  0 
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber   10
  bAlternateSetting   1
  bNumEndpoints   1
  bInterfaceClass 1 Audio
  bInterfaceSubClass  2 Streaming
  bInterfaceProtocol  0 
  iInterface  0 
  AudioStreaming Interface Descriptor:
bLength 7
bDescriptorType36
bDescriptorSubtype  1 (AS_GENERAL)
bTerminalLink   3
bDelay  1 frames
wFormatTag  1 PCM
  AudioStreaming Interface Descriptor:
bLength11
bDescriptorType36
bDescriptorSubtype  2 (FORMAT_TYPE)
bFormatType 1 (FORMAT_TYPE_I)
bNrChannels 1
bSubframeSize   2
bBitResolution 16
bSamFreqType1 Discrete
tSamFreq[ 0] 8000
  Endpoint Descriptor:
bLength 9
bDescriptorType 5
bEndpointAddress 0x08  EP 8 OUT
bmAttributes9
  Transfer TypeIsochronous
  Synch Type   Adaptive
  Usage Type   Data
wMaxPacketSize 0x0010  1x 16 bytes
bInterval   4
bRefresh0
bSynchAddress   0
AudioControl Endpoint Descriptor:
  bLength 7
  bDescriptorType37
  bDescriptorSubtype  1 (EP_GENERAL)
  bmAttributes 0x01
Sampling Frequency
  bLockDelayUnits 1 Milliseconds
  wLockDelay  1 Milliseconds
Binary Object Store Descriptor:
  bLength 5
  bDescriptorType15
  wTotalLength   22
  bNumDeviceCaps  2
  USB 2.0 Extension Device Capability:
bLength 7
bDescriptorType16
bDevCapabilityType  2
bmAttributes   0x0002
  Link Power Management (LPM) Supported
  SuperSpeed USB Device Capability:
bLength10
bDescriptorType16
bDevCapabilityType  3
bmAttributes 0x00
wSpeedsSupported   0x000f
  Device can operate at Low Speed (1Mbps)
  Device can operate at Full Speed (12Mbps)
  Device can operate at High Speed (480Mbps)
  Device can operate at SuperSpeed (5Gbps)
bFunctionalitySupport   1
  Lowest fully-functional device speed is Full Speed (12Mbps)
bU1DevExitLat   1 micro seconds
bU2DevExitLat 500 micro seconds
Device Status: 0x
  (Bus Powered)

Daniele Palmas (1):
  usb: serial: option: Adding support for Telit LE922 PID 0x1045

 drivers/usb/serial/option.c | 8 
 1 file changed, 8 insertions

[PATCH v2 1/2] net: usb: cdc_ncm: Adding Dell DW5812 LTE Verizon Mobile Broadband Card

[Daniele Palmas]

Unlike DW5550, Dell DW5812 is a mobile broadband card with no ARP
capabilities: the patch makes this device to use wwan_noarp_info struct

Signed-off-by: Daniele Palmas <dnl...@gmail.com>
---
 drivers/net/usb/cdc_ncm.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index b45e5ca..7be9b73 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -1593,6 +1593,15 @@ static const struct usb_device_id cdc_devs[] = {
  .driver_info = (unsigned long) _info,
},
 
+   /* DW5812 LTE Verizon Mobile Broadband Card
+* Unlike DW5550 this device requires FLAG_NOARP
+*/
+   { USB_DEVICE_AND_INTERFACE_INFO(0x413c, 0x81bb,
+   USB_CLASS_COMM,
+   USB_CDC_SUBCLASS_NCM, USB_CDC_PROTO_NONE),
+ .driver_info = (unsigned long)_noarp_info,
+   },
+
/* Dell branded MBM devices like DW5550 */
{ .match_flags = USB_DEVICE_ID_MATCH_INT_INFO
| USB_DEVICE_ID_MATCH_VENDOR,
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 0/2] net: usb: cdc_ncm: Adding support for two new Dell devices

[Daniele Palmas]

This patch series add support in the cdc_ncm driver for two devices
based on the same platform, that are different only for carrier
customization.

V2: Added comment for highlighting FLAG_NOARP usage for those devices

Daniele Palmas (2):
  net: usb: cdc_ncm: Adding Dell DW5812 LTE Verizon Mobile Broadband
Card
  net: usb: cdc_ncm: Adding Dell DW5813 LTE AT Mobile Broadband Card

 drivers/net/usb/cdc_ncm.c | 18 ++
 1 file changed, 18 insertions(+)

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 2/2] net: usb: cdc_ncm: Adding Dell DW5813 LTE AT Mobile Broadband Card

[Daniele Palmas]

Unlike DW5550, Dell DW5813 is a mobile broadband card with no ARP
capabilities: the patch makes this device to use wwan_noarp_info struct

Signed-off-by: Daniele Palmas <dnl...@gmail.com>
---
 drivers/net/usb/cdc_ncm.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index 7be9b73..89536d9 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -1602,6 +1602,15 @@ static const struct usb_device_id cdc_devs[] = {
  .driver_info = (unsigned long)_noarp_info,
},
 
+   /* DW5813 LTE AT Mobile Broadband Card
+* Unlike DW5550 this device requires FLAG_NOARP
+*/
+   { USB_DEVICE_AND_INTERFACE_INFO(0x413c, 0x81bc,
+   USB_CLASS_COMM,
+   USB_CDC_SUBCLASS_NCM, USB_CDC_PROTO_NONE),
+ .driver_info = (unsigned long)_noarp_info,
+   },
+
/* Dell branded MBM devices like DW5550 */
{ .match_flags = USB_DEVICE_ID_MATCH_INT_INFO
| USB_DEVICE_ID_MATCH_VENDOR,
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/2] net: usb: cdc_ncm: Adding support for two new Dell devices

[Daniele Palmas]

Hi Bjorn,

2015-12-17 13:21 GMT+01:00 Bjørn Mork <bj...@mork.no>:
> Dan Williams <d...@redhat.com> writes:
>> On Wed, 2015-12-16 at 10:39 +0100, Daniele Palmas wrote:
>>> This patch series add support in the cdc_ncm driver for two devices
>>> based on the same platform, that are different only for carrier
>>> customization.
>>>
>>> The devices do not have ARP capabilities.
>>>
>>> Daniele Palmas (2):
>>>   net: usb: cdc_ncm: Adding Dell DW5812 LTE Verizon Mobile Broadband
>>> Card
>>>   net: usb: cdc_ncm: Adding Dell DW5813 LTE AT Mobile Broadband
>>> Card
>>
>> Quite interesting; Google knows nothing about these devices that I can
>> find.  What platform are these based on?
>
> There are a number of launchpad bugs reported for these devices.  Don't
> know why they chose that channel..  This one:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1520147
> shows that it is an Intel/Infineon based design.
>
> BTW, DeWalt seems to own these device names :)
>

patches were passed first to Canonical for custom OS image testing.

413c:81ba is the HSPA+ variant of the family: however this does not
use ncm, but ecm, see
https://github.com/torvalds/linux/commit/0b88393cdf6b1322522849e61f7a3328f4fd3843

>
> Bjørn

Thanks,
Daniele
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/2] net: usb: cdc_ncm: Adding support for two new Dell devices

[Daniele Palmas]

Hi Dan,

2015-12-16 18:12 GMT+01:00 Dan Williams <d...@redhat.com>:
> On Wed, 2015-12-16 at 10:39 +0100, Daniele Palmas wrote:
>> This patch series add support in the cdc_ncm driver for two devices
>> based on the same platform, that are different only for carrier
>> customization.
>>
>> The devices do not have ARP capabilities.
>>
>> Daniele Palmas (2):
>>   net: usb: cdc_ncm: Adding Dell DW5812 LTE Verizon Mobile Broadband
>> Card
>>   net: usb: cdc_ncm: Adding Dell DW5813 LTE AT Mobile Broadband
>> Card
>
> Quite interesting; Google knows nothing about these devices that I can
> find.  What platform are these based on?
>

those devices are still in the testing stage, so there is nothing
about them in the web. They are Infineon based.

> But in any case, since these blocks are almost identical to the DW5550
> block, maybe update the comments to indicate that they need NOARP
> unlike the MBM platform that the 5550 is based on?

Sure, I can do a V2 patch for that.

>
> Dan

Thanks,
Daniele
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/2] net: usb: cdc_ncm: Adding support for two new Dell devices

[Daniele Palmas]

This patch series add support in the cdc_ncm driver for two devices
based on the same platform, that are different only for carrier
customization.

The devices do not have ARP capabilities.

Daniele Palmas (2):
  net: usb: cdc_ncm: Adding Dell DW5812 LTE Verizon Mobile Broadband
Card
  net: usb: cdc_ncm: Adding Dell DW5813 LTE AT Mobile Broadband Card

 drivers/net/usb/cdc_ncm.c | 14 ++
 1 file changed, 14 insertions(+)

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] net: usb: cdc_ncm: Adding Dell DW5812 LTE Verizon Mobile Broadband Card

[Daniele Palmas]

Dell DW5812 is a mobile broadband card with no ARP capabilities: the patch
makes this device to use wwan_noarp_info struct

Signed-off-by: Daniele Palmas <dnl...@gmail.com>
---
 drivers/net/usb/cdc_ncm.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index b45e5ca..2c0257a 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -1593,6 +1593,13 @@ static const struct usb_device_id cdc_devs[] = {
  .driver_info = (unsigned long) _info,
},
 
+   /* DW5812 LTE Verizon Mobile Broadband Card */
+   { USB_DEVICE_AND_INTERFACE_INFO(0x413c, 0x81bb,
+   USB_CLASS_COMM,
+   USB_CDC_SUBCLASS_NCM, USB_CDC_PROTO_NONE),
+ .driver_info = (unsigned long)_noarp_info,
+   },
+
/* Dell branded MBM devices like DW5550 */
{ .match_flags = USB_DEVICE_ID_MATCH_INT_INFO
| USB_DEVICE_ID_MATCH_VENDOR,
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] net: usb: cdc_ncm: Adding Dell DW5813 LTE AT Mobile Broadband Card

[Daniele Palmas]

Dell DW5813 is a mobile broadband card with no ARP capabilities: the patch
makes this device to use wwan_noarp_info struct

Signed-off-by: Daniele Palmas <dnl...@gmail.com>
---
 drivers/net/usb/cdc_ncm.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index 2c0257a..8e971a2 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -1600,6 +1600,13 @@ static const struct usb_device_id cdc_devs[] = {
  .driver_info = (unsigned long)_noarp_info,
},
 
+   /* DW5813 LTE AT Mobile Broadband Card */
+   { USB_DEVICE_AND_INTERFACE_INFO(0x413c, 0x81bc,
+   USB_CLASS_COMM,
+   USB_CDC_SUBCLASS_NCM, USB_CDC_PROTO_NONE),
+ .driver_info = (unsigned long)_noarp_info,
+   },
+
/* Dell branded MBM devices like DW5550 */
{ .match_flags = USB_DEVICE_ID_MATCH_INT_INFO
| USB_DEVICE_ID_MATCH_VENDOR,
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/1] net: usb: cdc_ether: add Dell DW5580 as a mobile broadband adapter

[Daniele Palmas]

Since Dell DW5580 is a 3G modem, this patch adds the device as a
mobile broadband adapter

Signed-off-by: Daniele Palmas <dnl...@gmail.com>
---
 drivers/net/usb/cdc_ether.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c
index 35a2bff..5e92076 100644
--- a/drivers/net/usb/cdc_ether.c
+++ b/drivers/net/usb/cdc_ether.c
@@ -764,6 +764,11 @@ static const struct usb_device_id  products[] = {
USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE),
.driver_info = (kernel_ulong_t) _info,
 }, {
+   /* Dell DW5580 modules */
+   USB_DEVICE_AND_INTERFACE_INFO(DELL_VENDOR_ID, 0x81ba, USB_CLASS_COMM,
+   USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE),
+   .driver_info = (kernel_ulong_t)_info,
+}, {
USB_INTERFACE_INFO(USB_CLASS_COMM, USB_CDC_SUBCLASS_ETHERNET,
USB_CDC_PROTO_NONE),
.driver_info = (unsigned long) _info,
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] cdc_acm: Ignore Infineon Flash Loader utility

[Daniele Palmas]

Hi Johan,

2015-11-13 11:58 GMT+01:00 Johan Hovold <jo...@kernel.org>:
> On Thu, Nov 12, 2015 at 02:55:04PM +0100, Bjørn Mork wrote:
>> Daniele Palmas <dnl...@gmail.com> writes:
>
>> > But I see that Infineon flashing devices in newer chipsets have become
>> > an only bulk serial link device (see device 0x8087/0x0716 in
>> > usb-serial-simple), so maybe this has a meaning...
>>
>> Yes.  I have a Sierra Wireless EM7345 modem which is based on the same
>> chipset. I haven't really paid much attemtion to the flashloader
>> functionality before, but this is how that modem looks before it loads
>> its Sierra firmware:
>
>> So this device looks very much like an ACM device, except that it is
>> missing the necessary control interface and status endpoint.  And
>> without a control interface there is of course no way to send a properly
>> formatted CDC control request either.
>>
>> I assume the different vendors also use the same Intel provided firmware
>> toolkit, making the firmwares share basic functionality like bootloader
>> and flashing.  But the USB descriptors are likely configurable by the
>> vendor.  Telit might have tried to "improve" the above into a proper ACM
>> device.
>>
>> I believe this supports the assumption that Infineon Flash Loader
>> devices have some ACM descriptors without actually being ACM class
>> devices, and that it is best to just collect them all in the
>> usb-serial-simple "flashloader" driver.
>
> I'm still not convinced. The device at hand does look and apparently
> behaves like a compliant ACM device, and I think we need to figure out
> why it does not work with this particular proprietary user-space tool
> before modifying the kernel.
>
> For example, using usb-serial-simple means that no line-control requests
> are sent. Perhaps the tool simply needs to set the termios settings to
> something else than the default 9600N81 that the cdc-acm driver uses.
>
> Modem control-requests would not be sent either (and HUPCL determines if
> DTR/RTS is lowered at close).
>
> Daniele, could you provide some more details about what happens when the
> proprietary tool fails. Do you have access to the sources?

I'll try to explain how the whole thing should work.

This is what happens when the device is turned on (without modifying
the drivers):

[155492.352031] usb 1-3: new high-speed USB device number 27 using ehci-pci
[155492.485429] usb 1-3: config 1 interface 0 altsetting 0 endpoint
0x81 has an invalid bInterval 255, changing to 11
[155492.485436] usb 1-3: New USB device found, idVendor=058b, idProduct=0041
[155492.485439] usb 1-3: New USB device strings: Mfr=0, Product=0,
SerialNumber=0
[155492.485952] cdc_acm 1-3:1.0: ttyACM0: USB ACM device

This is the flashing device that is caught by the cdc-acm driver. Once
the ttyACM appears, the application starts sending a magic string
(simple write on the file descriptor) to keep the device in flashing
mode. If this magic string is not properly received in a certain time
interval, the modem goes on in normal operative mode:

[155493.748094] usb 1-3: USB disconnect, device number 27
[155494.916025] usb 1-3: new high-speed USB device number 28 using ehci-pci
[155495.059978] usb 1-3: New USB device found, idVendor=1bc7, idProduct=0021
[155495.059983] usb 1-3: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[155495.059986] usb 1-3: Product: 6 CDC-ACM + 1 CDC-ECM
[155495.059989] usb 1-3: Manufacturer: Telit
[155495.059992] usb 1-3: SerialNumber: 359658044004697
[155495.138958] cdc_acm 1-3:1.0: ttyACM0: USB ACM device
[155495.140832] cdc_acm 1-3:1.2: ttyACM1: USB ACM device
[155495.142827] cdc_acm 1-3:1.4: ttyACM2: USB ACM device
[155495.144462] cdc_acm 1-3:1.6: ttyACM3: USB ACM device
[155495.145967] cdc_acm 1-3:1.8: ttyACM4: USB ACM device
[155495.147588] cdc_acm 1-3:1.10: ttyACM5: USB ACM device
[155495.154322] cdc_ether 1-3:1.12 wwan0: register 'cdc_ether' at
usb-:00:1a.7-3, Mobile Broadband Network Device, 00:00:11:12:13:14

Using the cdc-acm driver, the string, though being sent in the same
way than using the usb-serial-simple driver (I can confirm that the
data is passing properly since I used an hw usb sniffer), does not
make the device to stay in flashing mode.

I thought that the problem was something done by the acm driver when
opening the port that is not accepted well by the flashing device on
the firmware side, so I tried also in the past to debug the driver,
but without success.

I can start again to understand which is really the problem with
cdc-acm, but my fear is that to have a working solution with cdc-acm
will be more complicated (e.g. adding a new quirk) than adding support
in the usb-serial-simple driver. Consider also that this is not really
a communication device with

Re: [PATCH 1/2] cdc_acm: Ignore Infineon Flash Loader utility

[Daniele Palmas]

Hi Bjorn,

2015-11-12 12:39 GMT+01:00 Bjørn Mork :
> Oliver Neukum  writes:
>> On Thu, 2015-11-12 at 10:12 +0100, Johan Hovold wrote:
>>> What exactly do you mean by "not work"? Does the driver fail to probe?
>>> Or is it just that your user-space tool expects the tty devices to be
>>> named ttyUSBn rather than ttyACMn (in which case the tool needs to be
>>> fixed)?
>>
>> Hi,
>>
>> actually the cdc-acm driver contains some baggage for status
>> inquiries, the parsing of the extra headers and other stuff.
>> If you really just need a serial link, cdc-acm is not a good choice.
>
> True.  But that decision is really up to the firmware developer, isn't
> it?  They should know what they are doing.  Yes, that's a bad joke if it
> wasn't obvious :)
>
> But trying to be serious - I'm wondering a bit about this application
> that supposedly fails.  Any chance we could have a look at that?  Given
> the rather contentless descriptions of the problem, I wouldn't be
> surprised if it all boils down to some stupid device name assumption or
> something like that.  If so, then I think it is wrong trying to work
> around the problem in the kernel.
>

Unfortunately the application has a proprietary firmware flashing
protocol under NDA, so I am not able to share it. I know that I will
lose points for that...

I can confirm that it is not a stupid device name assumption, since
the device name is an argument of the flashing application.

Being the device an "Infineon" device, it would be really interesting
what developers at Infineon think about that...

But I see that Infineon flashing devices in newer chipsets have become
an only bulk serial link device (see device 0x8087/0x0716 in
usb-serial-simple), so maybe this has a meaning...

>
> Bjørn

Regards,
Daniele
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] cdc_acm: Ignore Infineon Flash Loader utility

[Daniele Palmas]

Hi,

2015-11-12 14:55 GMT+01:00 Bjørn Mork <bj...@mork.no>:
> Daniele Palmas <dnl...@gmail.com> writes:
>
>> Unfortunately the application has a proprietary firmware flashing
>> protocol under NDA, so I am not able to share it. I know that I will
>> lose points for that...
>
> I was afraid of that.
>
>> I can confirm that it is not a stupid device name assumption, since
>> the device name is an argument of the flashing application.
>
> OK, thanks.
>
>> Being the device an "Infineon" device, it would be really interesting
>> what developers at Infineon think about that...
>
> I guess you have to do s/Infineon/Intel/ now.  Not sure that helps much,
> though.  The Intel modem division haven't been much more open about
> their business than Infineon used to be (or Qualcomm is for that sake -
> it looks like a radio modem related disease)
>
>> But I see that Infineon flashing devices in newer chipsets have become
>> an only bulk serial link device (see device 0x8087/0x0716 in
>> usb-serial-simple), so maybe this has a meaning...
>
> Yes.  I have a Sierra Wireless EM7345 modem which is based on the same
> chipset. I haven't really paid much attemtion to the flashloader
> functionality before, but this is how that modem looks before it loads
> its Sierra firmware:
>
>
> Bus 003 Device 013: ID 8087:0716 Intel Corp.
> Device Descriptor:
>   bLength18
>   bDescriptorType 1
>   bcdUSB   2.00
>   bDeviceClass2 Communications
>   bDeviceSubClass 0
>   bDeviceProtocol 0
>   bMaxPacketSize064
>   idVendor   0x8087 Intel Corp.
>   idProduct  0x0716
>   bcdDevice0.00
>   iManufacturer   0
>   iProduct0
>   iSerial 0
>   bNumConfigurations  1
>   Configuration Descriptor:
> bLength 9
> bDescriptorType 2
> wTotalLength   46
> bNumInterfaces  1
> bConfigurationValue 1
> iConfiguration  0
> bmAttributes 0xc0
>   Self Powered
> MaxPower  500mA
> ** UNRECOGNIZED:  05 24 00 10 01
> ** UNRECOGNIZED:  05 24 01 00 00
> ** UNRECOGNIZED:  04 24 02 02
> Interface Descriptor:
>   bLength 9
>   bDescriptorType 4
>   bInterfaceNumber0
>   bAlternateSetting   0
>   bNumEndpoints   2
>   bInterfaceClass10 CDC Data
>   bInterfaceSubClass  0 Unused
>   bInterfaceProtocol  0
>   iInterface  0
>   Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x83  EP 3 IN
> bmAttributes2
>   Transfer TypeBulk
>   Synch Type   None
>   Usage Type   Data
> wMaxPacketSize 0x0200  1x 512 bytes
> bInterval   0
>   Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x02  EP 2 OUT
> bmAttributes2
>   Transfer TypeBulk
>   Synch Type   None
>   Usage Type   Data
> wMaxPacketSize 0x0200  1x 512 bytes
> bInterval   0
> Device Qualifier (for other device speed):
>   bLength10
>   bDescriptorType 6
>   bcdUSB   2.00
>   bDeviceClass2 Communications
>   bDeviceSubClass 0
>   bDeviceProtocol 0
>   bMaxPacketSize064
>   bNumConfigurations  1
> Device Status: 0x0001
>   Self Powered
>
>
> There are a couple of oddities in the above lsusb output which I believe
> supports the proposed patch: Note the use of a "CDC Data" class
> interface for an assumed vendor specific function.  There is no
> "Communications" interface here.  And do note the three unrecognised
> descriptors.  These are obviously CDC class specific functional
> descriptors.  You have the
>
>  Header:  05 24 00 10 01
>  Call Management: 05 24 01 00 00
>  ACM: 04 24 02 02
>
>
> So this device looks very much like an ACM device, except that it is
> missing the necessary control interface and status endpoint.  And
> without a control interface there is of course no way to send a properly
> formatted CDC control request either.
>

Thanks for this analysis, it is very very interesting!

> I assume the different vendors also use the same Intel pr

Re: [PATCH 1/2] cdc_acm: Ignore Infineon Flash Loader utility

[Daniele Palmas]

Hi Johan,

2015-11-06 12:24 GMT+01:00 Johan Hovold :
> On Thu, Nov 05, 2015 at 01:57:43PM +0100, Jonas Jonsson wrote:
>> Some modems, such as the Telit UE910, are using an Infineon Flash Loader
>> utility. It has two interfaces, 2/2/0 (Abstract Modem) and 10/0/0 (CDC
>> Data). The latter can be used as a serial interface to upgrade the
>> firmware of the modem. However, that isn't possible when the cdc-acm
>> driver takes control of the device.
>
> Why can't you just use the tty device that the cdc-acm driver provides?

I have the same problem reported by Jonas.

Telit flashing procedure does not work with the cdc-acm driver.

Moreover, the device 0x058b/0x0041 is in itself a flashing device, so
/* Infineon Flashloader driver */ section of usb-serial-simple seems a
good place for it.

Since the procedure is working properly with only bulk endpoints I suspect
that on the firmware side the definition of the device is not correct.

Best regards,
Daniele

>
> Thanks,
> Johan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] USB: serial: Another Infineon flash loader USB ID

[Daniele Palmas]

Hi Jonas,

2015-11-05 13:57 GMT+01:00 Jonas Jonsson <jo...@ludd.ltu.se>:
> This has been seen on a Telit UE910 modem.
>
> Signed-off-by: Jonas Jonsson <jo...@ludd.ltu.se>
> ---
>  drivers/usb/serial/usb-serial-simple.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/serial/usb-serial-simple.c 
> b/drivers/usb/serial/usb-serial-simple.c
> index 3658662..93ab784 100644
> --- a/drivers/usb/serial/usb-serial-simple.c
> +++ b/drivers/usb/serial/usb-serial-simple.c
> @@ -53,7 +53,9 @@ DEVICE(funsoft, FUNSOFT_IDS);
>
>  /* Infineon Flashloader driver */
>  #define FLASHLOADER_IDS()  \
> -   { USB_DEVICE(0x8087, 0x0716) }
> +   { USB_DEVICE(0x8087, 0x0716) }, \
> +   { USB_DEVICE_INTERFACE_CLASS(0x058b, 0x0041, 0x0a) }
> +
>  DEVICE(flashloader, FLASHLOADER_IDS);
>
>  /* Google Serial USB SubClass */
> --
> 2.5.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


This and the previous patch are fine to me for all Telit devices based
on 3G IMC chipset with Telit proprietary flashing protocol.

I'm wondering if this is fine for all other non-Telit devices based on
the same chipset, but a different protocol...

Anyway, if you wish you can add my

Tested-by: Daniele Palmas <dnl...@gmail.com>

Regards,
Daniele
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Reg : USB modeswitch details LE920 Module

[Daniele Palmas]

Hi Arulpandiyan,

2015-03-03 13:05 GMT+01:00 Arul pandiyan arulcse2...@gmail.com:

 Hi Vaibhav

 We are using Telit LE920 module for 3G/LTE support in our module. Our 
 configuration is as follows,
 Processor- imx6 -Q7
 Operating system- Jelly Bean
 Kernel Version - 3.0.35
 We have found that our module id is detected as 1201. we have updated the 
 same in option.c and it is detecting as storage device.

 I came to know from internet, i should get the interface like wwan0 once i 
 done the usb_modeswitch, but the problem is, We are not aware about the 
 target_device list and usb_mode_switch.conf details.
 Could you please help us to configure this module.

 DefaultVendor= 0x1bc7
 DefaultProduct=0x:1201

 TargetVendor=0x1bc7
 TargetProductList=

 CheckSuccess=20

 MessageEndpoint= 0x01
 MessageContent=55534243123456780011062001

 Note :
   a)  It does create the /dev/ttyUSB0 - /dev/ttyUSB4 devices in the virtual 
 filesystem.
   b)  I have added the patch 03eb466f276ceef9dcf023dc5474db02af68aad9I, 
 Should i do anything apart from this patch to bring up Telit LE920 module



There should be no need to use usb_modeswitch: attached you can find LE920
0x1201 PID default composition.

USB serial ports support in option is present since official kernel
version 3.18.

QMI network adapter support in qmi_wwan is present since official kernel
version 3.13.

Please note: it is useful to contact the modem vendor for this kind of issues
especially if you use old kernel versions such as 3.0.35.

Also please remember to keep cc'ed the USB mailing list.

Regards,
Daniele
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Reg : USB modeswitch details LE920 Module

[Daniele Palmas]

Hi Arulpandiyan,

2015-03-02 18:42 GMT+01:00 Arulpandiyan Vadivel
arulpandiyan.vadi...@aricent.com:
 Hi Daniele  Greg,

snip

 Regards,
 Arulpandiyan Vadivel.
 DISCLAIMER: This message is proprietary to Aricent and is intended solely
 for the use of the individual to whom it is addressed. It may contain
 privileged or confidential information and should not be circulated or used
 for any purpose other than for what it is intended. If you have received
 this message in error, please notify the originator immediately. If you are
 not the intended recipient, you are notified that you are strictly
 prohibited from using, copying, altering, or disclosing the contents of this
 message. Aricent accepts no responsibility for loss or damage arising from
 the use of the information transmitted by this email including damage from
 virus.

I really wanted to answer your question, but due to this disclaimer I
am not able to
answer.

Please resend your mail to the list without this disclaimer.

Regards,
Daniele
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/1] usb: option: add support for Telit LE910

[Daniele Palmas]

Hi Johan,

2014-10-14 10:03 GMT+02:00 Johan Hovold jo...@kernel.org:
 On Tue, Oct 14, 2014 at 08:47:09AM +0200, Daniele Palmas wrote:
 option driver, added VID/PID for Telit LE910 modem. Interfaces description
 is almost the same than LE920, except that the qmi interface is number 2
 (instead than 5).

 Signed-off-by: Daniele Palmas dnl...@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 d1a3f60..0ed7626 100644
 --- a/drivers/usb/serial/option.c
 +++ b/drivers/usb/serial/option.c
 @@ -269,6 +269,7 @@ static void option_instat_callback(struct urb *urb);
  #define TELIT_PRODUCT_DE910_DUAL 0x1010
  #define TELIT_PRODUCT_UE910_V2   0x1012
  #define TELIT_PRODUCT_LE920  0x1200
 +#define TELIT_PRODUCT_LE910  0x1201

  /* ZTE PRODUCTS */
  #define ZTE_VENDOR_ID0x19d2
 @@ -594,6 +595,11 @@ static const struct option_blacklist_info 
 telit_le920_blacklist = {
   .reserved = BIT(1) | BIT(5),
  };

 +static const struct option_blacklist_info telit_le910_blacklist = {
 + .sendsetup = BIT(0),
 + .reserved = BIT(1) | BIT(2),
 +};
 +
  static const struct usb_device_id option_ids[] = {
   { USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_COLT) },
   { USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_RICOLA) },
 @@ -1140,6 +1146,8 @@ static const struct usb_device_id option_ids[] = {
   { USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_UE910_V2) },
   { USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_LE920),
   .driver_info = (kernel_ulong_t)telit_le920_blacklist },
 + { USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_LE910),
 + .driver_info = (kernel_ulong_t)telit_le910_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 },

 Looks good, but could you keep the blacklist info and device_id entries
 above sorted alphabetically? (The defines should be sorted by PID so no
 need to change that.)


Thanks for the review. I sent a V2 patch to address your remarks.

Regards,
Daniele

 Thanks,
 Johan
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/1] usb: option: add support for Telit LE910

[Daniele Palmas]

option driver, added VID/PID for Telit LE910 modem. Interfaces description
is almost the same than LE920, except that the qmi interface is number 2
(instead than 5).

Signed-off-by: Daniele Palmas dnl...@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 d1a3f60..0ed7626 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -269,6 +269,7 @@ static void option_instat_callback(struct urb *urb);
 #define TELIT_PRODUCT_DE910_DUAL   0x1010
 #define TELIT_PRODUCT_UE910_V2 0x1012
 #define TELIT_PRODUCT_LE9200x1200
+#define TELIT_PRODUCT_LE9100x1201
 
 /* ZTE PRODUCTS */
 #define ZTE_VENDOR_ID  0x19d2
@@ -594,6 +595,11 @@ static const struct option_blacklist_info 
telit_le920_blacklist = {
.reserved = BIT(1) | BIT(5),
 };
 
+static const struct option_blacklist_info telit_le910_blacklist = {
+   .sendsetup = BIT(0),
+   .reserved = BIT(1) | BIT(2),
+};
+
 static const struct usb_device_id option_ids[] = {
{ USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_COLT) },
{ USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_RICOLA) },
@@ -1140,6 +1146,8 @@ static const struct usb_device_id option_ids[] = {
{ USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_UE910_V2) },
{ USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_LE920),
.driver_info = (kernel_ulong_t)telit_le920_blacklist },
+   { USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_LE910),
+   .driver_info = (kernel_ulong_t)telit_le910_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.5.4

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 1/1] usb: option: add support for Telit LE910

[Daniele Palmas]

option driver, added VID/PID for Telit LE910 modem. Interfaces description
is almost the same than LE920, except that the qmi interface is number 2
(instead than 5).

Signed-off-by: Daniele Palmas dnl...@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 d1a3f60..19280a3 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -269,6 +269,7 @@ static void option_instat_callback(struct urb *urb);
 #define TELIT_PRODUCT_DE910_DUAL   0x1010
 #define TELIT_PRODUCT_UE910_V2 0x1012
 #define TELIT_PRODUCT_LE9200x1200
+#define TELIT_PRODUCT_LE9100x1201
 
 /* ZTE PRODUCTS */
 #define ZTE_VENDOR_ID  0x19d2
@@ -589,6 +590,11 @@ static const struct option_blacklist_info 
zte_1255_blacklist = {
.reserved = BIT(3) | BIT(4),
 };
 
+static const struct option_blacklist_info telit_le910_blacklist = {
+   .sendsetup = BIT(0),
+   .reserved = BIT(1) | BIT(2),
+};
+
 static const struct option_blacklist_info telit_le920_blacklist = {
.sendsetup = BIT(0),
.reserved = BIT(1) | BIT(5),
@@ -1138,6 +1144,8 @@ static const struct usb_device_id option_ids[] = {
{ 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_UE910_V2) },
+   { USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_LE910),
+   .driver_info = (kernel_ulong_t)telit_le910_blacklist },
{ 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 */
-- 
1.7.5.4

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 1/1] usb: option driver, add support for Telit UE910v2

[Daniele Palmas]

option driver, added VID/PID for Telit UE910v2 modem

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

diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 68fc9fe..367c7f0 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -243,6 +243,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_UE910_V2 0x1012
 #define TELIT_PRODUCT_LE9200x1200
 
 /* ZTE PRODUCTS */
@@ -1041,6 +1042,7 @@ 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_UE910_V2) },
{ 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 */
-- 
1.7.5.4

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/1] usb: option driver, add support for Telit UE910v2

[Daniele Palmas]

Hello Johan,

2014-03-31 10:58 GMT+02:00 Johan Hovold jhov...@gmail.com:
 On Fri, Mar 28, 2014 at 05:08:56PM +0100, Daniele Palmas wrote:
 option driver, added VID/PID for Telit UE910v2 modem

 Thanks for the patch.

 Could you also include the output of lsusb -vd 1bc7:1012 for reference?


Bus 002 Device 004: ID 1bc7:1012
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize064
  idVendor   0x1bc7
  idProduct  0x1012
  bcdDevice0.00
  iManufacturer   3 Telit Wireless Solutions
  iProduct2 Telit HS-USB Modem
  iSerial 0
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   92
bNumInterfaces  3
bConfigurationValue 1
iConfiguration  1 Telit Configuration
bmAttributes 0xe0
  Self Powered
  Remote Wakeup
MaxPower  500mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass255 Vendor Specific Subclass
  bInterfaceProtocol255 Vendor Specific Protocol
  iInterface  0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval  32
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01  EP 1 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval  32
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber1
  bAlternateSetting   0
  bNumEndpoints   3
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass255 Vendor Specific Subclass
  bInterfaceProtocol255 Vendor Specific Protocol
  iInterface  0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82  EP 2 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   5
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83  EP 3 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval  32
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02  EP 2 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval  32
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber2
  bAlternateSetting   0
  bNumEndpoints   3
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass255 Vendor Specific Subclass
  bInterfaceProtocol255 Vendor Specific Protocol
  iInterface  0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84  EP 4 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   5
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x85  EP 5 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval  32
  Endpoint Descriptor:
bLength 7

[PATCH 1/1] usb: option driver, add support for Telit UE910v2

[Daniele Palmas]

option driver, added VID/PID for Telit UE910v2 modem

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

diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 68fc9fe..8811a5b 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -244,6 +244,7 @@ static void option_instat_callback(struct urb *urb);
 #define TELIT_PRODUCT_CC864_SINGLE 0x1006
 #define TELIT_PRODUCT_DE910_DUAL   0x1010
 #define TELIT_PRODUCT_LE9200x1200
+#define TELIT_PRODUCT_UE910_V2 0x1012
 
 /* ZTE PRODUCTS */
 #define ZTE_VENDOR_ID  0x19d2
@@ -1043,6 +1044,7 @@ static const struct usb_device_id option_ids[] = {
{ 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(TELIT_VENDOR_ID, TELIT_PRODUCT_UE910_V2) },
{ 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.5.4

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: cdc_acm buffer allocation out of memory

[Daniele Palmas]

Hello,

2013/4/22 Jan Pohanka xhpoha...@gmail.com:
 Dear all,

 I'm getting following message from cdc_acm driver when plugging in my
 GSM module on Amlogic 8726-MXS platform (kernel v3.0.8):

 cdc_acm 1-1:1.4: ttyACM2: USB ACM device
 [ 26.730474@0] cdc_acm 1-1:1.6: This device cannot do calls on its
 own. It is not a modem.
 [ 26.733206@0] cdc_acm 1-1:1.6: out of memory (write buffer alloc)
 [ 26.740307@0] cdc_acm: probe of 1-1:1.6 failed with error -12

 acm_write_buffers_alloc() function calls hcd_buffer_alloc() which
 allocates coherent memory for DMA transfers through dma_pool_alloc or
 dma_alloc_coherent.
 Can please someone give me an advice where is the memory available for
 these allocations defined?

If I am not wrong you should take a look at the define CONSISTENT_DMA_SIZE.

Regards,
Daniele
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@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]

2013/1/30 Bjørn Mork bj...@mork.no:
 Daniele Palmas dnl...@gmail.com writes:

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

 Interface Descriptor:
   bLength 9
   bDescriptorType 4
   bInterfaceNumber1
   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=421p_ac=showp=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
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] NET: qmi_wwan: add Telit LE920 support

[Daniele Palmas]

Add VID, PID and fixed interface for Telit LE920

Signed-off-by: Daniele Palmas dnl...@gmail.com
---
v2:
 - rebased against net tree

 drivers/net/usb/qmi_wwan.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 575a583..2ca7f8e 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -461,6 +461,7 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x1199, 0x901c, 8)},/* Sierra Wireless EM7700 */
{QMI_FIXED_INTF(0x1bbb, 0x011e, 4)},/* Telekom Speedstick LTE II 
(Alcatel One Touch L100V LTE) */
{QMI_FIXED_INTF(0x2357, 0x0201, 4)},/* TP-LINK HSUPA Modem MA180 */
+   {QMI_FIXED_INTF(0x1bc7, 0x1200, 5)},/* Telit LE920 */
 
/* 4. Gobi 1000 devices */
{QMI_GOBI1K_DEVICE(0x05c6, 0x9212)},/* Acer Gobi Modem Device */
-- 
1.7.4.1

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/1] NET: qmi_wwan: add Telit LE920 support

[Daniele Palmas]

Hello,

2013/1/28 Bjørn Mork bj...@mork.no:
 Daniele Palmas dnl...@gmail.com writes:

 Add VID, PID and fixed interface for Telit LE920

 Signed-off-by: Daniele Palmas dnl...@gmail.com
 ---
  drivers/net/usb/qmi_wwan.c |1 +
  1 files changed, 1 insertions(+), 0 deletions(-)

 diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
 index 6a1ca50..e32f9a1 100644
 --- a/drivers/net/usb/qmi_wwan.c
 +++ b/drivers/net/usb/qmi_wwan.c
 @@ -459,6 +459,7 @@ static const struct usb_device_id products[] = {
   {QMI_FIXED_INTF(0x1199, 0x68a2, 19)},   /* Sierra Wireless MC7710 in 
 QMI mode */
   {QMI_FIXED_INTF(0x1199, 0x901c, 8)},/* Sierra Wireless EM7700 */
   {QMI_FIXED_INTF(0x1bbb, 0x011e, 4)},/* Telekom Speedstick LTE II 
 (Alcatel One Touch L100V LTE) */
 + {QMI_FIXED_INTF(0x1bc7, 0x1200, 5)},/* Telit LE920 */

   /* 4. Gobi 1000 devices */
   {QMI_GOBI1K_DEVICE(0x05c6, 0x9212)},/* Acer Gobi Modem Device */

 Thanks for adding this device. But the patch doesn't apply to the
 current net tree.  Care to rebase it?


Sure. Should I use the following git repository

git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/net-next.git

?

Thanks,
Daniele
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@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 bj...@mork.no:
 Dan Williams d...@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
  bInterfaceNumber1
  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
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/1] USB: qcserial: add Telit Gobi QDL device

[Daniele Palmas]

Add VID and PID for Telit Gobi QDL device

Signed-off-by: Daniele Palmas dnl...@gmail.com
---
 drivers/usb/serial/qcserial.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
index aa148c2..2466254 100644
--- a/drivers/usb/serial/qcserial.c
+++ b/drivers/usb/serial/qcserial.c
@@ -53,6 +53,7 @@ static const struct usb_device_id id_table[] = {
{DEVICE_G1K(0x05c6, 0x9221)},   /* Generic Gobi QDL device */
{DEVICE_G1K(0x05c6, 0x9231)},   /* Generic Gobi QDL device */
{DEVICE_G1K(0x1f45, 0x0001)},   /* Unknown Gobi QDL device */
+   {DEVICE_G1K(0x1bc7, 0x900e)},   /* Telit Gobi QDL device */
 
/* Gobi 2000 devices */
{USB_DEVICE(0x1410, 0xa010)},   /* Novatel Gobi 2000 QDL device */
-- 
1.7.4.1

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[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 dnl...@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_LE9200x1200
 
 /* 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

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/1] NET: qmi_wwan: add Telit LE920 support

[Daniele Palmas]

Add VID, PID and fixed interface for Telit LE920

Signed-off-by: Daniele Palmas dnl...@gmail.com
---
 drivers/net/usb/qmi_wwan.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 6a1ca50..e32f9a1 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -459,6 +459,7 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x1199, 0x68a2, 19)},   /* Sierra Wireless MC7710 in 
QMI mode */
{QMI_FIXED_INTF(0x1199, 0x901c, 8)},/* Sierra Wireless EM7700 */
{QMI_FIXED_INTF(0x1bbb, 0x011e, 4)},/* Telekom Speedstick LTE II 
(Alcatel One Touch L100V LTE) */
+   {QMI_FIXED_INTF(0x1bc7, 0x1200, 5)},/* Telit LE920 */
 
/* 4. Gobi 1000 devices */
{QMI_GOBI1K_DEVICE(0x05c6, 0x9212)},/* Acer Gobi Modem Device */
-- 
1.7.4.1

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

cdc-acm and remote wakeup

[Daniele Palmas]

Hello,

I'm using the modem Telit HE910 with cdc-acm driver.

I've found that after a suspend and resume of the operating system
(e.g. pm-suspend), the modem does not answer anymore.

Collecting logs with an usb sniffer, it seems that, unlike the Windows
driver, the host does not send the packet SET_FEATURE DEVICE_REMOTE
WAKEUP, needed by the modem.

I've added few lines of code (in the acm_suspend function) for sending
this packet and now things work.

According to the USB 2.0 specs it seems to me that this feature should
be always requested when suspending a device, so probably the driver
behavior is not correct.

Does cdc-acm really not support this feature or am I missing some
configuration parameters that enable the sending of this request?

Thanks,
Daniele
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: cdc-acm and remote wakeup

[Daniele Palmas]

Hello Oliver,

2012/11/26 Oliver Neukum oneu...@suse.de:
 On Monday 26 November 2012 10:42:48 Daniele Palmas wrote:
 Hello,

 I'm using the modem Telit HE910 with cdc-acm driver.

 I've found that after a suspend and resume of the operating system
 (e.g. pm-suspend), the modem does not answer anymore.

 Collecting logs with an usb sniffer, it seems that, unlike the Windows
 driver, the host does not send the packet SET_FEATURE DEVICE_REMOTE
 WAKEUP, needed by the modem.

 This is a new quirk.


Ok.

 I've added few lines of code (in the acm_suspend function) for sending
 this packet and now things work.

 acm_suspend is definitely not the place to put this, even if it fixes
 your particular usage.


Ok. Do you have any hint for adding the code in the proper place?

 According to the USB 2.0 specs it seems to me that this feature should
 be always requested when suspending a device, so probably the driver
 behavior is not correct.

 Hm. Which part of the spec do you base this on?


The doc is Universal Serial Bus Specification revision 2.0 paragraph
10.5.4.5, if I am not misunderstanding the topic.

Here

http://msdn.microsoft.com/en-us/library/windows/hardware/ff537628%28v=vs.85%29.aspx

there is an interpretation coming from Microsoft

In USB terminology, a USB device is enabled for remote wakeup when
its DEVICE_REMOTE_WAKEUP feature is set. The USB specification
specifies that host software must set the remote wakeup feature on a
device only just prior to putting the device to sleep.

 Does cdc-acm really not support this feature or am I missing some
 configuration parameters that enable the sending of this request?

 For a modem this feature makes relatively little sense. I've never
 seen a modem that doesn't hang up when you suspend it.

Maybe I have to explain better my scenario:

Modem is registered to the network. Host suspended, I want my device
to wake up the host when it receives, for example, a call or an sms.

This doesn't happen if the driver doesn't send the
DEVICE_REMOTE_WAKEUP request. Moreover without this request the modem
is bricked.

I understand that probably there are problems in the firmware of the
modem (because it should not brick), but I'm trying to find a
workaround to have things working.


 Regards
 Oliver


Thanks,
Daniele
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: cdc-acm and remote wakeup

[Daniele Palmas]

2012/11/26 Oliver Neukum oneu...@suse.de:
 On Monday 26 November 2012 13:29:09 Daniele Palmas wrote:

 Ok. Do you have any hint for adding the code in the proper place?

 First we need to define a new quirk.

  According to the USB 2.0 specs it seems to me that this feature should
  be always requested when suspending a device, so probably the driver
  behavior is not correct.
 
  Hm. Which part of the spec do you base this on?
 

 The doc is Universal Serial Bus Specification revision 2.0 paragraph
 10.5.4.5, if I am not misunderstanding the topic.

 Here

 http://msdn.microsoft.com/en-us/library/windows/hardware/ff537628%28v=vs.85%29.aspx

 there is an interpretation coming from Microsoft

 In USB terminology, a USB device is enabled for remote wakeup when
 its DEVICE_REMOTE_WAKEUP feature is set. The USB specification
 specifies that host software must set the remote wakeup feature on a
 device only just prior to putting the device to sleep.

 Well, that tells us when to set DEVICE_REMOTE_WAKEUP, if we want remote
 wakeup, not whether we want it at all.


I see the point: to me having the device able to remote wakeup the
system was a direct consequence of going into suspend state, but
probably this is not the desired behaviour for all the situations.

Aside the specific quirk of my modem, at the moment is there the
possibility to tell the driver (or the usb stack) if we want this
request to be sent or not?

 Modem is registered to the network. Host suspended, I want my device
 to wake up the host when it receives, for example, a call or an sms.

 If you want a device to wake up the system, you need to declare it
 a wakeup source in sysfs.

 This doesn't happen if the driver doesn't send the
 DEVICE_REMOTE_WAKEUP request. Moreover without this request the modem
 is bricked.

 That is not good.


So is it not enough to put enabled in the correct device of
/proc/acpi/wakeup ?

 I understand that probably there are problems in the firmware of the
 modem (because it should not brick), but I'm trying to find a
 workaround to have things working.

 I am attaching a patch to introduce a new quirk type. You need to add
 your device to the list of quirky devices in drivers/usb/core/quirks.c
 with the new quirk type.
 You cannot solve this in the cdc-acm driver because there is an
 unsolvable race if your system is suspended after the device is enumerated
 but before the driver is loaded.

 Would you test this?


Thanks for you patch, I will try it as soon as possible.

Regards,
Daniele
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: cdc-acm and remote wakeup

[Daniele Palmas]

Hello Alan,

2012/11/26 Alan Stern st...@rowland.harvard.edu:
 On Mon, 26 Nov 2012, Daniele Palmas wrote:

 Maybe I have to explain better my scenario:

 Modem is registered to the network. Host suspended, I want my device
 to wake up the host when it receives, for example, a call or an sms.

 What if the modem isn't registered to the network?  For example, if the
 cdc-acm driver is unloaded.  Does it need remote wakeup to be enabled
 then?


That is a good question: in my specific scenario it is not useful to
have the remote wakeup enabled if the cdc-acm driver is unloaded. But,
though at the moment I cannot identify any, maybe there are situations
in which it is useful to have the remote wakeup enabled even if the
driver is not loaded.

 This doesn't happen if the driver doesn't send the
 DEVICE_REMOTE_WAKEUP request. Moreover without this request the modem
 is bricked.

 Are you sure that bricked is the right word?  It means that the
 modem's firmware got corrupted so that it is impossible ever to use the
 modem again unless an EPROM chip is replaced.  Maybe you just meant
 that the modem crashed.


You are right, sorry for my poor English... The modem is crashed, but
after the device reset it still works.

Regards,
Daniele
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: cdc-acm and remote wakeup

[Daniele Palmas]

2012/11/26 Alan Stern st...@rowland.harvard.edu:
 On Mon, 26 Nov 2012, Daniele Palmas wrote:

  What if the modem isn't registered to the network?  For example, if the
  cdc-acm driver is unloaded.  Does it need remote wakeup to be enabled
  then?
 

 That is a good question: in my specific scenario it is not useful to
 have the remote wakeup enabled if the cdc-acm driver is unloaded. But,
 though at the moment I cannot identify any, maybe there are situations
 in which it is useful to have the remote wakeup enabled even if the
 driver is not loaded.

 Without a driver, and without being registered with the network, I
 don't see how the modem could ever send a wakeup request in the first
 place.

 Still, this is an important consideration.  It means that remote wakeup
 doesn't need to be enabled when the driver isn't present.  Which means
 that the cdc-acm driver is indeed the right place to fix this problem
 -- although the way you did it isn't the right way.  The right way is
 to have cdc-acm turn on the needs_remote_wakeup flag in the
 usb_interface structure.

Ok, I'll try to take a look at that.

 And by the way, /proc/acpi/wakeup is deprecated.  To allow the modem to
 wake up the system, you should do:

 echo enabled /sys/bus/usb/devices/.../power/wakeup

 where the ... part is filled in with the device name corresponding to
 the modem.


Thanks for the tip.

Regards,
Daniele
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html