Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp5579237pxj; Wed, 23 Jun 2021 04:37:06 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzNCa+W6AIs1F6PmFZ0DAeiCUyCvhCK1zNsvBFdL4Fn61bR5VMiovrIG9bHt0+vaMnkDkyx X-Received: by 2002:a5d:804c:: with SMTP id b12mr6724016ior.15.1624448226633; Wed, 23 Jun 2021 04:37:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1624448226; cv=none; d=google.com; s=arc-20160816; b=f8wRYSR4J6n2vlm52OlAoQKhaPb3dnEwzrFW1Pn2xuy2w17uwSNdiolmZl8Poj2M/g qpi06Jj/+Yi1CUOAqhq6D2VGgHHXzoQozf6uYFxReC1NrZjv7Y91ejTeKcJWAP6MVQTL uX77qSG0CrzN4MY2PQ3bcx5LRkqHlQ72aj69thtSmWgEZkqhu9n9fHNYIZ7qy0+B4/Hn EgztOzznhK+ZyAf2iGp/xCCmEDkc1DZ/CtlxLD45OesCh2eTAZE520N7e37YwYV1nFUr +SrSsqtEo+K7kgFQfwca/BNb7vLktu/bE2YfyUC9hE4laoaNSxnqssjABr09OfXbaBZ9 kB3A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=jEZZ45DDuHRyrCjf7s6YEOD5EkkxDfbTtLLvuE0tHI0=; b=ai6cRiTPtCXw0PT2jFQtL6iKgn8Y5L7QWzyqJiA5b4TWvFRICev/kXurn0pEyKIYv0 gczAm0FTeMaTRd/CutWKTj1Ps4y5RgMrme2qlpIzZ6DyZBmtGSAN0meZrgdPmnG0X0JD 1xZPwo0qXgB+j58oXBLAYpUVhMxReLXTmBhCwHf3WI/Tl0TLyeInFkid7c00Vi5soeV4 doGaRlJY16y6RDFn2InnZhoWup2JaEXaLZ47iGpPyJRTRIB4ZQAHsZ8RXhEzeYGHHxc1 fG/RgRFAK4GO9+dZFo8OnjINoJwx/8XcYdOzRmUv97plsRNvjgnhtThOaNhOJd0d5lGU MewQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=JFYjYfsP; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u18si2490173jap.83.2021.06.23.04.36.54; Wed, 23 Jun 2021 04:37:06 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=JFYjYfsP; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230202AbhFWLiR (ORCPT + 99 others); Wed, 23 Jun 2021 07:38:17 -0400 Received: from mail.kernel.org ([198.145.29.99]:43504 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230031AbhFWLiQ (ORCPT ); Wed, 23 Jun 2021 07:38:16 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id DC5E76102A; Wed, 23 Jun 2021 11:35:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1624448159; bh=ULWB5KI+zjDyMD0EzoZpOHi/DdRro5AI6tgZ+h/zzr4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=JFYjYfsPgBYnn1bWADVLquINtLQ7FoXgseSi7z3HTLd4K4CDj+iL8tSv/mQJrTaws yKSow+w65tKtGKLQ8LrPzMS/TVpeS8CzW8TSpZkekpRaTvw4TdT/OVbDymMUJLES+4 s7Kwy6tcihIqEsuGy4wlGrZxVYKM9svzywvhaSRY= Date: Wed, 23 Jun 2021 13:35:56 +0200 From: Greg KH To: Wesley Cheng Cc: balbi@kernel.org, robh+dt@kernel.org, agross@kernel.org, bjorn.andersson@linaro.org, frowand.list@gmail.com, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-msm@vger.kernel.org, jackp@codeaurora.org, fntoth@gmail.com, heikki.krogerus@linux.intel.com, andy.shevchenko@gmail.com Subject: Re: [PATCH v10 2/6] usb: gadget: configfs: Check USB configuration before adding Message-ID: References: <1623923899-16759-1-git-send-email-wcheng@codeaurora.org> <1623923899-16759-3-git-send-email-wcheng@codeaurora.org> <012b0264-107a-5596-d73f-3a2fd20470cf@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 23, 2021 at 02:38:55AM -0700, Wesley Cheng wrote: > > > On 6/21/2021 11:05 PM, Greg KH wrote: > > On Mon, Jun 21, 2021 at 10:27:09PM -0700, Wesley Cheng wrote: > >> > >> > >> On 6/17/2021 4:07 AM, Greg KH wrote: > >>> On Thu, Jun 17, 2021 at 02:58:15AM -0700, Wesley Cheng wrote: > >>>> Ensure that the USB gadget is able to support the configuration being > >>>> added based on the number of endpoints required from all interfaces. This > >>>> is for accounting for any bandwidth or space limitations. > >>>> > >>>> Signed-off-by: Wesley Cheng > >>>> --- > >>>> drivers/usb/gadget/configfs.c | 22 ++++++++++++++++++++++ > >>>> 1 file changed, 22 insertions(+) > >>>> > >>>> diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c > >>>> index 15a607c..76b9983 100644 > >>>> --- a/drivers/usb/gadget/configfs.c > >>>> +++ b/drivers/usb/gadget/configfs.c > >>>> @@ -1374,6 +1374,7 @@ static int configfs_composite_bind(struct usb_gadget *gadget, > >>>> struct usb_function *f; > >>>> struct usb_function *tmp; > >>>> struct gadget_config_name *cn; > >>>> + unsigned long ep_map = 0; > >>>> > >>>> if (gadget_is_otg(gadget)) > >>>> c->descriptors = otg_desc; > >>>> @@ -1403,7 +1404,28 @@ static int configfs_composite_bind(struct usb_gadget *gadget, > >>>> list_add(&f->list, &cfg->func_list); > >>>> goto err_purge_funcs; > >>>> } > >>>> + if (f->fs_descriptors) { > >>>> + struct usb_descriptor_header **d; > >>>> + > >>>> + d = f->fs_descriptors; > >>>> + for (; *d; ++d) { > >> > >> Hi Greg, > >> > >> Thanks for the review and feedback. > >> > >>> > >>> With this check, there really is not a need to check for > >>> f->fs_descriptors above in the if statement, right? > >>> > >> > >> f->fs_descriptor will carry the table of descriptors that a particular > >> function driver has assigned to it. The for loop here, will dereference > >> the individual descriptors within that descriptor array, so we need to > >> first ensure the descriptor array is present before traversing through > >> the individual entries/elements. > > > > Ah, it's a dereference of an array element. Subtle. Tricky. Messy :( > > > >>>> + struct usb_endpoint_descriptor *ep; > >>>> + int addr; > >>>> + > >>>> + if ((*d)->bDescriptorType != USB_DT_ENDPOINT) > >>>> + continue; > >>>> + > >>>> + ep = (struct usb_endpoint_descriptor *)*d; > >>>> + addr = ((ep->bEndpointAddress & 0x80) >> 3) | > >>>> + (ep->bEndpointAddress & 0x0f); > >>> > >>> Don't we have direction macros for this type of check? > >>> > >> > >> I don't believe we have a macro which would be able to convert the > >> bEndpointAddress field into the bit which needs to be set, assuming that > >> the 32bit ep_map has the lower 16bits carrying OUT EPs, and the upper > >> 16bits carrying the IN EPs. > > Hi Greg, > > > > > We have macros to tell if an endpoint is IN or OUT, please use those. > > > > And this "cram the whole thing into 64 bits" is not obvious at all. > > Just pass around the original pointer to the descriptors if someone > > wants to use it or not, don't make up yet-another-data-structure here > > for no good reason. We aren't so memory constrained we need to pack > > stuff into bits here. > > > > Hmm ok, what I can do is to move this logic into the check_config() > callback itself, which is implemented by the UDC driver. So now, the > DWC3 will have to do something similar to what is done here, ie loop the > EP descriptors for each function to determine the number of IN endpoints > being used. We have common USB core functions for this, why can't you just use them? Please do not take data that we already have in one format, and convert it to another one just for a single driver to consume. That's pointless. thanks, greg k-h