[PATCH] x86 64: Add new device Cordoba Edge Platform
Add new device Cordoba Edge Platform hardware specifications: CPU - Intel Atom C3000 Ethernet - 2 10Gbps ixgbe SPF+ 2 1Gbps ixgbe RJ45/SPF 4 2.5Gbps igc RJ45 WiFi - mt7915e LED - 3 multicolor(red|blue|green) LEDs Signed-off-by: Xiaojun Liu mailto:xiaojun@silicom.co.il -- diff --git a/target/linux/x86/base-files/etc/board.d/01_leds b/target/linux/x86/base-files/etc/board.d/01_leds index efc5460df3..47ea0929e6 100644 --- a/target/linux/x86/base-files/etc/board.d/01_leds +++ b/target/linux/x86/base-files/etc/board.d/01_leds @@ -28,6 +28,10 @@ traverse-technologies-geos) ucidef_set_led_netdev "wlan" "WiFi" "geos:2" "phy0tpt" ucidef_set_led_default "diag" "DIAG" "geos:3" "1" ;; +silicom-80500-0214-*) +ucidef_set_led_netdev "wan" "WAN" "multicolor:fp_center" "wan0" +ucidef_set_led_netdev "lan" "LAN" "multicolor:fp_right" "br-lan" +;; esac board_config_flush diff --git a/target/linux/x86/base-files/etc/board.d/02_network b/target/linux/x86/base-files/etc/board.d/02_network index e00e8c04dd..5174906264 100644 --- a/target/linux/x86/base-files/etc/board.d/02_network +++ b/target/linux/x86/base-files/etc/board.d/02_network @@ -75,6 +75,17 @@ traverse-technologies-geos) macaddr="$(cat /sys/class/net/eth0/address)" 2>/dev/null [ -n "$macaddr" ] && ucidef_set_interface_macaddr "wan" "$macaddr" ;; +silicom-80500-0214-*) +ucidef_set_network_device_path "wan0" "pci:00/:00:16.0/:03:00.0" +ucidef_set_network_device_path "wan1" "pci:00/:00:16.0/:03:00.1" +ucidef_set_network_device_path "media0" "pci:00/:00:17.0/:02:00.1" +ucidef_set_network_device_path "media1" "pci:00/:00:17.0/:02:00.0" +ucidef_set_network_device_path "eth0" "pci:00/:00:0c.0/:04:00.0" +ucidef_set_network_device_path "eth1" "pci:00/:00:0e.0/:05:00.0" +ucidef_set_network_device_path "eth2" "pci:00/:00:0f.0/:06:00.0" +ucidef_set_network_device_path "eth3" "pci:00/:00:10.0/:07:00.0" +ucidef_set_interfaces_lan_wan "eth0 eth1 eth2 eth3" "wan0" +;; esac board_config_flush x86 64 Add new device Cordoba Edge Platform.patch Description: x86 64 Add new device Cordoba Edge Platform.patch ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Adding a new x86 image or related packages to the default x86 image
> On Sep 14, 2023, at 5:19 PM, Stefan Lippers-Hollmann wrote:
>
> On 2023-09-14, Paul Spooren wrote:
>>
>> I’d like to merge the PR which adds the Mellanox Spectrum SN2100 to
>> OpenWrt[1]. In its current state a new x86 image would be added next
>> to the generic x86 image. Another approach is to add all related
>> packages to the default image. Either way creates a working image.
>>
>> I remember that people were complaining about a “bloated” x86 image
>> which slows down their container/VM needs. So what would be a simple
>> way forward here?
> [...]
>
> If at all reasonably possible (assuming the size increase is roughly in
> the ball park of 1-2 MB for the total image), I'd suggest to stick to a
> single x86_64 image for maintenance and testing reasons alone. The bump
> of the x86 targets to kernel v6.1 -while easy- is mostly stalled due to
> there being three 32 bit x86 sub-targets and the need to go through the
> kernel config rebase three times, which is wearing thin the patience and
> motivation of doing so (x86_64 alone would have been ready >2 months
> ago). Unless these SN2100 devices suddenly become a cheap commodity and
> ubiquitous among OpenWrt developers and -users, I fear that it would
> just add to this churn and pretty much rot away in the tree, while at
> the same time making progress harder for the other x86{,_64} devices.
In that case I would suggest removing the x86/generic target. Since it
has CONFIG_MPENTIUM4=y, that is only appropriate for a very small number
of computers. The earlier ones are covered by x86/legacy, the later ones
are covered by x86/64.
I don't know what others are running into, but the bigger issue for VMs
(possibly containers as well) is memory is expensive. A small VM
machine could have 2GB of memory. OpenWRT's baseline of 128MB is quite
nice for sticking a full-featured AP in a VM.
On Sun, Nov 12, 2023 at 06:31:29PM -0700, Philip Prindeville wrote:
>
> Sometime back I tried to add "pcituils" and "usbutils" to the generic x86_64
> image, and was told that they weren't sufficiently "ubiquitous" to add to the
> default image.
>
> I note that they can be removed from the BOM easily by doing:
>
> DEVICE_PACKAGES += -pciutils -usbutils
>
> And that would remove them if they were already present in $(DEVICE_PACKAGES).
>
> I've never encountered an x86_64 platform that didn't have both USB and PCI,
> as they've without question become a "cheap commodity".
>
> Contrarily, I've yet to own or operate a platform that has a Mellanox switch.
> This seems arbitrary.
>
I've encountered plenty of amd64 devices which lacked USB, PCI, PATA,
SATA, SCSI and SAS. They're all VMs, yet they're quite functional (an AP
in VM will almost certainly need PCI).
I think the various hypervisors could do with targeted builds. Mostly
this involves removing nearly all common drivers, then keeping/adding a
small number of specialized drivers.
--
(\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/)
\BS (| ehem+sig...@m5p.com PGP 87145445 |) /
\_CS\ | _ -O #include O- _ | / _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Adding a new x86 image or related packages to the default x86 image
> On Sep 14, 2023, at 5:19 PM, Stefan Lippers-Hollmann wrote:
>
> Hi
>
> On 2023-09-14, Paul Spooren wrote:
>> Hi,
>>
>> I’d like to merge the PR which adds the Mellanox Spectrum SN2100 to
>> OpenWrt[1]. In its current state a new x86 image would be added next
>> to the generic x86 image. Another approach is to add all related
>> packages to the default image. Either way creates a working image.
>>
>> I remember that people were complaining about a “bloated” x86 image
>> which slows down their container/VM needs. So what would be a simple
>> way forward here?
> [...]
>
> If at all reasonably possible (assuming the size increase is roughly in
> the ball park of 1-2 MB for the total image), I'd suggest to stick to a
> single x86_64 image for maintenance and testing reasons alone. The bump
> of the x86 targets to kernel v6.1 -while easy- is mostly stalled due to
> there being three 32 bit x86 sub-targets and the need to go through the
> kernel config rebase three times, which is wearing thin the patience and
> motivation of doing so (x86_64 alone would have been ready >2 months
> ago). Unless these SN2100 devices suddenly become a cheap commodity and
> ubiquitous among OpenWrt developers and -users, I fear that it would
> just add to this churn and pretty much rot away in the tree, while at
> the same time making progress harder for the other x86{,_64} devices.
>
> Regards
> Stefan Lippers-Hollmann
Sometime back I tried to add "pcituils" and "usbutils" to the generic x86_64
image, and was told that they weren't sufficiently "ubiquitous" to add to the
default image.
I note that they can be removed from the BOM easily by doing:
DEVICE_PACKAGES += -pciutils -usbutils
And that would remove them if they were already present in $(DEVICE_PACKAGES).
I've never encountered an x86_64 platform that didn't have both USB and PCI, as
they've without question become a "cheap commodity".
Contrarily, I've yet to own or operate a platform that has a Mellanox switch.
This seems arbitrary.
-Philip
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[sdwalker/sdwalker.github.io] 141bf6: This week's update
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Branch: refs/heads/master Home: https://github.com/sdwalker/sdwalker.github.io Commit: 141bf646922bc3e1d13c2e7394646972c50652fa https://github.com/sdwalker/sdwalker.github.io/commit/141bf646922bc3e1d13c2e7394646972c50652fa Author: Stephen Walker Date: 2023-11-12 (Sun, 12 Nov 2023) Changed paths: M uscan/index-22.03.html M uscan/index-23.05.html M uscan/index.html Log Message: --- This week's update --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH ustream-ssl 1/2] ustream-mbedtls: Add compatibility with Mbed TLS 3.0.0
On 11/12/23 20:16, Rosen Penev wrote: On Sat, Nov 11, 2023 at 1:35 PM Hauke Mehrtens wrote: This adds support for compiling the code against Mbed TLS 3.0.0. It still compiles against Mbed TLS 2.28. The following changes were needed: * DES and 3DES was removed * mbedtls_pk_context->pk_info is private, use mbedtls_pk_get_type() to check if it was initialized * mbedtls_pk_parse_keyfile() now gets a random callback * mbedtls/certs.h contains test data and is not installed any more and not needed. Signed-off-by: Hauke Mehrtens --- ustream-mbedtls.c | 12 +++- ustream-mbedtls.h | 1 - 2 files changed, 11 insertions(+), 2 deletions(-) diff --git a/ustream-mbedtls.c b/ustream-mbedtls.c index 7fc7874..1c70cac 100644 --- a/ustream-mbedtls.c +++ b/ustream-mbedtls.c @@ -110,9 +110,15 @@ static const int default_ciphersuites_client[] = AES_CBC_CIPHERS(ECDHE_ECDSA), AES_CBC_CIPHERS(ECDHE_RSA), AES_CBC_CIPHERS(DHE_RSA), +/* Removed in Mbed TLS 3.0.0 */ are these for Windows XP compatibility? No, This is for the TLS client. I assume this is for some legacy embedded webserver. Mbed TLS 3.0.0 also removes support for TLS 1.0 and 1.1, it only support TLS 1.2 and 1.3, this could cause some problems with older equipment and legacy WPA enterprise clients. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] kernel: of: remove "mac-address-ascii" support hack
On Fri, Nov 10, 2023 at 1:31 AM Shiji Yang wrote:
>
> From: Shiji Yang
>
> ASCII MAC address can be handled by nvmem "fixed-layout" now. And all
> related devices were converted to the new "mac-base" layout format.
> It's time to remove this hack.
>
> Signed-off-by: Shiji Yang
Reviewed-by: Rosen Penev
> ---
>
> Git grep ref:
> https://git.openwrt.org/?p=openwrt%2Fopenwrt.git&a=search&h=HEAD&st=grep&s=mac-address-ascii&sr=1
>
> Regards,
> Shiji Yang
>
>
> ...of_net-add-mac-address-ascii-support.patch | 116 --
> ...of_net-add-mac-address-ascii-support.patch | 116 --
> 2 files changed, 232 deletions(-)
> delete mode 100644
> target/linux/generic/hack-5.15/601-of_net-add-mac-address-ascii-support.patch
> delete mode 100644
> target/linux/generic/hack-6.1/601-of_net-add-mac-address-ascii-support.patch
>
> diff --git
> a/target/linux/generic/hack-5.15/601-of_net-add-mac-address-ascii-support.patch
>
> b/target/linux/generic/hack-5.15/601-of_net-add-mac-address-ascii-support.patch
> deleted file mode 100644
> index 55866c3135..00
> ---
> a/target/linux/generic/hack-5.15/601-of_net-add-mac-address-ascii-support.patch
> +++ /dev/null
> @@ -1,116 +0,0 @@
> -From: Yousong Zhou
> -Subject: [PATCH] of: net: add nvmem cell mac-address-ascii support
> -
> -This is needed for devices with mac address stored in ascii format,
> -e.g. HiWiFi HC6361 to be ported in the following patch.
> -
> -Submitted-by: Yousong Zhou
>
> - net/core/of_net.c | 83 --
> - 1 files changed, 72 insertions(+), 11 deletions(-)
> -
> a/net/core/of_net.c
> -+++ b/net/core/of_net.c
> -@@ -57,13 +57,70 @@ static int of_get_mac_addr(struct device
> - return -ENODEV;
> - }
> -
> -+static void *nvmem_cell_get_mac_address(struct nvmem_cell *cell)
> -+{
> -+ size_t len;
> -+ void *mac;
> -+
> -+ mac = nvmem_cell_read(cell, &len);
> -+ if (IS_ERR(mac))
> -+ return mac;
> -+ if (len != ETH_ALEN) {
> -+ kfree(mac);
> -+ return ERR_PTR(-EINVAL);
> -+ }
> -+ return mac;
> -+}
> -+
> -+static void *nvmem_cell_get_mac_address_ascii(struct nvmem_cell *cell)
> -+{
> -+ size_t len;
> -+ int ret;
> -+ void *mac_ascii;
> -+ u8 *mac;
> -+
> -+ mac_ascii = nvmem_cell_read(cell, &len);
> -+ if (IS_ERR(mac_ascii))
> -+ return mac_ascii;
> -+ if (len != ETH_ALEN*2+5) {
> -+ kfree(mac_ascii);
> -+ return ERR_PTR(-EINVAL);
> -+ }
> -+ mac = kmalloc(ETH_ALEN, GFP_KERNEL);
> -+ if (!mac) {
> -+ kfree(mac_ascii);
> -+ return ERR_PTR(-ENOMEM);
> -+ }
> -+ ret = sscanf(mac_ascii, "%2hhx:%2hhx:%2hhx:%2hhx:%2hhx:%2hhx",
> -+ &mac[0], &mac[1], &mac[2],
> -+ &mac[3], &mac[4], &mac[5]);
> -+ kfree(mac_ascii);
> -+ if (ret == ETH_ALEN)
> -+ return mac;
> -+ kfree(mac);
> -+ return ERR_PTR(-EINVAL);
> -+}
> -+
> -+static struct nvmem_cell_mac_address_property {
> -+ char *name;
> -+ void *(*read)(struct nvmem_cell *);
> -+} nvmem_cell_mac_address_properties[] = {
> -+ {
> -+ .name = "mac-address",
> -+ .read = nvmem_cell_get_mac_address,
> -+ }, {
> -+ .name = "mac-address-ascii",
> -+ .read = nvmem_cell_get_mac_address_ascii,
> -+ },
> -+};
> -+
> - static int of_get_mac_addr_nvmem(struct device_node *np, u8 *addr)
> - {
> - struct platform_device *pdev = of_find_device_by_node(np);
> -+ struct nvmem_cell_mac_address_property *property;
> - struct nvmem_cell *cell;
> - const void *mac;
> -- size_t len;
> -- int ret;
> -+ int ret, i;
> -
> - /* Try lookup by device first, there might be a nvmem_cell_lookup
> -* associated with a given device.
> -@@ -74,17 +131,26 @@ static int of_get_mac_addr_nvmem(struct
> - return ret;
> - }
> -
> -- cell = of_nvmem_cell_get(np, "mac-address");
> -+ for (i = 0; i < ARRAY_SIZE(nvmem_cell_mac_address_properties); i++) {
> -+ property = &nvmem_cell_mac_address_properties[i];
> -+ cell = of_nvmem_cell_get(np, property->name);
> -+ /* For -EPROBE_DEFER don't try other properties.
> -+ * We'll get back to this one.
> -+ */
> -+ if (!IS_ERR(cell) || PTR_ERR(cell) == -EPROBE_DEFER)
> -+ break;
> -+ }
> -+
> - if (IS_ERR(cell))
> - return PTR_ERR(cell);
> -
> -- mac = nvmem_cell_read(cell, &len);
> -+ mac = property->read(cell);
> - nvmem_cell_put(cell);
> -
> - if (IS_ERR(mac))
> - return PTR_ERR(mac);
> -
> -- if (len != ETH_ALEN || !is_valid_ether_addr(mac)) {
> -+ if (!is_valid_ether_addr(mac)) {
> - kfree(mac);
> - return -EINVAL;
>
Re: [PATCH ustream-ssl 1/2] ustream-mbedtls: Add compatibility with Mbed TLS 3.0.0
On Sat, Nov 11, 2023 at 1:35 PM Hauke Mehrtens wrote:
>
> This adds support for compiling the code against Mbed TLS 3.0.0.
> It still compiles against Mbed TLS 2.28.
>
> The following changes were needed:
> * DES and 3DES was removed
> * mbedtls_pk_context->pk_info is private, use mbedtls_pk_get_type()
>to check if it was initialized
> * mbedtls_pk_parse_keyfile() now gets a random callback
> * mbedtls/certs.h contains test data and is not installed any more and
>not needed.
>
> Signed-off-by: Hauke Mehrtens
> ---
> ustream-mbedtls.c | 12 +++-
> ustream-mbedtls.h | 1 -
> 2 files changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/ustream-mbedtls.c b/ustream-mbedtls.c
> index 7fc7874..1c70cac 100644
> --- a/ustream-mbedtls.c
> +++ b/ustream-mbedtls.c
> @@ -110,9 +110,15 @@ static const int default_ciphersuites_client[] =
> AES_CBC_CIPHERS(ECDHE_ECDSA),
> AES_CBC_CIPHERS(ECDHE_RSA),
> AES_CBC_CIPHERS(DHE_RSA),
> +/* Removed in Mbed TLS 3.0.0 */
are these for Windows XP compatibility?
> +#ifdef MBEDTLS_TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
> MBEDTLS_TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA,
> +#endif
> AES_CIPHERS(RSA),
> +/* Removed in Mbed TLS 3.0.0 */
> +#ifdef MBEDTLS_TLS_RSA_WITH_3DES_EDE_CBC_SHA
> MBEDTLS_TLS_RSA_WITH_3DES_EDE_CBC_SHA,
> +#endif
> 0
> };
>
> @@ -171,7 +177,7 @@ static void ustream_ssl_update_own_cert(struct
> ustream_ssl_ctx *ctx)
> if (!ctx->cert.version)
> return;
>
> - if (!ctx->key.pk_info)
> + if (mbedtls_pk_get_type(&ctx->key) == MBEDTLS_PK_NONE)
> return;
>
> mbedtls_ssl_conf_own_cert(&ctx->conf, &ctx->cert, &ctx->key);
> @@ -206,7 +212,11 @@ __hidden int __ustream_ssl_set_key_file(struct
> ustream_ssl_ctx *ctx, const char
> {
> int ret;
>
> +#if (MBEDTLS_VERSION_NUMBER >= 0x0300)
> + ret = mbedtls_pk_parse_keyfile(&ctx->key, file, NULL, _random, NULL);
> +#else
> ret = mbedtls_pk_parse_keyfile(&ctx->key, file, NULL);
> +#endif
> if (ret)
> return -1;
>
> diff --git a/ustream-mbedtls.h b/ustream-mbedtls.h
> index e622e5e..7e7c699 100644
> --- a/ustream-mbedtls.h
> +++ b/ustream-mbedtls.h
> @@ -21,7 +21,6 @@
>
> #include
> #include
> -#include
> #include
> #include
> #include
> --
> 2.39.2
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ath79: use "fixed-layout" for Embedded Wireless devices
On Fri, Nov 10, 2023 at 2:27 AM Rafał Miłecki wrote:
>
> From: Rafał Miłecki
>
> Those devices have Ethernet interfaces using base MAC address increased
> by 0x40 in the 3rd indexed byte (00:00:00:FF:00:00). To describe that we
> were using a custom (downstream) "mac-address-increment-byte" property.
>
> The same result can be achieved by using "mac-base" with a properly
> adjusted offset value (0x40 << 16). It may be not pretty but it should
> work without custom property or downstream kernel patch to support it.
>
> Cc: Ansuel Smith
> Cc: Catrinel Catrinescu
> Cc: Felix Fietkau
> Signed-off-by: Rafał Miłecki
Reviewed-by: Rosen Penev
> ---
> .../dts/ar9331_embeddedwireless_dorin.dts | 26
> .../dts/ar9344_embeddedwireless_balin.dts | 30 ++-
> 2 files changed, 29 insertions(+), 27 deletions(-)
>
> diff --git a/target/linux/ath79/dts/ar9331_embeddedwireless_dorin.dts
> b/target/linux/ath79/dts/ar9331_embeddedwireless_dorin.dts
> index de6b709b5c..6286f203ef 100644
> --- a/target/linux/ath79/dts/ar9331_embeddedwireless_dorin.dts
> +++ b/target/linux/ath79/dts/ar9331_embeddedwireless_dorin.dts
> @@ -85,6 +85,18 @@
> label = "art";
> reg = <0xff 0x01>;
> read-only;
> +
> + nvmem-layout {
> + compatible = "fixed-layout";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + macaddr_art_1002: macaddr@1002 {
> + compatible = "mac-base";
> + reg = <0x1002 0x6>;
> + #nvmem-cell-cells = <1>;
> + };
> + };
> };
> };
> };
> @@ -93,10 +105,8 @@
> ð1 {
> status = "okay";
>
> - nvmem-cells = <&macaddr_art_1002>;
> + nvmem-cells = <&macaddr_art_1002 0x40>;
> nvmem-cell-names = "mac-address";
> - mac-address-increment-byte = <3>;
> - mac-address-increment = <0x40>;
> };
>
> &mdio1 {
> @@ -108,13 +118,3 @@
>
> mtd-cal-data = <&art 0x1000>;
> };
> -
> -&art {
> - compatible = "nvmem-cells";
> - #address-cells = <1>;
> - #size-cells = <1>;
> -
> - macaddr_art_1002: macaddr@1002 {
> - reg = <0x1002 0x6>;
> - };
> -};
> diff --git a/target/linux/ath79/dts/ar9344_embeddedwireless_balin.dts
> b/target/linux/ath79/dts/ar9344_embeddedwireless_balin.dts
> index a84c273f86..de13865818 100644
> --- a/target/linux/ath79/dts/ar9344_embeddedwireless_balin.dts
> +++ b/target/linux/ath79/dts/ar9344_embeddedwireless_balin.dts
> @@ -83,16 +83,20 @@
> reg = <0xff 0x01>;
> read-only;
>
> - compatible = "nvmem-cells";
> - #address-cells = <1>;
> - #size-cells = <1>;
> -
> - calibration_art_1000: calibration_data@1000 {
> - reg = <0x1000 0x440>;
> - };
> -
> - macaddr_art_1002: macaddr@1002 {
> - reg = <0x1002 0x6>;
> + nvmem-layout {
> + compatible = "fixed-layout";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + calibration_art_1000:
> calibration_data@1000 {
> + reg = <0x1000 0x440>;
> + };
> +
> + macaddr_art_1002: macaddr@1002 {
> + compatible = "mac-base";
> + reg = <0x1002 0x6>;
> + #nvmem-cell-cells = <1>;
> + };
> };
> };
> };
> @@ -106,10 +110,8 @@
> ð1 {
> status = "okay";
>
> - nvmem-cells = <&macaddr_art_1002>;
> + nvmem-cells = <&macaddr_art_1002 0x40>;
> nvmem-cell-names = "mac-address";
> - mac-address-increment-byte = <3>;
> - mac-address-increment = <0x40>;
>
> gmac-config {
> device = <&gmac>;
> @@ -121,7 +123,7 @@
> &wmac {
> status = "okay";
>
> - nvmem-cells = <&macaddr_art_1002>, <&calibration_art_1000>;
> + nvmem-cells = <&macaddr_art_1002 0>, <&calibration_art_1000>;
> n
