Re: [PATCHv2] USB: serial: option: blacklist intf1 for Huawei E173s-6

2013-11-11 Thread Gustavo Zacarias 
On 11/08/2013 04:44 AM, Bjørn Mork wrote:

 I believe it's nice to document the layout of complex composite devices
 if known, but if not then I don't see any need to delay a patch like
 this.

From looking at the .inf files from the windows drivers i can't get much
info other than:

%QcomDevice00% = QportInstall00, USB\VID_12d1PID_1C0B
(which is the PID before usb_modeswitch/modem mode kicks in).

If there's another to lookup way feel free to prod me :)
Regards.
--
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: [PATCHv2] USB: serial: option: blacklist intf1 for Huawei E173s-6

2013-11-11 Thread Gustavo Zacarias 
On 11/09/2013 10:47 AM, Johan Hovold wrote:
 Ok. Thanks.
 
 Gustavo, could you fix up the commit message (the subject line) and
 resend so we can apply this?

Sure, but it was already handled by {
USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0xff, 0xff) }
which caused issues without the blacklist (card reader for intf1 maybe?).
I'll ammend the define to focus on the E173s-6 (and probably not other
E173s-*) because according to usb_modeswitch data the E173S's can end up
in PIDs 1c05, 1c07, 1c08 and 1c10 which likely means there are other
variants out there.
Regards.

--
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

[PATCHv3] USB: serial: option: add support for Huawei E173s-6

2013-11-11 Thread Gustavo Zacarias 
Interface 1 on this device isn't for option to bind to otherwise an oops
on usb_wwan with log flooding will happen when accessing the port:

tty_release: ttyUSB1: read/write wait queue active!

It doesn't seem to respond to QMI if it's added to qmi_wwan so don't add
it there - it's likely used by the card reader.

Signed-off-by: Gustavo Zacarias gust...@zacarias.com.ar
---
 drivers/usb/serial/option.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index acaee06..04f65a0 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -81,6 +81,7 @@ static void option_instat_callback(struct urb *urb);
 
 #define HUAWEI_VENDOR_ID   0x12D1
 #define HUAWEI_PRODUCT_E1730x140C
+#define HUAWEI_PRODUCT_E173S6  0x1C07
 #define HUAWEI_PRODUCT_E1750   0x1406
 #define HUAWEI_PRODUCT_K4505   0x1464
 #define HUAWEI_PRODUCT_K3765   0x1465
@@ -572,6 +573,8 @@ static const struct usb_device_id option_ids[] = {
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0x1c23, 
USB_CLASS_COMM, 0x02, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E173, 
0xff, 0xff, 0xff),
.driver_info = (kernel_ulong_t) net_intf1_blacklist },
+   { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 
HUAWEI_PRODUCT_E173S6, 0xff, 0xff, 0xff),
+   .driver_info = (kernel_ulong_t) net_intf1_blacklist },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E1750, 
0xff, 0xff, 0xff),
.driver_info = (kernel_ulong_t) net_intf2_blacklist },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0x1441, 
USB_CLASS_COMM, 0x02, 0xff) },
-- 
1.8.3.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

[PATCHv4] USB: serial: option: add support for Huawei E173s-6

2013-11-11 Thread Gustavo Zacarias 
Interface 1 on this device isn't for option to bind to otherwise an oops
on usb_wwan with log flooding will happen when accessing the port:

tty_release: ttyUSB1: read/write wait queue active!

It doesn't seem to respond to QMI if it's added to qmi_wwan so don't add
it there - it's likely used by the card reader.

Signed-off-by: Gustavo Zacarias gust...@zacarias.com.ar
---

v4:
- Unbreak v2 ID sort broken in v3

v3:
- Focus define name on E173s -6 variant, there are others
- Change msg to E173-s6 add suggested by Johan Hovold

v2:
- Sort define by id as pointed by Sergei Shtylyov

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

diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index acaee06..98a4a1c 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -85,6 +85,7 @@ static void option_instat_callback(struct urb *urb);
 #define HUAWEI_PRODUCT_K4505   0x1464
 #define HUAWEI_PRODUCT_K3765   0x1465
 #define HUAWEI_PRODUCT_K4605   0x14C6
+#define HUAWEI_PRODUCT_E173S6  0x1C07
 
 #define QUANTA_VENDOR_ID   0x0408
 #define QUANTA_PRODUCT_Q1010xEA02
@@ -572,6 +573,8 @@ static const struct usb_device_id option_ids[] = {
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0x1c23, 
USB_CLASS_COMM, 0x02, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E173, 
0xff, 0xff, 0xff),
.driver_info = (kernel_ulong_t) net_intf1_blacklist },
+   { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 
HUAWEI_PRODUCT_E173S6, 0xff, 0xff, 0xff),
+   .driver_info = (kernel_ulong_t) net_intf1_blacklist },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E1750, 
0xff, 0xff, 0xff),
.driver_info = (kernel_ulong_t) net_intf2_blacklist },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0x1441, 
USB_CLASS_COMM, 0x02, 0xff) },
-- 
1.8.3.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: [PATCHv2] USB: serial: option: blacklist intf1 for Huawei E173s-6

2013-11-11 Thread Gustavo Zacarias 
On 11/11/2013 10:41 AM, Bjørn Mork wrote:

 One way, if you have access to a Windows system, is observing what
 happens there.  You can look up vid/pid/intfnumber in the Windows device
 manager.

From windows i've got:

3G Modem - usbcdcacm\VID_12D1PID_1C07MI_00
HUAWEI Mobile Connect Network Interface -
usbcdcecm\VID_12D1PID_1C07MI_01wwan
3G Application - usbcdcacm\VID_12D1PID_1C07MI_02
3G PC UI - usbcdcacm\VID_12D1PID_1C07MI_03

So it seems to be ECM.

 So according to thos, interface #1 on 12d1:1c07 should be either an ECM
 or(?) NCM function, so blacklisting it in option is definitely correct
 if the generic Huawei vendor rule picks it up.
 
 Now I do not understand how the same function can be both ECM and NCM,
 but we should try to find out which one it is...  The Huawei Windows
 driver use a single flag to select one of these, which may explain how
 they can mix configs like this.  It just seems completely pointless.
 
 You have already tried qmi_wwan, right?  But only with libqmi?  This is
 most likely not a QMI device in any case.  There is a fair chance that
 it supports Huawei's AT^NDISDUP and related vendor specific AT
 commands though.  You should try that, using either qmi_wwan (if ECM) or
 the new huawei_cdc_ncm driver (if NCM) for the network function.

Yes, tried with libqmi, queries get stuck/timeout with qmicli but
nothing nasty.
With minicom on /dev/cdc-wdm0 after patching qmi_wwan it seems to be
responsive to AT commands so yes it seems we are dealing with ECM here.
I'll send a followup patch to include qmi_wwan.

 This device use ff/ff/ff for class/subclass/protocol on all interfaces,
 is that right?

Yes, for bInterfaceNumber 0..3 i've got Class/SubClass/Protocol 255.
4 and 5 are mass storage which surely correspond with the MicroSD slot
and internal flash cdrom emulation/image.
Interface 1 has an alternate setting with one endpoint (#0) or 3
endpoints (#1) if that's of any use.
You can take a peek at lsusb -vv output @
https://www.zacarias.com.ar/e173s.txt
Regards.

--
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: [PATCHv2] USB: serial: option: blacklist intf1 for Huawei E173s-6

2013-11-11 Thread Gustavo Zacarias 
On 11/11/2013 01:10 PM, Dan Williams wrote:

 This is a bit confusing...  so you added the device to qmi_wwan, and now
 one of the AT ports works (cdc-wdm0) and the net port also works, as
 exposed by qmi_wwan?
 
 What's the full lsusb -v for this device after it's modeswitched?  I
 looked through all the recent mails you've sent and couldn't find one.
 Are the descriptors for standard USB specifications (ACM, WDM, ECM, NCM,
 etc), or are they vendor-specific 0xFF-type ones but implement the
 standard protocols?

I'm not 100% sure how to test the wwan0 interface: init modem,
AT^NDISUP... to leave it ready and then run a dhcp client on wwan0?
If that's it then no, wwan0 doesn't work, just cdc-wdm0 is providing
something useful.
I've uploaded the lsusb dump to https://www.zacarias.com.ar/e173s.txt to
avoid too much noise (mentioned in my last mail to Bjørn), and yes,
they're all 0xFF except for storage.
Regards.

--
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: [PATCHv2] USB: serial: option: blacklist intf1 for Huawei E173s-6

2013-11-11 Thread Gustavo Zacarias 
On 11/11/2013 02:27 PM, Bjørn Mork wrote:

 If dhcp doesn't work after a successful AT^NDISDUP connection, then
 there is still a chance that this actuall is a NCM device.  That would
 make things easier in many ways :-)
 
 Please try the huawei_cdc_ncm driver, although I am not completely sure
 that works at all at the moment. Snooping on the device in Windows is
 another option...
 
 Or the device might just not support DHCP.  You could try the AT^DHCP?
 command after connecting, and then configure the wwan0 device manually
 using addresses from the output of that command.

Actually it wasn't connecting at all, but it was my mistake, the command
doesn't work on /dev/ttyUSB?, only on /dev/cdc-acm0, greeted by the
always-on led and a happy ^NDISSTAT:1 result.
It doesn't help that Huawei OKs every command even if it's ignoring it.
And no, AT^DHCP wasn't necessary, dhcp on wwan0 worked just fine.
Regards.

--
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

[PATCHv2] USB: serial: option: blacklist intf1 for Huawei E173s-6

2013-11-05 Thread Gustavo Zacarias 
Interface 1 on this device isn't for option to bind to otherwise an oops
on usb_wwan with log flooding will happen when accessing the port:

tty_release: ttyUSB1: read/write wait queue active!

It doesn't seem to respond to QMI if it's added to qmi_wwan so don't add
it there.

Signed-off-by: Gustavo Zacarias gust...@zacarias.com.ar
---

v2:
- Sort define by id as pointed by Sergei Shtylyov

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

diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index acaee06..44741b6 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -85,6 +85,7 @@ static void option_instat_callback(struct urb *urb);
 #define HUAWEI_PRODUCT_K4505   0x1464
 #define HUAWEI_PRODUCT_K3765   0x1465
 #define HUAWEI_PRODUCT_K4605   0x14C6
+#define HUAWEI_PRODUCT_E173S   0x1C07
 
 #define QUANTA_VENDOR_ID   0x0408
 #define QUANTA_PRODUCT_Q1010xEA02
@@ -572,6 +573,8 @@ static const struct usb_device_id option_ids[] = {
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0x1c23, 
USB_CLASS_COMM, 0x02, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E173, 
0xff, 0xff, 0xff),
.driver_info = (kernel_ulong_t) net_intf1_blacklist },
+   { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E173S, 
0xff, 0xff, 0xff),
+   .driver_info = (kernel_ulong_t) net_intf1_blacklist },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E1750, 
0xff, 0xff, 0xff),
.driver_info = (kernel_ulong_t) net_intf2_blacklist },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0x1441, 
USB_CLASS_COMM, 0x02, 0xff) },
-- 
1.8.1.5

--
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 intf1 for Huawei E173s-6

2013-11-04 Thread Gustavo Zacarias 
Interface 1 on this device isn't for option to bind to otherwise an oops
on usb_wwan with log flooding will happen:

tty_release: ttyUSB1: read/write wait queue active!

And it doesn't seem to respond to QMI if it's added to qmi_wwan so don't
add it there.

Signed-off-by: Gustavo Zacarias gust...@zacarias.com.ar
---
 drivers/usb/serial/option.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index acaee06..b5d3b33 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -81,6 +81,7 @@ static void option_instat_callback(struct urb *urb);
 
 #define HUAWEI_VENDOR_ID   0x12D1
 #define HUAWEI_PRODUCT_E1730x140C
+#define HUAWEI_PRODUCT_E173S   0x1C07
 #define HUAWEI_PRODUCT_E1750   0x1406
 #define HUAWEI_PRODUCT_K4505   0x1464
 #define HUAWEI_PRODUCT_K3765   0x1465
@@ -572,6 +573,8 @@ static const struct usb_device_id option_ids[] = {
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0x1c23, 
USB_CLASS_COMM, 0x02, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E173, 
0xff, 0xff, 0xff),
.driver_info = (kernel_ulong_t) net_intf1_blacklist },
+   { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E173S, 
0xff, 0xff, 0xff),
+   .driver_info = (kernel_ulong_t) net_intf1_blacklist },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E1750, 
0xff, 0xff, 0xff),
.driver_info = (kernel_ulong_t) net_intf2_blacklist },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0x1441, 
USB_CLASS_COMM, 0x02, 0xff) },
-- 
1.8.1.5

--
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