Re: [RFC net-next 3/6] ethernet: prestera: use eth_hw_addr_set_port()
From: Jakub Kicinski <kuba@kernel.org>
Date: 2021-10-18 14:19:18
On Sat, 16 Oct 2021 14:19:18 -0700 Shannon Nelson wrote:
On 10/15/21 12:38 PM, Jakub Kicinski wrote:quoted
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>
quoted
@@ -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. In fact if someone is "afraid" of others refactoring their driver or can't provide timely feedback (ekhm, prestera people) maybe the driver doesn't belong upstream.