Re: [PATCHv2] USB: serial: option: blacklist intf1 for Huawei E173s-6
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
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
Re: [PATCHv2] USB: serial: option: blacklist intf1 for Huawei E173s-6
Gustavo Zacarias gust...@zacarias.com.ar writes: 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 :) 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. Looking around at various driver files I had here, I found this: bjorn@nemi:/tmp/foo/Huawei$ egrep '1C(05|07|08|10)' *.inf|sort |uniq ew_jubusenum.inf:%EnumDeviceDesc% = DevInstallNet, USB\VID_12D1PID_1C07MI_01 ew_jubusenum.inf:%EnumDeviceDesc% = DevInstall, USB\VID_12D1PID_1C05MI_00 ew_jubusenum.inf:%EnumDeviceDesc% = DevInstall, USB\VID_12D1PID_1C05MI_01 ew_jubusenum.inf:%EnumDeviceDesc% = DevInstall, USB\VID_12D1PID_1C05MI_02 ew_jubusenum.inf:%EnumDeviceDesc% = DevInstall, USB\VID_12D1PID_1C07MI_00 ew_jubusenum.inf:%EnumDeviceDesc% = DevInstall, USB\VID_12D1PID_1C07MI_02 ew_jubusenum.inf:%EnumDeviceDesc% = DevInstall, USB\VID_12D1PID_1C07MI_03 ew_jubusenum.inf:%EnumDeviceDesc% = DevInstall, USB\VID_12D1PID_1C07MI_06 ew_jubusenum.inf:%EnumDeviceDesc% = DevInstall, USB\VID_12D1PID_1C08MI_00 ew_jubusenum.inf:%EnumDeviceDesc% = DevInstall, USB\VID_12D1PID_1C08MI_01 ew_jubusenum.inf:%EnumDeviceDesc% = DevInstall, USB\VID_12D1PID_1C10MI_00 ew_jubusenum.inf:%EnumDeviceDesc% = DevInstall, USB\VID_12D1PID_1C10MI_01 ew_jubusenum.inf:%EnumDeviceDesc% = DevInstall, USB\VID_12D1PID_1C10MI_02 ew_jucdcacm.inf:%BTDeviceDesc% = DevInstall, USBCDCACM\VID_12D1PID_1C07MI_06 ew_jucdcacm.inf:%DIAGDeviceDesc% = DevInstall, USBCDCACM\VID_12D1PID_1C05MI_01 ew_jucdcacm.inf:%DIAGDeviceDesc% = DevInstall, USBCDCACM\VID_12D1PID_1C07MI_02 ew_jucdcacm.inf:%DIAGDeviceDesc% = DevInstall, USBCDCACM\VID_12D1PID_1C10MI_01 ew_jucdcacm.inf:%PCUIDeviceDesc% = DevInstall, USBCDCACM\VID_12D1PID_1C05MI_02 ew_jucdcacm.inf:%PCUIDeviceDesc% = DevInstall, USBCDCACM\VID_12D1PID_1C07MI_03 ew_jucdcacm.inf:%PCUIDeviceDesc% = DevInstall, USBCDCACM\VID_12D1PID_1C08MI_01 ew_jucdcacm.inf:%PCUIDeviceDesc% = DevInstall, USBCDCACM\VID_12D1PID_1C10MI_02 ew_jucdcecm.inf:%ECMDeviceDesc% = ew_jucdcecm.ndi, USBCDCECM\VID_12D1PID_1C07MI_01 ew_jucdcecm.inf:%NCMDeviceDesc% = ew_jucdcncm.ndi, USBCDCNCM\VID_12D1PID_1C07MI_01 ew_jucdcmdm.inf:%MDMDeviceDesc% = DevInstall, USBCDCACM\VID_12D1PID_1C05MI_00 ew_jucdcmdm.inf:%MDMDeviceDesc% = DevInstall, USBCDCACM\VID_12D1PID_1C07MI_00 ew_jucdcmdm.inf:%MDMDeviceDesc% = DevInstall, USBCDCACM\VID_12D1PID_1C08MI_00 ew_jucdcmdm.inf:%MDMDeviceDesc% = DevInstall, USBCDCACM\VID_12D1PID_1C10MI_00 ew_juextctrl.inf:%dc_ecm_dev.DevDesc% = DevInstall, USBCDCECM\VID_12D1PID_1C07MI_01ext_ctrl 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. This device use ff/ff/ff for class/subclass/protocol on all interfaces, is that right? Bjørn -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] USB: serial: option: blacklist intf1 for Huawei E173s-6
On Mon, Nov 11, 2013 at 06:47:52AM -0300, Gustavo Zacarias wrote:
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?).
Ah, my bad. Then your original commit message was perfectly adequate. :)
Johan
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] USB: serial: option: blacklist intf1 for Huawei E173s-6
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
Gustavo Zacarias gust...@zacarias.com.ar writes: 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. Maybe run a small discussion on the ModemManager list first? This would be the first non-QMI device there, and I don't think userspace is prepared for that I expected this type of device might exist, but we haven't really tried to support it before (AFAIK). Although the qmi_wwan driver doesn't care about whether the embedded control protocol is QMI or AT or something else, current userspace applications do. I am not entirely sure about how this should be handled, but it should be sorted out before we start adding non QMI devices to the driver. 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 Thanks Bjørn -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] USB: serial: option: blacklist intf1 for Huawei E173s-6
On Mon, 2013-11-11 at 15:43 +0100, Bjørn Mork wrote: Gustavo Zacarias gust...@zacarias.com.ar writes: 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 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? Maybe run a small discussion on the ModemManager list first? This would be the first non-QMI device there, and I don't think userspace is prepared for that We've got a bug open for this in ModemManager: https://bugzilla.gnome.org/show_bug.cgi?id=699741 Quite a few 2008 - 2009-era SonyEricsson phones (TM-506 and others) and many of the Ericsson MBM WWAN minicards expose a cdc-wdm AT port, so this device wouldn't be the first to expose an AT-capable cdc-wdm port. ModemManager does not currently support AT-capable cdc-wdm interfaces though, since the SE devices didn't use them for the primary/secondary AT ports. I expected this type of device might exist, but we haven't really tried to support it before (AFAIK). Although the qmi_wwan driver doesn't care about whether the embedded control protocol is QMI or AT or something else, current userspace applications do. I am not entirely sure about how this should be handled, but it should be sorted out before we start adding non QMI devices to the driver. If we start adding non-QMI devices to the driver, then we should rename it to something more generic. Or, better yet, make the driver generic, and keep qmi_wwan a sub-driver with all the current device IDs. Dan 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 Thanks Bjørn -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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
Dan Williams d...@redhat.com writes: On Mon, 2013-11-11 at 15:43 +0100, Bjørn Mork wrote: Maybe run a small discussion on the ModemManager list first? This would be the first non-QMI device there, and I don't think userspace is prepared for that We've got a bug open for this in ModemManager: https://bugzilla.gnome.org/show_bug.cgi?id=699741 Quite a few 2008 - 2009-era SonyEricsson phones (TM-506 and others) and many of the Ericsson MBM WWAN minicards expose a cdc-wdm AT port, so this device wouldn't be the first to expose an AT-capable cdc-wdm port. Yes, I am fully aware of this. But currently there is an assumed relationship between driver and cdc-wdm protocol: cdc-wdm = AT (except for the unfortunate v3.4+5 Huawei QMI case) qmi_wwan = QMI cdc_mbim = MBIM huawei_cdc_ncm = AT ModemManager does not currently support AT-capable cdc-wdm interfaces though, since the SE devices didn't use them for the primary/secondary AT ports. I expected this type of device might exist, but we haven't really tried to support it before (AFAIK). Although the qmi_wwan driver doesn't care about whether the embedded control protocol is QMI or AT or something else, current userspace applications do. I am not entirely sure about how this should be handled, but it should be sorted out before we start adding non QMI devices to the driver. If we start adding non-QMI devices to the driver, then we should rename it to something more generic. Or, better yet, make the driver generic, and keep qmi_wwan a sub-driver with all the current device IDs. This puts way too much into the driver name, IMHO. I don't think renaming the driver or creating two distinct driver names for AT or QMI devices makes much sense, given that these drivers will be identical. FWIW it's just a coincidence that the qmi_wwan driver didn't end up being named huawei_something instead. We could make the protocol (if known) an attribute of the cdc-wdm device, either in sysfs or adding another ioctl. A sysfs attribute would have been nice, but I guess the discussion around the message size attribute applies here too? But if we do that, then we do handle QMI+ECM and AT+ECM devices differently, so maybe separate drivers makes sense anyway? Hmm, as usual I don't know what I want... Bjørn -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] USB: serial: option: blacklist intf1 for Huawei E173s-6
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
Gustavo Zacarias gust...@zacarias.com.ar writes: 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. 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. Bjørn -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] USB: serial: option: blacklist intf1 for Huawei E173s-6
On Mon, 2013-11-11 at 18:03 +0100, Bjørn Mork wrote: Dan Williams d...@redhat.com writes: On Mon, 2013-11-11 at 15:43 +0100, Bjørn Mork wrote: Maybe run a small discussion on the ModemManager list first? This would be the first non-QMI device there, and I don't think userspace is prepared for that We've got a bug open for this in ModemManager: https://bugzilla.gnome.org/show_bug.cgi?id=699741 Quite a few 2008 - 2009-era SonyEricsson phones (TM-506 and others) and many of the Ericsson MBM WWAN minicards expose a cdc-wdm AT port, so this device wouldn't be the first to expose an AT-capable cdc-wdm port. Yes, I am fully aware of this. But currently there is an assumed relationship between driver and cdc-wdm protocol: cdc-wdm = AT (except for the unfortunate v3.4+5 Huawei QMI case) Assumed where? kernel or ModemManager? qmi_wwan = QMI cdc_mbim = MBIM huawei_cdc_ncm = AT ModemManager does not currently support AT-capable cdc-wdm interfaces though, since the SE devices didn't use them for the primary/secondary AT ports. I expected this type of device might exist, but we haven't really tried to support it before (AFAIK). Although the qmi_wwan driver doesn't care about whether the embedded control protocol is QMI or AT or something else, current userspace applications do. I am not entirely sure about how this should be handled, but it should be sorted out before we start adding non QMI devices to the driver. If we start adding non-QMI devices to the driver, then we should rename it to something more generic. Or, better yet, make the driver generic, and keep qmi_wwan a sub-driver with all the current device IDs. This puts way too much into the driver name, IMHO. I don't think renaming the driver or creating two distinct driver names for AT or QMI devices makes much sense, given that these drivers will be identical. FWIW it's just a coincidence that the qmi_wwan driver didn't end up being named huawei_something instead. Yeah, might be a coincidence but a driver name of qmi_wwan driving non-QMI devices still seems quite wrong. option driving non-option devices was also wrong, but at the time nobody pushed back on that. The correct solution at the time would have been to rename 'option' to wwan_serial or something like that. If we're going to pursue this, lets make the qmi_wwan driver a generic name instead. We could make the protocol (if known) an attribute of the cdc-wdm device, either in sysfs or adding another ioctl. A sysfs attribute would have been nice, but I guess the discussion around the message size attribute applies here too? While might be nice, it does have drawbacks and it's harder to get mistakes corrected if they are done in the kernel, due to how (in)frequently people update their kernels. I guess I'd say we stick with userspace solutions for this for now, even if it does duplicate the VID/PID lists or use probing. But if we do that, then we do handle QMI+ECM and AT+ECM devices differently, so maybe separate drivers makes sense anyway? So the net-port parts of qmi_wwan just do standard ECM then? Was it simply the case that, at the time, nobody else was doing quasi-ECM except Qualcomm? Dan Hmm, as usual I don't know what I want... Bjørn -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] USB: serial: option: blacklist intf1 for Huawei E173s-6
On Mon, 2013-11-11 at 18:27 +0100, Bjørn Mork wrote: Gustavo Zacarias gust...@zacarias.com.ar writes: 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. 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. Yeah, do that. Not all devices reliably support DHCP on the port. Configuring manually with the results of ^DHCP would be a more reliable test. Dan -- 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
Dan Williams d...@redhat.com writes: On Mon, 2013-11-11 at 18:03 +0100, Bjørn Mork wrote: Dan Williams d...@redhat.com writes: On Mon, 2013-11-11 at 15:43 +0100, Bjørn Mork wrote: Maybe run a small discussion on the ModemManager list first? This would be the first non-QMI device there, and I don't think userspace is prepared for that We've got a bug open for this in ModemManager: https://bugzilla.gnome.org/show_bug.cgi?id=699741 Quite a few 2008 - 2009-era SonyEricsson phones (TM-506 and others) and many of the Ericsson MBM WWAN minicards expose a cdc-wdm AT port, so this device wouldn't be the first to expose an AT-capable cdc-wdm port. Yes, I am fully aware of this. But currently there is an assumed relationship between driver and cdc-wdm protocol: cdc-wdm = AT (except for the unfortunate v3.4+5 Huawei QMI case) Assumed where? kernel or ModemManager? Maybe just in my head :-) I thought ModemManager based it's decisions wrt protocol on the driver? This puts way too much into the driver name, IMHO. I don't think renaming the driver or creating two distinct driver names for AT or QMI devices makes much sense, given that these drivers will be identical. FWIW it's just a coincidence that the qmi_wwan driver didn't end up being named huawei_something instead. Yeah, might be a coincidence but a driver name of qmi_wwan driving non-QMI devices still seems quite wrong. option driving non-option devices was also wrong, but at the time nobody pushed back on that. The correct solution at the time would have been to rename 'option' to wwan_serial or something like that. If we're going to pursue this, lets make the qmi_wwan driver a generic name instead. Well, I am sure you are right. We could make the protocol (if known) an attribute of the cdc-wdm device, either in sysfs or adding another ioctl. A sysfs attribute would have been nice, but I guess the discussion around the message size attribute applies here too? While might be nice, it does have drawbacks and it's harder to get mistakes corrected if they are done in the kernel, due to how (in)frequently people update their kernels. I guess I'd say we stick with userspace solutions for this for now, even if it does duplicate the VID/PID lists or use probing. But if we do that, then we do handle QMI+ECM and AT+ECM devices differently, so maybe separate drivers makes sense anyway? So the net-port parts of qmi_wwan just do standard ECM then? Yes. Only the descriptors are weird. The rest is standard ECM. Was it simply the case that, at the time, nobody else was doing quasi-ECM except Qualcomm? Limited by the devices I knew of. Bjørn -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] USB: serial: option: blacklist intf1 for Huawei E173s-6
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
Re: [PATCHv2] USB: serial: option: blacklist intf1 for Huawei E173s-6
On Mon, 2013-11-11 at 18:41 +0100, Bjørn Mork wrote: Dan Williams d...@redhat.com writes: On Mon, 2013-11-11 at 18:03 +0100, Bjørn Mork wrote: Dan Williams d...@redhat.com writes: On Mon, 2013-11-11 at 15:43 +0100, Bjørn Mork wrote: Maybe run a small discussion on the ModemManager list first? This would be the first non-QMI device there, and I don't think userspace is prepared for that We've got a bug open for this in ModemManager: https://bugzilla.gnome.org/show_bug.cgi?id=699741 Quite a few 2008 - 2009-era SonyEricsson phones (TM-506 and others) and many of the Ericsson MBM WWAN minicards expose a cdc-wdm AT port, so this device wouldn't be the first to expose an AT-capable cdc-wdm port. Yes, I am fully aware of this. But currently there is an assumed relationship between driver and cdc-wdm protocol: cdc-wdm = AT (except for the unfortunate v3.4+5 Huawei QMI case) Assumed where? kernel or ModemManager? Maybe just in my head :-) I thought ModemManager based it's decisions wrt protocol on the driver? It's a mix of driver names, device names, and udev rules. For example, ModemManager currently only cares about devices named cdc-wdm* when the USB device is driven by qmi_wwan or cdc_mbim. Otherwise these ports are ignored (as is the case for Ericsson devices). And this check only sets probing flags, so this could easily be extended to probe cdc-wdm devices for AT commands too. One example of solely driver-based detection is the 'hso' driver, which only drives Option HSO devices. In this case, ModemManager uses the driver name as the filter. This puts way too much into the driver name, IMHO. I don't think renaming the driver or creating two distinct driver names for AT or QMI devices makes much sense, given that these drivers will be identical. FWIW it's just a coincidence that the qmi_wwan driver didn't end up being named huawei_something instead. Yeah, might be a coincidence but a driver name of qmi_wwan driving non-QMI devices still seems quite wrong. option driving non-option devices was also wrong, but at the time nobody pushed back on that. The correct solution at the time would have been to rename 'option' to wwan_serial or something like that. If we're going to pursue this, lets make the qmi_wwan driver a generic name instead. Well, I am sure you are right. I've been wrong before :) We could make the protocol (if known) an attribute of the cdc-wdm device, either in sysfs or adding another ioctl. A sysfs attribute would have been nice, but I guess the discussion around the message size attribute applies here too? While might be nice, it does have drawbacks and it's harder to get mistakes corrected if they are done in the kernel, due to how (in)frequently people update their kernels. I guess I'd say we stick with userspace solutions for this for now, even if it does duplicate the VID/PID lists or use probing. But if we do that, then we do handle QMI+ECM and AT+ECM devices differently, so maybe separate drivers makes sense anyway? So the net-port parts of qmi_wwan just do standard ECM then? Yes. Only the descriptors are weird. The rest is standard ECM. Well, including all the IPv4/IPv6 quirks? Those seem to be Qualcomm specific; especially where the rawip/8023 and QoS options are concerned. Were we ever to support rawip or the QoS options, we'd need a completely different driver. My suggestion here would be to create a new cdc-ecm driver (like we did for cdc_eem or cdc_ether or cdc_ncm) and make qmi_wwan a sub-driver of that (if that's even needed given these all are subdrivers of usbnet). This way we keep standard ECM in one place and pile all the vendor-specific hacks into sub-drivers instead of tangling them all together? Dan Was it simply the case that, at the time, nobody else was doing quasi-ECM except Qualcomm? Limited by the devices I knew of. Bjørn -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] USB: serial: option: blacklist intf1 for Huawei E173s-6
Dan Williams d...@redhat.com writes: So the net-port parts of qmi_wwan just do standard ECM then? Yes. Only the descriptors are weird. The rest is standard ECM. Well, including all the IPv4/IPv6 quirks? No, all the firmware bugs are very implementation specific :-) I don't know if the ECM similarity is intentional or not. It's really a simple protocol, just transmitting plain ethernet frames over bulk USB. Those seem to be Qualcomm specific; especially where the rawip/8023 and QoS options are concerned. Were we ever to support rawip or the QoS options, we'd need a completely different driver. Yes. My suggestion here would be to create a new cdc-ecm driver (like we did for cdc_eem or cdc_ether or cdc_ncm) and make qmi_wwan a sub-driver of that (if that's even needed given these all are subdrivers of usbnet). This way we keep standard ECM in one place and pile all the vendor-specific hacks into sub-drivers instead of tangling them all together? This is pretty much what we already have there... All the networking code is in usbnet, and already shared with cdc_ether. The code in qmi_wwan is just a) device specific probing b) enabling the cdc-wdm subdriver c) quirks Nothing more. Bjørn -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] USB: serial: option: blacklist intf1 for Huawei E173s-6
On Fri, Nov 08, 2013 at 08:44:35AM +0100, Bjørn Mork wrote: Johan Hovold jhov...@gmail.com writes: Bjørn, do you want any more info for the commit message (e.g. interface layout)? 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. Ok. Thanks. Gustavo, could you fix up the commit message (the subject line) and resend so we can apply this? Thanks, Johan -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] USB: serial: option: blacklist intf1 for Huawei E173s-6
On Tue, Nov 05, 2013 at 07:20:41AM -0300, Gustavo Zacarias wrote:
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
Looks good to me, but perhaps you can change the subject line to read
USB: option: add support for Huawei E173s-6
or similar, as you're adding a new device id.
Bjørn, do you want any more info for the commit message (e.g. interface
layout)?
Thanks,
Johan
---
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_Q101 0xEA02
@@ -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
--
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
Johan Hovold jhov...@gmail.com writes: Bjørn, do you want any more info for the commit message (e.g. interface layout)? 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. Bjørn -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2] USB: serial: option: blacklist intf1 for Huawei E173s-6
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
