Hi, Chris, I think there are two reasons why doing FFU in kernel-space makes more sense. First, some eMMC (according to extCSD[492] FFU_FEATURES) will need to restart eMMC after FFU. Second, if host want to vouch "atmoic" in FFU process, we need to call mmc_claim_host API, and this API is the kernel-space code. I said "if" is because eMMC vendors may take care this. So, host may not need to worry about this. Thanks, Hsinhsiang 2014-07-01 8:34 GMT+08:00 Chris Ball <chris@xxxxxxxxxx>: > Hi Grant, sorry about the delay. > > On Tue, Jul 01 2014, Grant Grundler wrote: >> ping? Another week is past. >> >> I know you guys are busy with other stuff. But please at least publish >> what you think the next steps for this patch are. >> >> This is a critical patch for supporting eMMC products and adding >> additional support for other vendors. I'd like to continue working >> with "upstream" and the lack of response in this case is making this >> unnecessarily difficult. > > It's tough to merge a significant patch that you haven't tested and we > haven't tested. We could do it, though -- I'd like to hear what Ulf > thinks. Please could you give a quick explanation of why doing this > in kernel-space makes more sense than using your mmc-utils version? > > Thanks, > > - Chris. > -- > Chris Ball <http://printf.net/> > -- > To unsubscribe from this list: send the line "unsubscribe linux-mmc" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
