On Sun, 29 Sep 2002, Matthew Dharm wrote:
> It appears that we have a problem clearing halts. This patch causes a very
> clear message to be printed whenever a usb_stor_clear_halt() manages to
> work. So far, I haven't seen such a thing happen. And I've seen _lots_ of
> STALL conditions.
...
> 'result' in this function always seems to be -32. Which is odd, because
> control endpoints shouldn't do that.
>
> I'm open to suggestions as to where to look for this bug, but my instincts
> are telling me that this is a core or HCD issue, not a usb-storage issue.
Actually, it is possible to receive EPIPE for a control endpoint. But it
shouldn't happen very often. In fact, with normal use we shouldn't see it
at all. Protocol stalls occur only with commands that the device can't
understand or carry out (we don't send any commands like that) and are
cleared right away. Functional stalls are explicitly discouraged and can
only occur if we set a control endpoint's Halt feature (which we don't) or
as a vendor-specific feature.
In short, my guess would also be that EPIPE errors on control endpoints
are the result of an HCD problem.
Alan Stern
P.S.: For all interested parties, here are the relevant sections from the
USB-2.0 document:
From section 8.4.5:
The STALL handshake is used by a device in one of two distinct occasions.
The first case, known as functional stall, is when the Halt feature
associated with the endpoint is set. (The Halt feature is specified in
Chapter 9 of this document.) A special case of the functional stall is the
commanded stall. Commanded stall occurs when the host explicitly sets the
endpoint's Halt feature, as detailed in Chapter 9. Once a function's
endpoint is halted, the function must continue returning STALL until the
condition causing the halt has been cleared through host intervention.
The second case, known as protocol stall, is detailed in Section 8.5.3.
Protocol stall is unique to control pipes. Protocol stall differs from
functional stall in meaning and duration. A protocol STALL is returned
during the Data or Status stage of a control transfer, and the STALL
condition terminates at the beginning of the next control transfer
(Setup).
From section 8.5.3.4:
Control pipes have the unique ability to return a STALL handshake due to
function problems in control transfers. If the device is unable to
complete a command, it returns a STALL in the Data and/or Status stages of
the control transfer. Unlike the case of a functional stall, protocol
stall does not indicate an error with the device. The protocol STALL
condition lasts until the receipt of the next SETUP transaction, and the
function will return STALL in response to any IN or OUT transaction on the
pipe until the SETUP transaction is received. In general, protocol stall
indicates that the request or its parameters are not understood by the
device and thus provides a mechanism for extending USB requests.
A control pipe may also support functional stall as well, but this is not
recommended. This is a degenerative case, because a functional stall on a
control pipe indicates that it has lost the ability to communicate with
the host. If the control pipe does support functional stall, then it must
possess a Halt feature, which can be set or cleared by the host. Chapter 9
details how to treat the special case of a Halt feature on a control pipe.
A well-designed device will associate all of its functions and Halt
features with non-control endpoints. The control pipes should be reserved
for servicing USB requests.
From section 9.4:
Receipt of an unsupported or invalid request does NOT cause the optional
Halt feature on the control pipe to be set. If for any reason, the device
becomes unable to communicate via its Default Control Pipe due to an error
condition, the device must be reset to clear the condition and restart the
Default Control Pipe.
From section 9.4.5:
It is neither required nor recommended that the Halt feature be
implemented for the Default Control Pipe. However, devices may set the
Halt feature of the Default Control Pipe in order to reflect a functional
error condition. If the feature is set to one, the device will return
STALL in the Data and Status stages of each standard request to the pipe
except GetStatus(), SetFeature(), and ClearFeature() requests. The device
need not return STALL for class-specific and vendor-specific requests.
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
