linux-kernel - Re: [PATCH 5/6] net: bcmgenet: Fetch MAC address from the adapter

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 1 Feb 2020 13:20:14 -0600
From:   Jeremy Linton <jeremy.linton@....com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     netdev@...r.kernel.org, opendmb@...il.com, f.fainelli@...il.com,
        davem@...emloft.net, bcm-kernel-feedback-list@...adcom.com,
        linux-kernel@...r.kernel.org, wahrenst@....net,
        hkallweit1@...il.com
Subject: Re: [PATCH 5/6] net: bcmgenet: Fetch MAC address from the adapter

Hi,

On 2/1/20 9:37 AM, Andrew Lunn wrote:
>> @@ -3601,6 +3605,23 @@ 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;
>> +
>> +	if (IS_ERR_OR_NULL(macaddr) || !is_valid_ether_addr(macaddr)) {
>> +		if (has_acpi_companion(&pdev->dev))
>> +			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);
>> +	}
>> +
> 
> Could you also maybe put in here somewhere a call to
> device_get_mac_address(), to support getting the MAC address out of
> ACPI?

I had that here until right before I posted it, mostly because I was 
trying to consolidate the DT/ACPI paths. I pulled it out because it 
wasn't making the code any clearer, and as I mentioned in my response to 
the general _DSD properties I would rather entirely depend on non DSD 
properties if possible.

I will put it back in, but IMHO we shouldn't be finding firmware using 
it. Since the discussion a few years back, its become clearer to me its 
not usually needed. As in this example, the addresses can usually be 
picked off the adapter if the firmware bothers to set them up.