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

[Rob Herring]

On Tue, Feb 24, 2015 at 1:53 PM, Peter Hurley <peter@xxxxxxxxxxxxxxxxxx> wrote:
> Hi Rob,
>
> On 02/24/2015 02:27 PM, Rob Herring wrote:
>> 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.
>
> I thought that of_alias_scan() + of_console_check() caused DT stdout-path
> to add_preferred_console() the driver console @ port registration time
> via uart_add_one_port() -> of_console_check().
>
> Is that not how that works?

Yes, I believe that is how it works with earlycon not enabled. This
doesn't work when earlycon is enabled with just "earlycon" on the
command line. The fix I have is here[1], but I don't like putting DT
specifics into the console code.

Rob

[1] https://lkml.org/lkml/2014/7/25/333
--
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/