On 03/17/2015 10:20 AM, Peter Hurley wrote: > On 03/17/2015 09:43 AM, Hans de Goede wrote: >> Hi, >> >> On 17-03-15 14:30, Rob Herring wrote: >>> On Tue, Mar 17, 2015 at 3:20 AM, Hans de Goede <hdegoede@xxxxxxxxxx> wrote: >> >> <snip> >> >>>> TBH I do not understand why we're even arguing here, AFAICT the behavior >>>> change >>>> is an unwanted side-effect of your patch, so the solution is to rewrite the >>>> patch >>>> so that we get the same end result (not turning off bootconsole-s too early) >>>> without >>>> the unwanted side-effect, and you agreed to work on that ? >>> >>> I intend to revert this if we don't have a fix soon. >>> >>> I think we just need a flag saying we've enabled the earlycon from >>> stdout-path or not and then add the preferred console based on that. I >>> assume with "earlycon" only on the command-line, getting console only >>> on stdout-path is okay. >> >> Yes, if a user explicitly specifies something like "earlycon" on the >> commandline then not automatically getting console output on tty0 is >> fine AFAICT. The use case important for me / distros is when no >> console= (or related) arguments are present on the cmdline at all, >> then the desired behavior is to have console output on tty0 as well >> as on any serial console specified with stdout-path. > > The issues raised by this patch have nothing to do with earlycon. > > 1. PowerPC boot crash - the report with the most troubleshooting info right now > implicates some buffer overflow or console mismanagement triggered by simply > having defined a preferred console. This needs to be figured out regardless, > and this is what I'm working right now. > > 2. Hans' use-case was _already broken_ even before this patch; _any_ driver > that adds a preferred console before the vt console driver will cause > this problem. So again, this needs to be fixed regardless. Rob, You're right; this patch will need to be reverted. I'll send you a revert. Regards, Peter Hurley -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html