On Thu, 18 Aug 2011, Barry Song wrote: > > There's still one problem. The existing code assumes the block size is > > divisible by the bulk maxpacket size. If the block size were 256 or > > smaller, this would no longer be true. > > > > (In fact, we already have this problem now when people try to use > > g_file_storage or g_mass_storage running at SuperSpeed, because then > > the maxpacket size is 1024.) > > > > The only way to fix this is to remove the code that aligns the file > > transfers with the page size of the page cache. Would you like to > > write a preliminary patch to do that? > > we have no a block device whose logic block size is 256, and no a > SuperSpeed with 1024 maxpacket size. i am afraid that is difficult for > us to test. > but if i get some free time, i'd like to give a hand anyway. Never mind, I'll try writing a patch myself. > Is the SuperSpeed using USB 2.0? No; SuperSpeed is USB-3 only. > as the USB 2.0 spec, > "Bulk transfers are only supported by full and high speed devices. For > full speed endpoints, the maximum bulk packet size is either 8, 16, 32 > or 64 bytes long. > For high speed endpoints, the maximum packet size can be up to 512 bytes long. " > why do they have a 1024 max bulk packet size? All SuperSpeed bulk endpoints must have a maxpacket size of 1024. > anyway, since the issue has existed for some time and dropped into a > different area with this, it could be a seperate patch. Agreed, it should be separate. 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
