03f0:521d Hewlett-Packard

[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