| Message ID | 20250328160642.3595-1-ffmancera@riseup.net (mailing list archive) |
|---|---|
| State | Deferred |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | [v2,net-next] net: hsr: sync hw addr of slave2 according to slave1 hw addr on PRP | expand |
On 3/28/25 5:06 PM, Fernando Fernandez Mancera wrote: > In order to work properly PRP requires slave1 and slave2 to share the > same MAC address. To ease the configuration process on userspace tools, > sync the slave2 MAC address with slave1. > > Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net> > --- > NOTE: I am not sure the call_netdevice_notifiers() are needed here. > I am wondering, if this change makes sense in HSR too. > Feedback is welcome. > v2: specified the target tree Please respect the 24h grace period before reposting: https://elixir.bootlin.com/linux/v6.14-rc6/source/Documentation/process/maintainer-netdev.rst#L15 Also please note that net-next is currently closed for new features due to the merge window. Please resent after Apr 7th. > --- > net/hsr/hsr_device.c | 2 ++ > net/hsr/hsr_main.c | 9 +++++++++ > 2 files changed, 11 insertions(+) > > diff --git a/net/hsr/hsr_device.c b/net/hsr/hsr_device.c > index 439cfb7ad5d1..f971eb321655 100644 > --- a/net/hsr/hsr_device.c > +++ b/net/hsr/hsr_device.c > @@ -706,6 +706,8 @@ int hsr_dev_finalize(struct net_device *hsr_dev, struct net_device *slave[2], > */ > hsr->net_id = PRP_LAN_ID << 1; > hsr->proto_ops = &prp_ops; > + eth_hw_addr_set(slave[1], slave[0]->dev_addr); I'm unsure about this. It will have 'destructive' effect on slave[1], i.e. the original mac address will be permanently chaneged and will be up to the user-space restore it when/if removing from hsr. I think it would be better to additionally store the original mac address at hsr creation time and restore it at link removal time. Thanks, Paolo
On 01/04/2025 11:16, Paolo Abeni wrote: > On 3/28/25 5:06 PM, Fernando Fernandez Mancera wrote: >> In order to work properly PRP requires slave1 and slave2 to share the >> same MAC address. To ease the configuration process on userspace tools, >> sync the slave2 MAC address with slave1. >> >> Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net> >> --- >> NOTE: I am not sure the call_netdevice_notifiers() are needed here. >> I am wondering, if this change makes sense in HSR too. >> Feedback is welcome. >> v2: specified the target tree > > Please respect the 24h grace period before reposting: > > https://elixir.bootlin.com/linux/v6.14-rc6/source/Documentation/process/maintainer-netdev.rst#L15 > > Also please note that net-next is currently closed for new features due > to the merge window. Please resent after Apr 7th. > >> --- >> net/hsr/hsr_device.c | 2 ++ >> net/hsr/hsr_main.c | 9 +++++++++ >> 2 files changed, 11 insertions(+) >> >> diff --git a/net/hsr/hsr_device.c b/net/hsr/hsr_device.c >> index 439cfb7ad5d1..f971eb321655 100644 >> --- a/net/hsr/hsr_device.c >> +++ b/net/hsr/hsr_device.c >> @@ -706,6 +706,8 @@ int hsr_dev_finalize(struct net_device *hsr_dev, struct net_device *slave[2], >> */ >> hsr->net_id = PRP_LAN_ID << 1; >> hsr->proto_ops = &prp_ops; >> + eth_hw_addr_set(slave[1], slave[0]->dev_addr); > > I'm unsure about this. It will have 'destructive' effect on slave[1], > i.e. the original mac address will be permanently chaneged and will be > up to the user-space restore it when/if removing from hsr. > > I think it would be better to additionally store the original mac > address at hsr creation time and restore it at link removal time. > Yes, probably it makes more sense to restore the original MAC address at link removal. Thanks for the suggestion Paolo! > Thanks, > > Paolo > >
diff --git a/net/hsr/hsr_device.c b/net/hsr/hsr_device.c index 439cfb7ad5d1..f971eb321655 100644 --- a/net/hsr/hsr_device.c +++ b/net/hsr/hsr_device.c @@ -706,6 +706,8 @@ int hsr_dev_finalize(struct net_device *hsr_dev, struct net_device *slave[2], */ hsr->net_id = PRP_LAN_ID << 1; hsr->proto_ops = &prp_ops; + eth_hw_addr_set(slave[1], slave[0]->dev_addr); + call_netdevice_notifiers(NETDEV_CHANGEADDR, slave[1]); } else { hsr->proto_ops = &hsr_ops; } diff --git a/net/hsr/hsr_main.c b/net/hsr/hsr_main.c index d7ae32473c41..192893c3f2ec 100644 --- a/net/hsr/hsr_main.c +++ b/net/hsr/hsr_main.c @@ -78,6 +78,15 @@ static int hsr_netdev_notify(struct notifier_block *nb, unsigned long event, eth_hw_addr_set(master->dev, dev->dev_addr); call_netdevice_notifiers(NETDEV_CHANGEADDR, master->dev); + + if (hsr->prot_version == PRP_V1) { + port = hsr_port_get_hsr(hsr, HSR_PT_SLAVE_B); + if (port) { + eth_hw_addr_set(port->dev, dev->dev_addr); + call_netdevice_notifiers(NETDEV_CHANGEADDR, + port->dev); + } + } } /* Make sure we recognize frames from ourselves in hsr_rcv() */
In order to work properly PRP requires slave1 and slave2 to share the same MAC address. To ease the configuration process on userspace tools, sync the slave2 MAC address with slave1. Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net> --- NOTE: I am not sure the call_netdevice_notifiers() are needed here. I am wondering, if this change makes sense in HSR too. Feedback is welcome. v2: specified the target tree --- net/hsr/hsr_device.c | 2 ++ net/hsr/hsr_main.c | 9 +++++++++ 2 files changed, 11 insertions(+)