This patch adds support for the FHCI USB controller, as found
in the Freescale MPC836x and MPC832x processors. It can support
Full or Low speed modes.
Quite a lot the hardware is doing by itself (SOF generation, CRC
generation and checking), though scheduling and retransmission is on
software's shoulders.
This controller does not integrate the root hub, so this driver also
fakes one-port hub. External hub is required to support more than
one device.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This driver implements the support for Oxford OXU210HP USB high-speed host,
no peripheral nor OTG.
Signed-off-by: Rodolfo Giometti <giometti@linux.it>
Cc: Kan Liu <kan.k.liu@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
A driver for Wireless USB host controllers that comply with the
Wireless Host Controller Interface (HCI) specification as published by
Intel.
The latest publically available version of the specification (0.95) is
supported (except for isochronous transfers).
Build fixes by Randy Dunlap <rdunlap@xenotime.net>
Signed-off-by: David Vrabel <david.vrabel@csr.com>
This driver has been written from scratch and supports the ISP1760. ISP1761
might (should) work as well but the OTG isn't supported. Also ISO packets are
not. However, it works on my little PowerPC board.
Signed-off-by: Sebastian Siewior <bigeasy@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
I would like to submit Renesas R8A66597 USB HCD driver.
R8A66597 is Renesas USB 2.0 host and peripheral combined
controller device originally designed for embedded products.
As a limitation of this device, it does not support externel
hub more than 2 tier, and cannot communicate with a USB
device more than 10. Then this device is not compatible with
EHCI and/or OHCI, I wrote driver support patch based on
sl811 code.
This driver has the following unique specifications:
- Implement transfer timeout to share one pipe with plural endpoint.
- Detach detection of a USB device connected to externel hub.
The driver has been tested external hub, usb-hdd, usb-cdrom,
usb-speaker, mice, keyboard, and usbtest driver.
Signed-off-by : Yoshihiro Shimoda <shimoda.yoshihiro@renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Remove the old crisv10 HCD ... it can't have built for some time,
doesn't even have a Kconfig entry, was the last driver not to have
been converted to the "hcd" framework, and considering the usbcore
changes since its last patch was merged, has just got to buggy as
all get-out.
I'm told Axis has a new driver, and will be submitting it soon.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Mikael Starvik <mikael.starvik@axis.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This "u132-hcd" module is one half of the "driver" for
ELAN's U132 which is a USB to CardBus OHCI controller
adapter. This module needs the "ftdi-elan" module in
order to communicate to CardBus OHCI controller inserted
into the U132 adapter.
When the "ftdi-elan" module detects a supported CardBus
OHCI controller in the U132 adapter it loads this "u132-hcd"
module.
Upon a successful device probe() the single workqueue
is started up which does all the processing of commands
from the USB core that implement the host controller.
The workqueue maintains the urb queues and issues commands
via the functions exported by the "ftdi-elan" module. Each
such command will result in a callback.
Note that the "ftdi-elan" module is a USB client driver.
Note that this "u132-hcd" module is a (cut-down OHCI)
host controller.
Thus we have a topology with the parent of a host controller
being a USB client! This really stresses the USB subsystem
semaphore/mutex handling in the module removal.
Signed-off-by: Tony Olech <tony.olech@elandigitalsystems.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This modifies the HCD builds to automatically "-DDEBUG" if
CONFIG_USB_DEBUG is selected. It's just a minor source code cleanup,
guaranteeing consistency.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This moves the PCI quirk handling for USB host controllers from the
PCI directory to the USB directory. Follow-on patches will need to:
(a) merge these copies with the originals in the HCD reset methods.
they don't wholly agree, despite doing the very same thing; and
(b) eventually change it so "usb-handoff" is the default, to help
get more robust USB/BIOS/input/... interactions.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
drivers/Makefile | 2
drivers/pci/quirks.c | 253 ---------------------------------------
drivers/usb/Makefile | 1
drivers/usb/host/Makefile | 5
drivers/usb/host/pci-quirks.c | 272 ++++++++++++++++++++++++++++++++++++++++++
5 files changed, 280 insertions(+), 253 deletions(-)
This patch provides an "isp116x-hcd" driver for Philips'
ISP1160/ISP1161 USB host controllers.
The driver:
- is relatively small, meant for use on embedded platforms.
- runs usbtests 1-14 without problems for days.
- has been in use by 6-7 different people on ARM and PPC platforms,
running a range of devices including USB hubs.
- supports suspend/resume of both the platform device and the root hub;
supports remote wakeup of the root hub (but NOT the platform device)
by USB devices.
- does NOT support ISO transfers (nobody has asked for them).
- is PIO-only.
Signed-off-by: Olav Kongas <ok@artecdesign.ee>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This adds support for a CF-card USB Host adapter, the Ratoc REX-CFU1U, by
wrapping a PCMCIA driver around the existing "sl811-hcd" platform driver.
This CF card is especially useful for PDAs, which currently tend to have
no other solution for USB host capability.
From: Botond Botyanszki <boti@rocketmail.com>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!