linux-kernel - Re: [RFC 1/5] of: Add support for ePAPR "stdout-path" property

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:	Fri, 28 Mar 2014 16:56:28 -0500
From:	Rob Herring <robherring2@...il.com>
To:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc:	Grant Likely <grant.likely@...aro.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Christoffer Dall <christoffer.dall@...aro.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Olof Johansson <olof@...om.net>,
	Rob Herring <rob.herring@...aro.org>
Subject: Re: [RFC 1/5] of: Add support for ePAPR "stdout-path" property

On Fri, Mar 28, 2014 at 4:33 PM, Benjamin Herrenschmidt
<benh@...nel.crashing.org> wrote:
> On Fri, 2014-03-28 at 09:08 -0700, Grant Likely wrote:
>> ePAPR 1.1 defines the "stdout-path" property for specifying the console
>> device, but Linux currently only handles the older "linux,stdout-path"
>> property. This patch adds parsing for the new property name.
>
> Generally a good idea I think, but of course I need time to review and
> test ... :-)
>
> One thing that's been annoying me lately with the existing code which
> you don't address is ... in a few cases my consoles are usable *VERY*
> early. For example PAPR hvc and OPAL hvc can be used before we even turn
> the MMU on on powerpc (and thus before we unflatten the device-tree).
>
> It would be nice to be able to have the console going that early,
> unfortunately that would imply using the flat device-tree for the
> parsing / matching of the stdout-path in those drivers.

I'm working on getting just that working. See my series for "generic
earlycon". I'm working on cleaning up the FDT part still, but have
something functional. The "hardest" part with FDT is doing the address
translation for serial devices, but I just stole that from u-boot.

> Right now, I have this explicit config option to hard wire "early debug"
> but there are a few cases of field bugs that can happen in early init
> code which I'd like to see logged properly on those systems, and early
> debug isn't suitable for field use...

We have the same issue with multi-platform ARM kernels.

Rob
--
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/