The USB core allocates a USB 2.0 roothub descriptor that has room for 31
(USB_MAXCHILDREN) ports' worth of DeviceRemovable and PortPwrCtrlMask
fields. Limit the number of USB 2.0 roothub ports accordingly. I don't
expect to run into this limitation ever, but this prevents a buffer
overflow issue in the roothub descriptor filling code.
Similarly, a USB 3.0 hub can only have 15 downstream ports, so limit the
USB 3.0 roothub to 15 USB 3.0 ports.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Return the correct xHCI roothub descriptor, based on whether the roothub
is marked as USB 3.0 or USB 2.0 in usb_hcd->bcdUSB. Fill in
DeviceRemovable for the USB 2.0 and USB 3.0 roothub descriptors, using the
Device Removable bit in the port status and control registers. xHCI is
the first host controller to actually properly set these bits (other hosts
say all devices are removable).
When userspace asks for a USB 2.0-style hub descriptor for the USB 3.0
roothub, stall the endpoint. This is what real external USB 3.0 hubs do,
and we don't want to return a descriptor that userspace didn't ask for.
The USB core is already fixed to always ask for USB 3.0-style hub
descriptors. Only usbfs (typically lsusb) will ask for the USB 2.0-style
hub descriptors. This has already been fixed in usbutils version 0.91,
but the kernel needs to deal with older usbutils versions.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
This patch changes the xHCI driver to allocate two roothubs. This touches
the driver initialization and shutdown paths, roothub emulation code, and
port status change event handlers. This is a rather large patch, but it
can't be broken up, or it would break git-bisect.
Make the xHCI driver register its own PCI probe function. This will call
the USB core to create the USB 2.0 roothub, and then create the USB 3.0
roothub. This gets the code for registering a shared roothub out of the
USB core, and allows other HCDs later to decide if and how many shared
roothubs they want to allocate.
Make sure the xHCI's reset method marks the xHCI host controller's primary
roothub as the USB 2.0 roothub. This ensures that the high speed bus will
be processed first when the PCI device is resumed, and any USB 3.0 devices
that have migrated over to high speed will migrate back after being reset.
This ensures that USB persist works with these odd devices.
The reset method will also mark the xHCI USB2 roothub as having an
integrated TT. Like EHCI host controllers with a "rate matching hub" the
xHCI USB 2.0 roothub doesn't have an OHCI or UHCI companion controller.
It doesn't really have a TT, but we'll lie and say it has an integrated
TT. We need to do this because the USB core will reject LS/FS devices
under a HS hub without a TT.
Other details:
-------------
The roothub emulation code is changed to return the correct number of
ports for the two roothubs. For the USB 3.0 roothub, it only reports the
USB 3.0 ports. For the USB 2.0 roothub, it reports all the LS/FS/HS
ports. The code to disable a port now checks the speed of the roothub,
and refuses to disable SuperSpeed ports under the USB 3.0 roothub.
The code for initializing a new device context must be changed to set the
proper roothub port number. Since we've split the xHCI host into two
roothubs, we can't just use the port number in the ancestor hub. Instead,
we loop through the array of hardware port status register speeds and find
the Nth port with a similar speed.
The port status change event handler is updated to figure out whether the
port that reported the change is a USB 3.0 port, or a non-SuperSpeed port.
Once it figures out the port speed, it kicks the proper roothub.
The function to find a slot ID based on the port index is updated to take
into account that the two roothubs will have over-lapping port indexes.
It checks that the virtual device with a matching port index is the same
speed as the passed in roothub.
There's also changes to the driver initialization and shutdown paths:
1. Make sure that the xhci_hcd pointer is shared across the two
usb_hcd structures. The xhci_hcd pointer is allocated and the
registers are mapped in when xhci_pci_setup() is called with the
primary HCD. When xhci_pci_setup() is called with the non-primary
HCD, the xhci_hcd pointer is stored.
2. Make sure to set the sg_tablesize for both usb_hcd structures. Set
the PCI DMA mask for the non-primary HCD to allow for 64-bit or 32-bit
DMA. (The PCI DMA mask is set from the primary HCD further down in
the xhci_pci_setup() function.)
3. Ensure that the host controller doesn't start kicking khubd in
response to port status changes before both usb_hcd structures are
registered. xhci_run() only starts the xHC running once it has been
called with the non-primary roothub. Similarly, the xhci_stop()
function only halts the host controller when it is called with the
non-primary HCD. Then on the second call, it resets and cleans up the
MSI-X irqs.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
xhci_find_slot_id_by_port() tries to map the port index to the slot ID for
the USB device. In the future, there will be two xHCI roothubs, and their
port indices will overlap. Therefore, xhci_find_slot_id_by_port() will
need to use information in the roothub's usb_hcd structure to map the port
index and roothub speed to the right slot ID.
Add a new parameter to xhci_find_slot_id_by_port(), in order to pass in
the roothub's usb_hcd structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
There are several variables in the xhci_hcd structure that are related to
bus suspend and resume state. There are a couple different port status
arrays that are accessed by port index. Move those variables into a
separate structure, xhci_bus_state. Stash that structure in xhci_hcd.
When we have two roothhubs that can be suspended and resumed separately,
we can have two xhci_bus_states, and index into the port arrays in each
structure with the fake roothub port index (not the real hardware port
index).
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
In the upcoming patches, the roothub emulation code will need to return
port status and port change buffers based on whether they are called with
the xHCI USB 2.0 or USB 3.0 roothub. To facilitate that, make the roothub
code index into an array of port addresses with wIndex, rather than
calculating the address using the offset and the address of the PORTSC
registers. Later we can set the port array to be the array of USB 3.0
port addresses, or the USB 2.0 port addresses, depending on the roothub
passed in.
Create a temporary (statically sized) port array and fill it in with both
USB 3.0 and USB 2.0 port addresses. This is inefficient to do for every
roothub call, but this is needed for git bisect compatibility. The
temporary port array will be deleted in a subsequent patch.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
The hcd->flags are in a sorry state. Some of them are clearly specific to
the particular roothub (HCD_POLL_RH, HCD_POLL_PENDING, and
HCD_WAKEUP_PENDING), but some flags are related to PCI device state
(HCD_HW_ACCESSIBLE and HCD_SAW_IRQ). This is an issue when one PCI device
can have two roothubs that share the same IRQ line and hardware.
Make sure to set HCD_FLAG_SAW_IRQ for both roothubs when an interrupt is
serviced, or an URB is unlinked without an interrupt. (We can't tell if
the host actually serviced an interrupt for a particular bus, but we can
tell it serviced some interrupt.)
HCD_HW_ACCESSIBLE is set once by usb_add_hcd(), which is set for both
roothubs as they are added, so it doesn't need to be modified.
HCD_POLL_RH and HCD_POLL_PENDING are only checked by the USB core, and
they are never set by the xHCI driver, since the roothub never needs to be
polled.
The usb_hcd's state field is a similar mess. Sometimes the state applies
to the underlying hardware: HC_STATE_HALT, HC_STATE_RUNNING, and
HC_STATE_QUIESCING. But sometimes the state refers to the roothub state:
HC_STATE_RESUMING and HC_STATE_SUSPENDED.
Alan Stern recently made the USB core not rely on the hcd->state variable.
Internally, the xHCI driver still checks for HC_STATE_SUSPENDED, so leave
that code in. Remove all references to HC_STATE_HALT, since the xHCI
driver only sets and doesn't test those variables. We still have to set
HC_STATE_RUNNING, since Alan's patch has a bug that means the roothub
won't get registered if we don't set that.
Alan's patch made the USB core check a different variable when trying to
determine whether to suspend a roothub. The xHCI host has a split
roothub, where two buses are registered for one PCI device. Each bus in
the xHCI split roothub can be suspended separately, but both buses must be
suspended before the PCI device can be suspended. Therefore, make sure
that the USB core checks HCD_RH_RUNNING() for both roothubs before
suspending the PCI host.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Introduce the notion of a PCI device that may be associated with more than
one USB host controller driver (struct usb_hcd). This patch is the start
of the work to separate the xHCI host controller into two roothubs: a USB
3.0 roothub with SuperSpeed-only ports, and a USB 2.0 roothub with
HS/FS/LS ports.
One usb_hcd structure is designated to be the "primary HCD", and a pointer
is added to the usb_hcd structure to keep track of that. A new function
call, usb_hcd_is_primary_hcd() is added to check whether the USB hcd is
marked as the primary HCD (or if it is not part of a roothub pair). To
allow the USB core and xHCI driver to access either roothub in a pair, a
"shared_hcd" pointer is added to the usb_hcd structure.
Add a new function, usb_create_shared_hcd(), that does roothub allocation
for paired roothubs. It will act just like usb_create_hcd() did if the
primary_hcd pointer argument is NULL. If it is passed a non-NULL
primary_hcd pointer, it sets usb_hcd->shared_hcd and usb_hcd->primary_hcd
fields. It will also skip the bandwidth_mutex allocation, and set the
secondary hcd's bandwidth_mutex pointer to the primary HCD's mutex.
IRQs are only allocated once for the primary roothub.
Introduce a new usb_hcd driver flag that indicates the host controller
driver wants to create two roothubs. If the HCD_SHARED flag is set, then
the USB core PCI probe methods will allocate a second roothub, and make
sure that second roothub gets freed during rmmod and in initialization
error paths.
When usb_hc_died() is called with the primary HCD, make sure that any
roothubs that share that host controller are also marked as being dead.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
The xHCI driver essentially has both a USB 2.0 and a USB 3.0 roothub. So
setting the HCD_USB3 bits in the hcd->driver->flags is a bit misleading.
Add a new field to usb_hcd, bcdUSB. Store the result of
hcd->driver->flags & HCD_MASK in it. Later, when we have the xHCI driver
register the two roothubs, we'll set the usb_hcd->bcdUSB field to HCD_USB2
for the USB 2.0 roothub, and HCD_USB3 for the USB 3.0 roothub.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Change the bandwith_mutex in struct usb_hcd to a pointer. This will allow
the pointer to be shared across usb_hcds for the upcoming work to split
the xHCI driver roothub into a USB 2.0/1.1 and a USB 3.0 bus.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Refactor out the code in usb_add_hcd() to request the IRQ line for the
HCD. This will only need to be called once for the two xHCI roothubs, so
it's easier to refactor it into a function, rather than wrapping the long
if-else block into another if statement.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Make the labels for the goto statements in usb_hcd_pci_probe()
describe the cleanup they do, rather than being numbered err[1-4].
This makes it easier to add error handling later.
The error handling for this function looks a little fishy, since
set_hs_companion() isn't called until the very end of the function, and
clear_hs_companion() is called if this function fails earlier than that.
But it should be harmless to clear a NULL pointer, so leave the error
handling as-is.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Instead of allocating space for the whole xhci_hcd structure at the end of
usb_hcd, make the USB core allocate enough space for a pointer to the
xhci_hcd structure. This will make it easy to share the xhci_hcd
structure across the two roothubs (the USB 3.0 usb_hcd and the USB 2.0
usb_hcd).
Deallocate the xhci_hcd at PCI remove time, so the hcd_priv will be
deallocated after the usb_hcd is deallocated. We do this by registering a
different PCI remove function that calls the usb_hcd_pci_remove()
function, and then frees the xhci_hcd. usb_hcd_pci_remove() calls
kput() on the usb_hcd structure, which will deallocate the memory that
contains the hcd_priv pointer, but not the memory it points to.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Make sure to call into the USB core's link, unlink, and giveback URB
functions with the usb_hcd pointer found by using urb->dev->bus. This
will avoid confusion later, when the xHCI driver will deal with URBs from
two separate buses (the USB 3.0 roothub and the faked USB 2.0 roothub).
Assume xhci_urb_dequeue() will be called with the proper usb_hcd.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Commit d199c96d by Alan Stern ensured that low speed and full speed
devices below a high speed hub without a transaction translator (TT) would
never get enumerated. Simplify the check for a TT in the xHCI virtual
device allocation to only check if the usb_device references a parent's
TT.
Make sure not to set the TT information on LS/FS devices directly
connected to the roothub. The xHCI host doesn't really have a TT, and the
host will throw an error when those virtual device TT fields are set for a
device connected to the roothub. We need this check because the xHCI
driver will shortly register two roothubs: a USB 2.0 roothub and a USB 3.0
roothub.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Make the USB 3.0 roothub registered by the USB core have a SuperSpeed
Endpoint Companion Descriptor after the interrupt endpoint. All USB 3.0
devices are required to have this, and the USB 3.0 bus specification
(section 10.13.1) says which values the descriptor should have.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
In USB 3.0, there are two types of resets: a "hot" port reset and a "warm"
port reset. The hot port reset is always tried first, and involves
sending the reset signaling for a shorter amount of time. But sometimes
devices don't respond to the hot reset, and a "Bigger Hammer" is needed.
External hubs and roothubs will automatically try a warm reset when the
hot reset fails, and they will set a status change bit to indicate when
there is a "BH reset" change. Make sure the USB core clears that port
status change bit, or we'll get lots of status change notifications on the
interrupt endpoint of the USB 3.0 hub.
(Side note: you may be confused why the USB 3.0 spec calls the same type
of reset "warm reset" in some places and "BH reset" in other places. "BH"
reset is supposed to stand for "Big Hammer" reset, but it also stands for
"Brad Hosler". Brad died shortly after the USB 3.0 bus specification was
started, and they decided to name the reset after him. The suggestion was
made shortly before the spec was finalized, so the wording is a bit
inconsistent.)
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Update the USB core to deal with USB 3.0 hubs. These hubs have a slightly
different hub descriptor than USB 2.0 hubs, with a fixed (rather than
variable length) size. Change the USB core's hub descriptor to have a
union for the last fields that differ. Change the host controller drivers
that access those last fields (DeviceRemovable and PortPowerCtrlMask) to
use the union.
Translate the new version of the hub port status field into the old
version that khubd understands. (Note: we need to fix it to translate the
roothub's port status once we stop converting it to USB 2.0 hub status
internally.)
Add new code to handle link state change status. Send out new control
messages that are needed for USB 3.0 hubs, like Set Hub Depth.
This patch is a modified version of the original patch submitted by John
Youn. It's updated to reflect the removal of the "bitmap" #define, and
change the hub descriptor accesses of a couple new host controller
drivers.
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Cc: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
Cc: Tony Olech <tony.olech@elandigitalsystems.com>
Cc: "Robert P. J. Day" <rpjday@crashcourse.ca>
Cc: Max Vozeler <mvz@vozeler.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Cc: Rodolfo Giometti <giometti@linux.it>
Cc: Mike Frysinger <vapier@gentoo.org>
Cc: Anton Vorontsov <avorontsov@mvista.com>
Cc: Sebastian Siewior <bigeasy@linutronix.de>
Cc: Lothar Wassmann <LW@KARO-electronics.de>
Cc: Olav Kongas <ok@artecdesign.ee>
Cc: Martin Fuzzey <mfuzzey@gmail.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: David Brownell <dbrownell@users.sourceforge.net>
The USB core will set hcd->state to HC_STATE_RUNNING before calling
xhci_run, so there's no point in setting it twice. The USB core also
doesn't pay attention to HC_STATE_RUNNING on the resume path anymore; it
uses HCD_RH_RUNNING(), which looks at hcd->flags & (1U <<
HCD_FLAG_RH_RUNNING. Therefore, it's safe to remove the state set in
xhci_bus_resume().
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
We would like to allow host controller drivers to stop using hcd->state.
Unfortunately, some host controller drivers use hcd->state as an
implicit way of telling the core that a controller has died. The
roothub registration functions must assume the host died if hcd->state
equals HC_STATE_HALT.
To facilitate drivers that don't want to set hcd->state to
HC_STATE_RUNNING in their initialization routines, we set the state to
running before calling the host controller's start function.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
The xHCI driver doesn't ever test hcd->state for HC_STATE_HALT. The USB
core recently stopped using it internally, so there's no point in setting
it in the driver. We still need to set HC_STATE_RUNNING in order to make
it past the USB core's hcd->state check in register_roothub().
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
xHCI 1.0 spec specifies the xHC shall halt within 16ms after software clears
Run/Stop bit. In xHCI 0.96 spec the time limit is 16 microframes (2ms), it's
too short and often cause dmesg shows "Host controller not halted, aborting
reset." message when rmmod xhci-hcd.
Modify the time limit to comply with xHCI 1.0 specification and prevents the
warning message showing when remove xhci-hcd.
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Set hcd->state = HC_STATE_SUSPENDED if there is a power loss during system
resume or the system is hibernated, otherwise leave it be. The variable
old_state is redundant and made an unreachable code path, so remove it.
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
The xhci_bus_suspend() and xhci_bus_resume() functions are a bit hard to
read, because they have an ambiguously named variable "port". Rename it
to "port_index". Introduce a new temporary variable, "max_ports" that
holds the maximum number of roothub ports the host controller supports.
This will reduce the number of register reads, and make it easy to change
the maximum number of ports when there are two roothubs.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
The USB core only allows up to 31 (USB_MAXCHILDREN) ports under a roothub.
The xHCI driver keeps track of which ports are suspended, which ports have
a suspend change bit set, and what time the port will be done resuming.
It keeps track of the first two by setting a bit in a u32 variable,
suspended_ports or port_c_suspend. The xHCI driver currently assumes we
can have up to 256 ports under a roothub, so it allocates an array of 8
u32 variables for both suspended_ports and port_c_suspend. It also
allocates a 256-element array to keep track of when the ports will be done
resuming.
Since we can only have 31 roothub ports, we only need to use one u32 for
each of the suspend state and change variables. We simplify the bit math
that's trying to index into those arrays and set the correct bit, if we
assume wIndex never exceeds 30. (wIndex is zero-based after it's
decremented from the value passed in from the USB core.) Finally, we
change the resume_done array to only hold 31 elements.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <andiry.xu@amd.com>
The irq enabling code is going to be refactored into a new function, so
clean up some checkpatch errors before moving it.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Using a #define to redefine a common variable name is a bad thing,
especially when the #define is in a header. include/linux/usb/hcd.h
redefined bitmap to DeviceRemovable to avoid typing a long field in the
hub descriptor. This has unintended side effects for files like
drivers/usb/core/devio.c that include that file, since another header
included after hcd.h has different variables named bitmap.
Remove the bitmap #define and replace instances of it in the host
controller code. Cleanup the spaces around function calls and square
brackets while we're at it.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Cc: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
Cc: Tony Olech <tony.olech@elandigitalsystems.com>
Cc: "Robert P. J. Day" <rpjday@crashcourse.ca>
Cc: Max Vozeler <mvz@vozeler.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Cc: Rodolfo Giometti <giometti@linux.it>
Cc: Mike Frysinger <vapier@gentoo.org>
Cc: Anton Vorontsov <avorontsov@mvista.com>
Cc: Sebastian Siewior <bigeasy@linutronix.de>
Cc: Lothar Wassmann <LW@KARO-electronics.de>
Cc: Olav Kongas <ok@artecdesign.ee>
Cc: Martin Fuzzey <mfuzzey@gmail.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: David Brownell <dbrownell@users.sourceforge.net>
The test of placing a number of command no-ops on the command ring and
counting the number of no-op events that were generated was only used
during the initial xHCI driver bring up. This test is no longer used, so
delete it.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
The PM core reacts badly when the return code from usb_runtime_suspend()
is not 0, -EAGAIN, or -EBUSY. The PM core regards this as a fatal error,
and refuses to run anymore PM helper functions. In particular,
usbfs_open() and other usbfs functions will fail because the PM core will
return an error code when usb_autoresume_device() is called. This causes
libusb and/or lsusb to either hang or segfault.
If a USB device cannot suspend for some reason (e.g. a hub doesn't report
it has remote wakeup capabilities), we still want lsusb and other
userspace programs to work. So return -EBUSY, which will fill people's
log files with failed tries, but will ensure userspace still works.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Move the USB_STORAGE_ENE_UB6250 entry so that it stays under the
USB_STORAGE menu.
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Fix ene_ub6250 build: it uses usb_storage driver interfaces, so it
should depend on USB_STORAGE.
ene_ub6250.c:(.text+0x14ff19): undefined reference to `usb_stor_reset_resume'
ene_ub6250.c:(.text+0x14ffb1): undefined reference to `usb_stor_bulk_transfer_buf'
ene_ub6250.c:(.text+0x14ffdd): undefined reference to `usb_stor_bulk_srb'
ene_ub6250.c:(.text+0x14fff1): undefined reference to `usb_stor_bulk_transfer_sg'
ene_ub6250.c:(.text+0x1503dd): undefined reference to `usb_stor_set_xfer_buf'
ene_ub6250.c:(.text+0x15048e): undefined reference to `usb_stor_access_xfer_buf'
ene_ub6250.c:(.text+0x150723): undefined reference to `usb_stor_probe1'
ene_ub6250.c:(.text+0x150795): undefined reference to `usb_stor_probe2'
ene_ub6250.c:(.text+0x1507af): undefined reference to `usb_stor_disconnect'
drivers/built-in.o:(.data+0x10224): undefined reference to `usb_stor_suspend'
drivers/built-in.o:(.data+0x10230): undefined reference to `usb_stor_pre_reset'
drivers/built-in.o:(.data+0x10234): undefined reference to `usb_stor_post_reset'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
"buf" gets allocated twice in a row. It's the second allocation which
is correct. The first one should be removed.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Acked-by: huajun li <huajun.li.lee@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The Tegra2 USB controller doesn't properly deal with misaligned DMA
buffers, causing corruption. This is especially prevalent with USB
network adapters, where skbuff alignment is often in the middle of a
4-byte dword.
To avoid this, allocate a temporary buffer for the DMA if the provided
buffer isn't sufficiently aligned.
Signed-off-by: Robert Morell <rmorell@nvidia.com>
Signed-off-by: Benoit Goby <benoit@android.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The Tegra 2 SoC has 3 EHCI compatible USB controllers. This patch adds
the necessary glue to allow the ehci-hcd driver to work on Tegra 2
SoCs.
The platform data is used to configure board-specific phy settings and
to configure the operating mode, as one of the ports may be used as a otg
port. For additional power saving, the driver supports powering down the
phy on bus suspend when it is used, for example, to connect an internal
device that use an out-of-band remote wakeup mechanism (e.g. a gpio).
Signed-off-by: Benoit Goby <benoit@android.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
I picked up a new DAK-780EX(professional digitl reverb/mix system),
which use CH341T chipset to communication with computer on 3/2011
and the CH341T's vendor code is 1a86
Looking up the CH341T's vendor and product id's I see:
1a86 QinHeng Electronics
5523 CH341 in serial mode, usb to serial port converter
CH341T,CH341 are the products of the same company, maybe
have some common hardware, and I test the ch341.c works
well with CH341T
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
On a laptop I see these errors on (most) resumes:
hub 3-0:1.0: over-current change on port 1
hub 3-0:1.0: over-current change on port 2
Since over-current conditions can disappear quite quickly it's better to
downgrade that message to debug level, recheck for an over-current
condition a little later and only print and over-current condition error
if that condition (still) exists when it's rechecked.
Add similar logic to hub over-current changes. (That code is untested,
as those changes do not occur on this laptop.)
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Fix the following section mismatch warning:
WARNING: drivers/usb/built-in.o(.data+0x74c): Section mismatch in reference from the variable ehci_atmel_driver to the function .init.text:ehci_atmel_drv_probe()
The variable ehci_atmel_driver references
the function __init ehci_atmel_drv_probe()
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,
Signed-off-by: Hubert Feurstein <h.feurstein@gmail.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Adding support for the OLIMEX ARM-USB-OCD-H JTAG device (id 15ba:002b)
based on FTDI FT2232H
Signed-off-by: JF Argentino <jf.argentino@free.fr>
Acked-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
On https://bugs.launchpad.net/ubuntu/+source/linux/+bug/636091, one of
the cases reported is a big timeout on option_send_setup, which causes
some side effects as tty_lock is held. Looks like some of ZTE MF626
devices also don't like the RTS/DTR setting in option_send_setup, like
with 4G XS Stick W14. The reporter confirms which this it solves the
long freezes in his system.
Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Direct access to PMIC register is not safe and will impact battery
charging. New IPC command supported in SCU FW for VBus power control.
USB OTG driver will switch to such commands instead of direct access
to PMIC register for safety and SCU FW will handle the actual work
after got the request(IPC command).
Due to this change, usb driver should wait more time for sync OTGSC
with USBCFG by SCU. Update wait time from 2ms to 5ms.
Signed-off-by: Hao Wu <hao.wu@intel.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The usb portion of this driver can now go into drivers/usb/storage.
This leaves the non-usb portion of the code still in staging.
Signed-off-by: Huajun Li <huajun.li.lee@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Currently all boards using the s3c2410_udc driver use a GPIO to control the
state of the pullup, as a result the same code is reimplemented in each board
file.
This patch adds support for using a GPIO to control the pullup state to the udc
driver, so the boards can use a common implementation.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Commit ab1666c136 (USB: quirk PLL power down mode)
added code that reads the revision ID from the PCI configuration register while
it's stored by PCI subsystem in the 'revision' field of 'struct pci_dev'...
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This driver is used across all MSM SoCs. Hence give a generic name.
All Functions and strutures are also using "msm_otg" as prefix.
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This fixes a problem with my previous patch series where there's a great
risk that the kernel will crash when unplugging interrupt devices from
the USB port. These lines must have got missing when I rebased the
patches from the older kernel I was working with to 2.6.37 and 2.6-next:
This fixes a bug where the kernel may crash if you unplug a USB device
that has active interrupt transfers.
Signed-off-by: Arvid Brodin <arvid.brodin@enea.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The hcd->state variable is a disaster. It's not clearly owned by
either usbcore or the host controller drivers, and they both change it
from time to time, potentially stepping on each other's toes. It's
not protected by any locks. And there's no mechanism to prevent it
from going through an invalid transition.
This patch (as1451) takes a first step toward fixing these problems.
As it turns out, usbcore uses hcd->state for essentially only two
things: checking whether the controller's root hub is running and
checking whether the controller has died. Therefore the patch adds
two new atomic bitflags to the hcd structure, to store these pieces of
information. The new flags are used only by usbcore, and a private
spinlock prevents invalid combinations (a dead controller's root hub
cannot be running).
The patch does not change the places where usbcore sets hcd->state,
since HCDs may depend on them. Furthermore, there is one place in
usb_hcd_irq() where usbcore still must use hcd->state: An HCD's
interrupt handler can implicitly indicate that the controller died by
setting hcd->state to HC_STATE_HALT. Nevertheless, the new code is a
big improvement over the current code.
The patch makes one other change. The hcd_bus_suspend() and
hcd_bus_resume() routines now check first whether the host controller
has died; if it has then they return immediately without calling the
HCD's bus_suspend or bus_resume methods.
This fixes the major problem reported in Bugzilla #29902: The system
fails to suspend after a host controller dies during system resume.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Alex Terekhov <a.terekhov@gmail.com>
CC: <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Move to SOC_SOC_IMX3X.
Leave ARCH_MX31/35 definitions there, in case some place prevent multi-soc
single image.
Signed-off-by: Richard Zhao <richard.zhao@freescale.com>
Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6: (42 commits)
MAINTAINERS: Add Andy Gospodarek as co-maintainer.
r8169: disable ASPM
RxRPC: Fix v1 keys
AF_RXRPC: Handle receiving ACKALL packets
cnic: Fix lost interrupt on bnx2x
cnic: Prevent status block race conditions with hardware
net: dcbnl: check correct ops in dcbnl_ieee_set()
e1000e: disable broken PHY wakeup for ICH10 LOMs, use MAC wakeup instead
igb: fix sparse warning
e1000: fix sparse warning
netfilter: nf_log: avoid oops in (un)bind with invalid nfproto values
dccp: fix oops on Reset after close
ipvs: fix dst_lock locking on dest update
davinci_emac: Add Carrier Link OK check in Davinci RX Handler
bnx2x: update driver version to 1.62.00-6
bnx2x: properly calculate lro_mss
bnx2x: perform statistics "action" before state transition.
bnx2x: properly configure coefficients for MinBW algorithm (NPAR mode).
bnx2x: Fix ethtool -t link test for MF (non-pmf) devices.
bnx2x: Fix nvram test for single port devices.
...
timeout variable is not used anywhere in int write_cmd_usb, remove it
Signed-off-by: Huzaifa Sidhpurwala <huzaifas@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
is_iso variable is not used anywhere, remove it
Signed-off-by: Huzaifa Sidhpurwala <huzaifas@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Driver was taking max() of a size_t and u32 which causes complaint
about comparison of different types.
Stumbled on this accidently in my config, never used.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
In wusb_cluster_id_get(), if no zero bits exist in wusb_cluster_id_table,
find_first_zero_bit() returns CLUSTER_IDS.
But it is impossible to detect that the bitmap is full because there
is an off-by-one error in the return value check. It will cause
unexpected memory access by setting bit out of wusb_cluster_id_table
bitmap, and caller will get wrong cluster id.
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Cc: linux-usb@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Build log:
In file included from drivers/usb/host/ehci-hcd.c:1208:
drivers/usb/host/ehci-xilinx-of.c: In function 'ehci_hcd_xilinx_of_probe':
drivers/usb/host/ehci-xilinx-of.c:168: error: implicit declaration of function 'of_address_to_resource'
Signed-off-by: John Williams <john.williams@petalogix.com>
Signed-off-by: Michal Simek <monstr@monstr.eu>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
The SH EHCI/OHCI driver hardcoded the CPU type in {ehci,ohci}-hcd.c.
So if we will add the new CPU, we had to add to the hcd driver each time.
The patch adds the CONFIG_USB_{EHCI,OHCI}_SH configuration. So if we
want to use the SH EHCI/OHCI, we only enable the configuration.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch moves the AMD PLL quirk code in OHCI/EHCI driver to pci-quirks.c,
and exports the functions to be used by xHCI driver later.
AMD PLL quirk disable the optional PM feature inside specific
SB700/SB800/Hudson-2/3 platforms under the following conditions:
1. If an isochronous device is connected to OHCI/EHCI/xHCI port and is active;
2. Optional PM feature that powers down the internal Bus PLL when the link is
in low power state is enabled.
Without AMD PLL quirk, USB isochronous stream may stutter or have breaks
occasionally, which greatly impair the performance of audio/video streams.
Currently AMD PLL quirk is implemented in OHCI and EHCI driver, and will be
added to xHCI driver too. They are doing similar things actually, so move
the quirk code to pci-quirks.c, which has several advantages:
1. Remove duplicate defines and functions in OHCI/EHCI (and xHCI) driver and
make them cleaner;
2. AMD chipset information will be probed only once and then stored.
Currently they're probed during every OHCI/EHCI initialization, move
the detect code to pci-quirks.c saves the repeat detect cost;
3. Build up synchronization among OHCI/EHCI/xHCI driver. In current
code, every host controller enable/disable PLL only according to
its own status, and may enable PLL while there is still isoc transfer on
other HCs. Move the quirk to pci-quirks.c prevents this issue.
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Alex He <alex.he@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The ehci and ohci drivers are simplified; Since
UHH and TLL initialization, clock handling are
done by common usbhs core driver, these functionalities
are removed from ehci and ohci drivers.
Signed-off-by: Keshava Munegowda <keshava_mgowda@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Create the ehci and ohci specific platform data structures.
The port enum values are made common for both ehci and ohci.
Signed-off-by: Keshava Munegowda <keshava_mgowda@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
now that we have names on all memory bases, we can
switch to use platform_get_resource_byname() which
will make it simpler when we move to a setup where
OHCI and EHCI on OMAP play well together.
Signed-off-by: Felipe Balbi <balbi@ti.com>
The EHCI controller in OMAP4 supports a transceiver-less link
mode (TLL mode), similar to the one in OMAP3. On the OMAP4
however, there are an additional set of clocks that need
to be turned on to get this working.
Request and configure these for each port if that port
is connected in TLL mode.
Signed-off-by: Anand Gadiyar <gadiyar@ti.com>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
In OMAP3xxx with OTG mode or host only mode, When the device
is inserted after the gadget driver loading the enumeration was not
through. This is because the mentor controller will start sensing the
ID PIN only after setting the session bit.
So after ID-GND, need to set the session bit for mentor to get it
configured as A device.
This is a fix to set the session bit again in ID_GND notification handler.
Tested with OMAP3630Zoom3 platform.
Signed-off-by: Hema HK <hemahk@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Update the last_event variable of otg_transceiver. This will be used in
the musb platform glue driver for runtime idling the device.
Signed-off-by: Hema HK <hemahk@ti.com>
Cc: Felipe Balbi <balbi@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
This patch supports the retention and offmode support in the idle path for
musb driver using runtime pm APIs.
This is restricted to support offmode and retention only when device not
connected.When device/cable connected with gadget driver loaded,configured
to no idle/standby which will not allow the core transition to retention
or off.
There is no context save/restore done by hardware for musb in OMAP3
and OMAP4,driver has to take care of saving and restoring the context
during offmode.
Musb has a requirement of configuring sysconfig register to force
idle/standby mode and set the ENFORCE bit in module STANDBY register
for retention and offmode support.
Runtime pm and hwmod frameworks will take care of configuring to force
idle/standby when pm_runtime_put_sync is called and back to no
idle/standby when pm_runeime_get_sync is called.
Compile, boot tested and also tested the retention in the idle path on
OMAP3630Zoom3. And tested the global suspend/resume with offmode enabled.
Usb basic functionality tested on OMAP4430SDP.
There is some problem with idle path offmode in mainline, I could not test
with offmode. But I have tested this patch with resetting the controller
in the idle path when wakeup from retention just to make sure that the
context is lost, and restore path is working fine.
Removed .suspend/.resume fnction pointers and functions because there
is no need of having these functions as all required work is done
at runtime in the driver.
There is no need to call the runtime pm api with glue driver device
as glue layer device is the parent of musb core device, when runtime apis
are called for the child, parent device runtime functionality
will be invoked.
Design overview:
pm_runtime_get_sync: When called with musb core device takes care of
enabling the clock, calling runtime callback function of omap2430 glue
layer, runtime call back of musb driver and configure the musb sysconfig
to no idle/standby
pm_runtime_put: Takes care of calling runtime callback function of omap2430
glue layer, runtime call back of musb driver, Configure the musb sysconfig
to force idle/standby and disable the clock.
During musb driver load: Call pm_runtime_get_sync.
End of musb driver load: Call pm_runtime_put
During gadget driver load: Call pm_runtime_get_sync,
End of gadget driver load: Call pm_runtime_put if there is no device
or cable is connected.
During unload of the gadget driver:Call pm_runtime_get_sync if cable/device
is not connected.
End of the gadget driver unload : pm_runtime_put
During unload of musb driver : Call pm_runtime_get_sync
End of unload: Call pm_runtime_put
On connect of usb cable/device -> transceiver notification(VBUS and ID-GND):
pm_runtime_get_sync only if the gadget driver loaded.
On disconnect of the cable/device -> Disconnect Notification:
pm_runtime_put if the gadget driver is loaded.
Signed-off-by: Hema HK <hemahk@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
For OMAP3 and OMAP4 for offmode and retention support, musb
sysconfig is configured to force idle and standby with ENABLE_FORCE bit
of OTG_FORCESTNDBY set.
And on wakeup configure to no ilde/standby with resetting the ENABLE_FORCE
bit. There is not need to save and restore of this register anymore
so removed omap2430_save_context/omap2430_restore_context functions.
and also removed otg_forcestandby member of musb_context_registers
structure
Signed-off-by: Hema HK <hemahk@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
commit ad1adb89a0
(usb: musb: gadget: do not poke with gadget's list_head)
fixed a bug in musb where it was corrupting the list_head
which is supposed to be used by gadget drivers. While
doing that, I forgot to fix the usage in musb_gadget_dequeue()
method. Fix that.
Reported-by: Pavol Kurina <pavol.kurina@emsys.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Make sure that we check the return value of tty_port_tty_get.
Sometimes it may return NULL and we later dereference that.
The only place here is in kobil_read_int_callback, so fix it.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Alan Cox <alan@linux.intel.com>
Cc: stable@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Make sure that we check the return value of tty_port_tty_get.
Sometimes it may return NULL and we later dereference that.
There are several places to check. For easier handling,
tty_port_tty_get is moved directly to the palce where needed in
keyspan_pda_rx_interrupt.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Remove redundant "toggle" member from struct isp1760_qtd, and store toggle
status in struct isp1760_qh only.
Signed-off-by: Arvid Brodin <arvid.brodin@enea.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Replace the period calculation for INT packets with something readable. Seems
to fix a rare bug with quickly repeated insertion/removal of several USB
devices simultaneously (hub control INT packets).
Signed-off-by: Arvid Brodin <arvid.brodin@enea.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Consolidate printouts to use dev_XXX functions instead of an assortment of
printks and driver specific macros. Remove some unused code snippets and struct
members. Remove some unused function parameters and #defines. Change the
"queue_entry" variable name which has different but related meanings in
different places and use "slot" only.
Signed-off-by: Arvid Brodin <arvid.brodin@enea.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Removes the redundant hw_next list pointer from struct isp1760_qtd, removes some
unused #defines, removes redundant "urb" member from struct inter_packet_info.
Signed-off-by: Arvid Brodin <arvid.brodin@enea.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This helps users with platform-bus-connected isp176xs, big-endian cpu,
and missing byteswapping on the data bus. It does so by collecting all
SW byteswaps in one place and also fixes a bug with non-32-bit io
transfers on this hardware, where payload has to be byteswapped
instead of ptds.
Signed-off-by: Arvid Brodin <arvid.brodin@enea.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The Patch below removes one to many "n's" in a word..
Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
CC: Alan Stern <stern@rowland.harvard.edu>
CC: linux-usb@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The Patch below removes one to many "n's" in a word..
Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
CC: Alan Stern <stern@rowland.harvard.edu>
CC: linux-usb@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This is similar to what we already do in cdc-phonet.c in the same
situation. pskb_pull() refuses to work with HIGHMEM, even if it is
known that the socket buffer is entirely in "low" memory.
Signed-off-by: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Get rid of users of of_platform_driver in drivers/usb. The
of_platform_{,un}register_driver functions are going away, so the
users need to be converted to using the platform_bus_type directly.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
The patch below removes an extra "l" in the word.
Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
When a driver doesn't know how much data a device is going to send,
the buffer size should be at least as big as the endpoint's maxpacket
value. The serial drivers don't follow this rule; many of them
request only 256-byte bulk-in buffers. As a result, they suffer
overflow errors if a high-speed device wants to send a lot of data,
because high-speed bulk endpoints are required to have a maxpacket
size of 512.
This patch (as1450) fixes the problem by using the driver's
bulk_in_size value as a minimum, always allocating buffers no smaller
than the endpoint's maxpacket size.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Flynn Marquardt <flynn@flynnux.de>
CC: <stable@kernel.org> [after .39-rc1 is out]
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch add bus glue for USB controller commonly found in PMC-Sierra MSP71xx family of SoC's.
Signed-off-by: Anoop P A <anoop.pa@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
When USB CV MSC tests are run on f_mass_storage gadget
Bulk Only Mass Storage Reset fails since req->length
is set to USB_BUFSIZ=1024 in composite_setup().
Initialize req->length to zero to fix this.
Signed-off-by: Maulik Mankad <maulik@ti.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Michal Nazarewicz <mina86@mina86.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The USB stack historically has conflated device numbers (i.e., the
value of udev->devnum) with device addresses. This is understandable,
because until recently the two values were always the same.
But with USB-3.0 they aren't the same, so we should start calling
these things by their correct names. This patch (as1449b) changes many
of the references to "address" in the hub driver to "device number"
or "devnum".
The patch also removes some unnecessary or misleading comments.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Luben Tuikov <ltuikov@yahoo.com>
Reviewed-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This is similar to what we already do in cdc-phonet.c in the same
situation.
Signed-off-by: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch fixes the following compile warnings
drivers/usb/host/ehci-dbg.c:45: warning: 'dbg_hcs_params' defined but not used
drivers/usb/host/ehci-dbg.c:89: warning: 'dbg_hcc_params' defined but not used
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Implement the test modes mentioned in 7.1.20 section of USB 2.0
specification. High-speed capable devices must support these test
modes to facilitate compliance testing.
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch adds support for remote wakeup. The following things
are handled:
- Process SET_FEATURE/CLEAR_FEATURE control requests sent by host
for enabling/disabling remote wakeup feature.
- Report remote wakeup enable status in response to GET_STATUS
control request.
- Implement wakeup method defined in usb_gadget_ops for initiating
remote wakeup.
- Notify gadget driver about suspend and resume.
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Chipidea USB controller provides a means (Add dTD TripWire semaphore)
for safely adding a new dTD to an active endpoint's linked list. Make
use of this feature to improve performance. Dynamically allocate and
free dTD for supporting zero length packet termination. Honor
no_interrupt flag set by gadget drivers.
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
If a device plug/unplug is detected on an ATI SB700 USB controller in D3,
it appears to set the port status register but not the controller status
register. As a result we'll fail to detect the plug event. Check the port
status register on resume as well in order to catch this case.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Cc: stable <stable@kernel.org> [after .39-rc1 is out]
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
MUSB is a non-standard host implementation which
can handle all speeds with the same core. We need
to set has_tt flag after commit
d199c96d41 (USB: prevent
buggy hubs from crashing the USB stack) in order for
MUSB HCD to continue working.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Cc: stable <stable@kernel.org>
Cc: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Michael Jones <michael.jones@matrix-vision.de>
Tested-by: Alexander Holler <holler@ahsoftware.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Functions that are not used outsde of the module they are defined
should be marked as static.
Signed-off-by: Dmitry Torokhov <dtor@vmware.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
In the gadget code, there are several DBG() macro invocations that explicitly
print the calling function's name while DBG() macro itself does this anyway;
most of these were added by commit f11d893de4
(usb: musb: support ISO high bandwidth for gadget mode). Remove the duplicated
printing, somewhat clarifying the messages at the same time...
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
There is no point in casting to (void *) when setting up xhci->ir_set
as it only makes us lose __iomem annotation and makes sparse unhappy.
OTOH we do need to cast to (void *) when calculating xhci->dba from
offset, but since it is IO memory we need to annotate it as such.
Signed-off-by: Dmitry Torokhov <dtor@vmware.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
xhci->ir_set points to __iomem region, but xhci_print_ir_set accepts
plain struct xhci_intr_reg * causing multiple sparse warning at call
sites and inside the fucntion when we try to read that memory.
Instead of adding __iomem qualifier to the argument let's rework the
function so it itself gets needed register set from xhci and prints
it.
Signed-off-by: Dmitry Torokhov <dtor@vmware.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
If the device isn't reset, the XHCI HCD sends
SET ADDRESS to address 0 while the device is
already in Addressed state, and the request is
dropped on the floor as it is addressed to the
default address. This sequence of events, which this
patch fixes looks like this:
usb_reset_and_verify_device()
hub_port_init()
hub_set_address()
SET_ADDRESS to 0 with 1
usb_get_device_descriptor(udev, 8)
usb_get_device_descriptor(udev, 18)
descriptors_changed() --> goto re_enumerate:
hub_port_logical_disconnect()
kick_khubd()
And then:
hub_events()
hub_port_connect_change()
usb_disconnect()
usb_disable_device()
new device struct
sets device state to Powered
choose_address()
hub_port_init() <-- no reset, but SET ADDRESS to 0 with 1, timeout!
The solution is to always reset the device in
hub_port_init() to put it in a known state.
Note from Sarah Sharp:
This patch should be queued for stable trees all the way back to 2.6.34,
since that was the first kernel that supported configured device reset.
The code this patch touches has been there since 2.6.32, but the bug
would never be hit before 2.6.34 because the xHCI driver would
completely reject an attempt to reset a configured device under xHCI.
Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org
The expression
while (running_total < sg_dma_len(sg))
does not take into account that the remaining data length can be less
than sg_dma_len(sg). In that case, running_total can end up being
greater than the total data length, so an extra TRB is counted.
Changing the expression to
while (running_total < sg_dma_len(sg) && running_total < temp)
fixes that.
This patch should be queued for stable kernels back to 2.6.31.
Signed-off-by: Paul Zimmerman <paulz@synopsys.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org
Calculations like
running_total = TRB_MAX_BUFF_SIZE -
(sg_dma_address(sg) & (TRB_MAX_BUFF_SIZE - 1));
if (running_total != 0)
num_trbs++;
are incorrect, because running_total can never be zero, so the if()
expression will never be true. I think the intention was that
running_total be in the range of 0 to TRB_MAX_BUFF_SIZE-1, not 1
to TRB_MAX_BUFF_SIZE. So adding a
running_total &= TRB_MAX_BUFF_SIZE - 1;
fixes the problem.
This patch should be queued for stable kernels back to 2.6.31.
Signed-off-by: Paul Zimmerman <paulz@synopsys.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org
This makes it easier to spot some problems, which will be fixed by the
next patch in the series. Also change dev_dbg to dev_err in
check_trb_math(), so any math errors will be visible even when running
with debug disabled.
Note: This patch changes the expressions containing
"((1 << TRB_MAX_BUFF_SHIFT) - 1)" to use the equivalent
"(TRB_MAX_BUFF_SIZE - 1)". No change in behavior is intended for
those expressions.
This patch should be queued for stable kernels back to 2.6.31.
Signed-off-by: Paul Zimmerman <paulz@synopsys.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org
Change the BUGs in xhci_find_new_dequeue_state() to WARN_ONs, to avoid
bringing down the box if one of them is hit
This patch should be queued for stable kernels back to 2.6.31.
Signed-off-by: Paul Zimmerman <paulz@synopsys.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org
OMAP4430 is embedded with UTMI PHY. This PHY does not support the
OTG features like ID pin detection and VBUS detection. This function
is exported to an external companion chip TWL6030. Software must retrieve
the OTG HNP and SRP status from the TWL6030 and configure the bits inside
the control module that drive the related USBOTGHS UTMI interface signals.
It must also read back the UTMI signals needed to configure the TWL6030
OTG module.
Can find more details in the TRM[1].
[1]:http://focus.ti.com/pdfs/wtbu/OMAP4430_ES2.0_Public_TRM_vJ.pdf
In OMAP4430 musb driver VBUS and ID notifications are received from the
transceiver driver. If the cable/device is connected during boot,
notifications from transceiver driver will be missed till musb driver
is loaded.
Patch to configure the transceiver in the platform_enable/disable
functions and enable the vbus in the gadget driver based on the
last_event of the otg_transceiver.
Signed-off-by: Hema HK <hemahk@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Save the last event in the otg_transceiver so that it can used in the
musb driver and gadget driver to configure the musb and enable the
vbus for host mode and OTG mode, if the device is connected during boot.
Signed-off-by: Hema HK <hemahk@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Introduce the twl6030_phy_suspend function and assign to otg.set_suspend
function pointer.
This function is used by the musb-omap2430 platform driver
during suspend/resume.
Signed-off-by: Hema HK <hemahk@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
This reverts commit 637d11bfb8. Sarah
wants to tweak it some more before it's applied to the tree.
Cc: Luben Tuikov <ltuikov@yahoo.com>
Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Only oddities here are a couple of drivers that bogusly called the ldisc
helpers instead of returning -ENOIOCTLCMD. Fix the bug and the rest goes
away.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
We don't use it so we can trim it from here as we try and stamp the file
object dependencies out of the serial code.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Doing tiocmget was such fun we should do tiocmset as well for the same
reasons
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
We don't actually need this and it causes problems for internal use of
this functionality. Currently there is a single use of the FILE * pointer.
That is the serial core which uses it to check tty_hung_up_p. However if
that is true then IO_ERROR is also already set so the check may be removed.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
To get the ID status there was an I2C read transfer. Removed this I2C
read transfer as this info can be used from existing variable(linkstat).
Signed-off-by: Hema HK <hemahk@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Remove the regulator enable while driver loading and enable it only when
the cable/device is connected and disable it when disconnected.
Remove the configuration of config_state and config_trans register
configuration as these registers are programmed when regulator
enable/disable is called.
Signed-off-by: Hema HK <hemahk@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Calling runtime pm APIs pm_runtime_put_sync() and pm_runtime_get_sync()
for enabling/disabling the clocks, sysconfig settings.
Enable clock, configure no-idle/standby when active and configure force idle/standby
and disable clock when idled. This is taken care by the runtime framework when
driver calls the pm_runtime_get_sync and pm_runtime_put_sync APIs.
Need to configure MUSB into force standby and force idle mode when usb not used
Signed-off-by: Hema HK <hemahk@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Cousson, Benoit <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
struct usb_request's list_head is supposed to be
used only by gadget drivers, but musb is abusing
that. Give struct musb_request its own list_head
and prevent musb from poking into other driver's
business.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Just a few cosmetic fixes to usb_gadget_probe_driver()
and usb_gadget_unregister_driver().
Decreased a few indentation levels with goto statements.
While at that, also add the missing call to musb_stop().
If we don't have OTG, there's no point of leaving
MUSB prepared for operation if a gadget driver fails
to probe. The same is valid for usb_gadget_unregister_driver(),
since we are removing the gadget driver and we don't have
OTG, we can completely unconfigure MUSB.
Signed-off-by: Felipe Balbi <balbi@ti.com>
During development, even though board is wired
to e.g. OTG, we might want to compile host-only
or peripheral-only configurations.
Let's allow that to happen.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Use bitmap_set()/bitmap_clear() to fill/zero a region of a bitmap
instead of doing set_bit()/clear_bit() each bit.
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Now that ehci_run don't call ehci_reset, we can use ehci_run.
Signed-off-by: Matthieu CASTET <castet.matthieu@parrot.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
TDI driver does the ehci_reset in their reset callback.
Don't reset in ehci_run because configuration settings done in
platform driver will be reset.
This will allow to make msm use ehci_run.
Signed-off-by: Matthieu CASTET <castet.matthieu@parrot.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The driver private data is retrieved incorrectly which results
a crash when written into "mode" debugfs file.
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch fixes the below compiler warning
drivers/usb/otg/msm72k_otg.c:257: warning: 'msm_otg_suspend' defined but not used
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
resumption of devices can fail. Errors must be handled.
Signed-off-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The device never needs to be resumed in close(). But the counters
must be balanced. As resumption can fail, but the counters must
be balanced, use the _no_resume() version which cannot fail.
Signed-off-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
If an error happens during resumption.
The remaining data has to be cleanly discarded and the pm
counters have to be adjusted.
Signed-off-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
As soon as the first error happens, the write must
be stopped, lest we send mutilated messages.
Signed-off-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
An error in the write code path would permanently disable
runtime PM in this driver
Signed-off-by: Oliver Neukum <oliver@neukum.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This fixes two errors:
- the device is busy if a message was recieved even if resubmission fails
- the device is not busy if resubmission fails due to -EPERM
Signed-off-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The document says:
|2.1 Problem description
| When at least two USB devices are simultaneously running, it is observed that
| sometimes the INT corresponding to one of the USB devices stops occurring. This may
| be observed sometimes with USB-to-serial or USB-to-network devices.
| The problem is not noticed when only USB mass storage devices are running.
|2.2 Implication
| This issue is because of the clearing of the respective Done Map bit on reading the ATL
| PTD Done Map register when an INT is generated by another PTD completion, but is not
| found set on that read access. In this situation, the respective Done Map bit will remain
| reset and no further INT will be asserted so the data transfer corresponding to that USB
| device will stop.
|2.3 Workaround
| An SOF INT can be used instead of an ATL INT with polling on Done bits. A time-out can
| be implemented and if a certain Done bit is never set, verification of the PTD completion
| can be done by reading PTD contents (valid bit).
| This is a proven workaround implemented in software.
Russell King run into this with an USB-to-serial converter. This patch
implements his suggestion to enable the high frequent SOF interrupt only
at the time we have ATL packages queued. It goes even one step further
and enables the SOF interrupt only if we have more than one ATL packet
queued at the same time.
Cc: <stable@kernel.org> # [2.6.35.x, 2.6.36.x, 2.6.37.x]
Tested-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
ehci_lpm_set_da and ehci_lpm_check are EHCI 1.1 specific functions which
are not used on many platforms but do generate annoying gcc warnings
Signed-off-by: Maksim Rayskiy <mrayskiy@broadcom.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
We need FUSB300_MAX_NUM_EP (16) names otherwise the last 8 names get
initialized to garbage values in fusb300_probe().
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This is a patch that seems to make the USB hangs on the S3C244X go away.
At least a good amount of ping torture didn't make them come back so far.
The issue is that, if there are several back-to-back packets, sometimes no
interrupt is generated for one of them. This seems to be caused by the
mysterious dual packet mode, which the USB hardware enters automatically
if the endpoint size is half that of the FIFO. (On the 244X, this is the
normal situation for bulk data endpoints.)
There is also a timing factor in this. It seems that what happens is that
the USB hardware automatically sends an acknowledgement if there is only one
packet in the FIFO (the FIFO has space for two). If another packet arrives
before the host has retrieved and acknowledged the previous one, no interrupt
is generated for that second one.
However, there may be an indication. There is one undocumented bit (none
of the 244x manuals document it), OUT_CRS1_REG[1], that seems to be set
suspiciously often when this condition occurs. There is also
CLR_DATA_TOGGLE, OUT_CRS1_REG[7], which may have a function related to
this. (The Samsung manual is rather terse on that, as usual.)
This needs to be examined further. For now, the patch seems to do the
trick.
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This PCH_UDC driver does not work normally when "Ethernet gadget" is used.
This patch fixed this issue.
The following was modified.
- The FIFO flush process.
- The descriptor creation process.
- The adjustment of DMA buffer align.
Currently the PCH_UDC driver can work normally with "Ethernet gadget",
"Serial gadget" or "File-backed Storage Gadget".
Signed-off-by: Toshiharu Okada <toshiharu-linux@dsn.okisemi.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Reorder the driver->name assignment so the 'iProduct' could be initialized
as well if both 'name' and 'iProduct' come as NULL by default.
Also, remove the misplaced 'extern' keyword.
Signed-off-by: Jassi Brar <jassi.brar@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
While checking valid interface number we should compare MAX_CONFIG_INTERFACES
with the variable 'intf' (which holds the lower 8bits of w_index) rather than
'w_index'
Signed-off-by: Jassi Brar <jassi.brar@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
I picked up a new Sierra usb 308 (At&t Shockwave) on 2/2011 and the vendor code
is 0x0f3d
Looking up vendor and product id's I see:
0f3d Airprime, Incorporated
0112 CDMA 1xEVDO PC Card, PC 5220
Sierra and Airprime are somehow related and I'm guessing the At&t usb 308 might
be have some common hardware with the AirPrime SL809x.
Signed-off-by: Jon Thomas <jthomas@redhat.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Sarah Sharp