On Mon, 22 Aug 2016, Bjørn Mork wrote: > Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> writes: > > > On Mon, 22 Aug 2016, Bjørn Mork wrote: > > > >> Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> writes: > >> > >> > On Sun, 21 Aug 2016, Jiri Slaby wrote: > >> > > >> >> Cc: proper lists. > >> >> > >> >> ep->desc.bInterval seems to be 0 here. > > > >> > As far as I can see, this isn't possible. The usb_parse_endpoint() > >> > routine in drivers/usb/core/config.c is supposed to guarantee that > >> > ep->desc.bInterval is never 0. > >> > >> That is if it is an ISO endpoint, right? > > > > I can't tell; the bug report doesn't say. However, ep->desc.bInterval > > is ignored for bulk and control endpoints, so it must be either > > isochronous or interrupt. > > So what if the endpoint is not isochronous or interrupt here? Oops. You're right; for some reason I thought that code was executed only if the endpoint type was known to be isochronous or interrupt. > > USB uses two different encodings for endpoint intervals. The second > > encoding above just gives the interval in frames; this is used for low- > > and full-speed interrupt endpoints. The first encoding above is > > exponential (it gives n where the actual interval is 2^(n-1) frames or > > microframes); this is used for all isochronous endpoints and for > > high-speed (or SuperSpeed etc.) interrupt endpoints. > > OK, I am still puzzled: Won't the code I quoted above do the shift for > *any* uurb->type and endpoint type? There doesn't seem to be any test > for isochronous or interrupt endpoint around it? Yes, that's the reason for the UBSAN report. I'll write a patch to fix it. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
