Subject: Re: [PATCH net-next 01/10] net: etherdevice: add address inherit helper

From: Bjørn Mork <[email-masked]>
Date: Wed, 28 Aug 2013 09:17:00 +0200

David Miller <[email-masked]> writes:

> From: Bjørn Mork <[email-masked]>
> Date: Sat, 24 Aug 2013 00:28:55 +0200
>
>> Stephen Hemminger <[email-masked]> writes:
>>> On Fri, 23 Aug 2013 11:35:04 +0200
>>> Bjørn Mork <[email-masked]> wrote:
>>>
>>>>  /**
>>>> + * eth_hw_addr_inherit - Copy dev_addr from another net_device
>>>> + * @dst: pointer to net_device to copy dev_addr to
>>>> + * @src: pointer to net_device to copy dev_addr from
>>>> + *
>>>> + * Copy the Ethernet address from one net_device to another along with
>>>> + * the addr_assign_type.
>>>> + */
>>>> +static inline int eth_hw_addr_inherit(struct net_device *dst,
>>>> +				      struct net_device *src)
>>>> +{
>>>> +	if (dst->addr_len != src->addr_len)
>>>> +		return -EINVAL;
>>>> +
>>>> +	dst->addr_assign_type = src->addr_assign_type;
>>>> +	memcpy(dst->dev_addr, src->dev_addr, dst->addr_len);
>>>> +	return 0;
>>>> +}
>>>> +
>>>
>>> Since all the other code in this file assumes addr_len == ETH_ALEN
>>> why does this code need to handle variable addresses. Trivial but
>>> then the memcpy is fixed size and can be optimized.
>> 
>> Didn't know that. I'll make that change in the next version.  Not that
>> optimization matters much here, but consistency is always good.
>
> You can bug check that addr_len ETH_ALEN if you want.

I don't think that is necessary.  

> I realize that some drivers don't initialize it by this call point but
> that is arguably a bug.

Yes.  But I don't believe another test is going to make those drivers
work, so it's better to just drop it.

Bjørn