diff mbox series

[3/5] dt-bindings: nvmem: allow referencing device defined cells by names

Message ID 20211223110755.22722-4-zajec5@gmail.com (mailing list archive)
State Not Applicable
Headers show
Series nvmem: support more NVMEM cells variants | expand

Checks

Context Check Description
netdev/tree_selection success Not a local patch

Commit Message

Rafał Miłecki Dec. 23, 2021, 11:07 a.m. UTC
From: Rafał Miłecki <rafal@milecki.pl>

Not every NVMEM has predefined cells at hardcoded addresses. Some
devices store cells in internal structs and custom formats. Referencing
such cells is still required to let other bindings use them.

Modify binding to require "reg" xor "label". The later one can be used
to match "dynamic" NVMEM cells by their names.

Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
---
 Documentation/devicetree/bindings/nvmem/nvmem.yaml | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

Comments

Rob Herring Dec. 23, 2021, 9:18 p.m. UTC | #1
On Thu, Dec 23, 2021 at 7:08 AM Rafał Miłecki <zajec5@gmail.com> wrote:
>
> From: Rafał Miłecki <rafal@milecki.pl>
>
> Not every NVMEM has predefined cells at hardcoded addresses. Some
> devices store cells in internal structs and custom formats. Referencing
> such cells is still required to let other bindings use them.
>
> Modify binding to require "reg" xor "label". The later one can be used
> to match "dynamic" NVMEM cells by their names.

'label' is supposed to correspond to a sticker on a port or something
human identifiable. It generally should be something optional to
making the OS functional. Yes, there are already some abuses of that,
but this case is too far for me.

Rob
Rafał Miłecki Dec. 23, 2021, 9:58 p.m. UTC | #2
On 23.12.2021 22:18, Rob Herring wrote:
> On Thu, Dec 23, 2021 at 7:08 AM Rafał Miłecki <zajec5@gmail.com> wrote:
>>
>> From: Rafał Miłecki <rafal@milecki.pl>
>>
>> Not every NVMEM has predefined cells at hardcoded addresses. Some
>> devices store cells in internal structs and custom formats. Referencing
>> such cells is still required to let other bindings use them.
>>
>> Modify binding to require "reg" xor "label". The later one can be used
>> to match "dynamic" NVMEM cells by their names.
> 
> 'label' is supposed to correspond to a sticker on a port or something
> human identifiable. It generally should be something optional to
> making the OS functional. Yes, there are already some abuses of that,
> but this case is too far for me.

Good to learn that!

"name" is special & not allowed I think.

Any suggestion what to use? I'm not native. What about "title"? Or maybe
"term", "entity", "tag"?
Rob Herring Jan. 4, 2022, 8:16 p.m. UTC | #3
On Thu, Dec 23, 2021 at 10:58:56PM +0100, Rafał Miłecki wrote:
> On 23.12.2021 22:18, Rob Herring wrote:
> > On Thu, Dec 23, 2021 at 7:08 AM Rafał Miłecki <zajec5@gmail.com> wrote:
> > > 
> > > From: Rafał Miłecki <rafal@milecki.pl>
> > > 
> > > Not every NVMEM has predefined cells at hardcoded addresses. Some
> > > devices store cells in internal structs and custom formats. Referencing
> > > such cells is still required to let other bindings use them.
> > > 
> > > Modify binding to require "reg" xor "label". The later one can be used
> > > to match "dynamic" NVMEM cells by their names.
> > 
> > 'label' is supposed to correspond to a sticker on a port or something
> > human identifiable. It generally should be something optional to
> > making the OS functional. Yes, there are already some abuses of that,
> > but this case is too far for me.
> 
> Good to learn that!
> 
> "name" is special & not allowed I think.

It's the node name essentially. Why is using node names not sufficient? 
Do you have some specific examples?

Rob
Rafał Miłecki Jan. 4, 2022, 8:50 p.m. UTC | #4
On 4.01.2022 21:16, Rob Herring wrote:
> On Thu, Dec 23, 2021 at 10:58:56PM +0100, Rafał Miłecki wrote:
>> On 23.12.2021 22:18, Rob Herring wrote:
>>> On Thu, Dec 23, 2021 at 7:08 AM Rafał Miłecki <zajec5@gmail.com> wrote:
>>>>
>>>> From: Rafał Miłecki <rafal@milecki.pl>
>>>>
>>>> Not every NVMEM has predefined cells at hardcoded addresses. Some
>>>> devices store cells in internal structs and custom formats. Referencing
>>>> such cells is still required to let other bindings use them.
>>>>
>>>> Modify binding to require "reg" xor "label". The later one can be used
>>>> to match "dynamic" NVMEM cells by their names.
>>>
>>> 'label' is supposed to correspond to a sticker on a port or something
>>> human identifiable. It generally should be something optional to
>>> making the OS functional. Yes, there are already some abuses of that,
>>> but this case is too far for me.
>>
>> Good to learn that!
>>
>> "name" is special & not allowed I think.
> 
> It's the node name essentially. Why is using node names not sufficient?
> Do you have some specific examples?

I tried to explain in
[PATCH 1/5] dt-bindings: nvmem: add "label" property to allow more flexible cells names
that some vendors come with fancy names that can't fit node names.

Broadcom's NVRAM examples:
0:macaddr
1:macaddr
2:macaddr
0:ccode
1:ccode
2:ccode
0:regrev
Rafał Miłecki Jan. 4, 2022, 8:56 p.m. UTC | #5
On 4.01.2022 21:50, Rafał Miłecki wrote:
> On 4.01.2022 21:16, Rob Herring wrote:
>> On Thu, Dec 23, 2021 at 10:58:56PM +0100, Rafał Miłecki wrote:
>>> On 23.12.2021 22:18, Rob Herring wrote:
>>>> On Thu, Dec 23, 2021 at 7:08 AM Rafał Miłecki <zajec5@gmail.com> wrote:
>>>>>
>>>>> From: Rafał Miłecki <rafal@milecki.pl>
>>>>>
>>>>> Not every NVMEM has predefined cells at hardcoded addresses. Some
>>>>> devices store cells in internal structs and custom formats. Referencing
>>>>> such cells is still required to let other bindings use them.
>>>>>
>>>>> Modify binding to require "reg" xor "label". The later one can be used
>>>>> to match "dynamic" NVMEM cells by their names.
>>>>
>>>> 'label' is supposed to correspond to a sticker on a port or something
>>>> human identifiable. It generally should be something optional to
>>>> making the OS functional. Yes, there are already some abuses of that,
>>>> but this case is too far for me.
>>>
>>> Good to learn that!
>>>
>>> "name" is special & not allowed I think.
>>
>> It's the node name essentially. Why is using node names not sufficient?
>> Do you have some specific examples?
> 
> I tried to explain in
> [PATCH 1/5] dt-bindings: nvmem: add "label" property to allow more flexible cells names
> that some vendors come with fancy names that can't fit node names.
> 
> Broadcom's NVRAM examples:
> 0:macaddr
> 1:macaddr
> 2:macaddr
> 0:ccode
> 1:ccode
> 2:ccode
> 0:regrev

In other words I'd like to have something like:

nvram@1eff0000 {
	compatible = "brcm,nvram";
	reg = <0x1eff0000 0x10000>;

	mac: cell-0 {
		label = "1:macaddr";
	};
};

ethernet@1000 {
	compatible = "brcm,ethernet";
	reg = <0x1000 0x1000>;
	nvmem-cells = <&mac>;
	nvmem-cell-names = "mac-address";
};
Rob Herring Jan. 10, 2022, 5:44 p.m. UTC | #6
On Tue, Jan 04, 2022 at 09:56:01PM +0100, Rafał Miłecki wrote:
> On 4.01.2022 21:50, Rafał Miłecki wrote:
> > On 4.01.2022 21:16, Rob Herring wrote:
> > > On Thu, Dec 23, 2021 at 10:58:56PM +0100, Rafał Miłecki wrote:
> > > > On 23.12.2021 22:18, Rob Herring wrote:
> > > > > On Thu, Dec 23, 2021 at 7:08 AM Rafał Miłecki <zajec5@gmail.com> wrote:
> > > > > > 
> > > > > > From: Rafał Miłecki <rafal@milecki.pl>
> > > > > > 
> > > > > > Not every NVMEM has predefined cells at hardcoded addresses. Some
> > > > > > devices store cells in internal structs and custom formats. Referencing
> > > > > > such cells is still required to let other bindings use them.
> > > > > > 
> > > > > > Modify binding to require "reg" xor "label". The later one can be used
> > > > > > to match "dynamic" NVMEM cells by their names.
> > > > > 
> > > > > 'label' is supposed to correspond to a sticker on a port or something
> > > > > human identifiable. It generally should be something optional to
> > > > > making the OS functional. Yes, there are already some abuses of that,
> > > > > but this case is too far for me.
> > > > 
> > > > Good to learn that!
> > > > 
> > > > "name" is special & not allowed I think.
> > > 
> > > It's the node name essentially. Why is using node names not sufficient?
> > > Do you have some specific examples?
> > 
> > I tried to explain in
> > [PATCH 1/5] dt-bindings: nvmem: add "label" property to allow more flexible cells names
> > that some vendors come with fancy names that can't fit node names.

I still don't see the issue. Why do you need 'more flexible cells 
names'? What problem does that solve?

> > Broadcom's NVRAM examples:
> > 0:macaddr
> > 1:macaddr
> > 2:macaddr
> > 0:ccode
> > 1:ccode
> > 2:ccode
> > 0:regrev
>
> In other words I'd like to have something like:
> 
> nvram@1eff0000 {
> 	compatible = "brcm,nvram";
> 	reg = <0x1eff0000 0x10000>;
> 
> 	mac: cell-0 {
> 		label = "1:macaddr";
> 	};
> };
> 
> ethernet@1000 {
> 	compatible = "brcm,ethernet";
> 	reg = <0x1000 0x1000>;
> 	nvmem-cells = <&mac>;
> 	nvmem-cell-names = "mac-address";
> };

How does 'label' help here?

Note there's some other efforts around multiple mac addresses and how to 
interpret the nvmem data. Maybe that helps solve your problem.

Rob
diff mbox series

Patch

diff --git a/Documentation/devicetree/bindings/nvmem/nvmem.yaml b/Documentation/devicetree/bindings/nvmem/nvmem.yaml
index 3392405ee010..83154df25c27 100644
--- a/Documentation/devicetree/bindings/nvmem/nvmem.yaml
+++ b/Documentation/devicetree/bindings/nvmem/nvmem.yaml
@@ -43,6 +43,12 @@  patternProperties:
   "@[0-9a-f]+(,[0-7])?$":
     type: object
 
+    description: |
+      NVMEM cell - a part of NVMEM containing one specific information.
+
+      Cells can be fully defined by a binding or stored in NVMEM device specific
+      data and just referenced in DT by a name (label).
+
     properties:
       reg:
         maxItems: 1
@@ -64,8 +70,11 @@  patternProperties:
               description:
                 Size in bit within the address range specified by reg.
 
-    required:
-      - reg
+    oneOf:
+      - required:
+          - reg
+      - required:
+          - label
 
 additionalProperties: true