mail archive of the barebox mailing list
 help / color / mirror / Atom feed
* [RFC 1/2] misc: Add MAC address mapper "driver"
@ 2016-02-01  5:57 Andrey Smirnov
  2016-02-01  5:57 ` [RFC 2/2] arm/dts: i.MX6: Use generic MAC address mapper Andrey Smirnov
  2016-02-01 10:10 ` [RFC 1/2] misc: Add MAC address mapper "driver" Sascha Hauer
  0 siblings, 2 replies; 8+ messages in thread
From: Andrey Smirnov @ 2016-02-01  5:57 UTC (permalink / raw)
  To: barebox; +Cc: Andrey Smirnov

Add Barebox specific device tree provisions to allow specifying MAC
addresses for network interfaces via device tree.

Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
---
 .../bindings/barebox/barebox,mac-address-map.rst   |  27 ++++
 drivers/misc/Makefile                              |   1 +
 drivers/misc/mac-address-map.c                     | 142 +++++++++++++++++++++
 3 files changed, 170 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/barebox/barebox,mac-address-map.rst
 create mode 100644 drivers/misc/mac-address-map.c

diff --git a/Documentation/devicetree/bindings/barebox/barebox,mac-address-map.rst b/Documentation/devicetree/bindings/barebox/barebox,mac-address-map.rst
new file mode 100644
index 0000000..1ac3062
--- /dev/null
+++ b/Documentation/devicetree/bindings/barebox/barebox,mac-address-map.rst
@@ -0,0 +1,27 @@
+barebox MAC address map
+=======================
+
+This driver allows to specify each network adapter's source of MAC address from the devicetree.
+
+Required properties:
+
+* ``compatible``: should be ``barebox,mac-address-map``
+
+Besides ``compatible`` property the node is expected to contain a
+number of children nodes each specifing a single "MAC source ->
+interface" mapping.
+
+Child node's required properties:
+* ``network-interface``: phandle corresponding to network interface
+* ``mac-location``: a pair of phandle to 'cdev' containing MAC address
+  and offset withing that 'cdev'
+
+Example::
+
+  mac-address-map {
+	compatible = "barebox,mac-address-map";
+	nic@0 {
+		network-interface = <&fec>;
+		mac-location = <&ocotp 0x88>;
+	};
+  };
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 487e4b8..94d2a4f 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -5,3 +5,4 @@
 obj-$(CONFIG_JTAG)		+= jtag.o
 obj-$(CONFIG_SRAM)		+= sram.o
 obj-$(CONFIG_STATE_DRV)		+= state.o
+obj-y += mac-address-map.o
diff --git a/drivers/misc/mac-address-map.c b/drivers/misc/mac-address-map.c
new file mode 100644
index 0000000..2161dc3
--- /dev/null
+++ b/drivers/misc/mac-address-map.c
@@ -0,0 +1,142 @@
+/*
+ * Copyright (C) 2016 Zodiac Inflight Innovation
+ * Author: Andrey Smirnov <andrew.smirnov@gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <common.h>
+#include <driver.h>
+#include <init.h>
+#include <malloc.h>
+#include <of.h>
+#include <state.h>
+#include <io.h>
+#include <fcntl.h>
+#include <net.h>
+
+#include <linux/err.h>
+
+/*
+ * a single MAC address reference has the form
+ * <&phandle regoffset>
+ */
+#define MAC_ADDRESS_PROPLEN	(2 * sizeof(__be32))
+#define MAC_ADDRESS_SIZE	8 /* FIXME ocotp driver is broken and
+				   * can't read non multiple of 4
+				   * quantities of data */
+
+static int mac_address_map_read_cdev(struct device_d *dev,
+				     struct cdev *cdev,
+				     size_t offset,
+				     uint8_t *addr)
+{
+	int ret;
+
+	ret = cdev_do_open(cdev, O_RDONLY);
+	if (ret < 0) {
+		dev_err(dev, "Failed to open %s\n", cdev->name);
+		return ret;
+	}
+
+	ret = cdev_read(cdev, addr, MAC_ADDRESS_SIZE, offset, 0);
+	cdev_close(cdev);
+
+	if (ret != MAC_ADDRESS_SIZE) {
+		dev_err(dev, "Failed to read MAC address\n");
+		return (ret < 0) ? ret : -EIO;
+	}
+
+	return 0;
+}
+
+static int mac_address_map_probe(struct device_d *dev)
+{
+	int ret;
+	struct device_node *np = dev->device_node;
+	struct device_node *child;
+
+	if (!np || !of_get_next_child(np, NULL))
+		return -EINVAL;
+
+	for_each_child_of_node(np, child) {
+		uint8_t addr[MAC_ADDRESS_SIZE];
+
+		struct {
+			const __be32 *prop;
+			int plen;
+			uint32_t phandle;
+			size_t offset;
+			struct cdev *cdev;
+			struct device_node *node;
+		} nvm;
+
+		struct device_node *nic_node;
+
+		nvm.prop = of_get_property(child, "mac-location", &nvm.plen);
+
+		if (!nvm.prop || nvm.plen != MAC_ADDRESS_PROPLEN) {
+			dev_err(dev, "'mac-location' lookup failed\n");
+			return -EINVAL;
+		}
+
+		nvm.phandle = be32_to_cpup(nvm.prop);
+		nvm.offset  = be32_to_cpup(++nvm.prop);
+
+		nvm.node = of_find_node_by_phandle(nvm.phandle);
+		if (!nvm.node) {
+			dev_err(dev, "'mac-location' lookup failed\n");
+			return -EINVAL;
+		}
+
+		nvm.cdev = cdev_by_device_node(nvm.node);
+		if (!nvm.cdev) {
+			dev_err(dev, "no OCOTP character device\n");
+			return -ENODEV;
+		}
+
+		nic_node = of_parse_phandle(child, "network-interface", 0);
+		if (!nic_node) {
+			dev_err(dev, "'network-interface' lookup failed\n");
+			return -EINVAL;
+		}
+
+		ret = mac_address_map_read_cdev(dev,
+						nvm.cdev, nvm.offset,
+						addr);
+		if (ret < 0)
+			return ret;
+
+		if (is_valid_ether_addr(addr))
+			of_eth_register_ethaddr(nic_node, addr);
+		else
+			dev_warn(dev,
+				 "%s @ 0x%x does not contain a vaild MAC address\n",
+				 nvm.node->name, nvm.offset);
+	}
+
+	return 0;
+}
+
+static __maybe_unused struct of_device_id mac_address_map_ids[] = {
+	{
+		.compatible = "barebox,mac-address-map",
+	}, {
+		/* sentinel */
+	}
+};
+
+static struct driver_d mac_address_map_driver = {
+	.name = "mac-address-map",
+	.probe = mac_address_map_probe,
+	.of_compatible = DRV_OF_COMPAT(mac_address_map_ids),
+};
+device_platform_driver(mac_address_map_driver);
-- 
2.5.0


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [RFC 2/2] arm/dts: i.MX6: Use generic MAC address mapper
  2016-02-01  5:57 [RFC 1/2] misc: Add MAC address mapper "driver" Andrey Smirnov
@ 2016-02-01  5:57 ` Andrey Smirnov
  2016-02-01 10:10 ` [RFC 1/2] misc: Add MAC address mapper "driver" Sascha Hauer
  1 sibling, 0 replies; 8+ messages in thread
From: Andrey Smirnov @ 2016-02-01  5:57 UTC (permalink / raw)
  To: barebox; +Cc: Andrey Smirnov

Use generic MAC address mapper infrastructure instead of custom driver
OCOTP driver bindings to specify OCOTP as a source of MAC address for
'fec' interfaces.

Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
---

Note: imx6sx-sdb.dts was not converted in the patch because it
specifies second MAC source as <&ocotp 0x632> which is an offset that
due to limitations of imx6_ocotp_cdev_read cannot be read.

I plan to include patches to fix the issue above in next versions of
this patchset

 arch/arm/dts/imx6dl-hummingboard.dts         | 11 ++++++++---
 arch/arm/dts/imx6dl-tx6u-801x.dts            | 13 +++++++++----
 arch/arm/dts/imx6dl-wandboard.dts            | 11 ++++++++---
 arch/arm/dts/imx6q-hummingboard.dts          | 11 ++++++++---
 arch/arm/dts/imx6q-phytec-pcaaxl3.dtsi       | 13 +++++++++----
 arch/arm/dts/imx6q-wandboard.dts             | 11 ++++++++---
 arch/arm/dts/imx6qdl-dfi-fs700-m60.dtsi      | 11 ++++++++---
 arch/arm/dts/imx6qdl-nitrogen6x.dtsi         | 13 +++++++++----
 arch/arm/dts/imx6qdl-phytec-pfla02.dtsi      | 14 ++++++++++----
 arch/arm/dts/imx6qdl-phytec-phycore-som.dtsi | 13 +++++++++----
 arch/arm/dts/imx6qdl-sabrelite.dtsi          | 13 +++++++++----
 arch/arm/dts/imx6qdl-sabresd.dtsi            | 11 +++++++++--
 arch/arm/dts/imx6qdl-tqma6x.dtsi             | 15 +++++++++++----
 arch/arm/dts/imx6s-riotboard.dts             | 13 +++++++++----
 14 files changed, 124 insertions(+), 49 deletions(-)

diff --git a/arch/arm/dts/imx6dl-hummingboard.dts b/arch/arm/dts/imx6dl-hummingboard.dts
index 2314965..e47ccd5 100644
--- a/arch/arm/dts/imx6dl-hummingboard.dts
+++ b/arch/arm/dts/imx6dl-hummingboard.dts
@@ -17,10 +17,15 @@
 			device-path = &usdhc2, "partname:barebox-environment";
 		};
 	};
-};
 
-&ocotp {
-	barebox,provide-mac-address = <&fec 0x620>;
+	mac-address-map {
+		compatible = "barebox,mac-address-map";
+
+		nic@0 {
+			network-interface = <&fec>;
+			mac-location = <&ocotp 0x88>;
+		};
+	};
 };
 
 &usdhc2 {
diff --git a/arch/arm/dts/imx6dl-tx6u-801x.dts b/arch/arm/dts/imx6dl-tx6u-801x.dts
index a480408..9ebc31f 100644
--- a/arch/arm/dts/imx6dl-tx6u-801x.dts
+++ b/arch/arm/dts/imx6dl-tx6u-801x.dts
@@ -13,6 +13,15 @@
 			device-path = &gpmi, "partname:barebox-environment";
 		};
 	};
+
+	mac-address-map {
+		compatible = "barebox,mac-address-map";
+
+		nic@0 {
+			network-interface = <&fec>;
+			mac-location = <&ocotp 0x88>;
+		};
+	};
 };
 
 &gpmi {
@@ -59,7 +68,3 @@
 &fec {
 	phy-reset-duration = <22>;
 };
-
-&ocotp {
-	barebox,provide-mac-address = <&fec 0x620>;
-};
diff --git a/arch/arm/dts/imx6dl-wandboard.dts b/arch/arm/dts/imx6dl-wandboard.dts
index a867400..ff9904d 100644
--- a/arch/arm/dts/imx6dl-wandboard.dts
+++ b/arch/arm/dts/imx6dl-wandboard.dts
@@ -15,10 +15,15 @@
 	memory {
 		reg = <0x0 0x0>;
 	};
-};
 
-&ocotp {
-	barebox,provide-mac-address = <&fec 0x620>;
+	mac-address-map {
+		compatible = "barebox,mac-address-map";
+
+		nic@0 {
+			network-interface = <&fec>;
+			mac-location = <&ocotp 0x88>;
+		};
+	};
 };
 
 &usdhc3 {
diff --git a/arch/arm/dts/imx6q-hummingboard.dts b/arch/arm/dts/imx6q-hummingboard.dts
index e1d2fa8..8cc1218 100644
--- a/arch/arm/dts/imx6q-hummingboard.dts
+++ b/arch/arm/dts/imx6q-hummingboard.dts
@@ -17,10 +17,15 @@
 			device-path = &usdhc2, "partname:barebox-environment";
 		};
 	};
-};
 
-&ocotp {
-	barebox,provide-mac-address = <&fec 0x620>;
+	mac-address-map {
+		compatible = "barebox,mac-address-map";
+
+		nic@0 {
+			network-interface = <&fec>;
+			mac-location = <&ocotp 0x88>;
+		};
+	};
 };
 
 &usdhc2 {
diff --git a/arch/arm/dts/imx6q-phytec-pcaaxl3.dtsi b/arch/arm/dts/imx6q-phytec-pcaaxl3.dtsi
index 0522465..f379517 100644
--- a/arch/arm/dts/imx6q-phytec-pcaaxl3.dtsi
+++ b/arch/arm/dts/imx6q-phytec-pcaaxl3.dtsi
@@ -29,6 +29,15 @@
 			status = "disabled";
 		};
 	};
+
+	mac-address-map {
+		compatible = "barebox,mac-address-map";
+
+		nic@0 {
+			network-interface = <&fec>;
+			mac-location = <&ocotp 0x88>;
+		};
+	};
 };
 
 &i2c1 {
@@ -160,10 +169,6 @@
 	};
 };
 
-&ocotp {
-	barebox,provide-mac-address = <&fec 0x620>;
-};
-
 &uart3 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_uart3>;
diff --git a/arch/arm/dts/imx6q-wandboard.dts b/arch/arm/dts/imx6q-wandboard.dts
index 26d8a00..357fdfd 100644
--- a/arch/arm/dts/imx6q-wandboard.dts
+++ b/arch/arm/dts/imx6q-wandboard.dts
@@ -15,10 +15,15 @@
 	memory {
 		reg = <0x0 0x0>;
 	};
-};
 
-&ocotp {
-	barebox,provide-mac-address = <&fec 0x620>;
+	mac-address-map {
+		compatible = "barebox,mac-address-map";
+
+		nic@0 {
+			network-interface = <&fec>;
+			mac-location = <&ocotp 0x88>;
+		};
+	};
 };
 
 &usdhc3 {
diff --git a/arch/arm/dts/imx6qdl-dfi-fs700-m60.dtsi b/arch/arm/dts/imx6qdl-dfi-fs700-m60.dtsi
index 5c7bcd3..4fdfff1 100644
--- a/arch/arm/dts/imx6qdl-dfi-fs700-m60.dtsi
+++ b/arch/arm/dts/imx6qdl-dfi-fs700-m60.dtsi
@@ -9,10 +9,15 @@
 			device-path = &usdhc4, "partname:boot1";
 		};
 	};
-};
 
-&ocotp {
-	barebox,provide-mac-address = <&fec 0x620>;
+	mac-address-map {
+		compatible = "barebox,mac-address-map";
+
+		nic@0 {
+			network-interface = <&fec>;
+			mac-location = <&ocotp 0x88>;
+		};
+	};
 };
 
 &usbh1 {
diff --git a/arch/arm/dts/imx6qdl-nitrogen6x.dtsi b/arch/arm/dts/imx6qdl-nitrogen6x.dtsi
index 8fcd4e4..e9c64d9 100644
--- a/arch/arm/dts/imx6qdl-nitrogen6x.dtsi
+++ b/arch/arm/dts/imx6qdl-nitrogen6x.dtsi
@@ -23,6 +23,15 @@
 			device-path = &flash, "partname:barebox-environment";
 		};
 	};
+
+	mac-address-map {
+		compatible = "barebox,mac-address-map";
+
+		nic@0 {
+			network-interface = <&fec>;
+			mac-location = <&ocotp 0x88>;
+		};
+	};
 };
 
 &flash {
@@ -40,10 +49,6 @@
 	};
 };
 
-&ocotp {
-	barebox,provide-mac-address = <&fec 0x620>;
-};
-
 &usbh1 {
 	phy_type = "utmi";
 	dr_mode = "host";
diff --git a/arch/arm/dts/imx6qdl-phytec-pfla02.dtsi b/arch/arm/dts/imx6qdl-phytec-pfla02.dtsi
index b79ce2c..6d4d067 100644
--- a/arch/arm/dts/imx6qdl-phytec-pfla02.dtsi
+++ b/arch/arm/dts/imx6qdl-phytec-pfla02.dtsi
@@ -54,6 +54,16 @@
 			status = "disabled";
 		};
 	};
+
+	mac-address-map {
+		compatible = "barebox,mac-address-map";
+
+		nic@0 {
+			network-interface = <&fec>;
+			mac-location = <&ocotp 0x88>;
+		};
+	};
+
 };
 
 &ecspi3 {
@@ -170,10 +180,6 @@
 	};
 };
 
-&ocotp {
-	barebox,provide-mac-address = <&fec 0x620>;
-};
-
 &usdhc3 {
 	#address-cells = <1>;
 	#size-cells = <1>;
diff --git a/arch/arm/dts/imx6qdl-phytec-phycore-som.dtsi b/arch/arm/dts/imx6qdl-phytec-phycore-som.dtsi
index 2a975d1..444d707 100644
--- a/arch/arm/dts/imx6qdl-phytec-phycore-som.dtsi
+++ b/arch/arm/dts/imx6qdl-phytec-phycore-som.dtsi
@@ -33,6 +33,15 @@
 			status = "disabled";
 		};
 	};
+
+	mac-address-map {
+		compatible = "barebox,mac-address-map";
+
+		nic@0 {
+			network-interface = <&fec>;
+			mac-location = <&ocotp 0x88>;
+		};
+	};
 };
 
 &ecspi1 {
@@ -227,10 +236,6 @@
 	};
 };
 
-&ocotp {
-	barebox,provide-mac-address = <&fec 0x620>;
-};
-
 &uart2 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_uart2>;
diff --git a/arch/arm/dts/imx6qdl-sabrelite.dtsi b/arch/arm/dts/imx6qdl-sabrelite.dtsi
index d5a6ff4..b89e60c 100644
--- a/arch/arm/dts/imx6qdl-sabrelite.dtsi
+++ b/arch/arm/dts/imx6qdl-sabrelite.dtsi
@@ -23,6 +23,15 @@
 			device-path = &flash, "partname:barebox-environment";
 		};
 	};
+
+	mac-address-map {
+		compatible = "barebox,mac-address-map";
+
+		nic@0 {
+			network-interface = <&fec>;
+			mac-location = <&ocotp 0x88>;
+		};
+	};
 };
 
 &flash {
@@ -40,10 +49,6 @@
 	};
 };
 
-&ocotp {
-	barebox,provide-mac-address = <&fec 0x620>;
-};
-
 &usbh1 {
 	phy_type = "utmi";
 	dr_mode = "host";
diff --git a/arch/arm/dts/imx6qdl-sabresd.dtsi b/arch/arm/dts/imx6qdl-sabresd.dtsi
index 32318cf..5f36d1d 100644
--- a/arch/arm/dts/imx6qdl-sabresd.dtsi
+++ b/arch/arm/dts/imx6qdl-sabresd.dtsi
@@ -12,8 +12,15 @@
 
 #include <arm/imx6qdl-sabresd.dtsi>
 
-&ocotp {
-	barebox,provide-mac-address = <&fec 0x620>;
+/ {
+	mac-address-map {
+		compatible = "barebox,mac-address-map";
+
+		nic@0 {
+			network-interface = <&fec>;
+			mac-location = <&ocotp 0x88>;
+		};
+	};
 };
 
 &usbh1 {
diff --git a/arch/arm/dts/imx6qdl-tqma6x.dtsi b/arch/arm/dts/imx6qdl-tqma6x.dtsi
index f0b1a0d..f8a66a6 100644
--- a/arch/arm/dts/imx6qdl-tqma6x.dtsi
+++ b/arch/arm/dts/imx6qdl-tqma6x.dtsi
@@ -9,6 +9,17 @@
  * http://www.gnu.org/copyleft/gpl.html
  */
 
+/ {
+	mac-address-map {
+		compatible = "barebox,mac-address-map";
+
+		nic@0 {
+			network-interface = <&fec>;
+			mac-location = <&ocotp 0x88>;
+		};
+	};
+};
+
 &ecspi1 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_ecspi1>;
@@ -91,10 +102,6 @@
 	};
 };
 
-&ocotp {
-	barebox,provide-mac-address = <&fec 0x620>;
-};
-
 &i2c1 {
 	status = "okay";
 	clock-frequency = <100000>;
diff --git a/arch/arm/dts/imx6s-riotboard.dts b/arch/arm/dts/imx6s-riotboard.dts
index e14363f..c4eda90 100644
--- a/arch/arm/dts/imx6s-riotboard.dts
+++ b/arch/arm/dts/imx6s-riotboard.dts
@@ -57,6 +57,15 @@
 			regulator-always-on;
 		};
 	};
+
+	mac-address-map {
+		compatible = "barebox,mac-address-map";
+
+		nic@0 {
+			network-interface = <&fec>;
+			mac-location = <&ocotp 0x88>;
+		};
+	};
 };
 
 &iomuxc {
@@ -389,7 +398,3 @@
 	pinctrl-0 = <&pinctrl_i2c4_2>;
 };
 
-&ocotp {
-	barebox,provide-mac-address = <&fec 0x620>;
-};
-
-- 
2.5.0


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [RFC 1/2] misc: Add MAC address mapper "driver"
  2016-02-01  5:57 [RFC 1/2] misc: Add MAC address mapper "driver" Andrey Smirnov
  2016-02-01  5:57 ` [RFC 2/2] arm/dts: i.MX6: Use generic MAC address mapper Andrey Smirnov
@ 2016-02-01 10:10 ` Sascha Hauer
  2016-02-01 19:18   ` Trent Piepho
  2016-02-03  1:09   ` Andrey Smirnov
  1 sibling, 2 replies; 8+ messages in thread
From: Sascha Hauer @ 2016-02-01 10:10 UTC (permalink / raw)
  To: Andrey Smirnov; +Cc: barebox

On Sun, Jan 31, 2016 at 09:57:13PM -0800, Andrey Smirnov wrote:
> Add Barebox specific device tree provisions to allow specifying MAC
> addresses for network interfaces via device tree.
> 
> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
> ---
>  .../bindings/barebox/barebox,mac-address-map.rst   |  27 ++++
>  drivers/misc/Makefile                              |   1 +
>  drivers/misc/mac-address-map.c                     | 142 +++++++++++++++++++++
>  3 files changed, 170 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/barebox/barebox,mac-address-map.rst
>  create mode 100644 drivers/misc/mac-address-map.c
> 
> diff --git a/Documentation/devicetree/bindings/barebox/barebox,mac-address-map.rst b/Documentation/devicetree/bindings/barebox/barebox,mac-address-map.rst
> new file mode 100644
> index 0000000..1ac3062
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/barebox/barebox,mac-address-map.rst
> @@ -0,0 +1,27 @@
> +barebox MAC address map
> +=======================
> +
> +This driver allows to specify each network adapter's source of MAC address from the devicetree.
> +
> +Required properties:
> +
> +* ``compatible``: should be ``barebox,mac-address-map``
> +
> +Besides ``compatible`` property the node is expected to contain a
> +number of children nodes each specifing a single "MAC source ->
> +interface" mapping.
> +
> +Child node's required properties:
> +* ``network-interface``: phandle corresponding to network interface
> +* ``mac-location``: a pair of phandle to 'cdev' containing MAC address
> +  and offset withing that 'cdev'
> +
> +Example::
> +
> +  mac-address-map {
> +	compatible = "barebox,mac-address-map";
> +	nic@0 {
> +		network-interface = <&fec>;
> +		mac-location = <&ocotp 0x88>;
> +	};
> +  };

I wonder if the correct way to do this wouldn't be nvmem, see
Documentation/devicetree/bindings/nvmem/nvmem.txt in the Kernel.
This would mandate a binding like:

	ocotp {
		mac1: mac@88 {
			reg = <0x88 0x6>;
		};
	};

	&fec {
		nvmem-cells = <&mac1>;
		nvmem-cell-names = "mac-address";
	};

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [RFC 1/2] misc: Add MAC address mapper "driver"
  2016-02-01 10:10 ` [RFC 1/2] misc: Add MAC address mapper "driver" Sascha Hauer
@ 2016-02-01 19:18   ` Trent Piepho
  2016-02-03  1:14     ` Andrey Smirnov
  2016-02-03  1:09   ` Andrey Smirnov
  1 sibling, 1 reply; 8+ messages in thread
From: Trent Piepho @ 2016-02-01 19:18 UTC (permalink / raw)
  To: Sascha Hauer; +Cc: Andrey Smirnov, barebox

On Mon, 2016-02-01 at 11:10 +0100, Sascha Hauer wrote:
> On Sun, Jan 31, 2016 at 09:57:13PM -0800, Andrey Smirnov wrote:
> > Add Barebox specific device tree provisions to allow specifying MAC
> > addresses for network interfaces via device tree.
> > 
> > +
> > +Child node's required properties:
> > +* ``network-interface``: phandle corresponding to network interface
> > +* ``mac-location``: a pair of phandle to 'cdev' containing MAC address
> > +  and offset withing that 'cdev'
> > +
> > +Example::
> > +
> > +  mac-address-map {
> > +	compatible = "barebox,mac-address-map";
> > +	nic@0 {
> > +		network-interface = <&fec>;
> > +		mac-location = <&ocotp 0x88>;
> > +	};
> > +  };
> 
> I wonder if the correct way to do this wouldn't be nvmem, see
> Documentation/devicetree/bindings/nvmem/nvmem.txt in the Kernel.
> This would mandate a binding like:
> 
> 	ocotp {
> 		mac1: mac@88 {
> 			reg = <0x88 0x6>;
> 		};
> 	};
> 
> 	&fec {
> 		nvmem-cells = <&mac1>;
> 		nvmem-cell-names = "mac-address";
> 	};

The way imx28 works in the kernel is to just store the extension in the
OCOTP.  The OUI is determined from the board's compatible property and a
hard coded table in the kernel.  See arch/arm/mach-mxs/mach-mxs.c

While, IMHO, the hard coded table is ugly, and should have died long
ago, there are board that don't have the entire mac burned into OCOTP.
It seems like neither of these bindings could support a board like this.

If you look at Documentation/devicetree/bindings/c6x/dscr.txt, there is
already a binding for a different system of loading a MAC from OCOTP:
- ti,dscr-mac-fuse-regs
    MAC addresses are contained in two registers. Each element of a MAC address
    is contained in a single byte. This property has two tuples. Each tuple has
    a register offset and four cells representing bytes in the register from
    most significant to least. The value of these four cells is the MAC byte
    index (1-6) of the byte within the register. A value of 0 means the byte
    is unused in the MAC address.

For a board I did some time ago I reused this property but extended it
slightly to allow N tuples instead of just 2.  Example for above:

        &fec {
                mac-fuse-regs = <0x88 0x01020304
                                 0x8c 0x05060000>;
        };

Example for mxs style partial mac in OCOTP:
        &fec {
                /* OUI is not in OCOTP, just extension */
                mac-address = <0x11 0x22 0x33 0 0 0>; 

                mac-fuse-regs = <0x00 0x00040506>;
        };

Example for two controllers that share an OUI:
        &fec1 {
                mac-fuse-regs = <0x00 0x00010203   /* OUI */
                                 0x80 0x00040506>; /* Extension */
        };
        &fec2 {
                mac-fuse-regs = <0x00 0x00010203   /* OUI */
                                 0x84 0x00040506>; /* Extension */
        };

This doesn't allow the MAC to come from an EEPROM.  I think it would be
nice if the same system could support chips with OCOTP and also EEPROMS
or other storage systems.
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [RFC 1/2] misc: Add MAC address mapper "driver"
  2016-02-01 10:10 ` [RFC 1/2] misc: Add MAC address mapper "driver" Sascha Hauer
  2016-02-01 19:18   ` Trent Piepho
@ 2016-02-03  1:09   ` Andrey Smirnov
  1 sibling, 0 replies; 8+ messages in thread
From: Andrey Smirnov @ 2016-02-03  1:09 UTC (permalink / raw)
  To: Sascha Hauer; +Cc: barebox

>
> I wonder if the correct way to do this wouldn't be nvmem, see
> Documentation/devicetree/bindings/nvmem/nvmem.txt in the Kernel.
> This would mandate a binding like:
>
>         ocotp {
>                 mac1: mac@88 {
>                         reg = <0x88 0x6>;
>                 };
>         };
>
>         &fec {
>                 nvmem-cells = <&mac1>;
>                 nvmem-cell-names = "mac-address";
>         };

I completely forgot about that API! I think you are right that would
be a better way to implement what I am trying to do. I'll do some
experimentation with this approach and see what I can come up with.

Thanks,
Andrey

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [RFC 1/2] misc: Add MAC address mapper "driver"
  2016-02-01 19:18   ` Trent Piepho
@ 2016-02-03  1:14     ` Andrey Smirnov
  2016-02-03 18:40       ` Trent Piepho
  0 siblings, 1 reply; 8+ messages in thread
From: Andrey Smirnov @ 2016-02-03  1:14 UTC (permalink / raw)
  To: Trent Piepho; +Cc: barebox

On Mon, Feb 1, 2016 at 11:18 AM, Trent Piepho <tpiepho@kymetacorp.com> wrote:
> On Mon, 2016-02-01 at 11:10 +0100, Sascha Hauer wrote:
>> On Sun, Jan 31, 2016 at 09:57:13PM -0800, Andrey Smirnov wrote:
>> > Add Barebox specific device tree provisions to allow specifying MAC
>> > addresses for network interfaces via device tree.
>> >
>> > +
>> > +Child node's required properties:
>> > +* ``network-interface``: phandle corresponding to network interface
>> > +* ``mac-location``: a pair of phandle to 'cdev' containing MAC address
>> > +  and offset withing that 'cdev'
>> > +
>> > +Example::
>> > +
>> > +  mac-address-map {
>> > +   compatible = "barebox,mac-address-map";
>> > +   nic@0 {
>> > +           network-interface = <&fec>;
>> > +           mac-location = <&ocotp 0x88>;
>> > +   };
>> > +  };
>>
>> I wonder if the correct way to do this wouldn't be nvmem, see
>> Documentation/devicetree/bindings/nvmem/nvmem.txt in the Kernel.
>> This would mandate a binding like:
>>
>>       ocotp {
>>               mac1: mac@88 {
>>                       reg = <0x88 0x6>;
>>               };
>>       };
>>
>>       &fec {
>>               nvmem-cells = <&mac1>;
>>               nvmem-cell-names = "mac-address";
>>       };
>
> The way imx28 works in the kernel is to just store the extension in the
> OCOTP.  The OUI is determined from the board's compatible property and a
> hard coded table in the kernel.  See arch/arm/mach-mxs/mach-mxs.c
>
> While, IMHO, the hard coded table is ugly, and should have died long
> ago, there are board that don't have the entire mac burned into OCOTP.
> It seems like neither of these bindings could support a board like this.
>

What if you created a 'nvmem' provider whose only job is to take a
blob from DT, a phandle to another 'nvmem' provider and to return the
combined data from both sources. Wouldn't it work for the use-case you
are describing?

Andrey

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [RFC 1/2] misc: Add MAC address mapper "driver"
  2016-02-03  1:14     ` Andrey Smirnov
@ 2016-02-03 18:40       ` Trent Piepho
  2016-02-03 20:16         ` Andrey Smirnov
  0 siblings, 1 reply; 8+ messages in thread
From: Trent Piepho @ 2016-02-03 18:40 UTC (permalink / raw)
  To: Andrey Smirnov; +Cc: barebox

On Tue, 2016-02-02 at 17:14 -0800, Andrey Smirnov wrote:
> On Mon, Feb 1, 2016 at 11:18 AM, Trent Piepho <tpiepho@kymetacorp.com> wrote:
> > The way imx28 works in the kernel is to just store the extension in the
> > OCOTP.  The OUI is determined from the board's compatible property and a
> > hard coded table in the kernel.  See arch/arm/mach-mxs/mach-mxs.c
> >
> > While, IMHO, the hard coded table is ugly, and should have died long
> > ago, there are board that don't have the entire mac burned into OCOTP.
> > It seems like neither of these bindings could support a board like this.
> >
> 
> What if you created a 'nvmem' provider whose only job is to take a
> blob from DT, a phandle to another 'nvmem' provider and to return the
> combined data from both sources. Wouldn't it work for the use-case you
> are describing?

Not sure what it would look like, example?

One thing about the imx28 OCOTP is that the entire MAC isn't in the
OCOTP.  The OUI part comes from "elsewhere".

In the current kernel, that elsewhere is a hardcoded /board/compatible
to OUI mapping.  What I did was use the mac-address property to store
the OUI.  I think that makes a lot more sense.  Actually, storing the
whole MAC in the ocotp would have made a lot more sense!  But it's one
time programmable and that's the way all the boards were made.

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [RFC 1/2] misc: Add MAC address mapper "driver"
  2016-02-03 18:40       ` Trent Piepho
@ 2016-02-03 20:16         ` Andrey Smirnov
  0 siblings, 0 replies; 8+ messages in thread
From: Andrey Smirnov @ 2016-02-03 20:16 UTC (permalink / raw)
  To: Trent Piepho; +Cc: barebox

On Wed, Feb 3, 2016 at 10:40 AM, Trent Piepho <tpiepho@kymetacorp.com> wrote:
> On Tue, 2016-02-02 at 17:14 -0800, Andrey Smirnov wrote:
>> On Mon, Feb 1, 2016 at 11:18 AM, Trent Piepho <tpiepho@kymetacorp.com> wrote:
>> > The way imx28 works in the kernel is to just store the extension in the
>> > OCOTP.  The OUI is determined from the board's compatible property and a
>> > hard coded table in the kernel.  See arch/arm/mach-mxs/mach-mxs.c
>> >
>> > While, IMHO, the hard coded table is ugly, and should have died long
>> > ago, there are board that don't have the entire mac burned into OCOTP.
>> > It seems like neither of these bindings could support a board like this.
>> >
>>
>> What if you created a 'nvmem' provider whose only job is to take a
>> blob from DT, a phandle to another 'nvmem' provider and to return the
>> combined data from both sources. Wouldn't it work for the use-case you
>> are describing?
>
> Not sure what it would look like, example?

I am thinking of something similar to what you describe in "nvmem"
thread. You'd have a software scatter-gather "engine" that would just
take a description of multiple small chunks of memory and represent it
as a continuous property accessible via "nvmem" API. Something like:

mac-address-node {
           compatible = "nvmem-sg"

           composite_mac: mac@0 {
                     reg = <&nvmem1_cell 0x0 0x4
                                 &nvmem2_cell 0x0 0x2
                               >;
           };
 };

So you'd get a 'composite_mac' nvmem-cell that in term is comprised of
4 bytes @ offset 0x0 of "nvmem1_cell" and 2 bytes @ offset 0x0 of
"nvmem2_cell".


>
> One thing about the imx28 OCOTP is that the entire MAC isn't in the
> OCOTP.  The OUI part comes from "elsewhere".
>
> In the current kernel, that elsewhere is a hardcoded /board/compatible
> to OUI mapping.  What I did was use the mac-address property to store
> the OUI.  I think that makes a lot more sense.  Actually, storing the
> whole MAC in the ocotp would have made a lot more sense!  But it's one
> time programmable and that's the way all the boards were made.
>

From looking at the mach-mxs.c and assuming I didn't miss any
important details (which is a big if), it seems to me that it would
still be possible to cover this use-case by introducing(or extending
'nvmem' driver) an additional "nvmem" compatible entity whose only job
would be is to present data hard coded in its corresponding DT-node
via "nvmem" API.

So, say for example for apf28(OUI_ARMADEUS) you'd have something like:

board-oui-node {
      board_oui_cell: oui_cell@0 {
             immediate-data = [0x00  0x1e 0xac];
      };
};

and then you should be able to use <&board_oui_cell> in the
scatter-gatherer node from above.

Andrey

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2016-02-03 20:16 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-02-01  5:57 [RFC 1/2] misc: Add MAC address mapper "driver" Andrey Smirnov
2016-02-01  5:57 ` [RFC 2/2] arm/dts: i.MX6: Use generic MAC address mapper Andrey Smirnov
2016-02-01 10:10 ` [RFC 1/2] misc: Add MAC address mapper "driver" Sascha Hauer
2016-02-01 19:18   ` Trent Piepho
2016-02-03  1:14     ` Andrey Smirnov
2016-02-03 18:40       ` Trent Piepho
2016-02-03 20:16         ` Andrey Smirnov
2016-02-03  1:09   ` Andrey Smirnov

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox