10 Jan, 2015
1 commit
-
Solves xhci error cases with debug messages:
xhci_hcd 0000:00:14.0: Setup ERROR: setup context command for slot 1.
usb 1-6: hub failed to enable device, error -22xhci will give a context state error if we try to set a slot in default
state to the same default state with a special address device command.Turns out this happends in several cases:
- retry reading the device rescriptor in hub_port_init()
- usb_reset_device() is called for a slot in default state
- in resume path, usb_port_resume() calls hub_port_init()The default state is usually reached from most states with a reset device
command without any context state errors, but using the address device
command with BSA bit set (block set address) only works from the enabled
state and will otherwise cause context error.solve this by checking if we are already in the default state before issuing
a address device BSA=1 command.Fixes: 48fc7dbd52c0 ("usb: xhci: change enumeration scheme to 'new scheme'")
Cc: # v3.14+
Signed-off-by: Mathias Nyman
Signed-off-by: Greg Kroah-Hartman
15 Dec, 2014
1 commit
-
Pull USB updates from Greg KH:
"Here's the big set of USB and PHY patches for 3.19-rc1.The normal churn in the USB gadget area is in here, as well as xhci
and other individual USB driver updates. The PHY tree is also in
here, as there were dependancies on the USB tree.All of these have been in linux-next"
* tag 'usb-3.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (351 commits)
arm: omap3: twl: remove usb phy init data
usbip: fix error handling in stub_probe()
usb: gadget: udc: missing curly braces
USB: mos7720: delete some unneeded code
wusb: replace memset by memzero_explicit
usbip: remove unneeded structure
usb: xhci: fix comment for PORT_DEV_REMOVE
xhci: don't use the same variable for stopped and halted rings current TD
xhci: clear extra bits from slot context when setting max exit latency
xhci: cleanup finish_td function
USB: adutux: NULL dereferences on disconnect
usb: chipidea: fix platform_no_drv_owner.cocci warnings
usb: chipidea: Fixed a few typos in comments
Documentation: bindings: add doc for the USB2 ChipIdea USB driver
usb: chipidea: add a usb2 driver for ci13xxx
usb: chipidea: fix phy handling
usb: chipidea: remove duplicate dev_set_drvdata for host_start
usb: chipidea: parameter 'mode' isn't needed for hw_device_reset
usb: chipidea: add controller reset API
usb: chipidea: remove flag CI_HDRC_REQUIRE_TRANSCEIVER
...
09 Dec, 2014
1 commit
-
* pm-runtime: (25 commits)
i2c-omap / PM: Drop CONFIG_PM_RUNTIME from i2c-omap.c
dmaengine / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
drivers: sh / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
e1000e / igb / PM: Eliminate CONFIG_PM_RUNTIME
MMC / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
MFD / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
misc / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
media / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
input / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
iio / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
hsi / OMAP / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
i2c-hid / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
drm / exynos / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
gpio / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
hwrandom / exynos / PM: Use CONFIG_PM in #ifdef
block / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
USB / PM: Drop CONFIG_PM_RUNTIME from the USB core
PM: Merge the SET*_RUNTIME_PM_OPS() macros
PM / Kconfig: Do not select PM directly from Kconfig files
PCI / PM: Drop CONFIG_PM_RUNTIME from the PCI core
...
04 Dec, 2014
1 commit
-
After commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is
selected) PM_RUNTIME is always set if PM is set, so quite a few
depend on CONFIG_PM (or even dropped in some cases).Replace CONFIG_PM_RUNTIME with CONFIG_PM in the USB core code
and documentation.Signed-off-by: Rafael J. Wysocki
Acked-by: Alan Stern
Acked-by: Greg Kroah-Hartman
03 Dec, 2014
2 commits
-
Endpoints halted on errors, and endpoints stopped manually both used
the same ep->stopped_td to store the halted or stopped td. this causes
confusion and possible races.There is no longer a need to use the ep->stopped_td variable to store
the halted TD. A halted endpoint is handled immediately and we can pass
it to the handling function directly.Signed-off-by: Mathias Nyman
Signed-off-by: Greg Kroah-Hartman -
If we need to change the max exit latency with a Evaluate Context
command, we copy the old output slot context and use it as input
context for the command. This also copies the dev_state bits which
are supposed to be zero in the input slot context.Signed-off-by: Mathias Nyman
Signed-off-by: Greg Kroah-Hartman
22 Nov, 2014
2 commits
-
When system is being suspended, if host device is not allowed to do wakeup,
xhci_suspend() needs to clear all root port wake on bits. Otherwise, some
platforms may generate spurious wakeup, even if PCI PME# is disabled.The initial commit ff8cbf250b44 ("xhci: clear root port wake on bits"),
which also got into stable, turned out to not work correctly and had to
be reverted, and is now rewritten.Cc: stable # v3.2+
Signed-off-by: Lu Baolu
Suggested-by: Alan Stern
Acked-by: Alan Stern
[Mathias Nyman: reword commit message]
Signed-off-by: Mathias Nyman
Signed-off-by: Greg Kroah-Hartman -
If a device is halted and reuturns a STALL, then the halted endpoint
needs to be cleared both on the host and device side. The host
side halt is cleared by issueing a xhci reset endpoint command. The device side
is cleared with a ClearFeature(ENDPOINT_HALT) request, which should
be issued by the device driver if a URB reruen -EPIPE.Previously we cleared the host side halt after the device side was cleared.
To make sure the host side halt is cleared in time we want to issue the
reset endpoint command immedialtely when a STALL status is encountered.Otherwise we end up not following the specs and not returning -EPIPE
several times in a row when trying to transfer data to a halted endpoint.Fixes: bcef3fd (USB: xhci: Handle errors that cause endpoint halts.)
Cc: # v2.6.33+
Tested-by: Felipe Balbi
Signed-off-by: Mathias Nyman
Signed-off-by: Greg Kroah-Hartman
04 Oct, 2014
4 commits
-
Instead of building all of the xHCI code into a single module, separate
it out into the core (xhci-hcd), PCI (xhci-pci, now selected by the new
config option CONFIG_USB_XHCI_PCI), and platform (xhci-plat) drivers.
Also update the PCI/platform drivers with module descriptions/licenses
and have them register their respective drivers in their initcalls.Signed-off-by: Andrew Bresticker
Signed-off-by: Mathias Nyman
Signed-off-by: Greg Kroah-Hartman -
In preparation for allowing the xHCI host controller drivers to be built
as separate modules, export symbols from the xHCI core that may be used
by the host controller drivers.Signed-off-by: Andrew Bresticker
Signed-off-by: Mathias Nyman
Signed-off-by: Greg Kroah-Hartman -
Instead of calling xhci_compliance_mode_recovery_timer_quirk_check() again
in the PCI suspend path, just check for XHCI_COMP_MODE_QUIRK which will
have been set based on xhci_compliance_mode_recovery_timer_quirk_check()
in xhci_init().Signed-off-by: Andrew Bresticker
Signed-off-by: Mathias Nyman
Signed-off-by: Greg Kroah-Hartman -
Since the struct hc_driver is mostly the same across the xhci-pci,
xhci-plat, and the upcoming xhci-tegra driver, introduce the function
xhci_init_driver() which will populate the hc_driver with the default
xHCI operations. The caller must supply a setup function which will
be used as the hc_driver's reset callback.Note that xhci-plat also overrides the default ->start() callback so
that it can do rcar-specific initialization.Signed-off-by: Andrew Bresticker
Signed-off-by: Mathias Nyman
Signed-off-by: Greg Kroah-Hartman
24 Sep, 2014
3 commits
-
USB hub has started to use a workqueue instead of kthread. Let's update
the documentation and comments here and there.This patch mostly just replaces "khubd" with "hub_wq". There are only few
exceptions where the whole sentence was updated. These more complicated
changes can be found in the following files:Documentation/usb/hotplug.txt
drivers/net/usb/usbnet.c
drivers/usb/core/hcd.c
drivers/usb/host/ohci-hcd.c
drivers/usb/host/xhci.cSigned-off-by: Petr Mladek
Acked-by: Alan Stern
Signed-off-by: Greg Kroah-Hartman -
V2 - Restart polling (which will restart the timer) for the shared
HCD in xhci_resume().xhci_suspend() will stop the primary HCD's root hub timer, but leaves
the shared HCD's timer running. This change adds stopping of the
shared HCD timer.Signed-off-by: Al Cooper
Signed-off-by: Mathias Nyman
Signed-off-by: Greg Kroah-Hartman -
There are multiple reasons for this:
1) This fixes a missing check for xhci_alloc_command failing in
xhci_handle_cmd_stop_ep()
2) This adds a warning when we cannot set the new dequeue state because of
xhci_alloc_command failing
3) It puts the allocation of the command after the sanity checks in
queue_set_tr_deq(), avoiding leaking the command if those fail
4) Since queue_set_tr_deq now owns the command it can free it if queue_command
fails
5) It reduces code duplicationSigned-off-by: Hans de Goede
Signed-off-by: Mathias Nyman
Signed-off-by: Greg Kroah-Hartman
12 Sep, 2014
1 commit
-
Resuming from hibernate (S4) will restart and re-initialize xHC.
The device contexts are freed and will be re-allocated later during device reset.Usb core will disable link pm in device resume before device reset, which will
try to change the max exit latency, accessing the device contexts before they are re-allocated.There is no need to zero (disable) the max exit latency when disabling hw lpm
for a freshly re-initialized xHC. So check that device context exists before
doing anything. The max exit latency will be set again after device reset when usb core
enables the link pm.Reported-by: Imre Deak
Tested-by: Imre Deak
Cc: stable
Signed-off-by: Mathias Nyman
Signed-off-by: Greg Kroah-Hartman
20 Aug, 2014
1 commit
-
When we manually need to move the TR dequeue pointer we need to set the
correct cycle bit as well. Previously we used the trb pointer from the
last event received as a base, but this was changed in
commit 1f81b6d22a59 ("usb: xhci: Prefer endpoint context dequeue pointer")
to use the dequeue pointer from the endpoint context insteadIt turns out some Asmedia controllers advance the dequeue pointer
stored in the endpoint context past the event triggering TRB, and
this messed up the way the cycle bit was calculated.Instead of adding a quirk or complicating the already hard to follow cycle bit
code, the whole cycle bit calculation is now simplified and adapted to handle
event and endpoint context dequeue pointer differences.Fixes: 1f81b6d22a59 ("usb: xhci: Prefer endpoint context dequeue pointer")
Reported-by: Maciej Puzio
Reported-by: Evan Langlois
Reviewed-by: Julius Werner
Tested-by: Maciej Puzio
Tested-by: Evan Langlois
Signed-off-by: Mathias Nyman
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman
02 Aug, 2014
2 commits
-
Signed-off-by: Hans de Goede
Signed-off-by: Greg Kroah-Hartman -
Streams on the EJ168 do not work as they should. I've spend 2 days trying
to get them to work, but without success.The first problem is that when ever you ring the stream-ring doorbell, the
controller starts executing trbs at the beginning of the first ring segment,
event if it ended somewhere else previously. This can be worked around by
allowing enqueing only one td (not a problem with how streams are typically
used) and then resetting our copies of the enqueueing en dequeueing pointers
on a td completion to match what the controller seems to be doing.This way things seem to start working with uas and instead of being able
to complete only the very first scsi command, the scsi core can probe the disk.But then things break later on when td-s get enqueued with more then one
trb. The controller does seem to increase its dequeue pointer while executing
a stream-ring (data transfer events I inserted for debugging do trigger).
However execution seems to stop at the final normal trb of a multi trb td,
even if there is a data transfer event inserted after the final trb.The first problem alone is a serious deviation from the spec, and esp.
dealing with cancellation would have been very tricky if not outright
impossible, but the second problem simply is a deal breaker altogether,
so this patch simply disables streams.Note this will cause the usb-storage + uas driver pair to automatically switch
to using usb-storage instead of uas on these devices, essentially reverting
to the 3.14 and earlier behavior when uas was marked CONFIG_BROKEN.https://bugzilla.redhat.com/show_bug.cgi?id=1121288
https://bugzilla.kernel.org/show_bug.cgi?id=80101Cc: stable@vger.kernel.org # 3.15
Signed-off-by: Hans de Goede
Signed-off-by: Greg Kroah-Hartman
10 Jul, 2014
2 commits
-
grep must work, not matter the line length.
Signed-off-by: Oliver Neukum
Signed-off-by: Greg Kroah-Hartman -
As best case, a host controller should support U0 to U1 switching for
the devices connected below any tier of hub level supported by usb
specification. Therefore xhci_check_tier_policy should always return
success as default implementation.A host should be able to issue LGO_Ux after the timeout calculated as
per definition of system exit latency defined in C.1.5.2. Therefore
xhci_calculate_ux_timeout returns ux_params.sel as the default
implementation.Use default calculation in absence of any vendor specific limitations.
Signed-off-by: Pratyush Anand
Tested-by: Aymen Bouattay
Signed-off-by: Mathias Nyman
Signed-off-by: Greg Kroah-Hartman
08 Jul, 2014
1 commit
-
We want the USB fixes in here as well.
Signed-off-by: Greg Kroah-Hartman
25 Jun, 2014
2 commits
-
The current XHCI driver recalculates the Context Entries field in the
Slot Context on every add_endpoint() and drop_endpoint() call. In the
case of drop_endpoint(), it seems to assume that the add_flags will
always contain every endpoint for the new configuration, which is not
necessarily correct if you don't make assumptions about how the USB core
uses the add_endpoint/drop_endpoint interface (add_flags only contains
endpoints that are new additions in the new configuration).Furthermore, EP0_FLAG is not consistently set in add_flags throughout
the lifetime of a device. This means that when all endpoints are
dropped, the Context Entries field can be set to 0 (which is invalid and
may cause a Parameter Error) or -1 (which is interpreted as 31 and
causes the driver to keep using the old, incorrect value).The only surefire way to set this field right is to also take all
existing endpoints into account, and to force the value to 1 (meaning
only EP0 is active) if no other endpoint is found. This patch implements
that as a single step in the final check_bandwidth() call and removes
the intermediary calculations from add_endpoint() and drop_endpoint().Signed-off-by: Julius Werner
Signed-off-by: Mathias Nyman
Signed-off-by: Greg Kroah-Hartman -
The system suspend flow as following:
1, Freeze all user processes and kenrel threads.2, Try to suspend all devices.
2.1, If pci device is in RPM suspended state, then pci driver will try
to resume it to RPM active state in the prepare stage.2.2, xhci_resume function calls usb_hcd_resume_root_hub to queue two
workqueue items to resume usb2&usb3 roothub devices.2.3, Call suspend callbacks of devices.
2.3.1, All suspend callbacks of all hcd's children, including
roothub devices are called.2.3.2, Finally, hcd_pci_suspend callback is called.
Due to workqueue threads were already frozen in step 1, the workqueue
items can't be scheduled, and the roothub devices can't be resumed in
this flow. The HCD_FLAG_WAKEUP_PENDING flag which is set in
usb_hcd_resume_root_hub won't be cleared. Finally,
hcd_pci_suspend will return -EBUSY, and system suspend fails.The reason why this issue doesn't show up very often is due to that
choose_wakeup will be called in step 2.3.1. In step 2.3.1, if
udev->do_remote_wakeup is not equal to device_may_wakeup(&udev->dev), then
udev will resume to RPM active for changing the wakeup settings. This
has been a lucky hit which hides this issue.For some special xHCI controllers which have no USB2 port, then roothub
will not match hub driver due to probe failed. Then its
do_remote_wakeup will be set to zero, and we won't be as lucky.xhci driver doesn't need to resume roothub devices everytime like in
the above case. It's only needed when there are pending event TRBs.This patch should be back-ported to kernels as old as 3.2, that
contains the commit f69e3120df82391a0ee8118e0a156239a06b2afb
"USB: XHCI: resume root hubs when the controller resumes"Cc: stable@vger.kernel.org # 3.2
Signed-off-by: Wang, Yu
Acked-by: Alan Stern
[use readl() instead of removed xhci_readl(), reword commit message -Mathias]
Signed-off-by: Mathias Nyman
Signed-off-by: Greg Kroah-Hartman
20 May, 2014
7 commits
-
Use one timer to control command timeout.
start/kick the timer every time a command is completed and a
new command is waiting, or a new command is added to a empty list.If the timer runs out, then tag the current command as "aborted", and
start the xhci command abortion process.Previously each function that submitted a command had its own timer.
If that command timed out, a new command structure for the
command was created and it was put on a cancel_cmd_list list,
then a pci write to abort the command ring was issued.when the ring was aborted, it checked if the current command
was the one to be canceled, later when the ring was stopped the
driver got ownership of the TRBs in the command ring,
compared then to the TRBs in the cancel_cmd_list,
and turned them into No-ops.Now, instead, at timeout we tag the status of the command in the
command queue to be aborted, and start the ring abortion.
Ring abortion stops the command ring and gives control of the
commands to us.
All the aborted commands are now turned into No-ops.If the ring is already stopped when the command times outs its not possible
to start the ring abortion, in this case the command is turnd to No-op
right away.All these changes allows us to remove the entire cancel_cmd_list code.
The functions waiting for a command to finish no longer have their own timeouts.
They will wait either until the command completes normally,
or until the whole command abortion is done.Signed-off-by: Mathias Nyman
Signed-off-by: Greg Kroah-Hartman -
Remove the per-device command list and handle_cmd_in_cmd_wait_list()
and use the completion and status variables found in the
command structure in the global command list.Signed-off-by: Mathias Nyman
Signed-off-by: Greg Kroah-Hartman -
Create a list to store command structures, add a structure to it every time
a command is submitted, and remove it from the list once we get a
command completion event matching the command.Callers that wait for completion will free their command structures themselves.
The other command structures are freed in the command completion event handler.Also add a check that prevents queuing commands if host is dying
Signed-off-by: Mathias Nyman
Signed-off-by: Greg Kroah-Hartman -
To create a global command queue we require that each command put on the
command ring is submitted with a command structure.Functions that queue commands and wait for completion need to allocate a command
before submitting it, and free it once completed. The following command queuing
functions need to be modified.xhci_configure_endpoint()
xhci_address_device()
xhci_queue_slot_control()
xhci_queue_stop_endpoint()
xhci_queue_new_dequeue_state()
xhci_queue_reset_ep()
xhci_configure_endpoint()xhci_configure_endpoint() could already be called with a command structure,
and only xhci_check_maxpacket and xhci_check_bandwidth did not do so. These
are changed and a command structure is now required. This change also simplifies
the configure endpoint command completion handling and the "goto bandwidth_change"
handling code can be removed.In some cases the command queuing function is called in interrupt context.
These commands needs to be allocated atomically, and they can't wait for
completion. These commands will in this patch be freed directly after queuing,
but freeing will be moved to the command completion event handler in a later
patch once we get the global command queue up.(Just so that we won't leak
memory in the middle of the patch set)Signed-off-by: Mathias Nyman
Signed-off-by: Greg Kroah-Hartman -
xHCI host controllers may only support a limited number of device slot
IDs, which is usually far less than the theoretical maximum number of
devices (255) that the USB specifications advertise. This is
frustrating to consumers that expect to be able to plug in a large
number of devices.Add a print statement when the Enable Slot command fails to show how
many devices the host supports. We can't change hardware manufacturer's
design decisions, but hopefully we can save customers a little bit of
time trying to debug why their host mysteriously fails when too many
devices are plugged in.Signed-off-by: Sarah Sharp
Reported-by: Amund Hov
Signed-off-by: Mathias Nyman
Signed-off-by: Greg Kroah-Hartman -
As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range() or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.Signed-off-by: Alexander Gordeev
Cc: Sarah Sharp
Cc: Greg Kroah-Hartman
Cc: linux-usb@vger.kernel.org
Cc: linux-pci@vger.kernel.org
Signed-off-by: Mathias Nyman
Signed-off-by: Greg Kroah-Hartman -
This patch fix wrong port number reported when trying to enable/disable
USB2.0 hardware LPM.Signed-off-by: Lin Wang
Signed-off-by: Mathias Nyman
Signed-off-by: Greg Kroah-Hartman
26 Apr, 2014
2 commits
-
When CONFIG_PCI and CONFIG_PM are not selected, xhci.c gets this
warning:
drivers/usb/host/xhci.c:409:13: warning: ‘xhci_msix_sync_irqs’ defined
but not used [-Wunused-function]Instead of creating nested #ifdefs, this patch fixes it by defining the
xHCI PCI stubs as inline.This warning has been in since 3.2 kernel and was
caused by commit 421aa841a134f6a743111cf44d0c6d3b45e3cf8c
"usb/xhci: hide MSI code behind PCI bars", but wasn't noticed
until 3.13 when a configuration with these options was triedSigned-off-by: David Cohen
Cc: stable@vger.kernel.org # 3.2
Signed-off-by: Mathias Nyman
Signed-off-by: Greg Kroah-Hartman -
We have observed a rare cycle state desync bug after Set TR Dequeue
Pointer commands on Intel LynxPoint xHCs (resulting in an endpoint that
doesn't fetch new TRBs and thus an unresponsive USB device). It always
triggers when a previous Set TR Dequeue Pointer command has set the
pointer to the final Link TRB of a segment, and then another URB gets
enqueued and cancelled again before it can be completed. Further
investigation showed that the xHC had returned the Link TRB in the TRB
Pointer field of the Transfer Event (CC == Stopped -- Length Invalid),
but when xhci_find_new_dequeue_state() later accesses the Endpoint
Context's TR Dequeue Pointer field it is set to the first TRB of the
next segment.The driver expects those two values to be the same in this situation,
and uses the cycle state of the latter together with the address of the
former. This should be fine according to the XHCI specification, since
the endpoint ring should be stopped when returning the Transfer Event
and thus should not advance over the Link TRB before it gets restarted.
However, real-world XHCI implementations apparently don't really care
that much about these details, so the driver should follow a more
defensive approach to try to work around HC spec violations.This patch removes the stopped_trb variable that had been used to store
the TRB Pointer from the last Transfer Event of a stopped TRB. Instead,
xhci_find_new_dequeue_state() now relies only on the Endpoint Context,
requiring a small amount of additional processing to find the virtual
address corresponding to the TR Dequeue Pointer. Some other parts of the
function were slightly rearranged to better fit into this model.This patch should be backported to kernels as old as 2.6.31 that contain
the commit ae636747146ea97efa18e04576acd3416e2514f5 "USB: xhci: URB
cancellation support."Signed-off-by: Julius Werner
Cc: stable@vger.kernel.org
Signed-off-by: Mathias Nyman
Signed-off-by: Greg Kroah-Hartman
13 Mar, 2014
1 commit
-
We want the USB fixes in here as well.
08 Mar, 2014
1 commit
-
This reverts commit 247bf557273dd775505fb9240d2d152f4f20d304.
This commit, together with commit 3804fad45411b48233b48003e33a78f290d227c8
"USBNET: ax88179_178a: enable tso if usb host supports sg dma" were
origially added to get xHCI 1.0 hosts and usb ethernet ax88179_178a devices
working together with scatter gather. xHCI 1.0 hosts pose some requirement on how transfer
buffers are aligned, setting this requirement for 1.0 hosts caused USB 3.0 mass
storage devices to fail more frequently.USB 3.0 mass storage devices used to work before 3.14-rc1. Theoretically,
the TD fragment rules could have caused an occasional disk glitch.
Now the devices *will* fail, instead of theoretically failing.
>From a user perspective, this looks like a regression; the USB device obviously
fails on 3.14-rc1, and may sometimes silently fail on prior kernels.The proper soluition is to implement the TD fragment rules required, but for now
this patch needs to be reverted to get USB 3.0 mass storage devices working at the
level they used to.Signed-off-by: Mathias Nyman
Cc: stable
Signed-off-by: Greg Kroah-Hartman
07 Mar, 2014
1 commit
-
When some xHCI host controllers fall back to use the legacy IRQ,
the member irq_descr of the usb_hcd structure will be empty. This
leads to the empty string of the xHCI host controller in
/proc/interrupts. Here is the example (The irq 19 is the xHCI host
controller):CPU0
0: 91 IO-APIC-edge timer
8: 1 IO-APIC-edge rtc0
9: 7191 IO-APIC-fasteoi acpi
18: 104 IR-IO-APIC-fasteoi ehci_hcd:usb1, ehci_hcd:usb2
19: 473 IR-IO-APIC-fasteoiAfter applying the patch, the name of the registered xHCI host
controller can be displayed correctly. Here is the example:CPU0
0: 91 IO-APIC-edge timer
8: 1 IO-APIC-edge rtc0
9: 7191 IO-APIC-fasteoi acpi
18: 104 IR-IO-APIC-fasteoi ehci_hcd:usb1, ehci_hcd:usb2
19: 473 IR-IO-APIC-fasteoi xhci_hcd:usb3Tested on v3.14-rc4.
Signed-off-by: Adrian Huang
Reviewed-by: Nagananda Chumbalkar
Signed-off-by: Sarah Sharp
05 Mar, 2014
3 commits
-
Signed-off-by: Hans de Goede
Signed-off-by: Sarah Sharp -
The ss_ep_comp bmAttributes filed can contain more info then just the
streams, use usb_ss_max_streams to properly get max streams.Signed-off-by: Hans de Goede
Signed-off-by: Sarah Sharp -
And warn about this, as that would be a driver bug.
Like wise drivers should ensure that streams are properly free-ed before a
device is reset. So lets warn about that too. This already causes warnings
in the form of:[ 96.982398] xhci_hcd 0000:01:00.0: WARN Can't disable streams for endpoint 0x81
, streams are already disabled!
[ 96.982400] xhci_hcd 0000:01:00.0: WARN xhci_free_streams() called with non-streams endpointBut it is better to also warn about the actual cause of this later warnings.
Signed-off-by: Hans de Goede
Signed-off-by: Sarah Sharp
08 Feb, 2014
1 commit
-
This reverts commit f2d9b991c549f159dc9ae81f77d8206c790cbfee.
We are ripping out commit 35773dac5f862cb1c82ea151eba3e2f6de51ec3e "usb:
xhci: Link TRB must not occur within a USB payload burst" because it's a
hack that caused regressions in the usb-storage and userspace USB
drivers that use usbfs and libusb. This commit attempted to fix the
issues with that patch.Signed-off-by: Sarah Sharp
Cc: stable@vger.kernel.org #3.12