mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Felipe Balbi <balbi@ti.com>
To: Tanya Brokhman <tlinder@codeaurora.org>
Cc: balbi@ti.com, gregkh@suse.de, linux-arm-msm@vger.kernel.org,
	ablay@codeaurora.org,
	"'open list:USB GADGET/PERIPH...'" <linux-usb@vger.kernel.org>,
	"'open list'" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/5 v6] usb: Add usb_endpoint_descriptor to be part of the struct usb_ep
Date: Mon, 28 Mar 2011 11:46:25 +0300	[thread overview]
Message-ID: <20110328084624.GI2251@legolas.emea.dhcp.ti.com> (raw)
In-Reply-To: <000301cbec7a$3ff5cdf0$bfe169d0$@org>

On Sun, Mar 27, 2011 at 02:26:48PM +0200, Tanya Brokhman wrote:
> > 
> > On Wed, Mar 23, 2011 at 10:03:38AM +0200, Tatyana Brokhman wrote:
> > > Change usb_ep_enable() prototype to use endpoint descriptor from
> > usb_ep.
> > > This optimization spares the FDs from saving the endpoint chosen
> > > descriptor. This optimization is not full though. To fully exploit
> > this
> > > change one needs to update all the UDCs as well since in the current
> > > implementation each of them saves the endpoint descriptor in it's
> > > internal (and extended) endpoint structure.
> > 
> > I'm not sure this is such a good patch. But I don't have strong
> > arguments against it either.
> > 
> 
> Could you please share you concerns? Even if they are not strong arguments
> :).
> Our pros for this change were that it seems more accurate that the EP
> descriptor will be handled by the composite layer and not the FDs. Thus we
> tried to spare the FD from saving the chosen EP descriptor and passing it to
> different functions.
> This change is needed for our algorithm of SS implementation in the later
> patches in this series. 

Yes, I understood that much, but it's useful for UDCs to access the EP
descriptor (ok, we can still access it by dereferencing ep) since we can
(actually we need to) use that to let the HW know about max packet
sizes, endpoint types, etc etc.

Also, I'm not sure composite.c should know the details about the
endpoint. That's just a thin layer implementing the more generic part
(standard usb requests, handling, helpers for finding endpoints, etc),
but the one who should look into endpoint descriptors is the underlying
controller code for the reasons I listed above.

That's my feeling...

-- 
balbi

  reply	other threads:[~2011-03-28  8:46 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-23  8:03 Tatyana Brokhman
2011-03-25 13:42 ` Felipe Balbi
2011-03-27 12:26   ` Tanya Brokhman
2011-03-28  8:46     ` Felipe Balbi [this message]
2011-04-11 14:39       ` Sebastian Andrzej Siewior

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=20110328084624.GI2251@legolas.emea.dhcp.ti.com \
    --to=balbi@ti.com \
    --cc=ablay@codeaurora.org \
    --cc=gregkh@suse.de \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=tlinder@codeaurora.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

all inboxes | Powered by JetHome®