Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp2705334imu; Sun, 6 Jan 2019 08:05:10 -0800 (PST) X-Google-Smtp-Source: ALg8bN6830kokEMJ2F1jiYg0XK1RuMUxEHEAAGXPRywxTG19561UN/KIdwbJ1PVXvv2dEloYfQiH X-Received: by 2002:a63:4c4e:: with SMTP id m14mr8097449pgl.173.1546790710834; Sun, 06 Jan 2019 08:05:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1546790710; cv=none; d=google.com; s=arc-20160816; b=Xaa7W8H9W6DcF2pHF220+o8alYURcEqoTL5+qtvkHXdUiFjzNwBeRjFs/OnH63HK83 j4kvVqyDjnKVwjAr/IDx2GEt/1p6EuUurl2iQlGOK5EYYsP1aZjjv/Vfu2efNKaBv7iq bd+4XbrSPUyAszJgC0qXOn4eTqqIjABuD7OPlPN3t2fKElpL54gIYxZji78Ia5uBgPC+ wXDM6fR7NFYe80LE4zfDbIhONxKXg0eQThZfN10ldsA6vwe5ucAqYdTohCma1zjGbkst N6eux+ptFsmY2rJg1w/44fZWniKckzFE3Mr7YcdvZbTvtaF30HeJ9p71bHddcKRc6kh/ wFMQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=9B5yAHbtohHhEISKyhexiyMnx6cf4oNuChpuKrQkwfE=; b=M0rmAEmSscZ0vb3NCBGDNO2TB9qjk7NcEcaRwlTPzXrexEMhjNfolD7WE+DqJ1MtPe gzYS/AaG2GA9sJXZIeCZUsGga3wCcYsteau+RBVUpHdsj+lTXeJDp9dTr8ptIOjYL6rx 4vts6lmyp9kd97iojlh+5tPwE8uNdgkF1uSdpqfsw0fzjuxe3tnITKYXJMTNasdzgiMA gE9P34uiHD4/8xDoGLf6J2ohFn76VMdIyV7aqm8j+iAU9XLfEd8Q+NcXgx38liQ8D67i 0+BIuE20psS6oD8I0sJBRZCN8HKEkcx7UiJ387uHu3m2DiZKi7YSuyjvWBZ06kDM7ohr sWMQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass (test mode) header.i=@ideasonboard.com header.s=mail header.b=GlKyi1mD; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i13si60893040pgj.199.2019.01.06.08.04.55; Sun, 06 Jan 2019 08:05:10 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass (test mode) header.i=@ideasonboard.com header.s=mail header.b=GlKyi1mD; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726476AbfAFQCl (ORCPT + 99 others); Sun, 6 Jan 2019 11:02:41 -0500 Received: from perceval.ideasonboard.com ([213.167.242.64]:54854 "EHLO perceval.ideasonboard.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726431AbfAFQCh (ORCPT ); Sun, 6 Jan 2019 11:02:37 -0500 Received: from localhost.localdomain (unknown [96.44.9.229]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id D6EABE46; Sun, 6 Jan 2019 17:02:33 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1546790556; bh=us7SXvcOup8YY288VjEztT4JFcsjDYfGO3KSbF0zXGQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=GlKyi1mD8QIH3uO1IiJt2sU/C+iuVA7WjvJYh7tPeoHlwic8r2cJ9h5I2bEUQpMXV in+ZmxcnRoh7x6c0p2e6yyVMPNbVOF7Dkxqc1/DeAPFL0x5HVmo3MfPfNkuu4zFYJd fpApEN+cEF8D2MbRSRtFU5oCnCGudRtv1qxRsLYM= From: Paul Elder To: laurent.pinchart@ideasonboard.com, kieran.bingham@ideasonboard.com Cc: Paul Elder , b-liu@ti.com, stern@rowland.harvard.edu, rogerq@ti.com, balbi@kernel.org, gregkh@linuxfoundation.org, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v4 2/6] usb: gadget: uvc: enqueue usb request in setup handler for control OUT Date: Sun, 6 Jan 2019 11:02:17 -0500 Message-Id: <20190106160221.4480-3-paul.elder@ideasonboard.com> X-Mailer: git-send-email 2.19.2 In-Reply-To: <20190106160221.4480-1-paul.elder@ideasonboard.com> References: <20190106160221.4480-1-paul.elder@ideasonboard.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Currently, for uvc class-specific control IN and OUT requests, in the setup handler a UVC_EVENT_SETUP with the setup control is enqueued to userspace. In response to this, the uvc function driver expects userspace to call ioctl UVCIOC_SEND_RESPONSE containing uvc request data. In the case of control IN this is fine, but for control OUT it causes a problem. Since the host sends data immediately after the setup stage completes, it is possible that the empty uvc request data is not enqueued in time for the UDC driver to put the data stage data into (this causes some UDC drivers, such as MUSB, to reply with a STALL). This problem is remedied by having the setup handler enqueue the empty uvc request data, instead of waiting for userspace to do it. Signed-off-by: Paul Elder Reviewed-by: Laurent Pinchart --- No change from v3 No change from v2 No change from v1 drivers/usb/gadget/function/f_uvc.c | 25 +++++++++++++++++++------ drivers/usb/gadget/function/uvc_v4l2.c | 7 +++++++ 2 files changed, 26 insertions(+), 6 deletions(-) diff --git a/drivers/usb/gadget/function/f_uvc.c b/drivers/usb/gadget/function/f_uvc.c index 3472a2863436..96054403418a 100644 --- a/drivers/usb/gadget/function/f_uvc.c +++ b/drivers/usb/gadget/function/f_uvc.c @@ -223,8 +223,6 @@ static int uvc_function_setup(struct usb_function *f, const struct usb_ctrlrequest *ctrl) { struct uvc_device *uvc = to_uvc(f); - struct v4l2_event v4l2_event; - struct uvc_event *uvc_event = (void *)&v4l2_event.u.data; if ((ctrl->bRequestType & USB_TYPE_MASK) != USB_TYPE_CLASS) { uvcg_info(f, "invalid request type\n"); @@ -241,10 +239,25 @@ uvc_function_setup(struct usb_function *f, const struct usb_ctrlrequest *ctrl) uvc->event_setup_out = !(ctrl->bRequestType & USB_DIR_IN); uvc->event_length = le16_to_cpu(ctrl->wLength); - memset(&v4l2_event, 0, sizeof(v4l2_event)); - v4l2_event.type = UVC_EVENT_SETUP; - memcpy(&uvc_event->req, ctrl, sizeof(uvc_event->req)); - v4l2_event_queue(&uvc->vdev, &v4l2_event); + if (uvc->event_setup_out) { + struct usb_request *req = uvc->control_req; + + /* + * Enqueue the request immediately for control OUT as the + * host will start the data stage straight away. + */ + req->length = uvc->event_length; + req->zero = 0; + usb_ep_queue(f->config->cdev->gadget->ep0, req, GFP_KERNEL); + } else { + struct v4l2_event v4l2_event; + struct uvc_event *uvc_event = (void *)&v4l2_event.u.data; + + memset(&v4l2_event, 0, sizeof(v4l2_event)); + v4l2_event.type = UVC_EVENT_SETUP; + memcpy(&uvc_event->req, ctrl, sizeof(uvc_event->req)); + v4l2_event_queue(&uvc->vdev, &v4l2_event); + } return 0; } diff --git a/drivers/usb/gadget/function/uvc_v4l2.c b/drivers/usb/gadget/function/uvc_v4l2.c index 4b0a82cc4763..9f7c67f6f4b2 100644 --- a/drivers/usb/gadget/function/uvc_v4l2.c +++ b/drivers/usb/gadget/function/uvc_v4l2.c @@ -35,6 +35,13 @@ uvc_send_response(struct uvc_device *uvc, struct uvc_request_data *data) struct usb_composite_dev *cdev = uvc->func.config->cdev; struct usb_request *req = uvc->control_req; + /* + * For control OUT transfers the request has been enqueued synchronously + * by the setup handler, there's nothing to be done here. + */ + if (uvc->event_setup_out) + return 0; + if (data->length < 0) return usb_ep_set_halt(cdev->gadget->ep0); -- 2.19.2