On Tue, 2014-10-28 at 10:05 +0100, Bjørn Mork wrote:
> Johan Hovold <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
