linux-kernel - Re: [PATCH] SPCR: check bit width for the 16550 UART

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 07 Dec 2016 10:23:19 -0500
From:   Mark Salter <msalter@...hat.com>
To:     Jon Masters <jcm@...hat.com>, Duc Dang <dhdang@....com>
Cc:     Aleksey Makarov <aleksey.makarov@...aro.org>,
        "Rafael J . Wysocki" <rjw@...ysocki.net>,
        linux-acpi@...r.kernel.org, linux-serial@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Russell King <linux@....linux.org.uk>,
        Peter Hurley <peter@...leysoftware.com>,
        Graeme Gregory <graeme.gregory@...aro.org>,
        Len Brown <lenb@...nel.org>
Subject: Re: [PATCH] SPCR: check bit width for the 16550 UART

On Tue, 2016-12-06 at 01:34 -0500, Jon Masters wrote:
> On 12/05/2016 10:55 PM, Duc Dang wrote:
> > 
> > On Mon, Dec 5, 2016 at 6:27 PM, Jon Masters <jcm@...hat.com> wrote:
> > > 
> > > Hi Duc, all,
> > > 
> > > So after regenerating the initrd override (I must have fat fingered)
> > > it is now detecting the correct bit width on boot (attached dmesg log).
> > > 
> > > HOWEVER while the console does come up, the use of "earlycon" on the
> > > command line (with no parameters) doesn't result in the early SPCR
> > > console coming up correctly. I see some garbled characters that
> > > suggest the baud (or register access width) is off somewhere.
> > My bad that I did not catch this in the morning. Yes, earlycon does
> > not seems to work as expected. I can see that earlycon parameters
> > seems to be correct, but the bootconsole message does not come out
> > (the following is from 'dmesg')
> > 
> > [    0.000000] ACPI: SPCR: console: uart,mmio32,0x1c020000,115200
> > [    0.000000] earlycon: uart0 at MMIO32 0x000000001c020000 (options '115200')
> > [    0.000000] bootconsole [uart0] enabled
> The difference appears to be in the baud rate. When I explicitly specify
> "earlycon=uart8250,mmio32,0x1c021000" no baud is set. When booting with
> the SPCR, the baud is set to 9600 in my case or 115200 in yours. But we
> both know that the base clock on the X-Gene UART is weird. Maybe
> somehow we can explain this through the lack of setting a baud.

BTW, this behavior is same with devicetree.
If you specify a baudrate with earlycon=, the driver tries to set that
baudrate and if you have an 8250 with some non-standard baud clock, then
it will fail. Perhaps SPCR shouldn't pass baud option to setup_earlycon().
Then again, setup_earlycon() has this comment:

 *	setup_earlycon - match and register earlycon console
 *	@buf:	earlycon param string
 *
 *	Registers the earlycon console matching the earlycon specified
 *	in the param string @buf. Acceptable param strings are of the form
 *	   <name>,io|mmio|mmio32|mmio32be,<addr>,<options>
 *	   <name>,0x<addr>,<options>
 *	   <name>,<options>
 *	   <name>
 *
 *	Only for the third form does the earlycon setup() method receive the
 *	<options> string in the 'options' parameter; all other forms set
 *	the parameter to NULL.

That part about the 3rd form doesn't seem to be true. I don't see where
options gets set to NULL for forms other than the third.

> 
> I am pondering some more currently. If it's X-Gene specific, let's add
> that to the quirk (and to perhaps a more APM specific SPCR subtype).
> 
> Jon.
>