On Mon, Jun 30, 2014 at 5:34 PM, Chris Ball <ch...@printf.net> wrote: > 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.
Hi Chris! Thanks for the response. You are correct that neither of us has tested the patch. But I know SanDisk, Samsung, and Kingston (IIRC) have. And in the case that FFU doesn't work, contracts with these HW vendors require FFU works. So they have financial incentives to make it work. I'm comfortable with support that ChromeOS has for this patch in the long term. Most of the magic (for FFU and general flash operation) is in the Vendor Firmware. We depend on those vendors entirely for this to work correctly already. This is not a new dependency and looks more like collaboration when they supply the patch to support "industry standard" features (like FFU). > We could do it, though -- I'd like to hear what Ulf thinks. Sure - me too. :) > Please could you give a quick explanation of why doing this > in kernel-space makes more sense than using your mmc-utils version? Only the kernel can guarantee no other commands are sent to the device during FFU. User space can attempt to hold this promise but the constraints on when it can are pretty onerous. SanDisk is pushing this patch entirely for this reason and I agree it's a better solution. I don't know about extCSD[492] FFU_FEATURES bits that Hsin-Hsiang mentions. cheers, grant > > 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
