From: "Brokhman Tatyana" <tlinder@codeaurora.org>
To: "Alan Stern" <stern@rowland.harvard.edu>
Cc: "Tatyana Brokhman" <tlinder@codeaurora.org>,
linux-usb@vger.kernel.org,
"David Brownell" <dbrownell@users.sourceforge.net>,
"Greg Kroah-Hartman" <gregkh@suse.de>,
linux-kernel@vger.kernel.org
Subject: Re: [RFC/PATCH 2/2] usb: Adding SuperSpeed support to dummy_hcd
Date: Tue, 12 Oct 2010 00:21:32 -0700 (PDT) [thread overview]
Message-ID: <3bcbaf2980892d18960a399f235fd993.squirrel@www.codeaurora.org> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1010101648230.30042-100000@netrider.rowland.org>
Hi Alan
Thanks you for your comments. Please see my reply inline.
Best Regards,
Tanya Brokhman
> On Sun, 10 Oct 2010, Tatyana Brokhman wrote:
>
>> USB 3.0 hub includes 2 hubs - HS and SS ones.
>> Thus, when dummy_hcd enabled it will register 2 root hubs (SS and HS).
>>
>> Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
>> ---
>> drivers/usb/gadget/dummy_hcd.c | 739
>> +++++++++++++++++++++++++++++++++-------
>> 1 files changed, 616 insertions(+), 123 deletions(-)
>
> I'd appreciate if you break this up into two patches. Separating out
> handle_control_request into a separate function is independent of the
> USB-3.0 conversion.
You're right about that. Will do.
I'll wait for others to review and send an updated patch soon.
>Also, you should update the kerneldoc title line
> for handle_control_request: the format is wrong and it contains a
> spelling error. (The format of the kerneldoc for the other new
> routines in this patch is also wrong.)
Will be fixed in the next patch version.
> In addition, I suspect the dummy_hcd driver structure shouldn't contain
> an address_device entry. It should be present only in dummy_ss_hcd.
I'm not sure I follow...
According to the code and comments in hub.c address_device cb is used if
the host controller wishes to choose the device address itself instead of
the address chosen by the core. It seems to me that there is nothing
preventing the dummy_hcd from supplying such cb as well. Is there?
Having both HS and SS dummy_hcd determine the device address seems more
convenient for testing proposes.
> Alan Stern
>
>
--
Sent by an consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
next prev parent reply other threads:[~2010-10-12 7:21 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-10 14:29 [RFC/PATCH 2/2] usb: Adding SuperSpeed support to dummy_hcd Tatyana Brokhman
2010-10-10 20:58 ` Alan Stern
2010-10-12 7:21 ` Brokhman Tatyana [this message]
2010-10-12 13:55 ` Alan Stern
2010-10-12 18:07 ` tlinder
2010-10-20 23:44 ` Sarah Sharp
2010-10-21 14:02 ` Alan Stern
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=3bcbaf2980892d18960a399f235fd993.squirrel@www.codeaurora.org \
--to=tlinder@codeaurora.org \
--cc=dbrownell@users.sourceforge.net \
--cc=gregkh@suse.de \
--cc=linux-kernel@vger.kernel.org \
--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