Message-ID: <20150127101440.GA17721@leverpostej>
Date:	Tue, 27 Jan 2015 10:14:40 +0000
From:	Mark Rutland <mark.rutland@....com>
To:	Jon Masters <jcm@...hat.com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"leif.lindholm@...aro.org" <leif.lindholm@...aro.org>,
	"grant.likely@...aro.org" <grant.likely@...aro.org>,
	andre.przywara@....com
Subject: Re: inverse mapping from a struct console to device

On Tue, Jan 27, 2015 at 03:06:35AM +0000, Jon Masters wrote:
> On 01/26/2015 03:50 PM, Mark Rutland wrote:
> > On Mon, Jan 26, 2015 at 07:40:58PM +0000, Jon Masters wrote:
> >> Hi Folks,
> >>
> >> TLDR: I need a back reference from a console struct to its device. I
> >> can't see an easy way to do this right now without adding one?
> > 
> > I don't think that's quite what you need. All you need is to be able to
> > refer to the SPCR at serial probe time (more on that below), when you
> > should have the data you want.
> 
> Hmm. I wanted to do it in console_register due to the existing logic for
> adding a preferred console there. But that's a silly reason.
> 
> >> 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)
> > 
> > In DT we have /chosen/stdout-path which offers analagous functionality.
> > It is independent of the command line, and has a standard set of
> > parameters (<baud>{<parity>{<bits>{<flow>}}}).
> 
> Hmm. I thought it was embedding a Linux specific console parameter, but
> I see when I actually check the code and the Documentation (sorry) that
> it is indeed similar in capability. Which is awesome. I'll do similar.
> 
> > To make this work we check against the stdout-path when we register the
> > UART. Take a look at of_console check (called from uart_add_one_port).
> 
> Great. Thanks. I looked at modifying uart_add_one_port, but I wasn't
> convinced it was called by every serial driver (for example, the
> sbsauart driver). I don't know the tty/serial code as well as I'd like.
> But I'll implement it the same way as in the OF case for the moment, and
> if we need to fix up a driver or two we can always do that.

The SBSA UART is a bit of a special case, given it cannot be
reconfigured. While Andre's SBSA UART driver [1] will call
uart_add_one_port (as the PL011 driver seems to currently), I believe
any configuration is ignored.

In the DT case, we'd expect the SBSA UART node to have a current-speed
property describing the fixed, preconfigured speed. This has no bearing
on the operation of the driver (because there's nothing to configure)
and is only used to report the speed to userspace.

I guess we don't have something on the ACPI node, and you want to use
the SPCR to determine the preconfigured rate in this case?

> > Assuming your UART probing looks similar for ACPI, you can have an
> > analagous function that goes and checks uport->dev.acpi_dev_node against
> > entires in the SPCR, configuring the UART as required at this point at
> > registration time.
> 
> > This requires that you parse the SPCR earlier, but presumably the SPCR
> > is simple enough that this is possible (no AML, for instance).
> 
> I already parse it as an initcall early in boot and indeed have it prior
> to the port being registered.
> 
> > Is there some reason that approach is unworkable?
> 
> Apparently not, just need to check a couple of drivers.
> 
> Thanks Mark. I'll post a patch later for SPCR setup.

Great!

Mark.

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/317146.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists