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.stikkolo...@hhs.nl>
> Tested-by: Dave Stikkolorum <d.r.stikkolo...@hhs.nl>
> Signed-off-by: Hans de Goede <hdego...@redhat.com>
> ---
> 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 <st...@rowland.harvard.edu>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
