USB problems

[John Birrell]

On Tue, Dec 28, 2004 at 04:22:13PM +0100, Bernd Walter wrote:
> Why is the quirk required?
> OK - you get a stall on control endpoint, but this shouldn't harm
> anything, as stalls on control enpoints are automatically cleared on
> the next setup phase and the Philips controllers do that on their own.
> If you get in trouble then the firmware on the device does more wrong
> than just stalling the endpoint.

The quirk gets around the problem that FreeBSD turns the stall status
of the control endpoint into an error which aborts any further processing.

The string descriptors are returned normally by the device, except for the
fact that it sets the stall bit on the control endpoint.

(If the handling of the stall status is changed, the quirk wouldn't be
necessary)

> IIRC some USB2.0 firmware stall the control enpoint after transfering
> legal data if they have been asked in an USB1.1 format.
> I think we had this a while back for high speed hubs.

The firmware in this device doesn't test the format. It unconditionally
stalls the control endpoint in many cases (like getting a device or
configuration descriptor and requesting less bytes than the full
descriptor; getting a string descriptor; getting configuration; getting
status).

> Maybe there are broken comments left, but a stalled control endpoint
> doesn't require any special handling other than taken this a an error.

In usbd_do_request_flags_pipe() there is code that detects a stalled
control endpoint and then tries to clear the stall. In the case of the
devices I have, this code just fails because it gets a stall error too.

The FreeBSD code *never* takes into account that the control endpoint
stall will be cleared with the next setup packet.

I think that a control endpoint transfer should not return USBD_STALLED
to the caller unless the length received is less than that requested
and ~SHORT_TRANSER_OK. A stall on the control endpoint should only be an
error if the controller has a problem with the protocol (i.e. it is
a protocol stall, not a device stall);

-- 
John Birrell