mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Christian Eggers <ceggers@arri.de>
To: barebox@lists.infradead.org
Cc: Ahmad Fatoum <a.fatoum@pengutronix.de>
Subject: Re: state framework, fixed-partitions, eeprom and linux
Date: Tue, 4 Feb 2020 14:06:00 +0100	[thread overview]
Message-ID: <21090636.oFDgJnQYPg@n95hx1g2> (raw)
In-Reply-To: <07ba5178-786b-d4c2-16c7-68102ca41462@pengutronix.de>

Dear Ahmad,

Am Montag, 3. Februar 2020, 18:47:29 CET schrieb Ahmad Fatoum:
> Fortunately, I was mistaken. The upstream bindings says that only objects
> matching "^.*@[0-9a-f]+$" should be considered for nvmem cells. a partitions
> node doesn't match this. So I'd instead suggest this:
> 
>     nvmem: core: don't consider subnodes not matching binding
> 
>     The nvmem cell binding applies to objects which match "^.*@[0-9a-f]+$",
>     but so far the driver has matched all objects and failed if they didn't
>     have the expected properties.
> 
>     The driver's behavior in this regard precludes future extension of
>     EEPROMs by child nodes other than nvmem and clashes with the barebox
>     bootloader binding that extends the fixed-partitions MTD binding to
>     EEPROMs.
> 
>     Solve this issue by checking whether the node name contains a @.
>     This still matches against node names like partitions@0,0, but this is
>     much less likely to cause future collisions.
> 
>     Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
> 

I have a different approach, taken from the Linux MTD sources. Here the DT partitions are added as NVMEM cells. Is there any conceptual difference between "MTD partitions" and "NVMEM cells"? 

Are you able to bring one/both patches into Linux?

Regards
Christian

From 927f3aa9c4a64802f25ef2f292caa1dc951ce667 Mon Sep 17 00:00:00 2001
From: Christian Eggers <ceggers@arri.de>
Date: Tue, 4 Feb 2020 13:52:36 +0100
Subject: [PATCH] nvmem: core: Move OF cells to a dedicated dt node

In 5cfdedb7b9 ("mtd: ofpart: move ofpart partitions to a dedicated dt
node"), mtd introduced the separate "partitions" node as container for
the partitions of a MTD device.

This commit applies a similar behavior to NVMEM partitions/cells.

Signed-off-by: Christian Eggers <ceggers@arri.de>
---
 drivers/nvmem/core.c | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index 057d1ff87d5d..3e93b82b96bd 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -287,7 +287,7 @@ nvmem_find_cell_by_name(struct nvmem_device *nvmem, const char *cell_id)
 
 static int nvmem_add_cells_from_of(struct nvmem_device *nvmem)
 {
-	struct device_node *parent, *child;
+	struct device_node *parent, *child, *ofpart_node;
 	struct device *dev = &nvmem->dev;
 	struct nvmem_cell *cell;
 	const __be32 *addr;
@@ -295,7 +295,16 @@ static int nvmem_add_cells_from_of(struct nvmem_device *nvmem)
 
 	parent = dev->of_node;
 
-	for_each_child_of_node(parent, child) {
+	ofpart_node = of_get_child_by_name(parent, "partitions");
+	if (!ofpart_node) {
+		/* Try to parse direct subnodes */
+		ofpart_node = parent;
+	} else if (!of_device_is_compatible(ofpart_node, "fixed-partitions")) {
+		/* The 'partitions' subnode might be used by another parser */
+		return 0;
+	}
+
+	for_each_child_of_node(ofpart_node, child) {
 		addr = of_get_property(child, "reg", &len);
 		if (!addr || (len < 2 * sizeof(u32))) {
 			dev_err(dev, "nvmem: invalid reg on %pOF\n", child);
-- 
Christian Eggers
Embedded software developer

Arnold & Richter Cine Technik GmbH & Co. Betriebs KG
Sitz: Muenchen - Registergericht: Amtsgericht Muenchen - Handelsregisternummer: HRA 57918
Persoenlich haftender Gesellschafter: Arnold & Richter Cine Technik GmbH
Sitz: Muenchen - Registergericht: Amtsgericht Muenchen - Handelsregisternummer: HRB 54477
Geschaeftsfuehrer: Dr. Michael Neuhaeuser; Stephan Schenk; Walter Trauninger; Markus Zeiler







_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

  reply	other threads:[~2020-02-04 13:06 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-03 12:12 Christian Eggers
2020-02-03 17:17 ` Ahmad Fatoum
2020-02-03 17:47   ` Ahmad Fatoum
2020-02-04 13:06     ` Christian Eggers [this message]
2020-02-04 13:45       ` Ahmad Fatoum
2021-03-05 20:35       ` Ahmad Fatoum

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=21090636.oFDgJnQYPg@n95hx1g2 \
    --to=ceggers@arri.de \
    --cc=a.fatoum@pengutronix.de \
    --cc=barebox@lists.infradead.org \
    /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