On Mon, 18 Mar 2019 guido@xxxxxxxxxxxxxxxxxx wrote: > Zitat von Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>: > > > On Mon, 18 Mar 2019, Guido Kiener wrote: > > > >> The OUT endpoint normally blocks (NAK) subsequent packets when a > >> short packet was 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 again, 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. > >> > >> This fix stops OUT naking only when OUT naking is enabled and when the > >> OUT FIFO is empty. It ensures that all received data is delivered to > >> the gadget driver which can detect a short packet now before new > >> packets overrun the last short packet. > > > > This description should explain the race which causes the problem. > > With the current code, it's possible that the "!ep->is_in && > > (readl(&ep->regs->ep_stat) & BIT(NAK_OUT_PACKETS))" test will fail, > > then a short packet will be received, and then start_queue() will call > > stop_out_naking(). That's what we don't want -- OUT naking gets turned > > off while there is data in the FIFO. With the patch, this race can't > > occur because the FIFO's state is tested after we know that OUT naking > > is already turned on. > > > > Thanks. Please feel free to change my wording/spelling. I'm not offended. > Does this description meet your request: > > The OUT endpoint normally blocks (NAK) subsequent packets when a > short packet was 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 race: > With the current code, it's possible that the "!ep->is_in && > (readl(&ep->regs->ep_stat) & BIT(NAK_OUT_PACKETS))" test will fail, > then a short packet will be received, and then start_queue() will call > stop_out_naking(). That's what we don't want -- OUT naking gets turned > off while there is data in the FIFO. With the patch, this race can't > occur because the FIFO's state is tested after we know that OUT naking > is already turned on. Here are a few more slight changes to the text. Submit the patch again with this description and it will be okay: The OUT endpoint normally blocks (NAK) subsequent packets when a short packet was 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 race: With the current code, it's possible that the "!ep->is_in && (readl(&ep->regs->ep_stat) & BIT(NAK_OUT_PACKETS))" test in start_dma() will fail, then a short packet will be received, and then start_queue() will call stop_out_naking(). That's what we don't want (OUT naking gets turned off while there is data in the FIFO) because then the next driver request might receive a mixture of old and new packets. With the patch, this race can't occur because the FIFO's state is tested after we know that OUT naking is already turned on, and OUT naking is stopped only when both of the conditions are met. This ensures that all received data is delivered to the gadget driver, which can detect a short packet now before new packets are appended to the last short packet. Alan Stern
