Dear Wolfgang Denk,
Dear Lukasz Majewski,
In message 1341416922-13792-4-git-send-email-l.majewski@samsung.com you wrote:
New, separate driver at ./drivers/dfu has been added. It allows platform and storage independent operation of DFU.
Sorry for a probably stupid question, but I know basicly zero about DFU. We are talking about "storage independent" here. Does this also mean file system independent?
Some clarification is needed. I've divided DFU support (PATCH v2) to three separate parts: 1. DFU transmission handling (via USB) with ./drivers/usb/gadget/g_dnl.c|f_dfu.c
2. Generic DFU functions ./drivers/dfu/dfu.c - which try to abstract DFU operation to be platform independent. Generic dfu_{write|read} functions have been defined and are accessible from USB code. On the other hand dfu_{write|read} calls function pointers dfu->{read|write}_medium(), which points to medium specific functions.
3. Code for MMC write/read - dfu_mmc.c. It is possible to read/write raw data to MMC (with passing LBA address) or to file systems (like FAT). For now MMC is only supported. It uses (in my opinion) "generic" sprintf+run_command() calls, which can be easily extended. To support OneNAND one needs to define dfu_onenand.c file with OneNAND specific functions.
Considering above, there are already defined "generic" access functions - dfu_{write|read}.
+static char *dfu_get_dev_type(enum dfu_device_type t) +{
- static char *dev_t[] = {NULL, "MMC", "ONENAND", "NAND" };
- return dev_t[t];
+}
So this currently supports MMC, OneNAND and NAND as storage devices?
It currently only supports MMC devices. Others (ONENAND/NAND) have been added as place holders for future usage.
+static char *dfu_get_layout(enum dfu_device_type l) +{
- static char *dfu_layout[] = {NULL, "RAW_ADDR", "FAT",
"EXT" };
- return dfu_layout[l];
+}
And FAT (or VFAT?) and EXT (as in EXT2? or EXT3? or ... ?) as file systems?
+enum dfu_device_type {
- MMC = 1,
- ONENAND,
- NAND
+};
+enum dfu_layout {
- RAW_ADDR = 1,
- FAT,
- EXT,
+};
MMC, NAND, FAT and EXT are very generic names that heavily pollute on the global name space. Please chose more specific names, probaly also indicating the meaning (EXT could be some "extension" or "external" or whatever - the name does not indicate that this is a file system type here.
Ok, no problem with this.
Best regards,
Wolfgang Denk