Signed-off-by: Maarten Lankhorst <[email protected]>
---
drivers/usb/host/xhci-dbg.c | 8 ++++----
drivers/usb/host/xhci.h | 5 +++++
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/host/xhci-dbg.c b/drivers/usb/host/xhci-dbg.c
index 2e04861..1f50b44 100644
--- a/drivers/usb/host/xhci-dbg.c
+++ b/drivers/usb/host/xhci-dbg.c
@@ -438,13 +438,13 @@ char *xhci_get_slot_state(struct xhci_hcd *xhci,
struct xhci_slot_ctx *slot_ctx = xhci_get_slot_ctx(xhci, ctx);
switch (GET_SLOT_STATE(le32_to_cpu(slot_ctx->dev_state))) {
- case 0:
+ case SLOT_STATE_ENABLED:
return "enabled/disabled";
- case 1:
+ case SLOT_STATE_DEFAULT:
return "default";
- case 2:
+ case SLOT_STATE_ADDRESSED:
return "addressed";
- case 3:
+ case SLOT_STATE_CONFIGURED:
return "configured";
default:
return "reserved";
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index ac0196e..bbc1d9a 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -560,6 +560,11 @@ struct xhci_slot_ctx {
#define SLOT_STATE (0x1f << 27)
#define GET_SLOT_STATE(p) (((p) & (0x1f << 27)) >> 27)
+#define SLOT_STATE_DISABLED 0
+#define SLOT_STATE_ENABLED SLOT_STATE_DISABLED
+#define SLOT_STATE_DEFAULT 1
+#define SLOT_STATE_ADDRESSED 2
+#define SLOT_STATE_CONFIGURED 3
/**
* struct xhci_ep_ctx
--
1.7.4.1
Xhci controllers respond to this by returning an error. Instead of
issuing a command that will fail, just return.
This fixes the xhci driver not working on asrock P67 Pro/Extreme boards.
Signed-off-by: Maarten Lankhorst <[email protected]>
---
drivers/usb/host/xhci.c | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index d9660eb..a1f32186 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -2467,6 +2467,7 @@ int xhci_discover_or_reset_device(struct usb_hcd *hcd, struct usb_device *udev)
struct xhci_command *reset_device_cmd;
int timeleft;
int last_freed_endpoint;
+ struct xhci_slot_ctx *slot_ctx;
ret = xhci_check_args(hcd, udev, NULL, 0, false, __func__);
if (ret <= 0)
@@ -2499,6 +2500,12 @@ int xhci_discover_or_reset_device(struct usb_hcd *hcd, struct usb_device *udev)
return -EINVAL;
}
+ /* If device is not setup, there is no point in resetting it */
+ slot_ctx = xhci_get_slot_ctx(xhci, virt_dev->out_ctx);
+ if (GET_SLOT_STATE(le32_to_cpu(slot_ctx->dev_state)) ==
+ SLOT_STATE_DISABLED)
+ return 0;
+
xhci_dbg(xhci, "Resetting device with slot ID %u\n", slot_id);
/* Allocate the command structure that holds the struct completion.
* Assume we're in process context, since the normal device reset
--
1.7.4.1
On Wed, Jun 01, 2011 at 11:27:49PM +0200, Maarten Lankhorst wrote:
> Signed-off-by: Maarten Lankhorst <[email protected]>
> ---
> drivers/usb/host/xhci-dbg.c | 8 ++++----
> drivers/usb/host/xhci.h | 5 +++++
> 2 files changed, 9 insertions(+), 4 deletions(-)
<formletter>
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read Documentation/stable_kernel_rules.txt
for how to do this properly.
</formletter>
On Wed, Jun 01, 2011 at 11:27:50PM +0200, Maarten Lankhorst wrote:
> Xhci controllers respond to this by returning an error. Instead of
> issuing a command that will fail, just return.
>
> This fixes the xhci driver not working on asrock P67 Pro/Extreme boards.
>
> Signed-off-by: Maarten Lankhorst <[email protected]>
> ---
> drivers/usb/host/xhci.c | 7 +++++++
> 1 files changed, 7 insertions(+), 0 deletions(-)
<formletter>
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read Documentation/stable_kernel_rules.txt
for how to do this properly.
</formletter>
Maarten, if you feel a patch needs to be added to the stable trees,
please just add this line below your Signed-off-by line:
Cc: [email protected]
Don't Cc stable in your initial RFC patches. Once they're done, I'll
queue them to my xHCI tree and send them off to Greg. When Greg sends
them off to Linus for inclusion into 3.0, the patches will automatically
get picked up into the stable tree.
Sarah Sharp
On Thu, Jun 02, 2011 at 07:17:22AM +0900, Greg KH wrote:
> On Wed, Jun 01, 2011 at 11:27:50PM +0200, Maarten Lankhorst wrote:
> > Xhci controllers respond to this by returning an error. Instead of
> > issuing a command that will fail, just return.
> >
> > This fixes the xhci driver not working on asrock P67 Pro/Extreme boards.
> >
> > Signed-off-by: Maarten Lankhorst <[email protected]>
> > ---
> > drivers/usb/host/xhci.c | 7 +++++++
> > 1 files changed, 7 insertions(+), 0 deletions(-)
>
>
> <formletter>
>
> This is not the correct way to submit patches for inclusion in the
> stable kernel tree. Please read Documentation/stable_kernel_rules.txt
> for how to do this properly.
>
> </formletter>
Hi Sarah,
Op 02-06-11 00:42, Sarah Sharp schreef:
> Maarten, if you feel a patch needs to be added to the stable trees,
> please just add this line below your Signed-off-by line:
>
> Cc: [email protected]
>
> Don't Cc stable in your initial RFC patches. Once they're done, I'll
> queue them to my xHCI tree and send them off to Greg. When Greg sends
> them off to Linus for inclusion into 3.0, the patches will automatically
> get picked up into the stable tree.
Sorry about that. I interpreted cc'ing stable wrongly, feel like such a
noob on this whole submitting patches thing. :)
I do think it needs inclusion in stable though, since it fixes the
xhci controller that so far never worked for me, although the earliest
kernel I tested on was v2.6.33.$x-rt$y. Didn't test the patch though,
but iirc the failure mode wasn't any different.
~Maarten
On Thu, Jun 02, 2011 at 01:02:06AM +0200, Maarten Lankhorst wrote:
> Hi Sarah,
>
> Op 02-06-11 00:42, Sarah Sharp schreef:
> > Maarten, if you feel a patch needs to be added to the stable trees,
> > please just add this line below your Signed-off-by line:
> >
> > Cc: [email protected]
> >
> > Don't Cc stable in your initial RFC patches. Once they're done, I'll
> > queue them to my xHCI tree and send them off to Greg. When Greg sends
> > them off to Linus for inclusion into 3.0, the patches will automatically
> > get picked up into the stable tree.
> Sorry about that. I interpreted cc'ing stable wrongly, feel like such a
> noob on this whole submitting patches thing. :)
No worries! Everyone has to start somewhere.
> I do think it needs inclusion in stable though, since it fixes the
> xhci controller that so far never worked for me, although the earliest
> kernel I tested on was v2.6.33.$x-rt$y. Didn't test the patch though,
> but iirc the failure mode wasn't any different.
Ok, but do these two patches fix the problem you're seeing on the Etron
xHCI host controller on 2.6.39 or 3.0?
Sarah Sharp
Hi Sarah,
Op 02-06-11 01:32, Sarah Sharp schreef:
>> I do think it needs inclusion in stable though, since it fixes the
>> xhci controller that so far never worked for me, although the earliest
>> kernel I tested on was v2.6.33.$x-rt$y. Didn't test the patch though,
>> but iirc the failure mode wasn't any different.
> Ok, but do these two patches fix the problem you're seeing on the Etron
> xHCI host controller on 2.6.39 or 3.0?
>
> Sarah Sharp
Yeah, I tested on linus' rc tree and 2.6.39, no longer have 33-rtX, but I suppose I can test there too. There seem to be a few regressions though that adds a few kernel oopses I'm hitting in sound in 3.0rc1, which I haven't isolated yet, but the xhci controller itself works. Also on works on 2.6.39.
~Maarten