On 2/3/21 12:51 PM, Marcus Glocker wrote:
On Wed, 3 Feb 2021 11:41:17 +0000
Edd Barrett <e...@theunixzoo.co.uk> wrote:
On Wed, Feb 03, 2021 at 11:17:01AM +0000, Stuart Henderson wrote:
btw the problem was seen with umb, it's not just ugen.
From mglocker@'s explanation, I understood that it is the ugen driver
trying to attach to some part of the device that in turn hoses umb for
the same device?
Maybe I misunderstood.
That's right. ugen(4) tries to attach to another umb(4) interface,
then fails, and labels the whole umb(4) device dying. I don't know if
all umb(4) devices show this behaviour (I don't have such a device).
But the other thing I was thinking about is whether we should make
umb(4) attach to this other interface as well to prevent ugen(4) to
take control.
I don't think that's a good idea. Sierra Wireless devices have an
"USB composite" (USBCOMP) where the user can select between several
modes. And each mode is a different composition of USB devices.
E.g. mode 8 gives you four different interfaces:
- DM (Device Management)
- NMEA (GPS Services)
- AT (AT Commands)
- MBIM
While mode 9 is MBIM only. So depending upon the USBCOMP selection,
the devices will offer completely different interfaces.
If umb would claim all interfaces, the other features become unusable.
And esp. AT commands can be very useful and allow to do things that
are not possible via MBIM.
If the additional interfaces are a problem, umb(4) could switch
Sierra Wireless modems into MBIM-only mode with QMI-over-MBIM
commands. But since the USBCOMP setting is persistent, that could
confuse dual-boot systems.
Gerhard
At some point you just have to say "this device is broken crap, send
it back or ebay it and buy an alternative". This is much easier for
some classes of device where there are many alternatives (like
audio interfaces) than mobile broadband where it's still very
difficult to find something suitable with the correct physical
interface.
Yes, I'm starting to lean in this direction too.
The only other solution would be to have some kind of quirks system,
but I don't think that'd be perfect either: I bet some (different)
devices share vendor and device IDs...
Well. I think there are a lot of USB device with all kind of
non-compliant USB configurations. That's why I personally think
spending too much efforts here, trying to make the right thing, isn't
worth it. You will fix something, and then break something else IMO.
I would rather focus on getting as much devices possible supported
without breaking others. Just as we did now :-)
