console vs earlycon ?

console vs earlycon ?

[Masahiro Yamada]

Hi.




I think there are three places where console could be enabled.

[1] earlycon

Each driver entry is declared with
EARLYCON_DECLARE()  or OF_EARLYCON_DECLARE()



[2] console_init()

Each entry is declared with  console_initcall()



[3]  when driver is probed
The console is usually enabled at this point
unless some special treatment is done.




My question is about [2].

I am using 8250-ish UART device.


I noticed univ8250_console_match() and univ8250_console_setup()
always fail at the point of [2] unless early_serial_setup() has been
called in advance;
however, it looks like early_serial_setup() is only used for old platforms.

So, console cannot be enabled at [2] for modern platforms.


My questions are:

 -  Given that earlycon can be now available for major architectures such ARM,
     [2] will be deprecated at some point in the future?

 - I am implementing  earlycon  for my own UART driver.
   Is it meaningless to implement  console_initcall()  as well as earlycon?



-- 
Best Regards
Masahiro Yamada

console vs earlycon ?

[Arnd Bergmann]

On Wednesday 21 October 2015 17:21:07 Masahiro Yamada wrote:
> Hi.
> 
> 
> 
> 
> I think there are three places where console could be enabled.
> 
> [1] earlycon
> 
> Each driver entry is declared with
> EARLYCON_DECLARE()  or OF_EARLYCON_DECLARE()
> 
> 
> 
> [2] console_init()
> 
> Each entry is declared with  console_initcall()
> 
> 
> 
> [3]  when driver is probed
> The console is usually enabled at this point
> unless some special treatment is done.
> 
> 
> 
> 
> My question is about [2].
> 
> I am using 8250-ish UART device.
> 
> 
> I noticed univ8250_console_match() and univ8250_console_setup()
> always fail at the point of [2] unless early_serial_setup() has been
> called in advance;
> however, it looks like early_serial_setup() is only used for old platforms.
> 
> So, console cannot be enabled at [2] for modern platforms.
> 
> 
> My questions are:
> 
>  -  Given that earlycon can be now available for major architectures such ARM,
>      [2] will be deprecated at some point in the future?
> 
>  - I am implementing  earlycon  for my own UART driver.
>    Is it meaningless to implement  console_initcall()  as well as earlycon?

I would still do both. We don't enable earlycon by default at the moment,
and I'd say things should remain working with just console_initcall().

How closely related to 8250 is your hardware? If it's not all that different,
you should probably reuse the existing driver.

	Arnd

console vs earlycon ?

[Masahiro Yamada]

Hi Arnd,


2015-10-21 17:57 GMT+09:00 Arnd Bergmann <arnd@arndb.de>:
> On Wednesday 21 October 2015 17:21:07 Masahiro Yamada wrote:
>> Hi.
>>
>>
>>
>>
>> I think there are three places where console could be enabled.
>>
>> [1] earlycon
>>
>> Each driver entry is declared with
>> EARLYCON_DECLARE()  or OF_EARLYCON_DECLARE()
>>
>>
>>
>> [2] console_init()
>>
>> Each entry is declared with  console_initcall()
>>
>>
>>
>> [3]  when driver is probed
>> The console is usually enabled at this point
>> unless some special treatment is done.
>>
>>
>>
>>
>> My question is about [2].
>>
>> I am using 8250-ish UART device.
>>
>>
>> I noticed univ8250_console_match() and univ8250_console_setup()
>> always fail at the point of [2] unless early_serial_setup() has been
>> called in advance;
>> however, it looks like early_serial_setup() is only used for old platforms.
>>
>> So, console cannot be enabled at [2] for modern platforms.
>>
>>
>> My questions are:
>>
>>  -  Given that earlycon can be now available for major architectures such ARM,
>>      [2] will be deprecated at some point in the future?
>>
>>  - I am implementing  earlycon  for my own UART driver.
>>    Is it meaningless to implement  console_initcall()  as well as earlycon?
>
> I would still do both. We don't enable earlycon by default at the moment,
> and I'd say things should remain working with just console_initcall().
>
> How closely related to 8250 is your hardware? If it's not all that different,
> you should probably reuse the existing driver.


Very close.
It is already in the mainline.

drivers/tty/serial/8250/8250_uniphier.c

The core parts are shared with 8250_core.c


I am trying to implement OF_EARLYCON_DECLARE() for that.

I was just wondering if console_initcall() should work as well.


As I said, I noticed the console_initcall() in 8250_core.c
only works on very limited platforms.



-- 
Best Regards
Masahiro Yamada

console vs earlycon ?

[Arnd Bergmann]

On Wednesday 21 October 2015 18:09:33 Masahiro Yamada wrote:
> Hi Arnd,
> 
> 
> 2015-10-21 17:57 GMT+09:00 Arnd Bergmann <arnd@arndb.de>:
> > On Wednesday 21 October 2015 17:21:07 Masahiro Yamada wrote:
> >> Hi.
> >>
> >>
> >>
> >>
> >> I think there are three places where console could be enabled.
> >>
> >> [1] earlycon
> >>
> >> Each driver entry is declared with
> >> EARLYCON_DECLARE()  or OF_EARLYCON_DECLARE()
> >>
> >>
> >>
> >> [2] console_init()
> >>
> >> Each entry is declared with  console_initcall()
> >>
> >>
> >>
> >> [3]  when driver is probed
> >> The console is usually enabled at this point
> >> unless some special treatment is done.
> >>
> >>
> >>
> >>
> >> My question is about [2].
> >>
> >> I am using 8250-ish UART device.
> >>
> >>
> >> I noticed univ8250_console_match() and univ8250_console_setup()
> >> always fail at the point of [2] unless early_serial_setup() has been
> >> called in advance;
> >> however, it looks like early_serial_setup() is only used for old platforms.
> >>
> >> So, console cannot be enabled at [2] for modern platforms.
> >>
> >>
> >> My questions are:
> >>
> >>  -  Given that earlycon can be now available for major architectures such ARM,
> >>      [2] will be deprecated at some point in the future?
> >>
> >>  - I am implementing  earlycon  for my own UART driver.
> >>    Is it meaningless to implement  console_initcall()  as well as earlycon?
> >
> > I would still do both. We don't enable earlycon by default at the moment,
> > and I'd say things should remain working with just console_initcall().
> >
> > How closely related to 8250 is your hardware? If it's not all that different,
> > you should probably reuse the existing driver.
> 
> 
> Very close.
> It is already in the mainline.
> 
> drivers/tty/serial/8250/8250_uniphier.c
> 
> The core parts are shared with 8250_core.c

Ok, but I guess no close enough that it makes sense to use drivers/serial/of_serial.c


> I am trying to implement OF_EARLYCON_DECLARE() for that.
> 
> I was just wondering if console_initcall() should work as well.
> 
> 
> As I said, I noticed the console_initcall() in 8250_core.c
> only works on very limited platforms.

It works with all those that use of_serial.c, right? I think they are
the majority.

	Arnd

console vs earlycon ?

[Masahiro Yamada]

Hi Arnd,


2015-10-21 18:19 GMT+09:00 Arnd Bergmann <arnd@arndb.de>:
> On Wednesday 21 October 2015 18:09:33 Masahiro Yamada wrote:
>> Hi Arnd,
>>
>>
>> 2015-10-21 17:57 GMT+09:00 Arnd Bergmann <arnd@arndb.de>:
>> > On Wednesday 21 October 2015 17:21:07 Masahiro Yamada wrote:
>> >> Hi.
>> >>
>> >>
>> >>
>> >>
>> >> I think there are three places where console could be enabled.
>> >>
>> >> [1] earlycon
>> >>
>> >> Each driver entry is declared with
>> >> EARLYCON_DECLARE()  or OF_EARLYCON_DECLARE()
>> >>
>> >>
>> >>
>> >> [2] console_init()
>> >>
>> >> Each entry is declared with  console_initcall()
>> >>
>> >>
>> >>
>> >> [3]  when driver is probed
>> >> The console is usually enabled at this point
>> >> unless some special treatment is done.
>> >>
>> >>
>> >>
>> >>
>> >> My question is about [2].
>> >>
>> >> I am using 8250-ish UART device.
>> >>
>> >>
>> >> I noticed univ8250_console_match() and univ8250_console_setup()
>> >> always fail at the point of [2] unless early_serial_setup() has been
>> >> called in advance;
>> >> however, it looks like early_serial_setup() is only used for old platforms.
>> >>
>> >> So, console cannot be enabled at [2] for modern platforms.
>> >>
>> >>
>> >> My questions are:
>> >>
>> >>  -  Given that earlycon can be now available for major architectures such ARM,
>> >>      [2] will be deprecated at some point in the future?
>> >>
>> >>  - I am implementing  earlycon  for my own UART driver.
>> >>    Is it meaningless to implement  console_initcall()  as well as earlycon?
>> >
>> > I would still do both. We don't enable earlycon by default at the moment,
>> > and I'd say things should remain working with just console_initcall().
>> >
>> > How closely related to 8250 is your hardware? If it's not all that different,
>> > you should probably reuse the existing driver.
>>
>>
>> Very close.
>> It is already in the mainline.
>>
>> drivers/tty/serial/8250/8250_uniphier.c
>>
>> The core parts are shared with 8250_core.c
>
> Ok, but I guess no close enough that it makes sense to use drivers/serial/of_serial.c

Right.


>
>> I am trying to implement OF_EARLYCON_DECLARE() for that.
>>
>> I was just wondering if console_initcall() should work as well.
>>
>>
>> As I said, I noticed the console_initcall() in 8250_core.c
>> only works on very limited platforms.
>
> It works with all those that use of_serial.c, right?

I doubt it.


I have a board with a pure 8250-compat device working.
(  compatible = "ns16550a")
It uses of_serial.c, of course.


As far as I tested, it would never enable the console at console_init().

The console is enabled when the UART driver is probed.
(or earlycon if "earlycon" is specified in the kernel-parameter.)


-- 
Best Regards
Masahiro Yamada

console vs earlycon ?

[Arnd Bergmann]

On Wednesday 21 October 2015 18:30:05 Masahiro Yamada wrote:
> >
> >> I am trying to implement OF_EARLYCON_DECLARE() for that.
> >>
> >> I was just wondering if console_initcall() should work as well.
> >>
> >>
> >> As I said, I noticed the console_initcall() in 8250_core.c
> >> only works on very limited platforms.
> >
> > It works with all those that use of_serial.c, right?
> 
> I doubt it.
> 
> 
> I have a board with a pure 8250-compat device working.
> (  compatible = "ns16550a")
> It uses of_serial.c, of course.
> 
> 
> As far as I tested, it would never enable the console at console_init().

Ok, that sounds like a bug. Peter and others have changed that code
a lot in the last year. I wonder if this has never worked then or
if it has regressed.

> The console is enabled when the UART driver is probed.
> (or earlycon if "earlycon" is specified in the kernel-parameter.)

Got it. Let me know if you think this interpretation is correct:

* univ8250_console_match() looks for the earlycon argument format like
  "console=uart[8250],io|mmio|mmio32,<addr>[,<options>]", and that
  would work, but we don't want to have to pass all that data when
  the information should already be there.

* univ8250_console_setup() looks for ports that have been added by
  one of several other methods (including earlycon) already, but
  we don't do that on ARM without earlycon being enabled.

* arch/powerpc/kernel/legacy_serial.c does everything we need, but
  does not live in architecture independent code and does a few
  things that we probably don't need or want there. It relies
  on scanning the device tree for known UART device nodes before
  the platform devices are added.

* for console_initcall() to do the right thing, we want both the
  ttyS devices to get added early for console=ttyS1 to work, as well
  as having the preferred console work based on the stdout-property.

* we parse the /chosen/stdout-path property in drivers/of/base and
  store the device node pointer in the global 'of_stdout' variable,
  but do not use it until the uart is added by the tty driver
  and calls of_console_check() to add the default console device.
 
	Arnd

console vs earlycon ?

[Peter Hurley]

On 10/21/2015 06:36 AM, Arnd Bergmann wrote:
> On Wednesday 21 October 2015 18:30:05 Masahiro Yamada wrote:
>>>
>>>> I am trying to implement OF_EARLYCON_DECLARE() for that.
>>>>
>>>> I was just wondering if console_initcall() should work as well.
>>>>
>>>>
>>>> As I said, I noticed the console_initcall() in 8250_core.c
>>>> only works on very limited platforms.
>>>
>>> It works with all those that use of_serial.c, right?
>>
>> I doubt it.
>>
>>
>> I have a board with a pure 8250-compat device working.
>> (  compatible = "ns16550a")
>> It uses of_serial.c, of course.
>>
>>
>> As far as I tested, it would never enable the console at console_init().
> 
> Ok, that sounds like a bug. Peter and others have changed that code
> a lot in the last year. I wonder if this has never worked then or
> if it has regressed.

No, not a bug. console_init() is only for legacy platforms, not for
probed drivers.

>> The console is enabled when the UART driver is probed.
>> (or earlycon if "earlycon" is specified in the kernel-parameter.)
> 
> Got it. Let me know if you think this interpretation is correct:
> 
> * univ8250_console_match() looks for the earlycon argument format like
>   "console=uart[8250],io|mmio|mmio32,<addr>[,<options>]", and that
>   would work, but we don't want to have to pass all that data when
>   the information should already be there.

This only works at console_init() time for legacy platforms that
have already initialized the 8250 port table.


> * univ8250_console_setup() looks for ports that have been added by
>   one of several other methods (including earlycon) already

8250 earlycon doesn't add ports.

>   , but we don't do that on ARM without earlycon being enabled.


> * arch/powerpc/kernel/legacy_serial.c does everything we need, but
>   does not live in architecture independent code and does a few
>   things that we probably don't need or want there. It relies
>   on scanning the device tree for known UART device nodes before
>   the platform devices are added.
> 
> * for console_initcall() to do the right thing, we want both the
>   ttyS devices to get added early for console=ttyS1 to work, as well
>   as having the preferred console work based on the stdout-property.
> 
> * we parse the /chosen/stdout-path property in drivers/of/base and
>   store the device node pointer in the global 'of_stdout' variable,
>   but do not use it until the uart is added by the tty driver
>   and calls of_console_check() to add the default console device.

I'm assuming the issue with trying to get console_init() working
is because the dummy color console causes the earlycon to be disabled?

I fixed that once before for stdout-path but there were some regressions
on PPC platforms; maybe I can revisit that.

Regards,
Peter Hurley

console vs earlycon ?

[Arnd Bergmann]

On Wednesday 21 October 2015 09:53:47 Peter Hurley wrote:
> On 10/21/2015 06:36 AM, Arnd Bergmann wrote:
> > On Wednesday 21 October 2015 18:30:05 Masahiro Yamada wrote:
> >>>
> >>>> I am trying to implement OF_EARLYCON_DECLARE() for that.
> >>>>
> >>>> I was just wondering if console_initcall() should work as well.
> >>>>
> >>>>
> >>>> As I said, I noticed the console_initcall() in 8250_core.c
> >>>> only works on very limited platforms.
> >>>
> >>> It works with all those that use of_serial.c, right?
> >>
> >> I doubt it.
> >>
> >>
> >> I have a board with a pure 8250-compat device working.
> >> (  compatible = "ns16550a")
> >> It uses of_serial.c, of course.
> >>
> >>
> >> As far as I tested, it would never enable the console at console_init().
> > 
> > Ok, that sounds like a bug. Peter and others have changed that code
> > a lot in the last year. I wonder if this has never worked then or
> > if it has regressed.
> 
> No, not a bug. console_init() is only for legacy platforms, not for
> probed drivers.

Ah, I had no idea we were moving in this direction. So I guess the idea
is not to add another for_each_compatible_node() loop when we already have
two places (earlycon and tty) in the code that do this?

> > * arch/powerpc/kernel/legacy_serial.c does everything we need, but
> >   does not live in architecture independent code and does a few
> >   things that we probably don't need or want there. It relies
> >   on scanning the device tree for known UART device nodes before
> >   the platform devices are added.
> > 
> > * for console_initcall() to do the right thing, we want both the
> >   ttyS devices to get added early for console=ttyS1 to work, as well
> >   as having the preferred console work based on the stdout-property.
> > 
> > * we parse the /chosen/stdout-path property in drivers/of/base and
> >   store the device node pointer in the global 'of_stdout' variable,
> >   but do not use it until the uart is added by the tty driver
> >   and calls of_console_check() to add the default console device.
> 
> I'm assuming the issue with trying to get console_init() working
> is because the dummy color console causes the earlycon to be disabled?

I don't think so.

My line of thinking was more about usability: earlycon requires that
you edit the kernel command line at the moment, while console_init()
doesn't require any user interaction and just uses the stdout-path.

I guess we could enable earlycon using a Kconfig symbol if we want
to, or make it a per-architecture decision whether it's enabled even
in the absence of the command line flag.

	Arnd

console vs earlycon ?

[Peter Hurley]

On 10/21/2015 10:13 AM, Arnd Bergmann wrote:
> On Wednesday 21 October 2015 09:53:47 Peter Hurley wrote:
>> On 10/21/2015 06:36 AM, Arnd Bergmann wrote:
>>> On Wednesday 21 October 2015 18:30:05 Masahiro Yamada wrote:
>>>>>
>>>>>> I am trying to implement OF_EARLYCON_DECLARE() for that.
>>>>>>
>>>>>> I was just wondering if console_initcall() should work as well.
>>>>>>
>>>>>>
>>>>>> As I said, I noticed the console_initcall() in 8250_core.c
>>>>>> only works on very limited platforms.
>>>>>
>>>>> It works with all those that use of_serial.c, right?
>>>>
>>>> I doubt it.
>>>>
>>>>
>>>> I have a board with a pure 8250-compat device working.
>>>> (  compatible = "ns16550a")
>>>> It uses of_serial.c, of course.
>>>>
>>>>
>>>> As far as I tested, it would never enable the console at console_init().
>>>
>>> Ok, that sounds like a bug. Peter and others have changed that code
>>> a lot in the last year. I wonder if this has never worked then or
>>> if it has regressed.
>>
>> No, not a bug. console_init() is only for legacy platforms, not for
>> probed drivers.
> 
> Ah, I had no idea we were moving in this direction.

I would not say this was a conscious design decision, but rather an
outcome of getting-something-working-without-breaking-existing-usage.

My main focus with earlycon/console has been to try to reduce and
generalize the existing code.

> So I guess the idea
> is not to add another for_each_compatible_node() loop when we already have
> two places (earlycon and tty) in the code that do this?

I wouldn't want to do that just because, but rather only to enable some
functionality that doesn't work now.

FWIW, console_init() is basically a hack. The dummy color console
registration is a good example of the gymnastics made necessary by
console_init().

OTOH, I don't like the reverse-linkage that exists now between
serial core and OF (ie., of_console_check()). And now ACPI wants to
recapitulate that design. :/


>>> * arch/powerpc/kernel/legacy_serial.c does everything we need, but
>>>   does not live in architecture independent code and does a few
>>>   things that we probably don't need or want there. It relies
>>>   on scanning the device tree for known UART device nodes before
>>>   the platform devices are added.
>>>
>>> * for console_initcall() to do the right thing, we want both the
>>>   ttyS devices to get added early for console=ttyS1 to work, as well
>>>   as having the preferred console work based on the stdout-property.
>>>
>>> * we parse the /chosen/stdout-path property in drivers/of/base and
>>>   store the device node pointer in the global 'of_stdout' variable,
>>>   but do not use it until the uart is added by the tty driver
>>>   and calls of_console_check() to add the default console device.
>>
>> I'm assuming the issue with trying to get console_init() working
>> is because the dummy color console causes the earlycon to be disabled?
> 
> I don't think so.
> 
> My line of thinking was more about usability: earlycon requires that
> you edit the kernel command line at the moment, while console_init()
> doesn't require any user interaction and just uses the stdout-path.
> 
> I guess we could enable earlycon using a Kconfig symbol if we want
> to, or make it a per-architecture decision whether it's enabled even
> in the absence of the command line flag.

Ah, I see. You want to start the stdout-path console at console_init()
time.

Regards,
Peter Hurley

console vs earlycon ?

[Arnd Bergmann]

On Wednesday 21 October 2015 11:32:15 Peter Hurley wrote:
> On 10/21/2015 10:13 AM, Arnd Bergmann wrote:
> > On Wednesday 21 October 2015 09:53:47 Peter Hurley wrote:
> > 
> > Ah, I had no idea we were moving in this direction.
> 
> I would not say this was a conscious design decision, but rather an
> outcome of getting-something-working-without-breaking-existing-usage.
> 
> My main focus with earlycon/console has been to try to reduce and
> generalize the existing code.

Ok.

> >> I'm assuming the issue with trying to get console_init() working
> >> is because the dummy color console causes the earlycon to be disabled?
> > 
> > I don't think so.
> > 
> > My line of thinking was more about usability: earlycon requires that
> > you edit the kernel command line at the moment, while console_init()
> > doesn't require any user interaction and just uses the stdout-path.
> > 
> > I guess we could enable earlycon using a Kconfig symbol if we want
> > to, or make it a per-architecture decision whether it's enabled even
> > in the absence of the command line flag.
> 
> Ah, I see. You want to start the stdout-path console at console_init()
> time.

Yes, I see this as a tradeoff: we want the console to be as early as
possible in order to report boot-time errors to the user, but not so early
to require hacks that can cause problems themselves. earlycon has to
do some scary stuff and is relatively recent, while the hacks
necessary for console_init() are much older and better tested.

	Arnd

console vs earlycon ?

[Peter Hurley]

On 10/21/2015 03:00 PM, Arnd Bergmann wrote:
> On Wednesday 21 October 2015 11:32:15 Peter Hurley wrote:
>> On 10/21/2015 10:13 AM, Arnd Bergmann wrote:
>>> On Wednesday 21 October 2015 09:53:47 Peter Hurley wrote:
>>>> I'm assuming the issue with trying to get console_init() working
>>>> is because the dummy color console causes the earlycon to be disabled?
>>>
>>> I don't think so.
>>>
>>> My line of thinking was more about usability: earlycon requires that
>>> you edit the kernel command line at the moment, while console_init()
>>> doesn't require any user interaction and just uses the stdout-path.
>>>
>>> I guess we could enable earlycon using a Kconfig symbol if we want
>>> to, or make it a per-architecture decision whether it's enabled even
>>> in the absence of the command line flag.
>>
>> Ah, I see. You want to start the stdout-path console at console_init()
>> time.
> 
> Yes, I see this as a tradeoff: we want the console to be as early as
> possible in order to report boot-time errors to the user, but not so early
> to require hacks that can cause problems themselves. earlycon has to
> do some scary stuff and is relatively recent, while the hacks
> necessary for console_init() are much older and better tested.

I assume you mean the hacks necessary to get _earlycon_ working at
console_init() time, because the hacks necessary to get non-8250
serial consoles working at console_init() would be extensive and
brand new.

Regards,
Peter Hurley

console vs earlycon ?

[Arnd Bergmann]

On Wednesday 21 October 2015 15:24:41 Peter Hurley wrote:
> On 10/21/2015 03:00 PM, Arnd Bergmann wrote:

> > Yes, I see this as a tradeoff: we want the console to be as early as
> > possible in order to report boot-time errors to the user, but not so early
> > to require hacks that can cause problems themselves. earlycon has to
> > do some scary stuff and is relatively recent, while the hacks
> > necessary for console_init() are much older and better tested.
> 
> I assume you mean the hacks necessary to get _earlycon_ working at
> console_init() time, because the hacks necessary to get non-8250
> serial consoles working at console_init() would be extensive and
> brand new.
> 

No, I was just being slow and assumed that the 51 drivers that come with
a console_initcall() do something in there to actually start the console,
but you are right that most of them don't actually do that. They just
call register_console() and wait for the device to show up later.

	Arnd

console vs earlycon ?

[Peter Hurley]

On 10/21/2015 04:21 AM, Masahiro Yamada wrote:
> Hi.
> 
> 
> 
> 
> I think there are three places where console could be enabled.
> 
> [1] earlycon
> 
> Each driver entry is declared with
> EARLYCON_DECLARE()  or OF_EARLYCON_DECLARE()
> 
> 
> 
> [2] console_init()
> 
> Each entry is declared with  console_initcall()
> 
> 
> 
> [3]  when driver is probed
> The console is usually enabled at this point
> unless some special treatment is done.
> 
> 
> 
> 
> My question is about [2].

For 8250 sub-drivers, the console_initcall() is only for legacy
platforms, and not for 8250 ports added via serial8250_register_8250_port().

In this contexts, legacy platforms are:
1. early_serial_setup()
2. platforms that define SERIAL_PORT_DFNS (eg., ISA ports)


At the point where console_initcall() occurs, the 8250 core has _not_
been initialized (ie., serial8250_init() has _not_ run).



> I am using 8250-ish UART device.
> 
> 
> I noticed univ8250_console_match() and univ8250_console_setup()
> always fail at the point of [2] unless early_serial_setup() has been
> called in advance;
> however, it looks like early_serial_setup() is only used for old platforms.
> 
> So, console cannot be enabled at [2] for modern platforms.

Since console_init() => console_initcall() occurs before almost everything,
it's not practical to use for probed drivers.


> My questions are:
> 
>  -  Given that earlycon can be now available for major architectures such ARM,
>      [2] will be deprecated at some point in the future?

PPC and x86 platforms still rely on console_init() so it will be some time
before this disappears.

>  - I am implementing  earlycon  for my own UART driver.
>    Is it meaningless to implement  console_initcall()  as well as earlycon?

Probed drivers should only implement earlycon and console. 8250 sub-drivers
should only implement earlycon and/or console if the base 8250 earlycon and/or
console are not operational.

Regards,
Peter Hurley

console vs earlycon ?

[Masahiro Yamada]

Hi Peter

2015-10-21 22:20 GMT+09:00 Peter Hurley <peter@hurleysoftware.com>:
> On 10/21/2015 04:21 AM, Masahiro Yamada wrote:
>> Hi.
>>
>>
>>
>>
>> I think there are three places where console could be enabled.
>>
>> [1] earlycon
>>
>> Each driver entry is declared with
>> EARLYCON_DECLARE()  or OF_EARLYCON_DECLARE()
>>
>>
>>
>> [2] console_init()
>>
>> Each entry is declared with  console_initcall()
>>
>>
>>
>> [3]  when driver is probed
>> The console is usually enabled at this point
>> unless some special treatment is done.
>>
>>
>>
>>
>> My question is about [2].
>
> For 8250 sub-drivers, the console_initcall() is only for legacy
> platforms, and not for 8250 ports added via serial8250_register_8250_port().
>
> In this contexts, legacy platforms are:
> 1. early_serial_setup()
> 2. platforms that define SERIAL_PORT_DFNS (eg., ISA ports)
>
>
> At the point where console_initcall() occurs, the 8250 core has _not_
> been initialized (ie., serial8250_init() has _not_ run).
>
>
>
>> I am using 8250-ish UART device.
>>
>>
>> I noticed univ8250_console_match() and univ8250_console_setup()
>> always fail at the point of [2] unless early_serial_setup() has been
>> called in advance;
>> however, it looks like early_serial_setup() is only used for old platforms.
>>
>> So, console cannot be enabled at [2] for modern platforms.
>
> Since console_init() => console_initcall() occurs before almost everything,
> it's not practical to use for probed drivers.
>
>
>> My questions are:
>>
>>  -  Given that earlycon can be now available for major architectures such ARM,
>>      [2] will be deprecated at some point in the future?
>
> PPC and x86 platforms still rely on console_init() so it will be some time
> before this disappears.
>
>>  - I am implementing  earlycon  for my own UART driver.
>>    Is it meaningless to implement  console_initcall()  as well as earlycon?
>
> Probed drivers should only implement earlycon and console. 8250 sub-drivers
> should only implement earlycon and/or console if the base 8250 earlycon and/or
> console are not operational.

Sorry, let me to be sure a bit.

Which does "console" in this context mean
  - console_initcall
  - console enabled when the driver is probed

I am assuming the latter.


Thanks,



-- 
Best Regards
Masahiro Yamada