Re: [PATCH] xhci-ring: Fix Null pointer dereference
On 08/28/2014 06:09 PM, Ricardo Ribalda Delgado wrote:
Sure, but the hw leaves my desk until next monday in 30 minutes.
So unless you send the patch right now you will have to wait for
results until next Monday
Thanks!
Great, anytime you can test it is appreciated.
Added the patch to the bug:
https://bugzilla.kernel.org/show_bug.cgi?id=75521
Patch looks like this:
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index c020b09..7aee5a3 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -3544,6 +3544,10 @@ int xhci_discover_or_reset_device(struct usb_hcd *hcd,
struct usb_device *udev)
for (i = 1; i 31; ++i) {
struct xhci_virt_ep *ep = virt_dev-eps[i];
+ /* reset device sets ep states to disabled, also halted ones */
+ ep-ep_state = ~(EP_HALTED || SET_DEQ_PENDING);
+ ep-stopped_td = NULL;
+
if (ep-ep_state EP_HAS_STREAMS) {
xhci_warn(xhci, WARN: endpoint 0x%02x has streams on
device reset, freeing streams.\n,
xhci_get_endpoint_address(i));
-Mathias
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] xhci-ring: Fix Null pointer dereference
On 08/28/2014 03:36 PM, Ricardo Ribalda Delgado wrote: > Hello Mathias > > This is the dmesg output after your patch. No WARN(), no crash :), but > still some weird messages: > > [ 146.511623] usb 2-2: new SuperSpeed USB device number 2 using xhci_hcd > [ 146.531652] usb 2-2: New USB device found, idVendor=0525, idProduct=a4a5 > [ 146.531661] usb 2-2: New USB device strings: Mfr=3, Product=4, > SerialNumber=0 > [ 146.531666] usb 2-2: Product: Mass Storage Gadget > [ 146.531670] usb 2-2: Manufacturer: Linux 3.16.0-qtec-standard+ with net2280 > [ 147.772743] usb-storage 2-2:1.0: USB Mass Storage device detected > [ 147.773018] usb-storage 2-2:1.0: Quirks match for vid 0525 pid a4a5: 1 > [ 147.773185] scsi host6: usb-storage 2-2:1.0 > [ 147.773361] usbcore: registered new interface driver usb-storage > [ 147.788950] usbcore: registered new interface driver uas > [ 148.772699] scsi 6:0:0:0: Direct-Access LinuxFile-Stor > Gadget 0316 PQ: 0 ANSI: 2 > [ 148.773192] sd 6:0:0:0: Attached scsi generic sg2 type 0 > [ 148.774860] sd 6:0:0:0: [sdb] 32768 512-byte logical blocks: (16.7 > MB/16.0 MiB) > [ 148.888294] usb 2-2: reset SuperSpeed USB device number 2 using xhci_hcd > [ 148.905202] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called > with disabled ep 880036f3cc88 > [ 148.905207] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called > with disabled ep 880036f3cc40 > [ 148.906324] xhci_hcd :0e:00.0: Error: Failed finding new dequeue state > [ 148.912639] sd 6:0:0:0: [sdb] Test WP failed, assume Write Enabled > [ 149.014972] sd 6:0:0:0: [sdb] Write cache: enabled, read cache: > enabled, doesn't support DPO or FUA > [ 149.128640] usb 2-2: reset SuperSpeed USB device number 2 using xhci_hcd > [ 149.145953] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called > with disabled ep 880036f3cc88 > [ 149.145963] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called > with disabled ep 880036f3cc40 > [ 149.147525] xhci_hcd :0e:00.0: Error: Failed finding new dequeue state > [ 149.268626] usb 2-2: reset SuperSpeed USB device number 2 using xhci_hcd > [ 149.285563] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called > with disabled ep 880036f3cc88 > [ 149.285573] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called > with disabled ep 880036f3cc40 > [ 149.286904] xhci_hcd :0e:00.0: Error: Failed finding new dequeue state > [ 149.404621] usb 2-2: reset SuperSpeed USB device number 2 using xhci_hcd > [ 149.421397] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called > with disabled ep 880036f3cc88 > [ 149.421404] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called > with disabled ep 880036f3cc40 > [ 149.422855] xhci_hcd :0e:00.0: Error: Failed finding new dequeue state > [ 149.431667] sdb: unknown partition table > [ 149.544713] usb 2-2: reset SuperSpeed USB device number 2 using xhci_hcd > [ 149.561649] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called > with disabled ep 880036f3cc88 > [ 149.561658] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called > with disabled ep 880036f3cc40 > [ 149.563021] xhci_hcd :0e:00.0: Error: Failed finding new dequeue state > [ 149.680733] usb 2-2: reset SuperSpeed USB device number 2 using xhci_hcd > [ 149.697766] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called > with disabled ep 880036f3cc88 > [ 149.697774] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called > with disabled ep 880036f3cc40 > [ 149.699025] xhci_hcd :0e:00.0: Error: Failed finding new dequeue state > [ 149.706700] sd 6:0:0:0: [sdb] Write cache: enabled, read cache: > enabled, doesn't support DPO or FUA > [ 149.706712] sd 6:0:0:0: [sdb] Attached SCSI disk > [ 149.820933] usb 2-2: reset SuperSpeed USB device number 2 using xhci_hcd > [ 149.837887] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called > with disabled ep 880036f3cc88 > [ 149.837895] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called > with disabled ep 880036f3cc40 > [ 149.839242] xhci_hcd :0e:00.0: Error: Failed finding new dequeue state > [ 155.752101] usb 3-1.5.6: reset high-speed USB device number 10 using > ehci-pci > [ 155.866642] cdc_acm 3-1.5.6:1.1: This device cannot do calls on its > own. It is not a modem. > [ 155.866756] cdc_acm 3-1.5.6:1.1: ttyACM0: USB ACM device > [ 155.867613] usb 3-1.5.6: usbfs: process 1521 (pool) did not claim > interface 0 before use > [ 160.471327] pool[1680]: segfault at fc0e61c0 ip > 7f570f036200 sp 7f570639f0d0 error 5 in > libc-2.19.so[7f570efee000+19f000] > > Thanks! > Thanks, I see you already found bug 75521 https://bugzilla.kernel.org/show_bug.cgi?id=75521 I think this is the same cause. Currently I suspect that one halted endpoint is not handled before the entire device is reset. After device reset we try to handle the old halted endpoint that has a pointer to a invalid old dequeue state. I'll see If I can make a patch
Re: [PATCH] xhci-ring: Fix Null pointer dereference
On 08/27/2014 07:10 PM, Ricardo Ribalda Delgado wrote: > Perhaps we could apply both patches to current tree and backport mine > to older kernels? > The already applied patch fixes many other issues than just this one. backporting it to stable < 3.13 turned out to not be that difficult, stable maintainers said they can do it themselves. Stable kernels prefer patches that are already upstream, as Documentation/stable_kernel_rules.txt states: "- It or an equivalent fix must already exist in Linus' tree (upstream)." There is no need for the other patch anymore, not upstream nor to stable -Mathias -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] xhci-ring: Fix Null pointer dereference
On 08/27/2014 07:10 PM, Ricardo Ribalda Delgado wrote: Perhaps we could apply both patches to current tree and backport mine to older kernels? The already applied patch fixes many other issues than just this one. backporting it to stable 3.13 turned out to not be that difficult, stable maintainers said they can do it themselves. Stable kernels prefer patches that are already upstream, as Documentation/stable_kernel_rules.txt states: - It or an equivalent fix must already exist in Linus' tree (upstream). There is no need for the other patch anymore, not upstream nor to stable -Mathias -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] xhci-ring: Fix Null pointer dereference
On 08/28/2014 03:36 PM, Ricardo Ribalda Delgado wrote: Hello Mathias This is the dmesg output after your patch. No WARN(), no crash :), but still some weird messages: [ 146.511623] usb 2-2: new SuperSpeed USB device number 2 using xhci_hcd [ 146.531652] usb 2-2: New USB device found, idVendor=0525, idProduct=a4a5 [ 146.531661] usb 2-2: New USB device strings: Mfr=3, Product=4, SerialNumber=0 [ 146.531666] usb 2-2: Product: Mass Storage Gadget [ 146.531670] usb 2-2: Manufacturer: Linux 3.16.0-qtec-standard+ with net2280 [ 147.772743] usb-storage 2-2:1.0: USB Mass Storage device detected [ 147.773018] usb-storage 2-2:1.0: Quirks match for vid 0525 pid a4a5: 1 [ 147.773185] scsi host6: usb-storage 2-2:1.0 [ 147.773361] usbcore: registered new interface driver usb-storage [ 147.788950] usbcore: registered new interface driver uas [ 148.772699] scsi 6:0:0:0: Direct-Access LinuxFile-Stor Gadget 0316 PQ: 0 ANSI: 2 [ 148.773192] sd 6:0:0:0: Attached scsi generic sg2 type 0 [ 148.774860] sd 6:0:0:0: [sdb] 32768 512-byte logical blocks: (16.7 MB/16.0 MiB) [ 148.888294] usb 2-2: reset SuperSpeed USB device number 2 using xhci_hcd [ 148.905202] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called with disabled ep 880036f3cc88 [ 148.905207] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called with disabled ep 880036f3cc40 [ 148.906324] xhci_hcd :0e:00.0: Error: Failed finding new dequeue state [ 148.912639] sd 6:0:0:0: [sdb] Test WP failed, assume Write Enabled [ 149.014972] sd 6:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 149.128640] usb 2-2: reset SuperSpeed USB device number 2 using xhci_hcd [ 149.145953] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called with disabled ep 880036f3cc88 [ 149.145963] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called with disabled ep 880036f3cc40 [ 149.147525] xhci_hcd :0e:00.0: Error: Failed finding new dequeue state [ 149.268626] usb 2-2: reset SuperSpeed USB device number 2 using xhci_hcd [ 149.285563] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called with disabled ep 880036f3cc88 [ 149.285573] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called with disabled ep 880036f3cc40 [ 149.286904] xhci_hcd :0e:00.0: Error: Failed finding new dequeue state [ 149.404621] usb 2-2: reset SuperSpeed USB device number 2 using xhci_hcd [ 149.421397] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called with disabled ep 880036f3cc88 [ 149.421404] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called with disabled ep 880036f3cc40 [ 149.422855] xhci_hcd :0e:00.0: Error: Failed finding new dequeue state [ 149.431667] sdb: unknown partition table [ 149.544713] usb 2-2: reset SuperSpeed USB device number 2 using xhci_hcd [ 149.561649] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called with disabled ep 880036f3cc88 [ 149.561658] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called with disabled ep 880036f3cc40 [ 149.563021] xhci_hcd :0e:00.0: Error: Failed finding new dequeue state [ 149.680733] usb 2-2: reset SuperSpeed USB device number 2 using xhci_hcd [ 149.697766] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called with disabled ep 880036f3cc88 [ 149.697774] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called with disabled ep 880036f3cc40 [ 149.699025] xhci_hcd :0e:00.0: Error: Failed finding new dequeue state [ 149.706700] sd 6:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 149.706712] sd 6:0:0:0: [sdb] Attached SCSI disk [ 149.820933] usb 2-2: reset SuperSpeed USB device number 2 using xhci_hcd [ 149.837887] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called with disabled ep 880036f3cc88 [ 149.837895] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called with disabled ep 880036f3cc40 [ 149.839242] xhci_hcd :0e:00.0: Error: Failed finding new dequeue state [ 155.752101] usb 3-1.5.6: reset high-speed USB device number 10 using ehci-pci [ 155.866642] cdc_acm 3-1.5.6:1.1: This device cannot do calls on its own. It is not a modem. [ 155.866756] cdc_acm 3-1.5.6:1.1: ttyACM0: USB ACM device [ 155.867613] usb 3-1.5.6: usbfs: process 1521 (pool) did not claim interface 0 before use [ 160.471327] pool[1680]: segfault at fc0e61c0 ip 7f570f036200 sp 7f570639f0d0 error 5 in libc-2.19.so[7f570efee000+19f000] Thanks! Thanks, I see you already found bug 75521 https://bugzilla.kernel.org/show_bug.cgi?id=75521 I think this is the same cause. Currently I suspect that one halted endpoint is not handled before the entire device is reset. After device reset we try to handle the old halted endpoint that has a pointer to a invalid old dequeue state. I'll see If I can make a patch that clears all pending halted endpoint states (xhci software internal states) when
Re: [PATCH] xhci-ring: Fix Null pointer dereference
On 08/27/2014 05:14 PM, Ricardo Ribalda Delgado wrote: > At least I have seen the issue on Debian 3.14 and 3.16. Is your patch > going to be backported to linux-stable? The computer crashes very very > badly > Yes, it is, but it might need some additional work as it won't apply cleanly on older versions http://marc.info/?l=linux-usb=140913688327011=2 -Mathias -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] xhci-ring: Fix Null pointer dereference
On 08/26/2014 06:47 PM, Ricardo Ribalda Delgado wrote: > While testing a usb gadget I managed to crash completely the host > computer. This was due to a NULL pointer derefence. > > This patch avoids the crash although the kernel still outputs some > warnings. > > Without this patch, kernels from (at least) 3.14 can be crashed with > mass storage gadgets. > > Affected host: NEC Corporation uPD720200 USB 3.0 > This should not be necessary anymore after commit 365038d83313951d6ace15342eb24624bbef1666 xhci: rework cycle bit checking for new dequeue pointers http://marc.info/?l=linux-usb=140844993115671=2 Which was just added to Greg's usb-linus branch. It checks that the new_deq_ptr and new_deq_seg are valid before calling xhci_queue_new_dequeue_state() -Mathias -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] xhci: rework cycle bit checking for new dequeue pointers
On 08/21/2014 01:06 AM, Joseph Salisbury wrote:
> On 08/19/2014 08:17 AM, Mathias Nyman wrote:
>> When we manually need to move the TR dequeue pointer we need to set the
>> correct cycle bit as well. Previously we used the trb pointer from the
>> last event received as a base, but this was changed in
>> commit 1f81b6d22a59 ("usb: xhci: Prefer endpoint context dequeue pointer")
>> to use the dequeue pointer from the endpoint context 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: 1f81b6d22a59 ("usb: xhci: Prefer endpoint context dequeue pointer")
>> Reported-by: Maciej Puzio
>> Reported-by: Evan Langlois
>> Reviewed-by: Julius Werner
>> Tested-by: Maciej Puzio
>> Tested-by: Evan Langlois
>> Signed-off-by: Mathias Nyman
>> Cc: sta...@vger.kernel.org
>> ---
>> drivers/usb/host/xhci-ring.c | 101
>> +--
>> drivers/usb/host/xhci.c | 3 ++
>> 2 files changed, 42 insertions(+), 62 deletions(-)
>>
>> diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
>> index ac8cf23..abed30b 100644
>> --- a/drivers/usb/host/xhci-ring.c
>> +++ b/drivers/usb/host/xhci-ring.c
>> @@ -364,32 +364,6 @@ static void ring_doorbell_for_active_rings(struct
>> xhci_hcd *xhci,
>> }
>> }
>>
>> -/*
>> - * Find the segment that trb is in. Start searching in start_seg.
>> - * If we must move past a segment that has a link TRB with a toggle cycle
>> state
>> - * bit set, then we will toggle the value pointed at by cycle_state.
>> - */
>> -static struct xhci_segment *find_trb_seg(
>> -struct xhci_segment *start_seg,
>> -union xhci_trb *trb, int *cycle_state)
>> -{
>> -struct xhci_segment *cur_seg = start_seg;
>> -struct xhci_generic_trb *generic_trb;
>> -
>> -while (cur_seg->trbs > trb ||
>> -_seg->trbs[TRBS_PER_SEGMENT - 1] < trb) {
>> -generic_trb = _seg->trbs[TRBS_PER_SEGMENT - 1].generic;
>> -if (generic_trb->field[3] & cpu_to_le32(LINK_TOGGLE))
>> -*cycle_state ^= 0x1;
>> -cur_seg = cur_seg->next;
>> -if (cur_seg == start_seg)
>> -/* Looped over the entire list. Oops! */
>> -return NULL;
>> -}
>> -return cur_seg;
>> -}
>> -
>> -
>> static struct xhci_ring *xhci_triad_to_transfer_ring(struct xhci_hcd *xhci,
>> unsigned int slot_id, unsigned int ep_index,
>> unsigned int stream_id)
>> @@ -459,9 +433,12 @@ void xhci_find_new_dequeue_state(struct xhci_hcd *xhci,
>> struct xhci_virt_device *dev = xhci->devs[slot_id];
>> struct xhci_virt_ep *ep = >eps[ep_index];
>> struct xhci_ring *ep_ring;
>> -struct xhci_generic_trb *trb;
>> +struct xhci_segment *new_seg;
>> +union xhci_trb *new_deq;
>> dma_addr_t addr;
>> u64 hw_dequeue;
>> +bool cycle_found = false;
>> +bool td_last_trb_found = false;
>>
>> ep_ring = xhci_triad_to_transfer_ring(xhci, slot_id,
>> ep_index, stream_id);
>> @@ -486,45 +463,45 @@ void xhci_find_new_dequeue_state(struct xhci_hcd *xhci,
>> hw_dequeue = le64_to_cpu(ep_ctx->deq);
>> }
>>
>> -/* Find virtual address and segment of hardware dequeue pointer */
>> -state->new_deq_seg = ep_ring->deq_seg;
>> -state->new_deq_ptr = ep_ring->dequeue;
>> -while (xhci_trb_virt_to_dma(state->new_deq_seg, state->new_deq_ptr)
>> -!= (dma_addr_t)(hw_dequeue & ~0xf)) {
>> -next_trb(xhci, ep_ring, >new_deq_seg,
>> ->new_deq_ptr);
>> -if (state->new_deq_ptr == ep_ring->dequeue) {
>> -WARN_ON(1);
>> -return;
>> -}
>> -}
>> +new_seg = ep_ring->deq_seg;
>> +new_deq = ep_ring->dequeue;
>> +state->new_cycle_state = hw_
Re: [PATCH 3/3] xhci: rework cycle bit checking for new dequeue pointers
On 08/21/2014 01:06 AM, Joseph Salisbury wrote:
On 08/19/2014 08:17 AM, Mathias Nyman wrote:
When we manually need to move the TR dequeue pointer we need to set the
correct cycle bit as well. Previously we used the trb pointer from the
last event received as a base, but this was changed in
commit 1f81b6d22a59 (usb: xhci: Prefer endpoint context dequeue pointer)
to use the dequeue pointer from the endpoint context 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: 1f81b6d22a59 (usb: xhci: Prefer endpoint context dequeue pointer)
Reported-by: Maciej Puzio mx34...@gmail.com
Reported-by: Evan Langlois uudrui...@gmail.com
Reviewed-by: Julius Werner jwer...@chromium.org
Tested-by: Maciej Puzio mx34...@gmail.com
Tested-by: Evan Langlois uudrui...@gmail.com
Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com
Cc: sta...@vger.kernel.org
---
drivers/usb/host/xhci-ring.c | 101
+--
drivers/usb/host/xhci.c | 3 ++
2 files changed, 42 insertions(+), 62 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index ac8cf23..abed30b 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -364,32 +364,6 @@ static void ring_doorbell_for_active_rings(struct
xhci_hcd *xhci,
}
}
-/*
- * Find the segment that trb is in. Start searching in start_seg.
- * If we must move past a segment that has a link TRB with a toggle cycle
state
- * bit set, then we will toggle the value pointed at by cycle_state.
- */
-static struct xhci_segment *find_trb_seg(
-struct xhci_segment *start_seg,
-union xhci_trb *trb, int *cycle_state)
-{
-struct xhci_segment *cur_seg = start_seg;
-struct xhci_generic_trb *generic_trb;
-
-while (cur_seg-trbs trb ||
-cur_seg-trbs[TRBS_PER_SEGMENT - 1] trb) {
-generic_trb = cur_seg-trbs[TRBS_PER_SEGMENT - 1].generic;
-if (generic_trb-field[3] cpu_to_le32(LINK_TOGGLE))
-*cycle_state ^= 0x1;
-cur_seg = cur_seg-next;
-if (cur_seg == start_seg)
-/* Looped over the entire list. Oops! */
-return NULL;
-}
-return cur_seg;
-}
-
-
static struct xhci_ring *xhci_triad_to_transfer_ring(struct xhci_hcd *xhci,
unsigned int slot_id, unsigned int ep_index,
unsigned int stream_id)
@@ -459,9 +433,12 @@ void xhci_find_new_dequeue_state(struct xhci_hcd *xhci,
struct xhci_virt_device *dev = xhci-devs[slot_id];
struct xhci_virt_ep *ep = dev-eps[ep_index];
struct xhci_ring *ep_ring;
-struct xhci_generic_trb *trb;
+struct xhci_segment *new_seg;
+union xhci_trb *new_deq;
dma_addr_t addr;
u64 hw_dequeue;
+bool cycle_found = false;
+bool td_last_trb_found = false;
ep_ring = xhci_triad_to_transfer_ring(xhci, slot_id,
ep_index, stream_id);
@@ -486,45 +463,45 @@ void xhci_find_new_dequeue_state(struct xhci_hcd *xhci,
hw_dequeue = le64_to_cpu(ep_ctx-deq);
}
-/* Find virtual address and segment of hardware dequeue pointer */
-state-new_deq_seg = ep_ring-deq_seg;
-state-new_deq_ptr = ep_ring-dequeue;
-while (xhci_trb_virt_to_dma(state-new_deq_seg, state-new_deq_ptr)
-!= (dma_addr_t)(hw_dequeue ~0xf)) {
-next_trb(xhci, ep_ring, state-new_deq_seg,
-state-new_deq_ptr);
-if (state-new_deq_ptr == ep_ring-dequeue) {
-WARN_ON(1);
-return;
-}
-}
+new_seg = ep_ring-deq_seg;
+new_deq = ep_ring-dequeue;
+state-new_cycle_state = hw_dequeue 0x1;
+
/*
- * Find cycle state for last_trb, starting at old cycle state of
- * hw_dequeue. If there is only one segment ring, find_trb_seg() will
- * return immediately and cannot toggle the cycle state if this search
- * wraps around, so add one more toggle manually in that case.
+ * We want to find the pointer, segment and cycle state of the new trb
+ * (the one after current TD's last_trb). We know the cycle state at
+ * hw_dequeue, so walk the ring until both hw_dequeue and last_trb are
+ * found.
*/
-state-new_cycle_state = hw_dequeue 0x1;
-if (ep_ring-first_seg == ep_ring-first_seg-next
-cur_td-last_trb state-new_deq_ptr)
-state-new_cycle_state ^= 0x1;
+do
Re: [PATCH] xhci-ring: Fix Null pointer dereference
On 08/26/2014 06:47 PM, Ricardo Ribalda Delgado wrote: While testing a usb gadget I managed to crash completely the host computer. This was due to a NULL pointer derefence. This patch avoids the crash although the kernel still outputs some warnings. Without this patch, kernels from (at least) 3.14 can be crashed with mass storage gadgets. Affected host: NEC Corporation uPD720200 USB 3.0 This should not be necessary anymore after commit 365038d83313951d6ace15342eb24624bbef1666 xhci: rework cycle bit checking for new dequeue pointers http://marc.info/?l=linux-usbm=140844993115671w=2 Which was just added to Greg's usb-linus branch. It checks that the new_deq_ptr and new_deq_seg are valid before calling xhci_queue_new_dequeue_state() -Mathias -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] xhci-ring: Fix Null pointer dereference
On 08/27/2014 05:14 PM, Ricardo Ribalda Delgado wrote: At least I have seen the issue on Debian 3.14 and 3.16. Is your patch going to be backported to linux-stable? The computer crashes very very badly Yes, it is, but it might need some additional work as it won't apply cleanly on older versions http://marc.info/?l=linux-usbm=140913688327011w=2 -Mathias -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHv2] gpio-lynxpoint: enable input sensing in resume
It appears that input sensing bit might be reset during
suspend/resume. Set input sensing again for all requested gpios
in resume
Tested-by: Jerome Blin
Signed-off-by: Mathias Nyman
---
drivers/gpio/gpio-lynxpoint.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpio/gpio-lynxpoint.c b/drivers/gpio/gpio-lynxpoint.c
index ff9eb91..fa945ec 100644
--- a/drivers/gpio/gpio-lynxpoint.c
+++ b/drivers/gpio/gpio-lynxpoint.c
@@ -407,9 +407,27 @@ static int lp_gpio_runtime_resume(struct device *dev)
return 0;
}
+static int lp_gpio_resume(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct lp_gpio *lg = platform_get_drvdata(pdev);
+ unsigned long reg;
+ int i;
+
+ /* on some hardware suspend clears input sensing, re-enable it here */
+ for (i = 0; i < lg->chip.ngpio; i++) {
+ if (gpiochip_is_requested(>chip, i) != NULL) {
+ reg = lp_gpio_reg(>chip, i, LP_CONFIG2);
+ outl(inl(reg) & ~GPINDIS_BIT, reg);
+ }
+ }
+ return 0;
+}
+
static const struct dev_pm_ops lp_gpio_pm_ops = {
.runtime_suspend = lp_gpio_runtime_suspend,
.runtime_resume = lp_gpio_runtime_resume,
+ .resume = lp_gpio_resume,
};
static const struct acpi_device_id lynxpoint_gpio_acpi_match[] = {
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] gpio-lynxpoint: enable input sensing in resume
On 08/19/2014 01:22 PM, Mika Westerberg wrote:
> On Tue, Aug 19, 2014 at 01:30:28PM +0300, Mathias Nyman wrote:
>> It appears that input sensing bit might be reset during
>> suspend/resume. Set input sensing again for all requested gpios
>> in resume
>>
>> Tested-by: Jerome Blin
>> Signed-off-by: Mathias Nyman
>> ---
>> drivers/gpio/gpio-lynxpoint.c | 24
>> 1 file changed, 24 insertions(+)
>>
>> diff --git a/drivers/gpio/gpio-lynxpoint.c b/drivers/gpio/gpio-lynxpoint.c
>> index ff9eb91..4165672 100644
>> --- a/drivers/gpio/gpio-lynxpoint.c
>> +++ b/drivers/gpio/gpio-lynxpoint.c
>> @@ -407,9 +407,33 @@ static int lp_gpio_runtime_resume(struct device *dev)
>> return 0;
>> }
>>
>> +static int lp_gpio_suspend(struct device *dev)
>> +{
>> +return 0;
>> +}
>
> If this function doesn't do anything why it needs to be defined here?
>
I guess it doesn't, Added the suspend and resume functions as a pair, but only
resume turned out to do something,
I'll remove it.
-Mathias
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] gpio-lynxpoint: enable input sensing in resume
It appears that input sensing bit might be reset during
suspend/resume. Set input sensing again for all requested gpios
in resume
Tested-by: Jerome Blin
Signed-off-by: Mathias Nyman
---
drivers/gpio/gpio-lynxpoint.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/gpio/gpio-lynxpoint.c b/drivers/gpio/gpio-lynxpoint.c
index ff9eb91..4165672 100644
--- a/drivers/gpio/gpio-lynxpoint.c
+++ b/drivers/gpio/gpio-lynxpoint.c
@@ -407,9 +407,33 @@ static int lp_gpio_runtime_resume(struct device *dev)
return 0;
}
+static int lp_gpio_suspend(struct device *dev)
+{
+ return 0;
+}
+
+static int lp_gpio_resume(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct lp_gpio *lg = platform_get_drvdata(pdev);
+ unsigned long reg;
+ int i;
+
+ /* on some hardware suspend clears input sensing, re-enable it here */
+ for (i = 0; i < lg->chip.ngpio; i++) {
+ if (gpiochip_is_requested(>chip, i) != NULL) {
+ reg = lp_gpio_reg(>chip, i, LP_CONFIG2);
+ outl(inl(reg) & ~GPINDIS_BIT, reg);
+ }
+ }
+ return 0;
+}
+
static const struct dev_pm_ops lp_gpio_pm_ops = {
.runtime_suspend = lp_gpio_runtime_suspend,
.runtime_resume = lp_gpio_runtime_resume,
+ .suspend = lp_gpio_suspend,
+ .resume = lp_gpio_resume,
};
static const struct acpi_device_id lynxpoint_gpio_acpi_match[] = {
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] gpio-lynxpoint: enable input sensing in resume
It appears that input sensing bit might be reset during
suspend/resume. Set input sensing again for all requested gpios
in resume
Tested-by: Jerome Blin jerome.b...@intel.com
Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com
---
drivers/gpio/gpio-lynxpoint.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/gpio/gpio-lynxpoint.c b/drivers/gpio/gpio-lynxpoint.c
index ff9eb91..4165672 100644
--- a/drivers/gpio/gpio-lynxpoint.c
+++ b/drivers/gpio/gpio-lynxpoint.c
@@ -407,9 +407,33 @@ static int lp_gpio_runtime_resume(struct device *dev)
return 0;
}
+static int lp_gpio_suspend(struct device *dev)
+{
+ return 0;
+}
+
+static int lp_gpio_resume(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct lp_gpio *lg = platform_get_drvdata(pdev);
+ unsigned long reg;
+ int i;
+
+ /* on some hardware suspend clears input sensing, re-enable it here */
+ for (i = 0; i lg-chip.ngpio; i++) {
+ if (gpiochip_is_requested(lg-chip, i) != NULL) {
+ reg = lp_gpio_reg(lg-chip, i, LP_CONFIG2);
+ outl(inl(reg) ~GPINDIS_BIT, reg);
+ }
+ }
+ return 0;
+}
+
static const struct dev_pm_ops lp_gpio_pm_ops = {
.runtime_suspend = lp_gpio_runtime_suspend,
.runtime_resume = lp_gpio_runtime_resume,
+ .suspend = lp_gpio_suspend,
+ .resume = lp_gpio_resume,
};
static const struct acpi_device_id lynxpoint_gpio_acpi_match[] = {
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] gpio-lynxpoint: enable input sensing in resume
On 08/19/2014 01:22 PM, Mika Westerberg wrote:
On Tue, Aug 19, 2014 at 01:30:28PM +0300, Mathias Nyman wrote:
It appears that input sensing bit might be reset during
suspend/resume. Set input sensing again for all requested gpios
in resume
Tested-by: Jerome Blin jerome.b...@intel.com
Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com
---
drivers/gpio/gpio-lynxpoint.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/gpio/gpio-lynxpoint.c b/drivers/gpio/gpio-lynxpoint.c
index ff9eb91..4165672 100644
--- a/drivers/gpio/gpio-lynxpoint.c
+++ b/drivers/gpio/gpio-lynxpoint.c
@@ -407,9 +407,33 @@ static int lp_gpio_runtime_resume(struct device *dev)
return 0;
}
+static int lp_gpio_suspend(struct device *dev)
+{
+return 0;
+}
If this function doesn't do anything why it needs to be defined here?
I guess it doesn't, Added the suspend and resume functions as a pair, but only
resume turned out to do something,
I'll remove it.
-Mathias
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv2] gpio-lynxpoint: enable input sensing in resume
It appears that input sensing bit might be reset during
suspend/resume. Set input sensing again for all requested gpios
in resume
Tested-by: Jerome Blin jerome.b...@intel.com
Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com
---
drivers/gpio/gpio-lynxpoint.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpio/gpio-lynxpoint.c b/drivers/gpio/gpio-lynxpoint.c
index ff9eb91..fa945ec 100644
--- a/drivers/gpio/gpio-lynxpoint.c
+++ b/drivers/gpio/gpio-lynxpoint.c
@@ -407,9 +407,27 @@ static int lp_gpio_runtime_resume(struct device *dev)
return 0;
}
+static int lp_gpio_resume(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct lp_gpio *lg = platform_get_drvdata(pdev);
+ unsigned long reg;
+ int i;
+
+ /* on some hardware suspend clears input sensing, re-enable it here */
+ for (i = 0; i lg-chip.ngpio; i++) {
+ if (gpiochip_is_requested(lg-chip, i) != NULL) {
+ reg = lp_gpio_reg(lg-chip, i, LP_CONFIG2);
+ outl(inl(reg) ~GPINDIS_BIT, reg);
+ }
+ }
+ return 0;
+}
+
static const struct dev_pm_ops lp_gpio_pm_ops = {
.runtime_suspend = lp_gpio_runtime_suspend,
.runtime_resume = lp_gpio_runtime_resume,
+ .resume = lp_gpio_resume,
};
static const struct acpi_device_id lynxpoint_gpio_acpi_match[] = {
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] pinctrl: baytrail: resolve unbalanced IRQ wake disable warning
Add the IRQCHIP_SKIP_SET_WAKE flag to baytrail gpio irq_chip
to resolve unbalaced IRQ wake disable warnings.
Suggested-by: Borun Fu
Signed-off-by: Mathias Nyman
---
drivers/pinctrl/pinctrl-baytrail.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/pinctrl/pinctrl-baytrail.c
b/drivers/pinctrl/pinctrl-baytrail.c
index 975572e..f8359aa 100644
--- a/drivers/pinctrl/pinctrl-baytrail.c
+++ b/drivers/pinctrl/pinctrl-baytrail.c
@@ -481,6 +481,7 @@ static struct irq_chip byt_irqchip = {
.irq_set_type = byt_irq_type,
.irq_request_resources = byt_irq_reqres,
.irq_release_resources = byt_irq_relres,
+ .flags = IRQCHIP_SKIP_SET_WAKE,
};
static void byt_gpio_irq_init_hw(struct byt_gpio *vg)
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] pinctrl: baytrail: resolve unbalanced IRQ wake disable warning
Add the IRQCHIP_SKIP_SET_WAKE flag to baytrail gpio irq_chip
to resolve unbalaced IRQ wake disable warnings.
Suggested-by: Borun Fu borun...@intel.com
Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com
---
drivers/pinctrl/pinctrl-baytrail.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/pinctrl/pinctrl-baytrail.c
b/drivers/pinctrl/pinctrl-baytrail.c
index 975572e..f8359aa 100644
--- a/drivers/pinctrl/pinctrl-baytrail.c
+++ b/drivers/pinctrl/pinctrl-baytrail.c
@@ -481,6 +481,7 @@ static struct irq_chip byt_irqchip = {
.irq_set_type = byt_irq_type,
.irq_request_resources = byt_irq_reqres,
.irq_release_resources = byt_irq_relres,
+ .flags = IRQCHIP_SKIP_SET_WAKE,
};
static void byt_gpio_irq_init_hw(struct byt_gpio *vg)
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: xhci: Fix Set TR Dequeue Pointer cycle state for quirky xHCs
On 07/17/2014 10:50 PM, Julius Werner wrote: >> Hmm. Wouldn't it be safer to have a quirk for this, and only enable >> the workaround if the Asmedia controller is detected? This code is so >> complicated that it is difficult to see whether this could have a >> harmful effect on controllers without the bug. > > Sorry for making it complicated, but it kinda has been like that > before already... I don't think the new patch adds much confusion on > its own. I would really advise against making this a quirk: checking > for it in every case essentially doesn't cost us anything (just one > more register compare that is negligible against all the > cache-coherent memory accesses of walking the ring), and hardcoding a > quirk would mean that we have to identify and add every host > controller that does this individually. > > I still haven't seen anything in the XHCI spec that actually forbids > this behavior, so it might be a perfectly legal interpretation and who > knows how many host controllers chose to do it that way. Until we find > them all, we would have some really bad and hard to track down bugs on > those controllers (we really just got lucky this time that Maciej was > able to catch it in a bisect). I think it's better to program the > driver defensively and able to deal with unexpected situations in > general. > -- > To unsubscribe from this list: send the line "unsubscribe linux-usb" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > It's starting to get a bit too complicated. xhci find_new_dequeue_state() now has four places where it can toggle the cycle bit in addition to the cycle toggle in find_trb_seg(). In the end we really just want to do it max once. I'll see if I can simplify the whole cycle bit code somehow. If not, then we need to take this or revert the original patch -Mathias -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 06/10 linux-next] xhci: remove unnecessary break after return
On 07/24/2014 11:18 AM, Fabian Frederick wrote: > Signed-off-by: Fabian Frederick > --- Acked-by: Mathias Nyman -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 06/10 linux-next] xhci: remove unnecessary break after return
On 07/24/2014 11:18 AM, Fabian Frederick wrote: Signed-off-by: Fabian Frederick f...@skynet.be --- Acked-by: Mathias Nyman mathias.ny...@linux.intel.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: xhci: Fix Set TR Dequeue Pointer cycle state for quirky xHCs
On 07/17/2014 10:50 PM, Julius Werner wrote: Hmm. Wouldn't it be safer to have a quirk for this, and only enable the workaround if the Asmedia controller is detected? This code is so complicated that it is difficult to see whether this could have a harmful effect on controllers without the bug. Sorry for making it complicated, but it kinda has been like that before already... I don't think the new patch adds much confusion on its own. I would really advise against making this a quirk: checking for it in every case essentially doesn't cost us anything (just one more register compare that is negligible against all the cache-coherent memory accesses of walking the ring), and hardcoding a quirk would mean that we have to identify and add every host controller that does this individually. I still haven't seen anything in the XHCI spec that actually forbids this behavior, so it might be a perfectly legal interpretation and who knows how many host controllers chose to do it that way. Until we find them all, we would have some really bad and hard to track down bugs on those controllers (we really just got lucky this time that Maciej was able to catch it in a bisect). I think it's better to program the driver defensively and able to deal with unexpected situations in general. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html It's starting to get a bit too complicated. xhci find_new_dequeue_state() now has four places where it can toggle the cycle bit in addition to the cycle toggle in find_trb_seg(). In the end we really just want to do it max once. I'll see if I can simplify the whole cycle bit code somehow. If not, then we need to take this or revert the original patch -Mathias -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/5] usb: xhci: Correct last context entry calculation for Configure Endpoint
On 06/24/2014 05:10 PM, Greg KH wrote: > On Tue, Jun 24, 2014 at 05:14:42PM +0300, Mathias Nyman wrote: >> From: Julius Werner >> >> The current XHCI driver recalculates the Context Entries field in the >> Slot Context on every add_endpoint() and drop_endpoint() call. In the >> case of drop_endpoint(), it seems to assume that the add_flags will >> always contain every endpoint for the new configuration, which is not >> necessarily correct if you don't make assumptions about how the USB core >> uses the add_endpoint/drop_endpoint interface (add_flags only contains >> endpoints that are new additions in the new configuration). >> >> Furthermore, EP0_FLAG is not consistently set in add_flags throughout >> the lifetime of a device. This means that when all endpoints are >> dropped, the Context Entries field can be set to 0 (which is invalid and >> may cause a Parameter Error) or -1 (which is interpreted as 31 and >> causes the driver to keep using the old, incorrect value). >> >> The only surefire way to set this field right is to also take all >> existing endpoints into account, and to force the value to 1 (meaning >> only EP0 is active) if no other endpoint is found. This patch implements >> that as a single step in the final check_bandwidth() call and removes >> the intermediary calculations from add_endpoint() and drop_endpoint(). >> >> Signed-off-by: Julius Werner >> Signed-off-by: Mathias Nyman >> --- >> drivers/usb/host/xhci.c | 51 >> + >> 1 file changed, 18 insertions(+), 33 deletions(-) > > Is this something for older (i.e. stable) kernels? > This was intentionally left out of stable, reasoning in a previous mail was: "We discussed with Sarah that we should try this out and queue it for usb-linus. This clearly fixes the generation of a invalid slot context if all endpoints are dropped. But because there hasn't been any reported issue about the other case this changes (always setting context entries to last valid ep in target configuration), and spec still has this tiny contradiction in this case, we should keep this out of stable. At least for now, until it gets some real world testing coverage." The mail: http://marc.info/?l=linux-usb=13987912807=2 Or if you prefer this patch could go to usb-next instead. -Mathias -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/5] xhci: Fix runtime suspended xhci from blocking system suspend.
From: "Wang, Yu"
The system suspend flow as following:
1, Freeze all user processes and kenrel threads.
2, Try to suspend all devices.
2.1, If pci device is in RPM suspended state, then pci driver will try
to resume it to RPM active state in the prepare stage.
2.2, xhci_resume function calls usb_hcd_resume_root_hub to queue two
workqueue items to resume usb2 roothub devices.
2.3, Call suspend callbacks of devices.
2.3.1, All suspend callbacks of all hcd's children, including
roothub devices are called.
2.3.2, Finally, hcd_pci_suspend callback is called.
Due to workqueue threads were already frozen in step 1, the workqueue
items can't be scheduled, and the roothub devices can't be resumed in
this flow. The HCD_FLAG_WAKEUP_PENDING flag which is set in
usb_hcd_resume_root_hub won't be cleared. Finally,
hcd_pci_suspend will return -EBUSY, and system suspend fails.
The reason why this issue doesn't show up very often is due to that
choose_wakeup will be called in step 2.3.1. In step 2.3.1, if
udev->do_remote_wakeup is not equal to device_may_wakeup(>dev), then
udev will resume to RPM active for changing the wakeup settings. This
has been a lucky hit which hides this issue.
For some special xHCI controllers which have no USB2 port, then roothub
will not match hub driver due to probe failed. Then its
do_remote_wakeup will be set to zero, and we won't be as lucky.
xhci driver doesn't need to resume roothub devices everytime like in
the above case. It's only needed when there are pending event TRBs.
This patch should be back-ported to kernels as old as 3.2, that
contains the commit f69e3120df82391a0ee8118e0a156239a06b2afb
"USB: XHCI: resume root hubs when the controller resumes"
Cc: sta...@vger.kernel.org # 3.2
Signed-off-by: Wang, Yu
Acked-by: Alan Stern
[use readl() instead of removed xhci_readl(), reword commit message -Mathias]
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 013aabb..f07be65 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -936,7 +936,7 @@ int xhci_suspend(struct xhci_hcd *xhci)
*/
int xhci_resume(struct xhci_hcd *xhci, bool hibernated)
{
- u32 command, temp = 0;
+ u32 command, temp = 0, status;
struct usb_hcd *hcd = xhci_to_hcd(xhci);
struct usb_hcd *secondary_hcd;
int retval = 0;
@@ -1054,8 +1054,12 @@ int xhci_resume(struct xhci_hcd *xhci, bool hibernated)
done:
if (retval == 0) {
- usb_hcd_resume_root_hub(hcd);
- usb_hcd_resume_root_hub(xhci->shared_hcd);
+ /* Resume root hubs only when have pending events. */
+ status = readl(>op_regs->status);
+ if (status & STS_EINT) {
+ usb_hcd_resume_root_hub(hcd);
+ usb_hcd_resume_root_hub(xhci->shared_hcd);
+ }
}
/*
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/5] xhci: clear root port wake on bits if controller isn't wake-up capable
From: Lu Baolu
When xHCI PCI host is suspended, if do_wakeup is false in xhci_pci_suspend,
xhci_bus_suspend needs to clear all root port wake on bits. Otherwise some Intel
platforms may get a spurious wakeup, even if PCI PME# is disabled.
This patch should be back-ported to kernels as old as 2.6.37, that
contains the commit 9777e3ce907d4cb5a513902a87ecd03b52499569
"USB: xHCI: bus power management implementation".
Cc: sta...@vger.kernel.org # 2.6.37
Signed-off-by: Lu Baolu
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci-hub.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index 2b998c6..aa79e87 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -22,6 +22,7 @@
#include
+#include
#include
#include "xhci.h"
@@ -1139,7 +1140,9 @@ int xhci_bus_suspend(struct usb_hcd *hcd)
* including the USB 3.0 roothub, but only if CONFIG_PM_RUNTIME
* is enabled, so also enable remote wake here.
*/
- if (hcd->self.root_hub->do_remote_wakeup) {
+ if (hcd->self.root_hub->do_remote_wakeup
+ && device_may_wakeup(hcd->self.controller)) {
+
if (t1 & PORT_CONNECT) {
t2 |= PORT_WKOC_E | PORT_WKDISC_E;
t2 &= ~PORT_WKCONN_E;
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/5] usb: xhci: Correct last context entry calculation for Configure Endpoint
From: Julius Werner
The current XHCI driver recalculates the Context Entries field in the
Slot Context on every add_endpoint() and drop_endpoint() call. In the
case of drop_endpoint(), it seems to assume that the add_flags will
always contain every endpoint for the new configuration, which is not
necessarily correct if you don't make assumptions about how the USB core
uses the add_endpoint/drop_endpoint interface (add_flags only contains
endpoints that are new additions in the new configuration).
Furthermore, EP0_FLAG is not consistently set in add_flags throughout
the lifetime of a device. This means that when all endpoints are
dropped, the Context Entries field can be set to 0 (which is invalid and
may cause a Parameter Error) or -1 (which is interpreted as 31 and
causes the driver to keep using the old, incorrect value).
The only surefire way to set this field right is to also take all
existing endpoints into account, and to force the value to 1 (meaning
only EP0 is active) if no other endpoint is found. This patch implements
that as a single step in the final check_bandwidth() call and removes
the intermediary calculations from add_endpoint() and drop_endpoint().
Signed-off-by: Julius Werner
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci.c | 51 +
1 file changed, 18 insertions(+), 33 deletions(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 2b8d9a2..013aabb 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -1582,12 +1582,10 @@ int xhci_drop_endpoint(struct usb_hcd *hcd, struct
usb_device *udev,
struct xhci_hcd *xhci;
struct xhci_container_ctx *in_ctx, *out_ctx;
struct xhci_input_control_ctx *ctrl_ctx;
- struct xhci_slot_ctx *slot_ctx;
- unsigned int last_ctx;
unsigned int ep_index;
struct xhci_ep_ctx *ep_ctx;
u32 drop_flag;
- u32 new_add_flags, new_drop_flags, new_slot_info;
+ u32 new_add_flags, new_drop_flags;
int ret;
ret = xhci_check_args(hcd, udev, ep, 1, true, __func__);
@@ -1634,24 +1632,13 @@ int xhci_drop_endpoint(struct usb_hcd *hcd, struct
usb_device *udev,
ctrl_ctx->add_flags &= cpu_to_le32(~drop_flag);
new_add_flags = le32_to_cpu(ctrl_ctx->add_flags);
- last_ctx = xhci_last_valid_endpoint(le32_to_cpu(ctrl_ctx->add_flags));
- slot_ctx = xhci_get_slot_ctx(xhci, in_ctx);
- /* Update the last valid endpoint context, if we deleted the last one */
- if ((le32_to_cpu(slot_ctx->dev_info) & LAST_CTX_MASK) >
- LAST_CTX(last_ctx)) {
- slot_ctx->dev_info &= cpu_to_le32(~LAST_CTX_MASK);
- slot_ctx->dev_info |= cpu_to_le32(LAST_CTX(last_ctx));
- }
- new_slot_info = le32_to_cpu(slot_ctx->dev_info);
-
xhci_endpoint_zero(xhci, xhci->devs[udev->slot_id], ep);
- xhci_dbg(xhci, "drop ep 0x%x, slot id %d, new drop flags = %#x, new add
flags = %#x, new slot info = %#x\n",
+ xhci_dbg(xhci, "drop ep 0x%x, slot id %d, new drop flags = %#x, new add
flags = %#x\n",
(unsigned int) ep->desc.bEndpointAddress,
udev->slot_id,
(unsigned int) new_drop_flags,
- (unsigned int) new_add_flags,
- (unsigned int) new_slot_info);
+ (unsigned int) new_add_flags);
return 0;
}
@@ -1674,11 +1661,9 @@ int xhci_add_endpoint(struct usb_hcd *hcd, struct
usb_device *udev,
struct xhci_hcd *xhci;
struct xhci_container_ctx *in_ctx, *out_ctx;
unsigned int ep_index;
- struct xhci_slot_ctx *slot_ctx;
struct xhci_input_control_ctx *ctrl_ctx;
u32 added_ctxs;
- unsigned int last_ctx;
- u32 new_add_flags, new_drop_flags, new_slot_info;
+ u32 new_add_flags, new_drop_flags;
struct xhci_virt_device *virt_dev;
int ret = 0;
@@ -1693,7 +1678,6 @@ int xhci_add_endpoint(struct usb_hcd *hcd, struct
usb_device *udev,
return -ENODEV;
added_ctxs = xhci_get_endpoint_flag(>desc);
- last_ctx = xhci_last_valid_endpoint(added_ctxs);
if (added_ctxs == SLOT_FLAG || added_ctxs == EP0_FLAG) {
/* FIXME when we have to issue an evaluate endpoint command to
* deal with ep0 max packet size changing once we get the
@@ -1759,24 +1743,14 @@ int xhci_add_endpoint(struct usb_hcd *hcd, struct
usb_device *udev,
*/
new_drop_flags = le32_to_cpu(ctrl_ctx->drop_flags);
- slot_ctx = xhci_get_slot_ctx(xhci, in_ctx);
- /* Update the last valid endpoint context, if we just added one past */
- if ((le32_to_cpu(slot_ctx->dev_info) & LAST_CTX_MASK) <
- LAST_CTX(last_ctx)) {
- slot_ctx->dev_info &= cpu_t
[PATCH 1/5] xhci: Use correct SLOT ID when handling a reset device command
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 20e7acb13ff48fbc884d5918c3697c27de63922a "xhci: use completion event's slot id rather than dig it out of command" Cc: sta...@vger.kernel.org # 3.13 Reported-by: Saran Neti Tested-by: Saran Neti Signed-off-by: Mathias Nyman --- drivers/usb/host/xhci-ring.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c index d67ff71..71657d3 100644 --- a/drivers/usb/host/xhci-ring.c +++ b/drivers/usb/host/xhci-ring.c @@ -1433,8 +1433,11 @@ static void handle_cmd_completion(struct xhci_hcd *xhci, xhci_handle_cmd_reset_ep(xhci, slot_id, cmd_trb, cmd_comp_code); break; case TRB_RESET_DEV: - WARN_ON(slot_id != TRB_TO_SLOT_ID( - le32_to_cpu(cmd_trb->generic.field[3]))); + /* SLOT_ID field in reset device cmd completion event TRB is 0. +* Use the SLOT_ID from the command TRB instead (xhci 4.6.11) +*/ + slot_id = TRB_TO_SLOT_ID( + le32_to_cpu(cmd_trb->generic.field[3])); xhci_handle_cmd_reset_dev(xhci, slot_id, event); break; case TRB_NEC_GET_FW: -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/5] xhci: correct burst count field for isoc transfers on 1.0 xhci hosts
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 5cd43e33b9519143f06f507dd7cbee6b7a621885 "xhci 1.0: Set transfer burst count field." Cc: sta...@vger.kernel.org # 3.0 Suggested-by: ShiChun Ma Signed-off-by: Mathias Nyman --- drivers/usb/host/xhci-ring.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c index 71657d3..749fc68 100644 --- a/drivers/usb/host/xhci-ring.c +++ b/drivers/usb/host/xhci-ring.c @@ -3537,7 +3537,7 @@ static unsigned int xhci_get_burst_count(struct xhci_hcd *xhci, return 0; max_burst = urb->ep->ss_ep_comp.bMaxBurst; - return roundup(total_packet_count, max_burst + 1) - 1; + return DIV_ROUND_UP(total_packet_count, max_burst + 1) - 1; } /* -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/5] xhci fixes for 3.16-rc usb-linus
Hi Greg These xhci fixes are for usb-linus 3.16-rc. Most of them are small fixes that also go to stable. Julius "Correct last context entry" is the only one with a bit more content. -Mathias Julius Werner (1): usb: xhci: Correct last context entry calculation for Configure Endpoint Lu Baolu (1): xhci: clear root port wake on bits if controller isn't wake-up capable Mathias Nyman (2): xhci: Use correct SLOT ID when handling a reset device command xhci: correct burst count field for isoc transfers on 1.0 xhci hosts Wang, Yu (1): xhci: Fix runtime suspended xhci from blocking system suspend. drivers/usb/host/xhci-hub.c | 5 +++- drivers/usb/host/xhci-ring.c | 9 --- drivers/usb/host/xhci.c | 61 ++-- 3 files changed, 35 insertions(+), 40 deletions(-) -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/5] xhci fixes for 3.16-rc usb-linus
Hi Greg These xhci fixes are for usb-linus 3.16-rc. Most of them are small fixes that also go to stable. Julius Correct last context entry is the only one with a bit more content. -Mathias Julius Werner (1): usb: xhci: Correct last context entry calculation for Configure Endpoint Lu Baolu (1): xhci: clear root port wake on bits if controller isn't wake-up capable Mathias Nyman (2): xhci: Use correct SLOT ID when handling a reset device command xhci: correct burst count field for isoc transfers on 1.0 xhci hosts Wang, Yu (1): xhci: Fix runtime suspended xhci from blocking system suspend. drivers/usb/host/xhci-hub.c | 5 +++- drivers/usb/host/xhci-ring.c | 9 --- drivers/usb/host/xhci.c | 61 ++-- 3 files changed, 35 insertions(+), 40 deletions(-) -- 1.8.3.2 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/5] xhci: correct burst count field for isoc transfers on 1.0 xhci hosts
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 5cd43e33b9519143f06f507dd7cbee6b7a621885 xhci 1.0: Set transfer burst count field. Cc: sta...@vger.kernel.org # 3.0 Suggested-by: ShiChun Ma masc2...@qq.com Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com --- drivers/usb/host/xhci-ring.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c index 71657d3..749fc68 100644 --- a/drivers/usb/host/xhci-ring.c +++ b/drivers/usb/host/xhci-ring.c @@ -3537,7 +3537,7 @@ static unsigned int xhci_get_burst_count(struct xhci_hcd *xhci, return 0; max_burst = urb-ep-ss_ep_comp.bMaxBurst; - return roundup(total_packet_count, max_burst + 1) - 1; + return DIV_ROUND_UP(total_packet_count, max_burst + 1) - 1; } /* -- 1.8.3.2 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/5] xhci: Use correct SLOT ID when handling a reset device command
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 20e7acb13ff48fbc884d5918c3697c27de63922a xhci: use completion event's slot id rather than dig it out of command Cc: sta...@vger.kernel.org # 3.13 Reported-by: Saran Neti saran...@gmail.com Tested-by: Saran Neti saran...@gmail.com Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com --- drivers/usb/host/xhci-ring.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c index d67ff71..71657d3 100644 --- a/drivers/usb/host/xhci-ring.c +++ b/drivers/usb/host/xhci-ring.c @@ -1433,8 +1433,11 @@ static void handle_cmd_completion(struct xhci_hcd *xhci, xhci_handle_cmd_reset_ep(xhci, slot_id, cmd_trb, cmd_comp_code); break; case TRB_RESET_DEV: - WARN_ON(slot_id != TRB_TO_SLOT_ID( - le32_to_cpu(cmd_trb-generic.field[3]))); + /* SLOT_ID field in reset device cmd completion event TRB is 0. +* Use the SLOT_ID from the command TRB instead (xhci 4.6.11) +*/ + slot_id = TRB_TO_SLOT_ID( + le32_to_cpu(cmd_trb-generic.field[3])); xhci_handle_cmd_reset_dev(xhci, slot_id, event); break; case TRB_NEC_GET_FW: -- 1.8.3.2 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/5] xhci: clear root port wake on bits if controller isn't wake-up capable
From: Lu Baolu baolu...@linux.intel.com
When xHCI PCI host is suspended, if do_wakeup is false in xhci_pci_suspend,
xhci_bus_suspend needs to clear all root port wake on bits. Otherwise some Intel
platforms may get a spurious wakeup, even if PCI PME# is disabled.
This patch should be back-ported to kernels as old as 2.6.37, that
contains the commit 9777e3ce907d4cb5a513902a87ecd03b52499569
USB: xHCI: bus power management implementation.
Cc: sta...@vger.kernel.org # 2.6.37
Signed-off-by: Lu Baolu baolu...@linux.intel.com
Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com
---
drivers/usb/host/xhci-hub.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index 2b998c6..aa79e87 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -22,6 +22,7 @@
#include linux/slab.h
+#include linux/device.h
#include asm/unaligned.h
#include xhci.h
@@ -1139,7 +1140,9 @@ int xhci_bus_suspend(struct usb_hcd *hcd)
* including the USB 3.0 roothub, but only if CONFIG_PM_RUNTIME
* is enabled, so also enable remote wake here.
*/
- if (hcd-self.root_hub-do_remote_wakeup) {
+ if (hcd-self.root_hub-do_remote_wakeup
+device_may_wakeup(hcd-self.controller)) {
+
if (t1 PORT_CONNECT) {
t2 |= PORT_WKOC_E | PORT_WKDISC_E;
t2 = ~PORT_WKCONN_E;
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/5] usb: xhci: Correct last context entry calculation for Configure Endpoint
From: Julius Werner jwer...@chromium.org
The current XHCI driver recalculates the Context Entries field in the
Slot Context on every add_endpoint() and drop_endpoint() call. In the
case of drop_endpoint(), it seems to assume that the add_flags will
always contain every endpoint for the new configuration, which is not
necessarily correct if you don't make assumptions about how the USB core
uses the add_endpoint/drop_endpoint interface (add_flags only contains
endpoints that are new additions in the new configuration).
Furthermore, EP0_FLAG is not consistently set in add_flags throughout
the lifetime of a device. This means that when all endpoints are
dropped, the Context Entries field can be set to 0 (which is invalid and
may cause a Parameter Error) or -1 (which is interpreted as 31 and
causes the driver to keep using the old, incorrect value).
The only surefire way to set this field right is to also take all
existing endpoints into account, and to force the value to 1 (meaning
only EP0 is active) if no other endpoint is found. This patch implements
that as a single step in the final check_bandwidth() call and removes
the intermediary calculations from add_endpoint() and drop_endpoint().
Signed-off-by: Julius Werner jwer...@chromium.org
Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com
---
drivers/usb/host/xhci.c | 51 +
1 file changed, 18 insertions(+), 33 deletions(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 2b8d9a2..013aabb 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -1582,12 +1582,10 @@ int xhci_drop_endpoint(struct usb_hcd *hcd, struct
usb_device *udev,
struct xhci_hcd *xhci;
struct xhci_container_ctx *in_ctx, *out_ctx;
struct xhci_input_control_ctx *ctrl_ctx;
- struct xhci_slot_ctx *slot_ctx;
- unsigned int last_ctx;
unsigned int ep_index;
struct xhci_ep_ctx *ep_ctx;
u32 drop_flag;
- u32 new_add_flags, new_drop_flags, new_slot_info;
+ u32 new_add_flags, new_drop_flags;
int ret;
ret = xhci_check_args(hcd, udev, ep, 1, true, __func__);
@@ -1634,24 +1632,13 @@ int xhci_drop_endpoint(struct usb_hcd *hcd, struct
usb_device *udev,
ctrl_ctx-add_flags = cpu_to_le32(~drop_flag);
new_add_flags = le32_to_cpu(ctrl_ctx-add_flags);
- last_ctx = xhci_last_valid_endpoint(le32_to_cpu(ctrl_ctx-add_flags));
- slot_ctx = xhci_get_slot_ctx(xhci, in_ctx);
- /* Update the last valid endpoint context, if we deleted the last one */
- if ((le32_to_cpu(slot_ctx-dev_info) LAST_CTX_MASK)
- LAST_CTX(last_ctx)) {
- slot_ctx-dev_info = cpu_to_le32(~LAST_CTX_MASK);
- slot_ctx-dev_info |= cpu_to_le32(LAST_CTX(last_ctx));
- }
- new_slot_info = le32_to_cpu(slot_ctx-dev_info);
-
xhci_endpoint_zero(xhci, xhci-devs[udev-slot_id], ep);
- xhci_dbg(xhci, drop ep 0x%x, slot id %d, new drop flags = %#x, new add
flags = %#x, new slot info = %#x\n,
+ xhci_dbg(xhci, drop ep 0x%x, slot id %d, new drop flags = %#x, new add
flags = %#x\n,
(unsigned int) ep-desc.bEndpointAddress,
udev-slot_id,
(unsigned int) new_drop_flags,
- (unsigned int) new_add_flags,
- (unsigned int) new_slot_info);
+ (unsigned int) new_add_flags);
return 0;
}
@@ -1674,11 +1661,9 @@ int xhci_add_endpoint(struct usb_hcd *hcd, struct
usb_device *udev,
struct xhci_hcd *xhci;
struct xhci_container_ctx *in_ctx, *out_ctx;
unsigned int ep_index;
- struct xhci_slot_ctx *slot_ctx;
struct xhci_input_control_ctx *ctrl_ctx;
u32 added_ctxs;
- unsigned int last_ctx;
- u32 new_add_flags, new_drop_flags, new_slot_info;
+ u32 new_add_flags, new_drop_flags;
struct xhci_virt_device *virt_dev;
int ret = 0;
@@ -1693,7 +1678,6 @@ int xhci_add_endpoint(struct usb_hcd *hcd, struct
usb_device *udev,
return -ENODEV;
added_ctxs = xhci_get_endpoint_flag(ep-desc);
- last_ctx = xhci_last_valid_endpoint(added_ctxs);
if (added_ctxs == SLOT_FLAG || added_ctxs == EP0_FLAG) {
/* FIXME when we have to issue an evaluate endpoint command to
* deal with ep0 max packet size changing once we get the
@@ -1759,24 +1743,14 @@ int xhci_add_endpoint(struct usb_hcd *hcd, struct
usb_device *udev,
*/
new_drop_flags = le32_to_cpu(ctrl_ctx-drop_flags);
- slot_ctx = xhci_get_slot_ctx(xhci, in_ctx);
- /* Update the last valid endpoint context, if we just added one past */
- if ((le32_to_cpu(slot_ctx-dev_info) LAST_CTX_MASK)
- LAST_CTX(last_ctx)) {
- slot_ctx-dev_info = cpu_to_le32(~LAST_CTX_MASK);
- slot_ctx-dev_info |= cpu_to_le32
[PATCH 5/5] xhci: Fix runtime suspended xhci from blocking system suspend.
From: Wang, Yu yu.y.w...@intel.com
The system suspend flow as following:
1, Freeze all user processes and kenrel threads.
2, Try to suspend all devices.
2.1, If pci device is in RPM suspended state, then pci driver will try
to resume it to RPM active state in the prepare stage.
2.2, xhci_resume function calls usb_hcd_resume_root_hub to queue two
workqueue items to resume usb2usb3 roothub devices.
2.3, Call suspend callbacks of devices.
2.3.1, All suspend callbacks of all hcd's children, including
roothub devices are called.
2.3.2, Finally, hcd_pci_suspend callback is called.
Due to workqueue threads were already frozen in step 1, the workqueue
items can't be scheduled, and the roothub devices can't be resumed in
this flow. The HCD_FLAG_WAKEUP_PENDING flag which is set in
usb_hcd_resume_root_hub won't be cleared. Finally,
hcd_pci_suspend will return -EBUSY, and system suspend fails.
The reason why this issue doesn't show up very often is due to that
choose_wakeup will be called in step 2.3.1. In step 2.3.1, if
udev-do_remote_wakeup is not equal to device_may_wakeup(udev-dev), then
udev will resume to RPM active for changing the wakeup settings. This
has been a lucky hit which hides this issue.
For some special xHCI controllers which have no USB2 port, then roothub
will not match hub driver due to probe failed. Then its
do_remote_wakeup will be set to zero, and we won't be as lucky.
xhci driver doesn't need to resume roothub devices everytime like in
the above case. It's only needed when there are pending event TRBs.
This patch should be back-ported to kernels as old as 3.2, that
contains the commit f69e3120df82391a0ee8118e0a156239a06b2afb
USB: XHCI: resume root hubs when the controller resumes
Cc: sta...@vger.kernel.org # 3.2
Signed-off-by: Wang, Yu yu.y.w...@intel.com
Acked-by: Alan Stern st...@rowland.harvard.edu
[use readl() instead of removed xhci_readl(), reword commit message -Mathias]
Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com
---
drivers/usb/host/xhci.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 013aabb..f07be65 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -936,7 +936,7 @@ int xhci_suspend(struct xhci_hcd *xhci)
*/
int xhci_resume(struct xhci_hcd *xhci, bool hibernated)
{
- u32 command, temp = 0;
+ u32 command, temp = 0, status;
struct usb_hcd *hcd = xhci_to_hcd(xhci);
struct usb_hcd *secondary_hcd;
int retval = 0;
@@ -1054,8 +1054,12 @@ int xhci_resume(struct xhci_hcd *xhci, bool hibernated)
done:
if (retval == 0) {
- usb_hcd_resume_root_hub(hcd);
- usb_hcd_resume_root_hub(xhci-shared_hcd);
+ /* Resume root hubs only when have pending events. */
+ status = readl(xhci-op_regs-status);
+ if (status STS_EINT) {
+ usb_hcd_resume_root_hub(hcd);
+ usb_hcd_resume_root_hub(xhci-shared_hcd);
+ }
}
/*
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/5] usb: xhci: Correct last context entry calculation for Configure Endpoint
On 06/24/2014 05:10 PM, Greg KH wrote: On Tue, Jun 24, 2014 at 05:14:42PM +0300, Mathias Nyman wrote: From: Julius Werner jwer...@chromium.org The current XHCI driver recalculates the Context Entries field in the Slot Context on every add_endpoint() and drop_endpoint() call. In the case of drop_endpoint(), it seems to assume that the add_flags will always contain every endpoint for the new configuration, which is not necessarily correct if you don't make assumptions about how the USB core uses the add_endpoint/drop_endpoint interface (add_flags only contains endpoints that are new additions in the new configuration). Furthermore, EP0_FLAG is not consistently set in add_flags throughout the lifetime of a device. This means that when all endpoints are dropped, the Context Entries field can be set to 0 (which is invalid and may cause a Parameter Error) or -1 (which is interpreted as 31 and causes the driver to keep using the old, incorrect value). The only surefire way to set this field right is to also take all existing endpoints into account, and to force the value to 1 (meaning only EP0 is active) if no other endpoint is found. This patch implements that as a single step in the final check_bandwidth() call and removes the intermediary calculations from add_endpoint() and drop_endpoint(). Signed-off-by: Julius Werner jwer...@chromium.org Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com --- drivers/usb/host/xhci.c | 51 + 1 file changed, 18 insertions(+), 33 deletions(-) Is this something for older (i.e. stable) kernels? This was intentionally left out of stable, reasoning in a previous mail was: We discussed with Sarah that we should try this out and queue it for usb-linus. This clearly fixes the generation of a invalid slot context if all endpoints are dropped. But because there hasn't been any reported issue about the other case this changes (always setting context entries to last valid ep in target configuration), and spec still has this tiny contradiction in this case, we should keep this out of stable. At least for now, until it gets some real world testing coverage. The mail: http://marc.info/?l=linux-usbm=13987912807w=2 Or if you prefer this patch could go to usb-next instead. -Mathias -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/1] xhci: clear root port wake on bits if controller isn't wake-up capable
On 06/13/2014 03:06 AM, Lu Baolu wrote:
> When xHCI PCI host is suspended, if do_wakeup is false in xhci_pci_suspend,
> xhci_bus_suspend needs to clear all root port wake on bits. Otherwise some
> Intel
> platforms may get a spurious wakeup, even if PCI PME# is disabled.
>
> This patch should be back-ported to kernels as old as 2.6.37, that
> contains the commit 9777e3ce907d4cb5a513902a87ecd03b52499569
> "USB: xHCI: bus power management implementation".
>
> Signed-off-by: Lu Baolu
> ---
> drivers/usb/host/xhci-hub.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
> index 6231ce6..fb771bd 100644
> --- a/drivers/usb/host/xhci-hub.c
> +++ b/drivers/usb/host/xhci-hub.c
> @@ -22,6 +22,7 @@
>
>
> #include
> +#include
> #include
>
> #include "xhci.h"
> @@ -1139,7 +1140,9 @@ int xhci_bus_suspend(struct usb_hcd *hcd)
>* including the USB 3.0 roothub, but only if CONFIG_PM_RUNTIME
>* is enabled, so also enable remote wake here.
>*/
> - if (hcd->self.root_hub->do_remote_wakeup) {
> + if (hcd->self.root_hub->do_remote_wakeup
> + && device_may_wakeup(hcd->self.controller)) {
> +
> if (t1 & PORT_CONNECT) {
> t2 |= PORT_WKOC_E | PORT_WKDISC_E;
> t2 &= ~PORT_WKCONN_E;
>
Looks good to me, thanks for fixing.
I can take it, add the "cc: stable" tag and send it forward to Greg once his
trees get updated to 3.16 release candidates
-Mathias
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/1] xhci: clear root port wake on bits if controller isn't wake-up capable
On 06/13/2014 03:06 AM, Lu Baolu wrote:
When xHCI PCI host is suspended, if do_wakeup is false in xhci_pci_suspend,
xhci_bus_suspend needs to clear all root port wake on bits. Otherwise some
Intel
platforms may get a spurious wakeup, even if PCI PME# is disabled.
This patch should be back-ported to kernels as old as 2.6.37, that
contains the commit 9777e3ce907d4cb5a513902a87ecd03b52499569
USB: xHCI: bus power management implementation.
Signed-off-by: Lu Baolu baolu...@linux.intel.com
---
drivers/usb/host/xhci-hub.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index 6231ce6..fb771bd 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -22,6 +22,7 @@
#include linux/slab.h
+#include linux/device.h
#include asm/unaligned.h
#include xhci.h
@@ -1139,7 +1140,9 @@ int xhci_bus_suspend(struct usb_hcd *hcd)
* including the USB 3.0 roothub, but only if CONFIG_PM_RUNTIME
* is enabled, so also enable remote wake here.
*/
- if (hcd-self.root_hub-do_remote_wakeup) {
+ if (hcd-self.root_hub-do_remote_wakeup
+ device_may_wakeup(hcd-self.controller)) {
+
if (t1 PORT_CONNECT) {
t2 |= PORT_WKOC_E | PORT_WKDISC_E;
t2 = ~PORT_WKCONN_E;
Looks good to me, thanks for fixing.
I can take it, add the cc: stable tag and send it forward to Greg once his
trees get updated to 3.16 release candidates
-Mathias
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/10] xhci: Use command structures when queuing commands on the command ring
On 06/06/2014 01:16 AM, Dan Williams wrote:
> Hi Mathias, hit a small issue playing with -next:
>
> On Thu, May 8, 2014 at 9:26 AM, Mathias Nyman
> wrote:
>> 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
>> ---
>> drivers/usb/host/xhci-hub.c | 21 +++--
>> drivers/usb/host/xhci-ring.c | 107 +---
>> drivers/usb/host/xhci.c | 194
>> ---
>> drivers/usb/host/xhci.h | 31 +++
>> 4 files changed, 216 insertions(+), 137 deletions(-)
>>
>> diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
>> index 1ad6bc1..3ce9c0a 100644
>> --- a/drivers/usb/host/xhci-hub.c
>> +++ b/drivers/usb/host/xhci-hub.c
>> @@ -20,7 +20,8 @@
>> * Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
>> */
>>
>> -#include
>> +
>> +#include
>> #include
>>
>> #include "xhci.h"
>> @@ -284,12 +285,22 @@ static int xhci_stop_device(struct xhci_hcd *xhci, int
>> slot_id, int suspend)
>>
>> spin_lock_irqsave(>lock, flags);
>> for (i = LAST_EP_INDEX; i > 0; i--) {
>> - if (virt_dev->eps[i].ring && virt_dev->eps[i].ring->dequeue)
>> - xhci_queue_stop_endpoint(xhci, slot_id, i, suspend);
>> + if (virt_dev->eps[i].ring && virt_dev->eps[i].ring->dequeue)
>> {
>> + struct xhci_command *command;
>> + command = xhci_alloc_command(xhci, false, false,
>> +GFP_NOIO);
>
> ...this needs to be GFP_NOWAIT, or move it outside the lock.
>
That's right, thanks, I'll fix it.
-Mathias
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/10] xhci: Use command structures when queuing commands on the command ring
On 06/06/2014 01:16 AM, Dan Williams wrote:
Hi Mathias, hit a small issue playing with -next:
On Thu, May 8, 2014 at 9:26 AM, Mathias Nyman
mathias.ny...@linux.intel.com wrote:
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.ny...@linux.intel.com
---
drivers/usb/host/xhci-hub.c | 21 +++--
drivers/usb/host/xhci-ring.c | 107 +---
drivers/usb/host/xhci.c | 194
---
drivers/usb/host/xhci.h | 31 +++
4 files changed, 216 insertions(+), 137 deletions(-)
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index 1ad6bc1..3ce9c0a 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -20,7 +20,8 @@
* Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/
-#include linux/gfp.h
+
+#include linux/slab.h
#include asm/unaligned.h
#include xhci.h
@@ -284,12 +285,22 @@ static int xhci_stop_device(struct xhci_hcd *xhci, int
slot_id, int suspend)
spin_lock_irqsave(xhci-lock, flags);
for (i = LAST_EP_INDEX; i 0; i--) {
- if (virt_dev-eps[i].ring virt_dev-eps[i].ring-dequeue)
- xhci_queue_stop_endpoint(xhci, slot_id, i, suspend);
+ if (virt_dev-eps[i].ring virt_dev-eps[i].ring-dequeue)
{
+ struct xhci_command *command;
+ command = xhci_alloc_command(xhci, false, false,
+GFP_NOIO);
...this needs to be GFP_NOWAIT, or move it outside the lock.
That's right, thanks, I'll fix it.
-Mathias
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 02/10] xhci: 'noxhci_port_switch' kernel parameter
On 05/20/2014 04:01 AM, Greg KH wrote: > On Thu, May 08, 2014 at 07:25:55PM +0300, Mathias Nyman wrote: >> From: Dan Williams >> >> Add a command line switch for disabling ehci port switchover. Useful >> for working around / debugging xhci incompatibilities where ehci >> operation is available. >> >> Reference: http://marc.info/?l=linux-usb=138920063001509=2 >> >> Cc: Sarah Sharp >> Cc: Mathias Nyman >> Cc: Holger Hans Peter Freyther >> Suggested-by: Alan Stern >> Signed-off-by: Dan Williams >> Signed-off-by: Mathias Nyman >> --- >> Documentation/kernel-parameters.txt | 3 +++ >> drivers/usb/host/pci-quirks.c | 15 +-- >> 2 files changed, 16 insertions(+), 2 deletions(-) >> >> diff --git a/Documentation/kernel-parameters.txt >> b/Documentation/kernel-parameters.txt >> index 4384217..fc3403114 100644 >> --- a/Documentation/kernel-parameters.txt >> +++ b/Documentation/kernel-parameters.txt >> @@ -2251,6 +2251,9 @@ bytes respectively. Such letter suffixes can also be >> entirely omitted. >> >> nox2apic[X86-64,APIC] Do not enable x2APIC mode. >> >> +noxhci_port_switch >> +[USB] Use EHCI instead of XHCI where available >> + > > Ugh, I really don't like new command line options. > > Especially one that isn't very well documented. Why would someone want > to enable this? What problem is it solving? Can we detect this > automatically and do it for the user? Is this just for prototype > hardware that has not shipped? What hardware needs this? > > I need a whole lot more documentation at the very least before I will > apply this. > On Intel hardware with both ehci and xhci controllers we can select if a usb2 port is controlled by ehci or xhci. This capability can be checked from Intel xhci pci config space. Xhci driver checks this on boot and switches over the supported ports. This is a feature in Intel Panther point and later chipsets, in shipped hardware. Its working quite well in most cases, but sometimes vendors claim they support switchover, but then forget to connect some wires, and the usb2 port ends up dead after switching. A recently found case is the Sony VAIO T-series. (I'll send you a different patch for that shortly) http://marc.info/?l=linux-usb=139993106029340=2 This is the extreme case that the usb2 ports appears completely dead. Other reasons are that some devices might work better under ehci than xhci, and users want to enforce the ehci opton. For powermanagement developers it's nice to disable switchover as it turns out some hardware are quirky with port switchover and suspend/resume. (might need to turn port back to ehci before suspending). I don't think we can detect this automatically. Dan, can you add more documentation to this patch? -Mathias -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 02/10] xhci: 'noxhci_port_switch' kernel parameter
On 05/20/2014 04:01 AM, Greg KH wrote: On Thu, May 08, 2014 at 07:25:55PM +0300, Mathias Nyman wrote: From: Dan Williams dan.j.willi...@intel.com Add a command line switch for disabling ehci port switchover. Useful for working around / debugging xhci incompatibilities where ehci operation is available. Reference: http://marc.info/?l=linux-usbm=138920063001509w=2 Cc: Sarah Sharp sarah.a.sh...@linux.intel.com Cc: Mathias Nyman mathias.ny...@linux.intel.com Cc: Holger Hans Peter Freyther hol...@moiji-mobile.com Suggested-by: Alan Stern st...@rowland.harvard.edu Signed-off-by: Dan Williams dan.j.willi...@intel.com Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com --- Documentation/kernel-parameters.txt | 3 +++ drivers/usb/host/pci-quirks.c | 15 +-- 2 files changed, 16 insertions(+), 2 deletions(-) diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 4384217..fc3403114 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -2251,6 +2251,9 @@ bytes respectively. Such letter suffixes can also be entirely omitted. nox2apic[X86-64,APIC] Do not enable x2APIC mode. +noxhci_port_switch +[USB] Use EHCI instead of XHCI where available + Ugh, I really don't like new command line options. Especially one that isn't very well documented. Why would someone want to enable this? What problem is it solving? Can we detect this automatically and do it for the user? Is this just for prototype hardware that has not shipped? What hardware needs this? I need a whole lot more documentation at the very least before I will apply this. On Intel hardware with both ehci and xhci controllers we can select if a usb2 port is controlled by ehci or xhci. This capability can be checked from Intel xhci pci config space. Xhci driver checks this on boot and switches over the supported ports. This is a feature in Intel Panther point and later chipsets, in shipped hardware. Its working quite well in most cases, but sometimes vendors claim they support switchover, but then forget to connect some wires, and the usb2 port ends up dead after switching. A recently found case is the Sony VAIO T-series. (I'll send you a different patch for that shortly) http://marc.info/?l=linux-usbm=139993106029340w=2 This is the extreme case that the usb2 ports appears completely dead. Other reasons are that some devices might work better under ehci than xhci, and users want to enforce the ehci opton. For powermanagement developers it's nice to disable switchover as it turns out some hardware are quirky with port switchover and suspend/resume. (might need to turn port back to ehci before suspending). I don't think we can detect this automatically. Dan, can you add more documentation to this patch? -Mathias -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] gpio: Add support for Intel SoC PMIC (Crystal Cove)
On 05/19/2014 03:27 AM, Zhu, Lejun wrote: > > > On 5/17/2014 1:33 AM, Linus Walleij wrote: >> On Wed, May 14, 2014 at 5:44 PM, Zhu, Lejun >> wrote: >> >>> Devices based on Intel SoC products such as Baytrail have a Power >>> Management IC. In the PMIC there are subsystems for voltage regulation, >>> A/D conversion, GPIO and PWMs. The PMIC in Baytrail-T platform is called >>> Crystal Cove. >>> >>> This patch adds support for the GPIO function in Crystal Cove. >>> >>> Signed-off-by: Yang, Bin >>> Signed-off-by: Zhu, Lejun >> >> (...) >> >>> +config GPIO_INTEL_SOC_PMIC >>> + bool "GPIO on Intel SoC PMIC" >>> + depends on INTEL_SOC_PMIC > > Thank you. That's a long list and all of them indeed need to be fixed. > I'll work on them and submit v2 when ready. > Shouldn't there be a .remove function undoing everything probe did? Freeing interrupts, removing irq domains, calling gpiochip_remove etc. Or is there something I'm missing? I see there's no option to compile this as module, but It might be added later so proper remove function would still be nice. -Mathias -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] gpio: Add support for Intel SoC PMIC (Crystal Cove)
On 05/19/2014 03:27 AM, Zhu, Lejun wrote: On 5/17/2014 1:33 AM, Linus Walleij wrote: On Wed, May 14, 2014 at 5:44 PM, Zhu, Lejun lejun@linux.intel.com wrote: Devices based on Intel SoC products such as Baytrail have a Power Management IC. In the PMIC there are subsystems for voltage regulation, A/D conversion, GPIO and PWMs. The PMIC in Baytrail-T platform is called Crystal Cove. This patch adds support for the GPIO function in Crystal Cove. Signed-off-by: Yang, Bin bin.y...@intel.com Signed-off-by: Zhu, Lejun lejun@linux.intel.com (...) +config GPIO_INTEL_SOC_PMIC + bool GPIO on Intel SoC PMIC + depends on INTEL_SOC_PMIC Thank you. That's a long list and all of them indeed need to be fixed. I'll work on them and submit v2 when ready. Shouldn't there be a .remove function undoing everything probe did? Freeing interrupts, removing irq domains, calling gpiochip_remove etc. Or is there something I'm missing? I see there's no option to compile this as module, but It might be added later so proper remove function would still be nice. -Mathias -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: baytrail: Add pull type, strength and open drain to debugfs output
On 05/16/2014 12:18 PM, Mika Westerberg wrote:
> In case of resolving power management or similar issues it might be useful
> to have these properties included in the debugfs output.
>
> Signed-off-by: Mika Westerberg
Looks good to me
Acked-by: Mathias Nyman
-Mathias
> ---
> drivers/pinctrl/pinctrl-baytrail.c | 55
> +++---
> 1 file changed, 51 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/pinctrl/pinctrl-baytrail.c
> b/drivers/pinctrl/pinctrl-baytrail.c
> index 7c65c9dab215..975572e2f260 100644
> --- a/drivers/pinctrl/pinctrl-baytrail.c
> +++ b/drivers/pinctrl/pinctrl-baytrail.c
> @@ -43,9 +43,20 @@
> #define BYT_INT_STAT_REG 0x800
>
> /* BYT_CONF0_REG register bits */
> +#define BYT_IODENBIT(31)
> #define BYT_TRIG_NEG BIT(26)
> #define BYT_TRIG_POS BIT(25)
> #define BYT_TRIG_LVL BIT(24)
> +#define BYT_PULL_STR_SHIFT 9
> +#define BYT_PULL_STR_MASK(3 << BYT_PULL_STR_SHIFT)
> +#define BYT_PULL_STR_2K (0 << BYT_PULL_STR_SHIFT)
> +#define BYT_PULL_STR_10K (1 << BYT_PULL_STR_SHIFT)
> +#define BYT_PULL_STR_20K (2 << BYT_PULL_STR_SHIFT)
> +#define BYT_PULL_STR_40K (3 << BYT_PULL_STR_SHIFT)
> +#define BYT_PULL_ASSIGN_SHIFT7
> +#define BYT_PULL_ASSIGN_MASK (3 << BYT_PULL_ASSIGN_SHIFT)
> +#define BYT_PULL_ASSIGN_UP (1 << BYT_PULL_ASSIGN_SHIFT)
> +#define BYT_PULL_ASSIGN_DOWN (2 << BYT_PULL_ASSIGN_SHIFT)
> #define BYT_PIN_MUX 0x07
>
> /* BYT_VAL_REG register bits */
> @@ -321,6 +332,8 @@ static void byt_gpio_dbg_show(struct seq_file *s, struct
> gpio_chip *chip)
> spin_lock_irqsave(>lock, flags);
>
> for (i = 0; i < vg->chip.ngpio; i++) {
> + const char *pull_str = NULL;
> + const char *pull = NULL;
> const char *label;
> offs = vg->range->pins[i] * 16;
> conf0 = readl(vg->reg_base + offs + BYT_CONF0_REG);
> @@ -330,8 +343,32 @@ static void byt_gpio_dbg_show(struct seq_file *s, struct
> gpio_chip *chip)
> if (!label)
> label = "Unrequested";
>
> + switch (conf0 & BYT_PULL_ASSIGN_MASK) {
> + case BYT_PULL_ASSIGN_UP:
> + pull = "up";
> + break;
> + case BYT_PULL_ASSIGN_DOWN:
> + pull = "down";
> + break;
> + }
> +
> + switch (conf0 & BYT_PULL_STR_MASK) {
> + case BYT_PULL_STR_2K:
> + pull_str = "2k";
> + break;
> + case BYT_PULL_STR_10K:
> + pull_str = "10k";
> + break;
> + case BYT_PULL_STR_20K:
> + pull_str = "20k";
> + break;
> + case BYT_PULL_STR_40K:
> + pull_str = "40k";
> + break;
> + }
> +
> seq_printf(s,
> -" gpio-%-3d (%-20.20s) %s %s %s pad-%-3d
> offset:0x%03x mux:%d %s%s%s\n",
> +" gpio-%-3d (%-20.20s) %s %s %s pad-%-3d
> offset:0x%03x mux:%d %s%s%s",
> i,
> label,
> val & BYT_INPUT_EN ? " " : "in",
> @@ -339,9 +376,19 @@ static void byt_gpio_dbg_show(struct seq_file *s, struct
> gpio_chip *chip)
> val & BYT_LEVEL ? "hi" : "lo",
> vg->range->pins[i], offs,
> conf0 & 0x7,
> -conf0 & BYT_TRIG_NEG ? " fall" : "",
> -conf0 & BYT_TRIG_POS ? " rise" : "",
> -conf0 & BYT_TRIG_LVL ? " level" : "");
> +conf0 & BYT_TRIG_NEG ? " fall" : " ",
> +conf0 & BYT_TRIG_POS ? " rise" : " ",
> +conf0 & BYT_TRIG_LVL ? " level" : " ");
> +
> + if (pull && pull_str)
> + seq_printf(s, " %-4s %-3s", pull, pull_str);
> + else
> + seq_puts(s, " ");
> +
> + if (conf0 & BYT_IODEN)
> + seq_puts(s, " open-drain");
> +
> + seq_puts(s, "\n");
> }
> spin_unlock_irqrestore(>lock, flags);
> }
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: baytrail: Add pull type, strength and open drain to debugfs output
On 05/16/2014 12:18 PM, Mika Westerberg wrote:
In case of resolving power management or similar issues it might be useful
to have these properties included in the debugfs output.
Signed-off-by: Mika Westerberg mika.westerb...@linux.intel.com
Looks good to me
Acked-by: Mathias Nyman mathias.ny...@linux.intel.com
-Mathias
---
drivers/pinctrl/pinctrl-baytrail.c | 55
+++---
1 file changed, 51 insertions(+), 4 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-baytrail.c
b/drivers/pinctrl/pinctrl-baytrail.c
index 7c65c9dab215..975572e2f260 100644
--- a/drivers/pinctrl/pinctrl-baytrail.c
+++ b/drivers/pinctrl/pinctrl-baytrail.c
@@ -43,9 +43,20 @@
#define BYT_INT_STAT_REG 0x800
/* BYT_CONF0_REG register bits */
+#define BYT_IODENBIT(31)
#define BYT_TRIG_NEG BIT(26)
#define BYT_TRIG_POS BIT(25)
#define BYT_TRIG_LVL BIT(24)
+#define BYT_PULL_STR_SHIFT 9
+#define BYT_PULL_STR_MASK(3 BYT_PULL_STR_SHIFT)
+#define BYT_PULL_STR_2K (0 BYT_PULL_STR_SHIFT)
+#define BYT_PULL_STR_10K (1 BYT_PULL_STR_SHIFT)
+#define BYT_PULL_STR_20K (2 BYT_PULL_STR_SHIFT)
+#define BYT_PULL_STR_40K (3 BYT_PULL_STR_SHIFT)
+#define BYT_PULL_ASSIGN_SHIFT7
+#define BYT_PULL_ASSIGN_MASK (3 BYT_PULL_ASSIGN_SHIFT)
+#define BYT_PULL_ASSIGN_UP (1 BYT_PULL_ASSIGN_SHIFT)
+#define BYT_PULL_ASSIGN_DOWN (2 BYT_PULL_ASSIGN_SHIFT)
#define BYT_PIN_MUX 0x07
/* BYT_VAL_REG register bits */
@@ -321,6 +332,8 @@ static void byt_gpio_dbg_show(struct seq_file *s, struct
gpio_chip *chip)
spin_lock_irqsave(vg-lock, flags);
for (i = 0; i vg-chip.ngpio; i++) {
+ const char *pull_str = NULL;
+ const char *pull = NULL;
const char *label;
offs = vg-range-pins[i] * 16;
conf0 = readl(vg-reg_base + offs + BYT_CONF0_REG);
@@ -330,8 +343,32 @@ static void byt_gpio_dbg_show(struct seq_file *s, struct
gpio_chip *chip)
if (!label)
label = Unrequested;
+ switch (conf0 BYT_PULL_ASSIGN_MASK) {
+ case BYT_PULL_ASSIGN_UP:
+ pull = up;
+ break;
+ case BYT_PULL_ASSIGN_DOWN:
+ pull = down;
+ break;
+ }
+
+ switch (conf0 BYT_PULL_STR_MASK) {
+ case BYT_PULL_STR_2K:
+ pull_str = 2k;
+ break;
+ case BYT_PULL_STR_10K:
+ pull_str = 10k;
+ break;
+ case BYT_PULL_STR_20K:
+ pull_str = 20k;
+ break;
+ case BYT_PULL_STR_40K:
+ pull_str = 40k;
+ break;
+ }
+
seq_printf(s,
- gpio-%-3d (%-20.20s) %s %s %s pad-%-3d
offset:0x%03x mux:%d %s%s%s\n,
+ gpio-%-3d (%-20.20s) %s %s %s pad-%-3d
offset:0x%03x mux:%d %s%s%s,
i,
label,
val BYT_INPUT_EN ?: in,
@@ -339,9 +376,19 @@ static void byt_gpio_dbg_show(struct seq_file *s, struct
gpio_chip *chip)
val BYT_LEVEL ? hi : lo,
vg-range-pins[i], offs,
conf0 0x7,
-conf0 BYT_TRIG_NEG ? fall : ,
-conf0 BYT_TRIG_POS ? rise : ,
-conf0 BYT_TRIG_LVL ? level : );
+conf0 BYT_TRIG_NEG ? fall : ,
+conf0 BYT_TRIG_POS ? rise : ,
+conf0 BYT_TRIG_LVL ? level : );
+
+ if (pull pull_str)
+ seq_printf(s, %-4s %-3s, pull, pull_str);
+ else
+ seq_puts(s, );
+
+ if (conf0 BYT_IODEN)
+ seq_puts(s, open-drain);
+
+ seq_puts(s, \n);
}
spin_unlock_irqrestore(vg-lock, flags);
}
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/10] xhci: features for usb-next
On 05/08/2014 07:25 PM, Mathias Nyman wrote: > Hi Greg > > These following xhci patches are for usb-next and hopefully for 3.16 > > This patcheseries includes a bigger change in xhci command queue code, > (last four patches), a task that I've been working on for a longer time. > Sarah gave green light for v5 before she went on her sabbatical. > > http://marc.info/?l=linux-usb=139889908701592=2 > > -Mathias > Ping Any chance of getting these into your usb-next tree? -Mathias -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/10] xhci: features for usb-next
On 05/08/2014 07:25 PM, Mathias Nyman wrote: Hi Greg These following xhci patches are for usb-next and hopefully for 3.16 This patcheseries includes a bigger change in xhci command queue code, (last four patches), a task that I've been working on for a longer time. Sarah gave green light for v5 before she went on her sabbatical. http://marc.info/?l=linux-usbm=139889908701592w=2 -Mathias Ping Any chance of getting these into your usb-next tree? -Mathias -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 03/10] usb: catch attempts to submit urbs with a vmalloc'd transfer buffer
On 05/08/2014 07:21 PM, Dan Williams wrote: On Thu, May 8, 2014 at 9:25 AM, Mathias Nyman wrote: From: Dan Williams Save someone else the debug cycles of figuring out why a driver's transfer request is failing or causing undefined system behavior. Buffers submitted for dma must come from GFP allocated / DMA-able memory. Return -EAGAIN matching the return value for dma_mapping_error() cases. Cc: Alan Stern Cc: Sarah Sharp Cc: Mathias Nyman Signed-off-by: Dan Williams Signed-off-by: Mathias Nyman Thanks Mathias. One note, this was acked-by Alan here: http://marc.info/?l=linux-usb=139327920501989=2 Ah, Right Greg, Alan, Should I resubmit this series with the added ACK for this patch? -Mathias -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 03/10] usb: catch attempts to submit urbs with a vmalloc'd transfer buffer
On 05/08/2014 07:21 PM, Dan Williams wrote: On Thu, May 8, 2014 at 9:25 AM, Mathias Nyman mathias.ny...@linux.intel.com wrote: From: Dan Williams dan.j.willi...@intel.com Save someone else the debug cycles of figuring out why a driver's transfer request is failing or causing undefined system behavior. Buffers submitted for dma must come from GFP allocated / DMA-able memory. Return -EAGAIN matching the return value for dma_mapping_error() cases. Cc: Alan Stern st...@rowland.harvard.edu Cc: Sarah Sharp sarah.a.sh...@linux.intel.com Cc: Mathias Nyman mathias.ny...@linux.intel.com Signed-off-by: Dan Williams dan.j.willi...@intel.com Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com Thanks Mathias. One note, this was acked-by Alan here: http://marc.info/?l=linux-usbm=139327920501989w=2 Ah, Right Greg, Alan, Should I resubmit this series with the added ACK for this patch? -Mathias -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [regression 3.15-rc3] Resume from s4 broken by 1f81b6d22a5980955b01e08cf27fb745dc9b686f
I can't see how this relates to Julius patch though, and I'm not sure yet why it only triggers when devices are connected to SS ports. Maybe just unlucky timing? I think the non-SS ports are connected to the EHCI controllers rather than the XHCI controllers. So that explains at least one detail. And I guess timing is as good an excuse as any why this gets exposed by the patch in question. That's right, sometimes I forget that there exists something else than xHCI. Does this help?: Indeed it does. The machine just survived a dozen or so suspend+resume cycles without a hitch. The bug was 100% reproducible on this machine, so the fix seems solid. Tested-by: Ville Syrjälä Great, a patch with your Tested-by tag pushed to my tree at: git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git for-usb-linus -Mathias -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [regression 3.15-rc3] Resume from s4 broken by 1f81b6d22a5980955b01e08cf27fb745dc9b686f
I can't see how this relates to Julius patch though, and I'm not sure yet why it only triggers when devices are connected to SS ports. Maybe just unlucky timing? I think the non-SS ports are connected to the EHCI controllers rather than the XHCI controllers. So that explains at least one detail. And I guess timing is as good an excuse as any why this gets exposed by the patch in question. That's right, sometimes I forget that there exists something else than xHCI. Does this help?: Indeed it does. The machine just survived a dozen or so suspend+resume cycles without a hitch. The bug was 100% reproducible on this machine, so the fix seems solid. Tested-by: Ville Syrjälä ville.syrj...@linux.intel.com Great, a patch with your Tested-by tag pushed to my tree at: git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git for-usb-linus -Mathias -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 05/10] xhci: Use pci_enable_msix_exact() instead of pci_enable_msix()
From: Alexander Gordeev
As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range() or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.
Signed-off-by: Alexander Gordeev
Cc: Sarah Sharp
Cc: Greg Kroah-Hartman
Cc: linux-...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 708cb29..88ec076 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -291,7 +291,7 @@ static int xhci_setup_msix(struct xhci_hcd *xhci)
xhci->msix_entries[i].vector = 0;
}
- ret = pci_enable_msix(pdev, xhci->msix_entries, xhci->msix_count);
+ ret = pci_enable_msix_exact(pdev, xhci->msix_entries, xhci->msix_count);
if (ret) {
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
"Failed to enable MSI-X");
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 06/10] xhci: Report max device limit when Enable Slot command fails.
From: Sarah Sharp
xHCI host controllers may only support a limited number of device slot
IDs, which is usually far less than the theoretical maximum number of
devices (255) that the USB specifications advertise. This is
frustrating to consumers that expect to be able to plug in a large
number of devices.
Add a print statement when the Enable Slot command fails to show how
many devices the host supports. We can't change hardware manufacturer's
design decisions, but hopefully we can save customers a little bit of
time trying to debug why their host mysteriously fails when too many
devices are plugged in.
Signed-off-by: Sarah Sharp
Reported-by: Amund Hov
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 88ec076..92e1dda 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -3696,6 +3696,9 @@ int xhci_alloc_dev(struct usb_hcd *hcd, struct usb_device
*udev)
if (!xhci->slot_id) {
xhci_err(xhci, "Error while assigning device slot ID\n");
+ xhci_err(xhci, "Max number of devices this xHCI host supports
is %u.\n",
+ HCS_MAX_SLOTS(
+ readl(>cap_regs->hcs_params1)));
return 0;
}
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 02/10] xhci: 'noxhci_port_switch' kernel parameter
From: Dan Williams
Add a command line switch for disabling ehci port switchover. Useful
for working around / debugging xhci incompatibilities where ehci
operation is available.
Reference: http://marc.info/?l=linux-usb=138920063001509=2
Cc: Sarah Sharp
Cc: Mathias Nyman
Cc: Holger Hans Peter Freyther
Suggested-by: Alan Stern
Signed-off-by: Dan Williams
Signed-off-by: Mathias Nyman
---
Documentation/kernel-parameters.txt | 3 +++
drivers/usb/host/pci-quirks.c | 15 +--
2 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 4384217..fc3403114 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -2251,6 +2251,9 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
nox2apic[X86-64,APIC] Do not enable x2APIC mode.
+ noxhci_port_switch
+ [USB] Use EHCI instead of XHCI where available
+
cpu0_hotplug[X86] Turn on CPU0 hotplug feature when
CONFIG_BOOTPARAM_HOTPLUG_CPU0 is off.
Some features depend on CPU0. Known dependencies are:
diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index 00661d3..38bfe3d 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -823,6 +823,15 @@ static int handshake(void __iomem *ptr, u32 mask, u32 done,
return -ETIMEDOUT;
}
+static int noxhci_port_switch;
+
+static int __init noxhci_port_switch_setup(char *str)
+{
+ noxhci_port_switch = 1;
+ return 0;
+}
+early_param("noxhci_port_switch", noxhci_port_switch_setup);
+
/*
* Intel's Panther Point chipset has two host controllers (EHCI and xHCI) that
* share some number of ports. These ports can be switched between either
@@ -860,8 +869,7 @@ void usb_enable_intel_xhci_ports(struct pci_dev *xhci_pdev)
return;
/* Don't switchover the ports if the user hasn't compiled the xHCI
-* driver. Otherwise they will see "dead" USB ports that don't power
-* the devices.
+* driver or has explicitly disabled switchover
*/
if (!IS_ENABLED(CONFIG_USB_XHCI_HCD)) {
dev_warn(_pdev->dev,
@@ -871,6 +879,9 @@ void usb_enable_intel_xhci_ports(struct pci_dev *xhci_pdev)
"USB 3.0 devices will work at USB 2.0
speeds.\n");
usb_disable_xhci_ports(xhci_pdev);
return;
+ } else if (noxhci_port_switch) {
+ usb_disable_xhci_ports(xhci_pdev);
+ return;
}
/* Read USB3PRM, the USB 3.0 Port Routing Mask Register
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 04/10] usb: xhci: Use IS_ENABLED() macro
From: Fabio Estevam
Using the IS_ENABLED() macro can make the code shorter and easier to read.
Signed-off-by: Fabio Estevam
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 4746816..cc67c76 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1738,8 +1738,7 @@ static inline int xhci_register_pci(void) { return 0; }
static inline void xhci_unregister_pci(void) {}
#endif
-#if defined(CONFIG_USB_XHCI_PLATFORM) \
- || defined(CONFIG_USB_XHCI_PLATFORM_MODULE)
+#if IS_ENABLED(CONFIG_USB_XHCI_PLATFORM)
int xhci_register_plat(void);
void xhci_unregister_plat(void);
#else
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 09/10] xhci: Use completion and status in global command queue
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
---
drivers/usb/host/xhci-hub.c | 11 --
drivers/usb/host/xhci-mem.c | 1 -
drivers/usb/host/xhci-ring.c | 84
drivers/usb/host/xhci.c | 16 ++---
drivers/usb/host/xhci.h | 3 --
5 files changed, 17 insertions(+), 98 deletions(-)
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index 3ce9c0a..12871b5 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -299,7 +299,6 @@ static int xhci_stop_device(struct xhci_hcd *xhci, int
slot_id, int suspend)
suspend);
}
}
- list_add_tail(>cmd_list, _dev->cmd_list);
xhci_queue_stop_endpoint(xhci, cmd, slot_id, 0, suspend);
xhci_ring_cmd_db(xhci);
spin_unlock_irqrestore(>lock, flags);
@@ -311,18 +310,8 @@ static int xhci_stop_device(struct xhci_hcd *xhci, int
slot_id, int suspend)
if (timeleft <= 0) {
xhci_warn(xhci, "%s while waiting for stop endpoint command\n",
timeleft == 0 ? "Timeout" : "Signal");
- spin_lock_irqsave(>lock, flags);
- /* The timeout might have raced with the event ring handler, so
-* only delete from the list if the item isn't poisoned.
-*/
- if (cmd->cmd_list.next != LIST_POISON1)
- list_del(>cmd_list);
- spin_unlock_irqrestore(>lock, flags);
ret = -ETIME;
- goto command_cleanup;
}
-
-command_cleanup:
xhci_free_command(xhci, cmd);
return ret;
}
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index b070a17..38dc721 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1020,7 +1020,6 @@ int xhci_alloc_virt_device(struct xhci_hcd *xhci, int
slot_id,
dev->num_rings_cached = 0;
init_completion(>cmd_completion);
- INIT_LIST_HEAD(>cmd_list);
dev->udev = udev;
/* Point to output device context in dcbaa. */
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 89b8745..3d60865 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -69,10 +69,6 @@
#include "xhci.h"
#include "xhci-trace.h"
-static int handle_cmd_in_cmd_wait_list(struct xhci_hcd *xhci,
- struct xhci_virt_device *virt_dev,
- struct xhci_event_cmd *event);
-
/*
* Returns zero if the TRB isn't in this segment, otherwise it returns the DMA
* address of the TRB.
@@ -765,7 +761,6 @@ static void xhci_handle_cmd_stop_ep(struct xhci_hcd *xhci,
int slot_id,
union xhci_trb *trb, struct xhci_event_cmd *event)
{
unsigned int ep_index;
- struct xhci_virt_device *virt_dev;
struct xhci_ring *ep_ring;
struct xhci_virt_ep *ep;
struct list_head *entry;
@@ -775,11 +770,7 @@ static void xhci_handle_cmd_stop_ep(struct xhci_hcd *xhci,
int slot_id,
struct xhci_dequeue_state deq_state;
if (unlikely(TRB_TO_SUSPEND_PORT(le32_to_cpu(trb->generic.field[3] {
- virt_dev = xhci->devs[slot_id];
- if (virt_dev)
- handle_cmd_in_cmd_wait_list(xhci, virt_dev,
- event);
- else
+ if (!xhci->devs[slot_id])
xhci_warn(xhci, "Stop endpoint command "
"completion for disabled slot %u\n",
slot_id);
@@ -1229,29 +1220,6 @@ static void xhci_complete_cmd_in_cmd_wait_list(struct
xhci_hcd *xhci,
}
-/* Check to see if a command in the device's command queue matches this one.
- * Signal the completion or free the command, and return 1. Return 0 if the
- * completed command isn't at the head of the command list.
- */
-static int handle_cmd_in_cmd_wait_list(struct xhci_hcd *xhci,
- struct xhci_virt_device *virt_dev,
- struct xhci_event_cmd *event)
-{
- struct xhci_command *command;
-
- if (list_empty(_dev->cmd_list))
- return 0;
-
- command = list_entry(virt_dev->cmd_list.next,
- struct xhci_command, cmd_list);
- if (xhci->cmd_ring->dequeue != command->command_trb)
- return 0;
-
- xhci_complete_cmd_in_cmd_wait_list(xhci, command,
- GET_COMP_CODE(le32_to_cpu(event->status)));
- return 1;
-}
-
/*
* Finding the command trb need to be cancelled and modifying it to
* NO OP command. And if the
[PATCH 10/10] xhci: rework command timeout and cancellation,
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
---
drivers/usb/host/xhci-hub.c | 11 +-
drivers/usb/host/xhci-mem.c | 14 +-
drivers/usb/host/xhci-ring.c | 378 +++
drivers/usb/host/xhci.c | 78 +++--
drivers/usb/host/xhci.h | 8 +-
5 files changed, 169 insertions(+), 320 deletions(-)
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index 12871b5..6231ce6 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -271,7 +271,6 @@ static int xhci_stop_device(struct xhci_hcd *xhci, int
slot_id, int suspend)
struct xhci_virt_device *virt_dev;
struct xhci_command *cmd;
unsigned long flags;
- int timeleft;
int ret;
int i;
@@ -304,12 +303,10 @@ static int xhci_stop_device(struct xhci_hcd *xhci, int
slot_id, int suspend)
spin_unlock_irqrestore(>lock, flags);
/* Wait for last stop endpoint command to finish */
- timeleft = wait_for_completion_interruptible_timeout(
- cmd->completion,
- XHCI_CMD_DEFAULT_TIMEOUT);
- if (timeleft <= 0) {
- xhci_warn(xhci, "%s while waiting for stop endpoint command\n",
- timeleft == 0 ? "Timeout" : "Signal");
+ wait_for_completion(cmd->completion);
+
+ if (cmd->status == COMP_CMD_ABORT || cmd->status == COMP_CMD_STOP) {
+ xhci_warn(xhci, "Timeout while waiting for stop endpoint
command\n");
ret = -ETIME;
}
xhci_free_command(xhci, cmd);
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 38dc721..6a57e81 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1793,10 +1793,11 @@ void xhci_free_command(struct xhci_hcd *xhci,
void xhci_mem_cleanup(struct xhci_hcd *xhci)
{
struct device *dev = xhci_to_hcd(xhci)->self.controller;
- struct xhci_cd *cur_cd, *next_cd;
int size;
int i, j, num_ports;
+ del_timer_sync(>cmd_timer);
+
/* Free the Event Ring Segment Table and the actual Event Ring */
size = sizeof(struct xhci_erst_entry)*(xhci->erst.num_entries);
if (xhci->erst.entries)
@@ -1815,11 +1816,6 @@ void xhci_mem_cleanup(struct xhci_hcd *xhci)
xhci_ring_free(xhci, xhci->cmd_ring);
xhci->cmd_ring = NULL;
xhci_dbg_trace(xhci, trace_xhci_dbg_init, "Freed command ring");
- list_for_each_entry_safe(cur_cd, next_cd,
- >cancel_cmd_list, cancel_cmd_list) {
- list_del(_cd->cancel_cmd_list);
- kfree(cur_cd);
- }
xhci_cleanup_command_queue(xhci);
for (i = 1; i < MAX_HC_SLOTS; ++i)
@@ -2323,7 +2319,6 @@ int xhci_mem_init(struct xhci_hcd *xhci, gfp_t flags)
u32 page_size, temp;
int i;
- INIT_LIST_HEAD(>cancel_cmd_list);
INIT_LIST_HEAD(>cmd_list);
page_size = readl(>op_regs->page_size);
@@ -2510,6 +2505,11 @@ int xhci_mem_init(struct xhci_hcd *xhci, gfp_t flags)
"Wrote ERST address to ir_set 0.");
xhci_print_ir_set(xhci, 0);
+ /* init command timeout timer */
+ init_timer(>cmd_timer);
+ xhci->cmd_timer.data = (unsigned long) xhci;
+ xhci->cmd_timer.function = xhci_handle_command_timeout;
+
/*
[PATCH 08/10] xhci: Add a global command queue
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
---
drivers/usb/host/xhci-mem.c | 2 ++
drivers/usb/host/xhci-ring.c | 34 ++
drivers/usb/host/xhci.c | 2 --
drivers/usb/host/xhci.h | 2 ++
4 files changed, 34 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index c089668..b070a17 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1821,6 +1821,7 @@ void xhci_mem_cleanup(struct xhci_hcd *xhci)
list_del(_cd->cancel_cmd_list);
kfree(cur_cd);
}
+ xhci_cleanup_command_queue(xhci);
for (i = 1; i < MAX_HC_SLOTS; ++i)
xhci_free_virt_device(xhci, i);
@@ -2324,6 +2325,7 @@ int xhci_mem_init(struct xhci_hcd *xhci, gfp_t flags)
int i;
INIT_LIST_HEAD(>cancel_cmd_list);
+ INIT_LIST_HEAD(>cmd_list);
page_size = readl(>op_regs->page_size);
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index b172a7d..89b8745 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1520,6 +1520,20 @@ static void xhci_handle_cmd_nec_get_fw(struct xhci_hcd
*xhci,
NEC_FW_MINOR(le32_to_cpu(event->status)));
}
+static void xhci_del_and_free_cmd(struct xhci_command *cmd)
+{
+ list_del(>cmd_list);
+ if (!cmd->completion)
+ kfree(cmd);
+}
+
+void xhci_cleanup_command_queue(struct xhci_hcd *xhci)
+{
+ struct xhci_command *cur_cmd, *tmp_cmd;
+ list_for_each_entry_safe(cur_cmd, tmp_cmd, >cmd_list, cmd_list)
+ xhci_del_and_free_cmd(cur_cmd);
+}
+
static void handle_cmd_completion(struct xhci_hcd *xhci,
struct xhci_event_cmd *event)
{
@@ -1528,6 +1542,7 @@ static void handle_cmd_completion(struct xhci_hcd *xhci,
dma_addr_t cmd_dequeue_dma;
u32 cmd_comp_code;
union xhci_trb *cmd_trb;
+ struct xhci_command *cmd;
u32 cmd_type;
cmd_dma = le64_to_cpu(event->cmd_trb);
@@ -1545,6 +1560,13 @@ static void handle_cmd_completion(struct xhci_hcd *xhci,
return;
}
+ cmd = list_entry(xhci->cmd_list.next, struct xhci_command, cmd_list);
+
+ if (cmd->command_trb != xhci->cmd_ring->dequeue) {
+ xhci_err(xhci,
+"Command completion event does not match command\n");
+ return;
+ }
trace_xhci_cmd_completion(cmd_trb, (struct xhci_generic_trb *) event);
cmd_comp_code = GET_COMP_CODE(le32_to_cpu(event->status));
@@ -1614,6 +1636,9 @@ static void handle_cmd_completion(struct xhci_hcd *xhci,
xhci->error_bitmask |= 1 << 6;
break;
}
+
+ xhci_del_and_free_cmd(cmd);
+
inc_deq(xhci, xhci->cmd_ring);
}
@@ -3998,6 +4023,8 @@ static int queue_command(struct xhci_hcd *xhci, struct
xhci_command *cmd,
{
int reserved_trbs = xhci->cmd_ring_reserved_trbs;
int ret;
+ if (xhci->xhc_state & XHCI_STATE_DYING)
+ return -ESHUTDOWN;
if (!command_must_succeed)
reserved_trbs++;
@@ -4011,10 +4038,9 @@ static int queue_command(struct xhci_hcd *xhci, struct
xhci_command *cmd,
"unfailable commands failed.\n");
return ret;
}
- if (cmd->completion)
- cmd->command_trb = xhci->cmd_ring->enqueue;
- else
- kfree(cmd);
+
+ cmd->command_trb = xhci->cmd_ring->enqueue;
+ list_add_tail(>cmd_list, >cmd_list);
queue_trb(xhci, xhci->cmd_ring, false, field1, field2, field3,
field4 | xhci->cmd_ring->cycle_state);
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 9a4c6df..8dbc410 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -3732,7 +3732,6 @@ int xhci_alloc_dev(struct usb_hcd *hcd, struct usb_device
*udev)
timeleft == 0 ? "Timeout" : "Signal");
/* cancel the enable slot request */
ret = xhci_cancel_cmd(xhci, NULL, command->command_trb);
- kfree(command);
return ret;
}
@@ -3891,7 +3890,6 @@ static int xhci_setup_device(struct usb_hcd *hcd, struct
usb_device *udev,
[PATCH 07/10] xhci: Use command structures when queuing commands on the command ring
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
---
drivers/usb/host/xhci-hub.c | 21 +++--
drivers/usb/host/xhci-ring.c | 107 +---
drivers/usb/host/xhci.c | 194 ---
drivers/usb/host/xhci.h | 31 +++
4 files changed, 216 insertions(+), 137 deletions(-)
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index 1ad6bc1..3ce9c0a 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -20,7 +20,8 @@
* Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/
-#include
+
+#include
#include
#include "xhci.h"
@@ -284,12 +285,22 @@ static int xhci_stop_device(struct xhci_hcd *xhci, int
slot_id, int suspend)
spin_lock_irqsave(>lock, flags);
for (i = LAST_EP_INDEX; i > 0; i--) {
- if (virt_dev->eps[i].ring && virt_dev->eps[i].ring->dequeue)
- xhci_queue_stop_endpoint(xhci, slot_id, i, suspend);
+ if (virt_dev->eps[i].ring && virt_dev->eps[i].ring->dequeue) {
+ struct xhci_command *command;
+ command = xhci_alloc_command(xhci, false, false,
+GFP_NOIO);
+ if (!command) {
+ spin_unlock_irqrestore(>lock, flags);
+ xhci_free_command(xhci, cmd);
+ return -ENOMEM;
+
+ }
+ xhci_queue_stop_endpoint(xhci, command, slot_id, i,
+suspend);
+ }
}
- cmd->command_trb = xhci_find_next_enqueue(xhci->cmd_ring);
list_add_tail(>cmd_list, _dev->cmd_list);
- xhci_queue_stop_endpoint(xhci, slot_id, 0, suspend);
+ xhci_queue_stop_endpoint(xhci, cmd, slot_id, 0, suspend);
xhci_ring_cmd_db(xhci);
spin_unlock_irqrestore(>lock, flags);
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 7a0e3c7..b172a7d 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -123,16 +123,6 @@ static int enqueue_is_link_trb(struct xhci_ring *ring)
return TRB_TYPE_LINK_LE32(link->control);
}
-union xhci_trb *xhci_find_next_enqueue(struct xhci_ring *ring)
-{
- /* Enqueue pointer can be left pointing to the link TRB,
-* we must handle that
-*/
- if (TRB_TYPE_LINK_LE32(ring->enqueue->link.control))
- return ring->enq_seg->next->trbs;
- return ring->enqueue;
-}
-
/* Updates trb to point to the next TRB in the ring, and updates seg if the
next
* TRB is in a new segment. This does not skip over link TRBs, and it does not
* effect the ring dequeue or enqueue pointers.
@@ -684,12 +674,14 @@ static void td_to_noop(struct xhci_hcd *xhci, struct
xhci_ring *ep_ring,
}
}
-static int queue_set_tr_deq(struct xhci_hcd *xhci, int slot_id,
+static int queue_set_tr_deq(struct xhci_hcd *xhci,
+ struct xhci_command *cmd, int slot_id,
unsigned int ep_index, unsigned int stream_id,
struct xhci_segment *deq_seg,
union xhci_trb *deq_ptr, u32 cycle_state);
void xhci_queue_new_dequeue_state(struct xhci_hcd *xhci,
+ struct xhci_command *cmd,
unsigned int slot_id, unsigned int ep_index,
unsigned int stream_id,
struct xhci_dequeue_state *deq_state)
@@ -704,7 +696,7 @@ void xhci_queue_new_dequeue_state(struct xhci_hcd *xhci,
deq_state->
[PATCH 00/10] xhci: features for usb-next
Hi Greg These following xhci patches are for usb-next and hopefully for 3.16 This patcheseries includes a bigger change in xhci command queue code, (last four patches), a task that I've been working on for a longer time. Sarah gave green light for v5 before she went on her sabbatical. http://marc.info/?l=linux-usb=139889908701592=2 -Mathias Alexander Gordeev (1): xhci: Use pci_enable_msix_exact() instead of pci_enable_msix() Dan Williams (2): xhci: 'noxhci_port_switch' kernel parameter usb: catch attempts to submit urbs with a vmalloc'd transfer buffer Fabio Estevam (1): usb: xhci: Use IS_ENABLED() macro Lin Wang (1): xhci: fix wrong port number reported when setting USB2.0 hardware LPM. Mathias Nyman (4): xhci: Use command structures when queuing commands on the command ring xhci: Add a global command queue xhci: Use completion and status in global command queue xhci: rework command timeout and cancellation, Sarah Sharp (1): xhci: Report max device limit when Enable Slot command fails. Documentation/kernel-parameters.txt | 3 + drivers/usb/core/hcd.c | 3 + drivers/usb/host/pci-quirks.c | 15 +- drivers/usb/host/xhci-hub.c | 43 ++- drivers/usb/host/xhci-mem.c | 17 +- drivers/usb/host/xhci-ring.c| 587 ++-- drivers/usb/host/xhci.c | 271 + drivers/usb/host/xhci.h | 47 +-- 8 files changed, 440 insertions(+), 546 deletions(-) -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 01/10] xhci: fix wrong port number reported when setting USB2.0 hardware LPM.
From: Lin Wang
This patch fix wrong port number reported when trying to enable/disable
USB2.0 hardware LPM.
Signed-off-by: Lin Wang
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 3008369..708cb29 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -4092,7 +4092,7 @@ int xhci_set_usb2_hardware_lpm(struct usb_hcd *hcd,
field = le32_to_cpu(udev->bos->ext_cap->bmAttributes);
xhci_dbg(xhci, "%s port %d USB2 hardware LPM\n",
- enable ? "enable" : "disable", port_num);
+ enable ? "enable" : "disable", port_num + 1);
if (enable) {
/* Host supports BESL timeout instead of HIRD */
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 03/10] usb: catch attempts to submit urbs with a vmalloc'd transfer buffer
From: Dan Williams
Save someone else the debug cycles of figuring out why a driver's
transfer request is failing or causing undefined system behavior.
Buffers submitted for dma must come from GFP allocated / DMA-able
memory.
Return -EAGAIN matching the return value for dma_mapping_error() cases.
Cc: Alan Stern
Cc: Sarah Sharp
Cc: Mathias Nyman
Signed-off-by: Dan Williams
Signed-off-by: Mathias Nyman
---
drivers/usb/core/hcd.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 9c4e292..adddc66 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -1502,6 +1502,9 @@ int usb_hcd_map_urb_for_dma(struct usb_hcd *hcd, struct
urb *urb,
ret = -EAGAIN;
else
urb->transfer_flags |= URB_DMA_MAP_PAGE;
+ } else if (is_vmalloc_addr(urb->transfer_buffer)) {
+ WARN_ONCE(1, "transfer buffer not dma
capable\n");
+ ret = -EAGAIN;
} else {
urb->transfer_dma = dma_map_single(
hcd->self.controller,
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 00/10] xhci: features for usb-next
Hi Greg These following xhci patches are for usb-next and hopefully for 3.16 This patcheseries includes a bigger change in xhci command queue code, (last four patches), a task that I've been working on for a longer time. Sarah gave green light for v5 before she went on her sabbatical. http://marc.info/?l=linux-usbm=139889908701592w=2 -Mathias Alexander Gordeev (1): xhci: Use pci_enable_msix_exact() instead of pci_enable_msix() Dan Williams (2): xhci: 'noxhci_port_switch' kernel parameter usb: catch attempts to submit urbs with a vmalloc'd transfer buffer Fabio Estevam (1): usb: xhci: Use IS_ENABLED() macro Lin Wang (1): xhci: fix wrong port number reported when setting USB2.0 hardware LPM. Mathias Nyman (4): xhci: Use command structures when queuing commands on the command ring xhci: Add a global command queue xhci: Use completion and status in global command queue xhci: rework command timeout and cancellation, Sarah Sharp (1): xhci: Report max device limit when Enable Slot command fails. Documentation/kernel-parameters.txt | 3 + drivers/usb/core/hcd.c | 3 + drivers/usb/host/pci-quirks.c | 15 +- drivers/usb/host/xhci-hub.c | 43 ++- drivers/usb/host/xhci-mem.c | 17 +- drivers/usb/host/xhci-ring.c| 587 ++-- drivers/usb/host/xhci.c | 271 + drivers/usb/host/xhci.h | 47 +-- 8 files changed, 440 insertions(+), 546 deletions(-) -- 1.8.3.2 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 01/10] xhci: fix wrong port number reported when setting USB2.0 hardware LPM.
From: Lin Wang bupt.wang...@gmail.com
This patch fix wrong port number reported when trying to enable/disable
USB2.0 hardware LPM.
Signed-off-by: Lin Wang lin.x.w...@intel.com
Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com
---
drivers/usb/host/xhci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 3008369..708cb29 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -4092,7 +4092,7 @@ int xhci_set_usb2_hardware_lpm(struct usb_hcd *hcd,
field = le32_to_cpu(udev-bos-ext_cap-bmAttributes);
xhci_dbg(xhci, %s port %d USB2 hardware LPM\n,
- enable ? enable : disable, port_num);
+ enable ? enable : disable, port_num + 1);
if (enable) {
/* Host supports BESL timeout instead of HIRD */
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 03/10] usb: catch attempts to submit urbs with a vmalloc'd transfer buffer
From: Dan Williams dan.j.willi...@intel.com
Save someone else the debug cycles of figuring out why a driver's
transfer request is failing or causing undefined system behavior.
Buffers submitted for dma must come from GFP allocated / DMA-able
memory.
Return -EAGAIN matching the return value for dma_mapping_error() cases.
Cc: Alan Stern st...@rowland.harvard.edu
Cc: Sarah Sharp sarah.a.sh...@linux.intel.com
Cc: Mathias Nyman mathias.ny...@linux.intel.com
Signed-off-by: Dan Williams dan.j.willi...@intel.com
Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com
---
drivers/usb/core/hcd.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 9c4e292..adddc66 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -1502,6 +1502,9 @@ int usb_hcd_map_urb_for_dma(struct usb_hcd *hcd, struct
urb *urb,
ret = -EAGAIN;
else
urb-transfer_flags |= URB_DMA_MAP_PAGE;
+ } else if (is_vmalloc_addr(urb-transfer_buffer)) {
+ WARN_ONCE(1, transfer buffer not dma
capable\n);
+ ret = -EAGAIN;
} else {
urb-transfer_dma = dma_map_single(
hcd-self.controller,
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 08/10] xhci: Add a global command queue
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.ny...@linux.intel.com
---
drivers/usb/host/xhci-mem.c | 2 ++
drivers/usb/host/xhci-ring.c | 34 ++
drivers/usb/host/xhci.c | 2 --
drivers/usb/host/xhci.h | 2 ++
4 files changed, 34 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index c089668..b070a17 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1821,6 +1821,7 @@ void xhci_mem_cleanup(struct xhci_hcd *xhci)
list_del(cur_cd-cancel_cmd_list);
kfree(cur_cd);
}
+ xhci_cleanup_command_queue(xhci);
for (i = 1; i MAX_HC_SLOTS; ++i)
xhci_free_virt_device(xhci, i);
@@ -2324,6 +2325,7 @@ int xhci_mem_init(struct xhci_hcd *xhci, gfp_t flags)
int i;
INIT_LIST_HEAD(xhci-cancel_cmd_list);
+ INIT_LIST_HEAD(xhci-cmd_list);
page_size = readl(xhci-op_regs-page_size);
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index b172a7d..89b8745 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1520,6 +1520,20 @@ static void xhci_handle_cmd_nec_get_fw(struct xhci_hcd
*xhci,
NEC_FW_MINOR(le32_to_cpu(event-status)));
}
+static void xhci_del_and_free_cmd(struct xhci_command *cmd)
+{
+ list_del(cmd-cmd_list);
+ if (!cmd-completion)
+ kfree(cmd);
+}
+
+void xhci_cleanup_command_queue(struct xhci_hcd *xhci)
+{
+ struct xhci_command *cur_cmd, *tmp_cmd;
+ list_for_each_entry_safe(cur_cmd, tmp_cmd, xhci-cmd_list, cmd_list)
+ xhci_del_and_free_cmd(cur_cmd);
+}
+
static void handle_cmd_completion(struct xhci_hcd *xhci,
struct xhci_event_cmd *event)
{
@@ -1528,6 +1542,7 @@ static void handle_cmd_completion(struct xhci_hcd *xhci,
dma_addr_t cmd_dequeue_dma;
u32 cmd_comp_code;
union xhci_trb *cmd_trb;
+ struct xhci_command *cmd;
u32 cmd_type;
cmd_dma = le64_to_cpu(event-cmd_trb);
@@ -1545,6 +1560,13 @@ static void handle_cmd_completion(struct xhci_hcd *xhci,
return;
}
+ cmd = list_entry(xhci-cmd_list.next, struct xhci_command, cmd_list);
+
+ if (cmd-command_trb != xhci-cmd_ring-dequeue) {
+ xhci_err(xhci,
+Command completion event does not match command\n);
+ return;
+ }
trace_xhci_cmd_completion(cmd_trb, (struct xhci_generic_trb *) event);
cmd_comp_code = GET_COMP_CODE(le32_to_cpu(event-status));
@@ -1614,6 +1636,9 @@ static void handle_cmd_completion(struct xhci_hcd *xhci,
xhci-error_bitmask |= 1 6;
break;
}
+
+ xhci_del_and_free_cmd(cmd);
+
inc_deq(xhci, xhci-cmd_ring);
}
@@ -3998,6 +4023,8 @@ static int queue_command(struct xhci_hcd *xhci, struct
xhci_command *cmd,
{
int reserved_trbs = xhci-cmd_ring_reserved_trbs;
int ret;
+ if (xhci-xhc_state XHCI_STATE_DYING)
+ return -ESHUTDOWN;
if (!command_must_succeed)
reserved_trbs++;
@@ -4011,10 +4038,9 @@ static int queue_command(struct xhci_hcd *xhci, struct
xhci_command *cmd,
unfailable commands failed.\n);
return ret;
}
- if (cmd-completion)
- cmd-command_trb = xhci-cmd_ring-enqueue;
- else
- kfree(cmd);
+
+ cmd-command_trb = xhci-cmd_ring-enqueue;
+ list_add_tail(cmd-cmd_list, xhci-cmd_list);
queue_trb(xhci, xhci-cmd_ring, false, field1, field2, field3,
field4 | xhci-cmd_ring-cycle_state);
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 9a4c6df..8dbc410 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -3732,7 +3732,6 @@ int xhci_alloc_dev(struct usb_hcd *hcd, struct usb_device
*udev)
timeleft == 0 ? Timeout : Signal);
/* cancel the enable slot request */
ret = xhci_cancel_cmd(xhci, NULL, command-command_trb);
- kfree(command);
return ret;
}
@@ -3891,7 +3890,6 @@ static int xhci_setup_device(struct usb_hcd *hcd, struct
usb_device *udev,
timeleft == 0 ? Timeout : Signal, act);
/* cancel the address device command */
ret
[PATCH 07/10] xhci: Use command structures when queuing commands on the command ring
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.ny...@linux.intel.com
---
drivers/usb/host/xhci-hub.c | 21 +++--
drivers/usb/host/xhci-ring.c | 107 +---
drivers/usb/host/xhci.c | 194 ---
drivers/usb/host/xhci.h | 31 +++
4 files changed, 216 insertions(+), 137 deletions(-)
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index 1ad6bc1..3ce9c0a 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -20,7 +20,8 @@
* Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/
-#include linux/gfp.h
+
+#include linux/slab.h
#include asm/unaligned.h
#include xhci.h
@@ -284,12 +285,22 @@ static int xhci_stop_device(struct xhci_hcd *xhci, int
slot_id, int suspend)
spin_lock_irqsave(xhci-lock, flags);
for (i = LAST_EP_INDEX; i 0; i--) {
- if (virt_dev-eps[i].ring virt_dev-eps[i].ring-dequeue)
- xhci_queue_stop_endpoint(xhci, slot_id, i, suspend);
+ if (virt_dev-eps[i].ring virt_dev-eps[i].ring-dequeue) {
+ struct xhci_command *command;
+ command = xhci_alloc_command(xhci, false, false,
+GFP_NOIO);
+ if (!command) {
+ spin_unlock_irqrestore(xhci-lock, flags);
+ xhci_free_command(xhci, cmd);
+ return -ENOMEM;
+
+ }
+ xhci_queue_stop_endpoint(xhci, command, slot_id, i,
+suspend);
+ }
}
- cmd-command_trb = xhci_find_next_enqueue(xhci-cmd_ring);
list_add_tail(cmd-cmd_list, virt_dev-cmd_list);
- xhci_queue_stop_endpoint(xhci, slot_id, 0, suspend);
+ xhci_queue_stop_endpoint(xhci, cmd, slot_id, 0, suspend);
xhci_ring_cmd_db(xhci);
spin_unlock_irqrestore(xhci-lock, flags);
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 7a0e3c7..b172a7d 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -123,16 +123,6 @@ static int enqueue_is_link_trb(struct xhci_ring *ring)
return TRB_TYPE_LINK_LE32(link-control);
}
-union xhci_trb *xhci_find_next_enqueue(struct xhci_ring *ring)
-{
- /* Enqueue pointer can be left pointing to the link TRB,
-* we must handle that
-*/
- if (TRB_TYPE_LINK_LE32(ring-enqueue-link.control))
- return ring-enq_seg-next-trbs;
- return ring-enqueue;
-}
-
/* Updates trb to point to the next TRB in the ring, and updates seg if the
next
* TRB is in a new segment. This does not skip over link TRBs, and it does not
* effect the ring dequeue or enqueue pointers.
@@ -684,12 +674,14 @@ static void td_to_noop(struct xhci_hcd *xhci, struct
xhci_ring *ep_ring,
}
}
-static int queue_set_tr_deq(struct xhci_hcd *xhci, int slot_id,
+static int queue_set_tr_deq(struct xhci_hcd *xhci,
+ struct xhci_command *cmd, int slot_id,
unsigned int ep_index, unsigned int stream_id,
struct xhci_segment *deq_seg,
union xhci_trb *deq_ptr, u32 cycle_state);
void xhci_queue_new_dequeue_state(struct xhci_hcd *xhci,
+ struct xhci_command *cmd,
unsigned int slot_id, unsigned int ep_index,
unsigned int stream_id,
struct xhci_dequeue_state *deq_state)
@@ -704,7 +696,7 @@ void xhci_queue_new_dequeue_state(struct xhci_hcd *xhci,
deq_state-new_deq_ptr,
(unsigned
[PATCH 09/10] xhci: Use completion and status in global command queue
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.ny...@linux.intel.com
---
drivers/usb/host/xhci-hub.c | 11 --
drivers/usb/host/xhci-mem.c | 1 -
drivers/usb/host/xhci-ring.c | 84
drivers/usb/host/xhci.c | 16 ++---
drivers/usb/host/xhci.h | 3 --
5 files changed, 17 insertions(+), 98 deletions(-)
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index 3ce9c0a..12871b5 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -299,7 +299,6 @@ static int xhci_stop_device(struct xhci_hcd *xhci, int
slot_id, int suspend)
suspend);
}
}
- list_add_tail(cmd-cmd_list, virt_dev-cmd_list);
xhci_queue_stop_endpoint(xhci, cmd, slot_id, 0, suspend);
xhci_ring_cmd_db(xhci);
spin_unlock_irqrestore(xhci-lock, flags);
@@ -311,18 +310,8 @@ static int xhci_stop_device(struct xhci_hcd *xhci, int
slot_id, int suspend)
if (timeleft = 0) {
xhci_warn(xhci, %s while waiting for stop endpoint command\n,
timeleft == 0 ? Timeout : Signal);
- spin_lock_irqsave(xhci-lock, flags);
- /* The timeout might have raced with the event ring handler, so
-* only delete from the list if the item isn't poisoned.
-*/
- if (cmd-cmd_list.next != LIST_POISON1)
- list_del(cmd-cmd_list);
- spin_unlock_irqrestore(xhci-lock, flags);
ret = -ETIME;
- goto command_cleanup;
}
-
-command_cleanup:
xhci_free_command(xhci, cmd);
return ret;
}
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index b070a17..38dc721 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1020,7 +1020,6 @@ int xhci_alloc_virt_device(struct xhci_hcd *xhci, int
slot_id,
dev-num_rings_cached = 0;
init_completion(dev-cmd_completion);
- INIT_LIST_HEAD(dev-cmd_list);
dev-udev = udev;
/* Point to output device context in dcbaa. */
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 89b8745..3d60865 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -69,10 +69,6 @@
#include xhci.h
#include xhci-trace.h
-static int handle_cmd_in_cmd_wait_list(struct xhci_hcd *xhci,
- struct xhci_virt_device *virt_dev,
- struct xhci_event_cmd *event);
-
/*
* Returns zero if the TRB isn't in this segment, otherwise it returns the DMA
* address of the TRB.
@@ -765,7 +761,6 @@ static void xhci_handle_cmd_stop_ep(struct xhci_hcd *xhci,
int slot_id,
union xhci_trb *trb, struct xhci_event_cmd *event)
{
unsigned int ep_index;
- struct xhci_virt_device *virt_dev;
struct xhci_ring *ep_ring;
struct xhci_virt_ep *ep;
struct list_head *entry;
@@ -775,11 +770,7 @@ static void xhci_handle_cmd_stop_ep(struct xhci_hcd *xhci,
int slot_id,
struct xhci_dequeue_state deq_state;
if (unlikely(TRB_TO_SUSPEND_PORT(le32_to_cpu(trb-generic.field[3] {
- virt_dev = xhci-devs[slot_id];
- if (virt_dev)
- handle_cmd_in_cmd_wait_list(xhci, virt_dev,
- event);
- else
+ if (!xhci-devs[slot_id])
xhci_warn(xhci, Stop endpoint command
completion for disabled slot %u\n,
slot_id);
@@ -1229,29 +1220,6 @@ static void xhci_complete_cmd_in_cmd_wait_list(struct
xhci_hcd *xhci,
}
-/* Check to see if a command in the device's command queue matches this one.
- * Signal the completion or free the command, and return 1. Return 0 if the
- * completed command isn't at the head of the command list.
- */
-static int handle_cmd_in_cmd_wait_list(struct xhci_hcd *xhci,
- struct xhci_virt_device *virt_dev,
- struct xhci_event_cmd *event)
-{
- struct xhci_command *command;
-
- if (list_empty(virt_dev-cmd_list))
- return 0;
-
- command = list_entry(virt_dev-cmd_list.next,
- struct xhci_command, cmd_list);
- if (xhci-cmd_ring-dequeue != command-command_trb)
- return 0;
-
- xhci_complete_cmd_in_cmd_wait_list(xhci, command,
- GET_COMP_CODE(le32_to_cpu(event-status)));
- return 1;
-}
-
/*
* Finding the command trb need to be cancelled and modifying it to
* NO OP command. And if the command is in device's command wait
@@ -1403,7 +1371,6 @@ static void xhci_handle_cmd_enable_slot(struct
[PATCH 10/10] xhci: rework command timeout and cancellation,
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.ny...@linux.intel.com
---
drivers/usb/host/xhci-hub.c | 11 +-
drivers/usb/host/xhci-mem.c | 14 +-
drivers/usb/host/xhci-ring.c | 378 +++
drivers/usb/host/xhci.c | 78 +++--
drivers/usb/host/xhci.h | 8 +-
5 files changed, 169 insertions(+), 320 deletions(-)
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index 12871b5..6231ce6 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -271,7 +271,6 @@ static int xhci_stop_device(struct xhci_hcd *xhci, int
slot_id, int suspend)
struct xhci_virt_device *virt_dev;
struct xhci_command *cmd;
unsigned long flags;
- int timeleft;
int ret;
int i;
@@ -304,12 +303,10 @@ static int xhci_stop_device(struct xhci_hcd *xhci, int
slot_id, int suspend)
spin_unlock_irqrestore(xhci-lock, flags);
/* Wait for last stop endpoint command to finish */
- timeleft = wait_for_completion_interruptible_timeout(
- cmd-completion,
- XHCI_CMD_DEFAULT_TIMEOUT);
- if (timeleft = 0) {
- xhci_warn(xhci, %s while waiting for stop endpoint command\n,
- timeleft == 0 ? Timeout : Signal);
+ wait_for_completion(cmd-completion);
+
+ if (cmd-status == COMP_CMD_ABORT || cmd-status == COMP_CMD_STOP) {
+ xhci_warn(xhci, Timeout while waiting for stop endpoint
command\n);
ret = -ETIME;
}
xhci_free_command(xhci, cmd);
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 38dc721..6a57e81 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1793,10 +1793,11 @@ void xhci_free_command(struct xhci_hcd *xhci,
void xhci_mem_cleanup(struct xhci_hcd *xhci)
{
struct device *dev = xhci_to_hcd(xhci)-self.controller;
- struct xhci_cd *cur_cd, *next_cd;
int size;
int i, j, num_ports;
+ del_timer_sync(xhci-cmd_timer);
+
/* Free the Event Ring Segment Table and the actual Event Ring */
size = sizeof(struct xhci_erst_entry)*(xhci-erst.num_entries);
if (xhci-erst.entries)
@@ -1815,11 +1816,6 @@ void xhci_mem_cleanup(struct xhci_hcd *xhci)
xhci_ring_free(xhci, xhci-cmd_ring);
xhci-cmd_ring = NULL;
xhci_dbg_trace(xhci, trace_xhci_dbg_init, Freed command ring);
- list_for_each_entry_safe(cur_cd, next_cd,
- xhci-cancel_cmd_list, cancel_cmd_list) {
- list_del(cur_cd-cancel_cmd_list);
- kfree(cur_cd);
- }
xhci_cleanup_command_queue(xhci);
for (i = 1; i MAX_HC_SLOTS; ++i)
@@ -2323,7 +2319,6 @@ int xhci_mem_init(struct xhci_hcd *xhci, gfp_t flags)
u32 page_size, temp;
int i;
- INIT_LIST_HEAD(xhci-cancel_cmd_list);
INIT_LIST_HEAD(xhci-cmd_list);
page_size = readl(xhci-op_regs-page_size);
@@ -2510,6 +2505,11 @@ int xhci_mem_init(struct xhci_hcd *xhci, gfp_t flags)
Wrote ERST address to ir_set 0.);
xhci_print_ir_set(xhci, 0);
+ /* init command timeout timer */
+ init_timer(xhci-cmd_timer);
+ xhci-cmd_timer.data = (unsigned long) xhci;
+ xhci-cmd_timer.function = xhci_handle_command_timeout;
+
/*
* XXX: Might need to set the Interrupter Moderation Register to
* something other than
[PATCH 04/10] usb: xhci: Use IS_ENABLED() macro
From: Fabio Estevam fabio.este...@freescale.com
Using the IS_ENABLED() macro can make the code shorter and easier to read.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com
---
drivers/usb/host/xhci.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 4746816..cc67c76 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1738,8 +1738,7 @@ static inline int xhci_register_pci(void) { return 0; }
static inline void xhci_unregister_pci(void) {}
#endif
-#if defined(CONFIG_USB_XHCI_PLATFORM) \
- || defined(CONFIG_USB_XHCI_PLATFORM_MODULE)
+#if IS_ENABLED(CONFIG_USB_XHCI_PLATFORM)
int xhci_register_plat(void);
void xhci_unregister_plat(void);
#else
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 06/10] xhci: Report max device limit when Enable Slot command fails.
From: Sarah Sharp sarah.a.sh...@linux.intel.com
xHCI host controllers may only support a limited number of device slot
IDs, which is usually far less than the theoretical maximum number of
devices (255) that the USB specifications advertise. This is
frustrating to consumers that expect to be able to plug in a large
number of devices.
Add a print statement when the Enable Slot command fails to show how
many devices the host supports. We can't change hardware manufacturer's
design decisions, but hopefully we can save customers a little bit of
time trying to debug why their host mysteriously fails when too many
devices are plugged in.
Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com
Reported-by: Amund Hov amund@silabs.com
Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com
---
drivers/usb/host/xhci.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 88ec076..92e1dda 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -3696,6 +3696,9 @@ int xhci_alloc_dev(struct usb_hcd *hcd, struct usb_device
*udev)
if (!xhci-slot_id) {
xhci_err(xhci, Error while assigning device slot ID\n);
+ xhci_err(xhci, Max number of devices this xHCI host supports
is %u.\n,
+ HCS_MAX_SLOTS(
+ readl(xhci-cap_regs-hcs_params1)));
return 0;
}
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 02/10] xhci: 'noxhci_port_switch' kernel parameter
From: Dan Williams dan.j.willi...@intel.com
Add a command line switch for disabling ehci port switchover. Useful
for working around / debugging xhci incompatibilities where ehci
operation is available.
Reference: http://marc.info/?l=linux-usbm=138920063001509w=2
Cc: Sarah Sharp sarah.a.sh...@linux.intel.com
Cc: Mathias Nyman mathias.ny...@linux.intel.com
Cc: Holger Hans Peter Freyther hol...@moiji-mobile.com
Suggested-by: Alan Stern st...@rowland.harvard.edu
Signed-off-by: Dan Williams dan.j.willi...@intel.com
Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com
---
Documentation/kernel-parameters.txt | 3 +++
drivers/usb/host/pci-quirks.c | 15 +--
2 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 4384217..fc3403114 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -2251,6 +2251,9 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
nox2apic[X86-64,APIC] Do not enable x2APIC mode.
+ noxhci_port_switch
+ [USB] Use EHCI instead of XHCI where available
+
cpu0_hotplug[X86] Turn on CPU0 hotplug feature when
CONFIG_BOOTPARAM_HOTPLUG_CPU0 is off.
Some features depend on CPU0. Known dependencies are:
diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index 00661d3..38bfe3d 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -823,6 +823,15 @@ static int handshake(void __iomem *ptr, u32 mask, u32 done,
return -ETIMEDOUT;
}
+static int noxhci_port_switch;
+
+static int __init noxhci_port_switch_setup(char *str)
+{
+ noxhci_port_switch = 1;
+ return 0;
+}
+early_param(noxhci_port_switch, noxhci_port_switch_setup);
+
/*
* Intel's Panther Point chipset has two host controllers (EHCI and xHCI) that
* share some number of ports. These ports can be switched between either
@@ -860,8 +869,7 @@ void usb_enable_intel_xhci_ports(struct pci_dev *xhci_pdev)
return;
/* Don't switchover the ports if the user hasn't compiled the xHCI
-* driver. Otherwise they will see dead USB ports that don't power
-* the devices.
+* driver or has explicitly disabled switchover
*/
if (!IS_ENABLED(CONFIG_USB_XHCI_HCD)) {
dev_warn(xhci_pdev-dev,
@@ -871,6 +879,9 @@ void usb_enable_intel_xhci_ports(struct pci_dev *xhci_pdev)
USB 3.0 devices will work at USB 2.0
speeds.\n);
usb_disable_xhci_ports(xhci_pdev);
return;
+ } else if (noxhci_port_switch) {
+ usb_disable_xhci_ports(xhci_pdev);
+ return;
}
/* Read USB3PRM, the USB 3.0 Port Routing Mask Register
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 05/10] xhci: Use pci_enable_msix_exact() instead of pci_enable_msix()
From: Alexander Gordeev agord...@redhat.com
As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range() or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.
Signed-off-by: Alexander Gordeev agord...@redhat.com
Cc: Sarah Sharp sarah.a.sh...@linux.intel.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: linux-...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com
---
drivers/usb/host/xhci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 708cb29..88ec076 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -291,7 +291,7 @@ static int xhci_setup_msix(struct xhci_hcd *xhci)
xhci-msix_entries[i].vector = 0;
}
- ret = pci_enable_msix(pdev, xhci-msix_entries, xhci-msix_count);
+ ret = pci_enable_msix_exact(pdev, xhci-msix_entries, xhci-msix_count);
if (ret) {
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
Failed to enable MSI-X);
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [regression 3.15-rc3] Resume from s4 broken by 1f81b6d22a5980955b01e08cf27fb745dc9b686f
On 05/06/2014 02:41 PM, Ville Syrjälä wrote:
On Mon, May 05, 2014 at 12:32:22PM -0700, Julius Werner wrote:
Hmmm... very odd. I unfortunately don't have a machine that can easily
do S4 at hand, but I did test this on an IVB with XHCI_RESET_ON_RESUME
in S3 (essentially the same code path), and I didn't run into any
problems.
How exactly does your machine fail on resume? Is it a kernel crash or
just a hang? Can you try getting some debug output (by setting 'echo N
/sys/module/printk/parameters/console_suspend' and trying to catch
the crash on the screen or a serial line, or maybe through pstore)? I
really don't see much that could go wrong with this patch, so without
more info it will be hard to understand your problem.
Also, I noticed that you have two HID devices plugged in during
suspend. Does it make a difference if you have different devices (e.g.
a mass storage stick) or none at all?
Looks like it doesn't like it when there's anything plugged into the
"SS" ports. I tried with just a HID keyboard or with just a hub. In
both cases it fails to resume. If I have nothing connected to the "SS"
ports then it resumes just fine.
I managed to catch something with ramoops. Looks like it's hitting
POISON_FREE when trying to delete some list entry.
<4>[ 107.047230] xhci_hcd :00:14.0: Slot 1 endpoint 2 not removed from BW
list!
<4>[ 107.047574] general protection fault: [#1] PREEMPT SMP
I took a look at the xhci_mem_cleanup() function and to me it looks
like it tries to access a list_head that is already freed.
The struct list_head xhci->devs[].eps[].bw_endpoint_list is added to an endpoint
list in xhci->rh_bw[].bw_table.interval_bw[].endpoints
xhci_mem_cleanup() frees all devices (the allocated xhci->devs[], containing the
bw_endpoint_list) before it starts to loop through, and delete entries from the
xhci->rh_bw[].bw_table.interval_bw[].endpoints list.
I can't see how this relates to Julius patch though, and I'm not sure yet why it
only triggers when devices are connected to SS ports. Maybe just unlucky timing?
Does this help?:
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index c089668..b1a8a5f 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1822,6 +1822,16 @@ void xhci_mem_cleanup(struct xhci_hcd *xhci)
kfree(cur_cd);
}
+ num_ports = HCS_MAX_PORTS(xhci->hcs_params1);
+ for (i = 0; i < num_ports; i++) {
+ struct xhci_interval_bw_table *bwt = >rh_bw[i].bw_table;
+ for (j = 0; j < XHCI_MAX_INTERVAL; j++) {
+ struct list_head *ep = >interval_bw[j].endpoints;
+ while (!list_empty(ep))
+ list_del_init(ep->next);
+ }
+ }
+
for (i = 1; i < MAX_HC_SLOTS; ++i)
xhci_free_virt_device(xhci, i);
@@ -1857,16 +1867,6 @@ void xhci_mem_cleanup(struct xhci_hcd *xhci)
if (!xhci->rh_bw)
goto no_bw;
- num_ports = HCS_MAX_PORTS(xhci->hcs_params1);
- for (i = 0; i < num_ports; i++) {
- struct xhci_interval_bw_table *bwt = >rh_bw[i].bw_table;
- for (j = 0; j < XHCI_MAX_INTERVAL; j++) {
- struct list_head *ep = >interval_bw[j].endpoints;
- while (!list_empty(ep))
- list_del_init(ep->next);
- }
- }
-
for (i = 0; i < num_ports; i++) {
struct xhci_tt_bw_info *tt, *n;
list_for_each_entry_safe(tt, n, >rh_bw[i].tts, tt_list) {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [regression 3.15-rc3] Resume from s4 broken by 1f81b6d22a5980955b01e08cf27fb745dc9b686f
On 05/06/2014 02:41 PM, Ville Syrjälä wrote:
On Mon, May 05, 2014 at 12:32:22PM -0700, Julius Werner wrote:
Hmmm... very odd. I unfortunately don't have a machine that can easily
do S4 at hand, but I did test this on an IVB with XHCI_RESET_ON_RESUME
in S3 (essentially the same code path), and I didn't run into any
problems.
How exactly does your machine fail on resume? Is it a kernel crash or
just a hang? Can you try getting some debug output (by setting 'echo N
/sys/module/printk/parameters/console_suspend' and trying to catch
the crash on the screen or a serial line, or maybe through pstore)? I
really don't see much that could go wrong with this patch, so without
more info it will be hard to understand your problem.
Also, I noticed that you have two HID devices plugged in during
suspend. Does it make a difference if you have different devices (e.g.
a mass storage stick) or none at all?
Looks like it doesn't like it when there's anything plugged into the
SS ports. I tried with just a HID keyboard or with just a hub. In
both cases it fails to resume. If I have nothing connected to the SS
ports then it resumes just fine.
I managed to catch something with ramoops. Looks like it's hitting
POISON_FREE when trying to delete some list entry.
4[ 107.047230] xhci_hcd :00:14.0: Slot 1 endpoint 2 not removed from BW
list!
4[ 107.047574] general protection fault: [#1] PREEMPT SMP
I took a look at the xhci_mem_cleanup() function and to me it looks
like it tries to access a list_head that is already freed.
The struct list_head xhci-devs[].eps[].bw_endpoint_list is added to an endpoint
list in xhci-rh_bw[].bw_table.interval_bw[].endpoints
xhci_mem_cleanup() frees all devices (the allocated xhci-devs[], containing the
bw_endpoint_list) before it starts to loop through, and delete entries from the
xhci-rh_bw[].bw_table.interval_bw[].endpoints list.
I can't see how this relates to Julius patch though, and I'm not sure yet why it
only triggers when devices are connected to SS ports. Maybe just unlucky timing?
Does this help?:
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index c089668..b1a8a5f 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1822,6 +1822,16 @@ void xhci_mem_cleanup(struct xhci_hcd *xhci)
kfree(cur_cd);
}
+ num_ports = HCS_MAX_PORTS(xhci-hcs_params1);
+ for (i = 0; i num_ports; i++) {
+ struct xhci_interval_bw_table *bwt = xhci-rh_bw[i].bw_table;
+ for (j = 0; j XHCI_MAX_INTERVAL; j++) {
+ struct list_head *ep = bwt-interval_bw[j].endpoints;
+ while (!list_empty(ep))
+ list_del_init(ep-next);
+ }
+ }
+
for (i = 1; i MAX_HC_SLOTS; ++i)
xhci_free_virt_device(xhci, i);
@@ -1857,16 +1867,6 @@ void xhci_mem_cleanup(struct xhci_hcd *xhci)
if (!xhci-rh_bw)
goto no_bw;
- num_ports = HCS_MAX_PORTS(xhci-hcs_params1);
- for (i = 0; i num_ports; i++) {
- struct xhci_interval_bw_table *bwt = xhci-rh_bw[i].bw_table;
- for (j = 0; j XHCI_MAX_INTERVAL; j++) {
- struct list_head *ep = bwt-interval_bw[j].endpoints;
- while (!list_empty(ep))
- list_del_init(ep-next);
- }
- }
-
for (i = 0; i num_ports; i++) {
struct xhci_tt_bw_info *tt, *n;
list_for_each_entry_safe(tt, n, xhci-rh_bw[i].tts, tt_list) {
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: xhci: Correct last context entry calculation for Configure Endpoint
On 04/29/2014 06:11 AM, Julius Werner wrote: *bump* Sarah, Mathias, can we decide how to proceed with this? I think the section Alan quoted is a pretty good argument in favor of my interpretation (although of course this would not be the first time that two sections of a spec contradict each other). But more importantly, we have a case that just generates a clearly wrong Slot Context right now (the one that only drops endpoints), and I see no way how you could construct a correct Slot Context for that case with Sarah's interpretation. We need to resolve that somehow. We discussed with Sarah that we should try this out and queue it for usb-linus. This clearly fixes the generation of a invalid slot context if all endpoints are dropped. But because there hasn't been any reported issue about the other case this changes (always setting context entries to last valid ep in target configuration), and spec still has this tiny contradiction in this case, we should keep this out of stable. At least for now, until it gets some real world testing coverage. -Mathias -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: xhci: Correct last context entry calculation for Configure Endpoint
On 04/29/2014 06:11 AM, Julius Werner wrote: *bump* Sarah, Mathias, can we decide how to proceed with this? I think the section Alan quoted is a pretty good argument in favor of my interpretation (although of course this would not be the first time that two sections of a spec contradict each other). But more importantly, we have a case that just generates a clearly wrong Slot Context right now (the one that only drops endpoints), and I see no way how you could construct a correct Slot Context for that case with Sarah's interpretation. We need to resolve that somehow. We discussed with Sarah that we should try this out and queue it for usb-linus. This clearly fixes the generation of a invalid slot context if all endpoints are dropped. But because there hasn't been any reported issue about the other case this changes (always setting context entries to last valid ep in target configuration), and spec still has this tiny contradiction in this case, we should keep this out of stable. At least for now, until it gets some real world testing coverage. -Mathias -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/4] xhci: fixes for 3.15-rc usb-linus
On 04/25/2014 07:35 PM, Greg KH wrote: On Fri, Apr 25, 2014 at 07:20:12PM +0300, Mathias Nyman wrote: Hi Greg Second try at this xhci fixes series for 3.15-rc usb-linus. Most of them are very small fixes that didn't make it to 3.14, sitting and waiting for 3.15-rc1 to come out. Only the "Prefer endpoint context.." patch by Julius has a bit more content. These patches are picked together with Sarah, they are tested on top of 3.15-rc1, and apply on your current usb-linus branch Much better, all now applied. What's with all that trailing whitespace in your email text? Thanks for applying, and sorry about the whitespace errors. Did some copy-pasting between editors without proper whitespace detection set on all file types. I'll be more careful with these in the future -Mathias -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/4] xhci: fixes for 3.15-rc usb-linus
On 04/25/2014 07:35 PM, Greg KH wrote: On Fri, Apr 25, 2014 at 07:20:12PM +0300, Mathias Nyman wrote: Hi Greg Second try at this xhci fixes series for 3.15-rc usb-linus. Most of them are very small fixes that didn't make it to 3.14, sitting and waiting for 3.15-rc1 to come out. Only the Prefer endpoint context.. patch by Julius has a bit more content. These patches are picked together with Sarah, they are tested on top of 3.15-rc1, and apply on your current usb-linus branch Much better, all now applied. What's with all that trailing whitespace in your email text? Thanks for applying, and sorry about the whitespace errors. Did some copy-pasting between editors without proper whitespace detection set on all file types. I'll be more careful with these in the future -Mathias -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/4] usb: xhci: Prefer endpoint context dequeue pointer over stopped_trb
From: Julius Werner
We have observed a rare cycle state desync bug after Set TR Dequeue
Pointer commands on Intel LynxPoint xHCs (resulting in an endpoint that
doesn't fetch new TRBs and thus an unresponsive USB device). It always
triggers when a previous Set TR Dequeue Pointer command has set the
pointer to the final Link TRB of a segment, and then another URB gets
enqueued and cancelled again before it can be completed. Further
investigation showed that the xHC had returned the Link TRB in the TRB
Pointer field of the Transfer Event (CC == Stopped -- Length Invalid),
but when xhci_find_new_dequeue_state() later accesses the Endpoint
Context's TR Dequeue Pointer field it is set to the first TRB of the
next segment.
The driver expects those two values to be the same in this situation,
and uses the cycle state of the latter together with the address of the
former. This should be fine according to the XHCI specification, since
the endpoint ring should be stopped when returning the Transfer Event
and thus should not advance over the Link TRB before it gets restarted.
However, real-world XHCI implementations apparently don't really care
that much about these details, so the driver should follow a more
defensive approach to try to work around HC spec violations.
This patch removes the stopped_trb variable that had been used to store
the TRB Pointer from the last Transfer Event of a stopped TRB. Instead,
xhci_find_new_dequeue_state() now relies only on the Endpoint Context,
requiring a small amount of additional processing to find the virtual
address corresponding to the TR Dequeue Pointer. Some other parts of the
function were slightly rearranged to better fit into this model.
This patch should be backported to kernels as old as 2.6.31 that contain
the commit ae636747146ea97efa18e04576acd3416e2514f5 "USB: xhci: URB
cancellation support."
Signed-off-by: Julius Werner
Cc: sta...@vger.kernel.org
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci-ring.c | 67
drivers/usb/host/xhci.c | 1 -
drivers/usb/host/xhci.h | 2 --
3 files changed, 31 insertions(+), 39 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 5f926be..7a0e3c7 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -550,6 +550,7 @@ void xhci_find_new_dequeue_state(struct xhci_hcd *xhci,
struct xhci_ring *ep_ring;
struct xhci_generic_trb *trb;
dma_addr_t addr;
+ u64 hw_dequeue;
ep_ring = xhci_triad_to_transfer_ring(xhci, slot_id,
ep_index, stream_id);
@@ -559,16 +560,6 @@ void xhci_find_new_dequeue_state(struct xhci_hcd *xhci,
stream_id);
return;
}
- state->new_cycle_state = 0;
- xhci_dbg_trace(xhci, trace_xhci_dbg_cancel_urb,
- "Finding segment containing stopped TRB.");
- state->new_deq_seg = find_trb_seg(cur_td->start_seg,
- dev->eps[ep_index].stopped_trb,
- >new_cycle_state);
- if (!state->new_deq_seg) {
- WARN_ON(1);
- return;
- }
/* Dig out the cycle state saved by the xHC during the stop ep cmd */
xhci_dbg_trace(xhci, trace_xhci_dbg_cancel_urb,
@@ -577,46 +568,57 @@ void xhci_find_new_dequeue_state(struct xhci_hcd *xhci,
if (ep->ep_state & EP_HAS_STREAMS) {
struct xhci_stream_ctx *ctx =
>stream_info->stream_ctx_array[stream_id];
- state->new_cycle_state = 0x1 & le64_to_cpu(ctx->stream_ring);
+ hw_dequeue = le64_to_cpu(ctx->stream_ring);
} else {
struct xhci_ep_ctx *ep_ctx
= xhci_get_ep_ctx(xhci, dev->out_ctx, ep_index);
- state->new_cycle_state = 0x1 & le64_to_cpu(ep_ctx->deq);
+ hw_dequeue = le64_to_cpu(ep_ctx->deq);
}
+ /* Find virtual address and segment of hardware dequeue pointer */
+ state->new_deq_seg = ep_ring->deq_seg;
+ state->new_deq_ptr = ep_ring->dequeue;
+ while (xhci_trb_virt_to_dma(state->new_deq_seg, state->new_deq_ptr)
+ != (dma_addr_t)(hw_dequeue & ~0xf)) {
+ next_trb(xhci, ep_ring, >new_deq_seg,
+ >new_deq_ptr);
+ if (state->new_deq_ptr == ep_ring->dequeue) {
+ WARN_ON(1);
+ return;
+ }
+ }
+ /*
+* Find cycle state for last_trb, starting at old cycle state of
+* hw_dequeue. If there is only one segment ring, find_trb_seg() will
+* return immediately and cannot toggle the cycle state if this search
+* wraps around, so add one more toggle manually in t
[PATCH v2 4/4] usb/xhci: fix compilation warning when !CONFIG_PCI && !CONFIG_PM
From: David Cohen
When CONFIG_PCI and CONFIG_PM are not selected, xhci.c gets this
warning:
drivers/usb/host/xhci.c:409:13: warning: ‘xhci_msix_sync_irqs’ defined
but not used [-Wunused-function]
Instead of creating nested #ifdefs, this patch fixes it by defining the
xHCI PCI stubs as inline.
This warning has been in since 3.2 kernel and was
caused by commit 421aa841a134f6a743111cf44d0c6d3b45e3cf8c
"usb/xhci: hide MSI code behind PCI bars", but wasn't noticed
until 3.13 when a configuration with these options was tried
Signed-off-by: David Cohen
Cc: sta...@vger.kernel.org # 3.2
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 988ed5f..3008369 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -408,16 +408,16 @@ static int xhci_try_enable_msi(struct usb_hcd *hcd)
#else
-static int xhci_try_enable_msi(struct usb_hcd *hcd)
+static inline int xhci_try_enable_msi(struct usb_hcd *hcd)
{
return 0;
}
-static void xhci_cleanup_msix(struct xhci_hcd *xhci)
+static inline void xhci_cleanup_msix(struct xhci_hcd *xhci)
{
}
-static void xhci_msix_sync_irqs(struct xhci_hcd *xhci)
+static inline void xhci_msix_sync_irqs(struct xhci_hcd *xhci)
{
}
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/4] xhci: extend quirk for Renesas cards
From: Igor Gnatenko After suspend another Renesas PCI-X USB 3.0 card doesn't work. [root@fedora-20 ~]# lspci -vmnnd 1912: Device: 03:00.0 Class: USB controller [0c03] Vendor: Renesas Technology Corp. [1912] Device: uPD720202 USB 3.0 Host Controller [0015] SVendor:Renesas Technology Corp. [1912] SDevice:uPD720202 USB 3.0 Host Controller [0015] Rev:02 ProgIf: 30 This patch should be applied to stable kernel 3.14 that contain the commit 1aa9578c1a9450fb21501c4f549f5b1edb557e6d "xhci: Fix resume issues on Renesas chips in Samsung laptops" Reported-and-tested-by: Anatoly Kharchenko Reference: http://redmine.russianfedora.pro/issues/1315 Signed-off-by: Igor Gnatenko Cc: sta...@vger.kernel.org # 3.14 Signed-off-by: Mathias Nyman --- drivers/usb/host/xhci-pci.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c index 1715063..35d4477 100644 --- a/drivers/usb/host/xhci-pci.c +++ b/drivers/usb/host/xhci-pci.c @@ -145,9 +145,7 @@ static void xhci_pci_quirks(struct device *dev, struct xhci_hcd *xhci) xhci->quirks |= XHCI_TRUST_TX_LENGTH; } if (pdev->vendor == PCI_VENDOR_ID_RENESAS && - pdev->device == 0x0015 && - pdev->subsystem_vendor == PCI_VENDOR_ID_SAMSUNG && - pdev->subsystem_device == 0xc0cd) + pdev->device == 0x0015) xhci->quirks |= XHCI_RESET_ON_RESUME; if (pdev->vendor == PCI_VENDOR_ID_VIA) xhci->quirks |= XHCI_RESET_ON_RESUME; -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/4] xhci: Switch Intel Lynx Point ports to EHCI on shutdown.
From: Denis Turischev
The same issue like with Panther Point chipsets. If the USB ports are
switched to xHCI on shutdown, the xHCI host will send a spurious interrupt,
which will wake the system. Some BIOS have work around for this, but not all.
One example is Compulab's mini-desktop, the Intense-PC2.
The bug can be avoided if the USB ports are switched back to EHCI on
shutdown.
This patch should be backported to stable kernels as old as 3.12,
that contain the commit 638298dc66ea36623dbc2757a24fc2c4ab41b016
"xhci: Fix spurious wakeups after S5 on Haswell"
Signed-off-by: Denis Turischev
Cc: sta...@vger.kernel.org
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci-pci.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 47390e3..1715063 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -134,6 +134,8 @@ static void xhci_pci_quirks(struct device *dev, struct
xhci_hcd *xhci)
*/
if (pdev->subsystem_vendor == PCI_VENDOR_ID_HP)
xhci->quirks |= XHCI_SPURIOUS_WAKEUP;
+
+ xhci->quirks |= XHCI_SPURIOUS_REBOOT;
}
if (pdev->vendor == PCI_VENDOR_ID_ETRON &&
pdev->device == PCI_DEVICE_ID_ASROCK_P67) {
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/4] xhci: fixes for 3.15-rc usb-linus
Hi Greg Second try at this xhci fixes series for 3.15-rc usb-linus. Most of them are very small fixes that didn't make it to 3.14, sitting and waiting for 3.15-rc1 to come out. Only the "Prefer endpoint context.." patch by Julius has a bit more content. These patches are picked together with Sarah, they are tested on top of 3.15-rc1, and apply on your current usb-linus branch changes since v1: Drop "xhci: Use pci_enable_msix_exact() instead of pci_enable_msix()" from this fixes series, and move to for-usb-next (3.16) instead Add proper stable tags and information to commit messages -Mathias David Cohen (1): usb/xhci: fix compilation warning when !CONFIG_PCI && !CONFIG_PM Denis Turischev (1): xhci: Switch Intel Lynx Point ports to EHCI on shutdown. Igor Gnatenko (1): xhci: extend quirk for Renesas cards Julius Werner (1): usb: xhci: Prefer endpoint context dequeue pointer over stopped_trb drivers/usb/host/xhci-pci.c | 6 ++-- drivers/usb/host/xhci-ring.c | 67 drivers/usb/host/xhci.c | 7 ++--- drivers/usb/host/xhci.h | 2 -- 4 files changed, 37 insertions(+), 45 deletions(-) -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/5] xhci: Use pci_enable_msix_exact() instead of pci_enable_msix()
On 04/24/2014 10:49 PM, Greg KH wrote: On Tue, Apr 22, 2014 at 03:22:59PM +0300, Mathias Nyman wrote: From: Alexander Gordeev As result of deprecation of MSI-X/MSI enablement functions pci_enable_msix() and pci_enable_msi_block() all drivers using these two interfaces need to be updated to use the new pci_enable_msi_range() or pci_enable_msi_exact() and pci_enable_msix_range() or pci_enable_msix_exact() interfaces. Signed-off-by: Alexander Gordeev Cc: Sarah Sharp Cc: Greg Kroah-Hartman Cc: linux-...@vger.kernel.org Cc: linux-...@vger.kernel.org Signed-off-by: Mathias Nyman --- drivers/usb/host/xhci.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c index 988ed5f..b0b8399 100644 --- a/drivers/usb/host/xhci.c +++ b/drivers/usb/host/xhci.c @@ -291,7 +291,7 @@ static int xhci_setup_msix(struct xhci_hcd *xhci) xhci->msix_entries[i].vector = 0; } - ret = pci_enable_msix(pdev, xhci->msix_entries, xhci->msix_count); + ret = pci_enable_msix_exact(pdev, xhci->msix_entries, xhci->msix_count); Why is this change needed for 3.15-final? Can't remember why I thought this was needed for 3.15 Looks like other subsystems (like PCI) just queued similar MSI changes for 3.16. I'll move it to the patchseries for usb-next -Mathias -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] xhci: fixes for 3.15-rc usb-linus
On 04/24/2014 10:50 PM, Greg KH wrote: On Tue, Apr 22, 2014 at 03:22:57PM +0300, Mathias Nyman wrote: Hi Greg Here are the xhci fixes for 3.15-rc usb-linus. Most of them are very small fixes that didn't make it to 3.14, sitting and waiting for 3.15-rc1 to come out. Only the "Prefer endpoint context.." patch by Julius has a bit more content. These patches are picked together with Sarah, they are tested on top of 3.15-rc1, and apply on your current usb-linus branch Please redo all of these based on my comments. Will do Thanks for the feedback -Mathias -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] xhci: fixes for 3.15-rc usb-linus
On 04/24/2014 10:50 PM, Greg KH wrote: On Tue, Apr 22, 2014 at 03:22:57PM +0300, Mathias Nyman wrote: Hi Greg Here are the xhci fixes for 3.15-rc usb-linus. Most of them are very small fixes that didn't make it to 3.14, sitting and waiting for 3.15-rc1 to come out. Only the Prefer endpoint context.. patch by Julius has a bit more content. These patches are picked together with Sarah, they are tested on top of 3.15-rc1, and apply on your current usb-linus branch Please redo all of these based on my comments. Will do Thanks for the feedback -Mathias -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/5] xhci: Use pci_enable_msix_exact() instead of pci_enable_msix()
On 04/24/2014 10:49 PM, Greg KH wrote: On Tue, Apr 22, 2014 at 03:22:59PM +0300, Mathias Nyman wrote: From: Alexander Gordeev agord...@redhat.com As result of deprecation of MSI-X/MSI enablement functions pci_enable_msix() and pci_enable_msi_block() all drivers using these two interfaces need to be updated to use the new pci_enable_msi_range() or pci_enable_msi_exact() and pci_enable_msix_range() or pci_enable_msix_exact() interfaces. Signed-off-by: Alexander Gordeev agord...@redhat.com Cc: Sarah Sharp sarah.a.sh...@linux.intel.com Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: linux-...@vger.kernel.org Cc: linux-...@vger.kernel.org Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com --- drivers/usb/host/xhci.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c index 988ed5f..b0b8399 100644 --- a/drivers/usb/host/xhci.c +++ b/drivers/usb/host/xhci.c @@ -291,7 +291,7 @@ static int xhci_setup_msix(struct xhci_hcd *xhci) xhci-msix_entries[i].vector = 0; } - ret = pci_enable_msix(pdev, xhci-msix_entries, xhci-msix_count); + ret = pci_enable_msix_exact(pdev, xhci-msix_entries, xhci-msix_count); Why is this change needed for 3.15-final? Can't remember why I thought this was needed for 3.15 Looks like other subsystems (like PCI) just queued similar MSI changes for 3.16. I'll move it to the patchseries for usb-next -Mathias -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/4] xhci: fixes for 3.15-rc usb-linus
Hi Greg Second try at this xhci fixes series for 3.15-rc usb-linus. Most of them are very small fixes that didn't make it to 3.14, sitting and waiting for 3.15-rc1 to come out. Only the Prefer endpoint context.. patch by Julius has a bit more content. These patches are picked together with Sarah, they are tested on top of 3.15-rc1, and apply on your current usb-linus branch changes since v1: Drop xhci: Use pci_enable_msix_exact() instead of pci_enable_msix() from this fixes series, and move to for-usb-next (3.16) instead Add proper stable tags and information to commit messages -Mathias David Cohen (1): usb/xhci: fix compilation warning when !CONFIG_PCI !CONFIG_PM Denis Turischev (1): xhci: Switch Intel Lynx Point ports to EHCI on shutdown. Igor Gnatenko (1): xhci: extend quirk for Renesas cards Julius Werner (1): usb: xhci: Prefer endpoint context dequeue pointer over stopped_trb drivers/usb/host/xhci-pci.c | 6 ++-- drivers/usb/host/xhci-ring.c | 67 drivers/usb/host/xhci.c | 7 ++--- drivers/usb/host/xhci.h | 2 -- 4 files changed, 37 insertions(+), 45 deletions(-) -- 1.8.3.2 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/4] xhci: Switch Intel Lynx Point ports to EHCI on shutdown.
From: Denis Turischev denis.turisc...@compulab.co.il
The same issue like with Panther Point chipsets. If the USB ports are
switched to xHCI on shutdown, the xHCI host will send a spurious interrupt,
which will wake the system. Some BIOS have work around for this, but not all.
One example is Compulab's mini-desktop, the Intense-PC2.
The bug can be avoided if the USB ports are switched back to EHCI on
shutdown.
This patch should be backported to stable kernels as old as 3.12,
that contain the commit 638298dc66ea36623dbc2757a24fc2c4ab41b016
xhci: Fix spurious wakeups after S5 on Haswell
Signed-off-by: Denis Turischev de...@compulab.co.il
Cc: sta...@vger.kernel.org
Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com
---
drivers/usb/host/xhci-pci.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 47390e3..1715063 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -134,6 +134,8 @@ static void xhci_pci_quirks(struct device *dev, struct
xhci_hcd *xhci)
*/
if (pdev-subsystem_vendor == PCI_VENDOR_ID_HP)
xhci-quirks |= XHCI_SPURIOUS_WAKEUP;
+
+ xhci-quirks |= XHCI_SPURIOUS_REBOOT;
}
if (pdev-vendor == PCI_VENDOR_ID_ETRON
pdev-device == PCI_DEVICE_ID_ASROCK_P67) {
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 4/4] usb/xhci: fix compilation warning when !CONFIG_PCI !CONFIG_PM
From: David Cohen david.a.co...@linux.intel.com
When CONFIG_PCI and CONFIG_PM are not selected, xhci.c gets this
warning:
drivers/usb/host/xhci.c:409:13: warning: ‘xhci_msix_sync_irqs’ defined
but not used [-Wunused-function]
Instead of creating nested #ifdefs, this patch fixes it by defining the
xHCI PCI stubs as inline.
This warning has been in since 3.2 kernel and was
caused by commit 421aa841a134f6a743111cf44d0c6d3b45e3cf8c
usb/xhci: hide MSI code behind PCI bars, but wasn't noticed
until 3.13 when a configuration with these options was tried
Signed-off-by: David Cohen david.a.co...@linux.intel.com
Cc: sta...@vger.kernel.org # 3.2
Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com
---
drivers/usb/host/xhci.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 988ed5f..3008369 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -408,16 +408,16 @@ static int xhci_try_enable_msi(struct usb_hcd *hcd)
#else
-static int xhci_try_enable_msi(struct usb_hcd *hcd)
+static inline int xhci_try_enable_msi(struct usb_hcd *hcd)
{
return 0;
}
-static void xhci_cleanup_msix(struct xhci_hcd *xhci)
+static inline void xhci_cleanup_msix(struct xhci_hcd *xhci)
{
}
-static void xhci_msix_sync_irqs(struct xhci_hcd *xhci)
+static inline void xhci_msix_sync_irqs(struct xhci_hcd *xhci)
{
}
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/4] xhci: extend quirk for Renesas cards
From: Igor Gnatenko i.gnatenko.br...@gmail.com After suspend another Renesas PCI-X USB 3.0 card doesn't work. [root@fedora-20 ~]# lspci -vmnnd 1912: Device: 03:00.0 Class: USB controller [0c03] Vendor: Renesas Technology Corp. [1912] Device: uPD720202 USB 3.0 Host Controller [0015] SVendor:Renesas Technology Corp. [1912] SDevice:uPD720202 USB 3.0 Host Controller [0015] Rev:02 ProgIf: 30 This patch should be applied to stable kernel 3.14 that contain the commit 1aa9578c1a9450fb21501c4f549f5b1edb557e6d xhci: Fix resume issues on Renesas chips in Samsung laptops Reported-and-tested-by: Anatoly Kharchenko rfr-b...@yandex.ru Reference: http://redmine.russianfedora.pro/issues/1315 Signed-off-by: Igor Gnatenko i.gnatenko.br...@gmail.com Cc: sta...@vger.kernel.org # 3.14 Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com --- drivers/usb/host/xhci-pci.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c index 1715063..35d4477 100644 --- a/drivers/usb/host/xhci-pci.c +++ b/drivers/usb/host/xhci-pci.c @@ -145,9 +145,7 @@ static void xhci_pci_quirks(struct device *dev, struct xhci_hcd *xhci) xhci-quirks |= XHCI_TRUST_TX_LENGTH; } if (pdev-vendor == PCI_VENDOR_ID_RENESAS - pdev-device == 0x0015 - pdev-subsystem_vendor == PCI_VENDOR_ID_SAMSUNG - pdev-subsystem_device == 0xc0cd) + pdev-device == 0x0015) xhci-quirks |= XHCI_RESET_ON_RESUME; if (pdev-vendor == PCI_VENDOR_ID_VIA) xhci-quirks |= XHCI_RESET_ON_RESUME; -- 1.8.3.2 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/4] usb: xhci: Prefer endpoint context dequeue pointer over stopped_trb
From: Julius Werner jwer...@chromium.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 ae636747146ea97efa18e04576acd3416e2514f5 USB: xhci: URB
cancellation support.
Signed-off-by: Julius Werner jwer...@chromium.org
Cc: sta...@vger.kernel.org
Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com
---
drivers/usb/host/xhci-ring.c | 67
drivers/usb/host/xhci.c | 1 -
drivers/usb/host/xhci.h | 2 --
3 files changed, 31 insertions(+), 39 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 5f926be..7a0e3c7 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -550,6 +550,7 @@ void xhci_find_new_dequeue_state(struct xhci_hcd *xhci,
struct xhci_ring *ep_ring;
struct xhci_generic_trb *trb;
dma_addr_t addr;
+ u64 hw_dequeue;
ep_ring = xhci_triad_to_transfer_ring(xhci, slot_id,
ep_index, stream_id);
@@ -559,16 +560,6 @@ void xhci_find_new_dequeue_state(struct xhci_hcd *xhci,
stream_id);
return;
}
- state-new_cycle_state = 0;
- xhci_dbg_trace(xhci, trace_xhci_dbg_cancel_urb,
- Finding segment containing stopped TRB.);
- state-new_deq_seg = find_trb_seg(cur_td-start_seg,
- dev-eps[ep_index].stopped_trb,
- state-new_cycle_state);
- if (!state-new_deq_seg) {
- WARN_ON(1);
- return;
- }
/* Dig out the cycle state saved by the xHC during the stop ep cmd */
xhci_dbg_trace(xhci, trace_xhci_dbg_cancel_urb,
@@ -577,46 +568,57 @@ void xhci_find_new_dequeue_state(struct xhci_hcd *xhci,
if (ep-ep_state EP_HAS_STREAMS) {
struct xhci_stream_ctx *ctx =
ep-stream_info-stream_ctx_array[stream_id];
- state-new_cycle_state = 0x1 le64_to_cpu(ctx-stream_ring);
+ hw_dequeue = le64_to_cpu(ctx-stream_ring);
} else {
struct xhci_ep_ctx *ep_ctx
= xhci_get_ep_ctx(xhci, dev-out_ctx, ep_index);
- state-new_cycle_state = 0x1 le64_to_cpu(ep_ctx-deq);
+ hw_dequeue = le64_to_cpu(ep_ctx-deq);
}
+ /* Find virtual address and segment of hardware dequeue pointer */
+ state-new_deq_seg = ep_ring-deq_seg;
+ state-new_deq_ptr = ep_ring-dequeue;
+ while (xhci_trb_virt_to_dma(state-new_deq_seg, state-new_deq_ptr)
+ != (dma_addr_t)(hw_dequeue ~0xf)) {
+ next_trb(xhci, ep_ring, state-new_deq_seg,
+ state-new_deq_ptr);
+ if (state-new_deq_ptr == ep_ring-dequeue) {
+ WARN_ON(1);
+ return;
+ }
+ }
+ /*
+* Find cycle state for last_trb, starting at old cycle state of
+* hw_dequeue. If there is only one segment ring, find_trb_seg() will
+* return immediately and cannot toggle the cycle state if this search
+* wraps around, so add one more toggle manually in that case.
+*/
+ state-new_cycle_state
Re: [PATCH v3 1/1] pinctrl: add Intel BayTrail GPIO/pinctrl support
On 04/17/2014 07:47 PM, Timur Tabi wrote:
On 04/15/2014 05:01 AM, Mathias Nyman wrote:
This device will only be used on an ACPI system, right? And isn't ACPI
supposed to hide all the pinctrl programming from the OS? I thought
that was the whole point behind ACPI and the reason why ARM64 isn't
going to use device trees.
This was my starting point as well, and the driver was initially
submitted as a GPIO driver. But Linus W. suggested pinctrl instead, and
as he's the maintainer of both those subsystem I trust his judgment.
Do you think, for an ACPI pinctrl driver, that we will need to specify
any function groups? When I look at the ASL that configures GPIOs, I
see only lines like this:
GpioIo (Exclusive, PullDefault, , , , "\\GIO0") {0x1D, 0x1E}
This tells me that ACPI will never use any of the names that are
defined. I see that .get_function_name is called on my ACPI system, but
I don't see where it is used.
The reason I ask is because I would like to make a "generic" ACPI
pinctrl/gpio driver that doesn't specify any pin groups. So if we use
the same pinctrl/gpio hardware on multiple SOCs, the only thing that the
driver needs from ACPI is the number of pins.
Mika, Rafael (and me) have done some effort already on supporting ACPI
gpio resources.
ACPI code creates a platfrom device out of the GPIO device defined ACPI
tables, with all the resources set, and a hook back to the ACPI node.
Helper functions to translate the ACPI GpioIO and GpioInt resources to
linux gpio numbers can be found in gpio/gpiolib-acpi.c together with
other ACPI and gpio related helper functions.
see also
Documentation/acpi/enumeration.txt for some GPIO and ACPI related info
-Mathias
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl-baytrail: workaround for irq descriptor conflict on ASUS T100TA
Urgent fix and the maintainers did not react in a week? Well maybe they need
to be on the To: line...
Mathias: can you send a patch adding yourself as maintainer of this
driver in the MAINTAINERS file so stuff like this does not fall to the
floor (me)?
Hi,
Sorry about the delay. I'm taking over Sarah's role as usb3 xhci
maintainer and got my hands full over there. I can look at these
patches now and then but you might need to kick me.
In general, I'd agree with Mika, Andy and Heikki (and Rafael obviously)
opinion regarding baytrail gpio / acpi related matters.
Second: this fix is ugly like hell, is it really the best we can think
of, plus in the commit message I'd very much like to know the
real issue behind this as people in the x86 camp seem to be
using some strange static IRQ line assignments that I cannot
really understand so I don't know what the proper fix for this is :-(
This patch went out a bit early, a new version (which is not mangled)
can be found at:
http://marc.info/?l=linux-kernel=139765010717522=2
But that one still produces some compiler warning which should be fixed.
There might be some touchscreen related issues recently found related to
this patch that need to be investigated ( see bug link in commit message)
This is a hack to get T100TA working. This is one of many bad ways to
workaround the real issue instead of fixing it, and I hope it can be
reverted later, but this is the best we can do with our (my) limited
io-apic and interrupt knowledge. But in the end, with this the Asus
T100TA gpio works somehow, without it, it doesn't.
The real issue to my understanding is that the x86 io-apic code is not
really capable of living together with other interrupt controllers at
the same time. There are some assumptions that interrupts 0-15 belong to
the legacy ISA world, from there on we got io-apic PCI interrupts
( I think io-apic interrupt controller handles something like 24 - 48
interrupts?) we want to be outside that range until this is fixed.
The x86 io-apic code does nasty things, for example the function
that allocates the irq and the private chip data assumes that if the irq
descriptor is taken, (returns -EEXISTS) then io-apic just must have
reserved it earlier and can anyway use it, and access the chip data in a
format only io-apic (struct irq_cfg) uses. This is of course not the
case if a gpio interrupt controller like pinctrl-baytrail reserved the
interrupt descriptor earler. -> oops
here's the io_apic.c function:
static struct irq_cfg *alloc_irq_and_cfg_at(unsigned int at, int node)
{
int res = irq_alloc_desc_at(at, node);
struct irq_cfg *cfg;
if (res < 0) {
if (res != -EEXIST)
return NULL;
cfg = irq_get_chip_data(at);
if (cfg)
return cfg;
}
cfg = alloc_irq_cfg(at, node);
if (cfg)
irq_set_chip_data(at, cfg);
else
irq_free_desc(at);
return cfg;
}
We tried to fix this particular issue (make sure the interrupt belongs
to a io_apic controller before letting io_apic touch it), but we just
opened a can of worms of other issues I don't know how to deal with.
-Mathias
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl-baytrail: workaround for irq descriptor conflict on ASUS T100TA
Urgent fix and the maintainers did not react in a week? Well maybe they need
to be on the To: line...
Mathias: can you send a patch adding yourself as maintainer of this
driver in the MAINTAINERS file so stuff like this does not fall to the
floor (me)?
Hi,
Sorry about the delay. I'm taking over Sarah's role as usb3 xhci
maintainer and got my hands full over there. I can look at these
patches now and then but you might need to kick me.
In general, I'd agree with Mika, Andy and Heikki (and Rafael obviously)
opinion regarding baytrail gpio / acpi related matters.
Second: this fix is ugly like hell, is it really the best we can think
of, plus in the commit message I'd very much like to know the
real issue behind this as people in the x86 camp seem to be
using some strange static IRQ line assignments that I cannot
really understand so I don't know what the proper fix for this is :-(
This patch went out a bit early, a new version (which is not mangled)
can be found at:
http://marc.info/?l=linux-kernelm=139765010717522w=2
But that one still produces some compiler warning which should be fixed.
There might be some touchscreen related issues recently found related to
this patch that need to be investigated ( see bug link in commit message)
This is a hack to get T100TA working. This is one of many bad ways to
workaround the real issue instead of fixing it, and I hope it can be
reverted later, but this is the best we can do with our (my) limited
io-apic and interrupt knowledge. But in the end, with this the Asus
T100TA gpio works somehow, without it, it doesn't.
The real issue to my understanding is that the x86 io-apic code is not
really capable of living together with other interrupt controllers at
the same time. There are some assumptions that interrupts 0-15 belong to
the legacy ISA world, from there on we got io-apic PCI interrupts
( I think io-apic interrupt controller handles something like 24 - 48
interrupts?) we want to be outside that range until this is fixed.
The x86 io-apic code does nasty things, for example the function
that allocates the irq and the private chip data assumes that if the irq
descriptor is taken, (returns -EEXISTS) then io-apic just must have
reserved it earlier and can anyway use it, and access the chip data in a
format only io-apic (struct irq_cfg) uses. This is of course not the
case if a gpio interrupt controller like pinctrl-baytrail reserved the
interrupt descriptor earler. - oops
here's the io_apic.c function:
static struct irq_cfg *alloc_irq_and_cfg_at(unsigned int at, int node)
{
int res = irq_alloc_desc_at(at, node);
struct irq_cfg *cfg;
if (res 0) {
if (res != -EEXIST)
return NULL;
cfg = irq_get_chip_data(at);
if (cfg)
return cfg;
}
cfg = alloc_irq_cfg(at, node);
if (cfg)
irq_set_chip_data(at, cfg);
else
irq_free_desc(at);
return cfg;
}
We tried to fix this particular issue (make sure the interrupt belongs
to a io_apic controller before letting io_apic touch it), but we just
opened a can of worms of other issues I don't know how to deal with.
-Mathias
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/1] pinctrl: add Intel BayTrail GPIO/pinctrl support
On 04/17/2014 07:47 PM, Timur Tabi wrote:
On 04/15/2014 05:01 AM, Mathias Nyman wrote:
This device will only be used on an ACPI system, right? And isn't ACPI
supposed to hide all the pinctrl programming from the OS? I thought
that was the whole point behind ACPI and the reason why ARM64 isn't
going to use device trees.
This was my starting point as well, and the driver was initially
submitted as a GPIO driver. But Linus W. suggested pinctrl instead, and
as he's the maintainer of both those subsystem I trust his judgment.
Do you think, for an ACPI pinctrl driver, that we will need to specify
any function groups? When I look at the ASL that configures GPIOs, I
see only lines like this:
GpioIo (Exclusive, PullDefault, , , , \\GIO0) {0x1D, 0x1E}
This tells me that ACPI will never use any of the names that are
defined. I see that .get_function_name is called on my ACPI system, but
I don't see where it is used.
The reason I ask is because I would like to make a generic ACPI
pinctrl/gpio driver that doesn't specify any pin groups. So if we use
the same pinctrl/gpio hardware on multiple SOCs, the only thing that the
driver needs from ACPI is the number of pins.
Mika, Rafael (and me) have done some effort already on supporting ACPI
gpio resources.
ACPI code creates a platfrom device out of the GPIO device defined ACPI
tables, with all the resources set, and a hook back to the ACPI node.
Helper functions to translate the ACPI GpioIO and GpioInt resources to
linux gpio numbers can be found in gpio/gpiolib-acpi.c together with
other ACPI and gpio related helper functions.
see also
Documentation/acpi/enumeration.txt for some GPIO and ACPI related info
-Mathias
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND] [PATCH] xhci: Switch Intel Lynx Point ports to EHCI on shutdown.
On 04/22/2014 02:04 PM, Denis Turischev wrote: Hi Mathias, Just want to remind you about the patch, thanks. Sent to Greg a minute ago, thanks -Mathias -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
