Hi, Thinh Nguyen <Thinh.Nguyen@xxxxxxxxxxxx> writes: >> Thinh Nguyen <Thinh.Nguyen@xxxxxxxxxxxx> writes: >>> If a request is dequeued, the transfer is cancelled. Give back all >>> the started requests. >>> >>> In most scenarios, the function driver dequeues all requests of a >>> transfer when there's a failure. If the function driver follows this, >>> then it's fine. If not, then we'd be skipping TRBs at different points >>> within the dequeue and enqueue pointers, making dequeue/enqueue pointers >>> useless. To enforce and make sure that we're properly skipping TRBs, >>> cancel all the started requests and give back all the cancelled requests >>> to the function drivers. >> Which function driver is *not* cancelling transfers correctly? We can >> (and should) be defensive on dwc3, but let's not hide bugs on function >> drivers either. >> > > I didn't review all the function drivers for this. I just see a > potential issue and go for a more defensive approach. What's your > suggestion? Fair enough, that's good for my understading of why the patch was created. Is there a way to add a WARN() or something like that so we catch erroneous gadget drivers easily? Also, could you check if we need a documentation update for the gadget API with regards to this finding? cheers -- balbi
Attachment:
signature.asc
Description: PGP signature
