Set the controller speed to HCD_USB31 to if host hardware supports USB 3.1
For PCI xhci controllers the USB 3.1 support is checked from SBRN bits in
pci config space. Platform controllers will need to set xhci->sbrn == 0x31
to indicate USB 3.1 support before calling xhci_gen_setup().
Also make sure xhci driver works correctly with speed set to HCD_USB31
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
USB 3.1 capable xhci controllers use a new default speed ID "5" in the
PORTSC register to represent a 10Gbps connection speed of a SuperSpeedPlus
device
Make sure the xhci driver can handle the returned SuperSpeedPlus speed ID
properly
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Some changes between xhci 0.96 and xhci 1.0 specifications forced us to
check the hci version in code, some of these checks were implemented as
hci_version == 1.0, which will not work with new xhci 1.1 controllers.
xhci 1.1 behaves similar to xhci 1.0 in these cases, so change these
checks to hci_version >= 1.0
Cc: <stable@vger.kernel.org>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
We want to give the command abortion an additional try to stop
the command ring before we completely hose xhci.
Cc: <stable@vger.kernel.org>
Tested-by: Vincent Pelletier <plr.vincent@gmail.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch enables xhci driver to support SPC by handling
Stopped - Short Packet event in transfer event path.
If SPC = '1' and the stop endpoint command is executed, after a Short
Packet condition has been detected, but before the end of the TD has been
reached, (i.e. the TD is in progress for pipe), then a Transfer Event TRB
with its Completion Code set to Stopped - Short Packet and its TRB
Transfer Length set to value of the EDTLA shall be forced for the
interrupted TRB, irrespective of whether its IOC or ISP flags are set.
This Transfer Event TRB will precede the Command Completion Event TRB for
the command, and is referred to as a Stopped Transfer Event.
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If the Contiguous Frame ID Capability is supported (CFC = 1),
then the xHC shall match the Frame ID in every Isoch TD with
SIA = 0 against the Frame Index of the MFINDEX register. This
rule ensures resynchronization of Isoch TDs even if some are
dropped due to Missed Service Errors or Stopping the endpoint.
This patch enables xHCI driver to support CFC by calculating
and setting the Frame ID field of an Isoch TRB.
[made some dbg messages checkpatch friendly -Mathias]
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This commit checks for the URB_ZERO_PACKET flag and creates an extra
zero-length td if the urb transfer length is a multiple of the endpoint's
max packet length.
Signed-off-by: Reyad Attiyat <reyad.attiyat@gmail.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
We need to check that a TRB is part of the current segment
before calculating its DMA address.
Previously a ring segment didn't use a full memory page, and every
new ring segment got a new memory page, so the off by one
error in checking the upper bound was never seen.
Now that we use a full memory page, 256 TRBs (4096 bytes), the off by one
didn't catch the case when a TRB was the first element of the next segment.
This is triggered if the virtual memory pages for a ring segment are
next to each in increasing order where the ring buffer wraps around and
causes errors like:
[ 106.398223] xhci_hcd 0000:00:14.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 0 comp_code 1
[ 106.398230] xhci_hcd 0000:00:14.0: Looking for event-dma fffd3000 trb-start fffd4fd0 trb-end fffd5000 seg-start fffd4000 seg-end fffd4ff0
The trb-end address is one outside the end-seg address.
Cc: <stable@vger.kernel.org>
Tested-by: Arkadiusz Miśkiewicz <arekm@maven.pl>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When the link is just waken, it's in Resume state, and driver sets PLS to
U0. This refers to Phase 1. Phase 2 refers to when the link has completed
the transition from Resume state to U0.
With the fix of xhci: report U3 when link is in resume state, it also
exposes an issue that usb3 roothub and controller can suspend right
after phase 1, and this causes a hard hang in controller.
To fix the issue, we need to prevent usb3 bus suspend if any port is
resuming in phase 1.
[merge separate USB2 and USB3 port resume checking to one -Mathias]
Cc: <stable@vger.kernel.org>
Signed-off-by: Zhuang Jin Can <jin.can.zhuang@intel.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fix the xhci driver from bluntly setting the transferred length to 0 if
we get a STALL on anything else than the data stage of a control transfer.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The problem seems to be that if a new device is detected
while we have already removed the shared HCD, then many of the
xhci operations (e.g. xhci_alloc_dev(), xhci_setup_device())
hang as command never completes.
I don't think XHCI can operate without the shared HCD as we've
already called xhci_halt() in xhci_only_stop_hcd() when shared HCD
goes away. We need to prevent new commands from being queued
not only when HCD is dying but also when HCD is halted.
The following lockup was detected while testing the otg state
machine.
[ 178.199951] xhci-hcd xhci-hcd.0.auto: xHCI Host Controller
[ 178.205799] xhci-hcd xhci-hcd.0.auto: new USB bus registered, assigned bus number 1
[ 178.214458] xhci-hcd xhci-hcd.0.auto: hcc params 0x0220f04c hci version 0x100 quirks 0x00010010
[ 178.223619] xhci-hcd xhci-hcd.0.auto: irq 400, io mem 0x48890000
[ 178.230677] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[ 178.237796] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 178.245358] usb usb1: Product: xHCI Host Controller
[ 178.250483] usb usb1: Manufacturer: Linux 4.0.0-rc1-00024-g6111320 xhci-hcd
[ 178.257783] usb usb1: SerialNumber: xhci-hcd.0.auto
[ 178.267014] hub 1-0:1.0: USB hub found
[ 178.272108] hub 1-0:1.0: 1 port detected
[ 178.278371] xhci-hcd xhci-hcd.0.auto: xHCI Host Controller
[ 178.284171] xhci-hcd xhci-hcd.0.auto: new USB bus registered, assigned bus number 2
[ 178.294038] usb usb2: New USB device found, idVendor=1d6b, idProduct=0003
[ 178.301183] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 178.308776] usb usb2: Product: xHCI Host Controller
[ 178.313902] usb usb2: Manufacturer: Linux 4.0.0-rc1-00024-g6111320 xhci-hcd
[ 178.321222] usb usb2: SerialNumber: xhci-hcd.0.auto
[ 178.329061] hub 2-0:1.0: USB hub found
[ 178.333126] hub 2-0:1.0: 1 port detected
[ 178.567585] dwc3 48890000.usb: usb_otg_start_host 0
[ 178.572707] xhci-hcd xhci-hcd.0.auto: remove, state 4
[ 178.578064] usb usb2: USB disconnect, device number 1
[ 178.586565] xhci-hcd xhci-hcd.0.auto: USB bus 2 deregistered
[ 178.592585] xhci-hcd xhci-hcd.0.auto: remove, state 1
[ 178.597924] usb usb1: USB disconnect, device number 1
[ 178.603248] usb 1-1: new high-speed USB device number 2 using xhci-hcd
[ 190.597337] INFO: task kworker/u4:0:6 blocked for more than 10 seconds.
[ 190.604273] Not tainted 4.0.0-rc1-00024-g6111320 #1058
[ 190.610228] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 190.618443] kworker/u4:0 D c05c0ac0 0 6 2 0x00000000
[ 190.625120] Workqueue: usb_otg usb_otg_work
[ 190.629533] [<c05c0ac0>] (__schedule) from [<c05c10ac>] (schedule+0x34/0x98)
[ 190.636915] [<c05c10ac>] (schedule) from [<c05c1318>] (schedule_preempt_disabled+0xc/0x10)
[ 190.645591] [<c05c1318>] (schedule_preempt_disabled) from [<c05c23d0>] (mutex_lock_nested+0x1ac/0x3fc)
[ 190.655353] [<c05c23d0>] (mutex_lock_nested) from [<c046cf8c>] (usb_disconnect+0x3c/0x208)
[ 190.664043] [<c046cf8c>] (usb_disconnect) from [<c0470cf0>] (_usb_remove_hcd+0x98/0x1d8)
[ 190.672535] [<c0470cf0>] (_usb_remove_hcd) from [<c0485da8>] (usb_otg_start_host+0x50/0xf4)
[ 190.681299] [<c0485da8>] (usb_otg_start_host) from [<c04849a4>] (otg_set_protocol+0x5c/0xd0)
[ 190.690153] [<c04849a4>] (otg_set_protocol) from [<c0484b88>] (otg_set_state+0x170/0xbfc)
[ 190.698735] [<c0484b88>] (otg_set_state) from [<c0485740>] (otg_statemachine+0x12c/0x470)
[ 190.707326] [<c0485740>] (otg_statemachine) from [<c0053c84>] (process_one_work+0x1b4/0x4a0)
[ 190.716162] [<c0053c84>] (process_one_work) from [<c00540f8>] (worker_thread+0x154/0x44c)
[ 190.724742] [<c00540f8>] (worker_thread) from [<c0058f88>] (kthread+0xd4/0xf0)
[ 190.732328] [<c0058f88>] (kthread) from [<c000e810>] (ret_from_fork+0x14/0x24)
[ 190.739898] 5 locks held by kworker/u4:0/6:
[ 190.744274] #0: ("%s""usb_otg"){.+.+.+}, at: [<c0053bf4>] process_one_work+0x124/0x4a0
[ 190.752799] #1: ((&otgd->work)){+.+.+.}, at: [<c0053bf4>] process_one_work+0x124/0x4a0
[ 190.761326] #2: (&otgd->fsm.lock){+.+.+.}, at: [<c048562c>] otg_statemachine+0x18/0x470
[ 190.769934] #3: (usb_bus_list_lock){+.+.+.}, at: [<c0470ce8>] _usb_remove_hcd+0x90/0x1d8
[ 190.778635] #4: (&dev->mutex){......}, at: [<c046cf8c>] usb_disconnect+0x3c/0x208
[ 190.786700] INFO: task kworker/1:0:14 blocked for more than 10 seconds.
[ 190.793633] Not tainted 4.0.0-rc1-00024-g6111320 #1058
[ 190.799567] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 190.807783] kworker/1:0 D c05c0ac0 0 14 2 0x00000000
[ 190.814457] Workqueue: usb_hub_wq hub_event
[ 190.818866] [<c05c0ac0>] (__schedule) from [<c05c10ac>] (schedule+0x34/0x98)
[ 190.826252] [<c05c10ac>] (schedule) from [<c05c4e40>] (schedule_timeout+0x13c/0x1ec)
[ 190.834377] [<c05c4e40>] (schedule_timeout) from [<c05c19f0>] (wait_for_common+0xbc/0x150)
[ 190.843062] [<c05c19f0>] (wait_for_common) from [<bf068a3c>] (xhci_setup_device+0x164/0x5cc [xhci_hcd])
[ 190.852986] [<bf068a3c>] (xhci_setup_device [xhci_hcd]) from [<c046b7f4>] (hub_port_init+0x3f4/0xb10)
[ 190.862667] [<c046b7f4>] (hub_port_init) from [<c046eb64>] (hub_event+0x704/0x1018)
[ 190.870704] [<c046eb64>] (hub_event) from [<c0053c84>] (process_one_work+0x1b4/0x4a0)
[ 190.878919] [<c0053c84>] (process_one_work) from [<c00540f8>] (worker_thread+0x154/0x44c)
[ 190.887503] [<c00540f8>] (worker_thread) from [<c0058f88>] (kthread+0xd4/0xf0)
[ 190.895076] [<c0058f88>] (kthread) from [<c000e810>] (ret_from_fork+0x14/0x24)
[ 190.902650] 5 locks held by kworker/1:0/14:
[ 190.907023] #0: ("usb_hub_wq"){.+.+.+}, at: [<c0053bf4>] process_one_work+0x124/0x4a0
[ 190.915454] #1: ((&hub->events)){+.+.+.}, at: [<c0053bf4>] process_one_work+0x124/0x4a0
[ 190.924070] #2: (&dev->mutex){......}, at: [<c046e490>] hub_event+0x30/0x1018
[ 190.931768] #3: (&port_dev->status_lock){+.+.+.}, at: [<c046eb50>] hub_event+0x6f0/0x1018
[ 190.940558] #4: (&bus->usb_address0_mutex){+.+.+.}, at: [<c046b458>] hub_port_init+0x58/0xb10
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If the xHCI host controller has died (ie, device removed) or suffered
other serious fatal error (STS_FATAL), then xhci_irq should handle this
condition with IRQ_HANDLED instead of -ESHUTDOWN.
Signed-off-by: Joe Lawrence <joe.lawrence@stratus.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Isoc TDs usually consist of one TRB, sometimes two. When all goes well we
receive only one success event for a TD, and move the dequeue pointer to
the next TD.
This fails if the TD consists of two TRBs and we get a transfer error
on the first TRB, we will then see two events for that TD.
Fix this by making sure the event we get is for the last TRB in that TD
before moving the dequeue pointer to the next TD. This will resolve some
of the uvc and dvb issues with the
"ERROR Transfer event TRB DMA ptr not part of current TD" error message
Cc: <stable@vger.kernel.org>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This part 2 pull request contains only the patches
which make sure everybody on linux uses the same
resume timeout value.
Signed-off-by: Felipe Balbi <balbi@ti.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJVJEivAAoJEIaOsuA1yqREV6QP/1oJVdBxzOeQVXyGZsZT4k0E
T8SKmTIJmaCdSjgazSXAhqF7IR992sTM7urHZ2hww3tftODNVHvfFkgDlSguHwkr
GV95YpNv99ash7spjod3xVOt8lDvrt6FHs7Foj4b0yQZ1yXUZsOH4j8G4gMYOgTd
bq1mO2/NaaM7xiddzPMCGpSkL6NcsWrurJ8JiOlBXaUIkSR+Cwe9+8vzEDrxfSM+
6yBTLQCdvR0ammqV0YMNsF9dGLO8yiDotC6b104i3yCqpAZnyj0RJQ3riH7ESxsG
eSKkCXXGY0OWDGDcnWTskYEHJ7iDfg5MrlzBJyneMjauGKNeIoJRRYWP/f6NSV9m
GHxRV1ITKC61Dtt3w+Oy2a16UpAbq7/w1q/SkQl4YtJ8l0P1PUb+TfOZpTOsCLLF
cLXUKJufGWhuGbo+e2m6GizNCsDi5LlfdZcjIjVKRXpyiZI0peqyGj16mTm70UUY
/A9nsLtE7c6bqHMTcFQFRx4d2iHmkilyzQqOvx4ulo1rovNMafgmZJF7Kq0LY7ZO
Uj4s2rEAjqbELbOiEIf8HzGP+J/QuECG4SHyPEQsiG0drYyoCOqGR1S3kV7aJgFz
krl4zTvXR8EOk2IpPa8PDzmMr7YCYzlXOxzmSoJiZhqqpLH7cHYkDiRTmyxn+eB3
lEjEzBA8J9CG4iRIFjk3
=RqsO
-----END PGP SIGNATURE-----
Merge tag 'usb-for-v4.1-part2' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-testing
Felipe writes:
usb: generic resume timeout for v4.1
This part 2 pull request contains only the patches
which make sure everybody on linux uses the same
resume timeout value.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Make sure we're using the new macro, so our
resume signaling will always pass certification.
Cc: <stable@vger.kernel.org> # v3.10+
Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Some toggling operation in xHCI driver still use conditional toggling:
ring->cycle_state = (ring->cycle_state ? 0 : 1);
Use XOR to invert the cycle state instead of a conditional toggle to unify
cycle state toggling operation in xHCI driver.
Signed-off-by: Lin Wang <lin.x.wang@intel.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This reverts commit 27082e2654 ("xhci: Clear the host side toggle manually")
Turns out this fix to enable soft resetting endpoints wasn't mature enough.
It caused regression with some usb DVB-T devices and needs some more tuning
to get the endpiont ring pointers set correctly.
The original commit was tagged for stable 3.18, and should be reverted
from there as well.
Cc: stable <stable@vger.kernel.org> # v3.18
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When a control transfer has a short data stage, the xHCI controller generates
two transfer events: a COMP_SHORT_TX event that specifies the untransferred
amount, and a COMP_SUCCESS event. But when the data stage is not short, only the
COMP_SUCCESS event occurs. Therefore, xhci-hcd must set urb->actual_length to
urb->transfer_buffer_length while processing the COMP_SUCCESS event, unless
urb->actual_length was set already by a previous COMP_SHORT_TX event.
The driver checks this by seeing whether urb->actual_length == 0, but this alone
is the wrong test, as it is entirely possible for a short transfer to have an
urb->actual_length = 0.
This patch changes the xhci driver to rely on a new td->urb_length_set flag,
which is set to true when a COMP_SHORT_TX event is received and the URB length
updated at that stage.
This fixes a bug which affected the HSO plugin, which relies on URBs with
urb->actual_length == 0 to halt re-submitting the RX URB in the control
endpoint.
Cc: <stable@vger.kernel.org>
Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Main benefit of this is to get xhci connected USB scanners to work.
Some devices use a clear endpoint halt request as a 'soft reset' even if
the endpoint is not halted. This will clear the toggle and sequence on the
device side. xHCI however refuses to reset a non-halted endpoint, so instead
we need to issue a configure endpoint command on xHCI to clear its host side
toggle and sequence, and get it in sync with the device side.
Tested-by: Mike Mammarella <mikem@crystalorb.net>
Cc: <stable@vger.kernel.org> # v3.18
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Helps debugging to know the unhandled event type.
Also make the debug message grepable
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Some parameters are not used by functions in xhci-mem.c, just
remove it.
Changes compared to v1:
- Rebase to the latest usb-next branch
Signed-off-by: Lin Wang <lin.x.wang@intel.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Parameter 'xhci' is no longer be used in function xhci_handshake(),
just remove it.
Signed-off-by: Lin Wang <lin.x.wang@intel.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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 <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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: <stable@vger.kernel.org> # v2.6.33+
Tested-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
A halted endpoint ring must first be reset, then move the ring
dequeue pointer past the problematic TRB. If we start the ring too
early after reset, but before moving the dequeue pointer we
will end up executing the same problematic TRB again.
As we always issue a set transfer dequeue command after a reset
endpoint command we can skip starting endpoint rings at reset endpoint
command completion.
Without this fix we end up trying to handle the same faulty TD for
contol endpoints. causing timeout, and failing testusb ctrl_out write
tests.
Fixes: e9df17e (USB: xhci: Correct assumptions about number of rings per endpoint.)
Cc: <stable@vger.kernel.org> #v2.6.35
Tested-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Lately (with the use of uas / bulk-streams) we have been seeing several
cases where this error triggers (which should never happen).
Add some extra logging to make debugging these errors easier.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Even though a Set TR deq ptr command operates on a ring, and an endpoint
can have multiple rings, we can have only one Set TR deq ptr command pending.
When an endpoint with streams halts or is stopped to unlink urbs, there
will only be at most one ring active / one td being executed (the td
stopped_td points to).
So when we reset the endpoint (for a halt), or the stop command completes, we
will queue one Set TR deq ptr command at most, cancelled urbs on other stream
rings then the one being executed will have there trbs turned to nops, and
once the hcd gets around to execute that stream ring they will be simply
skipped.
So the SET_DEQ_PENDING flag in the endpoint is sufficient protection against
starting the endpoing before all stream rings are cleaned up.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Even if the stream for which the command was intended has been freed in the
mean time. This ensures that things start rolling again after an unlink / halt.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
xhci_queue_new_dequeue_state is the only caller of queue_set_tr_deq
and queue_set_tr_deq checks for SET_DEQ_PENDING, where as
xhci_queue_new_dequeue_state sets it which is inconsistent.
Simply fold the 2 into one is a nice cleanup and fixes the inconsistency.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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 duplication
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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 1f81b6d22a ("usb: xhci: Prefer endpoint context dequeue pointer")
to use the dequeue pointer from the endpoint context instead
It 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: 1f81b6d22a ("usb: xhci: Prefer endpoint context dequeue pointer")
Reported-by: Maciej Puzio <mx34567@gmail.com>
Reported-by: Evan Langlois <uudruid74@gmail.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: Maciej Puzio <mx34567@gmail.com>
Tested-by: Evan Langlois <uudruid74@gmail.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When using a Renesas uPD720231 chipset usb-3 uas to sata bridge with a 120G
Crucial M500 ssd, model string: Crucial_ CT120M500SSD1, together with a
the integrated Intel xhci controller on a Haswell laptop:
00:14.0 USB controller [0c03]: Intel Corporation 8 Series USB xHCI HC [8086:9c31] (rev 04)
The following error gets logged to dmesg:
xhci error: Transfer event TRB DMA ptr not part of current TD
Treating COMP_STOP the same as COMP_STOP_INVAL when no event_seg gets found
fixes this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The transfer burst count (TBC) field in xhci 1.0 hosts should be set
to the number of bursts needed to transfer all packets in a isoc TD.
Supported values are 0-2 (1 to 3 bursts per service interval).
Formula for TBC calculation is given in xhci spec section 4.11.2.3:
TBC = roundup( Transfer Descriptor Packet Count / Max Burst Size +1 ) - 1
This patch should be applied to stable kernels since 3.0 that contain
the commit 5cd43e33b9
"xhci 1.0: Set transfer burst count field."
Cc: stable@vger.kernel.org # 3.0
Suggested-by: ShiChun Ma <masc2008@qq.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Command completion events normally include command completion status,
SLOT_ID, and a pointer to the original command. Reset device command
completion SLOT_ID may be zero according to xhci specs 4.6.11.
VIA controllers set the SLOT_ID to zero, triggering a WARN_ON in the
command completion handler.
Use the SLOT ID found from the original command instead.
This patch should be applied to stable kernels since 3.13 that contain
the commit 20e7acb13f
"xhci: use completion event's slot id rather than dig it out of command"
Cc: stable@vger.kernel.org # 3.13
Reported-by: Saran Neti <sarannmr@gmail.com>
Tested-by: Saran Neti <sarannmr@gmail.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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 <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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 <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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 <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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 <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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 ae63674714 "USB: xhci: URB
cancellation support."
Signed-off-by: Julius Werner <jwerner@chromium.org>
Cc: stable@vger.kernel.org
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If the host controller stops responding to commands, we need to kill all
the URBs that were queued to all endpoints. The current code would only
kill URBs that had been queued to the endpoint rings. ep->ring is set
to NULL if streams has been enabled for the endpoint, which means URBs
submitted with a non-zero stream_id would never get killed. Fix this.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
In preparation for fixing this function for streams endpoints, refactor
code in the command watchdog timeout function into two new functions.
One kills all URBs on a ring (either stream or endpoint), the other
kills all URBs associated with an endpoint. Fix a split string while
we're at it.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
This fixes TR dequeue validation failing on Intel XHCI controllers with the
following warning:
Mismatch between completed Set TR Deq Ptr command & xHCI internal state.
Interestingly enough reading the deq ptr from the ep ctx after a
TR Deq Ptr command does work on a Nec XHCI controller, it seems the Nec
writes the ptr to both the ep and stream contexts when streams are used.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Nec XHCI controllers don't seem to care, but without this Intel XHCI
controllers reject Set TR dequeue commands with a COMP_TRB_ERR, leading
to the following warning:
WARN Set TR Deq Ptr cmd invalid because of stream ID configuration
And very shortly after this the system completely freezes.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
This changes debug messages and warnings in xhci-ring.c
to be on a single line so grep can find them. grep must
have precedence over the 80 column limit.
[Sarah fixed two checkpatch.pl issues with split lines
introduced by this commit.]
Signed-off-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
This reverts commit 35773dac5f. It's a
hack that caused regressions in the usb-storage and userspace USB
drivers that use usbfs and libusb. Commit 70cabb7d992f "xhci 1.0: Limit
arbitrarily-aligned scatter gather." should fix the issues seen with the
ax88179_178a driver on xHCI 1.0 hosts, without causing regressions.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org # 3.12
This reverts commit d6c9ea9069.
We are ripping out commit 35773dac5f "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 <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org # 3.12
This reverts commit e8b373326d. Many xHCI
host controllers can only handle 32-bit addresses, and writing 64-bits
at a time causes them to fail. Reading 64-bits at a time may also cause
them to return 0xffffffff, so revert this commit as well.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
This reverts commit 7dd09a1af2.
Many xHCI host controllers can only handle 32-bit addresses, and writing
64-bits at a time causes them to fail. Rafał reports that USB devices
simply do not enumerate, and reverting this patch helps. Branimir
reports that his host controller doesn't respond to an Enable Slot
command and dies:
[ 75.576160] xhci_hcd 0000:03:00.0: Timeout while waiting for a slot
[ 88.991634] xhci_hcd 0000:03:00.0: Stopped the command ring failed, maybe the host is dead
[ 88.991748] xhci_hcd 0000:03:00.0: Abort command ring failed
[ 88.991845] xhci_hcd 0000:03:00.0: HC died; cleaning up
[ 93.985489] xhci_hcd 0000:03:00.0: Timeout while waiting for a slot
[ 93.985494] xhci_hcd 0000:03:00.0: Abort the command ring, but the xHCI is dead.
[ 98.982586] xhci_hcd 0000:03:00.0: Timeout while waiting for a slot
[ 98.982591] xhci_hcd 0000:03:00.0: Abort the command ring, but the xHCI is dead.
[ 103.979696] xhci_hcd 0000:03:00.0: Timeout while waiting for a slot
[ 103.979702] xhci_hcd 0000:03:00.0: Abort the command ring, but the xHCI is dead
Signed-off-by: Sarah Sharp <sarah.a.sharp@intel.com>
Reported-by: Rafał Miłecki <zajec5@gmail.com>
Reported-by: Branimir Maksimovic <branimir.maksimovic@gmail.com>
Cc: Xenia Ragiadakou <burzalodowa@gmail.com>
Currently prepare_ring() returns -ENOMEM if the urb won't fit into a
single ring segment. usb_sg_wait() treats this error as a temporary
condition and will keep retrying until something else goes wrong.
The number of retries should be limited in usb_sg_wait(), but also
prepare_ring() should not return an error code that suggests it might
be worth retrying. Change it to -EINVAL.
Reported-by: jidanni@jidanni.org
References: http://bugs.debian.org/733907
Fixes: 35773dac5f ('usb: xhci: Link TRB must not occur within a USB payload burst')
Cc: stable <stable@vger.kernel.org> # 3.12
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Happy Holidays, Greg!
Here's four patches to be queued to usb-next for 3.14.
One adds a module parameter to the xHCI driver to allow users to enable
xHCI quirks without recompiling their kernel, which you've already said
is fine. The second patch is a bug fix for new usbtest code that's only
in usb-next. The third patch is simple cleanup.
The last patch is a non-urgent bug fix for xHCI platform devices. The
bug has been in the code since 3.9. You've been asking me to hold off
on non-urgent bug fixes after -rc4/-rc5, so it can go into usb-next, and
be backported to stable once 3.14 is out.
These have all been tested over the past week. I did run across one
oops, but it turned out to be a bug in 3.12, and therefore not related
to any of these patches.
Please queue these for usb-next and 3.14.
Thanks,
Sarah Sharp
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
iQIcBAABAgAGBQJStMtLAAoJEBMGWMLi1Gc5uxMQAIXOL38n53yfNETU+DJMLaWB
+DY/RJjJ0zAZuRL9emOvR+BYEsQpd2q6aT3F2MryjJT/dhEKwJgHLTLOv0EQEWS7
dfLXX/NKNI+iRNyJkSATriytWMmMwv13kTXkreu99ZAw2PWWt7mM4BPHaWJ6sz5G
MjWS3v6LE59zjZatdzZyg4wlgUeNmO8cc4CV8YSqv0rFiVrKBL8IJsxwgQkWXI+2
J19hZcEpgeVMPo7aPlkMGoS1Ze9SxTviALBVLBWwwR028UfWCELFWsSFGVfJ6RgJ
/3DsE+jhQBn/1Y1o6hrlU/arDj7N/iJ3Gz5Ru5l+BtJw56fdaI/ToaHzzIDarONE
DGLiziDIknlSPsuX6X81kqXqROz1Zt624aqLipvqGCk0FMrLZz5BMaPEslkmW4Wb
/TQRX6KnTVzK4uMjv5yNVaGtnyoTStJeRE7dIF4/9e2YDLo4SCmm2Y9necr4C3Ls
7FzT8t6m9F74ZHAkmPpKFlEkYTYOy3yv/KBlhHF/OVFo9FAxAwUEY69QVrvhaHVX
GhLANc4NOuJb1eIwQarVkub2+lLI3N9zwEWliepKKUTQ8OTFDkDFM/+bwDHd4RzD
PO23wuFHVLj9N2BZbIAV2OkDyJLU2FOl+ZiEG6NUDXssihiZj4AVfIRiOU1c3EMc
g27X+N4FI2fnpqvAYq/a
=PRbx
-----END PGP SIGNATURE-----
Merge tag 'for-usb-next-2013-12-20' of git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci into usb-next
Sarah writes:
xhci: Cleanups, non-urgent fixes for 3.14.
Happy Holidays, Greg!
Here's four patches to be queued to usb-next for 3.14.
One adds a module parameter to the xHCI driver to allow users to enable
xHCI quirks without recompiling their kernel, which you've already said
is fine. The second patch is a bug fix for new usbtest code that's only
in usb-next. The third patch is simple cleanup.
The last patch is a non-urgent bug fix for xHCI platform devices. The
bug has been in the code since 3.9. You've been asking me to hold off
on non-urgent bug fixes after -rc4/-rc5, so it can go into usb-next, and
be backported to stable once 3.14 is out.
These have all been tested over the past week. I did run across one
oops, but it turned out to be a bug in 3.12, and therefore not related
to any of these patches.
Please queue these for usb-next and 3.14.
Thanks,
Sarah Sharp
This patch remove unused variable 'addr' in inc_deq() and inc_enq().
Signed-off-by: Lin Wang <lin.x.wang@intel.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Change the default enumeration scheme for xhci attached non-SuperSpeed
devices from:
Reset
SetAddress [xhci address-device BSR = 0]
GetDescriptor(8)
GetDescriptor(18)
...to:
Reset
[xhci address-device BSR = 1]
GetDescriptor(64)
Reset
SetAddress [xhci address-device BSR = 0]
GetDescriptor(18)
...as some devices misbehave when encountering a SetAddress command
prior to GetDescriptor. There are known legacy devices that require
this scheme, but testing has found at least one USB3 device that fails
enumeration when presented with this ordering. For now, follow the ehci
case and enable 'new scheme' by default for non-SuperSpeed devices.
To support this enumeration scheme on xhci the AddressDevice operation
needs to be performed twice. The first instance of the command enables
the HC's device and slot context info for the device, but omits sending
the device a SetAddress command (BSR == block set address request).
Then, after GetDescriptor completes, follow up with the full
AddressDevice+SetAddress operation.
As mentioned before, this ordering of events with USB3 devices causes an
extra state transition to be exposed to xhci. Previously USB3 devices
would transition directly from 'enabled' to 'addressed' and never need
to underrun responses to 'get descriptor'. We do see the 64-byte
descriptor fetch the correct data, but the following 18-byte descriptor
read after the reset gets:
bLength = 0
bDescriptorType = 0
bcdUSB = 0
bDeviceClass = 0
bDeviceSubClass = 0
bDeviceProtocol = 0
bMaxPacketSize0 = 9
instead of:
bLength = 12
bDescriptorType = 1
bcdUSB = 300
bDeviceClass = 0
bDeviceSubClass = 0
bDeviceProtocol = 0
bMaxPacketSize0 = 9
which results in the discovery process looping until falling back to
'old scheme' enumeration.
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: David Moore <david.moore@gmail.com>
Suggested-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Function xhci_write_64() is used to write 64bit xHC registers residing in MMIO.
On 32bit systems, xHC registers need to be written with 32bit accesses by
writing first the lower 32bits and then the higher 32bits. The header file
asm-generic/io-64-nonatomic-lo-hi.h ensures that on 32bit systems writeq() will
will write 64bit registers in 32bit chunks with low-high order.
Replace all calls to xhci_write_64() with calls to writeq().
This is done to reduce code duplication since 64bit low-high write logic
is already implemented and to take advantage of inherent "atomic" 64bit
write operations on 64bit systems.
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Function xhci_read_64() is used to read 64bit xHC registers residing in MMIO.
On 32bit systems, xHC registers need to be read with 32bit accesses by
reading first the lower 32bits and then the higher 32bits.
Replace all calls to xhci_read_64() with calls to readq() and include
asm-generic/io-64-nonatomic-lo-hi.h header file, so that if the system
is not 64bit, readq() will read registers in 32bit chunks with low-high order.
This is done to reduce code duplication since 64bit low-high read logic
is already implemented and to take advantage of inherent "atomic" 64bit
read operations on 64bit systems.
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Function xhci_writel() is used to write a 32bit value in xHC registers residing
in MMIO address space. It takes as first argument a pointer to the xhci_hcd
although it does not use it. xhci_writel() internally simply calls writel().
This creates an illusion that xhci_writel() is an xhci specific function that
has to be called in a context where a pointer to xhci_hcd is available.
Remove xhci_writel() wrapper function and replace its calls with calls to
writel() to make the code more straight-forward.
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Function xhci_readl() is used to read 32bit xHC registers residing in MMIO
address space. It takes as first argument a pointer to the xhci_hcd although
it does not use it. xhci_readl() internally simply calls readl(). This creates
an illusion that xhci_readl() is an xhci specific function that has to be
called in a context where a pointer to xhci_hcd is available.
Remove the unnecessary xhci_readl() wrapper function and replace its calls to
with calls to readl() to make the code more straightforward.
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
This patch converts Event TRB's 3rd field, which has type le32, to CPU
byteorder before using it to retrieve the Slot ID with TRB_TO_SLOT_ID macro.
This bug was found using sparse.
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Section 4.11.7.1 of rev 1.0 of the xhci specification states that a link TRB
can only occur at a boundary between underlying USB frames (512 bytes for
high speed devices).
If this isn't done the USB frames aren't formatted correctly and, for example,
the USB3 ethernet ax88179_178a card will stop sending (while still receiving)
when running a netperf tcp transmit test with (say) and 8k buffer.
This should be a candidate for stable, the ax88179_178a driver defaults to
gso and tso enabled so it passes a lot of fragmented skb to the USB stack.
Notes from Sarah:
Discussion: http://marc.info/?l=linux-usb&m=138384509604981&w=2
This patch fixes a long-standing xHCI driver bug that was revealed by a
change in 3.12 in the usb-net driver. Commit
638c5115a7 "USBNET: support DMA SG" added
support to use bulk endpoint scatter-gather (urb->sg). Only the USB
ethernet drivers trigger this bug, because the mass storage driver sends
sg list entries in page-sized chunks.
This patch only fixes the issue for bulk endpoint scatter-gather. The
problem will still occur for periodic endpoints, because hosts will
interpret no-op transfers as a request to skip a service interval, which
is not what we want.
Luckily, the USB core isn't set up for scatter-gather on isochronous
endpoints, and no USB drivers use scatter-gather for interrupt
endpoints. Document this known limitation so that developers won't try
to use urb->sg for interrupt endpoints until this issue is fixed. The
more comprehensive fix would be to allow link TRBs in the middle of the
endpoint ring and revert this patch, but that fix would touch too much
code to be allowed in for stable.
This patch should be backported to kernels as old as 3.12, that contain
the commit 638c5115a7 "USBNET: support DMA
SG". Without this patch, the USB network device gets wedged, and stops
sending packets. Mark Lord confirms this patch fixes the regression:
http://marc.info/?l=linux-netdev&m=138487107625966&w=2
Signed-off-by: David Laight <david.laight@aculab.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Mark Lord <mlord@pobox.com>
Cc: stable@vger.kernel.org
Perform an unconditional toggle of the cycle bit with 'xor'.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
This patch replaces the 'event' argument of xhci_handle_cmd_set_deq() and
xhci_handle_cmd_reset_ep(), which is used to retrieve the command completion
status code, with the cmd_comp_code directly, since it is available.
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Since the Slot ID field in the command completion event matches the Slot ID
field in the associated command TRB for the Stop Endpoint, Set Dequeue Pointer
and Reset Endpoint commands, this patch adds in the handlers of their
completion events a 'slot_id' argument and removes the slot id calculation
in each of them.
Also, a WARN_ON() was added in case the slot ids reported by command TRB and
event TRB differ (although according to xhci spec rev1.0 that should not happen)
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
This patch replaces 'xhci->cmd_ring->dequeue' with 'trb', the address of
the command TRB, since it is available to reduce line length.
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
This patch adds a new variable 'cmd_type' to hold the command type so that
switch cases can be simplified by removing TRB_TYPE() macro improving
code readability.
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
This patch adds a new variable 'cmd_trb' to hold the address of the
command TRB, that is associated with the command completion event,
and to replace repetitions of xhci->cmd_ring->dequeue into the code.
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
This patch adds a new variable 'cmd_comp_code' to hold the command completion
status code aiming to reduce code duplication and to improve code readability.
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
The function that handles xHCI command completion is much too long and
there is need to be broken up into individual functions for each command
completion to improve code readablity.
This patch refactors the code in TRB_CONFIG_EP switch case, in
handle_cmd_completion(), into a fuction named xhci_handle_cmd_config_ep().
There were added two additional variables, 'add_flags' and 'drop_flags',
to reduce line length below 80 chars and improve code readability.
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
This patch removes the variable 'ep_ring' that is assigned in
TRB_CONFIG_EP switch case but never used.
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
The function that handles xHCI command completion is much too long and
there is need to be broken up into individual functions for each command
completion to improve code readablity.
This patch refactors the code in TRB_EVAL_CONTEXT switch case in
handle_cmd_completion() into a fuction named xhci_handle_cmd_eval_ctx().
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
The function that handles xHCI command completion is much too long and
there is need to be broken up into individual functions for each command
completion to improve code readablity.
This patch refactors the code in TRB_NEC_GET_FW switch case in
handle_cmd_completion() into a fuction named xhci_handle_cmd_nec_get_fw().
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
The function that handles xHCI command completion is much too long and
there is need to be broken up into individual functions for each command
completion to improve code readablity.
This patch refactors the code in TRB_RESET_DEV switch case in
handle_cmd_completion() into a fuction named xhci_handle_cmd_reset_dev().
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Since the slot id retrieved from the Reset Device TRB matches the slot id in
the command completion event, which is available, there is no need to determine
it again.
This patch removes the uneccessary reassignment to slot id and adds a WARN_ON
in case the two Slot ID fields differ (although according xhci spec rev1.0
they should not differ).
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
The function that handles xHCI command completion is much too long and
there is need to be broken up into individual functions for each command
completion to improve code readablity.
This patch refactors the code in TRB_ADDR_DEV switch case in
handle_cmd_completion() into a fuction named xhci_handle_cmd_addr_dev().
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
The function that handles xHCI command completion is much too long and
there is need to be broken up into individual functions for each command
completion to improve code readablity.
This patch refactors the code in TRB_DISABLE_SLOT switch case in
handle_cmd_completion() into a fuction named xhci_handle_cmd_disable_slot().
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
The function that handles xHCI command completion is much too long and
there is need to be broken up into individual functions for each command
completion to improve code readablity.
This patch refactors the code in TRB_ENABLE_SLOT switch case in
handle_cmd_completion() into a fuction named xhci_handle_cmd_enable_slot().
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
This patch renames the function handlers of a triggered Command Completion
Event that correspond to each command type into 'xhci_handle_cmd_<type>'.
That is done to give a consistent naming space to all the functions that
handle Command Completion Events and that will permit the code reader to
reference to them more easily.
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
This patch removes the "adjective" argument from xhci_giveback_urb_in_irq(),
since it is not used in the function anymore.
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
The halted state of a endpoint cannot be cleared over CLEAR_HALT from a
user process, because the stopped_td variable was overwritten in the
handle_stopped_endpoint() function. So the xhci_endpoint_reset() function will
refuse the reset and communication with device can not run over this endpoint.
https://bugzilla.kernel.org/show_bug.cgi?id=60699
Signed-off-by: Florian Wolter <wolly84@web.de>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
When a device signals remote wakeup on a roothub, and the suspend change
bit is set, the host controller driver must not give control back to the
USB core until the port goes back into the active state.
EHCI accomplishes this by waiting in the get port status function until
the PORT_RESUME bit is cleared:
/* stop resume signaling */
temp &= ~(PORT_RWC_BITS | PORT_SUSPEND | PORT_RESUME);
ehci_writel(ehci, temp, status_reg);
clear_bit(wIndex, &ehci->resuming_ports);
retval = ehci_handshake(ehci, status_reg,
PORT_RESUME, 0, 2000 /* 2msec */);
Similarly, the xHCI host should wait until the port goes into U0, before
passing control up to the USB core. When the port transitions from the
RExit state to U0, the xHCI driver will get a port status change event.
We need to wait for that event before passing control up to the USB
core.
After the port transitions to the active state, the USB core should time
a recovery interval before it talks to the device. The length of that
recovery interval is TRSMRCY, 10 ms, mentioned in the USB 2.0 spec,
section 7.1.7.7. The previous xHCI code (which did not wait for the
port to go into U0) would cause the USB core to violate that recovery
interval.
This bug caused numerous USB device disconnects on remote wakeup under
ChromeOS and a Lynx Point LP xHCI host that takes up to 20 ms to move
from RExit to U0. ChromeOS is very aggressive about power savings, and
sets the autosuspend_delay to 100 ms, and disables USB persist.
I attempted to replicate this bug with Ubuntu 12.04, but could not. I
used Ubuntu 12.04 on the same platform, with the same BIOS that the bug
was triggered on ChromeOS with. I also changed the USB sysfs settings
as described above, but still could not reproduce the bug under Ubuntu.
It may be that ChromeOS userspace triggers this bug through additional
settings.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
If a command on the command ring needs to be cancelled before it is handled
it can be turned to a no-op operation when the ring is stopped.
We want to store the command ring enqueue pointer in the command structure
when the command in enqueued for the cancellation case.
Some commands used to store the command ring dequeue pointers instead of enqueue
(these often worked because enqueue happends to equal dequeue quite often)
Other commands correctly used the enqueue pointer but did not check if it pointed
to a valid trb or a link trb, this caused for example stop endpoint command to timeout in
xhci_stop_device() in about 2% of suspend/resume cases.
This should also solve some weird behavior happening in command cancellation cases.
This patch is based on a patch submitted by Sarah Sharp to linux-usb, but
then forgotten:
http://marc.info/?l=linux-usb&m=136269803207465&w=2
This patch should be backported to kernels as old as 3.7, that contain
the commit b92cc66c04 "xHCI: add aborting
command ring function"
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
When a command times out, the command ring is first aborted,
and then stopped. If the command ring is empty when it is stopped
the stop event will point to next command which is not yet set.
xHCI tries to handle this next event often causing an oops.
Don't handle command completion events on stopped cmd ring if ring is
empty.
This patch should be backported to kernels as old as 3.7, that contain
the commit b92cc66c04 "xHCI: add aborting
command ring function"
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Reported-by: Giovanni <giovanni.nervi@yahoo.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
When debug is not enabled and dev_dbg() will expand to nothing,
log might be flooded with "callbacks suppressed". If it was not
done on purpose, better to use dev_dbg_ratelimited() instead.
Signed-off-by: Dmitry Kasatkin <d.kasatkin@samsung.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
This patch defines a new trace event, which is called xhci_dbg_ring_expansion
and belongs to the event class xhci_log_msg, and adds tracepoints that trace
the debug messages associated with the expansion of endpoint ring when there
is not enough space allocated to hold all pending TRBs.
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
This patch defines a new trace event, which is called xhci_dbg_cancel_urb
and belongs to the event class xhci_log_msg, and adds tracepoints that
trace the debug messages related to the removal of a cancelled URB from
the endpoint's transfer ring.
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
This patch creates a new event class, called xhci_log_event,
and defines the xhci_cmd_completion trace event used for
tracing the commands issued to xHC that generate a completion
event in the event ring.
This info can be used, later, to print, in a human readable
way, the completion status and flags as well as the command's
type and fields using the trace-cmd tool and the appropriate
plugin.
Also, a tracepoint is added in handle_cmd_completion().
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
This patch defines a new trace event, which is called xhci_dbg_reset_ep
and belongs in the event class xhci_log_msg, and adds tracepoints that
trace the debug messages associated with resetting an endpoint after
the reception of a STALL packet.
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
This patch defines a new trace event, which is called xhci_dbg_quirks
and belongs in the event class xhci_log_msg, and adds tracepoints that
trace the debug messages associated with xHCs' quirks.
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
This patch defines a new trace event, which is called xhci_dbg_context_change
and belongs in the event class xhci_log_msg, and adds tracepoints for tracing
the debug messages related to context updates performed with Configure Endpoint
and Evaluate Context commands.
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
in some cases where device is attched to xhci port and do not responding,
for example ath9k_htc with stalled firmware, kernel will
crash on ring_doorbell_for_active_rings.
This patch check if pointer exist before it is used.
This patch should be backported to kernels as old as 2.6.35, that
contain the commit e9df17eb14 "USB: xhci:
Correct assumptions about number of rings per endpoint"
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
Fail gracefully, instead of causing the kernel to panic, if the input
control context doesn't have the right type (XHCI_CTX_TYPE_INPUT). Push
finding the pointer to the input control context up into functions that
can fail.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: John Youn <johnyoun@synopsys.com>
According to Felipe and Alan's comments the second parameter of irq
handler should be 'void *' not a specific structure pointer.
So change it.
Signed-off-by: Alex Shi <alex.shi@intel.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
When a device attached to the roothub is suspended, the endpoint rings
are stopped. The host may generate a completion event with the
completion code set to 'Stopped' or 'Stopped Invalid' when the ring is
halted. The current xHCI code prints a warning in that case, which can
be really annoying if the USB device is coming into and out of suspend.
Remove the unnecessary warning.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Stephen Hemminger <stephen@networkplumber.org>
Use proper macro while extracting TRB transfer length from
Transfer event TRBs. Adding a macro EVENT_TRB_LEN (bits 0:23)
for the same, and use it instead of TRB_LEN (bits 0:16) in
case of event TRBs.
This patch should be backported to kernels as old as 2.6.31, that
contain the commit b10de14211 "USB: xhci:
Bulk transfer support". This patch will have issues applying to older
kernels.
Signed-off-by: Vivek gautam <gautam.vivek@samsung.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
/home/b29397/work/code/git/linus/linux-2.6/drivers/usb/host/xhci-ring.c: In function ‘handle_port_status’:
/home/b29397/work/code/git/linus/linux-2.6/drivers/usb/host/xhci-ring.c:1580: warning: ‘hcd’ may be used uninitialized in this function
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
This pulls in a bunch of fixes that are in Linus's tree because we need them
here for testing and development.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1640) fixes a memory leak in xhci-hcd. The urb_priv
data structure isn't always deallocated in the handle_tx_event()
routine for non-control transfers. The patch adds a kfree() call so
that all paths end up freeing the memory properly.
This patch should be backported to kernels as old as 2.6.36, that
contain the commit 8e51adccd4 "USB: xHCI:
Introduce urb_priv structure"
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-and-tested-by: Martin Mokrejs <mmokrejs@fold.natur.cuni.cz>
CC: <stable@vger.kernel.org>
Fix incorrect bit test that originally showed up in
4ee823b83b "USB/xHCI: Support
device-initiated USB 3.0 resume."
Use '&' instead of '&&'.
This should be backported to kernels as old as 3.4.
Signed-off-by: Nickolai Zeldovich <nickolai@csail.mit.edu>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
To calculate the TD size for a particular TRB in an isoc TD, we need
know the endpoint's max packet size. Isochronous endpoints also encode
the number of additional service opportunities in their wMaxPacketSize
field. The TD size calculation did not mask off those bits before using
the field. This resulted in incorrect TD size information for
isochronous TRBs when an URB frame buffer crossed a 64KB boundary.
For example:
- an isoc endpoint has 2 additional service opportunites and
a max packet size of 1020 bytes
- a frame transfer buffer contains 3060 bytes
- one frame buffer crosses a 64KB boundary, and must be split into
one 1276 byte TRB, and one 1784 byte TRB.
The TD size is is the number of packets that remain to be transferred
for a TD after processing all the max packet sized packets in the
current TRB and all previous TRBs.
For this TD, the number of packets to be transferred is (3060 / 1020),
or 3. The first TRB contains 1276 bytes, which means it contains one
full packet, and a 256 byte remainder. After processing all the max
packet-sized packets in the first TRB, the host will have 2 packets left
to transfer.
The old code would calculate the TD size for the first TRB as:
total packet count = DIV_ROUND_UP (TD length / endpoint wMaxPacketSize)
total packet count - (first TRB length / endpoint wMaxPacketSize)
The math should have been:
total packet count = DIV_ROUND_UP (3060 / 1020) = 3
3 - (1276 / 1020) = 2
Since the old code didn't mask off the additional service interval bits
from the wMaxPacketSize field, the math ended up as
total packet count = DIV_ROUND_UP (3060 / 5116) = 1
1 - (1276 / 5116) = 1
Fix this by masking off the number of additional service opportunities
in the wMaxPacketSize field.
This patch should be backported to stable kernels as old as 3.0, that
contain the commit 4da6e6f247 "xhci 1.0:
Update TD size field format." It may not apply well to kernels older
than 3.2 because of commit 29cc88979a
"USB: use usb_endpoint_maxp() instead of le16_to_cpu()".
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
An isochronous TD is comprised of one isochronous TRB chained to zero or
more normal TRBs. Only the isoc TRB has the TBC and TLBPC fields. The
normal TRBs must set those fields to zeroes. The code was setting the
TBC and TLBPC fields for both isoc and normal TRBs. Fix this.
This should be backported to stable kernels as old as 3.0, that contain
the commit b61d378f2d " xhci 1.0: Set
transfer burst last packet count field."
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
The union xhci_trb *trb variable is defined and assigned
inside the xHCI IRQ handler function but is never used.
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
The USB core hub thread (khubd) is designed with external USB hubs in
mind. It expects that if a port status change bit is set, the hub will
continue to send a notification through the hub status data transfer.
Basically, it expects hub notifications to be level-triggered.
The xHCI host controller is designed to be edge-triggered on the logical
'OR' of all the port status change bits. When all port status change
bits are clear, and a new change bit is set, the xHC will generate a
Port Status Change Event. If another change bit is set in the same port
status register before the first bit is cleared, it will not send
another event.
This means that the hub code may lose port status changes because of
race conditions between clearing change bits. The user sees this as a
"dead port" that doesn't react to device connects.
The fix is to turn on port polling whenever a new change bit is set.
Once the USB core issues a hub status request that shows that no change
bits are set in any USB ports, turn off port polling.
We can't allow the USB core to poll the roothub for port events during
host suspend because if the PCI host is in D3cold, the port registers
will be all f's. Instead, stop the port polling timer, and
unconditionally restart it when the host resumes. If there are no port
change bits set after the resume, the first call to hub_status_data will
disable polling.
This patch should be backported to stable kernels with the first xHCI
support, 2.6.31 and newer, that include the commit
0f2a79300a "USB: xhci: Root hub support."
There will be merge conflicts because the check for HC_STATE_SUSPENDED
was moved into xhci_suspend in 3.8.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable@vger.kernel.org
The xHCI 1.0 specification made a change to the TD Size field in TRBs.
The value is now the number of packets that remain to be sent in the TD,
not including this TRB. The TD Size value for the last TRB in a TD must
always be zero.
The xHCI function xhci_v1_0_td_remainder() attempts to calculate this,
but it gets it wrong. First, it erroneously reuses the old
xhci_td_remainder function, which will right shift the value by 10. The
xHCI 1.0 spec as of June 2011 says nothing about right shifting by 10.
Second, it does not set the TD size for the last TRB in a TD to zero.
Third, it uses roundup instead of DIV_ROUND_UP. The total packet count
is supposed to be the total number of bytes in this TD, divided by the
max packet size, rounded up. DIV_ROUND_UP is the right function to use
in that case.
With the old code, a TD on an endpoint with max packet size 1024 would
be set up like so:
TRB 1, TRB length = 600 bytes, TD size = 0
TRB 1, TRB length = 200 bytes, TD size = 0
TRB 1, TRB length = 100 bytes, TD size = 0
With the new code, the TD would be set up like this:
TRB 1, TRB length = 600 bytes, TD size = 1
TRB 1, TRB length = 200 bytes, TD size = 1
TRB 1, TRB length = 100 bytes, TD size = 0
This commit should be backported to kernels as old as 3.0, that contain
the commit 4da6e6f247 "xhci 1.0: Update TD
size field format."
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Chintan Mehta <chintan.mehta@sibridgetech.com>
Reported-by: Shimmer Huang <shimmering.h@gmail.com>
Tested-by: Bhavik Kothari <bhavik.kothari@sibridgetech.com>
Tested-by: Shimmer Huang <shimmering.h@gmail.com>
Cc: stable@vger.kernel.org
Non-static xHCI driver symbols should start with the "xhci_" prefix, in
order to avoid namespace pollution. Rename the "handshake" function to
"xhci_handshake".
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Ben Hutchings <ben@decadent.org.uk>
The command cancellation code doesn't check whether find_trb_seg()
couldn't find the segment that contains the TRB to be canceled. This
could cause a NULL pointer deference later in the function when next_trb
is called. It's unlikely to happen unless something is wrong with the
command ring pointers, so add some debugging in case it happens.
This patch should be backported to stable kernels as old as 3.0, that
contain the commit b63f4053cc "xHCI:
handle command after aborting the command ring".
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
When a device with an isochronous endpoint is behind a hub plugged into
the Intel Panther Point xHCI host controller, and the driver submits
multiple frames per URB, the xHCI driver will set the Block Event
Interrupt (BEI) flag on all but the last TD for the URB. This causes
the host controller to place an event on the event ring, but not send an
interrupt. When the last TD for the URB completes, BEI is cleared, and
we get an interrupt for the whole URB.
However, under a Panther Point xHCI host controller, if the parent hub
is unplugged when one or more events from transfers with BEI set are on
the event ring, a port status change event is placed on the event ring,
but no interrupt is generated. This means URBs stop completing, and the
USB device disconnect is not noticed. Something like a USB headset will
cause mplayer to hang when the device is disconnected.
If another transfer is sent (such as running `sudo lsusb -v`), the next
transfer event seems to "unstick" the event ring, the xHCI driver gets
an interrupt, and the disconnect is reported to the USB core.
The fix is not to use the BEI flag under the Panther Point xHCI host.
This will impact power consumption and system responsiveness, because
the xHCI driver will receive an interrupt for every frame in all
isochronous URBs instead of once per URB.
Intel chipset developers confirm that this bug will be hit if the BEI
flag is used on any endpoint, not just ones that are behind a hub.
This patch should be backported to kernels as old as 3.0, that contain
the commit 69e848c209 "Intel xhci: Support
EHCI/xHCI port switching."
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
removes unnecessary semicolon
Found by Coccinelle: http://coccinelle.lip6.fr/
Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
drivers/usb/host/xhci.c:1826:14: warning: symbol 'xhci_get_block_size' was not declared. Should it be static?
drivers/usb/host/xhci.c:1844:14: warning: symbol 'xhci_get_largest_overhead' was not declared. Should it be static?
drivers/usb/host/xhci-ring.c:2304:36: warning: context imbalance in 'handle_tx_event' - unexpected unlock
drivers/usb/host/xhci-hub.c:425:6: warning: symbol 'xhci_set_remote_wake_mask' was not declared. Should it be static?
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
According to xHCI spec section 4.6.1.1 and section 4.6.1.2,
after aborting a command on the command ring, xHC will
generate a command completion event with its completion
code set to Command Ring Stopped at least. If a command is
currently executing at the time of aborting a command, xHC
also generate a command completion event with its completion
code set to Command Abort. When the command ring is stopped,
software may remove, add, or rearrage Command Descriptors.
To cancel a command, software will initialize a command
descriptor for the cancel command, and add it into a
cancel_cmd_list of xhci. When the command ring is stopped,
software will find the command trbs described by command
descriptors in cancel_cmd_list and modify it to No Op
command. If software can't find the matched trbs, we can
think it had been finished.
This patch should be backported to kernels as old as 3.0, that contain
the commit 7ed603ecf8 "xhci: Add an
assertion to check for virt_dev=0 bug." That commit papers over a NULL
pointer dereference, and this patch fixes the underlying issue that
caused the NULL pointer dereference.
Signed-off-by: Elric Fu <elricfu1@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Miroslav Sabljic <miroslav.sabljic@avl.com>
Cc: stable@vger.kernel.org
Software have to abort command ring and cancel command
when a command is failed or hang. Otherwise, the command
ring will hang up and can't handle the others. An example
of a command that may hang is the Address Device Command,
because waiting for a SET_ADDRESS request to be acknowledged
by a USB device is outside of the xHC's ability to control.
To cancel a command, software will initialize a command
descriptor for the cancel command, and add it into a
cancel_cmd_list of xhci.
Sarah: Fixed missing newline on "Have the command ring been stopped?"
debugging statement.
This patch should be backported to kernels as old as 3.0, that contain
the commit 7ed603ecf8 "xhci: Add an
assertion to check for virt_dev=0 bug." That commit papers over a NULL
pointer dereference, and this patch fixes the underlying issue that
caused the NULL pointer dereference.
Signed-off-by: Elric Fu <elricfu1@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Miroslav Sabljic <miroslav.sabljic@avl.com>
Cc: stable@vger.kernel.org
Adding cmd_ring_state for command ring. It helps to verify
the current command ring state for controlling the command
ring operations.
This patch should be backported to kernels as old as 3.0. The commit
7ed603ecf8 "xhci: Add an assertion to
check for virt_dev=0 bug." papers over the NULL pointer dereference that
I now believe is related to a timed out Set Address command. This (and
the four patches that follow it) contain the real fix that also allows
VIA USB 3.0 hubs to consistently re-enumerate during the plug/unplug
stress tests.
Signed-off-by: Elric Fu <elricfu1@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Miroslav Sabljic <miroslav.sabljic@avl.com>
Cc: stable@vger.kernel.org
This patch fixes a particularly nasty bug that was revealed by the ring
expansion patches. The bug has been present since the very beginning of
the xHCI driver history, and could have caused general protection faults
from bad memory accesses.
The first thing to note is that a Set TR Dequeue Pointer command can
move the dequeue pointer to a link TRB, if the canceled or stalled
transfer TD ended just before a link TRB. The function to increment the
dequeue pointer, inc_deq, was written before cancellation and stall
support was added. It assumed that the dequeue pointer could never
point to a link TRB. It would unconditionally increment the dequeue
pointer at the start of the function, check if the pointer was now on a
link TRB, and move it to the top of the next segment if so.
This means that if a Set TR Dequeue Point command moved the dequeue
pointer to a link TRB, a subsequent call to inc_deq() would move the
pointer off the segment and into la-la-land. It would then read from
that memory to determine if it was a link TRB. Other functions would
often call inc_deq() until the dequeue pointer matched some other
pointer, which means this function would quite happily read all of
system memory before wrapping around to the right pointer value.
Often, there would be another endpoint segment from a different ring
allocated from the same DMA pool, which would be contiguous to the
segment inc_deq just stepped off of. inc_deq would eventually find the
link TRB in that segment, and blindly move the dequeue pointer back to
the top of the correct ring segment.
The only reason the original code worked at all is because there was
only one ring segment. With the ring expansion patches, the dequeue
pointer would eventually wrap into place, but the dequeue segment would
be out-of-sync. On the second TD after the dequeue pointer was moved to
a link TRB, trb_in_td() would fail (because the dequeue pointer and
dequeue segment were out-of-sync), and this message would appear:
ERROR Transfer event TRB DMA ptr not part of current TD
This fixes bugzilla entry 4333 (option-based modem unhappy on USB 3.0
port: "Transfer event TRB DMA ptr not part of current TD", "rejecting
I/O to offline device"),
https://bugzilla.kernel.org/show_bug.cgi?id=43333
and possibly other general protection fault bugs as well.
This patch should be backported to kernels as old as 2.6.31. A separate
patch will be created for kernels older than 3.4, since inc_deq was
modified in 3.4 and this patch will not apply.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: James Ettle <theholyettlz@googlemail.com>
Tested-by: Matthew Hall <mhall@mhcomputing.net>
Cc: stable@vger.kernel.org
When we encounter an xHCI host that needs the XHCI_TRUST_TX_LENGTH
quirk, the xHCI driver ends up spewing messages about the quirk into
dmesg every time a short packet occurs. Change the xHCI driver to
rate-limit such warnings.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Matthew Hall <mhall@mhcomputing.net>
Reported-by: Gary E. Miller <gem@rellim.com>
The Microsoft LifeChat 3000 USB headset was causing a very reproducible
hang whenever it was plugged in. At first, I thought the host
controller was producing bad transfer events, because the log was filled
with errors like:
xhci_hcd 0000:00:14.0: ERROR Transfer event TRB DMA ptr not part of current TD
However, it turned out to be an xHCI driver bug in the ring expansion
patches. The bug is triggered When there are two ring segments, and a
TD that ends just before a link TRB, like so:
______________ _____________
| | ---> | setup TRB B |
______________ | _____________
| | | | data TRB B |
______________ | _____________
| setup TRB A | <-- deq | | data TRB B |
______________ | _____________
| data TRB A | | | | <-- enq, deq''
______________ | _____________
| status TRB A | | | |
______________ | _____________
| link TRB |--------------- | link TRB |
_____________ <--- deq' _____________
TD A (the first control transfer) stalls on the data phase. That halts
the ring. The xHCI driver moves the hardware dequeue pointer to the
first TRB after the stalled transfer, which happens to be the link TRB.
Once the Set TR dequeue pointer command completes, the function
update_ring_for_set_deq_completion runs. That function is supposed to
update the xHCI driver's dequeue pointer to match the internal hardware
dequeue pointer. On the first call this would work fine, and the
software dequeue pointer would move to deq'.
However, if the transfer immediately after that stalled (TD B in this
case), another Set TR Dequeue command would be issued. That would move
the hardware dequeue pointer to deq''. Once that command completed,
update_ring_for_set_deq_completion would run again.
The original code would unconditionally increment the software dequeue
pointer, which moved the pointer off the ring segment into la-la-land.
The while loop would happy increment the dequeue pointer (possibly
wrapping it) until it matched the hardware pointer value.
The while loop would also access all the memory in between the first
ring segment and the second ring segment to determine if it was a link
TRB. This could cause general protection faults, although it was
unlikely because the ring segments came from a DMA pool, and would often
have consecutive memory addresses.
If nothing in that space looked like a link TRB, the deq_seg pointer for
the ring would remain on the first segment. Thus, the deq_seg and the
software dequeue pointer would get out of sync.
When the next transfer event came in after the stalled transfer, the
xHCI driver code would attempt to convert the software dequeue pointer
into a DMA address in order to compare the DMA address for the completed
transfer. Since the deq_seg and the dequeue pointer were out of sync,
xhci_trb_virt_to_dma would return NULL.
The transfer event would get ignored, the transfer would eventually
timeout, and we would mistakenly convert the finished transfer to no-op
TRBs. Some kernel driver (maybe xHCI?) would then get stuck in an
infinite loop in interrupt context, and the whole machine would hang.
This patch should be backported to kernels as old as 3.4, that contain
the commit b008df60c6 "xHCI: count free
TRBs on transfer ring"
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Cc: stable@vger.kernel.org
The upcoming USB 3.0 Link PM patches will introduce new API to enable
and disable low-power link states. We must be able to disable LPM in
order to reset a device, or place the device into U3 (device suspend).
Therefore, we need to make sure the Evaluate Context command to disable
the LPM timeouts can't fail due to there being no room on the command
ring.
Introduce a new flag to the function that queues the Evaluate Context
command, command_must_succeed. This tells the ring handler that a TRB
has already been reserved for the command (by incrementing
xhci->cmd_ring_reserved_trbs), and basically ensures that prepare_ring()
won't fail. A similar flag was already implemented for the Configure
Endpoint command queuing function.
All functions that currently call xhci_configure_endpoint() to issue an
Evaluate Context command pass "false" for the "must_succeed" parameter,
so this patch should have no effect on current xHCI driver behavior.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Sergio reported that when he recorded audio from a USB headset mic
plugged into the USB 3.0 port on his ASUS N53SV-DH72, the audio sounded
"robotic". When plugged into the USB 2.0 port under EHCI on the same
laptop, the audio sounded fine. The device is:
Bus 002 Device 004: ID 046d:0a0c Logitech, Inc. Clear Chat Comfort USB Headset
The problem was tracked down to the Fresco Logic xHCI host controller
not correctly reporting short transfers on isochronous IN endpoints.
The driver would submit a 96 byte transfer, the device would only send
88 or 90 bytes, and the xHCI host would report the transfer had a
"successful" completion code, with an untransferred buffer length of 8
or 6 bytes.
The successful completion code and non-zero untransferred length is a
contradiction. The xHCI host is supposed to only mark a transfer as
successful if all the bytes are transferred. Otherwise, the transfer
should be marked with a short packet completion code. Without the EHCI
bus trace, we wouldn't know whether the xHCI driver should trust the
completion code or the untransferred length. With it, we know to trust
the untransferred length.
Add a new xHCI quirk for the Fresco Logic host controller. If a
transfer is reported as successful, but the untransferred length is
non-zero, print a warning. For the Fresco Logic host, change the
completion code to COMP_SHORT_TX and process the transfer like a short
transfer.
This should be backported to stable kernels that contain the commit
f5182b4155 "xhci: Disable MSI for some
Fresco Logic hosts." That commit was marked for stable kernels as old
as 2.6.36.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Sergio Correia <lists@uece.net>
Tested-by: Sergio Correia <lists@uece.net>
Cc: stable@vger.kernel.org
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
This patch changes the output format specifier of a debugging line in
the xhci-hcd driver. An URB's transfer_buffer_length should be
printed in decimal; there's no reason to print it in hex. Especially
since the actual_length value, printed earlier on the same line, is
already in decimal.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
While testing unplugging an UVC HD webcam with usb-redirection (so through
usbdevfs), my userspace usb-redir code was getting a value of -1 in
iso_frame_desc[n].status, which according to Documentation/usb/error-codes.txt
is not a valid value.
The source of this -1 is the default case in xhci-ring.c:process_isoc_td()
adding a kprintf there showed the value of trb_comp_code to be COMP_TX_ERR
in this case, so this patch adds handling for that completion code to
process_isoc_td().
This was observed and tested with the following xhci controller:
1033:0194 NEC Corporation uPD720200 USB 3.0 Host Controller (rev 04)
Note: I also wonder if setting frame->status to -1 (-EPERM) is the best we can
do, but since I cannot come up with anything better I've left that as is.
This patch should be backported to kernels as old as 2.6.36, which contain the
commit 04e51901dd "USB: xHCI: Isochronous
transfer implementation".
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
This commit adds a bit-array to xhci bus_state for keeping track of
which ports are undergoing a resume transition. If any of the bits
are set when xhci_hub_status_data() is called, the routine will return
a non-zero value even if no ports have any status changes pending.
This will allow usbcore to handle races between root-hub suspend and
port wakeup.
This patch should be backported to kernels as old as 3.4, that contain
the commit 879d38e6bc "USB: fix race
between root-hub suspend and remote wakeup".
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: stable@vger.kernel.org
The caller is allowed to specify the GFP flags for these functions.
We should prefer their flags unless we have good reason. For
example, if we take a spin_lock ourselves we'd need to use
GFP_ATOMIC. But in this case it's safe to use the callers GFP
flags.
The callers all pass GFP_ATOMIC here, so this change doesn't affect
how the kernel behaves but we may add other callers later and this
is a cleanup.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
While we're at that, define IMAN bitfield to aid readability.
The interrupt enable bit should be set once on driver init, and we
shouldn't need to continually re-enable it. Commit c21599a3 introduced
a read of the irq_pending register, and that allows us to preserve the
state of the IE bit. Before that commit, we were blindly writing 0x3 to
the register.
This patch should be backported to kernels as old as 2.6.36, or ones
that contain the commit c21599a361 "USB:
xhci: Reduce reads and writes of interrupter registers".
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
When a urb is submitted to xHCI driver, check if queueing the urb will make
the enqueue pointer advance into dequeue seg and expand the ring if it
occurs. This is to guarantee the safety of ring expansion.
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Paul Zimmerman <Paul.Zimmerman@synopsys.com>
If room_on_ring() check fails, try to expand the ring and check again.
When expand a ring, use a cached ring or allocate new segments, link
the original ring and the new ring or segments, update the original ring's
segment numbers and the last segment pointer.
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Paul Zimmerman <Paul.Zimmerman@synopsys.com>
In the past, the room_on_ring() check was implemented by walking all over
the ring, which is wasteful and complicated.
Count the number of free TRBs instead. The free TRBs number should be
updated when enqueue/dequeue pointer is updated, or upon the completion
of a set dequeue pointer command.
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Paul Zimmerman <Paul.Zimmerman@synopsys.com>
When allocate a ring, store its type - four transfer types for endpoint,
TYPE_STREAM for stream transfer, and TYPE_COMMAND/TYPE_EVENT for xHCI host.
This helps to get rid of three bool function parameters: link_trbs, isoc
and consumer.
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Paul Zimmerman <Paul.Zimmerman@synopsys.com>
There's really no point in having hcd->irq as a
signed integer when we consider the fact that
IRQ 0 means NO_IRQ. In order to avoid confusion,
make hcd->irq unsigned and fix users who were
passing -1 as the IRQ number to usb_add_hcd.
Tested-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
USB 3.0 hubs don't have a port suspend change bit (that bit is now
reserved). Instead, when a host-initiated resume finishes, the hub sets
the port link state change bit.
When a USB 3.0 device initiates remote wakeup, the parent hubs with
their upstream links in U3 will pass the LFPS up the chain. The first
hub that has an upstream link in U0 (which may be the roothub) will
reflect that LFPS back down the path to the device.
However, the parent hubs in the resumed path will not set their link
state change bit. Instead, the device that initiated the resume has to
send an asynchronous "Function Wake" Device Notification up to the host
controller. Therefore, we need a way to notify the USB core of a device
resume without going through the normal hub URB completion method.
First, make the xHCI roothub act like an external USB 3.0 hub and not
pass up the port link state change bit when a device-initiated resume
finishes. Introduce a new xHCI bit field, port_remote_wakeup, so that
we can tell the difference between a port coming out of the U3Exit state
(host-initiated resume) and the RExit state (ending state of
device-initiated resume).
Since the USB core can't tell whether a port on a hub has resumed by
looking at the Hub Status buffer, we need to introduce a bitfield,
wakeup_bits, that indicates which ports have resumed. When the xHCI
driver notices a port finishing a device-initiated resume, we call into
a new USB core function, usb_wakeup_notification(), that will set
the right bit in wakeup_bits, and kick khubd for that hub.
We also call usb_wakeup_notification() when the Function Wake Device
Notification is received by the xHCI driver. This covers the case where
the link between the roothub and the first-tier hub is in U0, and the
hub reflects the resume signaling back to the device without giving any
indication it has done so until the device sends the Function Wake
notification.
Change the code in khubd that handles the remote wakeup to look at the
state the USB core thinks the device is in, and handle the remote wakeup
if the port's wakeup bit is set.
This patch only takes care of the case where the device is attached
directly to the roothub, or the USB 3.0 hub that is attached to the root
hub is the device sending the Function Wake Device Notification (e.g.
because a new USB device was attached). The other cases will be covered
in a second patch.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
When the USB 3.0 hub support went in, I disabled selective suspend for
all external USB 3.0 hubs because they used a different mechanism to
enable remote wakeup. In fact, other USB 3.0 devices that could signal
remote wakeup would have been prevented from going into suspend because
they would have stalled the SetFeature Device Remote Wakeup request.
This patch adds support for the USB 3.0 way of enabling remote wake up
(with a SetFeature Function Suspend request), and enables selective
suspend for all hubs during hub_probe. It assumes that all USB 3.0 have
only one "function" as defined by the interface association descriptor,
which is true of all the USB 3.0 devices I've seen so far. FIXME if
that turns out to change later.
After a device signals a remote wakeup, it is supposed to send a Device
Notification packet to the host controller, signaling which function
sent the remote wakeup. The host can then put any other functions back
into function suspend. Since we don't have support for function suspend
(and no devices currently support it), we'll just assume the hub
function will resume the device properly when it received the port
status change notification, and simply ignore any device notification
events from the xHCI host controller.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
xHCI roothubs go through slightly different port state machines when
either a device initiates a remote wakeup and signals resume, or when
the host initiates a resume.
According to section 4.19.1.2.13 of the xHCI 1.0 spec, on host-initiated
resume, the xHC port state machine automatically goes through the U3Exit
state into the U0 state, setting the port link state change (PLC) bit in
the process.
When a device initiates resume, the xHCI port state machine goes into
the "Resume" state and sets the PLC bit. Then the xHCI driver writes U0
into the port link state register to transition the port to U0 from the
Resume state.
We can't be sure the device is actually in the U0 state until we receive
the next port status change event with the PLC bit set. We really don't
want khubd to be polling the roothub port status bits until the device
is really in U0.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Andiry Xu <andiry.xu@amd.com>
When a TD length mismatch is found during isoc TRB enqueue, it directly
returns -EINVAL. However, isoc transfer is partially enqueued at this time,
and the ring should be cleared.
This should be backported to kernels as old as 2.6.36, which contain the
commit 522989a27c "xhci: Fix failed
enqueue in the middle of isoch TD."
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
The xHCI hub port code gets passed a zero-based port number by the USB
core. It then adds one to in order to find a device slot by port number
and device speed by calling xhci_find_slot_id_by_port. That function
clearly states it requires a one-based port number. The xHCI port
status change event handler was using a zero-based port number that it
got from find_faked_portnum_from_hw_portnum, not a one-based port
number. This lead to the doorbells never being rung for a device after
a resume, or worse, a different device with the same speed having its
doorbell rung (which could lead to bad power management in the xHCI host
controller).
This patch should be backported to kernels as old as 2.6.39.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Andiry Xu <andiry.xu@amd.com>
Cc: stable@vger.kernel.org
Randy Dunlap points out that commit 9258c0b2 "xhci: Better debugging for
critical host errors." introduces some new build warnings on 32-bit
builds:
drivers/usb/host/xhci-ring.c:1936:3: warning: format '%016llx' expects type 'long long unsigned int', but argument 3 has type 'dma_addr_t'
drivers/usb/host/xhci-ring.c:1958:3: warning: format '%016llx' expects type 'long long unsigned int', but argument 3 has type 'dma_addr_t'
Cast the results of xhci_trb_virt_to_dma() from a dma_addr_t to an
unsigned long long.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Randy Dunlap <rdunlap@xenotime.net>
When a host controller gives a bad event TRB, we should print out the
contents of the TRB as a warning so that users don't have to recompile
their kernel to get information about what went wrong. Also, print out
the event ring if they have xHCI debugging turned on, since previous
events can often explain what happened before the bad TRB occurred.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
With devices that can need up to 128 segments (with 64 TRBs per
segment), we can't afford to print out the entire endpoint ring every
time an URB is canceled. Instead, print the offset of the TRB, along
with device pathname and endpoint number.
Only print DMA addresses, since virtual addresses of internal structures
are not useful. Change the cancellation code to be more clear about
what steps of the cancellation it is in the process of doing (queueing
the request, handling the stop endpoint command, turning the TDs into
no-ops, or moving the dequeue pointers).
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
The code for toggling the cycle bits when the ring wraps around has
worked for years. The print statement alone is not enough to indicate
there's something wrong with that code. Now that full transfer tracing
has been ripped out, the print statement or lack thereof won't help
without context of where the enqueue pointer is.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Users can trace the submission of URBs through USBmon, so it makes no
sense to have duplicate debugging in the xHCI driver.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Remove verbose debugging about scatter-gather lists, as we haven't had
an issue with scatter gather list math for about a year now. The
debugging didn't help before, and just clutters up the log file when
trying to debug other issues.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Getting a short packet or a babble error is usually a recoverable error,
so stop scaring users with warnings in dmesg when xHCI debugging is turned
off.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Add a new field num_mapped_sgs to struct urb so that we have a place to
store the number of mapped entries and can also retain the original
value of entries in num_sgs. Previously, usb_hcd_map_urb_for_dma()
would overwrite this with the number of mapped entries, which would
break dma_unmap_sg() because it requires the original number of entries.
This fixes warnings like the following when using USB storage devices:
------------[ cut here ]------------
WARNING: at lib/dma-debug.c:902 check_unmap+0x4e4/0x695()
ehci_hcd 0000:00:12.2: DMA-API: device driver frees DMA sg list with different entry count [map count=4] [unmap count=1]
Modules linked in: ohci_hcd ehci_hcd
Pid: 0, comm: kworker/0:1 Not tainted 3.2.0-rc2+ #319
Call Trace:
<IRQ> [<ffffffff81036d3b>] warn_slowpath_common+0x80/0x98
[<ffffffff81036de7>] warn_slowpath_fmt+0x41/0x43
[<ffffffff811fa5ae>] check_unmap+0x4e4/0x695
[<ffffffff8105e92c>] ? trace_hardirqs_off+0xd/0xf
[<ffffffff8147208b>] ? _raw_spin_unlock_irqrestore+0x33/0x50
[<ffffffff811fa84a>] debug_dma_unmap_sg+0xeb/0x117
[<ffffffff8137b02f>] usb_hcd_unmap_urb_for_dma+0x71/0x188
[<ffffffff8137b166>] unmap_urb_for_dma+0x20/0x22
[<ffffffff8137b1c5>] usb_hcd_giveback_urb+0x5d/0xc0
[<ffffffffa0000d02>] ehci_urb_done+0xf7/0x10c [ehci_hcd]
[<ffffffffa0001140>] qh_completions+0x429/0x4bd [ehci_hcd]
[<ffffffffa000340a>] ehci_work+0x95/0x9c0 [ehci_hcd]
...
---[ end trace f29ac88a5a48c580 ]---
Mapped at:
[<ffffffff811faac4>] debug_dma_map_sg+0x45/0x139
[<ffffffff8137bc0b>] usb_hcd_map_urb_for_dma+0x22e/0x478
[<ffffffff8137c494>] usb_hcd_submit_urb+0x63f/0x6fa
[<ffffffff8137d01c>] usb_submit_urb+0x2c7/0x2de
[<ffffffff8137dcd4>] usb_sg_wait+0x55/0x161
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This pulls in the latest USB bugfixes and helps a few of the drivers
merge nicer in the future due to changes in both branches.
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The HCD_FLAG_SAW_IRQ flag was introduced in order to catch IRQ routing
errors: If an URB was unlinked and the host controller hadn't gotten
any IRQs, it seemed likely that the IRQs were directed to the wrong
vector.
This warning hasn't come up in many years, as far as I know; interrupt
routing now seems to be well under control. Therefore there's no
reason to keep the flag around any more. This patch (as1495) finally
removes it.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* 'usb-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (260 commits)
usb: renesas_usbhs: fixup inconsistent return from usbhs_pkt_push()
usb/isp1760: Allow to optionally trigger low-level chip reset via GPIOLIB.
USB: gadget: midi: memory leak in f_midi_bind_config()
USB: gadget: midi: fix range check in f_midi_out_open()
QE/FHCI: fixed the CONTROL bug
usb: renesas_usbhs: tidyup for smatch warnings
USB: Fix USB Kconfig dependency problem on 85xx/QoirQ platforms
EHCI: workaround for MosChip controller bug
usb: gadget: file_storage: fix race on unloading
USB: ftdi_sio.c: Use ftdi async_icount structure for TIOCMIWAIT, as in other drivers
USB: ftdi_sio.c:Fill MSR fields of the ftdi async_icount structure
USB: ftdi_sio.c: Fill LSR fields of the ftdi async_icount structure
USB: ftdi_sio.c:Fill TX field of the ftdi async_icount structure
USB: ftdi_sio.c: Fill the RX field of the ftdi async_icount structure
USB: ftdi_sio.c: Basic icount infrastructure for ftdi_sio
usb/isp1760: Let OF bindings depend on general CONFIG_OF instead of PPC_OF .
USB: ftdi_sio: Support TI/Luminary Micro Stellaris BD-ICDI Board
USB: Fix runtime wakeup on OHCI
xHCI/USB: Make xHCI driver have a BOS descriptor.
usb: gadget: add new usb gadget for ACM and mass storage
...
Setting the chain (CH) bit in the link TRB of isochronous transfer rings
is required by AMD 0.96 xHCI host controller to successfully transverse
multi-TRB TD that span through different memory segments.
When a Missed Service Error event occurs, if the chain bit is not set in
the link TRB and the host skips TDs which just across a link TRB, the
host may falsely recognize the link TRB as a normal TRB. You can see
this may cause big trouble - the host does not jump to the right address
which is pointed by the link TRB, but continue fetching the memory which
is after the link TRB address, which may not even belong to the host,
and the result cannot be predicted.
This causes some big problems. Without the former patch I sent: "xHCI:
prevent infinite loop when processing MSE event", the system may hang.
With that patch applied, system does not hang, but the host still access
wrong memory address and isoc transfer will fail. With this patch,
isochronous transfer works as expected.
This patch should be applied to kernels as old as 2.6.36, which was when
the first isochronous support was added for the xHCI host controller.
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
When the link state changes, xHC will report a port status change event
and set the PORT_PLC bit, for both USB3 and USB2 root hub ports.
The PLC will be cleared by usbcore for USB3 root hub ports, but not for
USB2 ports, because they do not report USB_PORT_STAT_C_LINK_STATE in
wPortChange.
Clear it for USB2 root hub ports in handle_port_status().
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Mathias Nyman