Re: Huawei ME906s-158 LTE, cdce(4) vs umb(4)
On 3/28/21 3:16 PM, Stuart Henderson wrote:
On 2021/03/28 13:40, Patrick Wildt wrote:
Am Sun, Mar 28, 2021 at 10:53:53AM +0100 schrieb Stuart Henderson:
On 2021/03/25 00:14, Stuart Henderson wrote:
On 2021/03/25 00:30, Patrick Wildt wrote:
Without having looked at anything, it might be worth looking at the most
recent mail in this thread:
'Re: [PATCH] umb(4) fix for X20 (DW5821e) in Dell Latitude 7300'
oh, usb runs through all drivers looking for a VID/PID match before
then running through all looking for a class match? I didn't realise
(thought it would try driver-by-driver with first VID/PID then class)
but that does make sense.
Updated diff below adding my pid/vid and tweaking some comments. My card
attaches to umb with this. I've only added it commented-out to the manual
for now until I see it actually pass traffic.
So this fixes Bryan's, at least improves mine (will look for another
sim / sim-adapter tomorrow), and seems targetted enough to not risk
fallout with existing working devices.
I think this makes sense to commit. OK with me if you'd like to commit
it Gerhard (I think it was your diff originally).
So this isn't enough for the Huawei yet but it doesn't make things
any worse, and helps for DW5821e.
If Gerhard isn't around, can I commit this bit so I'm not wrangling
things which should be separate commits? OK?
Yes, please do. ok patrick@
Thanks, done.
Since it looks like we're going to need additional quirks to get Huawei
to work and having three separate vid/pid tables seems silly, here's a
diff to change to using a single pid/vid table covering the matches and
the existing fccauth quirk.
Tested with EM7455 (fcc auth required; works as before) and Huawei
(attaches to the correct config descriptor; packet transfer not working
but this is not unexpected).
Hello Stuart,
this is fine with me. ok gerhard@
Index: if_umb.c
===
RCS file: /cvs/src/sys/dev/usb/if_umb.c,v
retrieving revision 1.38
diff -u -p -r1.38 if_umb.c
--- if_umb.c28 Mar 2021 12:08:58 - 1.38
+++ if_umb.c28 Mar 2021 13:10:56 -
@@ -224,34 +224,34 @@ const struct cfattach umb_ca = {
int umb_delay = 4000;
-/*
- * Normally, MBIM devices are detected by their interface class and subclass.
- * But for some models that have multiple configurations, it is better to
- * match by vendor and product id so that we can select the desired
- * configuration ourselves, e.g. to override a class-based match to another
- * driver.
- *
- * OTOH, some devices identify themselves as an MBIM device but fail to speak
- * the MBIM protocol.
- */
-struct umb_products {
+struct umb_quirk {
struct usb_devno dev;
- int confno;
+ u_int32_tumb_flags;
+ int umb_confno;
+ int umb_match;
};
-const struct umb_products umb_devs[] = {
- { { USB_VENDOR_DELL, USB_PRODUCT_DELL_DW5821E }, 2 },
- { { USB_VENDOR_HUAWEI, USB_PRODUCT_HUAWEI_ME906S }, 3 },
+const struct umb_quirk umb_quirks[] = {
+ { { USB_VENDOR_DELL, USB_PRODUCT_DELL_DW5821E },
+ 0,
+ 2,
+ UMATCH_VENDOR_PRODUCT
+ },
+
+ { { USB_VENDOR_HUAWEI, USB_PRODUCT_HUAWEI_ME906S },
+ 0,
+ 3,
+ UMATCH_VENDOR_PRODUCT
+ },
+
+ { { USB_VENDOR_SIERRA, USB_PRODUCT_SIERRA_EM7455 },
+ UMBFLG_FCC_AUTH_REQUIRED,
+ 0,
+ 0
+ },
};
#define umb_lookup(vid, pid) \
- ((const struct umb_products *)usb_lookup(umb_devs, vid, pid))
-
-/*
- * These devices require an "FCC Authentication" command.
- */
-const struct usb_devno umb_fccauth_devs[] = {
- { USB_VENDOR_SIERRA, USB_PRODUCT_SIERRA_EM7455 },
-};
+ ((const struct umb_quirk *)usb_lookup(umb_quirks, vid, pid))
uint8_t umb_qmi_alloc_cid[] = {
0x01,
@@ -283,10 +283,12 @@ int
umb_match(struct device *parent, void *match, void *aux)
{
struct usb_attach_arg *uaa = aux;
+ const struct umb_quirk *quirk;
usb_interface_descriptor_t *id;
- if (umb_lookup(uaa->vendor, uaa->product) != NULL)
- return UMATCH_VENDOR_PRODUCT;
+ quirk = umb_lookup(uaa->vendor, uaa->product);
+ if (quirk != NULL && quirk->umb_match)
+ return (quirk->umb_match);
if (!uaa->iface)
return UMATCH_NONE;
if ((id = usbd_get_interface_descriptor(uaa->iface)) == NULL)
@@ -317,6 +319,7 @@ umb_attach(struct device *parent, struct
{
struct umb_softc *sc = (struct umb_softc *)self;
struct usb_attach_arg *uaa = aux;
+ const struct umb_quirk *quirk;
usbd_status status;
struct usbd_desc_iter iter;
const usb_descriptor_t *desc;
@@ -339,13 +342,27 @@ umb_attach(struct device *parent, struct
sc->sc_ctrl_ifaceno = uaa->ifaceno;
ml_init(>sc_tx_ml);
+ quirk =
Re: Huawei ME906s-158 LTE, cdce(4) vs umb(4)
On 2021/03/28 13:40, Patrick Wildt wrote:
> Am Sun, Mar 28, 2021 at 10:53:53AM +0100 schrieb Stuart Henderson:
> > On 2021/03/25 00:14, Stuart Henderson wrote:
> > > On 2021/03/25 00:30, Patrick Wildt wrote:
> > > > Without having looked at anything, it might be worth looking at the most
> > > > recent mail in this thread:
> > > >
> > > > 'Re: [PATCH] umb(4) fix for X20 (DW5821e) in Dell Latitude 7300'
> > > >
> > >
> > > oh, usb runs through all drivers looking for a VID/PID match before
> > > then running through all looking for a class match? I didn't realise
> > > (thought it would try driver-by-driver with first VID/PID then class)
> > > but that does make sense.
> > >
> > > Updated diff below adding my pid/vid and tweaking some comments. My card
> > > attaches to umb with this. I've only added it commented-out to the manual
> > > for now until I see it actually pass traffic.
> > >
> > > So this fixes Bryan's, at least improves mine (will look for another
> > > sim / sim-adapter tomorrow), and seems targetted enough to not risk
> > > fallout with existing working devices.
> > >
> > > I think this makes sense to commit. OK with me if you'd like to commit
> > > it Gerhard (I think it was your diff originally).
> >
> > So this isn't enough for the Huawei yet but it doesn't make things
> > any worse, and helps for DW5821e.
> >
> > If Gerhard isn't around, can I commit this bit so I'm not wrangling
> > things which should be separate commits? OK?
>
> Yes, please do. ok patrick@
Thanks, done.
Since it looks like we're going to need additional quirks to get Huawei
to work and having three separate vid/pid tables seems silly, here's a
diff to change to using a single pid/vid table covering the matches and
the existing fccauth quirk.
Tested with EM7455 (fcc auth required; works as before) and Huawei
(attaches to the correct config descriptor; packet transfer not working
but this is not unexpected).
Index: if_umb.c
===
RCS file: /cvs/src/sys/dev/usb/if_umb.c,v
retrieving revision 1.38
diff -u -p -r1.38 if_umb.c
--- if_umb.c28 Mar 2021 12:08:58 - 1.38
+++ if_umb.c28 Mar 2021 13:10:56 -
@@ -224,34 +224,34 @@ const struct cfattach umb_ca = {
int umb_delay = 4000;
-/*
- * Normally, MBIM devices are detected by their interface class and subclass.
- * But for some models that have multiple configurations, it is better to
- * match by vendor and product id so that we can select the desired
- * configuration ourselves, e.g. to override a class-based match to another
- * driver.
- *
- * OTOH, some devices identify themselves as an MBIM device but fail to speak
- * the MBIM protocol.
- */
-struct umb_products {
+struct umb_quirk {
struct usb_devno dev;
- int confno;
+ u_int32_tumb_flags;
+ int umb_confno;
+ int umb_match;
};
-const struct umb_products umb_devs[] = {
- { { USB_VENDOR_DELL, USB_PRODUCT_DELL_DW5821E }, 2 },
- { { USB_VENDOR_HUAWEI, USB_PRODUCT_HUAWEI_ME906S }, 3 },
+const struct umb_quirk umb_quirks[] = {
+ { { USB_VENDOR_DELL, USB_PRODUCT_DELL_DW5821E },
+ 0,
+ 2,
+ UMATCH_VENDOR_PRODUCT
+ },
+
+ { { USB_VENDOR_HUAWEI, USB_PRODUCT_HUAWEI_ME906S },
+ 0,
+ 3,
+ UMATCH_VENDOR_PRODUCT
+ },
+
+ { { USB_VENDOR_SIERRA, USB_PRODUCT_SIERRA_EM7455 },
+ UMBFLG_FCC_AUTH_REQUIRED,
+ 0,
+ 0
+ },
};
#define umb_lookup(vid, pid) \
- ((const struct umb_products *)usb_lookup(umb_devs, vid, pid))
-
-/*
- * These devices require an "FCC Authentication" command.
- */
-const struct usb_devno umb_fccauth_devs[] = {
- { USB_VENDOR_SIERRA, USB_PRODUCT_SIERRA_EM7455 },
-};
+ ((const struct umb_quirk *)usb_lookup(umb_quirks, vid, pid))
uint8_t umb_qmi_alloc_cid[] = {
0x01,
@@ -283,10 +283,12 @@ int
umb_match(struct device *parent, void *match, void *aux)
{
struct usb_attach_arg *uaa = aux;
+ const struct umb_quirk *quirk;
usb_interface_descriptor_t *id;
- if (umb_lookup(uaa->vendor, uaa->product) != NULL)
- return UMATCH_VENDOR_PRODUCT;
+ quirk = umb_lookup(uaa->vendor, uaa->product);
+ if (quirk != NULL && quirk->umb_match)
+ return (quirk->umb_match);
if (!uaa->iface)
return UMATCH_NONE;
if ((id = usbd_get_interface_descriptor(uaa->iface)) == NULL)
@@ -317,6 +319,7 @@ umb_attach(struct device *parent, struct
{
struct umb_softc *sc = (struct umb_softc *)self;
struct usb_attach_arg *uaa = aux;
+ const struct umb_quirk *quirk;
usbd_status status;
struct usbd_desc_iter iter;
const usb_descriptor_t *desc;
@@ -339,13 +342,27 @@ umb_attach(struct device *parent, struct
sc->sc_ctrl_ifaceno =
Re: Huawei ME906s-158 LTE, cdce(4) vs umb(4)
Am Sun, Mar 28, 2021 at 10:53:53AM +0100 schrieb Stuart Henderson:
> On 2021/03/25 00:14, Stuart Henderson wrote:
> > On 2021/03/25 00:30, Patrick Wildt wrote:
> > > Without having looked at anything, it might be worth looking at the most
> > > recent mail in this thread:
> > >
> > > 'Re: [PATCH] umb(4) fix for X20 (DW5821e) in Dell Latitude 7300'
> > >
> >
> > oh, usb runs through all drivers looking for a VID/PID match before
> > then running through all looking for a class match? I didn't realise
> > (thought it would try driver-by-driver with first VID/PID then class)
> > but that does make sense.
> >
> > Updated diff below adding my pid/vid and tweaking some comments. My card
> > attaches to umb with this. I've only added it commented-out to the manual
> > for now until I see it actually pass traffic.
> >
> > So this fixes Bryan's, at least improves mine (will look for another
> > sim / sim-adapter tomorrow), and seems targetted enough to not risk
> > fallout with existing working devices.
> >
> > I think this makes sense to commit. OK with me if you'd like to commit
> > it Gerhard (I think it was your diff originally).
>
> So this isn't enough for the Huawei yet but it doesn't make things
> any worse, and helps for DW5821e.
>
> If Gerhard isn't around, can I commit this bit so I'm not wrangling
> things which should be separate commits? OK?
Yes, please do. ok patrick@
> > I added this product to usbdevs as a short string; the other Huawei
> > devices all say "HUAWEI Mobile xyz" rather than just "xyz" in the device
> > string which I think should be trimmed as well, probably worth doing
> > that on top.
> >
> >
> > Index: share/man/man4/umb.4
> > ===
> > RCS file: /cvs/src/share/man/man4/umb.4,v
> > retrieving revision 1.11
> > diff -u -p -r1.11 umb.4
> > --- share/man/man4/umb.412 May 2020 13:03:52 - 1.11
> > +++ share/man/man4/umb.425 Mar 2021 00:03:58 -
> > @@ -44,8 +44,10 @@ PIN again even if the system was reboote
> > The following devices should work:
> > .Pp
> > .Bl -tag -width Ds -offset indent -compact
> > +.It Dell DW5821e
> > .It Ericsson H5321gw and N5321gw
> > .It Fibocom L831-EAU
> > +.\" .It Huawei ME906s -- attaches but may need more work
> > .It Medion Mobile S4222 (MediaTek OEM)
> > .It Sierra Wireless EM7345
> > .It Sierra Wireless EM7455
> > Index: sys/dev/usb/if_umb.c
> > ===
> > RCS file: /cvs/src/sys/dev/usb/if_umb.c,v
> > retrieving revision 1.37
> > diff -u -p -r1.37 if_umb.c
> > --- sys/dev/usb/if_umb.c29 Jan 2021 17:06:19 - 1.37
> > +++ sys/dev/usb/if_umb.c24 Mar 2021 23:52:13 -
> > @@ -225,6 +225,28 @@ const struct cfattach umb_ca = {
> > int umb_delay = 4000;
> >
> > /*
> > + * Normally, MBIM devices are detected by their interface class and
> > subclass.
> > + * But for some models that have multiple configurations, it is better to
> > + * match by vendor and product id so that we can select the desired
> > + * configuration ourselves, e.g. to override a class-based match to another
> > + * driver.
> > + *
> > + * OTOH, some devices identify themselves as an MBIM device but fail to
> > speak
> > + * the MBIM protocol.
> > + */
> > +struct umb_products {
> > + struct usb_devno dev;
> > + int confno;
> > +};
> > +const struct umb_products umb_devs[] = {
> > + { { USB_VENDOR_DELL, USB_PRODUCT_DELL_DW5821E }, 2 },
> > + { { USB_VENDOR_HUAWEI, USB_PRODUCT_HUAWEI_ME906S }, 3 },
> > +};
> > +
> > +#define umb_lookup(vid, pid) \
> > + ((const struct umb_products *)usb_lookup(umb_devs, vid, pid))
> > +
> > +/*
> > * These devices require an "FCC Authentication" command.
> > */
> > const struct usb_devno umb_fccauth_devs[] = {
> > @@ -263,6 +285,8 @@ umb_match(struct device *parent, void *m
> > struct usb_attach_arg *uaa = aux;
> > usb_interface_descriptor_t *id;
> >
> > + if (umb_lookup(uaa->vendor, uaa->product) != NULL)
> > + return UMATCH_VENDOR_PRODUCT;
> > if (!uaa->iface)
> > return UMATCH_NONE;
> > if ((id = usbd_get_interface_descriptor(uaa->iface)) == NULL)
> > @@ -315,6 +339,43 @@ umb_attach(struct device *parent, struct
> > sc->sc_ctrl_ifaceno = uaa->ifaceno;
> > ml_init(>sc_tx_ml);
> >
> > + if (uaa->configno < 0) {
> > + /*
> > +* In case the device was matched by VID/PID instead of
> > +* InterfaceClass/InterfaceSubClass, we have to pick the
> > +* correct configuration ourself.
> > +*/
> > + uaa->configno = umb_lookup(uaa->vendor, uaa->product)->confno;
> > + DPRINTF("%s: switching to config #%d\n", DEVNAM(sc),
> > + uaa->configno);
> > + status = usbd_set_config_no(sc->sc_udev, uaa->configno, 1);
> > + if (status) {
> > + printf("%s:
Re: Huawei ME906s-158 LTE, cdce(4) vs umb(4)
On 2021/03/25 00:14, Stuart Henderson wrote:
> On 2021/03/25 00:30, Patrick Wildt wrote:
> > Without having looked at anything, it might be worth looking at the most
> > recent mail in this thread:
> >
> > 'Re: [PATCH] umb(4) fix for X20 (DW5821e) in Dell Latitude 7300'
> >
>
> oh, usb runs through all drivers looking for a VID/PID match before
> then running through all looking for a class match? I didn't realise
> (thought it would try driver-by-driver with first VID/PID then class)
> but that does make sense.
>
> Updated diff below adding my pid/vid and tweaking some comments. My card
> attaches to umb with this. I've only added it commented-out to the manual
> for now until I see it actually pass traffic.
>
> So this fixes Bryan's, at least improves mine (will look for another
> sim / sim-adapter tomorrow), and seems targetted enough to not risk
> fallout with existing working devices.
>
> I think this makes sense to commit. OK with me if you'd like to commit
> it Gerhard (I think it was your diff originally).
So this isn't enough for the Huawei yet but it doesn't make things
any worse, and helps for DW5821e.
If Gerhard isn't around, can I commit this bit so I'm not wrangling
things which should be separate commits? OK?
> I added this product to usbdevs as a short string; the other Huawei
> devices all say "HUAWEI Mobile xyz" rather than just "xyz" in the device
> string which I think should be trimmed as well, probably worth doing
> that on top.
>
>
> Index: share/man/man4/umb.4
> ===
> RCS file: /cvs/src/share/man/man4/umb.4,v
> retrieving revision 1.11
> diff -u -p -r1.11 umb.4
> --- share/man/man4/umb.4 12 May 2020 13:03:52 - 1.11
> +++ share/man/man4/umb.4 25 Mar 2021 00:03:58 -
> @@ -44,8 +44,10 @@ PIN again even if the system was reboote
> The following devices should work:
> .Pp
> .Bl -tag -width Ds -offset indent -compact
> +.It Dell DW5821e
> .It Ericsson H5321gw and N5321gw
> .It Fibocom L831-EAU
> +.\" .It Huawei ME906s -- attaches but may need more work
> .It Medion Mobile S4222 (MediaTek OEM)
> .It Sierra Wireless EM7345
> .It Sierra Wireless EM7455
> Index: sys/dev/usb/if_umb.c
> ===
> RCS file: /cvs/src/sys/dev/usb/if_umb.c,v
> retrieving revision 1.37
> diff -u -p -r1.37 if_umb.c
> --- sys/dev/usb/if_umb.c 29 Jan 2021 17:06:19 - 1.37
> +++ sys/dev/usb/if_umb.c 24 Mar 2021 23:52:13 -
> @@ -225,6 +225,28 @@ const struct cfattach umb_ca = {
> int umb_delay = 4000;
>
> /*
> + * Normally, MBIM devices are detected by their interface class and subclass.
> + * But for some models that have multiple configurations, it is better to
> + * match by vendor and product id so that we can select the desired
> + * configuration ourselves, e.g. to override a class-based match to another
> + * driver.
> + *
> + * OTOH, some devices identify themselves as an MBIM device but fail to speak
> + * the MBIM protocol.
> + */
> +struct umb_products {
> + struct usb_devno dev;
> + int confno;
> +};
> +const struct umb_products umb_devs[] = {
> + { { USB_VENDOR_DELL, USB_PRODUCT_DELL_DW5821E }, 2 },
> + { { USB_VENDOR_HUAWEI, USB_PRODUCT_HUAWEI_ME906S }, 3 },
> +};
> +
> +#define umb_lookup(vid, pid) \
> + ((const struct umb_products *)usb_lookup(umb_devs, vid, pid))
> +
> +/*
> * These devices require an "FCC Authentication" command.
> */
> const struct usb_devno umb_fccauth_devs[] = {
> @@ -263,6 +285,8 @@ umb_match(struct device *parent, void *m
> struct usb_attach_arg *uaa = aux;
> usb_interface_descriptor_t *id;
>
> + if (umb_lookup(uaa->vendor, uaa->product) != NULL)
> + return UMATCH_VENDOR_PRODUCT;
> if (!uaa->iface)
> return UMATCH_NONE;
> if ((id = usbd_get_interface_descriptor(uaa->iface)) == NULL)
> @@ -315,6 +339,43 @@ umb_attach(struct device *parent, struct
> sc->sc_ctrl_ifaceno = uaa->ifaceno;
> ml_init(>sc_tx_ml);
>
> + if (uaa->configno < 0) {
> + /*
> + * In case the device was matched by VID/PID instead of
> + * InterfaceClass/InterfaceSubClass, we have to pick the
> + * correct configuration ourself.
> + */
> + uaa->configno = umb_lookup(uaa->vendor, uaa->product)->confno;
> + DPRINTF("%s: switching to config #%d\n", DEVNAM(sc),
> + uaa->configno);
> + status = usbd_set_config_no(sc->sc_udev, uaa->configno, 1);
> + if (status) {
> + printf("%s: failed to switch to config #%d: %s\n",
> + DEVNAM(sc), uaa->configno, usbd_errstr(status));
> + goto fail;
> + }
> + usbd_delay_ms(sc->sc_udev, 200);
> +
> + /*
> + * Need to do some
Re: Huawei ME906s-158 LTE, cdce(4) vs umb(4)
On 2021/03/25 00:30, Patrick Wildt wrote:
> Without having looked at anything, it might be worth looking at the most
> recent mail in this thread:
>
> 'Re: [PATCH] umb(4) fix for X20 (DW5821e) in Dell Latitude 7300'
>
oh, usb runs through all drivers looking for a VID/PID match before
then running through all looking for a class match? I didn't realise
(thought it would try driver-by-driver with first VID/PID then class)
but that does make sense.
Updated diff below adding my pid/vid and tweaking some comments. My card
attaches to umb with this. I've only added it commented-out to the manual
for now until I see it actually pass traffic.
So this fixes Bryan's, at least improves mine (will look for another
sim / sim-adapter tomorrow), and seems targetted enough to not risk
fallout with existing working devices.
I think this makes sense to commit. OK with me if you'd like to commit
it Gerhard (I think it was your diff originally).
I added this product to usbdevs as a short string; the other Huawei
devices all say "HUAWEI Mobile xyz" rather than just "xyz" in the device
string which I think should be trimmed as well, probably worth doing
that on top.
Index: share/man/man4/umb.4
===
RCS file: /cvs/src/share/man/man4/umb.4,v
retrieving revision 1.11
diff -u -p -r1.11 umb.4
--- share/man/man4/umb.412 May 2020 13:03:52 - 1.11
+++ share/man/man4/umb.425 Mar 2021 00:03:58 -
@@ -44,8 +44,10 @@ PIN again even if the system was reboote
The following devices should work:
.Pp
.Bl -tag -width Ds -offset indent -compact
+.It Dell DW5821e
.It Ericsson H5321gw and N5321gw
.It Fibocom L831-EAU
+.\" .It Huawei ME906s -- attaches but may need more work
.It Medion Mobile S4222 (MediaTek OEM)
.It Sierra Wireless EM7345
.It Sierra Wireless EM7455
Index: sys/dev/usb/if_umb.c
===
RCS file: /cvs/src/sys/dev/usb/if_umb.c,v
retrieving revision 1.37
diff -u -p -r1.37 if_umb.c
--- sys/dev/usb/if_umb.c29 Jan 2021 17:06:19 - 1.37
+++ sys/dev/usb/if_umb.c24 Mar 2021 23:52:13 -
@@ -225,6 +225,28 @@ const struct cfattach umb_ca = {
int umb_delay = 4000;
/*
+ * Normally, MBIM devices are detected by their interface class and subclass.
+ * But for some models that have multiple configurations, it is better to
+ * match by vendor and product id so that we can select the desired
+ * configuration ourselves, e.g. to override a class-based match to another
+ * driver.
+ *
+ * OTOH, some devices identify themselves as an MBIM device but fail to speak
+ * the MBIM protocol.
+ */
+struct umb_products {
+ struct usb_devno dev;
+ int confno;
+};
+const struct umb_products umb_devs[] = {
+ { { USB_VENDOR_DELL, USB_PRODUCT_DELL_DW5821E }, 2 },
+ { { USB_VENDOR_HUAWEI, USB_PRODUCT_HUAWEI_ME906S }, 3 },
+};
+
+#define umb_lookup(vid, pid) \
+ ((const struct umb_products *)usb_lookup(umb_devs, vid, pid))
+
+/*
* These devices require an "FCC Authentication" command.
*/
const struct usb_devno umb_fccauth_devs[] = {
@@ -263,6 +285,8 @@ umb_match(struct device *parent, void *m
struct usb_attach_arg *uaa = aux;
usb_interface_descriptor_t *id;
+ if (umb_lookup(uaa->vendor, uaa->product) != NULL)
+ return UMATCH_VENDOR_PRODUCT;
if (!uaa->iface)
return UMATCH_NONE;
if ((id = usbd_get_interface_descriptor(uaa->iface)) == NULL)
@@ -315,6 +339,43 @@ umb_attach(struct device *parent, struct
sc->sc_ctrl_ifaceno = uaa->ifaceno;
ml_init(>sc_tx_ml);
+ if (uaa->configno < 0) {
+ /*
+* In case the device was matched by VID/PID instead of
+* InterfaceClass/InterfaceSubClass, we have to pick the
+* correct configuration ourself.
+*/
+ uaa->configno = umb_lookup(uaa->vendor, uaa->product)->confno;
+ DPRINTF("%s: switching to config #%d\n", DEVNAM(sc),
+ uaa->configno);
+ status = usbd_set_config_no(sc->sc_udev, uaa->configno, 1);
+ if (status) {
+ printf("%s: failed to switch to config #%d: %s\n",
+ DEVNAM(sc), uaa->configno, usbd_errstr(status));
+ goto fail;
+ }
+ usbd_delay_ms(sc->sc_udev, 200);
+
+ /*
+* Need to do some manual setups that usbd_probe_and_attach()
+* would do for us otherwise.
+*/
+ uaa->nifaces = uaa->device->cdesc->bNumInterfaces;
+ for (i = 0; i < uaa->nifaces; i++) {
+ if (usbd_iface_claimed(sc->sc_udev, i))
+ continue;
+ id =
usbd_get_interface_descriptor(>device->ifaces[i]);
+
Re: Huawei ME906s-158 LTE, cdce(4) vs umb(4)
On Wed, Mar 24, 2021 at 11:23:11PM +, Stuart Henderson wrote: > In my ongoing search to find a umb(4) that will actually work that > isn't the one in my laptop (since my EM7305 has been a failure), > I picked up a Huawei ME906s-158 off ebay. It attaches to cdce and ugen > and fails to work: > > cdce0 at uhub2 port 4 configuration 2 interface 0 "Huawei Technologies Co., > Ltd. HUAWEI Mobile" rev 2.10/1.02 addr 3 > cdce0: could not find data bulk in > ugen0 at uhub2 port 4 configuration 2 "Huawei Technologies Co., Ltd. HUAWEI > Mobile" rev 2.10/1.02 addr 3 > > Any information I can find for it suggests that it does MBIM, and > indeed if I disable cdce in the kernel it picks up on a different > config: > > umb0 at uhub2 port 4 configuration 3 interface 0 "Huawei Technologies Co., > Ltd. HUAWEI Mobile" rev 2.10/1.02 addr 3 > ugen0 at uhub2 port 4 configuration 3 "Huawei Technologies Co., Ltd. HUAWEI > Mobile" rev 2.10/1.02 addr 3 > > and after I figured out which of the APU2's mPCIe slots is routed to > the SIM slot (the middle one) it actually negotiates with the network > > umb0: flags=8855 mtu 1500 > index 11 priority 6 llprio 3 > roaming disabled registration home network > state up cell-class LTE rssi -83dBm speed 143Mbps up 143Mbps down > SIM initialized PIN valid (3 attempts left) > subscriber-id 234 ICC-id 8944xxx provider 3 > device ML1ME906SM IMEI 867 firmware 11.617.04.00.00 > phone# +44xx APN 3internet > dns 217.171.132.0 217.171.135.0 > groups: egress > status: active > inet 94.197.84.2 --> 94.197.84.1 netmask 0xfffc > > It doesn't seem to be working properly yet (packets transmitted over it > don't arrive at the destination) but I'm not 100% convinced that it's > not the network yet, I'll find some more SIMs to try. > > In the meantime, any suggestions how to knock it out from attaching > to cdce? Is there a way to drop out in the attach routine (e.g. if there's > no data bulk in) to allow another driver to attempt attaching, > or is it committed to a specific driver once it has matched? > > If the latter, would it make sense for cdce to look for MBIM on > another configuration and skip matching in that case? Or do (move > or replicate) some of cdce_attach()'s checks in cdce_match so it > can skip attaching if cdce isn't going to work? > > There are loads of these showing up (probably from laptops broken for > parts) for about 20 $currency_units on ebay/similar now so it would > be quite nice to get them working. A few similar devices showed up > on the lists before but I haven't noticed anyone trying to disable > cdce on them yet. > https://www.google.com/search?q=huawei+%22cdce0:+could+not+find+data+bulk+in%22+site:openbsd-archive.7691.n7.nabble.com > > If anyone else is thinking of getting one to poke at, to use in an APU > they also need a M.2 -> mPCIe adapter (aka NGFF -> mPCIe) with 'B' key > (doesn't need a sim carrier on the adapter), plus whatever u.fl pigtails > and antennas (the proper multiband LTE antennas usually have SMA > connectors rather than the RP-SMA common with wifi). > > Descriptors from lsusb below (seach for "HUAWEI Mobile Broadband Module" > for the 'right' one). Without having looked at anything, it might be worth looking at the most recent mail in this thread: 'Re: [PATCH] umb(4) fix for X20 (DW5821e) in Dell Latitude 7300'
