From: Ahmad Fatoum <a.fatoum@pengutronix.de>
To: Sascha Hauer <s.hauer@pengutronix.de>
Cc: "Clément Leger" <cleger@kalrayinc.com>,
"Barebox List" <barebox@lists.infradead.org>
Subject: Re: [PATCH 1/2] of: base: parse all available memory nodes
Date: Thu, 18 Jun 2020 12:16:13 +0200 [thread overview]
Message-ID: <980eb1d7-fc8a-4602-aecd-a61d8c78327c@pengutronix.de> (raw)
In-Reply-To: <20200325092958.GC27288@pengutronix.de>
On 3/25/20 10:29 AM, Sascha Hauer wrote:
> On Mon, Mar 23, 2020 at 11:31:26AM +0100, Ahmad Fatoum wrote:
>> Hi,
>>
>> On 3/23/20 11:21 AM, Clément Leger wrote:
>>>> AFAIK the device_type = "memory" property was mandatory in the early
>>>> days as well, there shouldn't be any /memory nodes without this
>>>> property. Given that, is the add-legacy-node-first still necessary?
>>>
>>> Agreed, I did that after speaking with someone on IRC which stated
>>> (rightfully), that I should keep the legacy behavior if possible.
>>
>> My concern was about HW that passes a device tree to barebox (PowerPC
>> possibly?), where it might have worked before and now won't anymore.
>>
>> If this is no real concern, it can be removed.
>
> There is no PowerPC hardware supported by barebox that passes a device
> tree to barebox. I don't think this is necessary.
Turns out we had quite a few device trees that lacked a device_type = "memory"
property: https://lists.infradead.org/pipermail/barebox/2020-June/042269.html
The property used to be there, but when upstream removed skeleton.dtsi and
either there was no upstream memory node to extend or it was renamed, we
ended up with an invalid memory node.
>
> Sascha
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
next prev parent reply other threads:[~2020-06-18 10:16 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-16 11:00 [PATCH 0/2] Allow parsing more than one memory node Clement Leger
2020-03-16 11:00 ` [PATCH 1/2] of: base: parse all available memory nodes Clement Leger
2020-03-23 10:12 ` Sascha Hauer
2020-03-23 10:21 ` Clément Leger
2020-03-23 10:31 ` Ahmad Fatoum
2020-03-25 9:29 ` Sascha Hauer
2020-06-18 10:16 ` Ahmad Fatoum [this message]
2020-03-16 11:00 ` [PATCH 2/2] of: base: allow of_add_memory to be called multiple times Clement Leger
2020-03-25 17:27 ` [PATCH v2 0/2] Allow parsing more than one memory node Clement Leger
2020-03-25 17:27 ` [PATCH v2 1/2] of: base: allow of_add_memory to be called multiple times Clement Leger
2020-03-25 17:27 ` [PATCH v2 2/2] of: base: parse all available memory nodes Clement Leger
2020-03-30 5:31 ` [PATCH v2 0/2] Allow parsing more than one memory node Sascha Hauer
2020-03-17 7:35 ` [PATCH " Sam Ravnborg
2020-03-17 8:19 ` Clément Leger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=980eb1d7-fc8a-4602-aecd-a61d8c78327c@pengutronix.de \
--to=a.fatoum@pengutronix.de \
--cc=barebox@lists.infradead.org \
--cc=cleger@kalrayinc.com \
--cc=s.hauer@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox