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. 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
