linux-kernel - Re: [PATCH] of: support passing console options with stdout-path

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:	Tue, 25 Nov 2014 14:44:39 +0000
From:	Grant Likely <grant.likely@...aro.org>
To:	Andrew Lunn <andrew@...n.ch>,
	Leif Lindholm <leif.lindholm@...aro.org>
Cc:	devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org, mark.rutland@....com,
	robh+dt@...nel.org, plagnioj@...osoft.com, ijc@...ian.org
Subject: Re: [PATCH] of: support passing console options with stdout-path

On Tue, 25 Nov 2014 00:00:16 +0100
, Andrew Lunn <andrew@...n.ch>
 wrote:
> On Mon, Nov 24, 2014 at 10:23:58PM +0000, Leif Lindholm wrote:
> > Support specifying console options (like with console=ttyXN,<options>)
> > by appending them to the stdout-path property after a separating ':'.
> > 
> > Example:
> > 	stdout-path = "uart0:115200";
> > 
> > This patch also modifies of_find_node_by_path() to match only the
> > portion of the path before a ':'.
> 
> Hi Leif
> 
> These appears to somewhat conform to ePAPR, which says:
> 
>       A string that specifies the full path to the node representing
>       the device to be used for boot console output. If the character
>       ":" is present in the value it terminates the path.
> 
> So you can put any random junk after the :. However, are we going to
> have backward/forward compatibility problems, and problems with
> bootloaders? The current kernel code does not look for the :. So a new
> DT blob on an old kernel will not work so well.

For DT, we've generally not been worrying about compatibility in that
direction.  If we've got a new firmware, we should be able to get a new
kernel.  Nobody has really screamed bout it yet.

> More worrying, barebox does not support the : either. So there is a
> danger your bootloader suddenly goes silent after a dt blob update.

Is barebox parsing the property? Or updating it? Or both? I've got no
problem with this patch, but we can also support things like the
'current-speed' property in the UART to set a default when the stdout
path doesn't have any arguments.

g.
--
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/