[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.44L0.1307191008200.1055-100000@iolanthe.rowland.org>
Date: Fri, 19 Jul 2013 11:14:09 -0400 (EDT)
From: Alan Stern <stern@...land.harvard.edu>
To: Sarah Sharp <sarah.a.sharp@...ux.intel.com>
cc: Peter Hurley <peter@...leysoftware.com>,
Nestor Lopez Casado <nlopezcasad@...itech.com>,
<jkosina@...e.cz>, <benjamin.tissoires@...il.com>,
<adlr@...omium.org>, <joseph.salisbury@...onical.com>,
<linux-input@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<linux-usb@...r.kernel.org>
Subject: Re: [PATCH 1/2] Revert "Revert "HID: Fix logitech-dj: missing Unifying
device issue""
On Thu, 18 Jul 2013, Sarah Sharp wrote:
> Question: does this USB device need a control transfer to reset its
> endpoints when the endpoints are not actually halted? If so, yes, that
> is a known xHCI driver bug that needs to be fixed. The xHCI host will
> not accept a Reset Endpoint command when the endpoints are not actually
> halted, but the USB core will send the control transfer to reset the
> endpoint. That means the device and host toggles will be out of sync,
> and all messages will start to fail with -EPIPE.
Why -EPIPE? Isn't that code reserved to indicate a STALL?
In fact, there's no way to detect a toggle mismatch problem with a
USB-2 device. Packets with the wrong toggle value are simply ignored
(or acknowledged and ignored). The problem ends up appearing as an
indefinite delay (for an IN transfer) or as data lost (for an OUT
transfer).
I don't know what happens with USB-3 devices when the sequence numbers
get out of alignment.
Alan Stern
--
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