Hello Gerhard,

On Wed, 3 Feb 2021 13:20:19 +0100
Gerhard Roth <gerhard_r...@genua.de> wrote:

> 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.

OK.  That's a quite a helpful update.  I'm not so familiar with the
umb(4) specifics.  Then at least this clarifies that the current
behaviour is fine.  Since we have now fixed the umb(4) problem with the
last usbdi.c commit I think we just keep it as is.

Reply via email to