[PATCH] USB: option: add support for DW5821e

[Aleksander Morgado]

The device exposes AT, NMEA and DIAG ports in both USB configurations.

The patch explicitly ignores interfaces 0 and 1, as they're bound to
other drivers already; and also interface 6, which is a GNSS interface
for which we don't have a driver yet.

T:  Bus=01 Lev=03 Prnt=04 Port=00 Cnt=01 Dev#= 18 Spd=480 MxCh= 0
D:  Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  2
P:  Vendor=413c ProdID=81d7 Rev=03.18
S:  Manufacturer=DELL
S:  Product=DW5821e Snapdragon X20 LTE
S:  SerialNumber=0123456789ABCDEF
C:  #Ifs= 7 Cfg#= 2 Atr=a0 MxPwr=500mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim
I:  If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I:  If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I:  If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I:  If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I:  If#= 6 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)

T:  Bus=01 Lev=03 Prnt=04 Port=00 Cnt=01 Dev#= 16 Spd=480 MxCh= 0
D:  Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  2
P:  Vendor=413c ProdID=81d7 Rev=03.18
S:  Manufacturer=DELL
S:  Product=DW5821e Snapdragon X20 LTE
S:  SerialNumber=0123456789ABCDEF
C:  #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA
I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
I:  If#= 1 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=00 Prot=00 Driver=usbhid
I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I:  If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I:  If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I:  If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option

Signed-off-by: Aleksander Morgado 
Cc: stable 
---
 drivers/usb/serial/option.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 664e61f16b6a..0215b70c4efc 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -196,6 +196,8 @@ static void option_instat_callback(struct urb *urb);
 #define DELL_PRODUCT_5800_V2_MINICARD_VZW  0x8196  /* Novatel E362 */
 #define DELL_PRODUCT_5804_MINICARD_ATT 0x819b  /* Novatel E371 */
 
+#define DELL_PRODUCT_5821E 0x81d7
+
 #define KYOCERA_VENDOR_ID  0x0c88
 #define KYOCERA_PRODUCT_KPC650 0x17da
 #define KYOCERA_PRODUCT_KPC680 0x180a
@@ -1030,6 +1032,8 @@ static const struct usb_device_id option_ids[] = {
{ USB_DEVICE_AND_INTERFACE_INFO(DELL_VENDOR_ID, 
DELL_PRODUCT_5800_MINICARD_VZW, 0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(DELL_VENDOR_ID, 
DELL_PRODUCT_5800_V2_MINICARD_VZW, 0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(DELL_VENDOR_ID, 
DELL_PRODUCT_5804_MINICARD_ATT, 0xff, 0xff, 0xff) },
+   { USB_DEVICE(DELL_VENDOR_ID, DELL_PRODUCT_5821E),
+ .driver_info = RSVD(0) | RSVD(1) | RSVD(6) },
{ USB_DEVICE(ANYDATA_VENDOR_ID, ANYDATA_PRODUCT_ADU_E100A) },   /* 
ADU-E100, ADU-310 */
{ USB_DEVICE(ANYDATA_VENDOR_ID, ANYDATA_PRODUCT_ADU_500A) },
{ USB_DEVICE(ANYDATA_VENDOR_ID, ANYDATA_PRODUCT_ADU_620UW) },
-- 
2.18.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

Re: [PATCH] usb: serial: qcserial: add support for the Dell DW5821e module

[Aleksander Morgado]

>> I believe Aleksander might be referring to usb_choose_configuration() in
>> drivers/usb/core/generic.c?  It does some confusing things with
>> multi-function/multi-configuration devices, explained by this comment:
>>
>>   /* From the remaining configs, choose the first one whose
>>* first interface is for a non-vendor-specific class.
>>* Reason: Linux is more likely to have a class driver
>>* than a vendor-specific driver. */
>>
>>
>> This code can make Linux default to a MBIM configuration if the MBIM
>> function uses the first interface in that configuration, even if this
>> configuration is not the first one. Availability of a driver is not
>> considered. Except for RNDIS, just to make it the whole mess even more
>> confusing
>
> Ah, that may be the case. Aleksander, would you mind updating the commit
> message and drop the cdc_mbim driver bit?
>

Yes, will do that.

I was actually completely mixing up this logic in the kernel with the
logic in usb_modeswitch indeed, as Bjørn pointed out.

-- 
Aleksander
https://aleksander.es
--
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] usb: serial: qcserial: add support for the Dell DW5821e module

[Aleksander Morgado]

>>
>> This would be when running on configuration #1:
>>
>> T:  Bus=04 Lev=03 Prnt=04 Port=02 Cnt=01 Dev#=  7 Spd=5000 MxCh= 0
>> D:  Ver= 3.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs=  2
>> P:  Vendor=413c ProdID=81d7 Rev=03.18
>> S:  Manufacturer=DELL
>> S:  Product=DW5821e Snapdragon X20 LTE
>> S:  SerialNumber=0123456789ABCDEF
>> C:  #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=896mA
>> I:  If#=0x0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=qcserial
>> I:  If#=0x1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
>> I:  If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=qcserial
>> I:  If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=qcserial
>> I:  If#=0x4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
>
> So this doesn't really match the Sierra layout in qcserial, where the
> QMI interface is documented as interface 8 (but perhaps we have other
> examples of that already).
>
> Do you know what these serial ports are used for?
>

You know what, I kind of missed that. This Dell device is not based on
Sierra Wireless, so using the Sierra layout is not a good idea. Let me
try to confirm with the manufacturer the purpose of each interface.

>> This would be when running on configuration #2:
>>
>> T:  Bus=04 Lev=03 Prnt=04 Port=02 Cnt=01 Dev#=  6 Spd=5000 MxCh= 0
>> D:  Ver= 3.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs=  2
>> P:  Vendor=413c ProdID=81d7 Rev=03.18
>> S:  Manufacturer=DELL
>> S:  Product=DW5821e Snapdragon X20 LTE
>> S:  SerialNumber=0123456789ABCDEF
>> C:  #Ifs= 3 Cfg#= 2 Atr=a0 MxPwr=896mA
>> I:  If#=0x0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim
>> I:  If#=0x1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
>> I:  If#=0x2 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=ff Driver=qcserial
>
> And here you happen to bind interface 2, but is that intentional? What
> is that port used for?
>

Same here; looks like interface was bound to qcserial by chance,
because that is what the sierra layout would have done in the QMI
capable configuration. Again, let me try to confirm what that other
interface may be for.

> Just based on the above, perhaps using option and matching on the vendor
> class, while blacklisting interface 1 would be more appropriate?
>

Being a Qualcomm based chipset, I believe qcserial would be more appropriate.
I'll send an updated patch, including usb-devices output, once I have
an explanation for all questions.

-- 
Aleksander
https://aleksander.es
--
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] usb: serial: qcserial: add support for the Dell DW5821e module

[Aleksander Morgado]

On Tue, Jun 26, 2018 at 8:09 AM, Johan Hovold  wrote:
> On Sat, Jun 23, 2018 at 11:24:08PM +0200, Aleksander Morgado wrote:
>> This module exposes two USB configurations: a QMI+AT capable setup on
>> USB config #1 and a MBIM capable setup on USB config #2.
>>
>> By default the kernel will choose the MBIM capable configuration as
>> long as the cdc_mbim driver is available. This patch adds support for
>> the serial ports in the secondary configuration.
>
> Could you please post the usb-devices output for this device?
>
> Depending on another driver to select a specific configuration seems
> fragile (and that behaviour is even configurable).
>

This would be when running on configuration #1:

T:  Bus=04 Lev=03 Prnt=04 Port=02 Cnt=01 Dev#=  7 Spd=5000 MxCh= 0
D:  Ver= 3.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs=  2
P:  Vendor=413c ProdID=81d7 Rev=03.18
S:  Manufacturer=DELL
S:  Product=DW5821e Snapdragon X20 LTE
S:  SerialNumber=0123456789ABCDEF
C:  #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=896mA
I:  If#=0x0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=qcserial
I:  If#=0x1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
I:  If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=qcserial
I:  If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=qcserial
I:  If#=0x4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)

This would be when running on configuration #2:

T:  Bus=04 Lev=03 Prnt=04 Port=02 Cnt=01 Dev#=  6 Spd=5000 MxCh= 0
D:  Ver= 3.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs=  2
P:  Vendor=413c ProdID=81d7 Rev=03.18
S:  Manufacturer=DELL
S:  Product=DW5821e Snapdragon X20 LTE
S:  SerialNumber=0123456789ABCDEF
C:  #Ifs= 3 Cfg#= 2 Atr=a0 MxPwr=896mA
I:  If#=0x0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim
I:  If#=0x1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
I:  If#=0x2 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=ff Driver=qcserial



-- 
Aleksander
https://aleksander.es
--
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] usb: serial: qcserial: add support for the Dell DW5821e module

[Aleksander Morgado]

This module exposes two USB configurations: a QMI+AT capable setup on
USB config #1 and a MBIM capable setup on USB config #2.

By default the kernel will choose the MBIM capable configuration as
long as the cdc_mbim driver is available. This patch adds support for
the serial ports in the secondary configuration.

Signed-off-by: Aleksander Morgado 
---
 drivers/usb/serial/qcserial.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
index 613f91add03d..ed109c86e747 100644
--- a/drivers/usb/serial/qcserial.c
+++ b/drivers/usb/serial/qcserial.c
@@ -177,6 +177,7 @@ static const struct usb_device_id id_table[] = {
{DEVICE_SWI(0x413c, 0x81d0)},   /* Dell Wireless 5819 */
{DEVICE_SWI(0x413c, 0x81d1)},   /* Dell Wireless 5818 */
{DEVICE_SWI(0x413c, 0x81d2)},   /* Dell Wireless 5818 */
+   {DEVICE_SWI(0x413c, 0x81d7)},   /* Dell Wireless 5821e */
 
/* Huawei devices */
{DEVICE_HWI(0x03f0, 0x581d)},   /* HP lt4112 LTE/HSPA+ Gobi 4G Modem 
(Huawei me906e) */
-- 
2.17.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] cdc_ether: flag the Huawei ME906/ME909 as WWAN

[Aleksander Morgado]

The Huawei ME906 (12d1:15c1) comes with a standard ECM interface that
requires management via AT commands sent over one of the control TTYs
(e.g. connected with AT^NDISDUP).

Signed-off-by: Aleksander Morgado <aleksan...@aleksander.es>
---
 drivers/net/usb/cdc_ether.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c
index 52ea80bcd639..788953afaba3 100644
--- a/drivers/net/usb/cdc_ether.c
+++ b/drivers/net/usb/cdc_ether.c
@@ -863,6 +863,12 @@ static const struct usb_device_id  products[] = {
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,
+}, {
+   /* Huawei ME906 and ME909 */
+   USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0x15c1, USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_ETHERNET,
+ USB_CDC_PROTO_NONE),
+   .driver_info = (unsigned long)_info,
 }, {
/* ZTE modules */
USB_VENDOR_AND_INTERFACE_INFO(ZTE_VENDOR_ID, USB_CLASS_COMM,
--
2.14.2
--
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] cdc_ether: flag the u-blox TOBY-L2 and SARA-U2 as wwan

[Aleksander Morgado]

The u-blox TOBY-L2 is a LTE Cat 4 module with HSPA+ and 2G fallback.
This module allows switching to different USB profiles with the
'AT+UUSBCONF' command, and provides a ECM network interface when the
'AT+UUSBCONF=2' profile is selected.

The u-blox SARA-U2 is a HSPA module with 2G fallback. The default USB
configuration includes a ECM network interface.

Both these modules are controlled via AT commands through one of the
TTYs exposed. Connecting these modules may be done just by activating
the desired PDP context with 'AT+CGACT=1,' and then running DHCP
on the ECM interface.

Signed-off-by: Aleksander Morgado <aleksan...@aleksander.es>
---
 drivers/net/usb/cdc_ether.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c
index 29c7e2ec0dcb..52ea80bcd639 100644
--- a/drivers/net/usb/cdc_ether.c
+++ b/drivers/net/usb/cdc_ether.c
@@ -560,6 +560,7 @@ static const struct driver_info wwan_info = {
 #define NVIDIA_VENDOR_ID   0x0955
 #define HP_VENDOR_ID   0x03f0
 #define MICROSOFT_VENDOR_ID0x045e
+#define UBLOX_VENDOR_ID0x1546
 
 static const struct usb_device_id  products[] = {
 /* BLACKLIST !!
@@ -868,6 +869,18 @@ static const struct usb_device_id  products[] = {
  USB_CDC_SUBCLASS_ETHERNET,
  USB_CDC_PROTO_NONE),
.driver_info = (unsigned long)_cdc_info,
+}, {
+   /* U-blox TOBY-L2 */
+   USB_DEVICE_AND_INTERFACE_INFO(UBLOX_VENDOR_ID, 0x1143, USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_ETHERNET,
+ USB_CDC_PROTO_NONE),
+   .driver_info = (unsigned long)_info,
+}, {
+   /* U-blox SARA-U2 */
+   USB_DEVICE_AND_INTERFACE_INFO(UBLOX_VENDOR_ID, 0x1104, USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_ETHERNET,
+ USB_CDC_PROTO_NONE),
+   .driver_info = (unsigned long)_info,
 }, {
USB_INTERFACE_INFO(USB_CLASS_COMM, USB_CDC_SUBCLASS_ETHERNET,
USB_CDC_PROTO_NONE),
-- 
2.14.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] rndis_host: support Novatel Verizon USB730L

[Aleksander Morgado]

Treat the ef/04/01 interface class/subclass/protocol combination used
by the Novatel Verizon USB730L (1410:9030) as a possible RNDIS
interface.

 T:  Bus=01 Lev=02 Prnt=02 Port=01 Cnt=02 Dev#= 17 Spd=480 MxCh= 0
 D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  3
 P:  Vendor=1410 ProdID=9030 Rev=03.10
 S:  Manufacturer=Novatel Wireless
 S:  Product=MiFi USB730L
 S:  SerialNumber=0123456789ABCDEF
 C:  #Ifs= 3 Cfg#= 1 Atr=80 MxPwr=500mA
 I:  If#= 0 Alt= 0 #EPs= 1 Cls=ef(misc ) Sub=04 Prot=01 Driver=rndis_host
 I:  If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=rndis_host
 I:  If#= 2 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=00 Prot=00 Driver=usbhid

Once the network interface is brought up, the user just needs to run a
DHCP client to get IP address and routing setup.

As a side note, other Novatel Verizon USB730L models with the same
vid:pid end up exposing a standard ECM interface which doesn't require
any other kernel update to make it work.

Signed-off-by: Aleksander Morgado <aleksan...@aleksander.es>
---

Hey,

I'm not sure if binding this logic to a specific vid:pid (1410:9030) would be 
more appropriate here, or if it's ok to just bind class/subclass/protocol (as 
in the activesync case).
Let me know what you think.

---
 drivers/net/usb/cdc_ether.c  | 11 ++-
 drivers/net/usb/rndis_host.c |  4 
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c
index 8ab281b478f2..2df0bcc6d30b 100644
--- a/drivers/net/usb/cdc_ether.c
+++ b/drivers/net/usb/cdc_ether.c
@@ -54,11 +54,19 @@ static int is_wireless_rndis(struct 
usb_interface_descriptor *desc)
desc->bInterfaceProtocol == 3);
 }

+static int is_novatel_rndis(struct usb_interface_descriptor *desc)
+{
+   return (desc->bInterfaceClass == USB_CLASS_MISC &&
+   desc->bInterfaceSubClass == 4 &&
+   desc->bInterfaceProtocol == 1);
+}
+
 #else

 #define is_rndis(desc) 0
 #define is_activesync(desc)0
 #define is_wireless_rndis(desc)0
+#define is_novatel_rndis(desc) 0

 #endif

@@ -150,7 +158,8 @@ int usbnet_generic_cdc_bind(struct usbnet *dev, struct 
usb_interface *intf)
 */
rndis = (is_rndis(>cur_altsetting->desc) ||
 is_activesync(>cur_altsetting->desc) ||
-is_wireless_rndis(>cur_altsetting->desc));
+is_wireless_rndis(>cur_altsetting->desc) ||
+is_novatel_rndis(>cur_altsetting->desc));

memset(info, 0, sizeof(*info));
info->control = intf;
diff --git a/drivers/net/usb/rndis_host.c b/drivers/net/usb/rndis_host.c
index a151f267aebb..b807c91abe1d 100644
--- a/drivers/net/usb/rndis_host.c
+++ b/drivers/net/usb/rndis_host.c
@@ -632,6 +632,10 @@ static const struct usb_device_id  products [] = {
/* RNDIS for tethering */
USB_INTERFACE_INFO(USB_CLASS_WIRELESS_CONTROLLER, 1, 3),
.driver_info = (unsigned long) _info,
+}, {
+   /* Novatel Verizon USB730L */
+   USB_INTERFACE_INFO(USB_CLASS_MISC, 4, 1),
+   .driver_info = (unsigned long) _info,
 },
{ },// END
 };
--
2.14.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] cdc_ncm: flag the u-blox TOBY-L4 as wwan

[Aleksander Morgado]

The u-blox TOBY-L4 is a LTE Advanced (Cat 6) module with HSPA+ and 2G
fallback.

Unlike the TOBY-L2, this module has one single USB layout and exposes
several TTYs for control and a NCM interface for data. Connecting this
module may be done just by activating the desired PDP context with
'AT+CGACT=1,' and then running DHCP on the NCM interface.

Signed-off-by: Aleksander Morgado <aleksan...@aleksander.es>
---
 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 811b18215cae..47cab1bde065 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -1758,6 +1758,13 @@ static const struct usb_device_id cdc_devs[] = {
  .driver_info = (unsigned long)_noarp_info,
},

+   /* u-blox TOBY-L4 */
+   { USB_DEVICE_AND_INTERFACE_INFO(0x1546, 0x1010,
+   USB_CLASS_COMM,
+   USB_CDC_SUBCLASS_NCM, USB_CDC_PROTO_NONE),
+ .driver_info = (unsigned long)_info,
+   },
+
/* Generic CDC-NCM devices */
{ USB_INTERFACE_INFO(USB_CLASS_COMM,
USB_CDC_SUBCLASS_NCM, USB_CDC_PROTO_NONE),
--
2.14.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] cdc_ncm: flag the ublox TOBY-L4 as wwan

[Aleksander Morgado]

On Fri, Aug 25, 2017 at 3:22 PM, Greg KH <gre...@linuxfoundation.org> wrote:
> On Fri, Aug 25, 2017 at 02:59:46PM +0200, Aleksander Morgado wrote:
>> Signed-off-by: Aleksander Morgado <aleksan...@aleksander.es>
>> ---
>>  drivers/net/usb/cdc_ncm.c | 7 +++
>>  1 file changed, 7 insertions(+)
>
> Personally, I require patches to have changelog texts in them...

Sure, will push a v2 with more info.

-- 
Aleksander
https://aleksander.es
--
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] cdc_ncm: flag the ublox TOBY-L4 as wwan

[Aleksander Morgado]

Signed-off-by: Aleksander Morgado <aleksan...@aleksander.es>
---
 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 811b18215cae..47cab1bde065 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -1758,6 +1758,13 @@ static const struct usb_device_id cdc_devs[] = {
  .driver_info = (unsigned long)_noarp_info,
},
 
+   /* u-blox TOBY-L4 */
+   { USB_DEVICE_AND_INTERFACE_INFO(0x1546, 0x1010,
+   USB_CLASS_COMM,
+   USB_CDC_SUBCLASS_NCM, USB_CDC_PROTO_NONE),
+ .driver_info = (unsigned long)_info,
+   },
+
/* Generic CDC-NCM devices */
{ USB_INTERFACE_INFO(USB_CLASS_COMM,
USB_CDC_SUBCLASS_NCM, USB_CDC_PROTO_NONE),
-- 
2.14.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: issues with commit c1da59dad0eb ("cdc-wdm: Clear read pipeline in case of error")

[Aleksander Morgado]

Hey Bjørn,

On Thu, Apr 20, 2017 at 10:32 AM, Bjørn Mork  wrote:
> Sorry for being much too late here, but during recent attemts to debug
> issues caused by my commit 833415a3e781 ("cdc-wdm: fix "out-of-sync" due
> to missing notifications") I believe I found a couple of issues with
> commit c1da59dad0eb. At least one of them is serious (potentional
> GPF_KERNEL allocation in interrupt context).
>
> But I don't know if I understand the problem the commit set out to
> solves, which is why I have no proposed patch here.

Just to be clear, the issues found with both commits are completely
unrelated one from the other, right?

-- 
Aleksander
https://aleksander.es
--
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] drivers: net: usb: qmi_wwan: add QMI_QUIRK_SET_DTR for Telit PID 0x1201

[Aleksander Morgado]

On Wed, Apr 19, 2017 at 7:28 PM, Bjørn Mork  wrote:
>> 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?

Reliably, as in the second command I sent already showed the issue :/
I meant to try to debug this issue myself a while ago, but got busy
with other stuff, as usual... This is with a Sierra Wireless MC7304
running SWI9X15C_05.05.67.00. If you want, I can give you SSH access
to a system with this modem plugged in, or I can even send you a spare
MC7354, whatever you prefer.

I'm just running --dms-get-operating-mode multiple times, and getting
errors frequently:

aleksander@athena:~/Development/foss/libqmi:(master)$ sudo qmicli -d
/dev/cdc-wdm3 --dms-get-operating-mode
[/dev/cdc-wdm3] Operating mode retrieved:
Mode: 'online'
HW restricted: 'no'

aleksander@athena:~/Development/foss/libqmi:(master)$ sudo qmicli -d
/dev/cdc-wdm3 --dms-get-operating-mode
[19 abr 2017, 20:25:36] -Warning ** Error reading from istream: Error
reading from file descriptor: Input/output error
^[[A^Ccancelling the operation...
error: couldn't create client for the 'dms' service: Operation was cancelled

aleksander@athena:~/Development/foss/libqmi:(master)$ sudo qmicli -d
/dev/cdc-wdm3 --dms-get-operating-mode
[19 abr 2017, 20:25:38] -Warning ** Error reading from istream: Error
reading from file descriptor: Input/output error
^Ccancelling the operation...
error: couldn't create client for the 'dms' service: Operation was cancelled

aleksander@athena:~/Development/foss/libqmi:(master)$ sudo qmicli -d
/dev/cdc-wdm3 --dms-get-operating-mode
[/dev/cdc-wdm3] Operating mode retrieved:
Mode: 'online'
HW restricted: 'no'

aleksander@athena:~/Development/foss/libqmi:(master)$ sudo qmicli -d
/dev/cdc-wdm3 --dms-get-operating-mode
[/dev/cdc-wdm3] Operating mode retrieved:
Mode: 'online'
HW restricted: 'no'

aleksander@athena:~/Development/foss/libqmi:(master)$ sudo qmicli -d
/dev/cdc-wdm3 --dms-get-operating-mode
[/dev/cdc-wdm3] Operating mode retrieved:
Mode: 'online'
HW restricted: 'no'

aleksander@athena:~/Development/foss/libqmi:(master)$ sudo qmicli -d
/dev/cdc-wdm3 --dms-get-operating-mode
[/dev/cdc-wdm3] Operating mode retrieved:
Mode: 'online'
HW restricted: 'no'

aleksander@athena:~/Development/foss/libqmi:(master)$ sudo qmicli -d
/dev/cdc-wdm3 --dms-get-operating-mode
[19 abr 2017, 20:25:52] -Warning ** Error reading from istream: Error
reading from file descriptor: Input/output error
error: couldn't create client for the 'dms' service: CID allocation
failed in the CTL client: Transaction timed out

...

-- 
Aleksander
https://aleksander.es
--
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] USB: qcserial: add Dell DW5570 QDL

[Aleksander Morgado]

The Dell DW5570 is a re-branded Sierra Wireless MC8805 which will by
default boot with vid 0x413c and pid 0x81a3. When triggered QDL download
mode, the device switches to pid 0x81a6 and provides the standard TTY
used for firmware upgrade.

Cc: <sta...@vger.kernel.org>
Signed-off-by: Aleksander Morgado <aleksan...@aleksander.es>
---
 drivers/usb/serial/qcserial.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
index 1bc6089b9008..696458db7e3c 100644
--- a/drivers/usb/serial/qcserial.c
+++ b/drivers/usb/serial/qcserial.c
@@ -124,6 +124,7 @@ static const struct usb_device_id id_table[] = {
{USB_DEVICE(0x1410, 0xa021)},   /* Novatel Gobi 3000 Composite */
{USB_DEVICE(0x413c, 0x8193)},   /* Dell Gobi 3000 QDL */
{USB_DEVICE(0x413c, 0x8194)},   /* Dell Gobi 3000 Composite */
+   {USB_DEVICE(0x413c, 0x81a6)},   /* Dell DW5570 QDL (MC8805) */
{USB_DEVICE(0x1199, 0x68a4)},   /* Sierra Wireless QDL */
{USB_DEVICE(0x1199, 0x68a5)},   /* Sierra Wireless Modem */
{USB_DEVICE(0x1199, 0x68a8)},   /* Sierra Wireless QDL */
-- 
2.11.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

Re: 03f0:521d Hewlett-Packard

[Aleksander Morgado]

On Thu, Apr 21, 2016 at 7:15 AM, mirkt  wrote:
> Bus 001 Device 007: ID 03f0:521d Hewlett-Packard
> Device Descriptor:
>   bLength18
>   bDescriptorType 1
>   bcdUSB   2.00
>   bDeviceClass  255 Vendor Specific Class
>   bDeviceSubClass 2
>   bDeviceProtocol 1
>   bMaxPacketSize064
>   idVendor   0x03f0 Hewlett-Packard
>   idProduct  0x521d
>   bcdDevice0.01
>   iManufacturer   5 Hewlett-Packard
>   iProduct4 HP hs3110 HSPA+ Mobile Broadband Device
>   iSerial 0

So this is a MBIM managed HP device. You may be hitting the "FCC
authentication" issue, although to know for sure we need to see the
ModemManager and NetworkManager debug logs (this doesn't look like a
kernel issue). Could you get them following these steps?
https://www.freedesktop.org/wiki/Software/ModemManager/Debugging/

Once you have them, please use the ModemManager-devel mailing list, as
this isn't a kernel issue:
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

-- 
Aleksander
https://aleksander.es
--
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/6] net: qmi_wwan: MDM9x30 support

[Aleksander Morgado]

On Thu, Dec 3, 2015 at 7:24 PM, Bjørn Mork  wrote:
> We add new device IDs all the time, often without any testing on
> actual hardware. This is usually OK as long as the device is similar
> to already supported devices, using the same chipset and firmware
> basis.  But the Sierra Wireless MC7455 is an example of a new chipset
> generation. Adding it based on assumed similarity with its ancestors
> proved too optimistic.
>
> This series adds the missing bits and pieces necessary to support LTE
> Advanced modems based on the Qualcomm MDM9x30 chipset. A big thanks to
> Sierra Wireless for providing MC7455 samples for testing
>
> The most important change is the "raw-ip" support. The series also
> adds a necessary control request, removes an unsupported device ID,
> and adds a driver specific entry in MAINTAINERS.
>
> A few random notes about "raw-ip":
>
> "I rather have these all running in raw IP mode. The 802.3 framing is
> utterly stupid." - Marcel Holtmann in Jan 2012 [1]
>
> Marcel was right.  I should have listened to him. What more can I say?
>
> The 802.3 framing has provided a steady supply of firmware bugs for
> many years. We've added driver workarounds for many of these, but
> there are still known bugs where the workaround is so yucky that we
> have refused to apply it. But all that is over now.  The latest
> generation Qualcomm chips no longer supports 802.3 framing at all.
>
> I had two open questions regarding the "raw-ip" userspace API:
>
> 1) Should we continue faking an ethernet device, even if we don't use
>the L2 headers on the USB link anymore?
>
>There was a vote in favour of the "headerless" device. This is the
>honest representation of the hardware/firmware interface.
>
> 2) What input should the driver base its framing on?
>
>Snooping or directly manipulating QMI is considered out of the
>question. We delegated all QMI handling to userspace from the
>beginning.
>
>We have so far required userspace to configure the firmware for
>"802.3" framing, or fail if that proved impossible.  This
>requirement is now changed.  Userspace must now inform the driver
>if it negotiates "raw-ip" framing.  Two alternative interfaces were
>proposed:
> - ethtool private driver flag, or
> - sysfs file
>
>The NetworkManager/ModemManager developers were in favour of the
>sysfs alternative.
>
> These questions (or any other you migh have :) are of course still
> open.  This patch set presents the solutions I currently prefer,
> considering the above.
>
> All comments are appreciated, even simple '+1' ones.
>

+1 from me as well.

We still need to decide how to manage this in userspace once the
kernel part is ready. For all pre-WDA devices, I'd use 802-3 as that
is what we've all been using. For WDA capable devices, we should
likely query what the current data link layer mode is, and ask the
kernel to use that one via sysfs; or, default to raw-ip in those,
don't know.

-- 
Aleksander
https://aleksander.es
--
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] USB: serial: option: add support for Novatel MiFi USB620L

[Aleksander Morgado]

Also known as Verizon U620L.

The device is modeswitched from 1410:9020 to 1410:9022 by selecting the 4th USB
configuration:

 $ sudo usb_modeswitch –v 0x1410 –p 0x9020 –u 4

This configuration provides a ECM interface as well as TTYs ('Enterprise Mode'
according to the U620 Linux integration guide).

Signed-off-by: Aleksander Morgado <aleksan...@aleksander.es>
---
 drivers/usb/serial/option.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 685fef7..2ab2a33 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -161,6 +161,7 @@ static void option_instat_callback(struct urb *urb);
 #define NOVATELWIRELESS_PRODUCT_HSPA_EMBEDDED_HIGHSPEED0x9001
 #define NOVATELWIRELESS_PRODUCT_E362   0x9010
 #define NOVATELWIRELESS_PRODUCT_E371   0x9011
+#define NOVATELWIRELESS_PRODUCT_U620L  0x9022
 #define NOVATELWIRELESS_PRODUCT_G2 0xA010
 #define NOVATELWIRELESS_PRODUCT_MC551  0xB001
 
@@ -1052,6 +1053,7 @@ static const struct usb_device_id option_ids[] = {
{ USB_DEVICE_AND_INTERFACE_INFO(NOVATELWIRELESS_VENDOR_ID, 
NOVATELWIRELESS_PRODUCT_MC551, 0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(NOVATELWIRELESS_VENDOR_ID, 
NOVATELWIRELESS_PRODUCT_E362, 0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(NOVATELWIRELESS_VENDOR_ID, 
NOVATELWIRELESS_PRODUCT_E371, 0xff, 0xff, 0xff) },
+   { USB_DEVICE_AND_INTERFACE_INFO(NOVATELWIRELESS_VENDOR_ID, 
NOVATELWIRELESS_PRODUCT_U620L, 0xff, 0x00, 0x00) },
 
{ USB_DEVICE(AMOI_VENDOR_ID, AMOI_PRODUCT_H01) },
{ USB_DEVICE(AMOI_VENDOR_ID, AMOI_PRODUCT_H01A) },
-- 
2.6.2

--
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] xhci: fix reporting of 0-sized URBs in control endpoint

[Aleksander Morgado]

On Fri, Mar 6, 2015 at 7:08 PM, Sergei Shtylyov
sergei.shtyl...@cogentembedded.com wrote:
 Hello.

 On 03/06/2015 06:14 PM, Mathias Nyman wrote:

 From: Aleksander Morgado aleksan...@aleksander.es


 When a control transfer has a short data stage, the xHCI controller
 generates
 two transfer events: a COMP_SHORT_TX event that specifies the
 untransferred
 amount, and a COMP_SUCCESS event. But when the data stage is not short,
 only the
 COMP_SUCCESS event occurs. Therefore, xhci-hcd must set urb-actual_length
 to
 urb-transfer_buffer_length while processing the COMP_SUCCESS event,
 unless
 urb-actual_length was set already by a previous COMP_SHORT_TX event.


 The driver checks this by seeing whether urb-actual_length == 0, but this
 alone
 is the wrong test, as it is entirely possible for a short transfer to have
 an
 urb-actual_length = 0.


 This patch changes the xhci driver to rely on a new td-urb_length_set
 flag,
 which is set to true when a COMP_SHORT_TX event is received and the URB
 length
 updated at that stage.


 This fixes a bug which affected the HSO plugin, which relies on URBs with
 urb-actual_length == 0 to halt re-submitting the RX URB in the control
 endpoint.


 Cc: sta...@vger.kernel.org
 Signed-off-by: Aleksander Morgado aleksan...@aleksander.es
 Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com


 [...]

 diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
 index 3b97f05..d066393 100644
 --- a/drivers/usb/host/xhci.h
 +++ b/drivers/usb/host/xhci.h
 @@ -1,3 +1,4 @@
 +
   /*
* xHCI host controller driver
*


Hm, I thought you've dropped this new line...


Ouch; sorry for that. How do I fix that now? Submit another patch just
removing it? Or resubmit a v6 of the patch? I think Greg already
cherry-picked it to his branch.

-- 
Aleksander
https://aleksander.es
--
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] xhci: no need to check for URB_SHORT_NOT_OK

[Aleksander Morgado]

The usb core automatically sets the status to -EREMOTEIO when giving back the
URB to the driver if the transfer was short, and URB_SHORT_NOT_OK was set in the
transfer_flags and the status is equal to 0 (see __usb_hcd_giveback_urb()).

So, avoid the redundant checks in the xhci logic; instead the status is always
set to 0.

Signed-off-by: Aleksander Morgado aleksan...@aleksander.es
---
 drivers/usb/host/xhci-ring.c | 51 +++-
 1 file changed, 8 insertions(+), 43 deletions(-)

diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 73485fa..7b87ffe 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1849,10 +1849,7 @@ td_cleanup:
urb-transfer_buffer_length,
urb-actual_length);
urb-actual_length = 0;
-   if (td-urb-transfer_flags  URB_SHORT_NOT_OK)
-   *status = -EREMOTEIO;
-   else
-   *status = 0;
+   *status = 0;
}
list_del_init(td-td_list);
/* Was this TD slated to be cancelled but completed anyway? */
@@ -1911,10 +1908,7 @@ static int process_ctrl_td(struct xhci_hcd *xhci, struct 
xhci_td *td,
}
break;
case COMP_SHORT_TX:
-   if (td-urb-transfer_flags  URB_SHORT_NOT_OK)
-   *status = -EREMOTEIO;
-   else
-   *status = 0;
+   *status = 0;
break;
case COMP_STOP_INVAL:
case COMP_STOP:
@@ -1946,16 +1940,7 @@ static int process_ctrl_td(struct xhci_hcd *xhci, struct 
xhci_td *td,
if (event_trb != ep_ring-dequeue) {
/* The event was for the status stage */
if (event_trb == td-last_trb) {
-   if (td-urb_length_set) {
-   /* Don't overwrite a previously set error code
-*/
-   if ((*status == -EINPROGRESS || *status == 0) 
-   (td-urb-transfer_flags
- URB_SHORT_NOT_OK))
-   /* Did we already see a short data
-* stage? */
-   *status = -EREMOTEIO;
-   } else {
+   if (!td-urb_length_set) {
td-urb-actual_length =
td-urb-transfer_buffer_length;
}
@@ -2111,21 +2096,13 @@ static int process_bulk_intr_td(struct xhci_hcd *xhci, 
struct xhci_td *td,
EVENT_TRB_LEN(le32_to_cpu(event-transfer_len)) != 0) {
xhci_warn(xhci, WARN Successful completion 
on short TX\n);
-   if (td-urb-transfer_flags  URB_SHORT_NOT_OK)
-   *status = -EREMOTEIO;
-   else
-   *status = 0;
if ((xhci-quirks  XHCI_TRUST_TX_LENGTH))
trb_comp_code = COMP_SHORT_TX;
-   } else {
-   *status = 0;
}
+   *status = 0;
break;
case COMP_SHORT_TX:
-   if (td-urb-transfer_flags  URB_SHORT_NOT_OK)
-   *status = -EREMOTEIO;
-   else
-   *status = 0;
+   *status = 0;
break;
default:
/* Others already handled above */
@@ -2149,26 +2126,14 @@ static int process_bulk_intr_td(struct xhci_hcd *xhci, 
struct xhci_td *td,
of %d bytes left\n,
  
EVENT_TRB_LEN(le32_to_cpu(event-transfer_len)));
td-urb-actual_length = 0;
-   if (td-urb-transfer_flags  URB_SHORT_NOT_OK)
-   *status = -EREMOTEIO;
-   else
-   *status = 0;
+   *status = 0;
}
/* Don't overwrite a previously set error code */
-   if (*status == -EINPROGRESS) {
-   if (td-urb-transfer_flags  URB_SHORT_NOT_OK)
-   *status = -EREMOTEIO;
-   else
-   *status = 0;
-   }
+   if (*status == -EINPROGRESS)
+   *status = 0;
} else {
td-urb-actual_length =
td-urb-transfer_buffer_length;
-   /* Ignore

[PATCH v5] xhci: fix reporting of 0-sized URBs in control endpoint

[Aleksander Morgado]

When a control transfer has a short data stage, the xHCI controller generates
two transfer events: a COMP_SHORT_TX event that specifies the untransferred
amount, and a COMP_SUCCESS event. But when the data stage is not short, only the
COMP_SUCCESS event occurs. Therefore, xhci-hcd must set urb-actual_length to
urb-transfer_buffer_length while processing the COMP_SUCCESS event, unless
urb-actual_length was set already by a previous COMP_SHORT_TX event.

The driver checks this by seeing whether urb-actual_length == 0, but this alone
is the wrong test, as it is entirely possible for a short transfer to have an
urb-actual_length = 0.

This patch changes the xhci driver to rely on a new td-urb_length_set flag,
which is set to true when a COMP_SHORT_TX event is received and the URB length
updated at that stage.

This fixes a bug which affected the HSO plugin, which relies on URBs with
urb-actual_length == 0 to halt re-submitting the RX URB in the control
endpoint.

Signed-off-by: Aleksander Morgado aleksan...@aleksander.es
---

Hey Mathias,

This v5 of the patch takes into account the possibility of needing to return
-EREMOTEIO if URB_SHORT_NOT_OK was requested in the transfer flags.

With this change we no longer check for having a value in urb-actual_length,
instead we just use the new flag and therefore we treat in the same way all
cases where we got a SHORT_TX event (including those were the transfer was 0).

Also changed the length of the comment lines to avoid going off 80chars per
line.

Let me know what you think.

---
 drivers/usb/host/xhci-ring.c | 10 --
 drivers/usb/host/xhci.h  |  3 +++
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 88da8d6..73485fa 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1946,7 +1946,7 @@ static int process_ctrl_td(struct xhci_hcd *xhci, struct 
xhci_td *td,
if (event_trb != ep_ring-dequeue) {
/* The event was for the status stage */
if (event_trb == td-last_trb) {
-   if (td-urb-actual_length != 0) {
+   if (td-urb_length_set) {
/* Don't overwrite a previously set error code
 */
if ((*status == -EINPROGRESS || *status == 0) 
@@ -1960,7 +1960,13 @@ static int process_ctrl_td(struct xhci_hcd *xhci, struct 
xhci_td *td,
td-urb-transfer_buffer_length;
}
} else {
-   /* Maybe the event was for the data stage? */
+   /*
+* Maybe the event was for the data stage? If so, update
+* already the actual_length of the URB and flag it as
+* set, so that it is not overwritten in the event for
+* the last TRB.
+*/
+   td-urb_length_set = true;
td-urb-actual_length =
td-urb-transfer_buffer_length -
EVENT_TRB_LEN(le32_to_cpu(event-transfer_len));
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 9745147..bd868aa 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1,3 +1,4 @@
+
 /*
  * xHCI host controller driver
  *
@@ -1288,6 +1289,8 @@ struct xhci_td {
struct xhci_segment *start_seg;
union xhci_trb  *first_trb;
union xhci_trb  *last_trb;
+   /* actual_length of the URB has already been set */
+   boolurb_length_set;
 };

 /* xHCI command default timeout value */
--
2.3.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: [RFC PATCH] xhci: fix reporting of 0-sized URBs in control endpoints

[Aleksander Morgado]

On Mon, Mar 2, 2015 at 12:57 PM, Mathias Nyman
mathias.ny...@linux.intel.com wrote:
 On 26.02.2015 23:59, Aleksander Morgado wrote:
 On Thu, Feb 26, 2015 at 5:12 PM, Mathias Nyman
 mathias.ny...@linux.intel.com wrote:
 When a control transfer has a short data stage, the xHCI controller 
 generates
 two transfer events: a COMP_SHORT_TX event that specifies the untransferred
 amount, and a COMP_SUCCESS event. But when the data stage is not short, only
 the COMP_SUCCESS event occurs. Therefore, xhci-hcd sets urb-actual_length
 to urb-transfer_buffer_length while processing the COMP_SUCCESS event,
 unless urb-actual_length was set already by a previous COMP_SHORT_TX event.

 The driver checks this by seeing whether urb-actual_length == 0, but this
 alone is the wrong test, as it is entirely possible for a short transfer to
 have an urb-actual_length = 0.

 This patch changes the xhci driver to set the urb-actual_length in advance
 to the expected value of a successful control transfer.
 The urb-actual_length is then only adjusted in case of short transfers or
 other special events, but not on COMP_SUCCESS events.

 This fixes a bug which affected the HSO plugin, which relies on URBs with
 urb-actual_length == 0 to halt re-submitting the RX URB in the control
 endpoint.

 Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com
 ---
  drivers/usb/host/xhci-ring.c | 73 
 ++--
  1 file changed, 37 insertions(+), 36 deletions(-)

 diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
 index b46b5b9..0e02e79 100644
 --- a/drivers/usb/host/xhci-ring.c
 +++ b/drivers/usb/host/xhci-ring.c
 @@ -732,7 +732,11 @@ remove_finished_td:
 /* Clean up the cancelled URB */
 /* Doesn't matter what we pass for status, since the core 
 will
  * just overwrite it (because the URB has been unlinked).
 +* Control urbs have the urb-actual_length pre-set, clear 
 it
 +* as well
  */
 +   if (usb_endpoint_xfer_control(cur_td-urb-ep-desc))
 +   cur_td-urb-actual_length = 0;
 xhci_giveback_urb_in_irq(xhci, cur_td, 0);

 /* Stop processing the cancelled list if the watchdog timer 
 is
 @@ -755,6 +759,7 @@ static void xhci_kill_ring_urbs(struct xhci_hcd *xhci, 
 struct xhci_ring *ring)
 list_del_init(cur_td-td_list);
 if (!list_empty(cur_td-cancelled_td_list))
 list_del_init(cur_td-cancelled_td_list);
 +   cur_td-urb-actual_length = 0;
 xhci_giveback_urb_in_irq(xhci, cur_td, -ESHUTDOWN);
 }
  }
 @@ -792,6 +797,7 @@ static void xhci_kill_endpoint_urbs(struct xhci_hcd 
 *xhci,
 cur_td = list_first_entry(ep-cancelled_td_list,
 struct xhci_td, cancelled_td_list);
 list_del_init(cur_td-cancelled_td_list);
 +   cur_td-urb-actual_length = 0;
 xhci_giveback_urb_in_irq(xhci, cur_td, -ESHUTDOWN);
 }
  }
 @@ -1888,6 +1894,7 @@ static int process_ctrl_td(struct xhci_hcd *xhci, 
 struct xhci_td *td,
 int ep_index;
 struct xhci_ep_ctx *ep_ctx;
 u32 trb_comp_code;
 +   bool force_finish_td = false;

 slot_id = TRB_TO_SLOT_ID(le32_to_cpu(event-flags));
 xdev = xhci-devs[slot_id];
 @@ -1906,7 +1913,8 @@ static int process_ctrl_td(struct xhci_hcd *xhci, 
 struct xhci_td *td,
 xhci_warn(xhci, WARN: Success on ctrl data TRB 
 without IOC set??\n);
 *status = -ESHUTDOWN;
 -   } else {
 +   } else if (*status == -EINPROGRESS) {
 +   /* only set to 0 if no previous event set it 
 earlier */
 *status = 0;
 }
 break;
 @@ -1918,6 +1926,8 @@ static int process_ctrl_td(struct xhci_hcd *xhci, 
 struct xhci_td *td,
 break;
 case COMP_STOP_INVAL:
 case COMP_STOP:
 +   /* we don't continue stopped TDs, so length can be set to 0 
 */
 +   td-urb-actual_length = 0;
 return finish_td(xhci, td, event_trb, event, ep, status, 
 false);
 default:
 if (!xhci_requires_manual_halt_cleanup(xhci,
 @@ -1928,44 +1938,26 @@ static int process_ctrl_td(struct xhci_hcd *xhci, 
 struct xhci_td *td,
 trb_comp_code, ep_index);
 /* else fall through */
 case COMP_STALL:
 -   /* Did we transfer part of the data (middle) phase? */
 -   if (event_trb != ep_ring-dequeue 
 -   event_trb != td-last_trb)
 -   td-urb-actual_length =
 -   td-urb-transfer_buffer_length -
 -   
 EVENT_TRB_LEN

Re: [RFC PATCH] xhci: fix reporting of 0-sized URBs in control endpoints

[Aleksander Morgado]

On Mon, Mar 2, 2015 at 4:02 PM, Alan Stern st...@rowland.harvard.edu wrote:
 On Mon, 2 Mar 2015, Aleksander Morgado wrote:

 I think my patch also lacks the -EREMOTEIO return for the case when 0
 bytes are transferred. I'll try to update it today.

 It's not necessary.  The USB core automatically sets the status to
 -EREMOTEIO if the status is equal to 0 and the transfer was short and
 URB_SHORT_NOT_OK was set.  See __usb_hcd_giveback_urb()

There are actually several places in xhci-ring.c where that check is
done in order to return -EREMOTEIO; does that mean that all of them
are redundant? e.g. not only the ones in process_ctrl_td() but also in
finish_td().

-- 
Aleksander
https://aleksander.es
--
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] hso: add missing spinlock grab when iterating the serial table

[Aleksander Morgado]

Access to the 'serial_table' array needs to be protected by the spinlock.

Signed-off-by: Aleksander Morgado aleksan...@aleksander.es
---
 drivers/net/usb/hso.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/hso.c
index 3c8dfe5..4f6deff 100644
--- a/drivers/net/usb/hso.c
+++ b/drivers/net/usb/hso.c
@@ -607,19 +607,24 @@ static struct hso_serial 
*get_serial_by_shared_int_and_type(
struct hso_shared_int *shared_int,
int mux)
 {
+   struct hso_serial *serial = NULL;
int i, port;
+   unsigned long flags;
 
port = hso_mux_to_port(mux);
 
+   spin_lock_irqsave(serial_table_lock, flags);
for (i = 0; i  HSO_SERIAL_TTY_MINORS; i++) {
if (serial_table[i] 
(dev2ser(serial_table[i])-shared_int == shared_int) 
((serial_table[i]-port_spec  HSO_PORT_MASK) == port)) {
-   return dev2ser(serial_table[i]);
+   serial = dev2ser(serial_table[i]);
+   break;
}
}
+   spin_unlock_irqrestore(serial_table_lock, flags);
 
-   return NULL;
+   return serial;
 }
 
 static struct hso_serial *get_serial_by_index(unsigned index)
-- 
2.3.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: [RFC PATCH] xhci: fix reporting of 0-sized URBs in control endpoints

[Aleksander Morgado]

On Thu, Feb 26, 2015 at 5:12 PM, Mathias Nyman
mathias.ny...@linux.intel.com wrote:
 When a control transfer has a short data stage, the xHCI controller generates
 two transfer events: a COMP_SHORT_TX event that specifies the untransferred
 amount, and a COMP_SUCCESS event. But when the data stage is not short, only
 the COMP_SUCCESS event occurs. Therefore, xhci-hcd sets urb-actual_length
 to urb-transfer_buffer_length while processing the COMP_SUCCESS event,
 unless urb-actual_length was set already by a previous COMP_SHORT_TX event.

 The driver checks this by seeing whether urb-actual_length == 0, but this
 alone is the wrong test, as it is entirely possible for a short transfer to
 have an urb-actual_length = 0.

 This patch changes the xhci driver to set the urb-actual_length in advance
 to the expected value of a successful control transfer.
 The urb-actual_length is then only adjusted in case of short transfers or
 other special events, but not on COMP_SUCCESS events.

 This fixes a bug which affected the HSO plugin, which relies on URBs with
 urb-actual_length == 0 to halt re-submitting the RX URB in the control
 endpoint.

 Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com

Tested this patch (with the extra else if suggested in the follow up
commit) and it seems to work correctly with the HSO plugin. Not sure
if it'll end up being the last version or not, but anyway:

Tested-by: Aleksander Morgado aleksan...@aleksander.es

Let me know if you want me to test anything else.

 ---
  drivers/usb/host/xhci-ring.c | 73 
 ++--
  1 file changed, 37 insertions(+), 36 deletions(-)

 diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
 index b46b5b9..0e02e79 100644
 --- a/drivers/usb/host/xhci-ring.c
 +++ b/drivers/usb/host/xhci-ring.c
 @@ -732,7 +732,11 @@ remove_finished_td:
 /* Clean up the cancelled URB */
 /* Doesn't matter what we pass for status, since the core will
  * just overwrite it (because the URB has been unlinked).
 +* Control urbs have the urb-actual_length pre-set, clear it
 +* as well
  */
 +   if (usb_endpoint_xfer_control(cur_td-urb-ep-desc))
 +   cur_td-urb-actual_length = 0;
 xhci_giveback_urb_in_irq(xhci, cur_td, 0);

 /* Stop processing the cancelled list if the watchdog timer is
 @@ -755,6 +759,7 @@ static void xhci_kill_ring_urbs(struct xhci_hcd *xhci, 
 struct xhci_ring *ring)
 list_del_init(cur_td-td_list);
 if (!list_empty(cur_td-cancelled_td_list))
 list_del_init(cur_td-cancelled_td_list);
 +   cur_td-urb-actual_length = 0;
 xhci_giveback_urb_in_irq(xhci, cur_td, -ESHUTDOWN);
 }
  }
 @@ -792,6 +797,7 @@ static void xhci_kill_endpoint_urbs(struct xhci_hcd *xhci,
 cur_td = list_first_entry(ep-cancelled_td_list,
 struct xhci_td, cancelled_td_list);
 list_del_init(cur_td-cancelled_td_list);
 +   cur_td-urb-actual_length = 0;
 xhci_giveback_urb_in_irq(xhci, cur_td, -ESHUTDOWN);
 }
  }
 @@ -1888,6 +1894,7 @@ static int process_ctrl_td(struct xhci_hcd *xhci, 
 struct xhci_td *td,
 int ep_index;
 struct xhci_ep_ctx *ep_ctx;
 u32 trb_comp_code;
 +   bool force_finish_td = false;

 slot_id = TRB_TO_SLOT_ID(le32_to_cpu(event-flags));
 xdev = xhci-devs[slot_id];
 @@ -1906,7 +1913,8 @@ static int process_ctrl_td(struct xhci_hcd *xhci, 
 struct xhci_td *td,
 xhci_warn(xhci, WARN: Success on ctrl data TRB 
 without IOC set??\n);
 *status = -ESHUTDOWN;
 -   } else {
 +   } else if (*status == -EINPROGRESS) {
 +   /* only set to 0 if no previous event set it earlier 
 */
 *status = 0;
 }
 break;
 @@ -1918,6 +1926,8 @@ static int process_ctrl_td(struct xhci_hcd *xhci, 
 struct xhci_td *td,
 break;
 case COMP_STOP_INVAL:
 case COMP_STOP:
 +   /* we don't continue stopped TDs, so length can be set to 0 */
 +   td-urb-actual_length = 0;
 return finish_td(xhci, td, event_trb, event, ep, status, 
 false);
 default:
 if (!xhci_requires_manual_halt_cleanup(xhci,
 @@ -1928,44 +1938,26 @@ static int process_ctrl_td(struct xhci_hcd *xhci, 
 struct xhci_td *td,
 trb_comp_code, ep_index);
 /* else fall through */
 case COMP_STALL:
 -   /* Did we transfer part of the data (middle) phase? */
 -   if (event_trb != ep_ring-dequeue 
 -   event_trb != td-last_trb

Re: [PATCH] hso: add missing spinlock grab when iterating the serial table

[Aleksander Morgado]

On Fri, Feb 27, 2015 at 7:44 PM, Aleksander Morgado
aleksan...@aleksander.es wrote:
 Access to the 'serial_table' array needs to be protected by the spinlock.

 Signed-off-by: Aleksander Morgado aleksan...@aleksander.es
 ---
  drivers/net/usb/hso.c | 9 +++--
  1 file changed, 7 insertions(+), 2 deletions(-)

 diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/hso.c
 index 3c8dfe5..4f6deff 100644
 --- a/drivers/net/usb/hso.c
 +++ b/drivers/net/usb/hso.c
 @@ -607,19 +607,24 @@ static struct hso_serial 
 *get_serial_by_shared_int_and_type(
 struct hso_shared_int *shared_int,
 int mux)
  {
 +   struct hso_serial *serial = NULL;
 int i, port;
 +   unsigned long flags;

 port = hso_mux_to_port(mux);

 +   spin_lock_irqsave(serial_table_lock, flags);
 for (i = 0; i  HSO_SERIAL_TTY_MINORS; i++) {
 if (serial_table[i] 
 (dev2ser(serial_table[i])-shared_int == shared_int) 
 ((serial_table[i]-port_spec  HSO_PORT_MASK) == port)) {
 -   return dev2ser(serial_table[i]);
 +   serial = dev2ser(serial_table[i]);
 +   break;
 }
 }
 +   spin_unlock_irqrestore(serial_table_lock, flags);

 -   return NULL;
 +   return serial;
  }

  static struct hso_serial *get_serial_by_index(unsigned index)
 --
 2.3.1


Seems there are actually more places where this has to be done; I'll
send an updated version of the patch.


-- 
Aleksander
https://aleksander.es
--
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: [RFC PATCH] xhci: fix reporting of 0-sized URBs in control endpoints

[Aleksander Morgado]

On Thu, Feb 26, 2015 at 5:12 PM, Mathias Nyman
mathias.ny...@linux.intel.com wrote:
 When a control transfer has a short data stage, the xHCI controller generates
 two transfer events: a COMP_SHORT_TX event that specifies the untransferred
 amount, and a COMP_SUCCESS event. But when the data stage is not short, only
 the COMP_SUCCESS event occurs. Therefore, xhci-hcd sets urb-actual_length
 to urb-transfer_buffer_length while processing the COMP_SUCCESS event,
 unless urb-actual_length was set already by a previous COMP_SHORT_TX event.

 The driver checks this by seeing whether urb-actual_length == 0, but this
 alone is the wrong test, as it is entirely possible for a short transfer to
 have an urb-actual_length = 0.

 This patch changes the xhci driver to set the urb-actual_length in advance
 to the expected value of a successful control transfer.
 The urb-actual_length is then only adjusted in case of short transfers or
 other special events, but not on COMP_SUCCESS events.

 This fixes a bug which affected the HSO plugin, which relies on URBs with
 urb-actual_length == 0 to halt re-submitting the RX URB in the control
 endpoint.

 Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com
 ---
  drivers/usb/host/xhci-ring.c | 73 
 ++--
  1 file changed, 37 insertions(+), 36 deletions(-)

 diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
 index b46b5b9..0e02e79 100644
 --- a/drivers/usb/host/xhci-ring.c
 +++ b/drivers/usb/host/xhci-ring.c
 @@ -732,7 +732,11 @@ remove_finished_td:
 /* Clean up the cancelled URB */
 /* Doesn't matter what we pass for status, since the core will
  * just overwrite it (because the URB has been unlinked).
 +* Control urbs have the urb-actual_length pre-set, clear it
 +* as well
  */
 +   if (usb_endpoint_xfer_control(cur_td-urb-ep-desc))
 +   cur_td-urb-actual_length = 0;
 xhci_giveback_urb_in_irq(xhci, cur_td, 0);

 /* Stop processing the cancelled list if the watchdog timer is
 @@ -755,6 +759,7 @@ static void xhci_kill_ring_urbs(struct xhci_hcd *xhci, 
 struct xhci_ring *ring)
 list_del_init(cur_td-td_list);
 if (!list_empty(cur_td-cancelled_td_list))
 list_del_init(cur_td-cancelled_td_list);
 +   cur_td-urb-actual_length = 0;
 xhci_giveback_urb_in_irq(xhci, cur_td, -ESHUTDOWN);
 }
  }
 @@ -792,6 +797,7 @@ static void xhci_kill_endpoint_urbs(struct xhci_hcd *xhci,
 cur_td = list_first_entry(ep-cancelled_td_list,
 struct xhci_td, cancelled_td_list);
 list_del_init(cur_td-cancelled_td_list);
 +   cur_td-urb-actual_length = 0;
 xhci_giveback_urb_in_irq(xhci, cur_td, -ESHUTDOWN);
 }
  }
 @@ -1888,6 +1894,7 @@ static int process_ctrl_td(struct xhci_hcd *xhci, 
 struct xhci_td *td,
 int ep_index;
 struct xhci_ep_ctx *ep_ctx;
 u32 trb_comp_code;
 +   bool force_finish_td = false;

 slot_id = TRB_TO_SLOT_ID(le32_to_cpu(event-flags));
 xdev = xhci-devs[slot_id];
 @@ -1906,7 +1913,8 @@ static int process_ctrl_td(struct xhci_hcd *xhci, 
 struct xhci_td *td,
 xhci_warn(xhci, WARN: Success on ctrl data TRB 
 without IOC set??\n);
 *status = -ESHUTDOWN;
 -   } else {
 +   } else if (*status == -EINPROGRESS) {
 +   /* only set to 0 if no previous event set it earlier 
 */
 *status = 0;
 }
 break;
 @@ -1918,6 +1926,8 @@ static int process_ctrl_td(struct xhci_hcd *xhci, 
 struct xhci_td *td,
 break;
 case COMP_STOP_INVAL:
 case COMP_STOP:
 +   /* we don't continue stopped TDs, so length can be set to 0 */
 +   td-urb-actual_length = 0;
 return finish_td(xhci, td, event_trb, event, ep, status, 
 false);
 default:
 if (!xhci_requires_manual_halt_cleanup(xhci,
 @@ -1928,44 +1938,26 @@ static int process_ctrl_td(struct xhci_hcd *xhci, 
 struct xhci_td *td,
 trb_comp_code, ep_index);
 /* else fall through */
 case COMP_STALL:
 -   /* Did we transfer part of the data (middle) phase? */
 -   if (event_trb != ep_ring-dequeue 
 -   event_trb != td-last_trb)
 -   td-urb-actual_length =
 -   td-urb-transfer_buffer_length -
 -   
 EVENT_TRB_LEN(le32_to_cpu(event-transfer_len));
 -   else
 -   td-urb-actual_length = 0;
 -
 -   return finish_td(xhci, 

Re: [PATCH v3] xhci: fix reporting of 0-sized URBs in control endpoint

[Aleksander Morgado]

 When a control transfer has a short data stage, the xHCI controller 
 generates
 two transfer events: a COMP_SHORT_TX event that specifies the untransferred
 amount, and a COMP_SUCCESS event. But when the data stage is not short, 
 only the
 COMP_SUCCESS event occurs. Therefore, xhci-hcd must set urb-actual_length 
 to
 urb-transfer_buffer_length while processing the COMP_SUCCESS event, unless
 urb-actual_length was set already by a previous COMP_SHORT_TX event.


 I think that the only case you should see a COMP_SUCCESS after a 
 COMP_SHORT_TX
 is if xhci hits a link TRB while automatically moving to the next TRB after 
 the
 short packet.

 If Event Data TRBs are used, or a later TRB in that TD has the IOC flag set 
 then xhci should just
 generate a second transfer event with the same COMP_SHORT_TX completion 
 code.
 (xhci specs section 4.10.1.1)


 Well, I can only speak for this usecase I have here with the Option
 HSO modem; in this case the COMP_SHORT_TX+COMP_SUCCESS pair happens
 always, as the hso driver submits a URB with a 1024 byte buffer, and
 the modem usually replies with AT responses character by character;
 for each character I end up getting both events: first with
 COMP_SHORT_TX and the event length set to 1023, second with
 COMP_SUCESS and event length set to 0.


 Looking at the code it seems that xhci controllers after 0.96 generate a
 spurious COMP_SUCCESS after short packet, code says:

 /* In xhci controllers which follow xhci 1.0 spec gives a spurious
  * success event after a short transfer. This quirk will ignore such
  * spurious event.
  */
 if (xhci-hci_version  0x96)
 xhci-quirks |= XHCI_SPURIOUS_SUCCESS;

 I read the xhci specs as well and I also got the impression that there
 wasn't anything explicitly stating that a COMP_SUCCESS event always
 follows a COMP_SHORT_TX. But, the code already assumes that if you get
 a COMP_SHORT_TX event for a TRB which isn't the last one, you should
 still get an event for the last TRB (i.e. finish_td() isn't called for
 a COMP_SHORT_TX event if the TRB isn't the first one (event_trb !=
 ep_ring-dequeue) and if it isn't the last one (event_trb !=
 td-last_trb).

 Thats right, we always set the IOC (interrupt on completion) in the last TRB 
 of
 a control transfer, so it will always interrupt, generating a transfer event.

 I read through your previous mails where you were investigating this and also 
 looked a bit
 in more detail at the xhci code. I now understand better the issue. Its 
 clearly a bug in xhci driver.

 Can you still add some debugging and check the if the second event after the 
 COMP_SHORT_TX really
 is a COMP_SUCCESS ? and also what it says about the transfer length.

 printing out these values for the second event should do it:
   GET_COMP_CODE(le32_to_cpu(event-transfer_len))
   EVENT_TRB_LEN(le32_to_cpu(event-transfer_len))


The second event is always COMP_SUCCESS and the event-transfer_len is
always set to 0 in that one. The 3 cases I've seen are:

case 1: 1 event on last TRB
  COMP_SUCCESS, event-len=0

case 2:  short event but with data
  COMP_SHORT_TX, event-len  urb-transfer_buffer_len
  COMP_SUCCESS, event-len=0

case 3: short event with no data
  COMP_SHORT_TX, event-len = urb-transfer_buffer_len
  COMP_SUCCESS, event-len=0

 Right now process_ctrl_td() sets the urb-actual_length based on TRB position 
 in TD (first, last, neither) and
 what value urb-actual_length contains. I think that by checking the actual 
 event completion code, and the event
 reported  remaining length we could get this correct without adding any 
 additional fields to struct xhci_td.


The problem with that logic is that just by checking the last event
completion code and event-length we cannot know whether there was a
previous COMP_SHORT_TX event. i.e. when processing that last event you
wouldn't know whether it was case 1, case 2 or case 3 from above.

 If I find the time I'll rewrite this part, if not then I'll add your patch, 
 (v4)


If you want to suggest any other approach, let me know and I'll spend
time with it.




 The driver checks this by seeing whether urb-actual_length == 0, but this 
 alone
 is the wrong test, as it is entirely possible for a short transfer to have 
 an
 urb-actual_length = 0.

 This should be fixed, handling short packets look a bit messy in general 
 right now


 This patch changes the xhci driver to rely not only on the 
 urb-actual_length,
 but also on the ep_ring-last_td_was_short flag, which is set to true when 
 a
 COMP_SHORT_TX event is received.

 This fixes a bug which affected the HSO plugin, which relies on URBs with
 urb-actual_length == 0 to halt re-submitting the RX URB in the control
 endpoint.

 Signed-off-by: Aleksander Morgado aleksan...@aleksander.es
 ---

 Hey,

 This is the third update of the patch:

  * v2 modified the commit message to make it shorter and clearer.

  * v3 updated the format of the commented lines

[PATCH v4] xhci: fix reporting of 0-sized URBs in control endpoint

[Aleksander Morgado]

When a control transfer has a short data stage, the xHCI controller generates
two transfer events: a COMP_SHORT_TX event that specifies the untransferred
amount, and a COMP_SUCCESS event. But when the data stage is not short, only the
COMP_SUCCESS event occurs. Therefore, xhci-hcd must set urb-actual_length to
urb-transfer_buffer_length while processing the COMP_SUCCESS event, unless
urb-actual_length was set already by a previous COMP_SHORT_TX event.

The driver checks this by seeing whether urb-actual_length == 0, but this alone
is the wrong test, as it is entirely possible for a short transfer to have an
urb-actual_length = 0.

This patch changes the xhci driver to rely not only on the urb-actual_length,
but also on a new td-urb_length_set flag, which is set to true when a
COMP_SHORT_TX event is received and the URB length updated at that stage.

This fixes a bug which affected the HSO plugin, which relies on URBs with
urb-actual_length == 0 to halt re-submitting the RX URB in the control
endpoint.

Signed-off-by: Aleksander Morgado aleksan...@aleksander.es
---

Hey Mathias,

I have now updated the patch to avoid re-using the 'last_td_was_short' flag, and
instead use a new 'urb_length_set' flag in the xhci_td struct. This new flag
will be unique for each URB, and therefore the flag shouldn't affect other TDs
that may come afterwards, as was the case when reusing the 'last_td_was_short'
flag in 'ep_ring'.

I was wondering whether the xhci_td struct is the best place to add this logic;
maybe it isn't, given that this is control-transfer specific?

Let me know what you think.

Cheers!

---
 drivers/usb/host/xhci-ring.c | 9 +++--
 drivers/usb/host/xhci.h  | 3 +++
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 88da8d6..be9c560 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1955,12 +1955,17 @@ static int process_ctrl_td(struct xhci_hcd *xhci, 
struct xhci_td *td,
/* Did we already see a short data
 * stage? */
*status = -EREMOTEIO;
-   } else {
+   } else if (!td-urb_length_set) {
td-urb-actual_length =
td-urb-transfer_buffer_length;
}
} else {
-   /* Maybe the event was for the data stage? */
+   /*
+* Maybe the event was for the data stage? If so, 
update already the
+* actual_length of the URB and flag it as set, so that 
it is not
+* overwritten in the event for the last TRB.
+*/
+   td-urb_length_set = true;
td-urb-actual_length =
td-urb-transfer_buffer_length -
EVENT_TRB_LEN(le32_to_cpu(event-transfer_len));
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 9745147..bd868aa 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1,3 +1,4 @@
+
 /*
  * xHCI host controller driver
  *
@@ -1288,6 +1289,8 @@ struct xhci_td {
struct xhci_segment *start_seg;
union xhci_trb  *first_trb;
union xhci_trb  *last_trb;
+   /* actual_length of the URB has already been set */
+   boolurb_length_set;
 };

 /* xHCI command default timeout value */
--
2.3.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

Re: [PATCH v2] xhci: fix reporting of 0-sized URBs in control endpoint

[Aleksander Morgado]

 When a control transfer has a short data stage, the xHCI controller
 generates
 two transfer events: a COMP_SHORT_TX event that specifies the
 untransferred
 amount, and a COMP_SUCCESS event. But when the data stage is not short,
 only the
 COMP_SUCCESS event occurs. Therefore, xhci-hcd must set urb-actual_length
 to
 urb-transfer_buffer_length while processing the COMP_SUCCESS event,
 unless
 urb-actual_length was set already by a previous COMP_SHORT_TX event.


 The driver checks this by seeing whether urb-actual_length == 0, but this
 alone
 is the wrong test, as it is entirely possible for a short transfer to have
 an
 urb-actual_length = 0.


 This patch changes the xhci driver to rely not only on the
 urb-actual_length,
 but also on the ep_ring-last_td_was_short flag, which is set to true when
 a
 COMP_SHORT_TX event is received.


 This fixes a bug which affected the HSO plugin, which relies on URBs with
 urb-actual_length == 0 to halt re-submitting the RX URB in the control
 endpoint.


 Signed-off-by: Aleksander Morgado aleksan...@aleksander.es
 ---
   drivers/usb/host/xhci-ring.c | 14 +-
   1 file changed, 9 insertions(+), 5 deletions(-)


 diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
 index 88da8d6..6b050f1 100644
 --- a/drivers/usb/host/xhci-ring.c
 +++ b/drivers/usb/host/xhci-ring.c

 [...]

 @@ -2484,6 +2480,14 @@ static int handle_tx_event(struct xhci_hcd *xhci,
 ret = process_bulk_intr_td(xhci, td, event_trb,
 event,
  ep, status);

 +   /* Flag whether the just processed TRB was short. Do it
 after
 +* processing, so that the processor methods can also use
 this
 +* flag. */


The preferred multi-line comment style is this:

 /*
  * bla
  * bla
  */

 [...]

 WBR, Sergei


Will submit then a v3 with that change.

Cheers,

-- 
Aleksander
https://aleksander.es
--
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 v3] xhci: fix reporting of 0-sized URBs in control endpoint

[Aleksander Morgado]

When a control transfer has a short data stage, the xHCI controller generates
two transfer events: a COMP_SHORT_TX event that specifies the untransferred
amount, and a COMP_SUCCESS event. But when the data stage is not short, only the
COMP_SUCCESS event occurs. Therefore, xhci-hcd must set urb-actual_length to
urb-transfer_buffer_length while processing the COMP_SUCCESS event, unless
urb-actual_length was set already by a previous COMP_SHORT_TX event.

The driver checks this by seeing whether urb-actual_length == 0, but this alone
is the wrong test, as it is entirely possible for a short transfer to have an
urb-actual_length = 0.

This patch changes the xhci driver to rely not only on the urb-actual_length,
but also on the ep_ring-last_td_was_short flag, which is set to true when a
COMP_SHORT_TX event is received.

This fixes a bug which affected the HSO plugin, which relies on URBs with
urb-actual_length == 0 to halt re-submitting the RX URB in the control
endpoint.

Signed-off-by: Aleksander Morgado aleksan...@aleksander.es
---

Hey,

This is the third update of the patch:

 * v2 modified the commit message to make it shorter and clearer.

 * v3 updated the format of the commented lines in the patch.

Cheers!

---
 drivers/usb/host/xhci-ring.c | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 88da8d6..eda3276 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1955,7 +1955,7 @@ static int process_ctrl_td(struct xhci_hcd *xhci, struct 
xhci_td *td,
/* Did we already see a short data
 * stage? */
*status = -EREMOTEIO;
-   } else {
+   } else if (!ep_ring-last_td_was_short) {
td-urb-actual_length =
td-urb-transfer_buffer_length;
}
@@ -2447,10 +2447,6 @@ static int handle_tx_event(struct xhci_hcd *xhci,
ret = skip_isoc_td(xhci, td, event, ep, status);
goto cleanup;
}
-   if (trb_comp_code == COMP_SHORT_TX)
-   ep_ring-last_td_was_short = true;
-   else
-   ep_ring-last_td_was_short = false;

if (ep-skip) {
xhci_dbg(xhci, Found td. Clear skip flag.\n);
@@ -2484,6 +2480,16 @@ static int handle_tx_event(struct xhci_hcd *xhci,
ret = process_bulk_intr_td(xhci, td, event_trb, event,
 ep, status);

+   /*
+* Flag whether the just processed TRB was short. Do it after
+* processing, so that the processor methods can also use this
+* flag.
+*/
+   if (trb_comp_code == COMP_SHORT_TX)
+   ep_ring-last_td_was_short = true;
+   else
+   ep_ring-last_td_was_short = false;
+
 cleanup:
/*
 * Do not update event ring dequeue pointer if ep-skip is set.
--
2.3.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

Re: [PATCH v3] xhci: fix reporting of 0-sized URBs in control endpoint

[Aleksander Morgado]

On Mon, Feb 23, 2015 at 4:23 PM, Mathias Nyman
mathias.ny...@linux.intel.com wrote:
 Hi

 On 23.02.2015 13:52, Aleksander Morgado wrote:
 When a control transfer has a short data stage, the xHCI controller generates
 two transfer events: a COMP_SHORT_TX event that specifies the untransferred
 amount, and a COMP_SUCCESS event. But when the data stage is not short, only 
 the
 COMP_SUCCESS event occurs. Therefore, xhci-hcd must set urb-actual_length to
 urb-transfer_buffer_length while processing the COMP_SUCCESS event, unless
 urb-actual_length was set already by a previous COMP_SHORT_TX event.


 I think that the only case you should see a COMP_SUCCESS after a COMP_SHORT_TX
 is if xhci hits a link TRB while automatically moving to the next TRB after 
 the
 short packet.

 If Event Data TRBs are used, or a later TRB in that TD has the IOC flag set 
 then xhci should just
 generate a second transfer event with the same COMP_SHORT_TX completion code.
 (xhci specs section 4.10.1.1)


Well, I can only speak for this usecase I have here with the Option
HSO modem; in this case the COMP_SHORT_TX+COMP_SUCCESS pair happens
always, as the hso driver submits a URB with a 1024 byte buffer, and
the modem usually replies with AT responses character by character;
for each character I end up getting both events: first with
COMP_SHORT_TX and the event length set to 1023, second with
COMP_SUCESS and event length set to 0.

I read the xhci specs as well and I also got the impression that there
wasn't anything explicitly stating that a COMP_SUCCESS event always
follows a COMP_SHORT_TX. But, the code already assumes that if you get
a COMP_SHORT_TX event for a TRB which isn't the last one, you should
still get an event for the last TRB (i.e. finish_td() isn't called for
a COMP_SHORT_TX event if the TRB isn't the first one (event_trb !=
ep_ring-dequeue) and if it isn't the last one (event_trb !=
td-last_trb).


 The driver checks this by seeing whether urb-actual_length == 0, but this 
 alone
 is the wrong test, as it is entirely possible for a short transfer to have an
 urb-actual_length = 0.

 This should be fixed, handling short packets look a bit messy in general 
 right now


 This patch changes the xhci driver to rely not only on the 
 urb-actual_length,
 but also on the ep_ring-last_td_was_short flag, which is set to true when a
 COMP_SHORT_TX event is received.

 This fixes a bug which affected the HSO plugin, which relies on URBs with
 urb-actual_length == 0 to halt re-submitting the RX URB in the control
 endpoint.

 Signed-off-by: Aleksander Morgado aleksan...@aleksander.es
 ---

 Hey,

 This is the third update of the patch:

  * v2 modified the commit message to make it shorter and clearer.

  * v3 updated the format of the commented lines in the patch.

 Cheers!

 ---
  drivers/usb/host/xhci-ring.c | 16 +++-
  1 file changed, 11 insertions(+), 5 deletions(-)

 diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
 index 88da8d6..eda3276 100644
 --- a/drivers/usb/host/xhci-ring.c
 +++ b/drivers/usb/host/xhci-ring.c
 @@ -1955,7 +1955,7 @@ static int process_ctrl_td(struct xhci_hcd *xhci, 
 struct xhci_td *td,
   /* Did we already see a short data
* stage? */
   *status = -EREMOTEIO;
 - } else {
 + } else if (!ep_ring-last_td_was_short) {
   td-urb-actual_length =
   td-urb-transfer_buffer_length;
   }
 @@ -2447,10 +2447,6 @@ static int handle_tx_event(struct xhci_hcd *xhci,
   ret = skip_isoc_td(xhci, td, event, ep, status);
   goto cleanup;
   }
 - if (trb_comp_code == COMP_SHORT_TX)
 - ep_ring-last_td_was_short = true;
 - else
 - ep_ring-last_td_was_short = false;

   if (ep-skip) {
   xhci_dbg(xhci, Found td. Clear skip flag.\n);
 @@ -2484,6 +2480,16 @@ static int handle_tx_event(struct xhci_hcd *xhci,
   ret = process_bulk_intr_td(xhci, td, event_trb, event,
ep, status);

 + /*
 +  * Flag whether the just processed TRB was short. Do it after
 +  * processing, so that the processor methods can also use this
 +  * flag.
 +  */
 + if (trb_comp_code == COMP_SHORT_TX)
 + ep_ring-last_td_was_short = true;
 + else
 + ep_ring-last_td_was_short = false;
 +

 How about the case where we only get one COMP_SHORT_TX event for that control 
 transfer,
 xhci then advances to the next TD, which completes successfully? That 
 successful TD won't get
 its td-urb-actual length set because the last_td_was_short flag it still 
 set

[PATCH v2] xhci: fix reporting of 0-sized URBs in control endpoint

[Aleksander Morgado]

When a control transfer has a short data stage, the xHCI controller generates
two transfer events: a COMP_SHORT_TX event that specifies the untransferred
amount, and a COMP_SUCCESS event. But when the data stage is not short, only the
COMP_SUCCESS event occurs. Therefore, xhci-hcd must set urb-actual_length to
urb-transfer_buffer_length while processing the COMP_SUCCESS event, unless
urb-actual_length was set already by a previous COMP_SHORT_TX event.

The driver checks this by seeing whether urb-actual_length == 0, but this alone
is the wrong test, as it is entirely possible for a short transfer to have an
urb-actual_length = 0.

This patch changes the xhci driver to rely not only on the urb-actual_length,
but also on the ep_ring-last_td_was_short flag, which is set to true when a
COMP_SHORT_TX event is received.

This fixes a bug which affected the HSO plugin, which relies on URBs with
urb-actual_length == 0 to halt re-submitting the RX URB in the control
endpoint.

Signed-off-by: Aleksander Morgado aleksan...@aleksander.es
---
 drivers/usb/host/xhci-ring.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 88da8d6..6b050f1 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1955,7 +1955,7 @@ static int process_ctrl_td(struct xhci_hcd *xhci, struct 
xhci_td *td,
/* Did we already see a short data
 * stage? */
*status = -EREMOTEIO;
-   } else {
+   } else if (!ep_ring-last_td_was_short) {
td-urb-actual_length =
td-urb-transfer_buffer_length;
}
@@ -2447,10 +2447,6 @@ static int handle_tx_event(struct xhci_hcd *xhci,
ret = skip_isoc_td(xhci, td, event, ep, status);
goto cleanup;
}
-   if (trb_comp_code == COMP_SHORT_TX)
-   ep_ring-last_td_was_short = true;
-   else
-   ep_ring-last_td_was_short = false;

if (ep-skip) {
xhci_dbg(xhci, Found td. Clear skip flag.\n);
@@ -2484,6 +2480,14 @@ static int handle_tx_event(struct xhci_hcd *xhci,
ret = process_bulk_intr_td(xhci, td, event_trb, event,
 ep, status);

+   /* Flag whether the just processed TRB was short. Do it after
+* processing, so that the processor methods can also use this
+* flag. */
+   if (trb_comp_code == COMP_SHORT_TX)
+   ep_ring-last_td_was_short = true;
+   else
+   ep_ring-last_td_was_short = false;
+
 cleanup:
/*
 * Do not update event ring dequeue pointer if ep-skip is set.
--
2.3.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

Re: [PATCH] xhci: fix reporting of 0-sized URBs in control endpoint

[Aleksander Morgado]

On Sat, Feb 21, 2015 at 4:34 PM, Alan Stern st...@rowland.harvard.edu wrote:
 On Sat, 21 Feb 2015, Aleksander Morgado wrote:

 Probably didn't explain well, sorry, likely mixing terms. What I mean
 is that when the data length received is equal to the transfer buffer
 length, we get a single IRQ event saying COMP_SUCCESS, with an event
 len = 0; the URB length in that case is set to be equal to the
 transfer buffer length.

 When the received data length is less that what it was requested in
 the transfer buffer length, we get 2 IRQ events: one with
 COMP_SHORT_TX status and the event length giving the 'unfilled' size
 of the buffer; and one with COMP_SUCCESS status and an event length
 set to 0. In this case, the URB length is set when the first event
 arrived, not when the second one arrived.

 The missing use case I'm trying to cover is when we do get 2 IRQ
 events for the same TD: one with COMP_SHORT_TX but where the
 unfilled length is equal to the transfer buffer length (hence, 0
 bytes transferred), and the second event with COMP_SUCCESS.

 It sounds like this should be handled in the same way as the previous
 case, but it isn't because of the peculiar way the driver is written.

 The current logic sets the final URB length in 2 different cases:
  * If the transferred length is equal to the transfer buffer length,
 the URB length is set when the event for the last TRB is received,
 notifying COMP_SUCESSS.
  * If the transferred length is less than the transfer buffer length
 but  0, the URB length is set when the COMP_SHORT_TX event arrives;
 when the COMP_SUCCESS one arrives the URB length that was previously
 set is not modified.

 Now, there is this 3rd case, where the transferred length is 0; in
 this case we get both COMP_SHORT_TX and COMP_SUCCESS events; and the
 first one states that the untransferred length is equal to the
 transfer buffer length. With this patch in, which truth be told seems
 a bit like a hack (is there any cleaner way?), the case is covered,
 and we do get the 0-length URB notified.

 I see the problem.  The driver needs to distinguish between two cases:
 COMP_SHORT_TX previously received and COMP_SHORT_TX not previously
 received.  The driver uses actual_length == 0 to make this distinction,
 but that is not correct because it is possible to have actual_length ==
 0 even after a COMP_SHORT_TX event.  Using the last_td_was_short flag
 instead seems like a reasonable solution.

 Currently the xhci driver doesn't report 0-sized URBs in the control
 endpoint, and that totally breaks the HSO driver usecase (which relies
 on the 0-sized URBs to stop re-submitting the RX URB), so Option HSO
 modems don't work properly on USB3 ports :/

 Clearly this is a bug.

 Can also reword the commit message to try to make it clearer.
 Actually, I talk about COMP_SHORT_SUCCESS in the commit message when
 it really is COMP_SUCCESS... Just let me know how to move it forward
 :)

 In general, shorter commit messages are easier to understand.  Try to
 avoid the tendency to report too much information.  :-)

 It wouldn't hurt simply to explain the situation as you did to me just
 now (but perhaps in a more consise form).  Something like this:

 When a control transfer has a short data stage, the xHCI
 controller generates two transfer events: a COMP_SHORT_TX event
 that includes the untransferred amount, and a COMP_SUCCESS
 event.  But when the data stage is not short, only the
 COMP_SUCCESS event occurs.

 Therefore, xhci-hcd must set urb-actual_length to
 urb-transfer_buffer_length while processing the COMP_SUCCESS
 event, unless actual_length was set previously.  The driver
 checks this by seeing whether actual_length == 0.  But this is
 the wrong test, because it is entirely possible for a short
 transfer to have an actual_length of 0.

 This patch changes the driver to use the last_td_was_short flag
 instead of checking actual_length.  This fixes a bug affecting
 the HSO plugin ... etc.


I think that part of the mess in the long explanation was because I
was trying to explain to myself the issue in the first place. But yes,
as soon as the issue is understood, a shorter explanation is clearly
more efficient. I'll resubmit the patch with the shorter explanation.
Thanks!

-- 
Aleksander
https://aleksander.es
--
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] xhci: fix reporting of 0-sized URBs in control endpoint

[Aleksander Morgado]

Hey Alan,

On Sat, Feb 21, 2015 at 3:47 AM, Alan Stern st...@rowland.harvard.edu wrote:
 On Sat, 21 Feb 2015, Aleksander Morgado wrote:

 When the control TD doesn't have TRBs in the data stage, the URB actual 
 length
 is set equal to the transfer buffer length. E.g. with a 64 byte transfer 
 buffer
 length:

   Transfer event len = 0, COMP_SHORT_SUCCESS  (status)
|- URB actual length set to transfer buffer length = 64

 How can a control TD have a transfer buffer length that is  0 and also
 have no TRBs in the data stage?  That doesn't make sense.


Probably didn't explain well, sorry, likely mixing terms. What I mean
is that when the data length received is equal to the transfer buffer
length, we get a single IRQ event saying COMP_SUCCESS, with an event
len = 0; the URB length in that case is set to be equal to the
transfer buffer length.


 When the control TD has TRBs in the data stage, the URB actual length is
 computed based on the transfer event length reported in the data stage TRB. 
 In
 this case, the URB actual length won't be modified in the status stage. E.g.
 again with a 64 byte transfer buffer length:

   Transfer event len = 63, COMP_SHORT_TX (data)
|- URB actual length = 64 - 63 = 1
   Transfer event len = 0, COMP_SHORT_SUCCESS (status)
|- URB actual length not modified = 1


When the received data length is less that what it was requested in
the transfer buffer length, we get 2 IRQ events: one with
COMP_SHORT_TX status and the event length giving the 'unfilled' size
of the buffer; and one with COMP_SUCCESS status and an event length
set to 0. In this case, the URB length is set when the first event
arrived, not when the second one arrived.

 The current logic, though, doesn't seem to contemplate the case where a TD 
 has a
 TDR in the data stage which actually reports 0 bytes (i.e. transfer event len
 equal to transfer buffer len). The logic is currently handling this case in 
 the
 following way:

   Transfer event len = 64, COMP_SHORT_TX (data)
|- URB actual length = 64 - 64 = 0
   Transfer event len = 0, COMP_SHORT_SUCCESS (status)
|- URB actual length set to transfer buffer length = 64   --

 In this case, the logic shouldn't update the URB actual length during the 
 status
 stage; instead it should leave the URB actual length that was computed during
 the data stage, even if it's 0:

   Transfer event len = 63, COMP_SHORT_TX (data)
|- URB actual length = 64 - 64 = 0
   Transfer event len = 0, COMP_SHORT_SUCCESS (status)
|- URB actual length not modified = 0 --

 In fact, is there _ever_ any reason for changing the actual length
 during the status stage?  It seems to me that by the end of the data
 stage, we already know the actual length.


The missing use case I'm trying to cover is when we do get 2 IRQ
events for the same TD: one with COMP_SHORT_TX but where the
unfilled length is equal to the transfer buffer length (hence, 0
bytes transferred), and the second event with COMP_SUCCESS.

 The proposed fix re-uses the 'last_td_was_short' flag in the endpoint ring. 
 The
 setting of this flag is moved to after the actual TRB processing, so that the
 flag value indicating whether the last TRB was short can be read during the
 processing. The control TDR processing will use this flag to determine 
 whether
 it has to reset the URB actual length or instead leave it as it was already
 precomputed by the previous short TRB.

 Why not always leave the actual length as is?


The current logic sets the final URB length in 2 different cases:
 * If the transferred length is equal to the transfer buffer length,
the URB length is set when the event for the last TRB is received,
notifying COMP_SUCESSS.
 * If the transferred length is less than the transfer buffer length
but  0, the URB length is set when the COMP_SHORT_TX event arrives;
when the COMP_SUCCESS one arrives the URB length that was previously
set is not modified.

Now, there is this 3rd case, where the transferred length is 0; in
this case we get both COMP_SHORT_TX and COMP_SUCCESS events; and the
first one states that the untransferred length is equal to the
transfer buffer length. With this patch in, which truth be told seems
a bit like a hack (is there any cleaner way?), the case is covered,
and we do get the 0-length URB notified.

Currently the xhci driver doesn't report 0-sized URBs in the control
endpoint, and that totally breaks the HSO driver usecase (which relies
on the 0-sized URBs to stop re-submitting the RX URB), so Option HSO
modems don't work properly on USB3 ports :/

Can also reword the commit message to try to make it clearer.
Actually, I talk about COMP_SHORT_SUCCESS in the commit message when
it really is COMP_SUCCESS... Just let me know how to move it forward
:)

-- 
Aleksander
https://aleksander.es
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord

[PATCH] xhci: fix reporting of 0-sized URBs in control endpoint

[Aleksander Morgado]

When the control TD doesn't have TRBs in the data stage, the URB actual length
is set equal to the transfer buffer length. E.g. with a 64 byte transfer buffer
length:

  Transfer event len = 0, COMP_SHORT_SUCCESS  (status)
   |- URB actual length set to transfer buffer length = 64

When the control TD has TRBs in the data stage, the URB actual length is
computed based on the transfer event length reported in the data stage TRB. In
this case, the URB actual length won't be modified in the status stage. E.g.
again with a 64 byte transfer buffer length:

  Transfer event len = 63, COMP_SHORT_TX (data)
   |- URB actual length = 64 - 63 = 1
  Transfer event len = 0, COMP_SHORT_SUCCESS (status)
   |- URB actual length not modified = 1

The current logic, though, doesn't seem to contemplate the case where a TD has a
TDR in the data stage which actually reports 0 bytes (i.e. transfer event len
equal to transfer buffer len). The logic is currently handling this case in the
following way:

  Transfer event len = 64, COMP_SHORT_TX (data)
   |- URB actual length = 64 - 64 = 0
  Transfer event len = 0, COMP_SHORT_SUCCESS (status)
   |- URB actual length set to transfer buffer length = 64   --

In this case, the logic shouldn't update the URB actual length during the status
stage; instead it should leave the URB actual length that was computed during
the data stage, even if it's 0:

  Transfer event len = 63, COMP_SHORT_TX (data)
   |- URB actual length = 64 - 64 = 0
  Transfer event len = 0, COMP_SHORT_SUCCESS (status)
   |- URB actual length not modified = 0 --

The proposed fix re-uses the 'last_td_was_short' flag in the endpoint ring. The
setting of this flag is moved to after the actual TRB processing, so that the
flag value indicating whether the last TRB was short can be read during the
processing. The control TDR processing will use this flag to determine whether
it has to reset the URB actual length or instead leave it as it was already
precomputed by the previous short TRB.

The background for this change is that the HSO plugin will resubmit the control
RX URB until zero bytes get read. Without this fix, the reported URB actual
length never reached this situation as all reported URBs had actual length  0,
and the driver ended up entering in an infinite loop of URB resubmissions
reading zeroes all the time, as in the following HSO debug logs:

  --- Got muxed ctrl callback 0x00 ---
  [  +0,08] [1997:ctrl_callback]: Actual length of urb = 1
  --- Got muxed ctrl callback 0x00 ---
  [  +0,06] [1997:ctrl_callback]: Actual length of urb = 1
  --- Got muxed ctrl callback 0x00 ---
  [  +0,07] [1997:ctrl_callback]: Actual length of urb = 1
  --- Got intr callback 0x00 ---
  [  +0,06] [1880:intr_callback]:  port_req = 0x01
  [  +0,04] [1888:intr_callback]: Pending read interrupt on port 0
  --- Got muxed ctrl callback 0x00 ---
  [  +0,07] [1997:ctrl_callback]: Actual length of urb = 6
  [  +0,04] [2035:put_rxbuf_data]: data to push to tty
  --- Got muxed ctrl callback 0x00 ---
  [  +0,06] [1997:ctrl_callback]: Actual length of urb = 1024
  [  +0,04] [2035:put_rxbuf_data]: data to push to tty
  --- Got muxed ctrl callback 0x00 ---
  [  +0,06] [1997:ctrl_callback]: Actual length of urb = 1024
  [  +0,03] [2035:put_rxbuf_data]: data to push to tty
  --- Got muxed ctrl callback 0x00 ---
  [  +0,06] [1997:ctrl_callback]: Actual length of urb = 1024
  [  +0,04] [2035:put_rxbuf_data]: data to push to tty
  .

Signed-off-by: Aleksander Morgado aleksan...@aleksander.es
---
 drivers/usb/host/xhci-ring.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 88da8d6..6b050f1 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1955,7 +1955,7 @@ static int process_ctrl_td(struct xhci_hcd *xhci, struct 
xhci_td *td,
/* Did we already see a short data
 * stage? */
*status = -EREMOTEIO;
-   } else {
+   } else if (!ep_ring-last_td_was_short) {
td-urb-actual_length =
td-urb-transfer_buffer_length;
}
@@ -2447,10 +2447,6 @@ static int handle_tx_event(struct xhci_hcd *xhci,
ret = skip_isoc_td(xhci, td, event, ep, status);
goto cleanup;
}
-   if (trb_comp_code == COMP_SHORT_TX)
-   ep_ring-last_td_was_short = true;
-   else
-   ep_ring-last_td_was_short = false;
 
if (ep-skip) {
xhci_dbg(xhci, Found td. Clear skip flag.\n);
@@ -2484,6 +2480,14 @@ static int

Re: [PATCH] xhci: fix reporting of 0-sized URBs in control endpoint

[Aleksander Morgado]

On Sat, Feb 21, 2015 at 1:18 AM, Aleksander Morgado
aleksan...@aleksander.es wrote:
 The current logic, though, doesn't seem to contemplate the case where a TD 
 has a
 TDR in the data stage which actually reports 0 bytes (i.e. transfer event len
 equal to transfer buffer len). The logic is currently handling this case in 
 the
 following way:

   Transfer event len = 64, COMP_SHORT_TX (data)
|- URB actual length = 64 - 64 = 0
   Transfer event len = 0, COMP_SHORT_SUCCESS (status)
|- URB actual length set to transfer buffer length = 64   --

 In this case, the logic shouldn't update the URB actual length during the 
 status
 stage; instead it should leave the URB actual length that was computed during
 the data stage, even if it's 0:

   Transfer event len = 63, COMP_SHORT_TX (data)

So much for re-reading the patch 10 times before sending it...  The
Transfer event len in this previous line should be 64, not 63.

|- URB actual length = 64 - 64 = 0
   Transfer event len = 0, COMP_SHORT_SUCCESS (status)
|- URB actual length not modified = 0 --


-- 
Aleksander
https://aleksander.es
--
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_mbim with Huawei E3372, nothing works

[Aleksander Morgado]

On Tue, Feb 17, 2015 at 4:32 PM, Sami Farin hvtaifwkbgefb...@gmail.com wrote:
 I have this USB ID 12d1:157d, Sonera Opengate LTE.
 It says all is okay but no packets are moving.
 With the SIM card in Lumia I get 50/25 Mbit/s.

 linux 3.19, Fedora 21, usb-modeswitch-2.2.1, usb_modeswitch-data 20150115, 
 Asus P8Z68-V PRO GEN3,
 NetworkManager-1.0.0-4.fc22, libmbim-1.12.0-1.fc22, ModemManager-1.4.4-1
 (tried USB 2 and USB 3 ports).

 In NetworkManager, setting Use only 4G does not work, it switches back to 
 Any.


That setting doesn't do anything any more with ModemManager 1.x. Plus,
MBIM modems won't allow to lock e.g. to 4G-only, so that's why it
always goes back to Any.

 usb_modeswitch log

 USB_ModeSwitch log from Thu Feb 12 21:58:45 EET 2015

 Use global config file: /etc/usb_modeswitch.conf
 Raw args from udev: /3-1:1.0

 Use top device dir /sys/bus/usb/devices/3-1

 
 USB values from sysfs:
 manufacturerHUAWEI_MOBILE
 product HUAWEI_MOBILE
 serial  0123456789ABCDEF
 
 ConfigList: /etc/usb_modeswitch.d/12d1:157d
 SCSI attributes not needed, move on
 Check config: /etc/usb_modeswitch.d/12d1:157d
 ! matched. Read config data
 Use config file from override folder /etc/usb_modeswitch.d
 Logger is /usr/bin/logger
 config: TargetVendor set to 12d1
 config: TargetProduct set to 14db
 Driver module is option, ID path is /sys/bus/usb-serial/drivers/option1

 Device may have an MBIM configuration, check driver ...
 driver for MBIM devices is available
 Find MBIM configuration number ...
 Command to be run:
 usb_modeswitch -W -D -s 20 -b 3 -g 31 -v 12d1 -p 157d -f $configBuffer

 Verbose debug output of usb_modeswitch and libusb follows
 (Note that some USB errors are to be expected in the process)
 

 Read long config from command line

 * usb_modeswitch: handle USB devices with multiple modes
 * Version 2.2.0 (C) Josua Dietze 2014
 * Based on libusb1/libusbx

 ! PLEASE REPORT NEW CONFIGURATIONS !

 DefaultVendor= 0x12d1
 DefaultProduct= 0x157d
 NeedResponse=0
 Configuration=0x02
 Success check enabled, max. wait time 20 seconds
 System integration mode enabled

 Use given bus/device number: 003/031 ...
 Note: No target parameter given; success check limited
 Look for default devices ...
 bus/device number matched
 found USB ID 12d1:157d
 vendor ID matched
 product ID matched
 Get the current device configuration ...
 device configuration 1 not matching target
 count device
 Found devices in default mode (1)
 Current configuration number is 1
 Use interface number 0

 USB description data (for identification)
 -
 Manufacturer: HUAWEI_MOBILE
 Product: HUAWEI_MOBILE
 Serial No.: 0123456789ABCDEF
 -
 Change configuration to 2 ...
 Device is busy, try to detach kernel driver
 Looking for active driver ...
 OK, driver detached
 OK, configuration set
 Get the current device configuration ...
 The configuration was set successfully
 Bus/dev search active, refer success check to wrapper. Bye!

 ok:busdev
 
 (end of usb_modeswitch output)

 Check success of mode switch for max. 20 seconds ...
 Read attributes ...
 All attributes matched
 Mode switching was successful, found 12d1:157d (HUAWEI_MOBILE: HUAWEI_MOBILE)
 Check for AVOID_RESET_QUIRK kernel attribute
 AVOID_RESET_QUIRK activated

 All done, exit



 ifconfig
 wwp3s0u1c2: flags=4291UP,BROADCAST,RUNNING,NOARP,MULTICAST  mtu 1500
 inet 46.132.188.224  netmask 255.255.255.192  broadcast 46.132.188.255
 inet6 fe80::  prefixlen 64  scopeid 0x20link
 ether 32:35:3a:64:2e:25  txqueuelen 1000  (Ethernet)
 RX packets 0  bytes 0 (0.0 B)
 RX errors 17764  dropped 0  overruns 0  frame 0
 TX packets 6714  bytes 18446744073709268911 (1638.3 PiB)
 TX errors 1427  dropped 0 overruns 0  carrier 0  collisions 0


That's a ton of RX errors in there, and an... unusual number of TX
bytes as well.

Bjørn, any idea?



 lsusb

 Bus 003 Device 017: ID 12d1:157d Huawei Technologies Co., Ltd.
 Device Descriptor:
   bLength18
   bDescriptorType 1
   bcdUSB   2.10
   bDeviceClass0 (Defined at Interface level)
   bDeviceSubClass 0
   bDeviceProtocol   255
   bMaxPacketSize064
   idVendor   0x12d1 Huawei Technologies Co., Ltd.
   idProduct  0x157d
   bcdDevice1.02
   iManufacturer   1 HUAWEI_MOBILE
   iProduct2 HUAWEI_MOBILE
   iSerial 3 0123456789ABCDEF
   bNumConfigurations  2
   Configuration Descriptor:
 bLength 9
 bDescriptorType 2
 wTotalLength   32
 bNumInterfaces  1
 bConfigurationValue 1
 iConfiguration  0
 bmAttributes 0xa0
   (Bus Powered)
   Remote Wakeup
 MaxPower2mA
 Interface Descriptor:
   bLength 9

Re: cdc_mbim with Huawei E3372, nothing works

[Aleksander Morgado]

On Tue, Feb 17, 2015 at 5:50 PM, Sami Farin hvtaifwkbgefb...@gmail.com wrote:
 On Tue, Feb 17, 2015 at 17:32:40 +0100, Aleksander Morgado wrote:
 On Tue, Feb 17, 2015 at 4:32 PM, Sami Farin hvtaifwkbgefb...@gmail.com 
 wrote:
  I have this USB ID 12d1:157d, Sonera Opengate LTE.
  It says all is okay but no packets are moving.
  With the SIM card in Lumia I get 50/25 Mbit/s.
 
  linux 3.19, Fedora 21, usb-modeswitch-2.2.1, usb_modeswitch-data 20150115, 
  Asus P8Z68-V PRO GEN3,
  NetworkManager-1.0.0-4.fc22, libmbim-1.12.0-1.fc22, ModemManager-1.4.4-1
  (tried USB 2 and USB 3 ports).
 
  In NetworkManager, setting Use only 4G does not work, it switches back 
  to Any.
 

 That setting doesn't do anything any more with ModemManager 1.x. Plus,
 MBIM modems won't allow to lock e.g. to 4G-only, so that's why it
 always goes back to Any.

 Maybe if some thing, like NetworkManager told that to me..  would be nice.


There are plans to remove that from the connection settings (where it
currently is) and let e.g. the gnome-control-center be able to allow
switching modes and capabilities directly (without being tied to a
connection setting).

 Dovado advertizes 4G bandlocking support [e.g. in their Pro model] for Huawei 
 E3372,
 I don't know what tricks they do..


The modem supports it, sure; it's just the MBIM protocol the one which
doesn't. There may be ways to do it, e.g. directly over AT commands
using a TTY or embedding AT in MBIM. ModemManager won't do that (yet)
when using MBIM, though.

 ...
  Saving state... (TRID: 6)
  Attaching to packet service with 'mbimcli -d /dev/cdc-wdm0 
  --attach-packet-service --no-open=6 --no-close'...
  Saving state... (TRID: 7)
  Starting network with 'mbimcli -d /dev/cdc-wdm0 --connect= --no-open=7 
  --no-close'...
  error: couldn't parse input string, missing arguments

 You didn't configure APN to use in mbim-network. You need to setup a
 /etc/mbim-network.conf file with the APN to use.

 Well, I am just trying all kinds of things, I have two weeks to test this
 modem and return it if it does not work.
 Besides, mbim-network does not seem to have documentation.


Yeah, no real docs for mbim-network; never thought it would end up
being used that much.

  Network start failed
  [/dev/cdc-wdm0] Session not closed: TRID: '7'
  Saving state... (TRID: 7)
 
  # mbim-network /dev/cdc-wdm0 status
  Loading previous state...
  Previous Transaction ID: 7
  Getting status with 'mbimcli -d /dev/cdc-wdm0 --query-connection-state 
  --no-close --no-open=7'...
  error: operation failed: Transaction timed out
  Saving state... (TRID: 8)
  error: couldn't get connection status
 

 This is likely an error due to the leftover logic in mbim-network.

 I don't mind, if NetworkManager sets things correctly.

 
  # mmcli -m 1 --simple-status
 
  /org/freedesktop/ModemManager1/Modem/1
-
Status |  state: 'connected'
   | signal quality: '80' (recent)
   |  bands: 'unknown'
   |access tech: 'lte'
-
3GPP   |   registration: 'home'
   |  operator code: '24491'
   |  operator name: 'FI SONERA'
   |   subscription: 'unknown'
 
 

 That status looks ok in ModemManager.

 That's good.
 Isn't there any debug features for CDC?  I'd like to see something in dmesg
 when I get 200 errors a second..


Try to gather usbmon traces, that should help.

-- 
Aleksander
https://aleksander.es
--
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] hso: always read interface number from the current altsetting

[Aleksander Morgado]

Always read bInterfaceNumber from the current altsetting, not from the first one
available in the altsetting array. This is coming from code review, not related
to any specific bug.

Signed-off-by: Aleksander Morgado aleksan...@aleksander.es
---
 drivers/net/usb/hso.c | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/hso.c
index 9cdfb3f..3c8dfe5 100644
--- a/drivers/net/usb/hso.c
+++ b/drivers/net/usb/hso.c
@@ -1477,6 +1477,7 @@ static void tiocmget_intr_callback(struct urb *urb)
struct uart_icount *icount;
struct hso_serial_state_notification *serial_state_notification;
struct usb_device *usb;
+   struct usb_interface *interface;
int if_num;
 
/* Sanity checks */
@@ -1494,7 +1495,9 @@ static void tiocmget_intr_callback(struct urb *urb)
BUG_ON((serial-parent-port_spec  HSO_PORT_MASK) != HSO_PORT_MODEM);
 
usb = serial-parent-usb;
-   if_num = serial-parent-interface-altsetting-desc.bInterfaceNumber;
+   interface = serial-parent-interface;
+
+   if_num = interface-cur_altsetting-desc.bInterfaceNumber;
 
/* wIndex should be the USB interface number of the port to which the
 * notification applies, which should always be the Modem port.
@@ -1675,6 +1678,7 @@ static int hso_serial_tiocmset(struct tty_struct *tty,
unsigned long flags;
int if_num;
struct hso_serial *serial = tty-driver_data;
+   struct usb_interface *interface;
 
/* sanity check */
if (!serial) {
@@ -1685,7 +1689,8 @@ static int hso_serial_tiocmset(struct tty_struct *tty,
if ((serial-parent-port_spec  HSO_PORT_MASK) != HSO_PORT_MODEM)
return -EINVAL;
 
-   if_num = serial-parent-interface-altsetting-desc.bInterfaceNumber;
+   interface = serial-parent-interface;
+   if_num = interface-cur_altsetting-desc.bInterfaceNumber;
 
spin_lock_irqsave(serial-serial_lock, flags);
if (set  TIOCM_RTS)
@@ -2808,7 +2813,7 @@ static int hso_get_config_data(struct usb_interface 
*interface)
 {
struct usb_device *usbdev = interface_to_usbdev(interface);
u8 *config_data = kmalloc(17, GFP_KERNEL);
-   u32 if_num = interface-altsetting-desc.bInterfaceNumber;
+   u32 if_num = interface-cur_altsetting-desc.bInterfaceNumber;
s32 result;
 
if (!config_data)
@@ -2886,7 +2891,7 @@ static int hso_probe(struct usb_interface *interface,
return -ENODEV;
}
 
-   if_num = interface-altsetting-desc.bInterfaceNumber;
+   if_num = interface-cur_altsetting-desc.bInterfaceNumber;
 
/* Get the interface/port specification from either driver_info or from
 * the device itself */
-- 
2.3.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

ehci vs xhci: zero-length packet received in control endpoint handled differently?

[Aleksander Morgado]

Hey,

I've been trying to debug the issue I have with my Option Globetrotter
modem, handled by the 'hso' driver.

One thing the driver does is to re-submit the RX urb in the control
endpoint if the urb-actual_length is  0:

put_rxbuf_data_and_resubmit_ctrl_urb ()
{
...
/* Re issue a read as long as we receive data. */
if (count == 0  ((urb-actual_length != 0) ||
(serial-rx_state == RX_PENDING))) {
serial-rx_state = RX_SENT;
hso_mux_serial_read(serial);
} else
serial-rx_state = RX_IDLE;
}

The thing is that (urb-actual_length == 0) never seems to happen with
the xhci driver.

When using the ehci driver, we do get that condition, see hso debug
logs when the modem sends back two characters (AT echo in the TTY):
  [  +0,05] [1995:ctrl_callback]: Actual length of urb = 1
  [  +0,05] [1995:ctrl_callback]: Actual length of urb = 1
  [  +0,05] [1995:ctrl_callback]: Actual length of urb = 0
After the last urb, rx_state would go to RX_IDLE.

When using the xhci driver,  we never get the actual_length set to 0,
instead, it is reset to transfer_buffer_length (1024 here) before it
reaches the hso driver. Equivalent logs would be:
  [  +0,05] [1995:ctrl_callback]: Actual length of urb = 1
  [  +0,05] [1995:ctrl_callback]: Actual length of urb = 1
  [  +0,05] [1995:ctrl_callback]: Actual length of urb = 1024
  [  +0,05] [1995:ctrl_callback]: Actual length of urb = 1024
  [  +0,05] [1995:ctrl_callback]: Actual length of urb = 1024
  [  +0,05] [1995:ctrl_callback]: Actual length of urb = 1024
  [  +0,05] [1995:ctrl_callback]: Actual length of urb = 1024
  
And it goes like that forever.

The issue is not only that the hso driver ends up getting in a loop
where the RX urb is continuously resubmitted, but also, the hso driver
will actually take all those 1024 bytes as data, and feed them as
output of the TTY (which is what e.g. ModemManager sees, a bunch of
NUL bytes interleaved with AT responses).

Looking at the xhci code, and after adding some additional debug logs,
the urb-actual_length is reset to transfer_buffer_length in the
following place:

process_ctrl_td()
{
...
/*
 * Did we transfer any data, despite the errors that might have
 * happened?  I.e. did we get past the setup stage?
 */
if (event_trb != ep_ring-dequeue) {
/* The event was for the status stage */
if (event_trb == td-last_trb) {
if (td-urb-actual_length != 0) {
...
} else {
td-urb-actual_length =
td-urb-transfer_buffer_length;
}
}
...
}
...
}

actual_length passes from being 0 to transfer_buffer_length, which is
what I see in the hso driver logs.

Now, what would be the thing to fix? Shouldn't ehci and xhci behave in
the same way w.r.t. this zero-length packet? Or is it the hso driver
the one needing a fix?

Cheers,

-- 
Aleksander
https://aleksander.es
--
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] hso: fix rx parsing logic when skb allocation fails

[Aleksander Morgado]

If skb allocation fails once the IP header has been received, the rx state is
being set to WAIT_SYNC. The logic, though, shouldn't directly return, as the
buffer may contain a full packet, and therefore the WAIT_SYNC state needs to be
processed (resetting state to WAIT_IP, clearing rx_buf_size and re-initializing
rx_buf_missing).

So, just let the while loop continue so that in the next iteration the WAIT_SYNC
state cleanly stops the loop. The WAIT_SYNC processing will be done just after
that, only if the end of packet is flagged.

Signed-off-by: Aleksander Morgado aleksan...@aleksander.es
---
 drivers/net/usb/hso.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/hso.c
index 6b8efca..9cdfb3f 100644
--- a/drivers/net/usb/hso.c
+++ b/drivers/net/usb/hso.c
@@ -914,7 +914,7 @@ static void packetizeRx(struct hso_net *odev, unsigned char 
*ip_pkt,
/* We got no receive buffer. */
D1(could not allocate memory);
odev-rx_parse_state = WAIT_SYNC;
-   return;
+   continue;
}
 
/* Copy what we got so far. make room for iphdr
-- 
2.3.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

Option HSO tty returning NUL bytes read continuously in USB3 port

[Aleksander Morgado]

Hey,

I'm trying to understand why this Option Globetrotter modem
(net/usb/hso driver, 0af0:6971) ends up returning NUL bytes read
continuously in the TTY when plugged in a USB3 port but not in a USB2
one.

I'm testing this with a 3.18.6 kernel plus a self-compiled hso driver
from net-next; but I had realized about this issue quite some time
ago, so it's likely not a new thing.

ATI output:
  Manufacturer: Option N.V.
  Model: GlobeTrotter HSDPA Modem
  Revision: 2.5.13Hd (Date: Feb 18 2008, Time: 18:32:40)

The device ends up handled like this in the usb tree:
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M
|__ Port 1: Dev 4, If 0, Class=Vendor Specific Class, Driver=hso, 12M
|__ Port 1: Dev 4, If 1, Class=Vendor Specific Class, Driver=hso, 12M
|__ Port 1: Dev 4, If 2, Class=Vendor Specific Class, Driver=hso, 12M

I just need to plug in the modem, and send something to the TTY (e.g.
using minicom) and the modem ends up in a cycle of sending NUL bytes,
see driver/usbmon logs below.

[  +7,092221] hso: /home/aleksander/Development/foss/hso/hso.c: Option Wireless
[  +0,58] [2419:hso_net_init]: sizeof hso_net is 200
[  +0,000642] usbcore: registered new interface driver hso

 $ sudo minicom -D /dev/ttyHS0

[feb11 20:24] [1278:hso_serial_open]: Opening 0
[  +0,06] [1119:_hso_serial_set_termios]: port 0
[  +0,25] [1416:hso_serial_set_termios]: Termios called with:
cflags new[7346] - old[5298]
[  +0,03] [1119:_hso_serial_set_termios]: port 0
[  +0,07] [1416:hso_serial_set_termios]: Termios called with:
cflags new[-2147476302] - old[7346]
[  +0,02] [1119:_hso_serial_set_termios]: port 0
[  +0,07] [1416:hso_serial_set_termios]: Termios called with:
cflags new[-2147476302] - old[-2147476302]
[  +0,03] [1119:_hso_serial_set_termios]: port 0
[  +0,04] [1416:hso_serial_set_termios]: Termios called with:
cflags new[-2147476302] - old[-2147476302]
[  +0,03] [1119:_hso_serial_set_termios]: port 0
[  +0,023639] [1876:intr_callback]:
--- Got intr callback 0x00 ---
[  +0,06] [1880:intr_callback]:  port_req = 0x02
[  +0,04] [1888:intr_callback]: Pending read interrupt on port 1
[  +0,03] [1901:intr_callback]: Already a read pending on port 1
or port not open
[  +0,031998] [1876:intr_callback]:
--- Got intr callback 0x00 ---
[  +0,06] [1880:intr_callback]:  port_req = 0x02
[  +0,05] [1888:intr_callback]: Pending read interrupt on port 1
[  +0,03] [1901:intr_callback]: Already a read pending on port 1
or port not open

minicom$ ATenter

--- Got muxed ctrl callback 0x00 ---
[  +0,08] [1997:ctrl_callback]: Actual length of urb = 1
[  +0,335992] [1996:ctrl_callback]:
--- Got muxed ctrl callback 0x00 ---
[  +0,06] [1997:ctrl_callback]: Actual length of urb = 1
[  +1,048984] [1996:ctrl_callback]:
--- Got muxed ctrl callback 0x00 ---
[  +0,07] [1997:ctrl_callback]: Actual length of urb = 1
[  +0,019000] [1876:intr_callback]:
--- Got intr callback 0x00 ---
[  +0,06] [1880:intr_callback]:  port_req = 0x01
[  +0,04] [1888:intr_callback]: Pending read interrupt on port 0
[  +0,002989] [1996:ctrl_callback]:
--- Got muxed ctrl callback 0x00 ---
[  +0,07] [1997:ctrl_callback]: Actual length of urb = 6
[  +0,04] [2035:put_rxbuf_data]: data to push to tty
[  +0,002982] [1996:ctrl_callback]:
--- Got muxed ctrl callback 0x00 ---
[  +0,06] [1997:ctrl_callback]: Actual length of urb = 1024
[  +0,04] [2035:put_rxbuf_data]: data to push to tty
[  +0,002934] [1996:ctrl_callback]:
--- Got muxed ctrl callback 0x00 ---
[  +0,06] [1997:ctrl_callback]: Actual length of urb = 1024
[  +0,03] [2035:put_rxbuf_data]: data to push to tty
[  +0,003052] [1996:ctrl_callback]:
--- Got muxed ctrl callback 0x00 ---
[  +0,06] [1997:ctrl_callback]: Actual length of urb = 1024
[  +0,04] [2035:put_rxbuf_data]: data to push to tty
[  +0,002933] [1996:ctrl_callback]:
--- Got muxed ctrl callback 0x00 ---
[  +0,04] [1997:ctrl_callback]: Actual length of urb = 1024
[  +0,03] [2035:put_rxbuf_data]: data to push to tty
[  +0,003045] [1996:ctrl_callback]:
--- Got muxed ctrl callback 0x00 ---
[  +0,06] [1997:ctrl_callback]: Actual length of urb = 1024
[  +0,04] [2035:put_rxbuf_data]: data to push to tty
[  +0,002994] [1996:ctrl_callback]:
--- Got muxed ctrl callback 0x00 ---
[  +0,06] [1997:ctrl_callback]: Actual length of urb = 1024
[  +0,04] [2035:put_rxbuf_data]: data to push to tty
[  +0,002956] [1996:ctrl_callback]:
--- Got muxed ctrl callback 0x00 ---
[  +0,05] [1997:ctrl_callback]: Actual length of urb = 1024
[  +0,03] [2035:put_rxbuf_data]: data to push to tty
[  +0,002990] [1996:ctrl_callback]:
--- Got muxed ctrl callback 0x00 ---
[  +0,05] [1997:ctrl_callback]: Actual length of urb = 1024


usbmon output looks like:
8800b898b240 3929042350 S Ii:1:004:5 -115:128 1 
8800b898b240 3929059968 C Ii:1:004:5 0:128 1 = 02

Re: Understanding what's going on when using a Huawei E173 USB 3G web-stick (UMTS/HSPA)

[Aleksander Morgado]

 NetworkManager uses ModemManager for all WWAN control, NM only handles
 the configuration storage and IP addressing parts of the setup.
 ModemManager handles modem hardware detection, capability detection,
 WWAN registration and setup, signal strength reporting, network
 connection initiation, and bearer IP addressing method determination.

 If you want more information from ModemManager, you can run mmcli
 --help or mmcli --set-logging=debug.


That (mmcli) will only be available in ModemManager = 1.x, BTW. And
beware of --set-logging=debug, as syslog may limit those if MM sends
too many too fast. In general I usually prefer to ask for --debug
output just in case:
http://www.freedesktop.org/wiki/Software/ModemManager/Debugging/

I saw the reporter talk about Ubuntu Precise (12.04) and Trusty
(14.04), so only in the latter mmcli will be available (if I'm not
mistaken). For Precise, this Ubuntu page shows how to enable debug
logs:
https://wiki.ubuntu.com/DebuggingModemmanager

-- 
Aleksander
https://aleksander.es
--
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: bugreport: huawei_cdc_ncm control device freezes for 3-5 minutes on connect with E3276 LTE modem

[Aleksander Morgado]

On Fri, Oct 3, 2014 at 10:01 AM, Erik Alapää erik.ala...@gmail.com wrote:
 Problem: When connecting to a Huawei E3276 LTE modem using
 'AT+CGACT=1,1' in minicom over /dev/cdc-wdm1, the cdc-wdm device
 freezes for 3-5 minutes until accepting AT commands again.

 Keywords: huawei_cdc_ncm, LTE, AT commands, cdc-wdm

 Detailed problem description:

 I am using a 4G mobile USB dongle with the huawei_cdc_ncm driver in
 Linux kernel 3.16. In general, the driver works well, but one major
 issue is that bringing the modem up using 'AT+CGACT=1.1' freezes the
 /dev/cdc-wdm1 control device for 3-5 minutes. After that, the device
 accepts more commands over minicom. Note that I do get connectivity,
 directly after the CGACT I can get a DHCP address for wwan0 and the
 bandwidth is approx 20 Mbit/s downstream and 6 Mbit/s upstream.

 I have tried building a custom 3.16 kernel with a few printk:s in
 cdc_ncm.c and huawei_cdc_ncm.c, but found nothing suspicious.

 Kernel version (from /proc/version): 3.16
 Environment: Thinkpad L440 64-bit x86 (Intel Core i5-4200M cpu) laptop
 with Kubuntu 14.04.1 LTS
 Kernel modules: huawei_cdc_ncm,cdc_ncm

 Workaround: Bring up the device with
 AT^NDISDUP=1,1,internet.telenor.se instead. Also worth noting is
 that AT+CGACT=1,1 does not freeze the control connection if using
 /dev/ttyUSB0.


Regardless of the actual issue in the kernel driver, if any, NDISDUP
in the cdc-wdm device is the way to go to connect that modem.

-- 
Aleksander
https://aleksander.es
--
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] USB: qcserial: add Netgear AirCard 341U PID

[Aleksander Morgado]

On Thu, May 29, 2014 at 10:20 AM, Johan Hovold jhov...@gmail.com wrote:
 From: Aleksander Morgado aleksan...@aleksander.es

 Add Netgear AirCard 341U PID.

 Signed-off-by: Aleksander Morgado aleksan...@aleksander.es
 Link: http://marc.info/?l=linux-usbm=140130486111309w=2
 Cc: sta...@vger.kernel.org# backport in link above
 Signed-off-by: Johan Hovold jhov...@gmail.com
 ---

 Aleksander, thanks for the patch and backport! I added a minimal commit
 message, stable tag and reference to your backport.


No problem :) but I think Greg already picked the original one I wrote
in his usb-next branch...

I have more patches to come, so I'll use your approach when sending them.

 Greg, this one is for usb-next with a stable backport provided in the
 link. I think this is the easiest way to handle this. What do you say?

 Thanks,
 Johan


  drivers/usb/serial/qcserial.c | 1 +
  1 file changed, 1 insertion(+)

 diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
 index ca7b43092439..9c8b6ee1d21d 100644
 --- a/drivers/usb/serial/qcserial.c
 +++ b/drivers/usb/serial/qcserial.c
 @@ -144,6 +144,7 @@ static const struct usb_device_id id_table[] = {
 {DEVICE_SWI(0x1199, 0x901f)},   /* Sierra Wireless EM7355 */
 {DEVICE_SWI(0x1199, 0x9041)},   /* Sierra Wireless MC7305/MC7355 */
 {DEVICE_SWI(0x1199, 0x9051)},   /* Netgear AirCard 340U */
 +   {DEVICE_SWI(0x1199, 0x9055)},   /* Netgear AirCard 341U */
 {DEVICE_SWI(0x413c, 0x81a2)},   /* Dell Wireless 5806 Gobi(TM) 4G LTE 
 Mobile Broadband Card */
 {DEVICE_SWI(0x413c, 0x81a3)},   /* Dell Wireless 5570 HSPA+ (42Mbps) 
 Mobile Broadband Card */
 {DEVICE_SWI(0x413c, 0x81a4)},   /* Dell Wireless 5570e HSPA+ (42Mbps) 
 Mobile Broadband Card */
 --
 1.8.5.5




-- 
Aleksander
https://aleksander.es
--
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 usb,stable] usb: qcserial: add additional Sierra Wireless QMI devices

[Aleksander Morgado]

A set of new VID/PIDs retrieved from the out-of-tree GobiNet/GobiSerial
Sierra Wireless drivers.

Signed-off-by: Aleksander Morgado aleksan...@aleksander.es
---

Hey,

This patch is for stable branches only, and should be applied after the
following one:
  [PATCH usb,stable] usb: qcserial: add Netgear AirCard 341U
  http://marc.info/?l=linux-usbm=140130486111309w=2

Cheers!

 drivers/usb/serial/qcserial.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
index 781e4db..43d93db 100644
--- a/drivers/usb/serial/qcserial.c
+++ b/drivers/usb/serial/qcserial.c
@@ -145,15 +145,33 @@ static const struct usb_device_id id_table[] = {
{USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x901f, 0)},   /* Sierra 
Wireless EM7355 Device Management */
{USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x901f, 2)},   /* Sierra 
Wireless EM7355 NMEA */
{USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x901f, 3)},   /* Sierra 
Wireless EM7355 Modem */
+   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9040, 0)},   /* Sierra 
Wireless Modem Device Management */
+   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9040, 2)},   /* Sierra 
Wireless Modem NMEA */
+   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9040, 3)},   /* Sierra 
Wireless Modem Modem */
{USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9041, 0)},   /* Sierra 
Wireless MC7305/MC7355 Device Management */
{USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9041, 2)},   /* Sierra 
Wireless MC7305/MC7355 NMEA */
{USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9041, 3)},   /* Sierra 
Wireless MC7305/MC7355 Modem */
{USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9051, 0)},   /* Netgear 
AirCard 340U Device Management */
{USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9051, 2)},   /* Netgear 
AirCard 340U NMEA */
{USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9051, 3)},   /* Netgear 
AirCard 340U Modem */
+   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9053, 0)},   /* Sierra 
Wireless Modem Device Management */
+   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9053, 2)},   /* Sierra 
Wireless Modem NMEA */
+   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9053, 3)},   /* Sierra 
Wireless Modem Modem */
+   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9054, 0)},   /* Sierra 
Wireless Modem Device Management */
+   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9054, 2)},   /* Sierra 
Wireless Modem NMEA */
+   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9054, 3)},   /* Sierra 
Wireless Modem Modem */
{USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9055, 0)},   /* Netgear 
AirCard 341U Device Management */
{USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9055, 2)},   /* Netgear 
AirCard 341U NMEA */
{USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9055, 3)},   /* Netgear 
AirCard 341U Modem */
+   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9056, 0)},   /* Sierra 
Wireless Modem Device Management */
+   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9056, 2)},   /* Sierra 
Wireless Modem NMEA */
+   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9056, 3)},   /* Sierra 
Wireless Modem Modem */
+   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9060, 0)},   /* Sierra 
Wireless Modem Device Management */
+   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9060, 2)},   /* Sierra 
Wireless Modem NMEA */
+   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9060, 3)},   /* Sierra 
Wireless Modem Modem */
+   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9061, 0)},   /* Sierra 
Wireless Modem Device Management */
+   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9061, 2)},   /* Sierra 
Wireless Modem NMEA */
+   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9061, 3)},   /* Sierra 
Wireless Modem Modem */
{USB_DEVICE_INTERFACE_NUMBER(0x413c, 0x81a2, 0)},   /* Dell 
Wireless 5806 Gobi(TM) 4G LTE Mobile Broadband Card Device Management */
{USB_DEVICE_INTERFACE_NUMBER(0x413c, 0x81a2, 2)},   /* Dell 
Wireless 5806 Gobi(TM) 4G LTE Mobile Broadband Card NMEA */
{USB_DEVICE_INTERFACE_NUMBER(0x413c, 0x81a2, 3)},   /* Dell 
Wireless 5806 Gobi(TM) 4G LTE Mobile Broadband Card Modem */
--
1.9.3
--
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 usb-next] usb: qcserial: add additional Sierra Wireless QMI devices

[Aleksander Morgado]

A set of new VID/PIDs retrieved from the out-of-tree GobiNet/GobiSerial
Sierra Wireless drivers.

Signed-off-by: Aleksander Morgado aleksan...@aleksander.es
Link: http://marc.info/?l=linux-usbm=140136310027293w=2
Cc: sta...@vger.kernel.org# backport in link above
---
 drivers/usb/serial/qcserial.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
index 9c8b6ee..b2aa003 100644
--- a/drivers/usb/serial/qcserial.c
+++ b/drivers/usb/serial/qcserial.c
@@ -142,9 +142,15 @@ static const struct usb_device_id id_table[] = {
{DEVICE_SWI(0x1199, 0x68c0)},   /* Sierra Wireless MC73xx */
{DEVICE_SWI(0x1199, 0x901c)},   /* Sierra Wireless EM7700 */
{DEVICE_SWI(0x1199, 0x901f)},   /* Sierra Wireless EM7355 */
+   {DEVICE_SWI(0x1199, 0x9040)},   /* Sierra Wireless Modem */
{DEVICE_SWI(0x1199, 0x9041)},   /* Sierra Wireless MC7305/MC7355 */
{DEVICE_SWI(0x1199, 0x9051)},   /* Netgear AirCard 340U */
+   {DEVICE_SWI(0x1199, 0x9053)},   /* Sierra Wireless Modem */
+   {DEVICE_SWI(0x1199, 0x9054)},   /* Sierra Wireless Modem */
{DEVICE_SWI(0x1199, 0x9055)},   /* Netgear AirCard 341U */
+   {DEVICE_SWI(0x1199, 0x9056)},   /* Sierra Wireless Modem */
+   {DEVICE_SWI(0x1199, 0x9060)},   /* Sierra Wireless Modem */
+   {DEVICE_SWI(0x1199, 0x9061)},   /* Sierra Wireless Modem */
{DEVICE_SWI(0x413c, 0x81a2)},   /* Dell Wireless 5806 Gobi(TM) 4G LTE 
Mobile Broadband Card */
{DEVICE_SWI(0x413c, 0x81a3)},   /* Dell Wireless 5570 HSPA+ (42Mbps) 
Mobile Broadband Card */
{DEVICE_SWI(0x413c, 0x81a4)},   /* Dell Wireless 5570e HSPA+ (42Mbps) 
Mobile Broadband Card */
--
1.9.3
--
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] net: qmi_wwan: add additional Sierra Wireless QMI devices

[Aleksander Morgado]

A set of new VID/PIDs retrieved from the out-of-tree GobiNet/GobiSerial
Sierra Wireless drivers.

Signed-off-by: Aleksander Morgado aleksan...@aleksander.es
---

Hey,

The patch should be applied after the following one:
  [PATCH] net: qmi_wwan: add Netgear AirCard 341U
  http://marc.info/?l=linux-netdevm=140130407711048w=2

Cheers!

 drivers/net/usb/qmi_wwan.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index c0b611f..faa1277 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -753,7 +753,11 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x1199, 0x901f, 8)},/* Sierra Wireless EM7355 */
{QMI_FIXED_INTF(0x1199, 0x9041, 8)},/* Sierra Wireless 
MC7305/MC7355 */
{QMI_FIXED_INTF(0x1199, 0x9051, 8)},/* Netgear AirCard 340U */
+   {QMI_FIXED_INTF(0x1199, 0x9053, 8)},/* Sierra Wireless Modem */
+   {QMI_FIXED_INTF(0x1199, 0x9054, 8)},/* Sierra Wireless Modem */
{QMI_FIXED_INTF(0x1199, 0x9055, 8)},/* Netgear AirCard 341U */
+   {QMI_FIXED_INTF(0x1199, 0x9056, 8)},/* Sierra Wireless Modem */
+   {QMI_FIXED_INTF(0x1199, 0x9061, 8)},/* Sierra Wireless Modem */
{QMI_FIXED_INTF(0x1bbb, 0x011e, 4)},/* Telekom Speedstick LTE II 
(Alcatel One Touch L100V LTE) */
{QMI_FIXED_INTF(0x1bbb, 0x0203, 2)},/* Alcatel L800MA */
{QMI_FIXED_INTF(0x2357, 0x0201, 4)},/* TP-LINK HSUPA Modem MA180 */
--
1.9.3
--
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] net: qmi_wwan: interface #11 in Sierra Wireless MC73xx is not QMI

[Aleksander Morgado]

This interface is unusable, as the cdc-wdm character device doesn't reply to
any QMI command. Also, the out-of-tree Sierra Wireless GobiNet driver fully
skips it.

Signed-off-by: Aleksander Morgado aleksan...@aleksander.es
---
 drivers/net/usb/qmi_wwan.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index faa1277..dc4bf06 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -748,7 +748,6 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x1199, 0x68a2, 19)},   /* Sierra Wireless MC7710 in 
QMI mode */
{QMI_FIXED_INTF(0x1199, 0x68c0, 8)},/* Sierra Wireless MC73xx */
{QMI_FIXED_INTF(0x1199, 0x68c0, 10)},   /* Sierra Wireless MC73xx */
-   {QMI_FIXED_INTF(0x1199, 0x68c0, 11)},   /* Sierra Wireless MC73xx */
{QMI_FIXED_INTF(0x1199, 0x901c, 8)},/* Sierra Wireless EM7700 */
{QMI_FIXED_INTF(0x1199, 0x901f, 8)},/* Sierra Wireless EM7355 */
{QMI_FIXED_INTF(0x1199, 0x9041, 8)},/* Sierra Wireless 
MC7305/MC7355 */
-- 
1.9.3

--
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 v3 4/5] usb: qcserial: define and use Sierra Wireless layout

[Aleksander Morgado]

On Sun, Apr 27, 2014 at 4:47 PM, Bjørn Mork bm...@telenor.net wrote:
 From: Bjørn Mork bj...@mork.no

 All the non Gobi Qualcomm based devices handled by this
 driver share a common standard Sierra Wireless specific
 layout. Adding code specifically for this layout allow
 us to reduce the number of match entries per device from
 three to one.

 This change will result in a penalty wrt stable backports,
 but simplifies new Sierra device addtitions in the long
 term.

 Signed-off-by: Bjørn Mork bj...@mork.no
 ---

Is this patch applied somewhere? I have some new VID/PID to add, so
should I base my patch on top of this one?


  drivers/usb/serial/qcserial.c | 98 
 +++
  1 file changed, 53 insertions(+), 45 deletions(-)

 diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
 index 217e29ccde52..91e7bb515398 100644
 --- a/drivers/usb/serial/qcserial.c
 +++ b/drivers/usb/serial/qcserial.c
 @@ -26,10 +26,13 @@
  enum qcserial_layouts {
 QCSERIAL_G2K = 0,   /* Gobi 2000 */
 QCSERIAL_G1K = 1,   /* Gobi 1000 */
 +   QCSERIAL_SWI = 2,   /* Sierra Wireless */
  };

  #define DEVICE_G1K(v, p) \
 USB_DEVICE(v, p), .driver_info = QCSERIAL_G1K
 +#define DEVICE_SWI(v, p) \
 +   USB_DEVICE(v, p), .driver_info = QCSERIAL_SWI

  static const struct usb_device_id id_table[] = {
 /* Gobi 1000 devices */
 @@ -132,46 +135,20 @@ static const struct usb_device_id id_table[] = {
 {USB_DEVICE(0x12D1, 0x14F1)},   /* Sony Gobi 3000 Composite */
 {USB_DEVICE(0x0AF0, 0x8120)},   /* Option GTM681W */

 -   /* non Gobi Qualcomm serial devices */
 -   {USB_DEVICE_INTERFACE_NUMBER(0x0f3d, 0x68a2, 0)},   /* Sierra 
 Wireless MC7700 Device Management */
 -   {USB_DEVICE_INTERFACE_NUMBER(0x0f3d, 0x68a2, 2)},   /* Sierra 
 Wireless MC7700 NMEA */
 -   {USB_DEVICE_INTERFACE_NUMBER(0x0f3d, 0x68a2, 3)},   /* Sierra 
 Wireless MC7700 Modem */
 -   {USB_DEVICE_INTERFACE_NUMBER(0x114f, 0x68a2, 0)},   /* Sierra 
 Wireless MC7750 Device Management */
 -   {USB_DEVICE_INTERFACE_NUMBER(0x114f, 0x68a2, 2)},   /* Sierra 
 Wireless MC7750 NMEA */
 -   {USB_DEVICE_INTERFACE_NUMBER(0x114f, 0x68a2, 3)},   /* Sierra 
 Wireless MC7750 Modem */
 -   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x68a2, 0)},   /* Sierra 
 Wireless MC7710 Device Management */
 -   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x68a2, 2)},   /* Sierra 
 Wireless MC7710 NMEA */
 -   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x68a2, 3)},   /* Sierra 
 Wireless MC7710 Modem */
 -   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x68c0, 0)},   /* Sierra 
 Wireless MC73xx Device Management */
 -   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x68c0, 2)},   /* Sierra 
 Wireless MC73xx NMEA */
 -   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x68c0, 3)},   /* Sierra 
 Wireless MC73xx Modem */
 -   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x901c, 0)},   /* Sierra 
 Wireless EM7700 Device Management */
 -   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x901c, 2)},   /* Sierra 
 Wireless EM7700 NMEA */
 -   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x901c, 3)},   /* Sierra 
 Wireless EM7700 Modem */
 -   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x901f, 0)},   /* Sierra 
 Wireless EM7355 Device Management */
 -   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x901f, 2)},   /* Sierra 
 Wireless EM7355 NMEA */
 -   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x901f, 3)},   /* Sierra 
 Wireless EM7355 Modem */
 -   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9041, 0)},   /* Sierra 
 Wireless MC7305/MC7355 Device Management */
 -   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9041, 2)},   /* Sierra 
 Wireless MC7305/MC7355 NMEA */
 -   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9041, 3)},   /* Sierra 
 Wireless MC7305/MC7355 Modem */
 -   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9051, 0)},   /* Netgear 
 AirCard 340U Device Management */
 -   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9051, 2)},   /* Netgear 
 AirCard 340U NMEA */
 -   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9051, 3)},   /* Netgear 
 AirCard 340U Modem */
 -   {USB_DEVICE_INTERFACE_NUMBER(0x413c, 0x81a2, 0)},   /* Dell 
 Wireless 5806 Gobi(TM) 4G LTE Mobile Broadband Card Device Management */
 -   {USB_DEVICE_INTERFACE_NUMBER(0x413c, 0x81a2, 2)},   /* Dell 
 Wireless 5806 Gobi(TM) 4G LTE Mobile Broadband Card NMEA */
 -   {USB_DEVICE_INTERFACE_NUMBER(0x413c, 0x81a2, 3)},   /* Dell 
 Wireless 5806 Gobi(TM) 4G LTE Mobile Broadband Card Modem */
 -   {USB_DEVICE_INTERFACE_NUMBER(0x413c, 0x81a3, 0)},   /* Dell 
 Wireless 5570 HSPA+ (42Mbps) Mobile Broadband Card Device Management */
 -   {USB_DEVICE_INTERFACE_NUMBER(0x413c, 0x81a3, 2)},   /* Dell 
 Wireless 5570 HSPA+ (42Mbps) Mobile Broadband Card NMEA */
 -   {USB_DEVICE_INTERFACE_NUMBER(0x413c, 0x81a3, 3)},   /* Dell 
 

Re: [PATCH v3 4/5] usb: qcserial: define and use Sierra Wireless layout

[Aleksander Morgado]

On Wed, May 28, 2014 at 2:54 PM, Bjørn Mork bj...@mork.no wrote:
 Aleksander Morgado aleksan...@aleksander.es writes:
 On Sun, Apr 27, 2014 at 4:47 PM, Bjørn Mork bm...@telenor.net wrote:
 From: Bjørn Mork bj...@mork.no

 All the non Gobi Qualcomm based devices handled by this
 driver share a common standard Sierra Wireless specific
 layout. Adding code specifically for this layout allow
 us to reduce the number of match entries per device from
 three to one.

 This change will result in a penalty wrt stable backports,
 but simplifies new Sierra device addtitions in the long
 term.

 Signed-off-by: Bjørn Mork bj...@mork.no
 ---

 Is this patch applied somewhere?

 Yes, it is now in Greg's usb-next branch.


Ah, great.

 I have some new VID/PID to add, so
 should I base my patch on top of this one?

 I guess so.  But there we have the stable backport issues coming...


I actually have the patch for stable, so I can provide both if needed.

-- 
Aleksander
https://aleksander.es
--
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] net: qmi_wwan: add Netgear AirCard 341U

[Aleksander Morgado]

Signed-off-by: Aleksander Morgado aleksan...@aleksander.es
---
 drivers/net/usb/qmi_wwan.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 83208d4..c0b611f 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -753,6 +753,7 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x1199, 0x901f, 8)},/* Sierra Wireless EM7355 */
{QMI_FIXED_INTF(0x1199, 0x9041, 8)},/* Sierra Wireless 
MC7305/MC7355 */
{QMI_FIXED_INTF(0x1199, 0x9051, 8)},/* Netgear AirCard 340U */
+   {QMI_FIXED_INTF(0x1199, 0x9055, 8)},/* Netgear AirCard 341U */
{QMI_FIXED_INTF(0x1bbb, 0x011e, 4)},/* Telekom Speedstick LTE II 
(Alcatel One Touch L100V LTE) */
{QMI_FIXED_INTF(0x1bbb, 0x0203, 2)},/* Alcatel L800MA */
{QMI_FIXED_INTF(0x2357, 0x0201, 4)},/* TP-LINK HSUPA Modem MA180 */
-- 
1.9.3

--
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 usb-next] usb: qcserial: add Netgear AirCard 341U

[Aleksander Morgado]

Signed-off-by: Aleksander Morgado aleksan...@aleksander.es
---
 drivers/usb/serial/qcserial.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
index ca7b430..9c8b6ee 100644
--- a/drivers/usb/serial/qcserial.c
+++ b/drivers/usb/serial/qcserial.c
@@ -144,6 +144,7 @@ static const struct usb_device_id id_table[] = {
{DEVICE_SWI(0x1199, 0x901f)},   /* Sierra Wireless EM7355 */
{DEVICE_SWI(0x1199, 0x9041)},   /* Sierra Wireless MC7305/MC7355 */
{DEVICE_SWI(0x1199, 0x9051)},   /* Netgear AirCard 340U */
+   {DEVICE_SWI(0x1199, 0x9055)},   /* Netgear AirCard 341U */
{DEVICE_SWI(0x413c, 0x81a2)},   /* Dell Wireless 5806 Gobi(TM) 4G LTE 
Mobile Broadband Card */
{DEVICE_SWI(0x413c, 0x81a3)},   /* Dell Wireless 5570 HSPA+ (42Mbps) 
Mobile Broadband Card */
{DEVICE_SWI(0x413c, 0x81a4)},   /* Dell Wireless 5570e HSPA+ (42Mbps) 
Mobile Broadband Card */
--
1.9.3
--
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 usb,stable] usb: qcserial: add Netgear AirCard 341U

[Aleksander Morgado]

Signed-off-by: Aleksander Morgado aleksan...@aleksander.es
---
 drivers/usb/serial/qcserial.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
index 6c0a542..781e4db 100644
--- a/drivers/usb/serial/qcserial.c
+++ b/drivers/usb/serial/qcserial.c
@@ -151,6 +151,9 @@ static const struct usb_device_id id_table[] = {
{USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9051, 0)},   /* Netgear 
AirCard 340U Device Management */
{USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9051, 2)},   /* Netgear 
AirCard 340U NMEA */
{USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9051, 3)},   /* Netgear 
AirCard 340U Modem */
+   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9055, 0)},   /* Netgear 
AirCard 341U Device Management */
+   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9055, 2)},   /* Netgear 
AirCard 341U NMEA */
+   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9055, 3)},   /* Netgear 
AirCard 341U Modem */
{USB_DEVICE_INTERFACE_NUMBER(0x413c, 0x81a2, 0)},   /* Dell 
Wireless 5806 Gobi(TM) 4G LTE Mobile Broadband Card Device Management */
{USB_DEVICE_INTERFACE_NUMBER(0x413c, 0x81a2, 2)},   /* Dell 
Wireless 5806 Gobi(TM) 4G LTE Mobile Broadband Card NMEA */
{USB_DEVICE_INTERFACE_NUMBER(0x413c, 0x81a2, 3)},   /* Dell 
Wireless 5806 Gobi(TM) 4G LTE Mobile Broadband Card Modem */
--
1.9.3
--
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] net: qmi_wwan: add support for Cinterion PXS8 and PHS8

[Aleksander Morgado]

When the PXS8 and PHS8 devices show up with PID 0x0053 they will expose both a
QMI port and a WWAN interface.

CC: Hans-Christoph Schemmel hans-christoph.schem...@gemalto.com
CC: Christian Schmiedl christian.schmi...@gemalto.com
CC: Nicolaus Colberg nicolaus.colb...@gemalto.com
CC: David McCullough david.mccullo...@accelecon.com
Signed-off-by: Aleksander Morgado aleksan...@aleksander.es
---
 drivers/net/usb/qmi_wwan.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index ff5c871..1eddd43 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -732,6 +732,7 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x1bc7, 0x1201, 2)},/* Telit LE920 */
{QMI_FIXED_INTF(0x0b3c, 0xc005, 6)},/* Olivetti Olicard 200 */
{QMI_FIXED_INTF(0x1e2d, 0x0060, 4)},/* Cinterion PLxx */
+   {QMI_FIXED_INTF(0x1e2d, 0x0053, 4)},/* Cinterion PHxx,PXxx */
 
/* 4. Gobi 1000 devices */
{QMI_GOBI1K_DEVICE(0x05c6, 0x9212)},/* Acer Gobi Modem Device */
-- 
1.8.5.3

--
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] USB: serial: option: blacklist interface 4 for Cinterion PHS8 and PXS8

[Aleksander Morgado]

This interface is to be handled by the qmi_wwan driver.

CC: Hans-Christoph Schemmel hans-christoph.schem...@gemalto.com
CC: Christian Schmiedl christian.schmi...@gemalto.com
CC: Nicolaus Colberg nicolaus.colb...@gemalto.com
CC: David McCullough david.mccullo...@accelecon.com
Signed-off-by: Aleksander Morgado aleksan...@aleksander.es
---
 drivers/usb/serial/option.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 5c86f57..604948b 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -1525,7 +1525,8 @@ static const struct usb_device_id option_ids[] = {
/* Cinterion */
{ USB_DEVICE(CINTERION_VENDOR_ID, CINTERION_PRODUCT_EU3_E) },
{ USB_DEVICE(CINTERION_VENDOR_ID, CINTERION_PRODUCT_EU3_P) },
-   { USB_DEVICE(CINTERION_VENDOR_ID, CINTERION_PRODUCT_PH8) },
+   { USB_DEVICE(CINTERION_VENDOR_ID, CINTERION_PRODUCT_PH8),
+   .driver_info = (kernel_ulong_t)net_intf4_blacklist },
{ USB_DEVICE(CINTERION_VENDOR_ID, CINTERION_PRODUCT_AHXX) },
{ USB_DEVICE(CINTERION_VENDOR_ID, CINTERION_PRODUCT_PLXX),
.driver_info = (kernel_ulong_t)net_intf4_blacklist },
-- 
1.8.5.3

--
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] net: qmi_wwan: fix Cinterion PLXX product ID

[Aleksander Morgado]

Cinterion PLXX LTE devices have a 0x0060 product ID, not 0x12d1.

The blacklisting in the serial/option driver does actually use the correct PID,
as per commit 8ff10bdb14a52e3f25d4ce09e0582a8684c1a6db ('USB: Blacklisted
Cinterion's PLxx WWAN Interface').

CC: Hans-Christoph Schemmel hans-christoph.schem...@gemalto.com
CC: Christian Schmiedl christian.schmi...@gemalto.com
CC: Nicolaus Colberg nicolaus.colb...@gemalto.com
Signed-off-by: Aleksander Morgado aleksan...@lanedo.com
---
 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 6312332..3d6aaf7 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -714,7 +714,7 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x2357, 0x0201, 4)},/* TP-LINK HSUPA Modem MA180 */
{QMI_FIXED_INTF(0x2357, 0x9000, 4)},/* TP-LINK MA260 */
{QMI_FIXED_INTF(0x1bc7, 0x1200, 5)},/* Telit LE920 */
-   {QMI_FIXED_INTF(0x1e2d, 0x12d1, 4)},/* Cinterion PLxx */
+   {QMI_FIXED_INTF(0x1e2d, 0x0060, 4)},/* Cinterion PLxx */
 
/* 4. Gobi 1000 devices */
{QMI_GOBI1K_DEVICE(0x05c6, 0x9212)},/* Acer Gobi Modem Device */
-- 
1.8.3.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] cdc-acm: implement TIOCSSERIAL to avoid blocking close(2)

[Aleksander Morgado]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/11/12 19:47, Dan Williams wrote:
 Some devices (ex Nokia C7) simply don't respond at all when data is
 sent to some of their USB interfaces.  The data gets stuck in the
 TTYs queue and sits there until close(2), which them blocks because
 closing_wait defaults to 30 seconds (even though the fd is
 O_NONBLOCK).  This is rarely desired.  Implement the standard
 mechanism to adjust closing_wait and let applications handle it how
 they want to.
 
 See also 02303f73373aa1da19dbec510ec5a4e2576f9610 for usb_wwan.c.
 
 Signed-off-by: Dan Williams d...@redhat.com Cc:
 sta...@vger.kernel.org

Works pretty well for me.

Tested-by: Aleksander Morgado aleksan...@gnu.org


 --- drivers/usb/class/cdc-acm.c | 38
 ++ 1 file changed, 38
 insertions(+)
 
 diff --git a/drivers/usb/class/cdc-acm.c
 b/drivers/usb/class/cdc-acm.c index 6e49ec6..8d809a8 100644 ---
 a/drivers/usb/class/cdc-acm.c +++ b/drivers/usb/class/cdc-acm.c @@
 -787,6 +787,10 @@ static int get_serial_info(struct acm *acm,
 struct serial_struct __user *info) tmp.flags = ASYNC_LOW_LATENCY; 
 tmp.xmit_fifo_size = acm-writesize; tmp.baud_base =
 le32_to_cpu(acm-line.dwDTERate); +   tmp.close_delay =
 acm-port.close_delay / 10; + tmp.closing_wait =
 acm-port.closing_wait == ASYNC_CLOSING_WAIT_NONE ? +
 ASYNC_CLOSING_WAIT_NONE : +   acm-port.closing_wait 
 / 10;
 
 if (copy_to_user(info, tmp, sizeof(tmp))) return -EFAULT; @@
 -794,6 +798,37 @@ static int get_serial_info(struct acm *acm,
 struct serial_struct __user *info) return 0; }
 
 +static int set_serial_info(struct acm *acm, +
 struct
 serial_struct __user *newinfo) +{ +   struct serial_struct
 new_serial; + unsigned int closing_wait, close_delay; +   int retval
 = 0; + +  if (copy_from_user(new_serial, newinfo,
 sizeof(new_serial))) +return -EFAULT; + + close_delay =
 new_serial.close_delay * 10; +closing_wait =
 new_serial.closing_wait == ASYNC_CLOSING_WAIT_NONE ? +
 ASYNC_CLOSING_WAIT_NONE : new_serial.closing_wait * 10; + +
 mutex_lock(acm-port.mutex); + + if (!capable(CAP_SYS_ADMIN)) { +
 if ((close_delay != acm-port.close_delay) || +   
 (closing_wait
 != acm-port.closing_wait)) + retval = -EPERM; +  
 else +  retval
 = -EOPNOTSUPP; +  } else { +  acm-port.close_delay  = 
 close_delay; 
 + acm-port.closing_wait = closing_wait; +} + +
 mutex_unlock(acm-port.mutex); + return retval; +} + static int
 acm_tty_ioctl(struct tty_struct *tty, unsigned int cmd, unsigned
 long arg) { @@ -804,6 +839,9 @@ static int acm_tty_ioctl(struct
 tty_struct *tty, case TIOCGSERIAL: /* gets serial port data */ rv =
 get_serial_info(acm, (struct serial_struct __user *) arg); break; +
 case TIOCSSERIAL: +   rv = set_serial_info(acm, (struct
 serial_struct __user *) arg); +   break; }
 
 return rv;
 


- -- 
Aleksander
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlCb/0kACgkQgxIgkKLogl7Z7wCdHR3ydnlfHjK5gtMNjjUMfBu9
KCkAoIfo+ZekWkZmW6MDj1KNJTcFUn95
=nxmZ
-END PGP SIGNATURE-
--
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] net: qmi_wwan: new device: Foxconn/Novatel E396

[Aleksander Morgado]

Foxconn-branded Novatel E396, Gobi3k modem.

Cc: Dan Williams d...@redhat.com
Cc: Bjørn Mork bj...@mork.no
Cc: Ben Chan benc...@google.com
Signed-off-by: Aleksander Morgado aleksan...@lanedo.com
---
 drivers/net/usb/qmi_wwan.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 328397c..189e52d 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -441,6 +441,7 @@ static const struct usb_device_id products[] = {
{QMI_GOBI_DEVICE(0x1199, 0x9015)},  /* Sierra Wireless Gobi 3000 
Modem device */
{QMI_GOBI_DEVICE(0x1199, 0x9019)},  /* Sierra Wireless Gobi 3000 
Modem device */
{QMI_GOBI_DEVICE(0x1199, 0x901b)},  /* Sierra Wireless MC7770 */
+   {QMI_GOBI_DEVICE(0x1410, 0xa021)},  /* Foxconn Gobi 3000 Modem 
device (Novatel E396) */
 
{ } /* END */
 };
-- 
1.7.11.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