Re: Making qcserial more flexible

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Bjørn Mork <bjorn@xxxxxxx> writes:
> Dan Williams <dcbw@xxxxxxxxxx> writes:
>
>> 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've now tried to code this a few times, but am not satisfied with the
> result.  There are too many decision levels involved in the probe, which
> I'd really like to compress to a single switch statement:
>
>  1) number of interfaces
>     2) interface number
>        3) device type 
>
>
> And I don't have a single Gobi device to test this with, which pretty
> much guarantees that I will screw up something if I change more than a
> few characters...
>
> I'll follow up with the patches I've currenly got, which works for the
> Sierra Wireless MC7710, as a basis for further discussion. Would
> appreciate it if someone else (with one or more Gobi devices) could look
> at the patches and preferably do something better.

Anyone?  Should I just submit this set as-is?

New "Gobi 4000" device IDs are popping up as laptop vendors start
selling these things pre-installed.  Just noticed Lenovo adding MC7700
and MC7750 modules using different vendor IDs from the MC77xx we've got
covered.  These should be added to some serial driver, but I'd really
like to avoid "sierra" as the modules don't support that protocol and we
end up waiting for it to time out on probing.

Do we want qcserial to handle them?



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


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux