[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20130827.143501.1692335946060457637.davem@davemloft.net>
Date: Tue, 27 Aug 2013 14:35:01 -0400 (EDT)
From: David Miller <davem@...emloft.net>
To: bjorn@...k.no
Cc: stephen@...workplumber.org, netdev@...r.kernel.org
Subject: Re: [PATCH net-next 01/10] net: etherdevice: add address inherit
helper
From: Bjørn Mork <bjorn@...k.no>
Date: Sat, 24 Aug 2013 00:28:55 +0200
> Stephen Hemminger <stephen@...workplumber.org> writes:
>> On Fri, 23 Aug 2013 11:35:04 +0200
>> Bjørn Mork <bjorn@...k.no> 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 realize that some drivers don't initialize it by this call point but
that is arguably a bug.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists