| Message ID | 20230906095143.99806-1-aford173@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [1/2] net: ethernet: davinci_emac: Use MAC Address from Device Tree | expand |
On Wed, Sep 06, 2023 at 04:51:42AM -0500, 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 <aford173@gmail.com> There is the potential for regressions here, since behaviour is being changed. But i do think what you are doing make sense. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Andrew
On Wed, Sep 6, 2023 at 7:39 AM Andrew Lunn <andrew@lunn.ch> wrote: > > On Wed, Sep 06, 2023 at 04:51:42AM -0500, 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 <aford173@gmail.com> > > There is the potential for regressions here, since behaviour is being > changed. But i do think what you are doing make sense. > > Reviewed-by: Andrew Lunn <andrew@lunn.ch> I don't know who the right person is to ask, but is there any chance this can be accepted? adam > > Andrew
> I don't know who the right person is to ask, but is there any chance > this can be accepted? It did not help you did not make it clear who you want to merge the patches. It is a good idea to use To: with the Maintainer you would like to do the merge and Cc: for the others. What is the state of patches? Has the other patch been merged? If just the driver change is left, please repost is on its own, and follow: https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html#netdev-faq Andrew
On Wed, Oct 11, 2023 at 10:00 AM Andrew Lunn <andrew@lunn.ch> wrote: > > > I don't know who the right person is to ask, but is there any chance > > this can be accepted? > > It did not help you did not make it clear who you want to merge the > patches. It is a good idea to use To: with the Maintainer you would > like to do the merge and Cc: for the others. I use ./scripts/get_maintainer to generate a list of maintainers for the respective patches, and they should have all been CC'd. > > What is the state of patches? Has the other patch been merged? If > just the driver change is left, please repost is on its own, and > follow: The device tree part has been accepted by Tony into the OMAP tree. I'll split the driver off, do a V2, and just fetch the maintainer of the driver itself and CC netdev. > > https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html#netdev-faq > Thanks! adam > Andrew
diff --git a/drivers/net/ethernet/ti/davinci_emac.c b/drivers/net/ethernet/ti/davinci_emac.c index 2eb9d5a32588..994ddd756782 100644 --- a/drivers/net/ethernet/ti/davinci_emac.c +++ b/drivers/net/ethernet/ti/davinci_emac.c @@ -1934,18 +1934,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);
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 <aford173@gmail.com>