* [patch 1/3] staging: fix comedi build when ISA_DMA_API is enabled but COMEDI_PCI is not enabled
2011-09-19 23:09 [patch 0/3] Staging and USB fixes for 3.1 Greg KH
@ 2011-09-19 23:05 ` Greg KH
2011-09-19 23:05 ` [patch 2/3] USB: xhci: Set change bit when warm reset change is set Greg KH
2011-09-19 23:05 ` [patch 3/3] USB: xHCI: prevent infinite loop when processing MSE event Greg KH
2 siblings, 0 replies; 6+ messages in thread
From: Greg KH @ 2011-09-19 23:05 UTC (permalink / raw)
To: torvalds, Greg KH
Cc: linux-kernel, linux-usb, Randy Dunlap, Sarah Sharp, Andiry Xu
From: Randy Dunlap <rdunlap@xenotime.net>
Fix build when CONFIG_ISA_DMA_API is enabled but
CONFIG_COMEDI_PCI[_DRIVERS] is not enabled.
Fixes these build errors:
drivers/staging/comedi/drivers/ni_labpc.c: In function 'labpc_ai_cmd':
drivers/staging/comedi/drivers/ni_labpc.c:1351: error: implicit declaration of function 'labpc_suggest_transfer_size'
drivers/staging/comedi/drivers/ni_labpc.c: At top level:
drivers/staging/comedi/drivers/ni_labpc.c:1802: error: conflicting types for 'labpc_suggest_transfer_size'
drivers/staging/comedi/drivers/ni_labpc.c:1351: note: previous implicit declaration of 'labpc_suggest_transfer_size' was here
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/staging/comedi/drivers/ni_labpc.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/staging/comedi/drivers/ni_labpc.c
+++ b/drivers/staging/comedi/drivers/ni_labpc.c
@@ -241,8 +241,10 @@ static int labpc_eeprom_write_insn(struc
struct comedi_insn *insn,
unsigned int *data);
static void labpc_adc_timing(struct comedi_device *dev, struct comedi_cmd *cmd);
-#ifdef CONFIG_COMEDI_PCI
+#ifdef CONFIG_ISA_DMA_API
static unsigned int labpc_suggest_transfer_size(struct comedi_cmd cmd);
+#endif
+#ifdef CONFIG_COMEDI_PCI
static int labpc_find_device(struct comedi_device *dev, int bus, int slot);
#endif
static int labpc_dio_mem_callback(int dir, int port, int data,
^ permalink raw reply [flat|nested] 6+ messages in thread
* [patch 2/3] USB: xhci: Set change bit when warm reset change is set.
2011-09-19 23:09 [patch 0/3] Staging and USB fixes for 3.1 Greg KH
2011-09-19 23:05 ` [patch 1/3] staging: fix comedi build when ISA_DMA_API is enabled but COMEDI_PCI is not enabled Greg KH
@ 2011-09-19 23:05 ` Greg KH
2011-09-20 11:22 ` Sergei Shtylyov
2011-09-19 23:05 ` [patch 3/3] USB: xHCI: prevent infinite loop when processing MSE event Greg KH
2 siblings, 1 reply; 6+ messages in thread
From: Greg KH @ 2011-09-19 23:05 UTC (permalink / raw)
To: torvalds
Cc: linux-kernel, linux-usb, Sarah Sharp, stable, Andiry Xu, Randy Dunlap
Sometimes, when a USB 3.0 device is disconnected, the Intel Panther Point
xHCI host controller will report a link state change with the state set
to "SS.Inactive". This causes the xHCI host controller to issue a warm
port reset, which doesn't finish before the USB core times out while
waiting for it to complete.
When the warm port reset does complete, and the xHC gives back a port
status change event, the xHCI driver kicks khubd. However, it fails to
set the bit indicating there is a change event for that port because the
logic in xhci-hub.c doesn't check for the warm port reset bit.
After that, the warm port status change bit is never cleared by the USB
core, and the xHC stops reporting port status change bits. (The xHCI spec
says it shouldn't report more port events until all change bits are
cleared.) This means any port changes when a new device is connected will
never be reported, and the port will seem "dead" until the xHCI driver is
unloaded and reloaded, or the computer is rebooted. Fix this by making
the xHCI driver set the port change bit when a warm port reset change bit
is set.
A better solution would be to make the USB core handle warm port reset in
differently, merging the current code with the standard port reset code
that does an incremental backoff on the timeout, and tries to complete the
port reset two more times before giving up. That more complicated fix
will be merged next window, and this fix will be backported to stable.
This should be backported to kernels as old as 3.0, since that was the
first kernel with commit a11496ebf37534177d67222285e8debed7a39788
"xHCI: warm reset support".
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/usb/host/xhci-hub.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -761,7 +761,7 @@ int xhci_hub_status_data(struct usb_hcd
memset(buf, 0, retval);
status = 0;
- mask = PORT_CSC | PORT_PEC | PORT_OCC | PORT_PLC;
+ mask = PORT_CSC | PORT_PEC | PORT_OCC | PORT_PLC | PORT_WRC;
spin_lock_irqsave(&xhci->lock, flags);
/* For each port, did anything change? If so, set that bit in buf. */
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [patch 2/3] USB: xhci: Set change bit when warm reset change is set.
2011-09-19 23:05 ` [patch 2/3] USB: xhci: Set change bit when warm reset change is set Greg KH
@ 2011-09-20 11:22 ` Sergei Shtylyov
2011-09-20 12:58 ` Greg KH
0 siblings, 1 reply; 6+ messages in thread
From: Sergei Shtylyov @ 2011-09-20 11:22 UTC (permalink / raw)
To: Greg KH
Cc: torvalds, linux-kernel, linux-usb, Sarah Sharp, stable,
Andiry Xu, Randy Dunlap
Hello.
On 20-09-2011 3:05, Greg KH wrote:
From: line is missing?
> Sometimes, when a USB 3.0 device is disconnected, the Intel Panther Point
> xHCI host controller will report a link state change with the state set
> to "SS.Inactive". This causes the xHCI host controller to issue a warm
> port reset, which doesn't finish before the USB core times out while
> waiting for it to complete.
> When the warm port reset does complete, and the xHC gives back a port
> status change event, the xHCI driver kicks khubd. However, it fails to
> set the bit indicating there is a change event for that port because the
> logic in xhci-hub.c doesn't check for the warm port reset bit.
> After that, the warm port status change bit is never cleared by the USB
> core, and the xHC stops reporting port status change bits. (The xHCI spec
> says it shouldn't report more port events until all change bits are
> cleared.) This means any port changes when a new device is connected will
> never be reported, and the port will seem "dead" until the xHCI driver is
> unloaded and reloaded, or the computer is rebooted. Fix this by making
> the xHCI driver set the port change bit when a warm port reset change bit
> is set.
> A better solution would be to make the USB core handle warm port reset in
> differently, merging the current code with the standard port reset code
> that does an incremental backoff on the timeout, and tries to complete the
> port reset two more times before giving up. That more complicated fix
> will be merged next window, and this fix will be backported to stable.
> This should be backported to kernels as old as 3.0, since that was the
> first kernel with commit a11496ebf37534177d67222285e8debed7a39788
> "xHCI: warm reset support".
> Signed-off-by: Sarah Sharp<sarah.a.sharp@linux.intel.com>
> Cc: stable@kernel.org
> Signed-off-by: Greg Kroah-Hartman<gregkh@suse.de>
WBR, Sergei
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [patch 2/3] USB: xhci: Set change bit when warm reset change is set.
2011-09-20 11:22 ` Sergei Shtylyov
@ 2011-09-20 12:58 ` Greg KH
0 siblings, 0 replies; 6+ messages in thread
From: Greg KH @ 2011-09-20 12:58 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Greg KH, torvalds, linux-kernel, linux-usb, Sarah Sharp, stable,
Andiry Xu, Randy Dunlap
On Tue, Sep 20, 2011 at 03:22:07PM +0400, Sergei Shtylyov wrote:
> Hello.
>
> On 20-09-2011 3:05, Greg KH wrote:
>
> From: line is missing?
Crap, me switching from git to quilt caused this to happen. My
apologies Sarah.
greg k-h
^ permalink raw reply [flat|nested] 6+ messages in thread
* [patch 3/3] USB: xHCI: prevent infinite loop when processing MSE event
2011-09-19 23:09 [patch 0/3] Staging and USB fixes for 3.1 Greg KH
2011-09-19 23:05 ` [patch 1/3] staging: fix comedi build when ISA_DMA_API is enabled but COMEDI_PCI is not enabled Greg KH
2011-09-19 23:05 ` [patch 2/3] USB: xhci: Set change bit when warm reset change is set Greg KH
@ 2011-09-19 23:05 ` Greg KH
2 siblings, 0 replies; 6+ messages in thread
From: Greg KH @ 2011-09-19 23:05 UTC (permalink / raw)
To: torvalds; +Cc: linux-kernel, linux-usb, Andiry Xu, Sarah Sharp, Randy Dunlap
From: Andiry Xu <andiry.xu@amd.com>
When a xHC host is unable to handle isochronous transfer in the interval,
it reports a Missed Service Error event and skips some tds.
Currently xhci driver handles MSE event in the following ways:
1. When encounter a MSE event, set ep->skip flag, update event ring dequeue
pointer and return.
2. When encounter the next event on this ep, the driver will run the do-while
loop, fetch td from ep's td_list to find the td corresponding to this event.
All tds missed are marked as short transfer(-EXDEV).
The do-while loop will end in two ways:
1. If the td pointed by the event trb is found;
2. If the ep ring's td_list is empty.
However, if a buggy HW reports some unpredicted event (for example, an overrun
event following a MSE event while the ep ring is actually not empty), the
driver will never find the td, and it will loop until the td_list is empty.
Unfortunately, the spinlock is dropped when give back a urb in the do-while
loop. During the spinlock released period, the class driver may still
submit urbs and add tds to the td_list. This may cause disaster, since the
td_list will never be empty and the loop never ends, and the system hangs.
To fix this, count the number of TDs on the ep ring before skipping TDs, and
quit the loop when skipped that number of tds. This guarantees the do-while
loop will end after certain number of cycles, and driver will not be trapped
in an infinite loop.
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/usb/host/xhci-ring.c | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1934,8 +1934,10 @@ static int handle_tx_event(struct xhci_h
int status = -EINPROGRESS;
struct urb_priv *urb_priv;
struct xhci_ep_ctx *ep_ctx;
+ struct list_head *tmp;
u32 trb_comp_code;
int ret = 0;
+ int td_num = 0;
slot_id = TRB_TO_SLOT_ID(le32_to_cpu(event->flags));
xdev = xhci->devs[slot_id];
@@ -1957,6 +1959,12 @@ static int handle_tx_event(struct xhci_h
return -ENODEV;
}
+ /* Count current td numbers if ep->skip is set */
+ if (ep->skip) {
+ list_for_each(tmp, &ep_ring->td_list)
+ td_num++;
+ }
+
event_dma = le64_to_cpu(event->buffer);
trb_comp_code = GET_COMP_CODE(le32_to_cpu(event->transfer_len));
/* Look for common error cases */
@@ -2068,7 +2076,18 @@ static int handle_tx_event(struct xhci_h
goto cleanup;
}
+ /* We've skipped all the TDs on the ep ring when ep->skip set */
+ if (ep->skip && td_num == 0) {
+ ep->skip = false;
+ xhci_dbg(xhci, "All tds on the ep_ring skipped. "
+ "Clear skip flag.\n");
+ ret = 0;
+ goto cleanup;
+ }
+
td = list_entry(ep_ring->td_list.next, struct xhci_td, td_list);
+ if (ep->skip)
+ td_num--;
/* Is this a TRB in the currently executing TD? */
event_seg = trb_in_td(ep_ring->deq_seg, ep_ring->dequeue,
^ permalink raw reply [flat|nested] 6+ messages in thread