> From: Gerhard Roth <[email protected]> > Date: Fri, 10 Jun 2016 00:31:44 +0200 > > On 10.06.2016 00:22, Stuart Henderson wrote: > > On 2016/06/10 00:10, Mark Kettenis wrote: > >>> From: Gerhard Roth <[email protected]> > >>> Date: Thu, 9 Jun 2016 23:48:23 +0200 > >>> > >>> On 09.06.2016 23:42, Mark Kettenis wrote: > >>>>> Date: Thu, 9 Jun 2016 22:59:28 +0200 (CEST) > >>>>> From: Mark Kettenis <[email protected]> > >>>>> > >>>>>> Date: Wed, 8 Jun 2016 15:08:52 +0200 > >>>>>> From: Gerhard Roth <[email protected]> > >>>>>> > >>>>>> I would be glad to hear from some people trying this with a real MBIM > >>>>>> device. > >>>>> > >>>>> Sierra Wireless EM7345 4G LTE here. This devices currently attached > >>>>> as umodem(4). But I did add its vendor id and device id to umb_devs, > >>>>> which makes it partially attach: > >>>>> > >>>>> umb0 at uhub0 port 4 "Sierra Wireless Inc. Sierra Wireless EM7345 4G > >>>>> LTE" rev 2.00/17.29 addr 2 > >>>>> umb0: switching to config #1 > >>>>> umb0: ignoring invalid segment size 1500 > >>>>> umb0: ctrl_len=512, maxpktlen=8192, cap=0x4 > >>>>> umb0: no control interface found > >>>>> > >>>>> (this is with UMB_DEBUG enabled) > >>>>> > >>>>> It seems this device needs some additional poking to select alternate > >>>>> interface settings. > >>>> > >>>> With the appropriate alternate settings for the communication > >>>> interface and data interface (1 and 2) hardcoded in the driver, this > >>>> works! > >>> > >>> Great! > >>> > >>> Although another example of a device violating the MBIM spec which > >>> clearly states that alternate settings 0 and 1 have to be used. > >> > >> Which version of the spec are you looking at? Because my copy > >> (Revision 1.0 Errata-1) clearly status alternate settings 1 and 2 have > >> to be used ;). > > > > There are different sections, 3.2 for dual-mode (NCM1.0 / MBIM) > > devices talks about various alternate settings for NCM1.0 and > > for MBIM, then 6.6 which is only dealing with MBIM just talks > > about 0 and 1 .. > > > > That's how I looked at it, too. But it seems that some vendors look > at it differently ;) > > So we should find a solution where we don't need to use the > currently hard-coded MBIM_INTERFACE_ALTSETTING (== 1) anymore.
I don't think that is too difficult. The alternate settings are encoded in the bAlternateSetting of the Interface Descriptor. So we just need to remmeber those when we iterate over the full set of interface descriptors at the start of umb_attach(). In any case this is something we can figure out once the code hits the tree. Unless mpi@ is still unhappy with the way the driver performs ioctls, I think we should get the driver bits into the tree such that we can work on fixing the remaining issues with it. The ifconfig bits seem to be a bit more controversial. And we defenitely need to test those in a RAMDISK context as well.
