On Sat, 22 Jun 2013, Ming Lei wrote: > > Nonsense. Transfers do not have short packets in the middle, only at > > the end. If the driver wants to have 1512 bytes in a single transfer > > then there must be 23 packets of length 64 followed one packet of > > length 40. > > > > If the driver wants to send 15 packets of length 64 followed by one > > packet of length 40 and 8 more packets of length 64, then it must use > > two transfers. > > > >> Denis's patch still can't do what you hope(short packet is at the end of the > >> transfer), can it? > > > > What I hope is that we can prevent SIGBUS or other memory access > > errors. The patch will do that. > > If we only want to prevent this errors, there should be better approach, IMO. > > Since you mentioned it doesn't make sense to generate short packet > in the middle of transfer, also it may not be what the driver/device expected, > I suggest to add a check in usb_submit_urb() for this case and returns > failure on it simply, because all HCDs shouldn't support this sort of thing. > The check in usb_submit_urb() can avoid unnecessary change in HCD. > > Any comments on the idea? Wireless USB has some strange features, one of which is that the maxpacket sizes for endpoints can be changed. I'm afraid that adding this check in usb_submit_urb() would not work right for wireless USB. See http://marc.info/?l=linux-usb&m=136934531624850&w=2 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. 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
