Zitat von Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>:
On Mon, 4 Feb 2019, Guido Kiener wrote:
From: Guido Kiener <guido.kiener@xxxxxxxxxxxxxxxxx>
The OUT endpoint normally blocks (NAK) subsequent packets when a
short packet is received and returns an incomplete queue entry to
the gadget driver. Thereby the gadget driver can detect
a short packet when reading queue entries with a length that is
not equal to a multiple of packet size.
The start_queue() function enables receiving OUT packets regardless
of the content of the OUT FIFO. This results in a problem:
When receiving is enabled more OUT packets are appended to the last
short packet and the gadget driver cannot determine the end of a
short packet anymore. Furthermore the remaining data in the OUT FIFO
is not delivered to the gadget driver immediately and can produce
timeout errors.
How can that happen? When the short packet is received, the endpoint
immediately starts sending NAKs, so no more data can enter the FIFO.
Furthermore, the incomplete transfer is returned to the gadget driver,
which removes the short packet from the FIFO. So the FIFO has to be
empty when start_queue() is called.
I don't remember the exact scenario. It happens something like this:
When you have only one request (e.g. 4kB) left in your endpoint OUT
queue and a host sends 4kB + some extra bytes, then your request (4kB)
is delivered to the gadget driver while the extra bytes (short packet)
are still in the OUT FIFO.
I try to reconstruct the situation (without fix) how the driver can call
(re)start_dma. I do not see a reasonable path in the moment.
Guido
This fix only stops OUT naking when all FIFO data is delivered
to the gadget driver and the OUT FIFO is empty.
