On Tue, 2014-10-28 at 10:05 +0100, Bjørn Mork wrote: > Johan Hovold <johan@xxxxxxxxxx> writes: > > > Today, only one device has the "NOT_A_MODEM" flag (*only* to prevent one > > message during probe), and most devices are simply matched on the > > interface class fields anyway. I'm not sure we want to start registering > > devices with broken bmCapabilities in the driver (rather than in say > > ModemManager). > > Dans example shows that there are devices with broken descriptors out > there, effectively making the Call Management bmCapabilities pretty > useless for everyone. I am sure that none of us are surprised by > this... There are lots of devices like that. Indeed. > Drop the quirk and demote the message to debug level. I have been a bit more radical. The message bloated the kernel and you can use lsusb. > A broken device registry is bound to be incomplete. New broken devices > are made every day, so it's not like MM ever can ignore a device with > zero bmCapabilities just because the device is not *known* to be broken. > All such devices must still be probed, making the registry pointless. That is not nice to the correct devices. > MM has a registry of devices which it should ignore, for example because > they aren't modems. Maintaining that list is much more interesting than > trying to make sense out of random data like the Call Management > bmCapabilities. Well, then I guess it is up to Dan. Would you use the exported capabilities? Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html