Hi Chris, Re your concern that the patch was not tested – some of SanDisk’s OEM customers have implemented the patch, and they report that it is working for them.
Thanks Avi -----Original Message----- From: Hsin-Hsiang Tseng [mailto:hsinhsiangts...@gmail.com] Sent: Tuesday, July 01, 2014 9:29 AM To: Chris Ball Cc: Grant Grundler; c...@laptop.org; Ulf Hansson; linux-mmc@vger.kernel.org; Alex Lemberg; Avi Shchislowski; Olof Johansson Subject: Re: [RFC PATCH 1/1 v7]mmc: Support-FFU-for-eMMC-v5.0 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 <ch...@printf.net>: > 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 majord...@vger.kernel.org More majordomo > info at http://vger.kernel.org/majordomo-info.html
