Hi, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> writes: > On Wed, 4 May 2016, Felipe Balbi wrote: > >> > multiple of 512 bytes and the maxpacket size is 1024. Then you either >> >> that's not common case for testusb. One of the test cases (see below) >> exercises exactly small sg entries: >> >> # try to trigger short OUT processing bugs >> echo "test 7a: $COUNT scatterlists, variable size/short entries" >> do_test -t 7 -v 579 >> BUFLEN=4096 >> echo "test 7b: $COUNT scatterlists, variable size/bigger entries" >> do_test -t 7 -v 41 >> BUFLEN=64 >> echo "test 7c: $COUNT scatterlists, variable size/micro entries" >> do_test -t 7 -v 63 > > These tests will fail if you run them on an EHCI host controller. > >> (above is from tools/usb/hcd-tests.sh) >> >> > have to split the last entry in two or move it completely into the next >> > ring segment. >> >> right, this is easy enough to do and that we (well, Mathias) already >> have working :-) >> >> > This approach doesn't work quite as well if the scatterlist entries are >> > very small. For instance, if they are 8 bytes or smaller then you >> > might have to fill out the segment with 128 or more no-op TRBs, which >> > is not so good if the segment can hold only 256 TRBs. I suppose we >> > could simply rule this out by requiring SG transfers to have a minimum >> > entry size of 128 bytes, or something like that. >> >> that's not a good idea, IMO. HCD drivers should be robust enough in >> these situations. > > Why? Just so that hcd-tests.sh can complete with no errors? I don't and some off-the-shelf usb-network adapters can work ;-) > know of any actual drivers or user programs that do real work and need > such small SG entry sizes. Well, apparently some ASIX network adapters fail similarly, but perhaps they provide sg entries big enough to be split without any memcpy() ? Dunno. >> >> /me goes dig EHCI >> > >> > Not sure that will help. The same issue could arise there, if the >> > scatterlist entries were smaller than 512 bytes. The driver doesn't >> > handle this case properly, but it works out okay because the case never >> > comes up. >> >> see testusb :-) You did mention, on another thread, that you ran >> testusb. > > Your counterexample isn't really testusb; it's hcd-tests.sh. I haven't > tried running that. That just calls testusb and is the same test.sh from many, many years ago which Dave wrote. At [1] you can find Dave's usbtest page on linux-usb.org and at [2] you can find a direct link to test.sh. >> And, btw, years ago I used to run these tests on daily basis on >> MUSB. It also seems that Synopsys' XHCI (part of dwc3 when configured as >> dual-role) is immune to this link TRB alignment limitation because I was >> running hcd-tests.sh also on a daily basis on TI's AM437x SK and IDK >> boards (one as host, one as peripheral). > > If creating bounce buffers for small SG transfers is so common (i.e., > necessary for more than one host controller driver) then it really > belongs in a common library somewhere. no arguments there ;-) [1] http://www.linux-usb.org/usbtest/ [2] http://www.linux-usb.org/usbtest/test.sh -- balbi
Attachment:
signature.asc
Description: PGP signature
