.../devicetree/bindings/nvmem/brcm,nvram.yaml | 25 +++++++++++++++-- .../devicetree/bindings/nvmem/nvmem.yaml | 3 --- drivers/nvmem/core.c | 27 +++++++++++++++++++ 3 files changed, 50 insertions(+), 5 deletions(-)
From: Rafał Miłecki <rafal@milecki.pl>
These changes will allow me to improve BCM5301X support with:
diff --git a/arch/arm/boot/dts/bcm47094-luxul-xwr-3150-v1.dts b/arch/arm/boot/dts/bcm47094-luxul-xwr-3150-v1.dts
index 24ae3c8a3..9efcb2424 100644
--- a/arch/arm/boot/dts/bcm47094-luxul-xwr-3150-v1.dts
+++ b/arch/arm/boot/dts/bcm47094-luxul-xwr-3150-v1.dts
@@ -25,6 +25,9 @@ memory@0 {
nvram@1eff0000 {
compatible = "brcm,nvram";
reg = <0x1eff0000 0x10000>;
+
+ et0macaddr: et0macaddr {
+ };
};
leds {
@@ -72,6 +75,11 @@ restart {
};
};
+&gmac0 {
+ nvmem-cells = <&et0macaddr>;
+ nvmem-cell-names = "mac-address";
+};
+
&usb3 {
vcc-gpio = <&chipcommon 18 GPIO_ACTIVE_HIGH>;
};
Rafał Miłecki (3):
dt-bindings: nvmem: make "reg" property optional
dt-bindings: nvmem: brcm,nvram: add basic NVMEM cells
nvmem: core: add cell name based matching of DT cell nodes
.../devicetree/bindings/nvmem/brcm,nvram.yaml | 25 +++++++++++++++--
.../devicetree/bindings/nvmem/nvmem.yaml | 3 ---
drivers/nvmem/core.c | 27 +++++++++++++++++++
3 files changed, 50 insertions(+), 5 deletions(-)
--
2.34.1
From: Rafał Miłecki <rafal@milecki.pl>
Most NVMEM providers have cells at hardcoded addresses however there are
some exceptions. Some devices store cells layout in internal structs
using custom formats.
It's important to allow NVMEM consumers to still reference such NVMEM
cells. Making "reg" optional allows defining NVMEM cells by their names
only and using them with phandles.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/nvmem/nvmem.yaml | 3 ---
1 file changed, 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/nvmem/nvmem.yaml b/Documentation/devicetree/bindings/nvmem/nvmem.yaml
index 43ed7e32e5ac..3bb349c634cb 100644
--- a/Documentation/devicetree/bindings/nvmem/nvmem.yaml
+++ b/Documentation/devicetree/bindings/nvmem/nvmem.yaml
@@ -60,9 +60,6 @@ patternProperties:
description:
Size in bit within the address range specified by reg.
- required:
- - reg
-
additionalProperties: true
examples:
--
2.34.1
On 18/02/2022 07:07, Rafał Miłecki wrote: > From: Rafał Miłecki <rafal@milecki.pl> > > Most NVMEM providers have cells at hardcoded addresses however there are > some exceptions. Some devices store cells layout in internal structs > using custom formats. > > It's important to allow NVMEM consumers to still reference such NVMEM > cells. Making "reg" optional allows defining NVMEM cells by their names > only and using them with phandles. > > Signed-off-by: Rafał Miłecki <rafal@milecki.pl> > Reviewed-by: Rob Herring <robh@kernel.org> Applied thanks, --srini > --- > Documentation/devicetree/bindings/nvmem/nvmem.yaml | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/Documentation/devicetree/bindings/nvmem/nvmem.yaml b/Documentation/devicetree/bindings/nvmem/nvmem.yaml > index 43ed7e32e5ac..3bb349c634cb 100644 > --- a/Documentation/devicetree/bindings/nvmem/nvmem.yaml > +++ b/Documentation/devicetree/bindings/nvmem/nvmem.yaml > @@ -60,9 +60,6 @@ patternProperties: > description: > Size in bit within the address range specified by reg. > > - required: > - - reg > - > additionalProperties: true > > examples:
From: Rafał Miłecki <rafal@milecki.pl>
NVRAM doesn't have cells at hardcoded addresses. They are stored in
internal struct (custom & dynamic format). It's still important to
define relevant cells in DT so NVMEM consumers can reference them.
Update binding to allow including basic cells as NVMEM device subnodes.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
---
V2: Add children nodes description per Rob's request
V3: Document NVMEM cells as properties
---
.../devicetree/bindings/nvmem/brcm,nvram.yaml | 25 +++++++++++++++++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/nvmem/brcm,nvram.yaml b/Documentation/devicetree/bindings/nvmem/brcm,nvram.yaml
index 8c3f0cd22821..25033de3ef6b 100644
--- a/Documentation/devicetree/bindings/nvmem/brcm,nvram.yaml
+++ b/Documentation/devicetree/bindings/nvmem/brcm,nvram.yaml
@@ -14,6 +14,8 @@ description: |
NVRAM can be accessed on Broadcom BCM47xx MIPS and Northstar ARM Cortex-A9
devices usiong I/O mapped memory.
+ NVRAM variables can be defined as NVMEM device subnodes.
+
maintainers:
- Rafał Miłecki <rafal@milecki.pl>
@@ -27,11 +29,30 @@ properties:
reg:
maxItems: 1
+ board_id:
+ type: object
+ description: Board identification name
+
+ et0macaddr:
+ type: object
+ description: First Ethernet interface's MAC address
+
+ et1macaddr:
+ type: object
+ description: Second Ethernet interface's MAC address
+
+ et2macaddr:
+ type: object
+ description: Third Ethernet interface's MAC address
+
unevaluatedProperties: false
examples:
- |
nvram@1eff0000 {
- compatible = "brcm,nvram";
- reg = <0x1eff0000 0x10000>;
+ compatible = "brcm,nvram";
+ reg = <0x1eff0000 0x10000>;
+
+ mac: et0macaddr {
+ };
};
--
2.34.1
On Fri, 18 Feb 2022 08:07:28 +0100, Rafał Miłecki wrote: > From: Rafał Miłecki <rafal@milecki.pl> > > NVRAM doesn't have cells at hardcoded addresses. They are stored in > internal struct (custom & dynamic format). It's still important to > define relevant cells in DT so NVMEM consumers can reference them. > > Update binding to allow including basic cells as NVMEM device subnodes. > > Signed-off-by: Rafał Miłecki <rafal@milecki.pl> > --- > V2: Add children nodes description per Rob's request > V3: Document NVMEM cells as properties > --- > .../devicetree/bindings/nvmem/brcm,nvram.yaml | 25 +++++++++++++++++-- > 1 file changed, 23 insertions(+), 2 deletions(-) > Reviewed-by: Rob Herring <robh@kernel.org>
On 18/02/2022 07:07, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> NVRAM doesn't have cells at hardcoded addresses. They are stored in
> internal struct (custom & dynamic format). It's still important to
> define relevant cells in DT so NVMEM consumers can reference them.
>
> Update binding to allow including basic cells as NVMEM device subnodes.
>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Applied thanks,
--srini
> ---
> V2: Add children nodes description per Rob's request
> V3: Document NVMEM cells as properties
> ---
> .../devicetree/bindings/nvmem/brcm,nvram.yaml | 25 +++++++++++++++++--
> 1 file changed, 23 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/nvmem/brcm,nvram.yaml b/Documentation/devicetree/bindings/nvmem/brcm,nvram.yaml
> index 8c3f0cd22821..25033de3ef6b 100644
> --- a/Documentation/devicetree/bindings/nvmem/brcm,nvram.yaml
> +++ b/Documentation/devicetree/bindings/nvmem/brcm,nvram.yaml
> @@ -14,6 +14,8 @@ description: |
> NVRAM can be accessed on Broadcom BCM47xx MIPS and Northstar ARM Cortex-A9
> devices usiong I/O mapped memory.
>
> + NVRAM variables can be defined as NVMEM device subnodes.
> +
> maintainers:
> - Rafał Miłecki <rafal@milecki.pl>
>
> @@ -27,11 +29,30 @@ properties:
> reg:
> maxItems: 1
>
> + board_id:
> + type: object
> + description: Board identification name
> +
> + et0macaddr:
> + type: object
> + description: First Ethernet interface's MAC address
> +
> + et1macaddr:
> + type: object
> + description: Second Ethernet interface's MAC address
> +
> + et2macaddr:
> + type: object
> + description: Third Ethernet interface's MAC address
> +
> unevaluatedProperties: false
>
> examples:
> - |
> nvram@1eff0000 {
> - compatible = "brcm,nvram";
> - reg = <0x1eff0000 0x10000>;
> + compatible = "brcm,nvram";
> + reg = <0x1eff0000 0x10000>;
> +
> + mac: et0macaddr {
> + };
> };
From: Rafał Miłecki <rafal@milecki.pl>
When adding NVMEM cells defined by driver it's important to match them
with DT nodes that specify matching names. That way other bindings &
drivers can reference such "dynamic" NVMEM cells.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
---
drivers/nvmem/core.c | 27 +++++++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index 53a43d843743..a891449c52f1 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -499,6 +499,31 @@ static int nvmem_cell_info_to_nvmem_cell_entry(struct nvmem_device *nvmem,
return 0;
}
+/**
+ * nvmem_find_cell_of_node() - Find DT node matching nvmem cell
+ *
+ * @nvmem: nvmem provider
+ * @name: nvmem cell name
+ *
+ * Runtime created nvmem cells (those not coming from DT) may still need to be
+ * referenced in DT. This function allows finding DT node referencing nvmem cell
+ * by its name. Such a DT node can be then used by nvmem consumers.
+ *
+ * Return: NULL or pointer to DT node
+ */
+static struct device_node *nvmem_find_cell_of_node(struct nvmem_device *nvmem,
+ const char *name)
+{
+ struct device_node *child;
+
+ for_each_child_of_node(nvmem->dev.of_node, child) {
+ if (!strcmp(child->name, name))
+ return child;
+ }
+
+ return NULL;
+}
+
/**
* nvmem_add_cells() - Add cell information to an nvmem device
*
@@ -532,6 +557,8 @@ static int nvmem_add_cells(struct nvmem_device *nvmem,
goto err;
}
+ cells[i]->np = nvmem_find_cell_of_node(nvmem, cells[i]->name);
+
nvmem_cell_entry_add(cells[i]);
}
--
2.34.1
Hi Rafał
On 18/02/2022 07:07, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> When adding NVMEM cells defined by driver it's important to match them
> with DT nodes that specify matching names. That way other bindings &
> drivers can reference such "dynamic" NVMEM cells.
>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> ---
> drivers/nvmem/core.c | 27 +++++++++++++++++++++++++++
> 1 file changed, 27 insertions(+)
>
> diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
> index 53a43d843743..a891449c52f1 100644
> --- a/drivers/nvmem/core.c
> +++ b/drivers/nvmem/core.c
> @@ -499,6 +499,31 @@ static int nvmem_cell_info_to_nvmem_cell_entry(struct nvmem_device *nvmem,
> return 0;
> }
>
> +/**
> + * nvmem_find_cell_of_node() - Find DT node matching nvmem cell
> + *
> + * @nvmem: nvmem provider
> + * @name: nvmem cell name
> + *
> + * Runtime created nvmem cells (those not coming from DT) may still need to be
> + * referenced in DT. This function allows finding DT node referencing nvmem cell
> + * by its name. Such a DT node can be then used by nvmem consumers.
> + *
> + * Return: NULL or pointer to DT node
> + */
> +static struct device_node *nvmem_find_cell_of_node(struct nvmem_device *nvmem,
> + const char *name)
> +{
> + struct device_node *child;
> +
> + for_each_child_of_node(nvmem->dev.of_node, child) {
> + if (!strcmp(child->name, name))
> + return child;
> + }
Isn't this just
return of_get_child_by_name(nvmem->dev.of_node, name);
> +
> + return NULL;
> +}
> +
> /**
> * nvmem_add_cells() - Add cell information to an nvmem device
> *
> @@ -532,6 +557,8 @@ static int nvmem_add_cells(struct nvmem_device *nvmem,
> goto err;
> }
>
> + cells[i]->np = nvmem_find_cell_of_node(nvmem, cells[i]->name);
This is really assuming that node name will be same as name passed in
nvmem_cell_info which might not be always true.
This seems be very specific with brcm and this code does not belong in
nvmem core.
How about adding device_node to struct nvmem_cell_info and update this
of_node as part of brcm_nvram_parse()?
--srini
> +
> nvmem_cell_entry_add(cells[i]);
> }
>
© 2016 - 2026 Red Hat, Inc.