John, On Thu, Jul 10, 2014 at 12:33 AM, John Stultz <[email protected]> wrote: > On Fri, Jan 13, 2012 at 11:15 PM, Doug Anderson <[email protected]> wrote: >> The old logic assumes CMDLINE_FROM_BOOTLOADER vs. CMDLINE_FORCE and >> ignores CMDLINE_EXTEND. Here's the old logic: >> >> - CONFIG_CMDLINE_FORCE=true >> CONFIG_CMDLINE >> - dt bootargs=non-empty: >> dt bootargs >> - dt bootargs=empty, @data is non-empty string >> @data is left unchanged >> - dt bootargs=empty, @data is empty string >> CONFIG_CMDLINE (or "" if that's not defined) >> >> The new logic is now documented in of_fdt.h and is copied here for >> reference: >> >> - CONFIG_CMDLINE_FORCE=true >> CONFIG_CMDLINE >> - CONFIG_CMDLINE_EXTEND=true, @data is non-empty string >> @data + dt bootargs (even if dt bootargs are empty) >> - CONFIG_CMDLINE_EXTEND=true, @data is empty string >> CONFIG_CMDLINE + dt bootargs (even if dt bootargs are empty) >> - CMDLINE_FROM_BOOTLOADER=true, dt bootargs=non-empty: >> dt bootargs >> - CMDLINE_FROM_BOOTLOADER=true, dt bootargs=empty, @data is non-empty string >> @data is left unchanged >> - CMDLINE_FROM_BOOTLOADER=true, dt bootargs=empty, @data is empty string >> CONFIG_CMDLINE (or "" if that's not defined) >> >> Signed-off-by: Doug Anderson <[email protected]> >> CC: [email protected] >> CC: Grant Likely <[email protected]> >> CC: Benjamin Herrenschmidt <[email protected]> >> CC: Rob Herring <[email protected]> >> --- >> I didn't hear a response from Ben about whether he was OK with >> my proposal for how CONFIG_CMDLINE_EXTEND should behave with >> a non-empty @data, so sending out code that implements my >> interpretation. Hopefully this looks OK. >> >> Changes in v2: >> - Removed broken fix for the case when there is no "chosen" attribute. >> - Changed CONFIG_CMDLINE_EXTEND behavior when @data is a non-empty string. > > In reviewing some of the random patches in the Android AOSP common.git > tree, I noticed this one, and found this discussion which petered out > without resolution. Were there any objections still, or did this just > slip through the cracks?
I gave up and decided not to keep pushing and solved the problem another way myself. ...but I still agree that it's a reasonable thing to do. I haven't really thought about this in several years now... I do remember seeing <https://android-review.googlesource.com/#/c/57349/1/drivers/of/fdt.c> where Colin looked to be making a bunch of changes to the patch before merging, but I guess he ended up splitting that into a cleanup patch. I think I pinged him to ask if he wanted me to get involved in the review but I got no response. > Note, there's also this follow-on fix from Colin, which probably > should be included if the parent patch is merged: > https://android.googlesource.com/kernel/common.git/+/a2acc58bc7460a03627f20842a7169d7a1328299 OK. Seems reasonable to me. I haven't done a full review of all of the boundary conditions here, but otherwise it looks fine. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
