On Mon, 24 Jun 2013, Konstantin Filatov wrote: > On 06/23/2013 07:05 PM, Alan Stern wrote: > >>> That's why, if the check is checked, I feel it should be added to each > >>> HCD driver separately. Maybe I'm wrong. But before doing anything, > >>> you should check with Thomas Pugliese. He recently added SG support to > >>> the wireless USB driver. > >> Suppose wireless USB is one exception, it should the only one, so we can > >> rule it out easily by using hcd->wireless, right? > > Yes, that's true. > > > > Alan Stern > > > This test passed for many years. It became to fail only for the recent > kernels. So this event looks like a broken thing. Looks can be deceiving. Even though the test used to pass, it wasn't doing what it was supposed to do. Also, if you tried test 8 (read) instead of test 7 (write), using the same test parameters, you would have found that it has _never_ worked. Not even on EHCI. The error is in the parameters, not just in the new kernel code. > It's not a good idea to force a higher driver to care about the max pkt > size in a dynamically selected usb configuration. Note that a sg-list > could be created even in another subsystem. (In fact, SG lists are usually created in other subsystems.) There have always been cases where this sort of thing is done. Consider for example the restrictions on the address value when using MMAP_FIXED in the mmap(2) system call. The fact is, most USB host controller hardware is not capable of sending or receiving a packet if the data buffer isn't contiguous in memory (or at best, "virtually contiguous", meaning that any discontinuities must occur exactly on page boundaries). > If we decided to treat such sg-lists as acceptable, then we have only > two options: > 1. Send a shorter packet between two full packets of a TD list. > 2. Introduce a bounce buffer similarly in lib/swiotlb.c > Option 2 is very costed. If the option 1 is acceptable, then we should > choose it. > > But ehci does resolve this issue in such way already, so the option 1 is > acceptable. The other choice is not to regard such SG lists as acceptable. In the end, that's a safer approach. The client will be notified at once that something went wrong, instead of thinking that the transfer succeeded when the data was not sent as intended. > From my point of view this choice is unrelated to the wireless USB > requirements. The choice is not related to wireless USB, but the best way to implement it is. Alan Stern -- 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
