On Fri, Jun 03, 2011 at 04:04:15PM +0800, Alex He wrote:
> It is one new TRB Completion Code for the xHCI spec v1.0.
> Asserted if the xHC detects a problem with a device that does not allow it to
> be successfully accessed, e.g. due to a device compliance or compatibility
> problem. This error may be returned by any command or transfer, and is fatal
> as far as the Slot is concerned. Return -EPROTO by urb->status or frame->status
> of ISOC for transfer case or skip the associate command completion event to let
> the USB core to decide how to do.
>
> Signed-off-by: Alex He <alex.he@xxxxxxx>
> ---
> drivers/usb/host/xhci-ring.c | 12 ++++++++++++
> drivers/usb/host/xhci.h | 2 ++
> 2 files changed, 14 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
> index b045750..18e6530 100644
> --- a/drivers/usb/host/xhci-ring.c
> +++ b/drivers/usb/host/xhci-ring.c
> @@ -1081,6 +1081,13 @@ static void handle_cmd_completion(struct xhci_hcd *xhci,
> xhci->error_bitmask |= 1 << 5;
> return;
> }
> +
> + if (GET_COMP_CODE(event->status) == COMP_DEV_ERR) {
> + xhci_warn(xhci, "WARN: detect an incompatilbe device\n");
> + inc_deq(xhci, xhci->cmd_ring, false);
> + return;
> + }
> +
Alex, I don't think you should return here before you get to the switch
statement. What if this error code is returned for a command like
Configure Endpoint? The command submission function is waiting on the
completion of the command in the command wait list, so you really need
to let the code get to the switch statement and complete that.
Otherwise the command will timeout, and return -ETIME to the USB core.
That's not ideal. I think the better solution would be to complete
those commands in handle_cmd_completion(), and return -ENODEV when the
COMP_DEV_ERR is found.
You'll have to add some handling for COMP_DEV_ERR in
xhci_configure_endpoint_result(), xhci_evaluate_context_result(), and
xhci_address_device(). That's where you should return -ENODEV, to let
the USB core know the host controller can't handle the device.
I'm not sure if you should add handling for that code to
xhci_discover_or_reset_device(). The spec says that the host controller
can return this code for any command, but I really don't see why it
would need to return this code for commands like Reset Device, Reset
Endpoint, Stop Endpoint Ring, and Set TR Dequeue Pointer. The host
controller has already accepted the device at that point, so why should
it need to return an Incompatible Device error? Unless you know of
specific host controllers that will return those error conditions for
those commands, I don't think we need to handle this error code for
those commands.
Sarah Sharp
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
