From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1754789AbcKQRXb (ORCPT <rfc822;w@1wt.eu>);
        Thu, 17 Nov 2016 12:23:31 -0500
Received: from bh-25.webhostbox.net ([208.91.199.152]:59263 "EHLO
        bh-25.webhostbox.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1754824AbcKQRXF (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 17 Nov 2016 12:23:05 -0500
Subject: Re: Boot failures in -next due to 'ARM: dts: imx: Remove
 skeleton.dtsi'
To: Mark Rutland <mark.rutland@arm.com>
References: <cda2df55-f2f3-00d6-c6b1-816ed47bbf56@roeck-us.net>
 <20161116184649.GF11228@leverpostej> <20161116221002.GA19925@roeck-us.net>
 <CAOMZO5Bd2X3pVqExBtBw_uHReDDkf6J2VdMXnAXynCAHxoX60A@mail.gmail.com>
 <20161116224024.GA11821@roeck-us.net> <20161117105513.GA12273@leverpostej>
 <198d764e-1612-81b4-5f4e-0c221a23c8e0@roeck-us.net>
 <20161117150551.GA21742@leverpostej>
 <2eaf84f9-ea00-d331-1875-56adafb62378@roeck-us.net>
 <20161117163906.GB21742@leverpostej>
Cc: Fabio Estevam <festevam@gmail.com>,
        Fabio Estevam <fabio.estevam@nxp.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-arm-kernel@lists.infradead.org" 
        <linux-arm-kernel@lists.infradead.org>
From: Guenter Roeck <linux@roeck-us.net>
Message-ID: <9313c664-e8e8-1fa9-2d64-5abe19e54ecc@roeck-us.net>
Date: Thu, 17 Nov 2016 09:23:01 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <20161117163906.GB21742@leverpostej>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Authenticated_sender: linux@roeck-us.net
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - bh-25.webhostbox.net
X-AntiAbuse: Original Domain - vger.kernel.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - roeck-us.net
X-Get-Message-Sender-Via: bh-25.webhostbox.net: authenticated_id: linux@roeck-us.net
X-Authenticated-Sender: bh-25.webhostbox.net: linux@roeck-us.net
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 11/17/2016 08:39 AM, Mark Rutland wrote:
> On Thu, Nov 17, 2016 at 08:17:00AM -0800, Guenter Roeck wrote:
>> On 11/17/2016 07:05 AM, Mark Rutland wrote:
>>> On Thu, Nov 17, 2016 at 06:44:55AM -0800, Guenter Roeck wrote:
>>>> On 11/17/2016 02:55 AM, Mark Rutland wrote:
>>>>> 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).
>>>
>> Good point.
>>
>> What would be the correct behavior for qemu ? Adding a chosen node if it does
>> not exist is one detail we already established. Also, I think a check if
>> /memory/device_type exists (and to bail out if it doesn't) would make sense.
>
> We'd also need to check for /memory@<n> nodes, as they can validly have
> unit-addresses (and many do).
>
> Generally, the "correct" way to find them is to iterate over all ndoes
> with device_type = "memory", so one could do that and give up if none
> are found, ignoring the naming entirely.
>
>> What about the memory node ? Does it have to exist, or should it be added
>> (including the device_type property) if not ?
>
> I'm not sure what QEMU does in this area. I suspect it may expect a node
> in some cases, or may generate one in others.
>
> There's no point generating one when we don't have the information to
> hand, certainly.
>
So far, for arm, qemu assumes that the /memory node exists, and it fills in
/memory/reg. This is done if a devicetree file is specified and numa is disabled.

Numa node handling is different; if NUMA is enabled, qemu removes an existing
/memory node and creates /memory@ nodes as configured. It does not expect
to see pre-existing /memory@ nodes.

Thanks,
Guenter

From mboxrd@z Thu Jan  1 00:00:00 1970
From: linux@roeck-us.net (Guenter Roeck)
Date: Thu, 17 Nov 2016 09:23:01 -0800
Subject: Boot failures in -next due to 'ARM: dts: imx: Remove
 skeleton.dtsi'
In-Reply-To: <20161117163906.GB21742@leverpostej>
References: <cda2df55-f2f3-00d6-c6b1-816ed47bbf56@roeck-us.net>
 <20161116184649.GF11228@leverpostej> <20161116221002.GA19925@roeck-us.net>
 <CAOMZO5Bd2X3pVqExBtBw_uHReDDkf6J2VdMXnAXynCAHxoX60A@mail.gmail.com>
 <20161116224024.GA11821@roeck-us.net> <20161117105513.GA12273@leverpostej>
 <198d764e-1612-81b4-5f4e-0c221a23c8e0@roeck-us.net>
 <20161117150551.GA21742@leverpostej>
 <2eaf84f9-ea00-d331-1875-56adafb62378@roeck-us.net>
 <20161117163906.GB21742@leverpostej>
Message-ID: <9313c664-e8e8-1fa9-2d64-5abe19e54ecc@roeck-us.net>
To: linux-arm-kernel@lists.infradead.org
List-Id: linux-arm-kernel.lists.infradead.org

On 11/17/2016 08:39 AM, Mark Rutland wrote:
> On Thu, Nov 17, 2016 at 08:17:00AM -0800, Guenter Roeck wrote:
>> On 11/17/2016 07:05 AM, Mark Rutland wrote:
>>> On Thu, Nov 17, 2016 at 06:44:55AM -0800, Guenter Roeck wrote:
>>>> On 11/17/2016 02:55 AM, Mark Rutland wrote:
>>>>> 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).
>>>
>> Good point.
>>
>> What would be the correct behavior for qemu ? Adding a chosen node if it does
>> not exist is one detail we already established. Also, I think a check if
>> /memory/device_type exists (and to bail out if it doesn't) would make sense.
>
> We'd also need to check for /memory@<n> nodes, as they can validly have
> unit-addresses (and many do).
>
> Generally, the "correct" way to find them is to iterate over all ndoes
> with device_type = "memory", so one could do that and give up if none
> are found, ignoring the naming entirely.
>
>> What about the memory node ? Does it have to exist, or should it be added
>> (including the device_type property) if not ?
>
> I'm not sure what QEMU does in this area. I suspect it may expect a node
> in some cases, or may generate one in others.
>
> There's no point generating one when we don't have the information to
> hand, certainly.
>
So far, for arm, qemu assumes that the /memory node exists, and it fills in
/memory/reg. This is done if a devicetree file is specified and numa is disabled.

Numa node handling is different; if NUMA is enabled, qemu removes an existing
/memory node and creates /memory@ nodes as configured. It does not expect
to see pre-existing /memory@ nodes.

Thanks,
Guenter