* Peter Korsgaard | 2011-07-26 13:53:43 [+0200]: >>>>>> "Felipe" == Felipe Balbi <balbi@xxxxxx> writes: > >Hi, > > >> Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@xxxxxxxxxxx> > >> Signed-off-by: Kyungmin Park <kyungmin.park@xxxxxxxxxxx> > > Felipe> I'm not sure this should be in kernel. Have you tried gadgetfs ? > >functionfs would be better, so it fits the composite framework. We do >have g_file_storage in the kernel, why not dfu? you can have it in /tools/usb/gadget/dfu. I support this. After a first review a few hints why in-kernel is not a good idea: - this is very media specific. You transfer a bootloader which goes straight into /dev/mmc0p1 or so. What about NAND/NOR which have a different semantic? A userland tool which does the flash_erase and so. - you hold the data in kernel with no real business. You could instead have 2 threads in userland: one reads data the other write the data to the specific location. - You need a userland tool anyway to setup the proper locations i.e. echo bla > entity. What about ./dfu -c file.cfg where cat file.cfg [alt_0] name = bootloader file =/dev/mmcblk0 ro = true [alt_1] name = kernel file =/dev/nand0 write_tool = ubifromat write_args = -y So you have one tool which does the administration and you write either straigt to the desired partition in case of mmc or nand with ubi helpers or nand_write what so ever. I really would appreciate a userland approach. Is it possible to extend the protocol a little? For instance add ep2/3 so you could use it to transfer more than 64bytes in one go on HS? Also if you send fat partitions for MMC it would make sense to pipe the data through LZO. LZO is _very_ fast on decompression so you would safe the amount of data that is transfer trough the wire and this should save time. Sebastian -- 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
