On Wed, 2012-05-23 at 21:43 +0200, Bjørn Mork wrote:
> 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 was just about to suggest that. I think qcserial's probing is not
flexible enough. We should have hints that existing devices are Gobi1K
or Gobi2K and thus assume the current code during probe, and then those
devices that don't match the generic Gobi layouts get per-interface
matching.
So we'd have two sets of matching:
1) VID/PID for "plain" Gobi devices like we do now, with hints for G1K
and G2K+ that the probe function interprets the same way it does now
2) VID/PID + intf# for devices that aren't plain Gobi liek the Sierra
MC7700
Does that sound like a good plan? That way we don't have to duplicate
the existing Gobi card entries 3 times each.
> >> 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).
Ok. Do you happen to remember if it supported HIP/CnS in Sierra-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.
Yeah, though instead of the crackrock custom driver info we always have
to do for non-Gobi devices here, I'd rather use the patch you added for
matching with USB interface #.
Dan
>
>
> 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
--
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
