Hi, David Laight <David.Laight@xxxxxxxxxx> writes: > From: Felipe Balbi >> David Laight <David.Laight@xxxxxxxxxx> writes: >> >> > From: Felipe Balbi >> >> >> Sent: 07 April 2017 12:37 >> >> >> Just like we did for all other endpoint types, let's rely on a chained >> >> >> TRB pointing to ep0_bounce_addr in order to align transfer size. This >> >> >> will make the code simpler. >> >> > ... >> >> > >> >> > Is the dwc3 similar enough to xhci to have an 'immediate data' bit? >> >> > If so the aligning data could come from the 8 byte 'address' field. >> >> >> >> you mean like patch 1 in this very series? >> >> >> >> https://marc.info/?i=20170407113655.27569-1-felipe.balbi@xxxxxxxxxxxxxxx >> > >> > Not exactly, that seems to be using the trb memory itself as the buffer. >> > I'm guessing that can only work for 'read' TRB. >> > >> > If you look at the xhci docs (eg table 71 in section 6.4.1.2.1 of the rev 1.0 >> > copy I have) bit 6 of the last word is 'IDT'. >> > So 8 bytes of data are put into the bpl/bph fields - not a pointer at all. >> >> Right, it works similarly for DWC3 :-) However, instead of IDT we just >> set BPH/BPL to the address of the TRB itself. > > Ah, not quite... > > You are setting BPH/BPL to point to BPH/BPL rather than the TRB. > This works for 'read' type transactions because the pointer isn't > needed after the data has been written. right, note that the address passed in _is_ the address of the TRB, but I *know* only 8 bytes will be used, thus only BPH/BPL get overwritten This is documented in DWC3 databook. > For short writes you'd need additional buffer memory somewhere. > Could be allocated after the TRB array. For that I have a single 1024 byte throw-away buffer that *all* endpoints use. I don't care about the data that goes there (there should never be *any* data there, actually), I'm just interested in guarateeing that a faulty host will never cause a buffer overflow. -- balbi
Attachment:
signature.asc
Description: PGP signature
