From: "Petr Štetiar" <ynezz@true.cz>
To: Andy Duan <fugang.duan@nxp.com>
Cc: "davem@davemloft.net" <davem@davemloft.net>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"john@phrozen.org" <john@phrozen.org>,
"bgolaszewski@baylibre.com" <bgolaszewski@baylibre.com>,
Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
Andrew Lunn <andrew@lunn.ch>,
Florian Fainelli <f.fainelli@gmail.com>,
Heiner Kallweit <hkallweit1@gmail.com>,
Rob Herring <robh+dt@kernel.org>,
Frank Rowand <frowand.list@gmail.com>,
Mark Rutland <mark.rutland@arm.com>,
Maxime Ripard <maxime.ripard@bootlin.com>,
Alban Bedel <albeu@free.fr>,
devicetree@vger.kernel.org
Subject: Re: [PATCH net 0/3] add property "nvmem_macaddr_swap" to swap macaddr bytes order
Date: Fri, 10 May 2019 13:28:22 +0200 [thread overview]
Message-ID: <20190510112822.GT81826@meh.true.cz> (raw)
In-Reply-To: <1557476567-17397-4-git-send-email-fugang.duan@nxp.com> <1557476567-17397-3-git-send-email-fugang.duan@nxp.com> <1557476567-17397-2-git-send-email-fugang.duan@nxp.com> <1557476567-17397-1-git-send-email-fugang.duan@nxp.com>
Andy Duan <fugang.duan@nxp.com> [2019-05-10 08:23:58]:
Hi Andy,
you've probably forget to Cc some maintainers and mailing lists, so I'm
adding them now to the Cc loop. This patch series should be posted against
net-next tree as per netdev FAQ[0], but you've to wait little bit as
net-next is currently closed for the new submissions and you would need to
resend it anyway.
0. https://www.kernel.org/doc/html/latest/networking/netdev-FAQ.html
> ethernet controller driver call .of_get_mac_address() to get
> the mac address from devictree tree, if these properties are
> not present, then try to read from nvmem. i.MX6x/7D/8MQ/8MM
> platforms ethernet MAC address read from nvmem ocotp eFuses,
> but it requires to swap the six bytes order.
Thanks for bringing up this topic, as I would like to extend the
functionality as well, but I'm still unsure how to tackle this and where,
so I'll (ab)use this opportunity to bring other use cases I would like to
cover in the future, so we could better understand the needs.
This reverse byte order format/layout is one of a few other storage formats
currently used by vendors, some other (creative) vendors are currently
providing MAC addresses in NVMEMs as ASCII text in following two formats
(hexdump -C /dev/mtdX):
a) 0090FEC9CBE5 - MAC address stored as ASCII without colon between octets
00000090 57 2e 4c 41 4e 2e 4d 41 43 2e 41 64 64 72 65 73 |W.LAN.MAC.Addres|
000000a0 73 3d 30 30 39 30 46 45 43 39 43 42 45 35 00 48 |s=0090FEC9CBE5.H|
000000b0 57 2e 4c 41 4e 2e 32 47 2e 30 2e 4d 41 43 2e 41 |W.LAN.2G.0.MAC.A|
(From https://github.com/openwrt/openwrt/pull/1448#issuecomment-442476695)
b) D4:EE:07:33:6C:20 - MAC address stored as ASCII with colon between octets
00000180 66 61 63 5f 6d 61 63 20 3d 20 44 34 3a 45 45 3a |fac_mac = D4:EE:|
00000190 30 37 3a 33 33 3a 36 43 3a 32 30 0a 42 44 49 4e |07:33:6C:20.BDIN|
(From https://github.com/openwrt/openwrt/pull/1906#issuecomment-483881911)
> The patch set is to add property "nvmem_macaddr_swap" to swap
> macaddr bytes order.
so it would allow following DT construct (simplified):
ð0 {
nvmem-cells = <ð0_addr>;
nvmem-cell-names = "mac-address";
nvmem_macaddr_swap;
};
I'm not sure about the `nvmem_macaddr_swap` property name, as currently there
are no other properties with underscores, so it should be probably named as
`nvmem-macaddr-swap`. DT specs permits use of the underscores, but the
estabilished convention is probably prefered.
In order to cover all above mentioned use cases, it would make more sense
to add a description of the MAC address layout to the DT and use this
information to properly postprocess the NVMEM content into usable MAC
address?
Something like this?
- nvmem-cells: phandle, reference to an nvmem node for the MAC address
- nvmem-cell-names: string, should be "mac-address" if nvmem is to be used
- nvmem-mac-address-layout: string, specifies MAC address storage layout.
Supported values are: "binary", "binary-swapped", "ascii", "ascii-delimited".
"binary" is the default.
Or perhaps something like this?
- nvmem-cells: phandle, reference to an nvmem node for the MAC address
- nvmem-cell-names: string, should be any of the supported values.
Supported values are: "mac-address", "mac-address-swapped",
"mac-address-ascii", "mac-address-ascii-delimited".
I'm more inclined towards the first proposed solution, as I would like to
propose MAC address octet incrementation feature in the future, so it would
become:
- nvmem-cells: phandle, reference to an nvmem node for the MAC address
- nvmem-cell-names: string, should be "mac-address" if nvmem is to be used
- nvmem-mac-address-layout: string, specifies MAC address storage layout.
Supported values are: "binary", "binary-swapped", "ascii", "ascii-delimited".
"binary" is the default.
- nvmem-mac-address-increment: number, value by which should be
incremented MAC address octet, could be negative value as well.
- nvmem-mac-address-increment-octet: number, valid values 0-5, default is 5.
Specifies MAC address octet used for `nvmem-mac-address-increment`.
What do you think?
Cheers,
Petr
next prev parent reply other threads:[~2019-05-10 11:28 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-10 8:23 [PATCH net 0/3] add property "nvmem_macaddr_swap" to swap macaddr bytes order Andy Duan
2019-05-10 8:24 ` [PATCH net 1/3] net: ethernet: " Andy Duan
2019-05-10 18:16 ` Andrew Lunn
2019-05-13 3:10 ` [EXT] " Andy Duan
2019-05-10 8:24 ` [PATCH net 2/3] of_net: add property "nvmem-mac-address" for of_get_mac_addr() Andy Duan
2019-05-10 18:17 ` Andrew Lunn
2019-05-13 3:31 ` [EXT] " Andy Duan
2019-05-13 8:00 ` Petr Štetiar
2019-05-13 8:47 ` Andy Duan
2019-05-10 8:24 ` [PATCH net 3/3] dt-bindings: doc: add new properties for of_get_mac_address from nvmem Andy Duan
2019-05-10 11:28 ` Petr Štetiar [this message]
2019-05-10 11:31 ` [PATCH net 0/3] add property "nvmem_macaddr_swap" to swap macaddr bytes order Maxime Ripard
2019-05-11 14:44 ` NVMEM address DT post processing [Was: Re: [PATCH net 0/3] add property "nvmem_macaddr_swap" to swap macaddr bytes order] Petr Štetiar
2019-05-12 12:19 ` Maxime Ripard
2019-05-13 9:28 ` Petr Štetiar
2019-05-13 8:25 ` Srinivas Kandagatla
2019-05-13 9:07 ` Petr Štetiar
2019-05-13 10:06 ` Srinivas Kandagatla
2019-05-13 11:16 ` Petr Štetiar
2019-05-14 15:13 ` Srinivas Kandagatla
2019-05-14 17:44 ` Petr Štetiar
2019-05-15 17:12 ` Srinivas Kandagatla
2019-05-20 14:28 ` Rob Herring
2019-05-13 3:38 ` [EXT] Re: [PATCH net 0/3] add property "nvmem_macaddr_swap" to swap macaddr bytes order Andy Duan
2019-05-13 9:35 ` ynezz
2019-05-13 3:06 ` [EXT] " Andy Duan
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=20190510112822.GT81826@meh.true.cz \
--to=ynezz@true.cz \
--cc=albeu@free.fr \
--cc=andrew@lunn.ch \
--cc=bgolaszewski@baylibre.com \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=f.fainelli@gmail.com \
--cc=frowand.list@gmail.com \
--cc=fugang.duan@nxp.com \
--cc=hkallweit1@gmail.com \
--cc=john@phrozen.org \
--cc=mark.rutland@arm.com \
--cc=maxime.ripard@bootlin.com \
--cc=netdev@vger.kernel.org \
--cc=robh+dt@kernel.org \
--cc=srinivas.kandagatla@linaro.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;
as well as URLs for NNTP newsgroup(s).