Message-ID: <4DE5283A.9070202@gmail.com>
Date:	Tue, 31 May 2011 19:41:14 +0200
From:	Maarten Lankhorst <m.b.lankhorst@...il.com>
To:	Sarah Sharp <sarah.a.sharp@...ux.intel.com>
CC:	"Xu, Andiry" <Andiry.Xu@....com>, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] [RFC] usb: Do not attempt to reset the device while it
 is disabled

Hi Sarah,

Op 31-05-11 19:14, Sarah Sharp schreef:
> On Tue, May 31, 2011 at 03:47:18PM +0200, Maarten Lankhorst wrote:
>> Hey Andiry,
>>
>> Op 31-05-11 02:34, Xu, Andiry schreef:
>>>> -----Original Message-----
>>>> From:linux-usb-owner@...r.kernel.org  [mailto:linux-usb-
>>>> owner@...r.kernel.org] On Behalf Of Maarten Lankhorst
>>>> Sent: Monday, May 30, 2011 5:57 PM
>>>> To:linux-usb@...r.kernel.org
>>>> Cc: Sarah Sharp;linux-kernel@...r.kernel.org; Maarten Lankhorst
>>>> Subject: [PATCH] [RFC] usb: Broaden range of vendor codes for xhci
>>>>
>>>> My asrock P67 chipset sends code 192 on device reset. Allowing>= 192
>>>> to be treated as success fixes it, and allows me to use my USB3 port.
>>>>
>>> TRB completion code 192-223 is defined as Vendor defined error. Your
>>> host
>>> controller returns a error - don't know what causes the error since it's
>>> vendor defined.
>> Ahh, making it the same as COMP_EBADSLT/COMP_CTX_STATE I get this:
>> [72677.470421] xhci_hcd 0000:04:00.0: Can't reset device (slot ID 1)
>> in enabled/disabled state
> Yes, because that's what those error codes mean.  But your host
> controller did not return that error code, it returned a vendor-specific
> error code.
>
>> Should reset_device even be called when in that state? The comments
>> above claim:
>> /* The Reset Device command can't fail, according to the 0.95/0.96 spec,
>>  * unless we tried to reset a slot ID that wasn't enabled,
>>  * or the device wasn't in the addressed or configured state.
>>  */
> The code shouldn't happen, but we cover the error condition in case
> there is a future bug in the USB core, or a buggy host controller.  But
> that's really beside the point.  Your host returned a different error
> code, and there's no telling what that means without vendor specific
> documentation.  Can you send me the lspci for the host?
>
>> Ignoring the error seems to make it work fine. It seems to me that
>> device reset shouldn't even be attempted since it hasn't been
>> brought up yet. The reset that fails is the one that happens on the
>> original hub_port_init when it calls hub_port_reset which calls
>> xhci_discover_or_reset_device. The failure I'm getting seems to be a
>> vendor specific variant of "you're trying to reset the device while
>> it wasn't enabled".
> Yes, the USB core resets a device during the standard enumeration
> process.  The host controller is supposed to be able to handle that
> case.  Why it returns a vendor specific error is something that company
> needs to answer.
>
> Can you send me the full dmesg with CONFIG_USB_XHCI_HCD_DEBUGGING turned
> on?  I'd like to see the full debug log for this and see if the host or
> driver is falling over in an earlier spot.
I'm on linux 2.6.39, relevant dmesg spits out this:

xhci_hcd 0000:04:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
xhci_hcd 0000:04:00.0: setting latency timer to 64
xhci_hcd 0000:04:00.0: xHCI Host Controller
xhci_hcd 0000:04:00.0: new USB bus registered, assigned bus number 3
xhci_hcd 0000:04:00.0: irq 17, io mem 0xfa100000
xhci_hcd 0000:04:00.0: Failed to enable MSI-X
xhci_hcd 0000:04:00.0: irq 47 for MSI/MSI-X
xHCI xhci_add_endpoint called for root hub
xHCI xhci_check_bandwidth called for root hub
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
xhci_hcd 0000:04:00.0: xHCI Host Controller
xhci_hcd 0000:04:00.0: new USB bus registered, assigned bus number 4
xHCI xhci_add_endpoint called for root hub
xHCI xhci_check_bandwidth called for root hub
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
xhci_hcd 0000:04:00.0: Unknown completion code 192 for reset device command.
usb 3-1: Cannot reset HCD device state
xhci_hcd 0000:04:00.0: Unknown completion code 192 for reset device command.
usb 3-1: Cannot reset HCD device state
xhci_hcd 0000:04:00.0: Unknown completion code 192 for reset device command.
usb 3-1: Cannot reset HCD device state
xhci_hcd 0000:04:00.0: Unknown completion code 192 for reset device command.
usb 3-1: Cannot reset HCD device state
xhci_hcd 0000:04:00.0: Unknown completion code 192 for reset device command.
usb 3-1: Cannot reset HCD device state
hub 3-0:1.0: Cannot enable port 1.  Maybe the USB cable is bad?
>> Signed-off-by: Maarten Lankhorst<m.b.lankhorst@...il.com>
>>
>> ---
>> index 81b976e..9a869b2 100644
>> --- a/drivers/usb/host/xhci.c
>> +++ b/drivers/usb/host/xhci.c
>> @@ -2307,6 +2307,10 @@ int xhci_discover_or_reset_device(struct usb_hcd *hcd, struct usb_device *udev)
>>  			return -EINVAL;
>>  	}
>>
>> +	if (GET_SLOT_STATE(xhci_get_slot_ctx(xhci, virt_dev->out_ctx)->dev_state) == 0&&
>> +	    (xhci_get_ep_ctx(xhci, virt_dev->out_ctx, 0)->ep_info&  EP_STATE_MASK) == EP_STATE_DISABLED)
>> +		return 0;
>> +
> Why are you looking at the endpoint state?  The control endpoint state
> has nothing to do with the outcome of the Reset Device command.  The
> host controller is only allowed to reject the command if the device slot
> is not in the addressed or configured state (according to the 0.96 spec,
> I assume this host isn't a 1.0 host).  So the control endpoint state
> should have nothing to do with whether the command succeeds.
>
> I'm also confused as to why this code works.  The control endpoint is
> never disabled until the USB core deallocates a device.  Once the xHCI
> driver allocates a slot and issues an Address Device command, the
> control endpoint's output context should move from the disabled state to
> the running state.  But if this conditional actually ran, then either
> the host controller didn't update the output context for the control
> endpoint, the Address Device command failed, or something very strange
> is going on.
>
> Full dmesg with the xHCI driver debug will help me figure this out.
> What kernel are you running?
I think it happens because hub_port_reset is called in hub_port_init since
commit 07194ab7be63a972096309ab0ea747df455c6a20, so I'd say that is
what causes the reset to be called in this state?

~Maarten
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists