[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPnjgZ31AAauR876W1RmU4JPzKUD8XAMCZrJDumE+Dr4miqABQ@mail.gmail.com>
Date: Thu, 14 Dec 2023 14:27:12 -0700
From: Simon Glass <sjg@...omium.org>
To: Rafał Miłecki <zajec5@...il.com>
Cc: Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>, Conor Dooley <conor+dt@...nel.org>,
Srinivas Kandagatla <srinivas.kandagatla@...aro.org>, devicetree@...r.kernel.org,
linux-mtd@...ts.infradead.org, linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org, u-boot@...ts.denx.de,
Rafał Miłecki <rafal@...ecki.pl>
Subject: Re: [PATCH RFC] dt-bindings: nvmem: u-boot, env: add any-name MAC
cells compatible
Hi Rafał,
On Thu, 14 Dec 2023 at 08:36, Rafał Miłecki <zajec5@...il.com> wrote:
>
> From: Rafał Miłecki <rafal@...ecki.pl>
>
> So far we had a property for "ethaddr" NVMEM cell containing base
> Ethernet MAC address. The problem is vendors often pick non-standard
> names for storing MAC(s) (other than "ethaddr"). A few names were
> noticed over years:
> 1. "wanaddr" (Edimax, ELECOM, EnGenius, I-O DATA, Sitecom)
> 2. "et1macaddr" (ASUS)
> 3. "eth1addr" (Buffalo)
> 4. "athaddr" (EnGenius)
> 5. "baseMAC" (Netgear)
> 6. "mac" (Netgear)
> 7. "mac_addr" (Moxa)
> and more ("HW_LAN_MAC", "HW_WAN_MAC", "INIC_MAC_ADDR", "LAN_MAC_ADDR",
> "RADIOADDR0", "RADIOADDR1", "WAN_MAC_ADDR", "lan1_mac_addr", "wanmac",
> "wmac1", "wmac2").
>
> It doesn't make sense to add property for every possible MAC cell name.
> Instead allow specifying cells with "mac" compatible.
>
> Signed-off-by: Rafał Miłecki <rafal@...ecki.pl>
> ---
> List of devices and their U-Boot MAC variables:
> alphanetworks,asl56026) wanmac
> asus,rt-ac65p) et1macaddr
> asus,rt-ac85p) et1macaddr
> belkin,f9k1109v1) HW_WAN_MAC + HW_LAN_MAC
> buffalo,ls220de) eth1addr
> buffalo,ls421de) eth1addr
> checkpoint,l-50) lan1_mac_addr
> dovado,tiny-ac) INIC_MAC_ADDR
> dovado,tiny-ac) LAN_MAC_ADDR + WAN_MAC_ADDR
> edimax,ra21s) wanaddr
> edimax,rg21s) wanaddr
> elecom,wrc-2533ghbk-i) wanaddr
> elecom,wrc-2533ghbk2-t) wanaddr
> engenius,ecb1200) athaddr
> engenius,ecb1750) athaddr
> engenius,epg5000) wanaddr
> engenius,epg600) wanaddr
> engenius,esr1200) wanaddr
> engenius,esr1750) wanaddr
> engenius,esr600) wanaddr
> engenius,esr600h) wanaddr
> engenius,esr900) wanaddr
> enterasys,ws-ap3705i) RADIOADDR0 + RADIOADDR1
> iodata,wn-ac1167dgr) wanaddr
> iodata,wn-ac1167gr) wanaddr
> iodata,wn-ac1600dgr) wanaddr
> iodata,wn-ac1600dgr2) wanaddr
> iodata,wn-ac733gr3) wanaddr
> iodata,wn-ag300dgr) wanaddr
> iodata,wnpr2600g) wanaddr
> moxa,awk-1137c) mac_addr
> netgear,wax220) mac
> netgear,wndap620) baseMAC
> netgear,wndap660) baseMAC
> ocedo,panda) wmac1 + wmac2
> sitecom,wlr-7100) wanaddr
> sitecom,wlr-8100) wanaddr
>
> .../devicetree/bindings/nvmem/u-boot,env.yaml | 33 +++++++++++++++++++
> 1 file changed, 33 insertions(+)
>
Are these upstream U-Boots, or just vendor forks?
Regards,
Simon
Powered by blists - more mailing lists