The usb_create_sysfs_intf_files() function always returned zero even
if it failed to create sysfs fails. Since this is a desired behaviour
there is no need to return return code at all. This commit changes
function's return type (form int) to void.
Signed-off-by: Michal Nazarewicz <mina86@mina86.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch clear PORT_POWER when suspend a USB3.0 device behind a USB3.0
external hub, so the system can suspend and resume.
Note USB3.0 device may not work after system resume and this is a temporary
workaround. The correct fix will be in future patches.
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
If I unplug a device while the UAS driver is loaded, I get an oops
in usb_free_streams(). This is because usb_unbind_interface() calls
usb_disable_interface() which calls usb_disable_endpoint() which sets
ep_out and ep_in to NULL. Then the UAS driver calls usb_pipe_endpoint()
which returns a NULL pointer and passes an array of NULL pointers to
usb_free_streams().
I think the correct fix for this is to check for the NULL pointer
in usb_free_streams() rather than making the driver check for this
situation. My original patch for this checked for dev->state ==
USB_STATE_NOTATTACHED, but the call to usb_disable_interface() is
conditional, so not all drivers would want this check.
Note from Sarah Sharp: This patch does avoid a potential dereference,
but the real fix (which will be implemented later) is to set the
.soft_unbind flag in the usb_driver structure for the UAS driver, and
all drivers that allocate streams. The driver should free any streams
when it is unbound from the interface. This avoids leaking stream rings
in the xHCI driver when usb_disable_interface() is called.
This should be queued for stable trees back to 2.6.35.
Signed-off-by: Matthew Wilcox <willy@linux.intel.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org
The `name' variable is unused in usb_deregister_dev() since commit d6e5bcf
(devfs: Remove the mode field from usb_class_driver as it's no longer needed).
Signed-off-by: Libor Pechacek <lpechacek@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Isochronous and interrupt SuperSpeed endpoints use the same mechanisms
for decoding bInterval values as HighSpeed ones so adjust the code
accordingly.
Also bandwidth reservation for SuperSpeed matches highspeed, not
low/full speed.
Signed-off-by: Dmitry Torokhov <dtor@vmware.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
When `echo Y > /sys/module/usbcore/parameters/usbfs_snoop` and
usb_control_msg() returns error, a lot of kernel memory is dumped to dmesg
until unhandled kernel paging request occurs.
Signed-off-by: Michal Sojka <sojkam1@fel.cvut.cz>
Cc: stable@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB defines usb_device_type pointing to usb_device_pm_ops that
provides system-wide PM callbacks only and usb_bus_type pointing to
usb_bus_pm_ops that provides runtime PM callbacks only. However,
the USB runtime PM callbacks may be defined in usb_device_pm_ops
which makes it possible to drop usb_bus_pm_ops and will allow us
to consolidate the handling of subsystems by the PM core code.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
* 'usb-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6: (172 commits)
USB: Add support for SuperSpeed isoc endpoints
xhci: Clean up cycle bit math used during stalls.
xhci: Fix cycle bit calculation during stall handling.
xhci: Update internal dequeue pointers after stalls.
USB: Disable auto-suspend for USB 3.0 hubs.
USB: Remove bogus USB_PORT_STAT_SUPER_SPEED symbol.
xhci: Return canceled URBs immediately when host is halted.
xhci: Fixes for suspend/resume of shared HCDs.
xhci: Fix re-init on power loss after resume.
xhci: Make roothub functions deal with device removal.
xhci: Limit roothub ports to 15 USB3 & 31 USB2 ports.
xhci: Return a USB 3.0 hub descriptor for USB3 roothub.
xhci: Register second xHCI roothub.
xhci: Change xhci_find_slot_id_by_port() API.
xhci: Refactor bus suspend state into a struct.
xhci: Index with a port array instead of PORTSC addresses.
USB: Set usb_hcd->state and flags for shared roothubs.
usb: Make core allocate resources per PCI-device.
usb: Store bus type in usb_hcd, not in driver flags.
usb: Change usb_hcd->bandwidth_mutex to a pointer.
...
After redefining CONFIG_PM to depend on (CONFIG_PM_SLEEP ||
CONFIG_PM_RUNTIME) the CONFIG_PM_OPS option is redundant and can be
replaced with CONFIG_PM.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
A subsequent patch will modify device_set_wakeup_capable() in such
a way that it will call functions which may sleep and therefore it
shouldn't be called under spinlocks. In preparation to that, modify
usb_set_device_state() to avoid calling device_set_wakeup_capable()
under device_state_lock.
Tested-by: Minchan Kim <minchan.kim@gmail.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Use the Mult and bMaxBurst values from the endpoint companion
descriptor to calculate the max length of an isoc transfer.
Add USB_SS_MULT macro to access Mult field of bmAttributes, at
Sarah's suggestion.
This patch should be queued for the 2.6.36 and 2.6.37 stable trees, since
those were the first kernels to have isochronous support for SuperSpeed
devices.
Signed-off-by: Paul Zimmerman <paulz@synopsys.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org
USB 3.0 devices have a slightly different suspend sequence than USB
2.0/1.1 devices. There isn't support for USB 3.0 device suspend yet, so
make khubd leave autosuspend disabled for USB 3.0 hubs. Make sure that
USB 3.0 roothubs still have autosuspend enabled, since that path in the
xHCI driver works fine.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
USB_PORT_STAT_SUPER_SPEED is a made up symbol that the USB core used to
track whether USB ports had a SuperSpeed device attached. This is a
linux-internal symbol that was used when SuperSpeed and non-SuperSpeed
devices would show up under the same xHCI roothub. This particular
port status is never returned by external USB 3.0 hubs. (Instead they
have a USB_PORT_STAT_SPEED_5GBPS that uses a completely different speed
mask.)
Now that the xHCI driver registers two roothubs, USB 3.0 devices will only
show up under USB 3.0 hubs. Rip out USB_PORT_STAT_SUPER_SPEED and replace
it with calls to hub_is_superspeed().
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>
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>