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