From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754895AbbHLQAm (ORCPT ); Wed, 12 Aug 2015 12:00:42 -0400 Received: from eu-smtp-delivery-143.mimecast.com ([146.101.78.143]:57546 "EHLO eu-smtp-delivery-143.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754659AbbHLQAk convert rfc822-to-8bit (ORCPT ); Wed, 12 Aug 2015 12:00:40 -0400 Date: Wed, 12 Aug 2015 17:00:37 +0100 From: Liviu Dudau To: Stephen Hemminger Cc: Florian Fainelli , Mirko Lindner , "ryan.harkin@linaro.org" , netdev , lkml Subject: Re: [PATCH v2 net-next] sky2: use random address if EEPROM is bad Message-ID: <20150812160037.GX20890@e106497-lin.cambridge.arm.com> References: <55C2AB51.1040409@gmail.com> <1439303756-30333-1-git-send-email-Liviu.Dudau@arm.com> <20150811100132.49229f86@urahara> <20150812093005.GV20890@e106497-lin.cambridge.arm.com> <20150812082823.4d62ee26@urahara> MIME-Version: 1.0 In-Reply-To: <20150812082823.4d62ee26@urahara> User-Agent: Mutt/1.5.22 (2013-10-16) X-OriginalArrivalTime: 12 Aug 2015 16:00:37.0758 (UTC) FILETIME=[079FA9E0:01D0D518] X-MC-Unique: iUPgSZ0vRmu-S9NedBmupw-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Aug 12, 2015 at 04:28:23PM +0100, Stephen Hemminger wrote: > On Wed, 12 Aug 2015 10:30:05 +0100 > Liviu Dudau wrote: > > > On Tue, Aug 11, 2015 at 06:01:32PM +0100, Stephen Hemminger wrote: > > > On Tue, 11 Aug 2015 15:35:56 +0100 > > > Liviu Dudau wrote: > > > > > > > On some embedded systems the EEPROM does not contain a valid MAC address. > > > > In that case it is better to fallback to a generated mac address and > > > > let init scripts fix the value later. > > > > > > > > Reported-by: Liviu Dudau > > > > Signed-off-by: Stephen Hemminger > > > > [Changed handcoded setup to use eth_hw_addr_random() instead] > > > > Signed-off-by: Liviu Dudau > > > > --- > > > > I have tested this on my Juno platform and I can successfully do an nfsroot boot. > > > > > > > > Best regards, > > > > Liviu > > > > > > > > drivers/net/ethernet/marvell/sky2.c | 7 +++++++ > > > > 1 file changed, 7 insertions(+) > > > > > > > > diff --git a/drivers/net/ethernet/marvell/sky2.c b/drivers/net/ethernet/marvell/sky2.c > > > > index d9f4498..c309879 100644 > > > > --- a/drivers/net/ethernet/marvell/sky2.c > > > > +++ b/drivers/net/ethernet/marvell/sky2.c > > > > @@ -4819,6 +4819,13 @@ static struct net_device *sky2_init_netdev(struct sky2_hw *hw, unsigned port, > > > > memcpy_fromio(dev->dev_addr, hw->regs + B2_MAC_1 + port * 8, > > > > ETH_ALEN); > > > > > > > > + /* if the address is invalid, use a random value */ > > > > + if (!is_valid_ether_addr(dev->dev_addr)) { > > > > + netdev_warn(dev, > > > > + "Invalid MAC address, defaulting to random\n"); > > > > + eth_hw_addr_random(dev); > > > > + } > > > > + > > > > return dev; > > > > } > > > > > > > > > > This is not enough, you need to program the hardware with the new random MAC > > > address. The easiest way is calling sky2_set_mac_address, but you need to convert > > > the address from array back to sockaddr. > > > > > > > OK, I am a bit confused as to why sky2_set_mac_address is needed here, as this was not > > required by the existing function. Given that in my tests I get a random MAC address > > assigned every time to the device and I can see the same MAC address with ifconfig, how > > can I test the effect of sky2_set_mac_address if I add it? > > The network device address is stored in two places. One is in the > kernel (dev->dev_addr) and is used by networking stack. > The other is the hardware (actually two places) and is used filtering received packets > in the PHY and for sending hardware generated pause frames. > > When a random address is generated, you need to tell the hardware > to use that address as well. I suspect your hardware maybe limited in functionality > and not do the normal filtering. > I understand now, thanks for explaining it. I admit my tests were very limited and I did not try to capture any packets using the interface. I thought the DHCP discovery requires the MAC address to be correct in the hardware to work, but it might be that the kernel's DHCP client is more thorough than userspace. I will add the setting of the MAC address in v3. Best regards, Liviu -- ==================== | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --------------- ¯\_(ツ)_/¯