From: Michael Walle <michael@walle.cc>
To: zajec5@gmail.com
Cc: andrew@lunn.ch, davem@davemloft.net, devicetree@vger.kernel.org,
hkallweit1@gmail.com, kuba@kernel.org,
linux-kernel@vger.kernel.org, linux@armlinux.org.uk,
netdev@vger.kernel.org, rafal@milecki.pl, robh+dt@kernel.org,
Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
Michael Walle <michael@walle.cc>
Subject: Re: [PATCH] of: net: support NVMEM cells with MAC in text format
Date: Wed, 29 Dec 2021 13:40:47 +0100 [thread overview]
Message-ID: <20211229124047.1286965-1-michael@walle.cc> (raw)
In-Reply-To: <20211223122747.30448-1-zajec5@gmail.com>
Hi,
> Some NVMEM devices have text based cells. In such cases MAC is stored in
> a XX:XX:XX:XX:XX:XX format. Use mac_pton() to parse such data and
> support those NVMEM cells. This is required to support e.g. a very
> popular U-Boot and its environment variables.
>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> ---
> Please let me know if checking NVMEM cell length (6 B vs. 17 B) can be
> considered a good enough solution. Alternatively we could use some DT
> property to make it explicity, e.g. something like:
>
> ethernet@18024000 {
> compatible = "brcm,amac";
> reg = <0x18024000 0x800>;
>
> nvmem-cells = <&mac_addr>;
> nvmem-cell-names = "mac-address";
> nvmem-mac-format = "text";
> };
Please note, that there is also this proposal, which had such a conversion
in mind:
https://lore.kernel.org/linux-devicetree/20211228142549.1275412-1-michael@walle.cc/
With this patch, there are now two different places where a mac address
format is converted. In of_get_mac_addr_nvmem() and in the imx otp driver.
And both have their shortcomings and aren't really flexible. Eg. this one
magically detects the format by comparing the length, but can't be used for
to swap bytes (because the length is also ETH_ALEN), which apparently is a
use case in the imx otp driver. And having the conversion in an nvmem
provider device driver is still a bad thing IMHO.
I'd really like to see all these kind of transformations in one place.
-michael
next prev parent reply other threads:[~2021-12-29 12:41 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-23 12:27 [PATCH] of: net: support NVMEM cells with MAC in text format Rafał Miłecki
2021-12-29 11:40 ` patchwork-bot+netdevbpf
2021-12-29 12:40 ` Michael Walle [this message]
2021-12-29 18:18 ` Jakub Kicinski
2021-12-29 22:04 ` Michael Walle
2022-01-06 9:23 ` Michael Walle
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=20211229124047.1286965-1-michael@walle.cc \
--to=michael@walle.cc \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=hkallweit1@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=netdev@vger.kernel.org \
--cc=rafal@milecki.pl \
--cc=robh+dt@kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).