<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/drivers/usb/host, branch v2.6.20.19</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>EHCI: add delay to bus_resume before accessing ports</title>
<updated>2007-03-23T19:49:23+00:00</updated>
<author>
<name>Alan Stern</name>
<email>stern@rowland.harvard.edu</email>
</author>
<published>2007-03-16T13:34:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=38d4f86736e5dd71a748f87b20d66a8cf2357454'/>
<id>38d4f86736e5dd71a748f87b20d66a8cf2357454</id>
<content type='text'>
This patch (as870) adds a delay to ehci-hcd's bus_resume routine.
Apparently there are controllers and/or BIOSes out there which need
such a delay to get the ports back into their correct state.  This
fixes Bugzilla #8190.

Signed-off-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch (as870) adds a delay to ehci-hcd's bus_resume routine.
Apparently there are controllers and/or BIOSes out there which need
such a delay to get the ports back into their correct state.  This
fixes Bugzilla #8190.

Signed-off-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>UHCI: fix port resume problem</title>
<updated>2007-03-09T18:50:21+00:00</updated>
<author>
<name>Alan Stern</name>
<email>stern@rowland.harvard.edu</email>
</author>
<published>2007-02-26T22:16:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=07c9ab037422089d2b8baf5c14734fe2105b6629'/>
<id>07c9ab037422089d2b8baf5c14734fe2105b6629</id>
<content type='text'>
This patch (as863) fixes a problem encountered sometimes when resuming
a port on a UHCI controller.  The hardware may turn off the
Resume-Detect bit before turning off the Suspend bit, leading usbcore
to think that the port is still suspended and the resume has failed.
The patch makes uhci_finish_suspend() wait until both bits are safely
off.

Signed-off-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch (as863) fixes a problem encountered sometimes when resuming
a port on a UHCI controller.  The hardware may turn off the
Resume-Detect bit before turning off the Suspend bit, leading usbcore
to think that the port is still suspended and the resume has failed.
The patch makes uhci_finish_suspend() wait until both bits are safely
off.

Signed-off-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>EHCI: turn off remote wakeup during shutdown</title>
<updated>2007-03-09T18:50:21+00:00</updated>
<author>
<name>Alan Stern</name>
<email>stern@rowland.harvard.edu</email>
</author>
<published>2007-02-13T19:53:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=5edd24258c5eae0a5cadc612ea1d6e13ec54e536'/>
<id>5edd24258c5eae0a5cadc612ea1d6e13ec54e536</id>
<content type='text'>
This patch (as850b) disables remote wakeup (and everything else!) on
all EHCI ports when the shutdown() method is called.  If remote wakeup
is left active then some systems will reboot instead of powering off.
This fixes Bugzilla #7828.

Signed-off-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch (as850b) disables remote wakeup (and everything else!) on
all EHCI ports when the shutdown() method is called.  If remote wakeup
is left active then some systems will reboot instead of powering off.
This fixes Bugzilla #7828.

Signed-off-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>USB: Fix for typo in ohci-ep93xx.c</title>
<updated>2007-01-22T19:55:17+00:00</updated>
<author>
<name>Petr Stetiar</name>
<email>ynezz@true.cz</email>
</author>
<published>2007-01-17T14:30:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=caaf26325d70f5b559a647d4c11d84ef5a3341a4'/>
<id>caaf26325d70f5b559a647d4c11d84ef5a3341a4</id>
<content type='text'>
Attached patch fixes typo in USB driver reported by Chase Douglas on linux-cirrus mailing
list. http://www.freelists.org/archives/linux-cirrus/12-2006/msg00003.html

Signed-off-by: Petr Stetiar &lt;ynezz@true.cz&gt;
Signed-off-by: David Brownell &lt;dbrownell@users.sourceforge.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Attached patch fixes typo in USB driver reported by Chase Douglas on linux-cirrus mailing
list. http://www.freelists.org/archives/linux-cirrus/12-2006/msg00003.html

Signed-off-by: Petr Stetiar &lt;ynezz@true.cz&gt;
Signed-off-by: David Brownell &lt;dbrownell@users.sourceforge.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>UHCI: support device_may_wakeup</title>
<updated>2007-01-05T20:19:08+00:00</updated>
<author>
<name>Alan Stern</name>
<email>stern@rowland.harvard.edu</email>
</author>
<published>2006-12-15T21:08:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=25c77b329467d563ec1fa5c3efab0b13996ce810'/>
<id>25c77b329467d563ec1fa5c3efab0b13996ce810</id>
<content type='text'>
This patch (as831) adds device_may_wakeup() support to uhci-hcd; it
has been lacking for a long time.

Signed-off-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch (as831) adds device_may_wakeup() support to uhci-hcd; it
has been lacking for a long time.

Signed-off-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>UHCI: make test for ASUS motherboard more specific</title>
<updated>2007-01-05T20:19:08+00:00</updated>
<author>
<name>Alan Stern</name>
<email>stern@rowland.harvard.edu</email>
</author>
<published>2006-12-15T21:06:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=c80a70d53fa0ca47ad122cd75fe32b6f41c04eb1'/>
<id>c80a70d53fa0ca47ad122cd75fe32b6f41c04eb1</id>
<content type='text'>
Instead of matching all motherboards whose name contains "A7V8X" for a
remote-wakeup hardware bug, this patch (as829) matches only those
boards whose name is exactly equal to "A7V8X".  Later motherboards
don't seem to have the bug.

(In fact, it's possible that only one motherboard in the world has the
bug.  With only one user reporting problems, it's hard to tell.)

Signed-off-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Instead of matching all motherboards whose name contains "A7V8X" for a
remote-wakeup hardware bug, this patch (as829) matches only those
boards whose name is exactly equal to "A7V8X".  Later motherboards
don't seem to have the bug.

(In fact, it's possible that only one motherboard in the world has the
bug.  With only one user reporting problems, it's hard to tell.)

Signed-off-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>USB: u132-hcd/ftdi-elan: add support for Option GT 3G Quad card</title>
<updated>2006-12-20T18:14:27+00:00</updated>
<author>
<name>Tony Olech</name>
<email>tony.olech@elandigitalsystems.com</email>
</author>
<published>2006-12-06T13:16:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=4b87361d49c04894458f4d4e80f9669abc894ae1'/>
<id>4b87361d49c04894458f4d4e80f9669abc894ae1</id>
<content type='text'>
ELAN's U132 is a USB to CardBus OHCI controller adapter,
    designed specifically for CardBus 3G data cards to
    function in machines without a CardBus slot.
The "ftdi-elan" module is a USB client driver, that detects
    a supported CardBus OHCI controller plugged into the
    U132 adapter and thereafter provides the conduit for
    for access by the "u132-hcd" module.
The "u132-hcd" module is a (cut-down OHCI) host controller
    that supports a single OHCI function of the CardBus 
    card inserted into the U132 adapter.

The problem with the initial implementation is that when
the CardBus card inserted into the U132 adapter has multiple
functions (and a CardBus card can support up to 4 functions),
it was the first function that was arbitrarily choosen.

The first batch of 3G cards tested, like the Merlin Qualcomm
V620, have two functions each supporting a seperate USB OHCI
host controller, of which it was that first function that is
wired up to the 3G modem.

Then along comes the Vodafone Mobile Connect 3G/GPRS data card,
aka "Option GT 3G Quad" as printed on it's rear or "Option N.V.
GlobeTrotter Fusion Quad Lite" as read with "lspci -v". And it
has the meaningful functionality in the second CardBus function.

That presents a problem because it was the "ftdi-elan" module
alone that knows how to communicate to the embedded CardBus slot
and the "u132-hcd" module alone that knows how to access the
pcmcia configuration and CardBus accessible memory space. And
of course, the information about attached (internally hardwired)
devices is contained within USB configuration embedded somewhere
within the CardBus card.

If only the "u132-hcd" module probe() interface could return a
result code that propagated back to the instigating function
platform_device_register() then the "ftdi-elan" module could
try an alternative CardBus function.     However in spite of
the recent changes to the drivers/base/ routines that moved 
device_attach() from bus_add_device() to bus_attach_device()
both of those routines lose the "failed to attach" 0 result
code and thus the calling routine, namely device_add() is
incapable of propaging the "failed to attach" condition back
to platform_device_add() and consequently back to the caller
of platform_device_register()

Experiments show that patching bus_attach_device() to return
ENODEV fails with the kernel locking up very early during
boot. But, however, if the patch is restricted to calls from
platform_device_add() then it does seem to work.

Unfortunately, until the kernel's drivers/base is properly
modified to propagate -ENODEV back to the caller of
platform_device_register(), it is necessary to "fix" the
"ftdi-elan" module by importing knowledge from the 
"u132-hcd" module. This is the reason for the duplicated
functionality introduced in this patch.

Signed-off-by: Tony Olech &lt;tony.olech@elandigitalsystems.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
ELAN's U132 is a USB to CardBus OHCI controller adapter,
    designed specifically for CardBus 3G data cards to
    function in machines without a CardBus slot.
The "ftdi-elan" module is a USB client driver, that detects
    a supported CardBus OHCI controller plugged into the
    U132 adapter and thereafter provides the conduit for
    for access by the "u132-hcd" module.
The "u132-hcd" module is a (cut-down OHCI) host controller
    that supports a single OHCI function of the CardBus 
    card inserted into the U132 adapter.

The problem with the initial implementation is that when
the CardBus card inserted into the U132 adapter has multiple
functions (and a CardBus card can support up to 4 functions),
it was the first function that was arbitrarily choosen.

The first batch of 3G cards tested, like the Merlin Qualcomm
V620, have two functions each supporting a seperate USB OHCI
host controller, of which it was that first function that is
wired up to the 3G modem.

Then along comes the Vodafone Mobile Connect 3G/GPRS data card,
aka "Option GT 3G Quad" as printed on it's rear or "Option N.V.
GlobeTrotter Fusion Quad Lite" as read with "lspci -v". And it
has the meaningful functionality in the second CardBus function.

That presents a problem because it was the "ftdi-elan" module
alone that knows how to communicate to the embedded CardBus slot
and the "u132-hcd" module alone that knows how to access the
pcmcia configuration and CardBus accessible memory space. And
of course, the information about attached (internally hardwired)
devices is contained within USB configuration embedded somewhere
within the CardBus card.

If only the "u132-hcd" module probe() interface could return a
result code that propagated back to the instigating function
platform_device_register() then the "ftdi-elan" module could
try an alternative CardBus function.     However in spite of
the recent changes to the drivers/base/ routines that moved 
device_attach() from bus_add_device() to bus_attach_device()
both of those routines lose the "failed to attach" 0 result
code and thus the calling routine, namely device_add() is
incapable of propaging the "failed to attach" condition back
to platform_device_add() and consequently back to the caller
of platform_device_register()

Experiments show that patching bus_attach_device() to return
ENODEV fails with the kernel locking up very early during
boot. But, however, if the patch is restricted to calls from
platform_device_add() then it does seem to work.

Unfortunately, until the kernel's drivers/base is properly
modified to propagate -ENODEV back to the caller of
platform_device_register(), it is necessary to "fix" the
"ftdi-elan" module by importing knowledge from the 
"u132-hcd" module. This is the reason for the duplicated
functionality introduced in this patch.

Signed-off-by: Tony Olech &lt;tony.olech@elandigitalsystems.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>USB: OHCI support for PNX8550</title>
<updated>2006-12-20T18:14:27+00:00</updated>
<author>
<name>Vitaly Wool</name>
<email>vitalywool@gmail.com</email>
</author>
<published>2006-10-09T08:32:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=5151d04068e37e710d2cc3962351ca0979fc5ad1'/>
<id>5151d04068e37e710d2cc3962351ca0979fc5ad1</id>
<content type='text'>
OHCI HCD (Host Controller Driver) for USB. Bus Glue for PNX8550.

Signed-off-by: Vitaly Wool &lt;vitalywool@gmail.com&gt;
Signed-off-by: David Brownell &lt;dbrownell@users.sourceforge.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
OHCI HCD (Host Controller Driver) for USB. Bus Glue for PNX8550.

Signed-off-by: Vitaly Wool &lt;vitalywool@gmail.com&gt;
Signed-off-by: David Brownell &lt;dbrownell@users.sourceforge.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>USB: ohci handles hardware faults during root port resets</title>
<updated>2006-12-20T18:14:27+00:00</updated>
<author>
<name>Takamasa Ohtake</name>
<email>ohtake-txa@necst.nec.co.jp</email>
</author>
<published>2006-12-07T01:04:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=23d10a9e376d6a9cd4afd4e27e5e403864f6729b'/>
<id>23d10a9e376d6a9cd4afd4e27e5e403864f6729b</id>
<content type='text'>
I have found a problem where the root_port_reset() goes into an infinite
loop and stalls the kernel.

This happens when a hardware fault inside the machine occurs during a small
timing window.  In case of USB device connection, if a USB device responds to
hcd_submit_urb(), and later the controller fails before root_port_reset(),
root_port_reset() will loop infinitely because ohci_readl() will always
return "-1".  Such a failure can include ejecting a CardBus OHCI controller.

The probability of this problem is low, but it will increase if PnP type
usage is frequent.  The attached patch can solve this problem and I believe
that it is better to fix this problem.

Signed-off-by: Takamasa Ohtake &lt;ohtake-txa@necst.nec.co.jp&gt;
Signed-off-by: David Brownell &lt;dbrownell@users.sourceforge.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
I have found a problem where the root_port_reset() goes into an infinite
loop and stalls the kernel.

This happens when a hardware fault inside the machine occurs during a small
timing window.  In case of USB device connection, if a USB device responds to
hcd_submit_urb(), and later the controller fails before root_port_reset(),
root_port_reset() will loop infinitely because ohci_readl() will always
return "-1".  Such a failure can include ejecting a CardBus OHCI controller.

The probability of this problem is low, but it will increase if PnP type
usage is frequent.  The attached patch can solve this problem and I believe
that it is better to fix this problem.

Signed-off-by: Takamasa Ohtake &lt;ohtake-txa@necst.nec.co.jp&gt;
Signed-off-by: David Brownell &lt;dbrownell@users.sourceforge.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>USB: ohci at91 warning fix</title>
<updated>2006-12-20T18:14:27+00:00</updated>
<author>
<name>Andrew Victor</name>
<email>andrew@sanpeople.com</email>
</author>
<published>2006-12-05T11:20:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=ee269d98a9248fbb729c20ffda0f1b97e82c5c37'/>
<id>ee269d98a9248fbb729c20ffda0f1b97e82c5c37</id>
<content type='text'>
Remove a warning about an unused variable in the OHCI bus glue for at91.

Signed-off-by: Andrew Victor &lt;andrew@sanpeople.com&gt;
Signed-off-by: David Brownell &lt;dbrownell@users.sourceforge.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Remove a warning about an unused variable in the OHCI bus glue for at91.

Signed-off-by: Andrew Victor &lt;andrew@sanpeople.com&gt;
Signed-off-by: David Brownell &lt;dbrownell@users.sourceforge.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
</feed>
