[PATCH v6 5/7] net: cpsw: Add am33xx MACID readout

* Markus Pargmann [off-list ref] [140908 23:05]:

On Mon, Sep 08, 2014 at 09:51:17AM -0700, Tony Lindgren wrote:

quoted

* Markus Pargmann [off-list ref] [140907 10:20]:

quoted

This patch adds a function to get the MACIDs from the am33xx SoC
control module registers which hold unique vendor MACIDs. This is only
used if of_get_mac_address() fails to get a valid mac address.

...

quoted

@@ -1928,8 +1960,16 @@ static int cpsw_probe_dt(struct cpsw_platform_data *data,
 			 PHY_ID_FMT, mdio->name, phyid);
 
 		mac_addr = of_get_mac_address(slave_node);
-		if (mac_addr)
+		if (mac_addr) {
 			memcpy(slave_data->mac_addr, mac_addr, ETH_ALEN);
+		} else {
+			if (of_machine_is_compatible("ti,am33xx")) {
+				ret = cpsw_am33xx_cm_get_macid(&pdev->dev, i,
+							slave_data->mac_addr);
+				if (ret)
+					return ret;
+			}
+		}
 
 		slave_data->phy_if = of_get_phy_mode(slave_node);
 		if (slave_data->phy_if < 0) {

Thanks for updating this, this looks more future proof for adding
the dra7 related patch.

For the long run, it probably makes sense to add SoC specific
compatible values such as "ti,cpsw-am3350" and so on. Then the
mac address functions can be initialized based on the of_device_id
entry for .data. The wiring is cleary SoC specific here.

The hardware doesn't differ across the SoCs, so I thought it may be
better to keep one compatible and parse the machine compatible for the
MACID location. But different compatible values are also ok.

Yes both will work, and you're right the Ethernet hardware is
the same. I already forgot that we're getting mac address from the
system control module.. And that's really SoC specific so your solution
is better at least for now.

Regards,

Tony