netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Florian Fainelli <f.fainelli@gmail.com>
To: Jeremy Linton <jeremy.linton@arm.com>, netdev@vger.kernel.org
Cc: opendmb@gmail.com, davem@davemloft.net,
	bcm-kernel-feedback-list@broadcom.com,
	linux-kernel@vger.kernel.org, wahrenst@gmx.net
Subject: Re: [RFC 2/2] net: bcmgenet: Fetch MAC address from the adapter
Date: Thu, 23 Jan 2020 13:13:01 -0800	[thread overview]
Message-ID: <465844cf-ff19-9bb5-15d3-cc876a2d40f6@gmail.com> (raw)
In-Reply-To: <20200123060823.1902366-3-jeremy.linton@arm.com>

On 1/22/20 10:08 PM, Jeremy Linton wrote:
> ARM/ACPI machines should utilize self describing hardware
> when possible. The MAC address on the BCM GENET can be
> read from the adapter if a full featured firmware has already
> programmed it. Lets try using the address already programmed,
> if it appears to be valid.

s/BCM GENET/BCMGENET/ or just GENET.

> 
> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
> ---
>  .../net/ethernet/broadcom/genet/bcmgenet.c    | 47 ++++++++++++++-----
>  1 file changed, 36 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
> index c736700f829e..6782bb0a24bd 100644
> --- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
> +++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
> @@ -2779,6 +2779,27 @@ static void bcmgenet_set_hw_addr(struct bcmgenet_priv *priv,
>  	bcmgenet_umac_writel(priv, (addr[4] << 8) | addr[5], UMAC_MAC1);
>  }
>  
> +static void bcmgenet_get_hw_addr(struct bcmgenet_priv *priv,
> +				 unsigned char *addr)
> +{
> +	u32 addr_tmp;
> +	bool acpi_mode = has_acpi_companion(&priv->pdev->dev);
> +
> +	/* UEFI/ACPI machines and possibly others will preprogram the MAC */
> +	if (acpi_mode) {
> +		addr_tmp = bcmgenet_umac_readl(priv, UMAC_MAC0);
> +		addr[0] = addr_tmp >> 24;
> +		addr[1] = (addr_tmp >> 16) & 0xff;
> +		addr[2] = (addr_tmp >>	8) & 0xff;
> +		addr[3] = addr_tmp & 0xff;
> +		addr_tmp = bcmgenet_umac_readl(priv, UMAC_MAC1);
> +		addr[4] = (addr_tmp >> 8) & 0xff;
> +		addr[5] = addr_tmp & 0xff;
> +	} else {
> +		memset(addr, 0, ETH_ALEN);
> +	}
> +}
> +
>  /* Returns a reusable dma control register value */
>  static u32 bcmgenet_dma_disable(struct bcmgenet_priv *priv)
>  {
> @@ -3509,11 +3530,6 @@ static int bcmgenet_probe(struct platform_device *pdev)
>  	}
>  	priv->wol_irq = platform_get_irq_optional(pdev, 2);
>  
> -	if (dn)
> -		macaddr = of_get_mac_address(dn);
> -	else if (pd)
> -		macaddr = pd->mac_address;
> -
>  	priv->base = devm_platform_ioremap_resource(pdev, 0);
>  	if (IS_ERR(priv->base)) {
>  		err = PTR_ERR(priv->base);
> @@ -3524,12 +3540,6 @@ static int bcmgenet_probe(struct platform_device *pdev)
>  
>  	SET_NETDEV_DEV(dev, &pdev->dev);
>  	dev_set_drvdata(&pdev->dev, dev);
> -	if (IS_ERR_OR_NULL(macaddr) || !is_valid_ether_addr(macaddr)) {
> -		dev_warn(&pdev->dev, "using random Ethernet MAC\n");
> -		eth_hw_addr_random(dev);
> -	} else {
> -		ether_addr_copy(dev->dev_addr, macaddr);
> -	}
>  	dev->watchdog_timeo = 2 * HZ;
>  	dev->ethtool_ops = &bcmgenet_ethtool_ops;
>  	dev->netdev_ops = &bcmgenet_netdev_ops;
> @@ -3601,6 +3611,21 @@ static int bcmgenet_probe(struct platform_device *pdev)
>  	    !strcasecmp(phy_mode_str, "internal"))
>  		bcmgenet_power_up(priv, GENET_POWER_PASSIVE);
>  
> +	if (dn)
> +		macaddr = of_get_mac_address(dn);
> +	else if (pd)
> +		macaddr = pd->mac_address;

I would be adding an:

	else if (has_acpi_companion())
		bcmgenet_get_hw_addr(priv, macaddr);

such that bcmgenet_get_hw_addr() does not have much ACPI specific
knowledge and get be used outside, with the caller knowing whether it is
appropriate.

You should also indicate in your commit message that you are moving the
fetching of the MAC address at a later point where the clocks are turned
on, to guarantee that the registers can be read.

With that fixed:

Acked-by: Florian Fainelli <f.fainelli@gmail.com>

> +
> +	if (IS_ERR_OR_NULL(macaddr) || !is_valid_ether_addr(macaddr)) {
> +		bcmgenet_get_hw_addr(priv, dev->dev_addr);
> +		if (!is_valid_ether_addr(dev->dev_addr)) {
> +			dev_warn(&pdev->dev, "using random Ethernet MAC\n");
> +			eth_hw_addr_random(dev);
> +		}
> +	} else {
> +		ether_addr_copy(dev->dev_addr, macaddr);
> +	}
> +
>  	reset_umac(priv);
>  
>  	err = bcmgenet_mii_init(dev);
> 


-- 
Florian

      reply	other threads:[~2020-01-23 21:13 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-23  6:08 [RFC 0/2] Add ACPI bindings to the genet Jeremy Linton
2020-01-23  6:08 ` [RFC 1/2] net: bcmgenet: Initial bcmgenet ACPI support Jeremy Linton
2020-01-23 21:22   ` Florian Fainelli
2020-01-23 22:32     ` Jeremy Linton
2020-01-23  6:08 ` [RFC 2/2] net: bcmgenet: Fetch MAC address from the adapter Jeremy Linton
2020-01-23 21:13   ` Florian Fainelli [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=465844cf-ff19-9bb5-15d3-cc876a2d40f6@gmail.com \
    --to=f.fainelli@gmail.com \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=davem@davemloft.net \
    --cc=jeremy.linton@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=opendmb@gmail.com \
    --cc=wahrenst@gmx.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).