public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: Felipe Balbi <balbi@ti.com>
Cc: Tanya Brokhman <tlinder@codeaurora.org>,
	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, 11 Apr 2011 16:39:30 +0200	[thread overview]
Message-ID: <20110411143930.GD4018@linutronix.de> (raw)
In-Reply-To: <20110328084624.GI2251@legolas.emea.dhcp.ti.com>

* Felipe Balbi | 2011-03-28 11:46:25 [+0300]:

>> 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...

If I look at the diffstat between patch 2 and 4 I see 
| 30 files changed, 299 insertions(+), 393 deletions(-)

So she got rid of almost 100 lines. While looking at the code it seems
that every gadget driver does the same thing which is now done in one
place. I like that so far :)

Sebastian

      reply	other threads:[~2011-04-11 14:39 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-23  8:03 [PATCH 2/5 v6] usb: Add usb_endpoint_descriptor to be part of the struct usb_ep Tatyana Brokhman
2011-03-25 13:42 ` Felipe Balbi
2011-03-27 12:26   ` Tanya Brokhman
2011-03-28  8:46     ` Felipe Balbi
2011-04-11 14:39       ` Sebastian Andrzej Siewior [this message]

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=20110411143930.GD4018@linutronix.de \
    --to=bigeasy@linutronix.de \
    --cc=ablay@codeaurora.org \
    --cc=balbi@ti.com \
    --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