Dan Williams <dcbw@xxxxxxxxxx> writes:
> On Fri, 2012-05-18 at 10:06 +0200, Bjørn Mork wrote:
>
>> Actually, I am not all that convinced that this is necessarily true for
>> the QMI speaking Sierra Wireless devices. The MC7710 does not like the
>> additional setup packets at all, resulting in an unwanted 5 second pause
>> in probing the first serial port:
>
> I said "usually" :) And that may not include QMI-based devices, but it
> does depend on the specifics. Does the MC7710 support TruInstall? (I'd
> guess not). Does it support the custom Sierra power state stuff? Does
> it support the custom NMEA port setup stuff? If the 7710 doesn't
> support this stuff, then it perhaps shouldn't go into sierra.
>
> But really, how standard is the option_send_setup() stuff anyway?
> Sierra sends the same setup packet too. Is *that* the thing the 7710
> doesn't like, or is it the custom Sierra power state or NMEA stuff?
>
>> I'm planning on researching this a bit more before proposing anything,
>> but I do suspect that the sierra driver is just plain wrong for this
>> device ("device" as in 1199:68a2, implying QMI mode).
>
> That would be great. The more we know the better.
I added a few debug printk's and the problem is obviously that the
MC7710 doesn't support the vendor specific SWIMS_USB_REQUEST_SetPower
control message when the firmware is running in QMI mode:
May 23 20:52:30 nemi kernel: [ 512.864469] USB Serial support registered for Sierra USB modem
May 23 20:52:30 nemi kernel: [ 512.864884] sierra 4-4:1.0: Sierra USB modem converter detected
May 23 20:52:30 nemi kernel: [ 512.864905] usb 4-4: sierra_startup
May 23 20:52:30 nemi kernel: [ 512.864912] usb 4-4: sierra_set_power_state swiState=0
May 23 20:52:35 nemi kernel: [ 517.864204] usb 4-4: sierra_set_power_state usb_control_msg() returned -110
May 23 20:52:35 nemi kernel: [ 517.864217] usb 4-4: Memory usage (urbs) interface #0, in=4, out=4
May 23 20:52:35 nemi kernel: [ 517.864439] usb 4-4: Sierra USB modem converter now attached to ttyUSB0
May 23 20:52:35 nemi kernel: [ 517.864489] sierra 4-4:1.2: Sierra USB modem converter detected
May 23 20:52:35 nemi kernel: [ 517.864506] usb 4-4: sierra_startup
May 23 20:52:35 nemi kernel: [ 517.864512] usb 4-4: sierra_set_power_state swiState=0
May 23 20:52:40 nemi kernel: [ 522.864279] usb 4-4: sierra_set_power_state usb_control_msg() returned -110
May 23 20:52:40 nemi kernel: [ 522.864293] usb 4-4: Memory usage (urbs) interface #2, in=4, out=4
May 23 20:52:40 nemi kernel: [ 522.864559] usb 4-4: Sierra USB modem converter now attached to ttyUSB1
May 23 20:52:40 nemi kernel: [ 522.864621] sierra 4-4:1.3: Sierra USB modem converter detected
May 23 20:52:40 nemi kernel: [ 522.864638] usb 4-4: sierra_startup
May 23 20:52:40 nemi kernel: [ 522.864644] usb 4-4: sierra_set_power_state swiState=0
May 23 20:52:45 nemi kernel: [ 527.864317] usb 4-4: sierra_set_power_state usb_control_msg() returned -110
May 23 20:52:45 nemi kernel: [ 527.864333] usb 4-4: Memory usage (urbs) interface #3, in=8, out=64
May 23 20:52:45 nemi kernel: [ 527.864572] usb 4-4: Sierra USB modem converter now attached to ttyUSB2
I also finally got hold of the CodeAurora based drivers Sierra Wireless
has made for this device, and it shows that they use a modified (to work
with the non-Gobi interface layout) "GobiSerial" driver for the QMI mode
vid:pid.
So, there is no doubt that the "sierra" driver is a bad choice for this
vid:pid.
However, I do not know what driver is a good choice... As you said, the
"option" driver is not really correct either. It's just flexible enough
to be usable. "qcserial" would the the natural choice as the mainline
version of "GobiSerial". But it cannot handle this device without some
changes due to the non-default interface layout.
How about extending the .driver_info usage in qcserial to provide a full
map of supported interfaces, instead of just a gobi1k flag? That would
make the driver more flexible and allow it to be used for more of the
non-Gobi Qualcomm based devices.
Whatdoyouthink?
>> I am not convinced about this either. The default interface layout of
>> the MC7710 in QMI mode is as shown above: ifs# 0, 2 and 3 are serial
>> ports (DM, NMEA and AT) while if#8 is QMI/wwan. Note the number on the
>> DM interface! qcserial won't handle this...
>
> My point above was also that if it supports HIP/CnS then we need to add
> *some* interfaces to sierra/sierra_net. I don't know if it does. But
> it would be nice to find out. Maybe the DirectIP/HIP/CnS devices also
> support QMI without the QMI-based ether port too :) In which case what
> driver should handle *that* interface?
No, it doesn't support HIP/CnS at all when the firmware runs in QMI
mode. Looks like the QMI mode expose exclusively Qualcomm protocols,
except for the Sierra specific AT commands still being available. It's
Qualcomm DM, QMI, NMEA (needing $GPS_START), and also a firmware
download mode with a single QDL interface like the Gobi devices (but
reusing the same vid:pid as for composite mode).
>> And then there are the other (non-default) QMI modes, having more
>> interfaces and therefore making qcserial fail completely.
>
> qcserial should only really be for plain Gobi devices; many
> manufacturers rebrand Gobis or change the IDs. Up until very recently
> the only Gobi devices we had were really plain Gobis. And clearly those
> should probably be driven by qcserial/qmi_wwan.
Well, I don't want to destroy the clean interface provided by the
qcserial driver, but I see that some vendors modify their version of the
GobiSerial driver to fit more than just Gobi interface layout. So how
about doing something like
static const struct qcserial_iface_info gobi1k = ...
static const struct qcserial_iface_info gobi2k = ...
#define DEVICE_G1K(v, p) \
USB_DEVICE(v, p), .driver_info = (kernel_ulong_t)&gobi1k
#define DEVICE_G2K(v, p) \
USB_DEVICE(v, p), .driver_info = (kernel_ulong_t)&gobi2k
#define DEVICE_G3K(v, p) \
USB_DEVICE(v, p), .driver_info = (kernel_ulong_t)&gobi2k
static const struct qcserial_iface_info some_odd_device = ...
static const struct usb_device_id id_table[] = {
/* Gobi 1000 devices */
{DEVICE_G1K(0x05c6, 0x9211)}, /* Acer Gobi QDL device */
..
/* Gobi 2000 devices */
{DEVICE_G2K(0x1410, 0xa010)}, /* Novatel Gobi 2000 QDL device */
..
/* Gobi 3000 devices */
{DEVICE_G2K(0x03f0, 0x371d)}, /* HP un2430 Gobi 3000 QDL */
..
/* non Gobi Qualcomm devices */
{USB_DEVICE(0x0000, 0xffff), .driver_info = (kernel_ulong_t)&some_odd_device},
..
}
And then let the probe use the .driver_info to figure out the serial
interface layout. This would allow the probe function to be simplified
a bit as well.
Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
