From: Tony Lindgren <tony@atomide.com>
To: Felipe Balbi <felipebalbi@users.sourceforge.net>
Cc: linux-omap-open-source@linux.omap.com
Subject: Re: [PATCH] USB: Fix OTG HNP for hub.c
Date: Tue, 29 May 2007 13:34:58 -0700 [thread overview]
Message-ID: <20070529203458.GB27603@atomide.com> (raw)
In-Reply-To: <31e679430705291224h5f1e8552paf8bff92f97f7f3f@mail.gmail.com>
* Felipe Balbi <felipebalbi@users.sourceforge.net> [070529 12:25]:
> Hi,
>
> On 5/29/07, David Brownell <david-b@pacbell.net> wrote:
>> On Tuesday 29 May 2007, Felipe Balbi wrote:
>> > From: Tony Lindgren <tony@atomide.com>
>> >
>> > This patch makes makes OTG Host Negotiation Protocol (HNP)
>> > to behave.
>>
>> Not really. It makes it strongly *MIS* behave in fact,
>> since it always kicks off HNP ... even when it should not
>> do so, because the device is in the whitelist. (Called
>> the "Targeted Peripherals List", TPL, in jargonese.)
>>
>> The two blocks of code are in the wrong order ...
Hmm, are you sure about that? My patch is based on
USB_TG_1-3.pdf and playing with usbcv13.exe and two N800s.
I'm under the impression that if the peripheral supports HNP, the
host must offer HNP at least once during the session.
And as I understand, the whitelist is for peripherals the host
supports, with HNP or no HNP.
With my patch, we offer to do HNP right in the beginning of the
session. Then the peripheral can use it or not use depending if
HNP is enabled on peripheral.
>> A more limited patch would help. Specifically, just
>> fixing whatever bug was seen in the original code,
>> rather than abstracting it into a new subroutine and
>> changing the logic while doing so.
Dave, did you ever get HNP working with any device and test
it with usbcv13.exe and OPT?
> Tony do you have any comments?
> Do you mind if I try to re-work you patch?
Felipe I guess you're the only one with OPT right now, and that's
really what we should use for doing the HNP. So go ahead!
Regards,
Tony
next prev parent reply other threads:[~2007-05-29 20:34 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-29 12:02 RFC PATCH Felipe Balbi
2007-05-29 12:02 ` [PATCH] USB: Disable file_storage USB_CONFIG_ATT_WAKEUP Felipe Balbi
2007-05-29 12:02 ` [PATCH] musb_hdrc: Implement workaround for tusb3.0 wbus bug rev2 Felipe Balbi
2007-05-29 12:02 ` [PATCH] musb_hdrc: Add SRP Interface and control it through sysfs Felipe Balbi
2007-05-29 12:02 ` [PATCH] Add Sysfs Interface to Control Vbus states Felipe Balbi
2007-05-29 12:02 ` [PATCH] Add more Test Modes Felipe Balbi
2007-05-29 12:02 ` [PATCH] musb_hdrc: Make HNP work Felipe Balbi
2007-05-29 12:02 ` [PATCH] USB: Fix OTG HNP for hub.c Felipe Balbi
2007-05-29 12:02 ` [PATCH] HSET tool for the MUSB Controler Felipe Balbi
2007-05-29 12:02 ` [PATCH] Leave GPIO[7:6] pullups enabled Felipe Balbi
[not found] ` <11804401803413-git-send-email-felipebalbi@users.sourceforge.net>
2007-05-29 12:02 ` [PATCH] Make SRP passes in all Electrical Tests Felipe Balbi
2007-05-29 14:39 ` Dirk Behme
2007-06-05 11:02 ` [PATCH] Leave GPIO[7:6] pullups enabled Tony Lindgren
2007-05-29 19:21 ` [PATCH] USB: Fix OTG HNP for hub.c David Brownell
2007-05-29 19:24 ` Felipe Balbi
2007-05-29 20:34 ` Tony Lindgren [this message]
2007-05-29 21:11 ` David Brownell
2007-05-29 21:26 ` Tony Lindgren
2007-05-29 17:16 ` [PATCH] Add more Test Modes David Brownell
2007-05-29 17:07 ` [PATCH] musb_hdrc: Add SRP Interface and control it through sysfs David Brownell
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=20070529203458.GB27603@atomide.com \
--to=tony@atomide.com \
--cc=felipebalbi@users.sourceforge.net \
--cc=linux-omap-open-source@linux.omap.com \
/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