From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Felipe Balbi <balbi@kernel.org>, linux-usb@vger.kernel.org
Cc: Greg KH <greg@kroah.com>, Joel Stanley <joel@jms.id.au>,
Andrew Jeffery <andrew@aj.id.au>
Subject: [v5,1/2] usb/gadget: Add an EP dispose() callback for EP lifetime tracking
Date: Tue, 20 Mar 2018 08:41:09 +1100 [thread overview]
Message-ID: <1521495669.16434.229.camel@kernel.crashing.org> (raw)
On Mon, 2018-03-19 at 12:56 +0200, Felipe Balbi wrote:
> >> do you really need this to be safe? You don't seem to be modifying
> >> ep_list here.
> >
> > Yes, ep->dispose() may do just that. In my Aspeed implementation in
> > fact that's pretty much the first thing it does.
> >
> > IE, I'm returning all the endpoints to the common pool, thus taking
> > them out of the gadget EP list.
> >
> > That said, there could be other reasons why a driver might want to know
> > about disposal without actually taking all the EPs back (for example a
> > driver could have some dedicated EPs and some in a pool) so I prefer
> > the list_del remaining in the back-end.
>
> That seems rather obfuscated. There's no indication that ep_list is
> modified from within that iteration block. Seems like it would be best
> to make the list_del() explicit and ->dispose() just adds the ep to its
> own internal list. No?
The problem with this approach is that other existing UDC drivers who
don't do dynamic EP management might break since they assume the EPs
remain in the EP list for ever.
So we would have to make the list_del conditional to the presence of
the ->dispose callback, or add a flag or something like that, which I
don't find particularily elegant either.
Also it's the backend that adds to the EP list, it should be the
backend that removes from it to. I don't like when you end up in a
situation where a different "layer" does half of the work. It gets more
confusing and bug prone. The ep_list management is under ownership of
the UDC and thus should probably remain that way imho.
I think it makes sense from a high level perspective to say that the
UDC backend can optionally support disposing of EPs. I think all that's
needed here is maybe adding a comment to my patch, something along
those lines:
/*
* Some UDC backends have a dynamic EP allocation scheme.
*
* In that case, the dispose() callback is used to notify the
* backend that the EPs are no longer in use.
*
* Note: The UDC backend can remove the EP from the ep_list as
* a result, so we need to use the _safe list iterator.
*/
list_for_each_entry_safe(ep, tmp_ep,
&cdev->gadget->ep_list, ep_list) {
...
Would that work for you ?
Cheers,
Ben.
---
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next reply other threads:[~2018-03-19 21:41 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-19 21:41 Benjamin Herrenschmidt [this message]
-- strict thread matches above, loose matches on Subject: below --
2018-03-22 8:57 [v5,1/2] usb/gadget: Add an EP dispose() callback for EP lifetime tracking Felipe Balbi
2018-03-19 10:56 Felipe Balbi
2018-03-17 0:37 Benjamin Herrenschmidt
2018-03-16 11:02 Felipe Balbi
2018-03-16 0:44 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=1521495669.16434.229.camel@kernel.crashing.org \
--to=benh@kernel.crashing.org \
--cc=andrew@aj.id.au \
--cc=balbi@kernel.org \
--cc=greg@kroah.com \
--cc=joel@jms.id.au \
--cc=linux-usb@vger.kernel.org \
/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).