net: cpsw: Support for am335x chip MACIDs

drivers/net/ethernet/ti/Makefile obj-$(CONFIG_TI_DAVINCI_EMAC) += davinci_emac.o · line 13

Quoted 12 lines

drivers/net/ethernet/ti/Makefile +1 -0

index 9cfaab8152be..5a31c2b322ee 100644
@@ -8,5 +8,6 @@ obj-$(CONFIG_TI_DAVINCI_EMAC) += davinci_emac.o
 obj-$(CONFIG_TI_DAVINCI_MDIO) += davinci_mdio.o
 obj-$(CONFIG_TI_DAVINCI_CPDMA) += davinci_cpdma.o
 obj-$(CONFIG_TI_CPSW_PHY_SEL) += cpsw-phy-sel.o
+obj-$(CONFIG_TI_CPSW_CTRL_MACID) += cpsw-ctrl-macid.o
 obj-$(CONFIG_TI_CPSW) += ti_cpsw.o
 ti_cpsw-y := cpsw_ale.o cpsw.o cpts.o

Leftover from your last series?

drivers/net/ethernet/ti/cpsw.c static void cpsw_slave_init(struct cpsw_slave *slave, struct cpsw_priv *priv, · line 1829

Quoted 7 lines

drivers/net/ethernet/ti/cpsw.c +6 -0

+	mac_addr[5] = (macid_lo >> 8) & 0xff;
+	mac_addr[4] = macid_lo & 0xff;
+	mac_addr[3] = (macid_hi >> 24) & 0xff;
+	mac_addr[2] = (macid_hi >> 16) & 0xff;
+	mac_addr[1] = (macid_hi >> 8) & 0xff;
+	mac_addr[0] = macid_hi & 0xff;

That looks twisted, but I assume that you tested it is correct.

drivers/net/ethernet/ti/cpsw.c static void cpsw_slave_init(struct cpsw_slave *slave, struct cpsw_priv *priv, · line 1830

Quoted 7 lines · Markus Pargmann

drivers/net/ethernet/ti/cpsw.c +7 -0

+	mac_addr[5] = (macid_lo >> 8) & 0xff;
+	mac_addr[4] = macid_lo & 0xff;
+	mac_addr[3] = (macid_hi >> 24) & 0xff;
+	mac_addr[2] = (macid_hi >> 16) & 0xff;
+	mac_addr[1] = (macid_hi >> 8) & 0xff;
+	mac_addr[0] = macid_hi & 0xff;
+

This will fail incase of DRA74x and DRA72x platforms, please check for u-boot src for parsing logic as TRM is not out yet. Below is the actual code for DRA7 platforms for MAC address parsing

mac_addr[0] = (mac_hi & 0xFF0000) >> 16;
mac_addr[1] = (mac_hi & 0xFF00) >> 8;
mac_addr[2] = mac_hi & 0xFF;
mac_addr[3] = (mac_lo & 0xFF0000) >> 16;
mac_addr[4] = (mac_lo & 0xFF00) >> 8;
mac_addr[5] = mac_lo & 0xFF;

From U-Boot:

Quoted 12 lines · On Mon, 18 Aug 2014 23:54:26 +0530 Mugunthan V N <[email protected]> wrote:

drivers/net/ethernet/ti/cpsw.c static void cpsw_slave_init(struct cpsw_slave *slave, struct cpsw_priv *priv, · line 1830

Quoted 7 lines · Markus Pargmann

drivers/net/ethernet/ti/cpsw.c +7 -0

+	mac_addr[5] = (macid_lo >> 8) & 0xff;
+	mac_addr[4] = macid_lo & 0xff;
+	mac_addr[3] = (macid_hi >> 24) & 0xff;
+	mac_addr[2] = (macid_hi >> 16) & 0xff;
+	mac_addr[1] = (macid_hi >> 8) & 0xff;
+	mac_addr[0] = macid_hi & 0xff;
+

This will fail incase of DRA74x and DRA72x platforms, please check for u-boot src for parsing logic as TRM is not out yet. Below is the actual code for DRA7 platforms for MAC address parsing

Quoted 7 lines

mac_addr[0] = (mac_hi & 0xFF0000) >> 16;
mac_addr[1] = (mac_hi & 0xFF00) >> 8;
mac_addr[2] = mac_hi & 0xFF;
mac_addr[3] = (mac_lo & 0xFF0000) >> 16;
mac_addr[4] = (mac_lo & 0xFF00) >> 8;
mac_addr[5] = mac_lo & 0xFF;

But this fails with my beaglebone white.

I tested Markus's patches and it came up with the same ethaddr that U-Boot had.

From U-Boot:

ethaddr=d4:94:a1:8b:ec:78

With Markus's changes:

eth0 Link encap:Ethernet HWaddr D4:94:A1:8B:EC:78

But when I changed the code to match what you wrote, I got this:

eth0 Link encap:Ethernet HWaddr CE:5A:8B:0E:44:45

but it also gave me:

cpsw 4a100000.ethernet: Random MACID = ce:5a:8b:0e:44:45

which means it failed the valid mac test.

Here's how I implemented your change:

#if 1
        mac_addr[0] = (macid_hi & 0xFF0000) >> 16;
        mac_addr[1] = (macid_hi & 0xFF00) >> 8;
        mac_addr[2] = macid_hi & 0xFF;
        mac_addr[3] = (macid_lo & 0xFF0000) >> 16;
        mac_addr[4] = (macid_lo & 0xFF00) >> 8;
        mac_addr[5] = macid_lo & 0xFF;

#else   
        mac_addr[5] = (macid_lo >> 8) & 0xff;
        mac_addr[4] = macid_lo & 0xff;
        mac_addr[3] = (macid_hi >> 24) & 0xff;
        mac_addr[2] = (macid_hi >> 16) & 0xff;
        mac_addr[1] = (macid_hi >> 8) & 0xff;
        mac_addr[0] = macid_hi & 0xff;

#endif

Just to be consistent, I updated the code as this too:

        mac_addr[0] = (macid_hi >> 16) & 0xFF;
        mac_addr[1] = (macid_hi >> 8) & 0xFF;
        mac_addr[2] = macid_hi & 0xFF;
        mac_addr[3] = (macid_lo >> 16) & 0xFF;
        mac_addr[4] = (macid_lo >> 8) & 0xFF;
        mac_addr[5] = macid_lo & 0xFF;

With the same affect.

Thus, for this patchset, as is:

Tested-by Steven Rostedt <[email protected]>

This will fail for DRA7xx not in AM33xx

Quoted 4 lines

Thus, for this patchset, as is:

Tested-by Steven Rostedt <[email protected]>

This will fail for DRA7xx not in AM33xx

Regards
Mugunthan V N
--

Hello Mugunthan,

Quoted 5 lines · Mugunthan V N

Quoted 4 lines

Thus, for this patchset, as is:

Tested-by Steven Rostedt <[email protected]>

Quoted 2 lines

This will fail for DRA7xx not in AM33xx

cpsw_am33xx_cm_get_macid() checks for of_machine_is_compatible("ti,am33xx") and returns 0 if the machine is not an am33xx. cpsw_probe_dt() only propagates the return value if is not 0 so this patch does not change the semantics for other SoCs besides am33xx.

Hi,

Quoted 8 lines · Javier Martinez Canillas

Hello Mugunthan,

Quoted 5 lines · Mugunthan V N

Quoted 3 lines

Thus, for this patchset, as is:

Tested-by Steven Rostedt <[email protected]>

This will fail for DRA7xx not in AM33xx

Quoted 5 lines

cpsw_am33xx_cm_get_macid() checks for of_machine_is_compatible("ti,am33xx") and returns 0 if the machine is not an am33xx. cpsw_probe_dt() only propagates the return value if is not 0 so this patch does not change the semantics for other SoCs besides am33xx.

Yes, this patch is only about the am33xx. I don't have the DRA7xx hardware so I am not able to test on that hardware. Mugunthan, perhaps you can supply some followup patches for DRA7xx.

Hi,

This series adds support to the cpsw driver to read the MACIDs of the am335x chip and use them as fallback. These addresses are only used if there are no mac addresses in the devicetree, for example set by a bootloader.

In v3 I removed the previously seperate driver and included the changes into the main cpsw driver. I now check for a am33xx machine to not make this operation when running on davinci.

Patches 1-4 are some minor fixes for the cpsw driver. Patch 5 adds the readout support.
Patches 6 and 7 are for am33xx.dtsi to actually enable this feature.