Skip to content

Error reporting of control read requests is not quite per spec #341

@xross

Description

@xross

For a bad Control Write Request (say an unrecognised SetSampleFreq) where the expected transaction sequence from host is as follows:

SETUP
OUT (Data stage)
IN (Status stage)

we currently would mark the control EP as halted after the SETUP, therefore responding to the OUT will a STALL (i.e the data stage)

The spec essentially defines two errors:

  • Device cannot fulfil the request - STALL the Status stage
  • Too much data is sent of requested from the device - STALL the Data stage

The spec is a little ambiguous in that in table 8-7 it states the the STALL is sent in the data phase when the function has an error. This seems to contradict the text.

My interpretation of the text is that in this case the device should accept the data stage but STALL the status stage.

Note, if we wish to stall reliably on too much data sent/requested we will probably need need to encapsulate the GetSetupBuffer() function further - GetControlData() for example. This would perform the checking and stall as appropriate.

Note, table 8-7 for "Control Read transfers" also reads "sent during the handshake phase". I assume this should be "sent during the status phase"

Ultimately this issue is probably low impact, a STALL is still issued from the device, just possibly at the wrong time. The end result is likely the same, that is the host moves to the next control request.

Metadata

Metadata

Assignees

Labels

bugSomething isn't working

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions