linux-kernel - Re: [RFC PATCH] always probe UART HW when options are not specified

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]

Message-ID: <5693ECBA.50003@laposte.net>
Date:	Mon, 11 Jan 2016 18:56:10 +0100
From:	Sebastian Frias <sf84@...oste.net>
To:	Peter Hurley <peter@...leysoftware.com>
CC:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	linux-serial@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
	mason <slash.tmp@...e.fr>,
	Måns Rullgård <mans@...sr.com>
Subject: Re: [RFC PATCH] always probe UART HW when options are not specified

Hi Peter,

On 01/11/2016 05:11 PM, Peter Hurley wrote:
> On 01/11/2016 07:07 AM, Sebastian Frias wrote:
>> On 12/22/2015 06:56 PM, Sebastian Frias wrote:
>>>
>>>       OF_EARLYCON_DECLARE(rt2880, "ralink,rt2880-uart",
>>> early_serial8250_setup);
>
> There is no support for this uart in 8250 earlycon; the registers
> need remapped.

Ok, two questions then:
1) If the UART is not supported on 8250 earlycon, what is the 
suggested/advised solution? Using just "earlyprintk"?
2) What would it take to make the "rt2880" work with the 8250 earlycon? 
I mean, it is already pretty much supported in there, what would be 
missing? (I don't see why it blocks on earlycon_map) And would it be 
worth doing?

>
>>> at the end of the file, trying to mimic commit
>>> d05f15707bb7659d2b863fafa1a918f286d74a63
>>>
>>> I'm still trying to figure out the right bootargs, so that's why both
>>> "earlycon" and "console" are there. Suggestions welcome.
>
> Just 'earlycon' triggers the attempted registration of earlycon matching the
> compatible string of the stdout-path node.
>
> The empty 'console' in bootargs is doing nothing.

Ok, thanks.

So, just to recap.
We would like to understand what is the right way of doing this:

- we are using 8250 (rt288x variant) UART: CONFIG_SERIAL_8250_RT288X=y
- the UART hardware is setup prior to Linux boot
- we don't want Linux to change the UART settings, just to pick up 
whatever settings the UART has and take over the UART.

There were two replies to that, one by Greg Kroah-Hartman 
(http://www.spinics.net/lists/linux-serial/msg20278.html) and one by 
you, where you suggested we use "console=uart", but as I reported 
(http://www.spinics.net/lists/linux-serial/msg20307.html) it does not 
work, you replied that iotype and mmio are not optional but mandatory 
(http://www.spinics.net/lists/linux-serial/msg20310.html), and I 
wondered if it was really necessary to duplicate data that is already on 
the DT among other questions 
(http://www.spinics.net/lists/linux-serial/msg20383.html), like how are 
DT described drivers supposed to interact with the 
"console="/"earlycon=" commandlines, or, the contradiction between 
"console=ttyS0" means '9600n81' and "if unspecified [the uart options], 
the h/w is not re-initialized"

So, for us, it is still not clear what is the recommended way of 
achieving our goal above, and it seems it is not clear what does 
"console=ttyS0" is supposed to do, hardcode ('9600n81') or probe ('the 
h/w is not re-initialized')
Any help will be appreciated.

Thanks, best regards,

Sebastian