On Tue, 2014-10-28 at 10:26 +0100, Oliver Neukum wrote: > 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? >From a practical standpoint, I'm not it would be as useful as we all would like, mainly because the capabilities can be wrong and kernel changes filter down too slowly to distros. We (ModemManager) are 110% happy to keep adding to upstream blacklist/graylist/whitelists though. I've just added the device to the blacklist for MM 1.0, 1.2, 1.4, and git master. Dan -- 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
