kernel/drivers/net/ethernet/ti/davinci_emac.c, branch linux-4.3.y

net: davinci_emac: fix error return code

2015-08-25T20:37:31Z

Propagate error code on failure. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // @@ identifier ret; expression e1,e2; @@ ( if (\(ret < 0\|ret != 0\)) { ... return ret; } | ret = 0 ) ... when != ret = e1 when != &ret *if(...) { ... when != ret = e2 when forall return ret; } // Signed-off-by: Julia Lawall Signed-off-by: David S. Miller

net: davinci_emac: Get device MAC on 3517

2015-01-31T01:42:01Z

Looks like on 3517 davinci_emac MAC address registers have a different layout compared to dm816x and am33xx. Let's add a function to get the 3517 MAC address. Signed-off-by: Tony Lindgren Signed-off-by: David S. Miller

net: davinci_emac: Get device dm816x MAC address using the cpsw code

2015-01-31T01:42:01Z

At least on dm81xx, we can get the davinci_emac MAC address the same way as on am33xx cpsw. Let's also use ether_addr_copy() for davinci_emac while at it. Cc: Brian Hutchinson Cc: Felipe Balbi Signed-off-by: Tony Lindgren Signed-off-by: David S. Miller

net: davinci_emac: Add support for emac on dm816x

2015-01-16T06:00:03Z

On dm816x we have two emac controllers with separate memory areas. Cc: Brian Hutchinson Cc: Felipe Balbi Signed-off-by: Tony Lindgren Signed-off-by: David S. Miller

net: davinci_emac: Fix ioremap for devices with MDIO within the EMAC address space

2015-01-16T06:00:03Z

Some devices like dm816x have the MDIO registers within the first EMAC instance address space. Let's fix the issue by allowing to pass an optional second IO range for the EMAC control register area. Cc: Brian Hutchinson Cc: Felipe Balbi Signed-off-by: Tony Lindgren Signed-off-by: David S. Miller

net: davinci_emac: Fix incomplete code for getting the phy from device tree

2015-01-16T06:00:03Z

Looks like the phy_id is never set up beyond getting the phandle. Note that we can remove the ifdef for phy_node as there is a stub for of_phy_connec() if CONFIG_OF is not set. Cc: Brian Hutchinson Cc: Felipe Balbi Signed-off-by: Tony Lindgren Signed-off-by: David S. Miller

net: davinci_emac: Free clock after checking the frequency

2015-01-16T06:00:03Z

We only use clk_get() to get the frequency, the rest is done by the runtime PM calls. Let's free the clock too. Cc: Brian Hutchinson Cc: Felipe Balbi Signed-off-by: Tony Lindgren Signed-off-by: David S. Miller

net: davinci_emac: Fix runtime pm calls for davinci_emac

2015-01-16T06:00:03Z

Commit 3ba97381343b ("net: ethernet: davinci_emac: add pm_runtime support") added support for runtime PM, but it causes issues on omap3 related devices that actually gate the clocks: Unhandled fault: external abort on non-linefetch (0x1008) ... [] (emac_dev_getnetstats) from [] (dev_get_stats+0x78/0xc8) [] (dev_get_stats) from [] (rtnl_fill_ifinfo+0x3b8/0x938) [] (rtnl_fill_ifinfo) from [] (rtmsg_ifinfo+0x68/0xd8) [] (rtmsg_ifinfo) from [] (register_netdevice+0x3a0/0x4ec) [] (register_netdevice) from [] (register_netdev+0x14/0x24) [] (register_netdev) from [] (davinci_emac_probe+0x408/0x5c8) [] (davinci_emac_probe) from [] (platform_drv_probe+0x48/0xa4) Let's fix it by moving the pm_runtime_get() call earlier, and also add it to the emac_dev_getnetstats(). Also note that we want to use pm_runtime_get_sync() as we don't want to have deferred_resume happen. And let's also check the return value for pm_runtime_get_sync() as noted by Felipe Balbi . Cc: Brian Hutchinson Acked-by: Mark A. Greer Reviewed-by: Felipe Balbi Signed-off-by: Tony Lindgren Signed-off-by: David S. Miller

net: davinci_emac: Fix hangs with interrupts

2015-01-16T06:00:03Z

On davinci_emac, we have pulse interrupts. This means that we need to clear the EOI bits when disabling interrupts as otherwise the interrupts keep happening. And we also need to not clear the EOI bits again when enabling the interrupts as otherwise we will get tons of: unexpected IRQ trap at vector 00 These errors almost certainly mean that the omap-intc.c is signaling a spurious interrupt with the reserved irq 127 as we've seen earlier on omap3. Let's fix the issue by clearing the EOI bits when disabling the interrupts. Let's also keep the comment for "Rx Threshold and Misc interrupts are not enabled" for both enable and disable so people are aware of this when potentially adding more support. Note that eventually we should handle the RX and TX interrupts separately like cpsw is now doing. However, so far I have not seen any issues with this based on my testing, so it seems to behave a little different compared to the cpsw that had a similar issue. Cc: Brian Hutchinson Reviewed-by: Felipe Balbi Signed-off-by: Tony Lindgren Signed-off-by: David S. Miller

ethernet: ti: remove unwanted THIS_MODULE macro

2014-09-09T18:59:14Z

It removes the owner field updation of driver structure. It will be automatically updated by module_platform_driver() Signed-off-by: Varka Bhadram Signed-off-by: David S. Miller