LKML Archive on
help / color / mirror / Atom feed
From: Jon Masters <>
To: Greg KH <>
Cc: "" <>
Subject: Re: inverse mapping from a struct console to device
Date: Mon, 26 Jan 2015 22:16:02 -0500	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 01/26/2015 03:20 PM, Greg KH wrote:
> On Mon, Jan 26, 2015 at 02:40:58PM -0500, Jon Masters wrote:

>> I've a quick question. I have prototype code that parses an ACPI table
>> known as the SPCR (Serial Port Console Redirection - exists on both x86
>> and ARM systems). It finds the correct serial device (but it's not a
>> Linux specific DT-style solution so there's no "console=" parameter
>> embedded in it or something) to use for the preferred console (I have
>> effectively the device object connected with the acpi_handle of the
>> underlying serial device, which I map on by walking the ACPI namespace
>> down from the root until I find the _ADR of the specified SPCR address).
>> One of the problems that I have is that I want to make the decision
>> about whether a console should be automatically configured once we get
>> to register_console, because that's where the existing logic is, and
>> it's one path I can be sure everyone is going to call (serial drivers
>> have a number of different APIs that they use during registration).
>> Once I'm in register_console, I have only the console struct to play
>> with. I can get from that to the tty_driver (by walking the tty driver
>> list and finding the back reference), but that still doesn't give me
>> what I want. I can add a reference to the underlying device in one of
>> these structs, but I would like to have additional opinions before I go
>> and make something hackish folks will balk at later. So, am I missing
>> something obvious? I hope I am because this seems slightly weird.
> I really don't understand what you are wanting to do here.  Who wants to
> "automatically configure" a console?

On ARM systems, we've several possible serial devices that could be in
use. We don't want to have to specify the console on the kernel command
line at install/boot time. Additionally, we want to (later)
automatically configure earlycon parameters. Fortunately there's an ACPI
table known as the SPCR which provides information about the preferred
serial uart, including type/address/interrupt/etc. SPCR exists on x86
systems too, and in fact has been used by Windows for over a decade to
handle the setup of its SAC (Special Administration Console). The
license on the underlying SPCR spec has been opened in the past couple
of years to cover other OS implementations using it.

Currently, we internally have a hack that sets up the console as a
preferred console, but it's not a long term solution. For that, I had
the SPCR made a requirement in the ARM SBBR specification. Windows on
x86 doesn't use the GSIV (ACPI interrupt) from my understanding so I
preemptively asked that it be made a requirement that this be populated,
along with requiring revision 2+ of the table. That way, we can propose
patches to use the SPCR for setup that might be useful on x86 (and if
limiting to revision 2+ it won't break existing systems as essentially
no PC class system reports that revision of the table yet).

For the rest - Mark Rutland's followup and my reply covers it I think.



  reply	other threads:[~2015-01-27  3:16 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-26 19:40 Jon Masters
2015-01-26 20:20 ` Greg KH
2015-01-27  3:16   ` Jon Masters [this message]
2015-01-26 20:50 ` Mark Rutland
2015-01-27  3:06   ` Jon Masters
2015-01-27 10:14     ` Mark Rutland
2015-01-27 11:54       ` Jon Masters
2015-01-27 12:30         ` Mark Rutland
2015-01-27 20:42           ` Jon Masters
2015-01-28 22:48             ` Peter Hurley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \
    --subject='Re: inverse mapping from a struct console to device' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).