Re: xhci spec (mis?)interpretation on hubs

[Sprow <webpages%sprow.co.uk@localhost>]

In article <3ef1728a-54fb-6c89-5634-e39ca9808d18%netbsd.org@localhost>,
   Nick Hudson <skrll%netbsd.org@localhost> wrote:
> On 12/19/17 20:32, Sprow wrote:
> > In article <5fc73ccd-26a2-7919-17e3-8098ccb3f8a1%netbsd.org@localhost>,
> >     Nick Hudson <skrll%netbsd.org@localhost> wrote:
> >> On 12/17/17 10:40, Nick Hudson wrote:
> >>> On 12/08/17 18:25, Sprow wrote:
> >>>> I've been having a look on a USB analyser at a class of hubs that
> >>>> don't seem to work on a driver based on
> >>>>     src/sys/dev/usb/xhci.c
> >>>>
> >>>> Comparing the dialogue for a non XHCI controller I see the issue is
> >>>> that the cascade of hubs is HS->FS->LS. The GetDescriptor of the LS
> >>>> device never makes it through.
> >> Can you try this patch?
> > I think there's a missing '(' on the IS_MTTHUB() macro.
>
> How so?

It used to read

#define IS_TTHUB(dd) \
    ((dd)->bDeviceProtocol == UDPROTO_HSHUBSTT || \
     (dd)->bDeviceProtocol == UDPROTO_HSHUBMTT)

then I applied

-#define IS_TTHUB(dd) \
-    ((dd)->bDeviceProtocol == UDPROTO_HSHUBSTT || \
+#define IS_MTTHUB(dd) \

leaving me with

#define IS_MTTHUB(dd) \
     (dd)->bDeviceProtocol == UDPROTO_HSHUBMTT)

which is missing a bracket.

> > The check around line 3201 still needs the '!ishub' qualifier in my view,
> > because the else could be reached if the speed/IS_MTTHUB checks fail. 
>
> The "FS/LS" device can be a hub so it's incorrect to test for !ishub, I 
> think.

Good point, yes. Previously I got away with that in my test because the
HS->FS step also happened that the "parent" hub was the HS one, but
HS->FS->FS->LS wouldn't have worked.

Thanks for taking a look at this,
Sprow.