From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: USB list <linux-usb@vger.kernel.org>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Subject: Re: f_mass_storage vs drivers/target
Date: Thu, 22 Aug 2019 15:14:39 +1000 [thread overview]
Message-ID: <4c8a9941fb54dffd823335c9f4bc01f3158fb1d5.camel@kernel.crashing.org> (raw)
In-Reply-To: <cc5030dcc06868fe93af4899be004c5a802d783b.camel@kernel.crashing.org>
On Thu, 2019-08-22 at 14:58 +1000, Benjamin Herrenschmidt wrote:
>
> Ah lovely ... the 338x fails in EP autoconf with f_tcm, digging...
>
> While digging I found this gem:
>
> /* USB3380: use same address for usb and hardware endpoints */
> snprintf(name, sizeof(name), "ep%d%s", usb_endpoint_num(desc),
> usb_endpoint_dir_in(desc) ? "in" : "out");
> ep = gadget_find_ep_by_name(_gadget, name);
> if (ep && usb_gadget_ep_match_desc(_gadget, ep, desc, ep_comp))
> return ep;
>
> Any idea what's that supposed to achieve ?
>
> When ep_match is called, usb_endpoint_num() hasn't been set yet so
> it's always 0 and always fails... or am I missing something ?
Two problems:
- net2280.c doesn't set a max EP size, so autoconfig fails since
f_tcm specifies one. What about this ?
--- a/drivers/usb/gadget/udc/core.c
+++ b/drivers/usb/gadget/udc/core.c
@@ -940,12 +940,14 @@ int usb_gadget_ep_match_desc(struct usb_gadget *gadget,
if (usb_endpoint_dir_out(desc) && !ep->caps.dir_out)
return 0;
- if (max > ep->maxpacket_limit)
+ if (ep->maxpacket_limit && max > ep->maxpacket_limit)
return 0;
(ie assume that ep->maxpacket_limit 0 means the UDC supports any
legal size)
- No UDC driver other than dummy sets max_streams, and f_tcm requires 4,
so f_tcm will fail with *any* superspeed UDC driver as far as I can tell.
Was it ever tested with USB 3 ?
I'm not sure what the right fix here yet is as I yet have to learn about
what those USB3 streams are :-) For now I've commented things out.
It's still not working yet as configuring f_tcm seems to be a black art
with no useful documentation or examples anywhere (the device shows up on
the host but doesn't bind to any mass storage driver ... yet).
Cheers,
Ben.
next prev parent reply other threads:[~2019-08-22 5:14 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-21 3:38 f_mass_storage vs drivers/target Benjamin Herrenschmidt
2019-08-21 9:32 ` Greg KH
2019-08-21 14:25 ` Alan Stern
2019-08-22 0:10 ` Benjamin Herrenschmidt
2019-08-22 4:58 ` Benjamin Herrenschmidt
2019-08-22 5:14 ` Benjamin Herrenschmidt [this message]
2019-08-22 5:48 ` Benjamin Herrenschmidt
2019-08-22 17:30 ` Alan Stern
2019-08-23 0:40 ` Benjamin Herrenschmidt
2019-08-23 15:21 ` Alan Stern
2019-08-26 2:19 ` Benjamin Herrenschmidt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4c8a9941fb54dffd823335c9f4bc01f3158fb1d5.camel@kernel.crashing.org \
--to=benh@kernel.crashing.org \
--cc=bigeasy@linutronix.de \
--cc=linux-usb@vger.kernel.org \
--cc=stern@rowland.harvard.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).