03f0:521d Hewlett-Packard
Harald Jung
jung at ecos.de
Tue Sep 16 07:14:49 PDT 2014
so the "ordinary" option driver worked with the patch from the last post.
So there is the question if it would make sense to make some tests with
the mbim stuff?
Dunno how long I'll have the notebook here, the option driver would be
okay for us.
I'll have to check a fujitsu laptop, too.
Details will follow in a new post.
Am 15.09.2014 um 12:39 schrieb Bjørn Mork:
> Aleksander Morgado <aleksander at aleksander.es> writes:
>
>> +Bjørn
>>
>> On Mon, Sep 8, 2014 at 8:17 PM, Harald Jung <jung at ecos.de> wrote:
>>> i have the same notebook for some days from this thread:
>>> https://www.mail-archive.com/linux-usb@vger.kernel.org/msg45745.html
>>>
>>> Are the problems fixed?
>>> or what can i do do give you further informations?
> Ah, thanks for the reminder. All my pre-vacation memory is completely
> erased, so I needed that.
>
> So to recall:
>
> 1. Use MBIM
>
> 2. Use MBIM :-)
>
> 3. As for the the remaining vendor specific parts...
>
> Dan posted a Windows driver overview covering this device here,
> indicating that it is a "Jungo" device (i.e not QMI, but possibly with
> an AT command "cdc-wdm" channel instead?):
> https://www.mail-archive.com/linux-usb@vger.kernel.org/msg45848.html
>
> This matches the bInterfaceSubClass "2" vendor specific functions, which
> AFAIK is used by Huawei "Jungo" firmwares. I guess we could/should(?)
> just add a few HP vendor entries similar to the Huawei class entries in
> "option" for the serial functions. I.e. something like
>
> { USB_VENDOR_AND_INTERFACE_INFO(HP_VENDOR_ID, 0xff, 0x02, 0x01) },
> { USB_VENDOR_AND_INTERFACE_INFO(HP_VENDOR_ID, 0xff, 0x02, 0x02) },
> { USB_VENDOR_AND_INTERFACE_INFO(HP_VENDOR_ID, 0xff, 0x02, 0x03) },
> { USB_VENDOR_AND_INTERFACE_INFO(HP_VENDOR_ID, 0xff, 0x02, 0x04) },
> { USB_VENDOR_AND_INTERFACE_INFO(HP_VENDOR_ID, 0xff, 0x02, 0x05) },
>
> That should provide a few AT command speaking serial ports, which might
> support ppp. Should I just propose such a patch to Johan & Co?
>
> But you do of course want something faster. MBIM is simplest. The
> vendor specific route is still unsupported. I don't think we've seen the
> exact type of network function using bInterfaceProtocol "7" before
> (although the Huawei drivers suggests that it exists):
>
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 4
> bAlternateSetting 0
> bNumEndpoints 1
> bInterfaceClass 255 Vendor Specific Class
> bInterfaceSubClass 2
> bInterfaceProtocol 7
> iInterface 0
> ** UNRECOGNIZED: 05 24 00 10 01
> ** UNRECOGNIZED: 0d 24 0f 01 05 00 00 00 ea 05 03 00 01
> ** UNRECOGNIZED: 05 24 06 04 04
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x87 EP 7 IN
> bmAttributes 3
> Transfer Type Interrupt
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0040 1x 64 bytes
> bInterval 5
>
> This alternate setting lacks the extra class descriptors, but have the
> bulk endpoints:
>
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 4
> bAlternateSetting 1
> bNumEndpoints 3
> bInterfaceClass 255 Vendor Specific Class
> bInterfaceSubClass 2
> bInterfaceProtocol 7
> iInterface 0
>
>
> Looking at the out-of-tree Huawei driver, I see this:
>
> /*Add for PID optimized marui 20100811*/
> #define HUAWEI_NDIS_OPTIMIZED_INTERFACE_JUNGO \
> .bInterfaceClass = 0xFF, \
> .bInterfaceSubClass = 0x02, \
> .bInterfaceProtocol = 0x07
>
> which is slighly different from the NCM variant we know very well by now
> (and support in the mainline huawei_cdc_ncm driver):
>
> /*Add for PID optimized liaojianping 20100811*/
> #define HUAWEI_NCM_OPTIMIZED_INTERFACE_JUNGO \
> .bInterfaceClass = 0xFF, \
> .bInterfaceSubClass = 0x02, \
> .bInterfaceProtocol = 0x16
>
>
> I've assumed that "NDIS" means "CDC ECM" framing. This may or may not
> be correct. We will have to see a few data frames to verify. I've also
> assumed that there is an AT command management channel inside the ECM
> funcion, similar to what we have for the NCM Huawei variant.
>
> If these assumptions are correct, then we don't have an appropriate
> driver exposing both data and command channel. The cdc_ether driver
> could support the network data transport, but will not provide access to
> the command channel. The qmi_wwan driver will do both, but I believe
> we've agreed not to use it for devices exposing anything but QMI over
> the embedded management channel. But qmi_wwan should still be good for
> testing because it is designed to allow dynamically added devices.
>
> Suggested test procedure (or start at least - this may need
> adjustments):
>
> modprobe option
> modprobe qmi_wwan
> echo "03f0 521d" > /sys/bus/usb-serial/drivers/option1/new_id
> echo "03f0 521d" > /sys/bus/usb/drivers/qmi_wwan/new_id
> echo "x-y:1.4" > /sys/bus/usb/drivers/option/unbind
> echo "x-y:1.4" > /sys/bus/usb/drivers/qmi_wwan/bind
>
>
> You need to replace the "x-y" with whatever bus/port this device is on.
> Use e.g. "ls -l /sys/bus/usb/drivers/option" to figure it out. You'll
> see symlinks to all the bound USB interfaces.
>
> Unless I've screwed up my untested example, then this will give to a
> number of /dev/ttyUSBx devices - at least some of them should accept AT
> commands. And there should be one wwanX network device, and one
> /dev/cdc-wdmX device. If my assumptions are correct then the
> /dev/cdc-wdmX will also support AT commands (but it is not a TTY so
> minicom will not work). If you are lucky then the wwanX network device
> can be connected using AT^NDISDUP or similar Huawei specific AT
> commands. I don't remember the exact details... Should be in the list
> archive.
>
> If we can figure out the network device, then we could discuss what to
> do about it. A new minidriver is maybe the cleanest solution? But it
> will be terribly similar to the qmi_wwan driver (excluding all the
> Qualcomm specific firmware quirks of course)...
>
>
> Bjørn
> _______________________________________________
> ModemManager-devel mailing list
> ModemManager-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
More information about the ModemManager-devel
mailing list