On Tue, 16 Apr 2013, Hans de Goede wrote: > When usbfs receives a ctrl-request from userspace it calls check_ctrlrecip, > which for a request with USB_RECIP_ENDPOINT tries to map this to an interface > to see if this interface is claimed, except for ctrl-requests with a type of > USB_TYPE_VENDOR. > > When trying to use this device: http://www.akaipro.com/eiepro > redirected to a Windows vm running on qemu on top of Linux. > > The windows driver makes a ctrl-req with USB_TYPE_CLASS and > USB_RECIP_ENDPOINT with index 0, and the mapping of the endpoint (0) to > the interface fails since ep 0 is the ctrl endpoint and thus never is > part of an interface. This is bizarre. Why would a class specification include a class-type request to endpoint 0 with the endpoint as the recipient? The recipient should be the interface. > This patch fixes this ctrl-req failing by skipping the checkintf call for > USB_RECIP_ENDPOINT ctrl-reqs on the ctrl endpoint. > > Reported-by: Dave Stikkolorum <d.r.stikkolorum@xxxxxx> > Tested-by: Dave Stikkolorum <d.r.stikkolorum@xxxxxx> > Signed-off-by: Hans de Goede <hdegoede@xxxxxxxxxx> > --- > drivers/usb/core/devio.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c > index 8823e98..caefc80 100644 > --- a/drivers/usb/core/devio.c > +++ b/drivers/usb/core/devio.c > @@ -739,6 +739,8 @@ static int check_ctrlrecip(struct dev_state *ps, unsigned int requesttype, > index &= 0xff; > switch (requesttype & USB_RECIP_MASK) { > case USB_RECIP_ENDPOINT: > + if ((index & ~USB_DIR_IN) == 0) > + return 0; > ret = findintfep(ps->dev, index); > if (ret >= 0) > ret = checkintf(ps, ret); Anyway, this looks fine. Acked-by: Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> -- 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
