Discussion:
[PATCH] : Allow embedded developers USB options normally reserved for OTG
Robin Getz
2008-01-02 14:48:51 UTC
Permalink
From: Robin Getz <***@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 <***@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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
David Brownell
2008-01-02 18:47:15 UTC
Permalink
Post by Robin Getz
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.
Post by Robin Getz
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.
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
Post by Robin Getz
---
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
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Felipe Balbi
2008-01-02 18:57:50 UTC
Permalink
Post by David Brownell
Post by Robin Getz
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.
Post by Robin Getz
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.
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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
David Brownell
2008-01-02 19:14:10 UTC
Permalink
Post by Felipe Balbi
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


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Mike Frysinger
2008-01-02 18:58:56 UTC
Permalink
Post by David Brownell
Post by Robin Getz
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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
David Brownell
2008-01-02 19:16:28 UTC
Permalink
Post by Mike Frysinger
Post by David Brownell
Post by Robin Getz
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



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Alan Stern
2008-01-02 19:46:56 UTC
Permalink
Post by Mike Frysinger
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


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
David Brownell
2008-01-02 20:25:27 UTC
Permalink
Post by Alan Stern
Post by Mike Frysinger
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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Alan Stern
2008-01-02 20:58:38 UTC
Permalink
Post by David Brownell
Post by Alan Stern
Post by Mike Frysinger
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


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
David Brownell
2008-01-03 03:50:36 UTC
Permalink
Post by Alan Stern
Post by David Brownell
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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Bryan Wu
2008-01-03 03:52:27 UTC
Permalink
Post by Alan Stern
Post by David Brownell
Post by Alan Stern
Post by Mike Frysinger
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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Richard D
2008-01-03 17:01:54 UTC
Permalink
-----Original Message-----
Sent: Thursday, January 03, 2008 2:29 AM
To: David Brownell
Subject: Re: [linux-usb-devel] [PATCH] : Allow embedded developers USB
options normally reserved for OTG
Post by David Brownell
Post by Alan Stern
Post by Mike Frysinger
perhaps the code size is arguable as to whether it really
matters.
Post by David Brownell
Post by Alan Stern
Post by Mike Frysinger
the reason we want it is that we have a USB host controller that
will
Post by David Brownell
Post by Alan Stern
Post by Mike Frysinger
not work with USB hubs, so we want to make sure the system does
not
Post by David Brownell
Post by Alan Stern
Post by Mike Frysinger
attempt such things. (yes, such a USB host controller is
retarded,
Post by David Brownell
Post by Alan Stern
Post by Mike Frysinger
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.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Robin Getz
2008-01-03 03:03:04 UTC
Permalink
Post by David Brownell
Post by Robin Getz
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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
David Brownell
2008-01-03 03:43:38 UTC
Permalink
Post by Robin Getz
Post by David Brownell
Post by Robin Getz
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


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Bryan Wu
2008-01-03 04:40:14 UTC
Permalink
Post by David Brownell
Post by Robin Getz
Post by David Brownell
Post by Robin Getz
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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
David Brownell
2008-01-03 07:36:09 UTC
Permalink
Post by Bryan Wu
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".
Post by Bryan Wu
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.
Post by Bryan Wu
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



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Bryan Wu
2008-01-03 08:05:12 UTC
Permalink
Post by David Brownell
Post by Bryan Wu
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".
Post by Bryan Wu
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.
Post by Bryan Wu
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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Richard D
2008-01-03 17:04:06 UTC
Permalink
Does all USB Host controller hardware have the ability to disable PING?
Post by David Brownell
Post by Bryan Wu
2. Do you remember the PING issue I reported in OMAP list? How do
you
Post by David Brownell
Post by Bryan Wu
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.
Post by Bryan Wu
I have an idea: the USB_NAKLIMIT0 should be set to some value,
when we
Post by David Brownell
Post by Bryan Wu
got NAK timeout interrupt, we can disable PING. When enumerating
normal
Post by David Brownell
Post by Bryan Wu
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Robin Getz
2008-01-04 01:20:47 UTC
Permalink
Post by Richard D
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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sour

Robin Getz
2008-01-03 07:58:09 UTC
Permalink
Post by David Brownell
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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Bryan Wu
2008-01-03 03:47:19 UTC
Permalink
Post by David Brownell
Post by Robin Getz
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.
Post by Robin Getz
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.
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
Post by David Brownell
Post by Robin Getz
---
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
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Loading...