On Nov 21, 2008, at 10:13 AM, Timur Tabi wrote:
Milton Miller wrote:
We want the last console= parameter on the command line to win. So if
that implys the last call to add_preferred_console wins, then you have
code overriding the command line.
Hmm, good point. However, how likely is it that we'll have more than
one
console driver?
For anything than custom embedded configs, quite likely. As I said, I
have 3 hvc clients, but that is unusual. But frame buffer, vterm,
rtas, and serial console would be a typical mix for a distribution.
Also, without calling add_preferred_console(), the kernel needs
to have a console= on the command line.
I'm not arguing against the call, I'm arguing when/from where it should
be made.
In my case, my driver only calls add_preferred_console() if the device
tree
contains a specific property that it looks for. In effect, this
property
override the console= line. However, the console= line goes to the HVC
subsystem, and not my driver, and I can't use it to send the
configuration data
the driver needs.
Discovering the hardware from the device tree and triggering your
regitration is the right approach. I think if you discover from an
early setup then you can go before the command line.
As far as getting parameters, you are talking like ttyS0,9600,8,n,1 ?
If you go after hvc_console then you could add a patch for hvc_console
to remember the setup and return it to possible clients.
Unfortunately, my driver hasn't been published yet, so it's hard to
explain the
details. I guess I need to think about this more.
I dont' know what details you would want on the console= command line
that you should not have in the device tree. If its which hypervisor
channel, then I would think just choosing your hvc number accordingly
would work. But I can only make wild guesses without details.
milton
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
