Sorry for missing CC On Sun, Jun 23, 2013 at 9:42 AM, Ming Lei <tom.leiming@xxxxxxxxx> wrote: > On Sun, Jun 23, 2013 at 2:58 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: >> 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 > > From the Thomas's last reply in the discussion, looks the device's maxp > need to be set as one value which is divided evenly into 4k, so looks the > check might be OK for wireless USB too. > >> >> 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? Thomas, there is one question about sg support on wireless USB: - if one middle sg(not last one in the sg list) which size can't be divided by endpoint's max packet size, can the wireless HCD handle it correctly or support it? >From USB 1.1/2.0/3.0 spec, the short packet should be the last packet in one transfer, could you help to clarify the wireless USB HCD behaviour in the case? Because other HCDs can't support it correctly, we plan to add check on the case in usb_submit_urb() to avoid passing this kind of sg list to HCD since Denis reported that test 7 of usbtest may do that and cause SIGBUS (in fact it may cause memory corruption). Thanks, -- Ming Lei -- 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
