Hi Filipe, On 3/22/2018 1:05 PM, Felipe Balbi wrote: > Minas Harutyunyan <Minas.Harutyunyan@xxxxxxxxxxxx> writes: > >> Hi Filipe, >> >> On 3/17/2018 1:08 PM, Minas Harutyunyan wrote: >>> This series fully update existing ISOC DDMA flow which initially based on >>> 2 descriptor chains. Switching between desc chains performing based on BNA >>> interrupt. Because of BNA interrupt few packets can be lost. >>> >>> 1/3 patch unmask ISOC IN BNA interrupt only. >>> 2/3 patch changing ISOC IN/OUT flow as described above. >>> 3/3 patch add High bandwidth ISOC OUT transfers support. >>> >>> All patches were tested on HAPS-DX7 platform using internal USB test tool. >>> >>> Changes from version 0: >>> >>> Fix kbuild test robot warnings on idents. >>> >>> >>> Minas Harutyunyan (3): >>> usb: dwc2: Enable BNA interrupt for IN endpoints >>> usb: dwc2: Change ISOC DDMA flow >>> usb: dwc2: Add High Bandwidth ISOC OUT support >>> >>> drivers/usb/dwc2/core.h | 2 - >>> drivers/usb/dwc2/gadget.c | 505 ++++++++++++++++++++++++++++++++-------------- >>> 2 files changed, 359 insertions(+), 148 deletions(-) >>> >> >> I need your advise on this patch series. >> >> My question is related to requests completion codes in different cases. >> In patch series I used follow completion codes: >> 1. In case of BNA. Request completed with status code -EIO; >> 2. In case of IN-NAK and OUT-EPDis. Request completed with status code >> -NODATA; >> 3. In case of XferComplete. Request completed with status code -NODATA >> or -ETIMEDOUT depend on descriptor error status: buffer flush, uf >> number, DPID's, etc. >> Are these status codes acceptable from function driver point of view? Or >> maybe dwc2 should complete the requests for above cases with "0" status >> code and function driver should rely on actual data size, not on >> completion code? > > I can't find it now, but we had documentation on accepted status codes > from usb_request completion. EINPROGRESS is used when you just queued > the request and it hasn't completed yet, ESHUTDOWN is when a disconnect > is seen, ECONNRESET is for STALL conditions or DMA aborts, or things > like that, EOVERFLOW for cases when host sends more data than promised, > 0 is for success. These are the ones I use and remember off the top of > my head and I think they are the only ones used. > Thank you for feedback. I think to update all, used by me, status codes (-EIO, -NODATA, -ETIMEDOUT) to 0 to keep consistency with original code for other non-DDMA modes. Let's function driver rely on actual size. Actually, in this error cases dwc2 served requests for some frames and to function driver will complete by status 0, which will mean request served successfully, but actual data length can be 0. Any objections? Thanks, Minas -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
