From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Joel Stanley <joel@jms.id.au>, Gavin Shan <gwshan@linux.vnet.ibm.com>
Cc: OpenBMC Maillist <openbmc@lists.ozlabs.org>
Subject: Re: [PATCH 07/10] net/farady: Read MAC address from chip
Date: Fri, 01 Jul 2016 21:25:07 +1000 [thread overview]
Message-ID: <1467372307.7422.40.camel@kernel.crashing.org> (raw)
In-Reply-To: <CACPK8XemtUzUMZXFjZSe9aQixcgiQnZimxMA7aMrts-1Yoya1Q@mail.gmail.com>
On Thu, 2016-06-30 at 23:35 +0930, Joel Stanley wrote:
> On Thu, Jun 30, 2016 at 7:57 PM, Gavin Shan wrote:
> > The device is assigned with random MAC address. It isn't reasonable.
> > An valid MAC address might have been in the chip. It's reasonable
> > to use it to maintain consistency.
> >
> > This uses the MAC address in the chip if it's valid. Otherwise, a
> > random MAC address is given as before.
If that is a worry we could use a device-tree property. Does our
uboot update the DT ? If yes it can set the local-mac-address prop.
> > Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
> > ---
> > drivers/net/ethernet/faraday/ftgmac100.c | 60 ++++++++++++++++++++++++++++----
> > 1 file changed, 53 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/faraday/ftgmac100.c b/drivers/net/ethernet/faraday/ftgmac100.c
> > index 2c22f74..120993e 100644
> > --- a/drivers/net/ethernet/faraday/ftgmac100.c
> > +++ b/drivers/net/ethernet/faraday/ftgmac100.c
> > @@ -141,6 +141,55 @@ static void ftgmac100_set_mac(struct ftgmac100 *priv, const unsigned char *mac)
> > iowrite32(laddr, priv->base + FTGMAC100_OFFSET_MAC_LADR);
> > }
> >
> > +static void ftgmac100_setup_mac(struct ftgmac100 *priv)
> > +{
> > + unsigned char mac[6];
> > + unsigned int m;
> > + unsigned int l;
> > +
> > + m = ioread32(priv->base + FTGMAC100_OFFSET_MAC_MADR);
> > + l = ioread32(priv->base + FTGMAC100_OFFSET_MAC_LADR);
> > +
> > + mac[0] = (m >> 8) & 0xff;
> > + mac[1] = m & 0xff;
> > + mac[2] = (l >> 24) & 0xff;
> > + mac[3] = (l >> 16) & 0xff;
> > + mac[4] = (l >> 8) & 0xff;
> > + mac[5] = l & 0xff;
> > +
> > + if (!is_valid_ether_addr(mac)) {
> > + mac[5] = (m >> 8) & 0xff;
> > + mac[4] = m & 0xff;
> > + mac[3] = (l >> 24) & 0xff;
> > + mac[2] = (l >> 16) & 0xff;
> > + mac[1] = (l >> 8) & 0xff;
> > + mac[0] = l & 0xff;
> > + }
> > +
> > + if (!is_valid_ether_addr(mac)) {
> > + eth_hw_addr_random(priv->netdev);
> > + dev_info(priv->dev, "Generated random MAC address %pM\n",
> > + priv->netdev->dev_addr);
> > + } else {
> > + memcpy(priv->netdev->dev_addr, mac, 6);
> > + dev_info(priv->dev, "Read MAC address from chip %pM\n", mac);
> > + }
> > +}
> > +
> > +static int ftgmac100_set_mac_addr(struct net_device *dev, void *p)
> > +{
> > + int ret;
> > +
> > + ret = eth_prepare_mac_addr_change(dev, p);
> > + if (ret < 0)
> > + return ret;
> > +
> > + eth_commit_mac_addr_change(dev, p);
> > + ftgmac100_set_mac(netdev_priv(dev), dev->dev_addr);
> > +
> > + return 0;
> > +}
> > +
> > static void ftgmac100_init_hw(struct ftgmac100 *priv)
> > {
> > /* setup ring buffer base registers */
> > @@ -1141,7 +1190,7 @@ static const struct net_device_ops ftgmac100_netdev_ops = {
> > .ndo_open = ftgmac100_open,
> > .ndo_stop = ftgmac100_stop,
> > .ndo_start_xmit = ftgmac100_hard_start_xmit,
> > - .ndo_set_mac_address = eth_mac_addr,
> > + .ndo_set_mac_address = ftgmac100_set_mac_addr,
> > .ndo_validate_addr = eth_validate_addr,
> > .ndo_do_ioctl = ftgmac100_do_ioctl,
> > };
> > @@ -1263,6 +1312,9 @@ static int ftgmac100_probe(struct platform_device *pdev)
> >
> > priv->irq = irq;
> >
> > + /* MAC address from chip or random one */
> > + ftgmac100_setup_mac(priv);
> > +
> > err = ftgmac100_setup_mdio(netdev);
> > if (err)
> > goto err_setup_mdio;
> > @@ -1276,12 +1328,6 @@ static int ftgmac100_probe(struct platform_device *pdev)
> >
> > netdev_info(netdev, "irq %d, mapped at %p\n", priv->irq, priv->base);
> >
> > - if (!is_valid_ether_addr(netdev->dev_addr)) {
> > - eth_hw_addr_random(netdev);
> > - netdev_info(netdev, "generated random MAC address %pM\n",
> > - netdev->dev_addr);
> > - }
> > -
> > return 0;
> >
> > err_register_netdev:
> > --
> > 2.1.0
> >
next prev parent reply other threads:[~2016-07-01 11:25 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-30 10:27 [PATCH 00/10] NCSI Support Gavin Shan
2016-06-30 10:27 ` [PATCH 01/10] net/ncsi: Resource management Gavin Shan
2016-06-30 14:04 ` Joel Stanley
2016-06-30 10:27 ` [PATCH 02/10] net/ncsi: NCSI command packet handler Gavin Shan
2016-06-30 14:05 ` Joel Stanley
2016-06-30 10:27 ` [PATCH 03/10] net/ncsi: NCSI response " Gavin Shan
2016-06-30 14:05 ` Joel Stanley
2016-06-30 10:27 ` [PATCH 04/10] net/ncsi: Package and channel management Gavin Shan
2016-06-30 14:05 ` Joel Stanley
2016-06-30 10:27 ` [PATCH 05/10] net/ncsi: NCSI AEN packet handler Gavin Shan
2016-06-30 14:05 ` Joel Stanley
2016-06-30 10:27 ` [PATCH 06/10] net/farady: Helper functions to create or destroy MDIO interface Gavin Shan
2016-06-30 13:49 ` Joel Stanley
2016-07-01 2:59 ` Benjamin Herrenschmidt
2016-06-30 10:27 ` [PATCH 07/10] net/farady: Read MAC address from chip Gavin Shan
2016-06-30 14:05 ` Joel Stanley
2016-07-01 11:25 ` Benjamin Herrenschmidt [this message]
[not found] ` <CACPK8XdAiDW=PADte4ZWNumKYXCkK-8kcw0atOUQATORsRQEGA@mail.gmail.com>
2016-07-01 12:17 ` Joel Stanley
2016-07-01 13:20 ` Benjamin Herrenschmidt
2016-07-03 5:35 ` Gavin Shan
2016-06-30 10:27 ` [PATCH 08/10] net/farady: Support NCSI mode Gavin Shan
2016-06-30 14:05 ` Joel Stanley
2016-07-01 11:26 ` Benjamin Herrenschmidt
2016-07-03 5:37 ` Gavin Shan
2016-06-30 10:27 ` [PATCH 09/10] net/farady: Match driver according to compatible property Gavin Shan
2016-06-30 14:06 ` Joel Stanley
2016-06-30 10:27 ` [PATCH 10/10] net/farady: Mask PHY interrupt with NCSI mode Gavin Shan
2016-06-30 14:06 ` Joel Stanley
2016-07-03 5:40 ` Gavin Shan
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=1467372307.7422.40.camel@kernel.crashing.org \
--to=benh@kernel.crashing.org \
--cc=gwshan@linux.vnet.ibm.com \
--cc=joel@jms.id.au \
--cc=openbmc@lists.ozlabs.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.