Vojtech Pavlik wrote: > I'd have no problem with the per-interface one, if it is OK to allocate > other interfaces than the one for which the probe was called and if the > probe will be called even when the default configuration isn't CDC (many > modems have primary configuration vendor-specific). I'm not sure about > either and can't test it right now. The first issue (allocating interfaces other than the one for which probe() is called) is the same with either id table entry. Remember that the id table says "give me any interface where these properties are true". It doesn't matter whether you choose to test every interface where the device class is == 2, or only a single interface where the interface class is ==2 && the subclass is == 2; because you are still going to have to claim an interface other than the one for which probe() is called. As long as we probe() on a single interface, and some devices need more than one, then this problem exists. Plus, the API supports this behaviour - usb_driver_claim_interface() exists for this very reason :)
The second issue is important though. We need to ensure that we are calling acm_probe() on every appropriate device, even if we occasionally call it on a non-appropriate device. > As for the per-device approach, it's OK, but slighly unelegant and means > more modules than needed will be loaded. Since the per-device approach is safer (doesn't break things that used to work), and this is supposed to be a _stable_ kernel, I think I'd like to go back to per-device for a while. In the longer term (aka Mythical 2.5 Timeframe), perhaps we can sort out those modems that have weird configurations, simplify acm_probe() and perhaps even share some of the CDC parsing code. Vojtech: does this approach suit you? Brad _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
