[PATCH] : Allow embedded developers USB options normally reserved for OTG

[PATCH] : Allow embedded developers USB options normally reserved for OTG

[Robin Getz]

From: Robin Getz <rgetz@blackfin.uclinux.org>

Allow embedded developers to turn support for USB Hubs off even if they have a 
full root hub. This saves the overhead (RAM and Flash size).

Allow embedded developers the capabilities of the "otg_whitelist.h" - a 
product whitelist, so USB peripherals not listed there will be rejected 
during enumeration. This is the desired operation for many embedded products.

Signed-off-by: Robin Getz <rgetz@blackfin.uclinux.org>

---

 drivers/usb/core/Kconfig |    7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)


Index: linux-2.6.x/drivers/usb/core/Kconfig
===================================================================
--- linux-2.6.x/drivers/usb/core/Kconfig	(revision 4074)
+++ linux-2.6.x/drivers/usb/core/Kconfig	(working copy)
@@ -95,8 +95,9 @@
 
 config USB_OTG_WHITELIST
 	bool "Rely on OTG Targeted Peripherals List"
-	depends on USB_OTG
-	default y
+	depends on USB_OTG || EMBEDDED
+	default y if USB_OTG
+	default n if EMBEDDED
 	help
 	  If you say Y here, the "otg_whitelist.h" file will be used as a
 	  product whitelist, so USB peripherals not listed there will be
@@ -111,7 +112,7 @@
 
 config USB_OTG_BLACKLIST_HUB
 	bool "Disable external hubs"
-	depends on USB_OTG
+	depends on USB_OTG || EMBEDDED
 	help
 	  If you say Y here, then Linux will refuse to enumerate
 	  external hubs.  OTG hosts are allowed to reduce hardware

Re: [linux-usb-devel] [PATCH] : Allow embedded developers USB options normally reserved for OTG

[David Brownell]

On Wednesday 02 January 2008, Robin Getz wrote:
> From: Robin Getz <rgetz@blackfin.uclinux.org>
> 
> Allow embedded developers to turn support for USB Hubs off even if they have a 
> full root hub. This saves the overhead (RAM and Flash size).

ISTR that it won't save very much code though ... the Linux USB
stack structures all its enumeration logic around hubs.


> Allow embedded developers the capabilities of the "otg_whitelist.h" - a 
> product whitelist, so USB peripherals not listed there will be rejected 
> during enumeration. This is the desired operation for many embedded products.
> 
> Signed-off-by: Robin Getz <rgetz@blackfin.uclinux.org>

This is probably the right thing to do.  Correct me if I'm wrong,
but USB-IF recently put out some specs about "embedded hosts" which
basically boil down to saying you can adopt the same functionality
restrictions that used to be OTG-only.  Which is why now there are
embedded developers who'd like this option.  :)

- Dave



> 
> ---
> 
>  drivers/usb/core/Kconfig |    7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> 
> Index: linux-2.6.x/drivers/usb/core/Kconfig
> ===================================================================
> --- linux-2.6.x/drivers/usb/core/Kconfig	(revision 4074)
> +++ linux-2.6.x/drivers/usb/core/Kconfig	(working copy)
> @@ -95,8 +95,9 @@
>  
>  config USB_OTG_WHITELIST
>  	bool "Rely on OTG Targeted Peripherals List"
> -	depends on USB_OTG
> -	default y
> +	depends on USB_OTG || EMBEDDED
> +	default y if USB_OTG
> +	default n if EMBEDDED
>  	help
>  	  If you say Y here, the "otg_whitelist.h" file will be used as a
>  	  product whitelist, so USB peripherals not listed there will be
> @@ -111,7 +112,7 @@
>  
>  config USB_OTG_BLACKLIST_HUB
>  	bool "Disable external hubs"
> -	depends on USB_OTG
> +	depends on USB_OTG || EMBEDDED
>  	help
>  	  If you say Y here, then Linux will refuse to enumerate
>  	  external hubs.  OTG hosts are allowed to reduce hardware
> 

Re: [linux-usb-devel] [PATCH] : Allow embedded developers USB options normally reserved for OTG

[Felipe Balbi]

On Wed, Jan 02, 2008 at 10:47:15AM -0800, David Brownell wrote:
> On Wednesday 02 January 2008, Robin Getz wrote:
> > From: Robin Getz <rgetz@blackfin.uclinux.org>
> > 
> > Allow embedded developers to turn support for USB Hubs off even if they have a 
> > full root hub. This saves the overhead (RAM and Flash size).
> 
> ISTR that it won't save very much code though ... the Linux USB
> stack structures all its enumeration logic around hubs.
> 
> 
> > Allow embedded developers the capabilities of the "otg_whitelist.h" - a 
> > product whitelist, so USB peripherals not listed there will be rejected 
> > during enumeration. This is the desired operation for many embedded products.
> > 
> > Signed-off-by: Robin Getz <rgetz@blackfin.uclinux.org>
> 
> This is probably the right thing to do.  Correct me if I'm wrong,
> but USB-IF recently put out some specs about "embedded hosts" which
> basically boil down to saying you can adopt the same functionality
> restrictions that used to be OTG-only.  Which is why now there are
> embedded developers who'd like this option.  :)

otg whitelist is not a blocker. A device that is not listed on TPL
might or might not work. The logic around that should be something like:

parse_whitelist()
if (!listed) {
	match_class_with_tpled_devices();
		if (match_any)
			check_power_need();
			if (power_need <= 100mA)
				allow_enumeration();
			else
				deny_enumaration_and_message();

If you check n810, you'll see that even though a usb memory stick is not
listed on its TPL, we allow it to enumerate as long as it draws less
then 100mA and this is true on something around 95% of usb memory
sticks.

I'm kinda busy with other tasks right now, but when I finish formating
proper patches for current mainline head, I'll release some code adding
support for dynamic otg tpl. The problem I see here is that my only
"user" is musb driver, currently only available on linux-omap git tree.

Maybe it's time to send it to mainline, what do you think Dave?

In any case, I'll format such patches when I'm done with twl4030 and
isp1301 development, something around 3 ~ 4 weeks from now.

Even though, embedded hosts should have the same behavior.

Best Regards,

Felipe Balbi

Re: [linux-usb-devel] [PATCH] : Allow embedded developers USB options normally reserved for OTG

[David Brownell]

On Wednesday 02 January 2008, Felipe Balbi wrote:
> 	 The problem I see here is that my only
> "user" is musb driver, currently only available on linux-omap git tree.
> 
> Maybe it's time to send it to mainline, what do you think Dave?

Probably time, yes.  ISTR the main open issues are on host side
behavior, and it'll be easier to sort those out if musb_hdrc can
be updated without a few months intervening lag time.

Plus that'll make it easier to merge the Blackfin platform updates
for that driver.  It's fine that musb_hdrc works on N800, N810,
DaVinci, OMAP2430, and more ... but non-TI chips also integrate
that high speed OTG silicon.  :)

- Dave

Re: [linux-usb-devel] [PATCH] : Allow embedded developers USB options normally reserved for OTG

[Mike Frysinger]

On Jan 2, 2008 1:47 PM, David Brownell <david-b@pacbell.net> wrote:
> On Wednesday 02 January 2008, Robin Getz wrote:
> > From: Robin Getz <rgetz@blackfin.uclinux.org>
> >
> > Allow embedded developers to turn support for USB Hubs off even if they have a
> > full root hub. This saves the overhead (RAM and Flash size).
>
> ISTR that it won't save very much code though ... the Linux USB
> stack structures all its enumeration logic around hubs.

perhaps the code size is arguable as to whether it really matters.
the reason we want it is that we have a USB host controller that will
not work with USB hubs, so we want to make sure the system does not
attempt such things.  (yes, such a USB host controller is retarded,
but the decision was out of our hands.)
-mike

Re: [linux-usb-devel] [PATCH] : Allow embedded developers USB options normally reserved for OTG

[David Brownell]

On Wednesday 02 January 2008, Mike Frysinger wrote:
> > >
> > > Allow embedded developers to turn support for USB Hubs off even if they have a
> > > full root hub. This saves the overhead (RAM and Flash size).
> >
> > ISTR that it won't save very much code though ... the Linux USB
> > stack structures all its enumeration logic around hubs.
> 
> perhaps the code size is arguable as to whether it really matters.
> the reason we want it is that we have a USB host controller that will
> not work with USB hubs, so we want to make sure the system does not
> attempt such things.  (yes, such a USB host controller is retarded,
> but the decision was out of our hands.)

Well, it won't work with *external* hubs.  Root hubs are a different
story.  :)

I think that's one of a class of decisions sometimes made by folk
who need to conserve silicon real estate.  Supporting external hubs
has always been optional for OTG systems.

- Dave

Re: [linux-usb-devel] [PATCH] : Allow embedded developers USB options normally reserved for OTG

[Alan Stern]

On Wed, 2 Jan 2008, Mike Frysinger wrote:

> perhaps the code size is arguable as to whether it really matters.
> the reason we want it is that we have a USB host controller that will
> not work with USB hubs, so we want to make sure the system does not
> attempt such things.  (yes, such a USB host controller is retarded,
> but the decision was out of our hands.)

Just out of curiosity, how does a host controller manage to avoid
working with external hubs?  Is it a matter of power consumption?  It
seems to me that in all other respects a hub should appear the same as
any other USB device.

Or is it a question of whether the controller works when communicating 
with devices behind an external hub?  And if it is, what is the 
difficulty?

Alan Stern

Re: [linux-usb-devel] [PATCH] : Allow embedded developers USB options normally reserved for OTG

[David Brownell]

On Wednesday 02 January 2008, Alan Stern wrote:
> On Wed, 2 Jan 2008, Mike Frysinger wrote:
> 
> > perhaps the code size is arguable as to whether it really matters.
> > the reason we want it is that we have a USB host controller that will
> > not work with USB hubs, so we want to make sure the system does not
> > attempt such things.  (yes, such a USB host controller is retarded,
> > but the decision was out of our hands.)
> 
> Just out of curiosity, how does a host controller manage to avoid
> working with external hubs? 

The transaction translators in external high speed hubs require
hosts to issue particular USB transactions.  If the host controller
doesn't implement the that split transaction support, then it won't
be supporting external hubs.

The Mentor USB High Speed Dual Role Host Controller silicon IP (using
the aforementioned musb_hdrc driver) is one example of such silicon.
The "Multipoint" licensing option is basically for the TT support,
as I understand it.

One example of its use in a product is with TI's DaVinci chips.  You
can go to http://focus.ti.com/docs/prod/folders/print/tms320dm6446.html
and download the USB controller docs.  Ignore the nasty CPPI DMA glued
onto it, and observe that there are host side TX and RX HUB registers
that won't be present on designs that omit the "multipoint" support.
(Which evidently include one of the Blackfin designs.)

- Dave

Re: [linux-usb-devel] [PATCH] : Allow embedded developers USB options normally reserved for OTG

[Alan Stern]

On Wed, 2 Jan 2008, David Brownell wrote:

> On Wednesday 02 January 2008, Alan Stern wrote:
> > On Wed, 2 Jan 2008, Mike Frysinger wrote:
> > 
> > > perhaps the code size is arguable as to whether it really matters.
> > > the reason we want it is that we have a USB host controller that will
> > > not work with USB hubs, so we want to make sure the system does not
> > > attempt such things.  (yes, such a USB host controller is retarded,
> > > but the decision was out of our hands.)
> > 
> > Just out of curiosity, how does a host controller manage to avoid
> > working with external hubs? 
> 
> The transaction translators in external high speed hubs require
> hosts to issue particular USB transactions.  If the host controller
> doesn't implement the that split transaction support, then it won't
> be supporting external hubs.

So in theory one could connect a high-speed hub to such a host
controller and expect it to communicate with high-speed devices.  So
long as no full- or low-speed devices are added there wouldn't be any
split transactions.  It wouldn't be USB-2.0 compliant but it should
still work.

Alan Stern

Re: [linux-usb-devel] [PATCH] : Allow embedded developers USB options normally reserved for OTG

[David Brownell]

On Wednesday 02 January 2008, Alan Stern wrote:
> 
> > The transaction translators in external high speed hubs require
> > hosts to issue particular USB transactions.  If the host controller
> > doesn't implement the that split transaction support, then it won't
> > be supporting external hubs.
> 
> So in theory one could connect a high-speed hub to such a host
> controller and expect it to communicate with high-speed devices.  So
> long as no full- or low-speed devices are added there wouldn't be any
> split transactions.  It wouldn't be USB-2.0 compliant but it should
> still work.

Yes ...

But that would be a nightmare in terms of support calls.  Take
two USB trees, and swap the hub ... suddenly one of the downstream
devices (the full speed one) starts (or stops!) working!  That's
not the sort of issue any support line wants to cope with on a
day-to-day basis.

The accounting for those products is often along the lines of:
if you got a support call, you didn't profit from that sale.
(And from the user perspective it's just a PITA and waste of
time.)  So *every* confusion like that one gets removed.

- Dave

Re: [linux-usb-devel] [PATCH] : Allow embedded developers USB options normally reserved for OTG

[Bryan Wu]

On Jan 3, 2008 4:58 AM, Alan Stern <stern@rowland.harvard.edu> wrote:
> On Wed, 2 Jan 2008, David Brownell wrote:
>
> > On Wednesday 02 January 2008, Alan Stern wrote:
> > > On Wed, 2 Jan 2008, Mike Frysinger wrote:
> > >
> > > > perhaps the code size is arguable as to whether it really matters.
> > > > the reason we want it is that we have a USB host controller that will
> > > > not work with USB hubs, so we want to make sure the system does not
> > > > attempt such things.  (yes, such a USB host controller is retarded,
> > > > but the decision was out of our hands.)
> > >
> > > Just out of curiosity, how does a host controller manage to avoid
> > > working with external hubs?
> >
> > The transaction translators in external high speed hubs require
> > hosts to issue particular USB transactions.  If the host controller
> > doesn't implement the that split transaction support, then it won't
> > be supporting external hubs.
>
> So in theory one could connect a high-speed hub to such a host
> controller and expect it to communicate with high-speed devices.  So
> long as no full- or low-speed devices are added there wouldn't be any
> split transactions.  It wouldn't be USB-2.0 compliant but it should
> still work.
>

Hmmm, basically, I think the answer is yes.

But when you tell customers your devices support USB 2.0, they will
try to plug-in lots of USB devices that you can not even imagine.
If they plug-in a combo USB device including an external USB hub, the
whole embedded Linux system maybe crash or hang there.
So this patch is to refuse enumerate such unsupported USB devices.

-Bryan Wu

RE: [linux-usb-devel] [PATCH] : Allow embedded developers USB options normally reserved for OTG

[Richard D]

> -----Original Message-----
> From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-
> owner@vger.kernel.org] On Behalf Of Alan Stern
> Sent: Thursday, January 03, 2008 2:29 AM
> To: David Brownell
> Cc: Mike Frysinger; gregkh@suse.de; linux-usb-
> devel@lists.sourceforge.net; Robin Getz; linux-kernel@vger.kernel.org
> Subject: Re: [linux-usb-devel] [PATCH] : Allow embedded developers USB
> options normally reserved for OTG
> 
> On Wed, 2 Jan 2008, David Brownell wrote:
> 
> > On Wednesday 02 January 2008, Alan Stern wrote:
> > > On Wed, 2 Jan 2008, Mike Frysinger wrote:
> > >
> > > > perhaps the code size is arguable as to whether it really
> matters.
> > > > the reason we want it is that we have a USB host controller that
> will
> > > > not work with USB hubs, so we want to make sure the system does
> not
> > > > attempt such things.  (yes, such a USB host controller is
> retarded,
> > > > but the decision was out of our hands.)
> > >
> > > Just out of curiosity, how does a host controller manage to avoid
> > > working with external hubs?
> >
> > The transaction translators in external high speed hubs require
> > hosts to issue particular USB transactions.  If the host controller
> > doesn't implement the that split transaction support, then it won't
> > be supporting external hubs.
> 
> So in theory one could connect a high-speed hub to such a host
> controller and expect it to communicate with high-speed devices.  So
> long as no full- or low-speed devices are added there wouldn't be any
> split transactions.  It wouldn't be USB-2.0 compliant but it should
> still work.


Perhaps we could reject any low/full speed devices after the USBV
enumeration phase itself. This would need perhaps a flag in the struct
hc_driver which the hub code (that does the enumeration) can check and
reject further enumeration?
Atleast this way we can support high speed devices.

Re: [linux-usb-devel] [PATCH] : Allow embedded developers USB options normally reserved for OTG

[Robin Getz]

On Wed 2 Jan 2008 13:47, David Brownell pondered:
> On Wednesday 02 January 2008, Robin Getz wrote:
> > From: Robin Getz <rgetz@blackfin.uclinux.org>
> > 
> > Allow embedded developers to turn support for USB Hubs off even if
> > they have a full root hub. This saves the overhead (RAM and Flash size).
> 
> ISTR that it won't save very much code though ... the Linux USB
> stack structures all its enumeration logic around hubs.

Today, there is an USB (Host), USB_GADGET and USB_OTG (which depends on USB && 
USB_GADGET).

This just enables cutting more code out, with out having to have USB_GADGET & 
USB_OTG enabled. When I checked - that is where most of the savings came 
from.

-Robin

Re: [linux-usb-devel] [PATCH] : Allow embedded developers USB options normally reserved for OTG

[David Brownell]

On Wednesday 02 January 2008, Robin Getz wrote:
> On Wed 2 Jan 2008 13:47, David Brownell pondered:
> > On Wednesday 02 January 2008, Robin Getz wrote:
> > > From: Robin Getz <rgetz@blackfin.uclinux.org>
> > > 
> > > Allow embedded developers to turn support for USB Hubs off even if
> > > they have a full root hub. This saves the overhead (RAM and Flash size).
> > 
> > ISTR that it won't save very much code though ... the Linux USB
> > stack structures all its enumeration logic around hubs.
> 
> Today, there is an USB (Host), USB_GADGET and USB_OTG (which depends on USB && 
> USB_GADGET).
> 
> This just enables cutting more code out, with out having to have USB_GADGET & 
> USB_OTG enabled. When I checked - that is where most of the savings came 
> from.

Right.  I'm not objecting to this at all.  Just pointing
out that usbcore will still end up including quite a lot
of hub functionality, because there's still going to be
a root hub in the system and a khubd managing it.

This patch might be improved slightly -- in ways that, as I
understand things, could save some RAM on Blackfin! -- by
having the BLACKLIST_HUB option get rid of the transaction
translator support (changing C code not just Kconfig).
It's pretty minimal, but won't be used...

Also, as you point out, it's no longer OTG specific, so
renaming the option would improve clarity.   Maybe to
something along the lines of USB_HOST_NO_EXTERNAL_HUBS.
No big deal, at least now.

- Dave

Re: [linux-usb-devel] [PATCH] : Allow embedded developers USB options normally reserved for OTG

[Bryan Wu]

On Jan 3, 2008 11:43 AM, David Brownell <david-b@pacbell.net> wrote:
> On Wednesday 02 January 2008, Robin Getz wrote:
> > On Wed 2 Jan 2008 13:47, David Brownell pondered:
> > > On Wednesday 02 January 2008, Robin Getz wrote:
> > > > From: Robin Getz <rgetz@blackfin.uclinux.org>
> > > >
> > > > Allow embedded developers to turn support for USB Hubs off even if
> > > > they have a full root hub. This saves the overhead (RAM and Flash size).
> > >
> > > ISTR that it won't save very much code though ... the Linux USB
> > > stack structures all its enumeration logic around hubs.
> >
> > Today, there is an USB (Host), USB_GADGET and USB_OTG (which depends on USB &&
> > USB_GADGET).
> >
> > This just enables cutting more code out, with out having to have USB_GADGET &
> > USB_OTG enabled. When I checked - that is where most of the savings came
> > from.
>
> Right.  I'm not objecting to this at all.  Just pointing
> out that usbcore will still end up including quite a lot
> of hub functionality, because there's still going to be
> a root hub in the system and a khubd managing it.
>
> This patch might be improved slightly -- in ways that, as I
> understand things, could save some RAM on Blackfin! -- by
> having the BLACKLIST_HUB option get rid of the transaction
> translator support (changing C code not just Kconfig).
> It's pretty minimal, but won't be used...
>
> Also, as you point out, it's no longer OTG specific, so
> renaming the option would improve clarity.   Maybe to
> something along the lines of USB_HOST_NO_EXTERNAL_HUBS.
> No big deal, at least now.
>

Thanks, that's the point.
Maybe Robin can choose a good name of this option.
I am just very happy that when plug-in an external hubs or something
like that will not make our system hangs, -:)))

B.T.W, 2 questions about the MUSB driver:
1. What's the plan for mainline merge of the whole MUSB driver? maybe
I can cleanup current Blackfin ports to you guys.
2. Do you remember the PING issue I reported in OMAP list? How do you
think of that?

Best Regards,
-Bryan Wu

Re: [linux-usb-devel] [PATCH] : Allow embedded developers USB options normally reserved for OTG

[David Brownell]

On Wednesday 02 January 2008, Bryan Wu wrote:
> B.T.W, 2 questions about the MUSB driver:
> 1. What's the plan for mainline merge of the whole MUSB driver? maybe
> I can cleanup current Blackfin ports to you guys.

It might as well merge in 2.6.25-early.  It'll be easier to integrate
patches that way.  Including your Blackfin port.  When I asked before,
nobody hugely objected to "one big patch".


> 2. Do you remember the PING issue I reported in OMAP list? How do you
> think of that?

Yes, something needs to be done.  EHCI might benefit from the same
kind of patch, to cope with ill-behaved usb thumb drives.


> > I have an idea: the USB_NAKLIMIT0 should be set to some value, when we
> > got NAK timeout interrupt, we can disable PING. When enumerating normal
> > USB stick, there is no NAK timeout, because PING is efficient for
> > handshaking. While problem USB stick will generate NAK timeout
> > interrupt, we disable PING for this kind of USB device enumeration.
 
That sounds much better than your original patch, which disabled it
always.  It might even be worth allocating a flag somewhere in the
usb_device structure to record when ep0 pings seem to misbehave.

- Dave

Re: [linux-usb-devel] [PATCH] : Allow embedded developers USB options normally reserved for OTG

[Bryan Wu]

On Jan 3, 2008 3:36 PM, David Brownell <david-b@pacbell.net> wrote:
> On Wednesday 02 January 2008, Bryan Wu wrote:
> > B.T.W, 2 questions about the MUSB driver:
> > 1. What's the plan for mainline merge of the whole MUSB driver? maybe
> > I can cleanup current Blackfin ports to you guys.
>
> It might as well merge in 2.6.25-early.  It'll be easier to integrate
> patches that way.  Including your Blackfin port.  When I asked before,
> nobody hugely objected to "one big patch".
>
>
> > 2. Do you remember the PING issue I reported in OMAP list? How do you
> > think of that?
>
> Yes, something needs to be done.  EHCI might benefit from the same
> kind of patch, to cope with ill-behaved usb thumb drives.
>
>
> > > I have an idea: the USB_NAKLIMIT0 should be set to some value, when we
> > > got NAK timeout interrupt, we can disable PING. When enumerating normal
> > > USB stick, there is no NAK timeout, because PING is efficient for
> > > handshaking. While problem USB stick will generate NAK timeout
> > > interrupt, we disable PING for this kind of USB device enumeration.
>
> That sounds much better than your original patch, which disabled it
> always.  It might even be worth allocating a flag somewhere in the
> usb_device structure to record when ep0 pings seem to misbehave.
>

OK, I will work on it and send out a patch for that fix.

Thanks
-Bryan Wu

RE: [linux-usb-devel] [PATCH] : Allow embedded developers USB options normally reserved for OTG

[Richard D]

Does all USB Host controller hardware have the ability to disable PING?

> > > 2. Do you remember the PING issue I reported in OMAP list? How do
> you
> > > think of that?
> >
> > Yes, something needs to be done.  EHCI might benefit from the same
> > kind of patch, to cope with ill-behaved usb thumb drives.
> >
> >
> > > > I have an idea: the USB_NAKLIMIT0 should be set to some value,
> when we
> > > > got NAK timeout interrupt, we can disable PING. When enumerating
> normal
> > > > USB stick, there is no NAK timeout, because PING is efficient for
> > > > handshaking. While problem USB stick will generate NAK timeout
> > > > interrupt, we disable PING for this kind of USB device
> enumeration.

Re: [linux-usb-devel] [PATCH] : Allow embedded developers USB options normally reserved for OTG

[Robin Getz]

On Thu 3 Jan 2008 12:04, Richard D pondered:
> Does all USB Host controller hardware have the ability to disable PING?

I think they do. (or at least should)...

http://www.intel.com/technology/usb/download/ehci-r10.pdf
==================
4.11 Ping Control (page 88)

USB 2.0 defines an addition to the protocol for high-speed devices called 
Ping. Ping is required for all USB 2.0 High-speed bulk and control endpoints. 
Ping is not allowed for a split-transaction stream. This extension to the 
protocol eliminates the bad side-effects of Naking OUT endpoints. The Status 
field has a Ping State bit, which the host controller uses to determine the 
next actual PID it will use in the next transaction to the endpoint (see 
Table 3-16).

Table 4–12 illustrates the state transition table for the host controller's 
responsibility for maintaining the PING protocol. 

Refer to Chapter 8 in the USB Specification Revision 2.0 for detailed 
description on the Ping protocol.

===============

I think the musb is just missing the PING/OUT State table, as described in 
table 4-12.

I think this is controlled in the ehci driver with:

host/ehci.h:#define     QTD_STS_PING    (1 << 0)        /* issue PING? */

-Robin

Re: [linux-usb-devel] [PATCH] : Allow embedded developers USB options normally reserved for OTG

[Robin Getz]

On Wed 2 Jan 2008 22:43, David Brownell pondered:
> This patch might be improved slightly -- in ways that, as I
> understand things, could save some RAM on Blackfin! -- by
> having the BLACKLIST_HUB option get rid of the transaction
> translator support (changing C code not just Kconfig).
> It's pretty minimal, but won't be used...
>
> Also, as you point out, it's no longer OTG specific, so
> renaming the option would improve clarity.   Maybe to
> something along the lines of USB_HOST_NO_EXTERNAL_HUBS.
> No big deal, at least now.

Are these two things something that you want me to have a stab at, or since 
you are more familiar with it - you want to do it.

Thanks
-Robin

Re: [linux-usb-devel] [PATCH] : Allow embedded developers USB options normally reserved for OTG

[Bryan Wu]

On Jan 3, 2008 2:47 AM, David Brownell <david-b@pacbell.net> wrote:
> On Wednesday 02 January 2008, Robin Getz wrote:
> > From: Robin Getz <rgetz@blackfin.uclinux.org>
> >
> > Allow embedded developers to turn support for USB Hubs off even if they have a
> > full root hub. This saves the overhead (RAM and Flash size).
>
> ISTR that it won't save very much code though ... the Linux USB
> stack structures all its enumeration logic around hubs.
>
>
> > Allow embedded developers the capabilities of the "otg_whitelist.h" - a
> > product whitelist, so USB peripherals not listed there will be rejected
> > during enumeration. This is the desired operation for many embedded products.
> >
> > Signed-off-by: Robin Getz <rgetz@blackfin.uclinux.org>
>
> This is probably the right thing to do.  Correct me if I'm wrong,
> but USB-IF recently put out some specs about "embedded hosts" which
> basically boil down to saying you can adopt the same functionality
> restrictions that used to be OTG-only.  Which is why now there are
> embedded developers who'd like this option.  :)
>
> - Dave
>
>

Yes, "embedded hosts" which currently not support whole USB 2.0 spec
is what Robin's patch serving for.

Although in MUSB of Blackfin can support USB_OTG and we can enable
this, some real embedded application just use the MUSB_HOST mode. So
just enable MUSB_HOST  can save some embedded space because it does
not including MUSB_PERIPHERAL code.

I believe some embedded SoC including embedded USB host controller
also need this option open for them.

Thanks
-Bryan Wu
>
>
> >
> > ---
> >
> >  drivers/usb/core/Kconfig |    7 ++++---
> >  1 file changed, 4 insertions(+), 3 deletions(-)
> >
> >
> > Index: linux-2.6.x/drivers/usb/core/Kconfig
> > ===================================================================
> > --- linux-2.6.x/drivers/usb/core/Kconfig      (revision 4074)
> > +++ linux-2.6.x/drivers/usb/core/Kconfig      (working copy)
> > @@ -95,8 +95,9 @@
> >
> >  config USB_OTG_WHITELIST
> >       bool "Rely on OTG Targeted Peripherals List"
> > -     depends on USB_OTG
> > -     default y
> > +     depends on USB_OTG || EMBEDDED
> > +     default y if USB_OTG
> > +     default n if EMBEDDED
> >       help
> >         If you say Y here, the "otg_whitelist.h" file will be used as a
> >         product whitelist, so USB peripherals not listed there will be
> > @@ -111,7 +112,7 @@
> >
> >  config USB_OTG_BLACKLIST_HUB
> >       bool "Disable external hubs"
> > -     depends on USB_OTG
> > +     depends on USB_OTG || EMBEDDED
> >       help
> >         If you say Y here, then Linux will refuse to enumerate
> >         external hubs.  OTG hosts are allowed to reduce hardware
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>