Re: [PATCH net-next v8 10/10] net: airoha: Support multiple LAN/WAN interfaces for hw MAC address configuration

[Lorenzo Bianconi <lorenzo@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 3538 bytes --]

On May 22, Jakub Kicinski wrote:
> On Wed, 20 May 2026 14:49:37 +0200 Lorenzo Bianconi wrote:
> > > Does this strict OUI validation cause the driver probe to fail when MAC addresses
> > > are randomly generated?
> > > 
> > > If a MAC address is not provided in the device tree, the driver generates a random
> > > one via eth_hw_addr_random(). For multi-port configurations, each port receives an
> > > independently generated random MAC address.
> > > 
> > > Since the upper 3 bytes of these random addresses will almost certainly differ,
> > > when register_netdev() is called for the second port, its ndo_init callback
> > > (airoha_dev_init) will invoke airoha_set_macaddr() and hit this check. Returning
> > > -EINVAL will fail register_netdev() and abort the entire driver probe, leaving
> > > the system without networking.
> > > 
> > > Does this also prevent users from changing the MAC address OUI?
> > > 
> > > When an administrator attempts to change the MAC address via standard userspace
> > > tools, only one interface can be modified at a time. The driver will compare the
> > > new MAC against the existing MAC of the other port.
> > > 
> > > If the MSBs differ, the change is rejected. This makes it impossible to atomically
> > > change the OUI of both interfaces simultaneously, locking the MAC address OUI
> > > to its initial probe-time value.  
> > 
> > As pointed out before, this is a hw design requirement when multiple
> > net_devices are configured as LAN.
> 
> What about Clashiko report about the MAC address?

Do you the following one?
https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260519-airoha-eth-multi-serdes-v8-0-6bd70e329df6%40kernel.org

- What happens when device tree does not provide MAC addresses for two or
  more same-side GDM interfaces?
  - This is the same comment reported in [0].
    Since the hw exposes just a single register (REG_FE_LAN_MAC_H or
    REG_FE_WAN_MAC_H) for the LAN/WAN mac address MSBs, we need to
    require all the interfaces configured as LAN or WAN to share the
    mac address MSBs and the user needs to select the new mac address
    observing this limitation.
    Please note this limitation is only valid if multiple net_devices
    are configured as LAN (or WAN). Since in the current codebase we
    do not support multiple interfaces configured as LAN or WAN, we are
    not introducing any regression.
    I do not think selecting a "base" for the mac address is helpful
    if the user does not provide the mac address via the DTS or NVME
    (as suggested by sashiko) since it will not help us if the mac
    addresses configured via DTS are "wrong" (if they do not respect
    the limitation described above).  What do you think?
 
- If airoha_set_macaddr() succeeds (and has just widened the shared
  [lmin, lmax] range to include this dev) and airoha_set_gdm2_loopback()
  then fails, airoha_dev_init() returns the error but there is no 
  airoha_dev_uninit / ndo_uninit to roll the LMIN/LMAX update back. 
  The shared range is then wider than the set of currently-registered peers.
  - I guess it is not harmful to keep the already configured mac address
    range if airoha_set_gdm2_loopback() fails and I decided to not unwind
    the changes to keep the code simple.  Moreover, in the current codebase,
    if ndo_init() fails, the airoha_probe() will fail.

Regards,
Lorenzo

[0] https://sashiko.dev/#/patchset/20260519-airoha-eth-multi-serdes-v8-0-6bd70e329df6%40kernel.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]