All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rob Herring <robh@kernel.org>
To: "Rafał Miłecki" <rafal@milecki.pl>
Cc: "Rafał Miłecki" <zajec5@gmail.com>,
	"Srinivas Kandagatla" <srinivas.kandagatla@linaro.org>,
	devicetree@vger.kernel.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	netdev <netdev@vger.kernel.org>
Subject: Re: [PATCH 3/5] dt-bindings: nvmem: allow referencing device defined cells by names
Date: Mon, 10 Jan 2022 11:44:51 -0600	[thread overview]
Message-ID: <Ydxwk7PCn4smJt5w@robh.at.kernel.org> (raw)
In-Reply-To: <0463d60e-b58e-84cc-df5e-d5030e8fdc1d@milecki.pl>

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

  reply	other threads:[~2022-01-10 17:44 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-23 11:07 [PATCH 0/5] nvmem: support more NVMEM cells variants Rafał Miłecki
2021-12-23 11:07 ` [PATCH 1/5] dt-bindings: nvmem: add "label" property to allow more flexible cells names Rafał Miłecki
2021-12-23 11:07 ` [PATCH 2/5] nvmem: core: read OF defined NVMEM cell name from "label" property Rafał Miłecki
2021-12-23 11:07 ` [PATCH 3/5] dt-bindings: nvmem: allow referencing device defined cells by names Rafał Miłecki
2021-12-23 21:18   ` Rob Herring
2021-12-23 21:58     ` Rafał Miłecki
2022-01-04 20:16       ` Rob Herring
2022-01-04 20:50         ` Rafał Miłecki
2022-01-04 20:56           ` Rafał Miłecki
2022-01-10 17:44             ` Rob Herring [this message]
2021-12-23 11:07 ` [PATCH 4/5] dt-bindings: nvmem: brcm,nvram: add NVMEM cell to example Rafał Miłecki
2021-12-23 11:07 ` [PATCH 5/5] nvmem: core: add cell name based matching of DT cell nodes Rafał Miłecki

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=Ydxwk7PCn4smJt5w@robh.at.kernel.org \
    --to=robh@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=rafal@milecki.pl \
    --cc=srinivas.kandagatla@linaro.org \
    --cc=zajec5@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.