# Re: \[RFC net-next 3/6\] ethernet: prestera: use eth\_hw\_addr\_set\_port()

- From: Shannon Nelson \<hidden\>
- Date: 2021-10-18 16:26:25 
- List: netdev
- Page: https://ratatoskr.run/netdev/2021/10/11213742
- Thread: https://ratatoskr.run/netdev/2021/10/11213554/t.md

```text
On 10/18/21 7:19 AM, Jakub Kicinski wrote:
> On Sat, 16 Oct 2021 14:19:18 -0700 Shannon Nelson wrote:
>> On 10/15/21 12:38 PM, Jakub Kicinski wrote:
>>> Commit 406f42fa0d3c ("net-next: When a bond have a massive amount
>>> of VLANs...") introduced a rbtree for faster Ethernet address look
>>> up. To maintain netdev->dev_addr in this tree we need to make all
>>> the writes to it got through appropriate helpers.
>>>
>>> We need to make sure the last byte is zeroed.
>>>
>>> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
>>> @@ -341,8 +342,8 @@ static int prestera_port_create(struct prestera_switch *sw, u32 id)
>>>    	/* firmware requires that port's MAC address consist of the first
>>>    	 * 5 bytes of the base MAC address
>>>    	 */
>>> -	memcpy(dev->dev_addr, sw->base_mac, dev->addr_len - 1);
>>> -	dev->dev_addr[dev->addr_len - 1] = port->fp_id;
>>> +	memcpy(addr, sw->base_mac, dev->addr_len - 1);
>>> +	eth_hw_addr_set_port(dev, addr, port->fp_id);
>> Notice in this case I think the original code is setting the last byte
>> to port->fp_id, found I think by a call to their firmware, not by adding
>> fp_id to the existing byte value.
> Yeah, as mentioned in the commit message and discussed with Vladimir.
> Notice that the memcpy is (,, size - 1) and the initial buf is zeroed.
>
>> This is an example of how I feel a bit queezy about this suggested
>> helper: each driver that does something like this may need to do it
>> slightly differently depending upon how their hardware/firmware works.
>> We may be trying to help too much here.
>>
>> As a potential consumer of these helpers, I'd rather do my own mac
>> address byte twiddling and then use eth_hw_addr_set() to put it into place.
> This is disproved by many upstream drivers, I only converted the ones
> that jumped out at me on Friday, but I'm sure there is more. If your
> driver is _really_ doing something questionable^W I mean "special"
> nothing is stopping you from open coding it. For others the helper will
> be useful.
>
> IOW I don't understand your comment.

To try to answer your RFC more clearly: I feel that this particular helper obfuscates the operation more than it helps.

sln

```