[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-usb-devel
Subject:    Re: [linux-usb-devel] [PATCH] Fix OTG HNP for hub.c (USB OTG HNP
From:       David Brownell <david-b () pacbell ! net>
Date:       2007-05-30 1:33:32
Message-ID: 200705291833.32835.david-b () pacbell ! net
[Download RAW message or body]

On Tuesday 29 May 2007, Tony Lindgren wrote:
> * Felipe Balbi <felipebalbi@users.sourceforge.net> [070529 16:34]:
> > <snip>
> >
> >> > The behavioral difference would be that WHEN ("not 'IF'")
> >> > the whitelist (which is very easily checked against product
> >> > documentation) diverges from the list of configured drivers
> >> > (no easy way to crosscheck that and docs) things would not
> >> > act the same.
> >>
> >> I guess HNP should be offered for peripherals even if not
> >> on whitelist, but only peripherals on whitelist (with HNP
> >> or not) should be allowed.

Yes.  The "original" HNP logic in Linux was structured
to work just that way ... ISTR the original OTG spec was
not as clear as it should have been on "when to HNP".

The logic is:  If device is on whitelist, anything goes:
normal connection, or (later) HNP.

Otherwise, "normal connection" *must* never happen.  But
we might be on that device's whitelist, so try HNP.


> > Or maybe we run a set_feature (b_hnp_enabled) just before the
> > suspend... can we do that dave?? It doesn't seem really correct when
> > typing... but...

Yes, that can work.  That's the "original" path for blacklisted
devices, in fact...


> > If I'm not wrong... every device can accept a b_hnp_enable set_feature
> > command... if the controller doesn't support it just return a
> > "stall".. or something like that... so... we could just forget about
> > the whitelist for now.. can't we?
> >
> > If the device supports HNP it will get the b_hnp_enable command and
> > after a_host enters in suspend mode... it will try to do HNP (if the
> > user wants...)
> 
> AFAIK, all OTG devices need to support b_hnp_enable, but it's just
> a way to tell it that host supports HNP, it does not mean HNP should
> enabled.

Keep the terminology straight please.  Yes, OTG devices will by
definition support HNP and thus B_HNP_ENABLE.  So they can always
have HNP enabled, but setting it up so it's not used isn't the
same thing ...


> Enabling HNP should be done by the user on the b-device. 

No.  By definition B_HNP_ENABLE is set by the host.

The peripheral option is the B_BUS_REQ (see otg 1.2 spec,
section 6.6.1.9).  If that's false, HNP won't be used.

Conceptually, everything's a lot simpler if that's always
treated as true.  And the gadget stack doesn't have any
interface to request that it be anything else...


I happen to have a hard time thinking about why it should
ever be anything else ... Linux won't _know_ if it has any
work for that particular device until it knows what's hooked
up, and it can't know that until HNP kicks in and then the
B_HOST can tell what's there.  "It's a printer, and I have
print jobs queued ... great!"; or "It's a disk drive, let
the user see if they want to copy files"; or "darn, I need
to print these pictures in color but that printer is b/w;
too bad, disconnect/die".



> >> > This is more or less what you were trying to achieve,
> >> > yes?  But it leads to surprising behavior in cases
> >> > like:
> >> >
> >> >    * hook up non-OTG peripheral #1 ... acts just
> >> >      the way you'd normally expect
> >> >
> >> >    * hook up OTG peripheral #2 ... surprise!  it
> >> >      refuses to act as a peripheral at first.
> >> >
> >> > The "principle of least astonishment" argues that
> >> > the "peripheral #1" model should be followed for
> >> > as long as possible.  Customer service calls would
> >> > be a lot simpler too...
> >>
> >> Yeh I guess in that case it needs to wait for autosuspend
> >> until #1 is done.
> >>
> >> But if #2 is not on whitelist and can do HNP, then
> >> it just gets rejected and never gets it's HNP opportunity.
> >>
> >> Hmmm...
> 
> I guess the non-whitelisted b-device should sit waiting for HNP
> mode start when the host autosuspend suspends the bus?

For simplicity, treat "non-whitelist" as "blacklisted"...
easier to think that way.

Then:  however it's done, the blacklisted device isn't
going to know it's blacklisted except by inference:
if it never gets a SET_CONFIGURATION, and only gets a
chance to HNP, it was probably blacklisted.  (Not that
it has any reason to care about that.)


I'd prefer to just keep the existing logic:  if it's
blacklisted, dive immediately into HNP and don't let
enumeration go any further.  As I said earlier, any
other course is error prone ... because the official
list can disagree with the list of drivers that have
been configured.

- Dave


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[prev in list] [next in list] [prev in thread] [next in thread]