Currently there is a device tree entry called "local-mac-address"
which can be filled by the bootloader or manually set.This is
useful when the user does not want to use the MAC address
programmed into the SoC.
Currently, the davinci_emac reads the MAC from the DT, copies
it from pdata->mac_addr to priv->mac_addr, then blindly overwrites
it by reading from registers in the SoC, and falls back to a
random MAC if it's still not valid. This completely ignores any
MAC address in the device tree.
In order to use the local-mac-address, check to see if the contents
of priv->mac_addr are valid before falling back to reading from the
SoC when the MAC address is not valid.
Signed-off-by: Adam Ford <[email protected]>
Reviewed-by: Andrew Lunn <[email protected]>
---
V2: Rebase, add R-B tag, and post stand-alone for netdev branch, since
the device tree patch has already been accepted via the omap tree.
diff --git a/drivers/net/ethernet/ti/davinci_emac.c b/drivers/net/ethernet/ti/davinci_emac.c
index 23f8bc1cd20d..b0950a318c42 100644
--- a/drivers/net/ethernet/ti/davinci_emac.c
+++ b/drivers/net/ethernet/ti/davinci_emac.c
@@ -1928,18 +1928,20 @@ static int davinci_emac_probe(struct platform_device *pdev)
goto err_free_rxchan;
ndev->irq = rc;
- rc = davinci_emac_try_get_mac(pdev, res_ctrl ? 0 : 1, priv->mac_addr);
- if (!rc)
- eth_hw_addr_set(ndev, priv->mac_addr);
-
+ /* If the MAC address is not present, read the registers from the SoC */
if (!is_valid_ether_addr(priv->mac_addr)) {
- /* Use random MAC if still none obtained. */
- eth_hw_addr_random(ndev);
- memcpy(priv->mac_addr, ndev->dev_addr, ndev->addr_len);
- dev_warn(&pdev->dev, "using random MAC addr: %pM\n",
- priv->mac_addr);
+ rc = davinci_emac_try_get_mac(pdev, res_ctrl ? 0 : 1, priv->mac_addr);
+ if (!rc)
+ eth_hw_addr_set(ndev, priv->mac_addr);
+
+ if (!is_valid_ether_addr(priv->mac_addr)) {
+ /* Use random MAC if still none obtained. */
+ eth_hw_addr_random(ndev);
+ memcpy(priv->mac_addr, ndev->dev_addr, ndev->addr_len);
+ dev_warn(&pdev->dev, "using random MAC addr: %pM\n",
+ priv->mac_addr);
+ }
}
-
ndev->netdev_ops = &emac_netdev_ops;
ndev->ethtool_ops = ðtool_ops;
netif_napi_add(ndev, &priv->napi, emac_poll);
--
2.40.1
On 10/22/2023 8:19 AM, Adam Ford wrote:
> Currently there is a device tree entry called "local-mac-address"
> which can be filled by the bootloader or manually set.This is
> useful when the user does not want to use the MAC address
> programmed into the SoC.
>
> Currently, the davinci_emac reads the MAC from the DT, copies
> it from pdata->mac_addr to priv->mac_addr, then blindly overwrites
> it by reading from registers in the SoC, and falls back to a
> random MAC if it's still not valid. This completely ignores any
> MAC address in the device tree.
>
> In order to use the local-mac-address, check to see if the contents
> of priv->mac_addr are valid before falling back to reading from the
> SoC when the MAC address is not valid.
>
> Signed-off-by: Adam Ford <[email protected]>
> Reviewed-by: Andrew Lunn <[email protected]>
> ---
> V2: Rebase, add R-B tag, and post stand-alone for netdev branch, since
> the device tree patch has already been accepted via the omap tree.
Looks like you didn't add the tag for which tree. Given the context, I
would assume net-next.
Reviewed-by: Jacob Keller <[email protected]>
On Mon, Oct 23, 2023 at 7:14 PM Jacob Keller <[email protected]> wrote:
>
>
>
> On 10/22/2023 8:19 AM, Adam Ford wrote:
> > Currently there is a device tree entry called "local-mac-address"
> > which can be filled by the bootloader or manually set.This is
> > useful when the user does not want to use the MAC address
> > programmed into the SoC.
> >
> > Currently, the davinci_emac reads the MAC from the DT, copies
> > it from pdata->mac_addr to priv->mac_addr, then blindly overwrites
> > it by reading from registers in the SoC, and falls back to a
> > random MAC if it's still not valid. This completely ignores any
> > MAC address in the device tree.
> >
> > In order to use the local-mac-address, check to see if the contents
> > of priv->mac_addr are valid before falling back to reading from the
> > SoC when the MAC address is not valid.
> >
> > Signed-off-by: Adam Ford <[email protected]>
> > Reviewed-by: Andrew Lunn <[email protected]>
> > ---
> > V2: Rebase, add R-B tag, and post stand-alone for netdev branch, since
> > the device tree patch has already been accepted via the omap tree.
>
> Looks like you didn't add the tag for which tree. Given the context, I
> would assume net-next.
>
That was my intent. I sent the e-mail to netdev and CC'd others. I
thought that was enough.
> Reviewed-by: Jacob Keller <[email protected]>
On Mon, 2023-10-23 at 20:22 -0500, Adam Ford wrote:
> On Mon, Oct 23, 2023 at 7:14 PM Jacob Keller <[email protected]> wrote:
> > Looks like you didn't add the tag for which tree. Given the context, I
> > would assume net-next.
>
> That was my intent. I sent the e-mail to netdev and CC'd others. I
> thought that was enough.
For future submissions: there are 2 different netdev trees, one for new
features (net-next) and another one for bugfixes (net), and you should
specify the target explcitly in the patch prefix. See:
Documentation/process/maintainer-netdev.rst
for the more details.
Looks like this one is targeting net-next.
Cheers,
Paolo
Hello:
This patch was applied to netdev/net-next.git (main)
by Paolo Abeni <[email protected]>:
On Sun, 22 Oct 2023 10:19:11 -0500 you wrote:
> Currently there is a device tree entry called "local-mac-address"
> which can be filled by the bootloader or manually set.This is
> useful when the user does not want to use the MAC address
> programmed into the SoC.
>
> Currently, the davinci_emac reads the MAC from the DT, copies
> it from pdata->mac_addr to priv->mac_addr, then blindly overwrites
> it by reading from registers in the SoC, and falls back to a
> random MAC if it's still not valid. This completely ignores any
> MAC address in the device tree.
>
> [...]
Here is the summary with links:
- [V2] net: ethernet: davinci_emac: Use MAC Address from Device Tree
https://git.kernel.org/netdev/net-next/c/f30a51a41828
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html