>>>> IIUC, req->length should still be set to len, not to data_len. >> >> I misunderstood the first time I read it: >> In order to avoid DWC3 to stall, we need to update req->length (this is >> the most important fix). kmalloc() is updated too to prevent USB >> controller to overflow buffer boundaries. > > Here I disagree. > > If the DWC3 hardware stalls, it is up to the DWC3 UDC driver to fix it. > Gadget drivers should not have to worry. Most especially, gadget > drivers should not lie about a request length. > > If the UDC driver decides to round up req->length before sending it to > the hardware, that's okay. But req->length should be set to len, not > data_len. And if the hardware receives more than len bytes of data, > the UDC driver should set req->status to -EOVERFLOW.
Got your point. As long as buffer allocation has enough size, DWC3 is able to fix itself. I'm fine with this approach too. But in this case I will need to redo my DWC3 patch and my validation. Br, David > > Alan Stern > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
