Re: [PATCH -next 00/13] Extensible console matching & direct earlycon

[Rob Herring]

On Tue, Feb 24, 2015 at 10:36 AM, Peter Hurley <peter@xxxxxxxxxxxxxxxxxx> wrote:
> Hi Greg & Andrew,
>
> This patch series implements:
>   1. console-definable (aka extensible) matching
>   2. generic earlycon-to-console handoff via extensible matching
>   3. arch/prom support for direct earlycon
>
>
> Extensible console matching
>
> Extensible console matching enables the console itself to define the
> conditions for a "command line" match. This mimics the design of
> device matching in the driver model. Two important use-cases which this
> feature enables are generic earlycon-to-console handoff and support
> for driver migration.
>
> Earlycon-to-console handoff was implemented in 2007. Console command
> lines of the form:
>    console=uart,io,0x3f8,115200n8
> start an earlycon and later allow the 8250 driver console to takeover.
> Unfortunately this implementation requires direct coupling between
> the earlycon and the console and is facilitated by ugly hacks like
> editing the console command line in-place.
>
> Extensible console matching allows the 8250 driver to directly match
> that console command line instead, and enables other serial drivers
> to trivially support console handoff themselves.
>
> In addition, extensible console matching allows a new driver to
> provide support for a different driver's console. This requirement
> stems from needing to minimize breakage when migrating serial drivers.
> Since many devices are based on the original 8250/16550 designs
> but sometimes have features incompatible with the existing 8250 driver
> support, the initial driver is often standalone. When/if the standalone
> driver is migrated to the 8250 driver, the problem of console names in
> the command line remains. Extensible console matching enables a simple
> migration path.
>
>
> Direct earlycon
>
> This feature enables arches and proms to start an earlycon directly,
> rather than requiring an "earlycon=" command line parameter.
> Devicetree can already do this via the 'linux,stdout-path' property,
> but arch and prom code requires direct coupling to the serial driver.
>
> This support is implemented by judicious refactoring and the same
> construct that devicetree and early_param use: a link table containing
> the necessary information (name and setup() function) to find and
> bind the appropriate earlycon "driver".

I've skimmed thru this and it looks like a great improvement.

One problem we have currently with DT stdout-path and earlycon is a
preferred console does not get registered, so the console will get
switched to tty0 and you lose your console. The problem is DT does not
know the console name to register a preferred console. It looks like
this series may help this problem, but I'm not sure and wanted your
thoughts.

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/