2011/8/17 Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>: > On Wed, 17 Aug 2011, Barry Song wrote: > >> From: Peiyu Li <peiyu.li@xxxxxxx> >> >> Now the mass storage driver has fixed logic block size of 512 bytes. >> >> The mass storage gadget read/write bound devices only through VFS, so the bottom level >> devices actually are just RAW devices to the driver and connected PC. As a RAW, hosts >> can always format, read and write it right in 512 bytes logic block and don't care about >> the actual logic block size of devices bound to the gadget. >> >> But if we want to share the bound block device partition between target board and PC, >> in case the logic block size of the bound block device is 4KB, we execute the following >> steps: >> 1. connect a board with mass storage gadget to PC(the board has set one partition of >> on-board block device as file name of the mass storage) >> 2. PC format the mass storage to VFAT by default logic block size and read/write it >> 3. disconnect boards from PC >> 4. target board mount the partition as VFAT >> Step 4 will fail since kernel on target thinks the logic block size of the bound partition >> as 4KB. >> A typical error is >> "FAT: logical sector size too small for device (logical sector size = 512)" >> >> If we execute opposite steps: >> 1. format the partition to VFAT on target board and read/write this partition >> 2. connect the board to Windows PC as usb mass storage gadget, windows will think the disk >> is not formatted >> >> So the conclusion is that only as a gadget, the mass storage driver has no any problem. >> But being shared VFAT or other filesystem on PC and target board, it will fail. >> >> This patch adapts logic block size to bound block devices and fix the issue. >> >> Cc: Michal Nazarewicz <mina86@xxxxxxxxxx> >> Cc: Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> >> Signed-off-by: Peiyu Li <peiyu.li@xxxxxxx> >> Signed-off-by: Xianglong Du <xianglong.du@xxxxxxx> >> Signed-off-by: Huayi Li <huayi.li@xxxxxxx> >> Signed-off-by: Barry Song <Baohua.Song@xxxxxxx> >> --- >> -v2: >> 1. While backing file is not block device, use fixed logic block size 512 >> 2. for cdrom, use fixed logic block size 2048 >> 3. change file_storage as well > > 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. Is the SuperSpeed using USB 2.0? 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? anyway, since the issue has existed for some time and dropped into a different area with this, it could be a seperate patch. > > Alan Stern > Thanks Barry -- 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
