linux-kernel - Re: [PATCH v10 3/6] usb: dwc3: Resize TX FIFOs to meet EP bursting requirements

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <YNF96IxZre5iQus/@kroah.com>
Date:   Tue, 22 Jun 2021 08:06:32 +0200
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Wesley Cheng <wcheng@...eaurora.org>
Cc:     balbi@...nel.org, robh+dt@...nel.org, agross@...nel.org,
        bjorn.andersson@...aro.org, frowand.list@...il.com,
        linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
        devicetree@...r.kernel.org, linux-arm-msm@...r.kernel.org,
        jackp@...eaurora.org, fntoth@...il.com,
        heikki.krogerus@...ux.intel.com, andy.shevchenko@...il.com
Subject: Re: [PATCH v10 3/6] usb: dwc3: Resize TX FIFOs to meet EP bursting
 requirements

On Mon, Jun 21, 2021 at 10:27:13PM -0700, Wesley Cheng wrote:
> 
> 
> On 6/17/2021 4:10 AM, Greg KH wrote:
> > On Thu, Jun 17, 2021 at 02:58:16AM -0700, Wesley Cheng wrote:
> >> +static int dwc3_gadget_check_config(struct usb_gadget *g, unsigned long ep_map)
> >> +{
> >> +	struct dwc3 *dwc = gadget_to_dwc(g);
> >> +	unsigned long in_ep_map;
> >> +	int fifo_size = 0;
> >> +	int ram1_depth;
> >> +	int ep_num;
> >> +
> >> +	if (!dwc->do_fifo_resize)
> >> +		return 0;
> >> +
> >> +	/* Only interested in the IN endpoints */
> >> +	in_ep_map = ep_map >> 16;
> 
> Hi Greg,
> 
> > 
> > Wait, this "map" is split up into 16/16 somehow?  So it's only 32bits
> > big?
> >
> 
> Yes, correct. Upper 16 carries IN eps, lower 16 carries OUT eps.  Will
> fix that based off your other comment.
> 
> > Where did you document this map structure?  Why is it needed at all, you
> > have the gadget, don't you have access to the full list of endpoints
> > here as well?
> > 
> > confused,
> > 
> 
> Unfortunately, we do not have the entire list of endpoints for each
> function until the composite driver receives the SET_CONFIG packet from
> the host.  By this time, if we incorrectly allowed the configuration to
> start enumeration w/ the host, and there were some EPs which have no
> FIFO memory allocated, that would lead to those interfaces/functions
> being broken.

So how would this magic bitmap be any different here?

I'm not understanding why you need to create something new here to
represent data we already have.

thanks,

greg k-h