On Tue, Jan 10, 2017 at 7:08 PM, Dan Williams <d...@redhat.com> wrote:
> On Tue, 2017-01-10 at 18:33 +0100, Greg KH wrote: > > On Tue, Jan 10, 2017 at 06:23:13PM +0100, Lars Knudsen wrote: > > > > > > > > > On Jan 10, 2017 18:19, "Greg KH" <g...@kroah.com> wrote: > > > > > > On Tue, Jan 10, 2017 at 06:04:46PM +0100, Lars Knudsen wrote: > > > > I figured that made most sense :) > > > > > > > > Still, it would be good if we could have a rule to not grab > > > the CDC > > > interface > > > > part if the device includes WebUSB functionality. > > > > > > What exactly do you mean by "grab"? > > > > > > MM probing :) > > > > Probe should be fine, right? Are you really thinking that MM needs > > to > > go "oh look, a cdc device, let's go look at all of the raw interfaces > > to > > ensure it really isn't a webusb device as well before I touch it!" > > > > That way lies madness... > > > > What's wrong with touching it? The kernel already did, why would > > userspace care? > > And we're quite happy to keep blacklisting specific VID/PID combos we > know are not modems. Another possible solution is to greylist devices > that happen to have webusb descriptors, such that they won't get auto- > probed, but could be probed on-demand via D-Bus. But I'd rather that > happen via udev rules than MM trying to walk USB device attributes and > parsing webusb descriptors. > Actually, that sounds like a very good compromise. I remember my own struggles 3-4 years ago when I had to get a device working properly on ChromeOS and Ubuntu, where the firmware had to handle that the first ~16 seconds it would *sometimes* get sent strange AT commands (the probing) all while the system thought it could already start speaking with the device over e.g. chrome.serial. Eventually you (modemmanager) were kind enough to get our VID/PID listed and ChromeOS was quick to pick it up (~5-6 months to get in stable) and ubuntu so kind to upgrade to the version of modemmanager including our blacklisting approx 2.5 years later (sigh) ;) If greylisting prevents auto-probing, I think it would be very valuable for devices with a WebUSB header because those will in most cases (as I see them used) be industrial things (like my current medical company employer) or IoT devices. And waiting ~16 seconds for a fallback to USB Serial where WebUSB is not available (or for other reasons not chosen), can be a real pain. I agree that a solid udev rule would be a good way forward (I'll look into greylisting and see if I can come up with something that covers) and maybe this could also be the place to do the user space access (or not - I'll try to come back with something. thanks for all the input. Maybe Kenneth, Reilly or some working on USB related things in Intel have something to add? > > Dan > > > > > The likelihood of a modem+WebUSB combo is so small that it > > > must fall > > > > in the category where potential rare exotic devices combining > > > it must > > > > be whitelisted and the rest be left alone. > > > > > > I think you misunderstand just how crazy firmware authors can > > > be. I'm > > > sure we will see those types of devices in the wild. > > > > > > ...But realistically how many? Bothering 99.9% to support the > > > special case > > > seems less logical than just finding the 0.1% and whitelisting it > > > (if needed) > > > > That's the joy of writing an operating system for all devices on the > > planet, those 0.1% can be a lot of devices :) > > > > Anyway, I don't think there's much to do here just yet, let's wait > > and > > see just how bad these webusb devices end up looking like... > > > > thanks, > > > > greg k-h > > _______________________________________________ > > ModemManager-devel mailing list > > modemmanager-de...@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel >
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
