linux-kernel - Re: Boot failures in -next due to 'ARM: dts: imx: Remove skeleton.dtsi'

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: <20161117150551.GA21742@leverpostej>
Date:   Thu, 17 Nov 2016 15:05:51 +0000
From:   Mark Rutland <mark.rutland@....com>
To:     Guenter Roeck <linux@...ck-us.net>
Cc:     Fabio Estevam <festevam@...il.com>,
        Fabio Estevam <fabio.estevam@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: Boot failures in -next due to 'ARM: dts: imx: Remove
 skeleton.dtsi'

On Thu, Nov 17, 2016 at 06:44:55AM -0800, Guenter Roeck wrote:
> On 11/17/2016 02:55 AM, Mark Rutland wrote:
> >On Wed, Nov 16, 2016 at 02:40:24PM -0800, Guenter Roeck wrote:
> >>On Wed, Nov 16, 2016 at 08:27:09PM -0200, Fabio Estevam wrote:
> >>>Hi Guenter,
> >>>
> >>>On Wed, Nov 16, 2016 at 8:10 PM, Guenter Roeck <linux@...ck-us.net> wrote:
> >>>>
> >>>>Anyway, I guess the problem is that the "official" dtb files no longer provide
> >>>>the skeleton /chosen and /memory nodes (and maybe others), and qemu seems to
> >>>>expect that they are provided. Is that correct ?
> >>>
> >>>imx6qdl-sabrelite.dtsi provides chosen and memory nodes.
> >>
> >>Yes, but not the 'device_type' property, which the kernel seems to expect.
> >
> >Memory nodes require this property per ePAPR and the devicetree.org
> >spec, so the bug is that we didn't add those when removing the
> >skeleton.dtsi include.
> 
> The downside from qemu perspective is that the real hardware seems
> to add the property unconditionally, or the boot failure would have
> been seen there as well.
> 
> I submitted https://patchwork.ozlabs.org/patch/695951/; we'll see how it goes.

Sure, the firmare/bootlaoder you're using may add this automatically.

My worry is that adding this to a generic file in QEMU only serves to
mask this class of bug for other boards (i.e. they'll work fine in QEMU,
but not on real HW using whatever bootlaoder happens ot be there).

Thanks,
Mark.