PIng. :) Just a friendly reminder. I am aware of additional issues that Gwendal pointed out. But I still think it's better to take this patch now, knowing there are issues (which is better than NOT knowing there are issues), and then review additional patches for the outstand issues.
thanks, grant On Tue, Jul 1, 2014 at 10:07 AM, Ulf Hansson <ulf.hans...@linaro.org> wrote: > On 1 July 2014 17:47, Grant Grundler <grund...@chromium.org> wrote: >> 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. :) > > Hi Grant, > > Sorry for lack of input! > > Unfortunate I am travelling and will have to come back to this next week. > >> >>> 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 am open to consider this patch. From my point of view, I need some > additional time to review the code. > > Kind regards > Uffe -- 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
