From: "Clément Leger" <cleger@kalrayinc.com>
To: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Barebox List <barebox@lists.infradead.org>
Subject: Re: [PATCH 1/2] of: base: parse all available memory nodes
Date: Mon, 23 Mar 2020 11:21:09 +0100 (CET) [thread overview]
Message-ID: <1211869674.11432033.1584958869528.JavaMail.zimbra@kalray.eu> (raw)
In-Reply-To: <20200323101246.GQ3335@pengutronix.de>
Hi Sascha,
----- On 23 Mar, 2020, at 11:12, Sascha Hauer s.hauer@pengutronix.de wrote:
> On Mon, Mar 16, 2020 at 12:00:07PM +0100, Clement Leger wrote:
>> Currently, barebox only parse one memory node which is either the
>> "/memory" node or the first node with device_type == "memory".
>> However, the use of multiple memory nodes with device_type = "memory"
>> property is allowed by the device tree specification and already
>> correctly parsed by Linux kernel.
>> In order to fix that, add of_probe_memory function which loop over all
>> available memory nodes. In order to try to keep existing legacy search
>> based on "memory" node name, try to find this node and add it. If the
>> memory node contains the device_type property, then it will only be
>> added once.
>>
>> Signed-off-by: Clement Leger <cleger@kalray.eu>
>> ---
>> drivers/of/base.c | 31 +++++++++++++++++++++++++------
>> 1 file changed, 25 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/of/base.c b/drivers/of/base.c
>> index 9ede05227..b1a96ee8f 100644
>> --- a/drivers/of/base.c
>> +++ b/drivers/of/base.c
>> @@ -2061,9 +2061,32 @@ const struct of_device_id of_default_bus_match_table[] =
>> {
>> }
>> };
>>
>> +static void of_probe_memory(void)
>> +{
>> + struct device_node *memory = root_node, *legacy_memory;
>> +
>> + /* Parse node based on name (for legacy dt) */
>> + legacy_memory = of_find_node_by_path("/memory");
>> + if (legacy_memory)
>> + of_add_memory(legacy_memory, false);
>> +
>> + /* Then, parse all available node with "memory" device_type */
>> + while (1) {
>> + memory = of_find_node_by_type(memory, "memory");
>> + if (!memory)
>> + break;
>> +
>> + /* Skip potentially already added legacy memory node */
>> + if (memory == legacy_memory)
>> + continue;
>> +
>> + of_add_memory(memory, false);
>> + }
>
> 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.
However, I agree that since the device_type = "memory" property should
have always been there, there is no reason to keep this behavior.
If you are ok with that, I will remove this chunk of code.
>
> 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-03-23 10:21 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 [this message]
2020-03-23 10:31 ` Ahmad Fatoum
2020-03-25 9:29 ` Sascha Hauer
2020-06-18 10:16 ` Ahmad Fatoum
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=1211869674.11432033.1584958869528.JavaMail.zimbra@kalray.eu \
--to=cleger@kalrayinc.com \
--cc=barebox@lists.infradead.org \
--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