| Age | Commit message (Collapse) | Author |
|---|
|
This is a stable-only fix for the backport of commit 5d9b70f7d52e
("xhci: Don't add a virt_dev to the devs array before it's fully
allocated").
In branches that predate commit c5628a2af83a ("xhci: remove endpoint
ring cache") there is an additional failure path in
xhci_alloc_virt_device() where ring cache allocation fails, in
which case we need to free the ring allocated for endpoint 0.
Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
Cc: Mathias Nyman <mathias.nyman@intel.com>
|
|
commit 5d9b70f7d52eb14bb37861c663bae44de9521c35 upstream.
Avoid null pointer dereference if some function is walking through the
devs array accessing members of a new virt_dev that is mid allocation.
Add the virt_dev to xhci->devs[i] _after_ the virt_device and all its
members are properly allocated.
issue found by KASAN: null-ptr-deref in xhci_find_slot_id_by_port
"Quick analysis suggests that xhci_alloc_virt_device() is not mutex
protected. If so, there is a time frame where xhci->devs[slot_id] is set
but not fully initialized. Specifically, xhci->devs[i]->udev can be NULL."
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 80e457699a8dbdd70f2d26911e46f538645c55fc upstream.
Check vdev->real_port 0 to avoid panic
[ 9.261347] [<ffffff800884a390>] xhci_free_virt_devices_depth_first+0x58/0x108
[ 9.261352] [<ffffff800884a814>] xhci_mem_cleanup+0x1bc/0x570
[ 9.261355] [<ffffff8008842de8>] xhci_stop+0x140/0x1c8
[ 9.261365] [<ffffff80087ed304>] usb_remove_hcd+0xfc/0x1d0
[ 9.261369] [<ffffff80088551c4>] xhci_plat_remove+0x6c/0xa8
[ 9.261377] [<ffffff80086e928c>] platform_drv_remove+0x2c/0x70
[ 9.261384] [<ffffff80086e6ea0>] __device_release_driver+0x80/0x108
[ 9.261387] [<ffffff80086e7a1c>] device_release_driver+0x2c/0x40
[ 9.261392] [<ffffff80086e5f28>] bus_remove_device+0xe0/0x120
[ 9.261396] [<ffffff80086e2e34>] device_del+0x114/0x210
[ 9.261399] [<ffffff80086e9e00>] platform_device_del+0x30/0xa0
[ 9.261403] [<ffffff8008810bdc>] dwc3_otg_work+0x204/0x488
[ 9.261407] [<ffffff80088133fc>] event_work+0x304/0x5b8
[ 9.261414] [<ffffff80080e31b0>] process_one_work+0x148/0x490
[ 9.261417] [<ffffff80080e3548>] worker_thread+0x50/0x4a0
[ 9.261421] [<ffffff80080e9ea0>] kthread+0xe8/0x100
[ 9.261427] [<ffffff8008083680>] ret_from_fork+0x10/0x50
The problem can occur if xhci_plat_remove() is called shortly after
xhci_plat_probe(). While xhci_free_virt_devices_depth_first been
called before the device has been setup and get real_port initialized.
The problem occurred on Hikey960 and was reproduced by Guenter Roeck
on Kevin with chromeos-4.4.
Fixes: ee8665e28e8d ("xhci: free xhci virtual devices with leaf nodes first")
Cc: Guenter Roeck <groeck@google.com>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Fan Ning <fanning4@hisilicon.com>
Signed-off-by: Li Rui <lirui39@hisilicon.com>
Signed-off-by: yangdi <yangdi10@hisilicon.com>
Signed-off-by: Yu Chen <chenyu56@huawei.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit b72eb8435b25be3a1880264cf32ac91e626ba5ba upstream.
xHCI host controllers can have both USB 3.1 and 3.0 extended speed
protocol lists. If the USB3.1 speed is parsed first and 3.0 second then
the minor revision supported will be overwritten by the 3.0 speeds and
the USB3 roothub will only show support for USB 3.0 speeds.
This was the case with a xhci controller with the supported protocol
capability listed below.
In xhci-mem.c, the USB 3.1 speed is parsed first, the min_rev of usb3_rhub
is set as 0x10. And then USB 3.0 is parsed. However, the min_rev of
usb3_rhub will be changed to 0x00. If USB 3.1 device is connected behind
this host controller, the speed of USB 3.1 device just reports 5G speed
using lsusb.
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00 01 08 00 00 00 00 00 40 00 00 00 00 00 00 00 00
10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20 02 08 10 03 55 53 42 20 01 02 00 00 00 00 00 00 //USB 3.1
30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40 02 08 00 03 55 53 42 20 03 06 00 00 00 00 00 00 //USB 3.0
50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60 02 08 00 02 55 53 42 20 09 0E 19 00 00 00 00 00 //USB 2.0
70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
This patch fixes the issue by only owerwriting the minor revision if
it is higher than the existing one.
[reword commit message -Mathias]
Signed-off-by: YD Tseng <yd_tseng@asmedia.com.tw>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 7480d912d549f414e0ce39331870899e89a5598c upstream.
According to xHCI ch4.20 Scratchpad Buffers, the Scratchpad
Buffer needs to be zeroed.
...
The following operations take place to allocate
Scratchpad Buffers to the xHC:
...
b. Software clears the Scratchpad Buffer to '0'
Signed-off-by: Peter Chen <peter.chen@nxp.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 5db851cf20857c5504b146046e97cb7781f2a743 upstream.
There is no reason to restrict allocations to the first 16MB ISA DMA
addresses.
It is causing problems in a virtualization setup with enabled IOMMU
(x86_64). The result is that USB is not working in the VM.
Signed-off-by: Matthias Lange <matthias.lange@kernkonzept.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 6fc091fb0459ade939a795bfdcaf645385b951d4 upstream.
Print correct command ring address using 'val_64'.
Signed-off-by: Peter Chen <peter.chen@nxp.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 69307ccb9ad7ccb653e332de68effdeaaab6907d upstream.
As per [1] issue #4,
"The periodic EP scheduler always tries to schedule the EPs
that have large intervals (interval equal to or greater than
128 microframes) into different microframes. So it maintains
an internal counter and increments for each large interval
EP added. When the counter is greater than 128, the scheduler
rejects the new EP. So when the hub re-enumerated 128 times,
it triggers this condition."
This results in Bandwidth error when devices with periodic
endpoints (ISO/INT) having bInterval > 7 are plugged and
unplugged several times on a TUSB73x0 XHCI host.
Workaround this issue by limiting the bInterval to 7
(i.e. interval to 6) for High-speed or faster periodic endpoints.
[1] - http://www.ti.com/lit/er/sllz076/sllz076.pdf
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>
|
|
commit 1c111b6c3844a142e03bcfc2fa17bfbdea08e9dc upstream.
Current abort operation has race.
xhci_handle_command_timeout()
xhci_abort_cmd_ring()
xhci_write_64(CMD_RING_ABORT)
xhci_handshake(5s)
do {
check CMD_RING_RUNNING
udelay(1)
...
COMP_CMD_ABORT event
COMP_CMD_STOP event
xhci_handle_stopped_cmd_ring()
restart cmd_ring
CMD_RING_RUNNING become 1 again
} while ()
return -ETIMEDOUT
xhci_write_64(CMD_RING_ABORT)
/* can abort random command */
To do abort operation correctly, we have to wait both of COMP_CMD_STOP
event and negation of CMD_RING_RUNNING.
But like above, while timeout handler is waiting negation of
CMD_RING_RUNNING, event handler can restart cmd_ring. So timeout
handler never be notice negation of CMD_RING_RUNNING, and retry of
CMD_RING_ABORT can abort random command (BTW, I guess retry of
CMD_RING_ABORT was workaround of this race).
To fix this race, this moves xhci_handle_stopped_cmd_ring() to
xhci_abort_cmd_ring(). And timeout handler waits COMP_CMD_STOP event.
At this point, timeout handler is owner of cmd_ring, and safely
restart cmd_ring by using xhci_handle_stopped_cmd_ring().
[FWIW, as bonus, this way would be easily extend to add CMD_RING_PAUSE
operation]
[locks edited as patch is rebased on other locking fixes -Mathias]
Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit cb4d5ce588c5ff68e0fdd30370a0e6bc2c0a736b upstream.
This is preparation to fix abort operation race (See "xhci: Fix race
related to abort operation"). To make timeout sleepable, use
delayed_work instead of timer.
[change a newly added pending timer fix to pending work -Mathias]
Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit c95a9f83711bf53faeb4ed9bbb63a3f065613dfb upstream.
We normally use the passed in gfp flags for allocations, it's just these
two which were missed.
Fixes: 22d45f01a836 ("usb/xhci: replace pci_*_consistent() with dma_*_coherent()")
Cc: Mathias Nyman <mathias.nyman@intel.com>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit ee8665e28e8d90ce69d4abe5a469c14a8707ae0e upstream.
the tt_info provided by a HS hub might be in use to by a child device
Make sure we free the devices in the correct order.
This is needed in special cases such as when xhci controller is
reset when resuming from hibernate, and all virt_devices are freed.
Also free the virt_devices starting from max slot_id as children
more commonly have higher slot_id than parent.
Reported-by: Guenter Roeck <groeck@chromium.org>
Tested-by: Guenter Roeck <groeck@chromium.org>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
If the last trb before a link is not packet size aligned, and is not
splittable then use a bounce buffer for that chunk of max packet size
unalignable data.
Allocate a max packet size bounce buffer for every segment of a bulk
endpoint ring at the same time as allocating the ring.
If we need to align the data before the link trb in that segment then
copy the data to the segment bounce buffer, dma map it, and enqueue it.
Once the td finishes, or is cancelled, unmap it.
For in transfers we need to first map the bounce buffer, then queue it,
after it finishes, copy the bounce buffer to the original sg list, and
finally unmap it
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This patch fixes some wild pointers produced by xhci_mem_cleanup.
These wild pointers will cause system crash if xhci_mem_cleanup()
is called twice.
Reported-and-tested-by: Pengcheng Li <lpc.li@hisilicon.com>
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.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>
|
|
SuperSpeedPlus doubled the number of transactions per service interval
the isoc endpoints supports.
To support this, xhci 1.1 added Large ESIT Capability (LEC), which
takes into use new bits in the endpoint context to fit the parameters.
If xhci supports LEC, and the device has a SuperSpeedPlus Isoc companion
descriptor then take into use the high bits of max esit payload, and
skip calculating the Mult field as it wouldn't fit. LEC capable
host will calculate the Mult based on other paramenters.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
xhci_endpoint_init() and helper functions were a bit messy.
Adding the higher bandwidth SuperSpeedPlus Isoc support on
top of it would make it even harder to read.
No functional changes.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The speed field of the input slot context should represent the speed the
device is working at.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
In most cases the devices with the speed set to USB_SPEED_SUPER_PLUS
are handled like regular SuperSpeed devices.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
replace dma_pool_alloc and memset with a single call to dma_pool_zalloc
Signed-off-by: Saurabh Sengar <saurabh.truth@gmail.com>
Acked-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Replace the existing two extended capability parsing helper functions with
one called xhci_find_next_ext_cap().
The extended capabilities are read both in pci-quirks before xhci driver is
loaded, and inside the xhci driver when adding ports. The existing helpers
did not suit well for these cases and a lot of custom parsing code was
needed.
The new helper function simplifies these two cases a lot.
The motivation for this rework was that code to support xhci debug
capability needed to parse extended capabilities, and it included
yet another capability parsing helper specific for its needs. With
this solution it debug capability code can use this new helper as well
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Don't use dev_warn() for intened behaviour, use dev_dbg()
Rounding down the interval to the nearest power of 2 is required
by xhci specs.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Remove unneeded NULL test.
The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@@ expression x; @@
-if (x != NULL)
\(kmem_cache_destroy\|mempool_destroy\|dma_pool_destroy\)(x);
// </smpl>
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
xhci 1.1 controllers that support USB 3.1 must provide a protocol speed ID
(PSI) list to inform the driver of the supported speeds.
The PSI list can be read from the xhci supported protocol extended
capabilities.
The PSI values will be used to create a USB 3.1 SuperSpeedPlus capability
descriptor for the xhci USB 3.1 roothub.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Don't check if timer is running with a timer_pending() before
deleting it with del_timer_sync(), this defies the whole point of
the sync part and can cause a possible race.
Instead we just want to make sure the timer is initialized early enough
before we have a chance to delete it.
Cc: <stable@vger.kernel.org>
Reported-by: Oliver Neukum <oneukum@suse.com>
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>
|
|
When xhci_mem_cleanup() is called, it's possible that the command
timer isn't initialized and scheduled. For those cases, to delete
the command timer causes soft-lockup as below stack dump shows.
The patch avoids deleting the command timer if it's not scheduled
with the help of timer_pending().
NMI watchdog: BUG: soft lockup - CPU#40 stuck for 23s! [kworker/40:1:8140]
:
NIP [c000000000150b30] lock_timer_base.isra.34+0x90/0xa0
LR [c000000000150c24] try_to_del_timer_sync+0x34/0xa0
Call Trace:
[c000000f67c975e0] [c0000000015b84f8] mon_ops+0x0/0x8 (unreliable)
[c000000f67c97620] [c000000000150c24] try_to_del_timer_sync+0x34/0xa0
[c000000f67c97660] [c000000000150cf0] del_timer_sync+0x60/0x80
[c000000f67c97690] [c00000000070ac0c] xhci_mem_cleanup+0x5c/0x5e0
[c000000f67c97740] [c00000000070c2e8] xhci_mem_init+0x1158/0x13b0
[c000000f67c97860] [c000000000700978] xhci_init+0x88/0x110
[c000000f67c978e0] [c000000000701644] xhci_gen_setup+0x2b4/0x590
[c000000f67c97970] [c0000000006d4410] xhci_pci_setup+0x40/0x190
[c000000f67c979f0] [c0000000006b1af8] usb_add_hcd+0x418/0xba0
[c000000f67c97ab0] [c0000000006cb15c] usb_hcd_pci_probe+0x1dc/0x5c0
[c000000f67c97b50] [c0000000006d3ba4] xhci_pci_probe+0x64/0x1f0
[c000000f67c97ba0] [c0000000004fe9ac] local_pci_probe+0x6c/0x130
[c000000f67c97c30] [c0000000000e5ce8] work_for_cpu_fn+0x38/0x60
[c000000f67c97c60] [c0000000000eacb8] process_one_work+0x198/0x470
[c000000f67c97cf0] [c0000000000eb6ac] worker_thread+0x37c/0x5a0
[c000000f67c97d80] [c0000000000f2730] kthread+0x110/0x130
[c000000f67c97e30] [c000000000009660] ret_from_kernel_thread+0x5c/0x7c
Cc: <stable@vger.kernel.org>
Reported-by: Priya M. A <priyama2@in.ibm.com>
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
virt_dev->num_cached_rings counts on freed ring and is not updated
correctly. In xhci_free_or_cache_endpoint_ring() function, the free ring
is added into cache and then num_rings_cache is incremented as below:
virt_dev->ring_cache[rings_cached] =
virt_dev->eps[ep_index].ring;
virt_dev->num_rings_cached++;
here, free ring pointer is added to a current index and then
index is incremented.
So current index always points to empty location in the ring cache.
For getting available free ring, current index should be decremented
first and then corresponding ring buffer value should be taken from ring
cache.
But In function xhci_endpoint_init(), the num_rings_cached index is
accessed before decrement.
virt_dev->eps[ep_index].new_ring =
virt_dev->ring_cache[virt_dev->num_rings_cached];
virt_dev->ring_cache[virt_dev->num_rings_cached] = NULL;
virt_dev->num_rings_cached--;
This is bug in manipulating the index of ring cache.
And it should be as below:
virt_dev->num_rings_cached--;
virt_dev->eps[ep_index].new_ring =
virt_dev->ring_cache[virt_dev->num_rings_cached];
virt_dev->ring_cache[virt_dev->num_rings_cached] = NULL;
Cc: <stable@vger.kernel.org>
Signed-off-by: Aman Deep <aman.deep@samsung.com>
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>
|
|
Convert a call to init_timer and accompanying intializations of
the timer's data and function fields to a call to setup_timer.
A simplified version of the semantic match that fixes this problem is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@@
expression t,f,d;
@@
-init_timer(&t);
+setup_timer(&t,f,d);
-t.data = d;
-t.function = f;
// </smpl>
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
current TD"
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>
|
|
The xhci driver will OOPS on resume from S2/S3 if dma_alloc_coherent()
is out of memory. This is a result of two things:
1. xhci_mem_cleanup() in xhci-mem.c free's xhci->lpm_command if
it's not NULL, but doesn't set it to NULL after the free.
2. xhci_mem_cleanup() is called twice on resume, once for normal
restart and once from xhci_mem_init() if dma_alloc_coherent() fails,
resulting in a free of xhci->lpm_command that has already been freed.
The fix is to set xhci->lpm_command to NULL after freeing it.
Signed-off-by: Al Cooper <alcooperx@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
If xhci initialization fails before the roothub bandwidth
domains (xhci->rh_bw[i]) are allocated it will oops when
trying to access rh_bw members in xhci_mem_cleanup().
Reported-by: Manuel Reimer <manuel.reimer@gmx.de>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Now that 3.15 is released, this merges the 'next' branch into 'master',
bringing us to the normal situation where my 'master' branch is the
merge window.
* accumulated work in next: (6809 commits)
ufs: sb mutex merge + mutex_destroy
powerpc: update comments for generic idle conversion
cris: update comments for generic idle conversion
idle: remove cpu_idle() forward declarations
nbd: zero from and len fields in NBD_CMD_DISCONNECT.
mm: convert some level-less printks to pr_*
MAINTAINERS: adi-buildroot-devel is moderated
MAINTAINERS: add linux-api for review of API/ABI changes
mm/kmemleak-test.c: use pr_fmt for logging
fs/dlm/debug_fs.c: replace seq_printf by seq_puts
fs/dlm/lockspace.c: convert simple_str to kstr
fs/dlm/config.c: convert simple_str to kstr
mm: mark remap_file_pages() syscall as deprecated
mm: memcontrol: remove unnecessary memcg argument from soft limit functions
mm: memcontrol: clean up memcg zoneinfo lookup
mm/memblock.c: call kmemleak directly from memblock_(alloc|free)
mm/mempool.c: update the kmemleak stack trace for mempool allocations
lib/radix-tree.c: update the kmemleak stack trace for radix tree allocations
mm: introduce kmemleak_update_trace()
mm/kmemleak.c: use %u to print ->checksum
...
|
|
Lists of endpoints are stored for bandwidth calculation for roothub ports.
Make sure we remove all endpoints from the list before the whole device,
containing its endpoints list_head stuctures, is freed.
This used to be done in the wrong order in xhci_mem_cleanup(),
and triggered an oops in resume from S4 (hibernate).
Cc: stable <stable@vger.kernel.org>
Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.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>
|
|
If we align segment dma pool memory to 64 bytes, then a segment can be located
at 0x10000040 - 0x1000043f, and a segment from another ring at 0x10000440 -
0x1000083f. The last trb in the first segment at 0x10000430 will then translate
to the same radix tree key as the first trb of the second segment, while they
are in different rings!
This patches fixes this by changing the alignment of the dma pool to be 1KB
rather then 64 bytes. An alternative fix would be to reduce the shift used
to calculate the radix tree keys, but that would (slighlty) grow the radix
trees so I believe this is the better fix.
Note this patch is mostly theoretical since in practice I've not seen
the dma_pool actually return not 1KB aligned memory.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
|
|
cmd_ring_reserved_trbs gets decremented by xhci_free_stream_info(), so set it
to 0 after freeing all rings, otherwise it wraps around to a very large value
when rings with streams are free-ed.
Before this patch the wrap-around could be triggered when xhci_resume
calls xhci_mem_cleanup if the controller resume fails.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
|
|
If we're expanding a stream ring, we want to make sure we can add those
ring segments to the radix tree that maps segments to ring pointers.
Try the radix tree insert after the new ring segments have been allocated
(the last segment in the new ring chunk will point to the first newly
allocated segment), but before the new ring segments are linked into the
old ring.
If insert fails on any one segment, remove each segment from the radix
tree, deallocate the new segments, and return. Otherwise, link the new
segments into the tree.
HdG: Add a check to only update stream mappings in xhci_ring_expansion when
the ring is a stream ring.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
|
|
Before this a device needing ie 32 stream ctxs would end up with an entry from
the small_streams_pool which has 256 bytes entries, where as 32 stream ctxs
need 512 bytes. Things actually keep running for a surprisingly long time
before crashing because of this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
|
|
xhci maintains a radix tree for each stream endpoint because it must
be able to map a trb address to the stream ring. Each ring segment
must be added to the ring for this to work. Currently xhci sticks
only the first segment of each stream ring into the radix tree.
Result is that things work initially, but as soon as the first segment
is full xhci can't map the trb address from the completion event to the
stream ring any more -> BOOM. You'll find this message in the logs:
ERROR Transfer event for disabled endpoint or incorrect stream ring
This patch adds a helper function to update the radix tree, and a
function to remove ring segments from the tree. Both functions loop
over the segment list and handles all segments instead of just the
first.
[Note: Sarah changed this patch to add radix_tree_maybe_preload() and
radix_tree_preload_end() calls around the radix tree insert, since we
can now insert entries in interrupt context. There are now two helper
functions to make the code cleaner, and those functions are moved to
make them static.]
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
|
|
This reverts commit e8b373326d8efcaf9ec1da8b618556c89bd5ffc4. 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 7dd09a1af2c7150269350aaa567a11b06e831003.
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>
|
|
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 removes the to_pci_dev() conversion performed to generic struct
device since it is not actually useful (the pointer to the generic device
can be used directly rather through a conversion to pci_dev) and it is pci
bus specific.
This isn't stable material because this code will produce harmless
behavior on non-PCI xHCI hosts. The pci_device pointer is never
dereferenced, only used to re-calculate the underlying device pointer.
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
|
|
This patch removes the unneccessary check 'if (stream_info)' because
there is already a check few lines above which ensures that stream_info
is not NULL.
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
|
