Re: [PATCH net-next v3 04/12] net: airoha: Rely on net_device pointer in HTB callbacks

[Lorenzo Bianconi <lorenzo@kernel.org>]

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

> On 10/04/2026 04:57, Jakub Kicinski wrote:
> > This is an AI-generated review of your patch. The human sending this
> > email says "For your consideration."
> > ---
> > net: airoha: Introduce WAN device flag
> > 
> > This commit introduces a WAN flag to specify whether a device is used to
> > transmit or receive WAN or LAN traffic. It enables specifying multiple LAN
> > devices but limits the configuration to a single WAN device.
> > 
> 
> [...]
> 
> > > +		fallthrough;
> > > +	}
> > > +	case AIROHA_GDM2_IDX:
> > > +		/* GDM2 is always used as wan */
> > > +		dev->flags |= PRIV_FLAG_WAN;
> > >   		break;
> > >   	default:
> > >   		break;
> > >   	}
> > > -	for (i = 0; i < eth->soc->num_ppe; i++)
> > > -		airoha_ppe_set_cpu_port(dev, i, airoha_get_fe_port(dev));
> > > +	airoha_dev_set_qdma(dev);
> > > +	airoha_set_macaddr(dev, netdev->dev_addr);
> > 
> > Since the commit message notes it is possible to specify multiple LAN
> > devices, does unconditionally calling airoha_set_macaddr() for each
> > device overwrite the single shared hardware LAN MAC register?
> > 
> > If so, could this cause only the last initialized LAN device to have its MAC
> > correctly programmed into the hardware, leading to dropped unicast
> > packets for the other LAN interfaces?
> > 
> > > +
> > > +	if (!airoha_is_lan_gdm_dev(dev) &&
> > > +	    (port->id == AIROHA_GDM3_IDX || port->id == AIROHA_GDM4_IDX)) {
> > > +		int err;
> > 
> > [ ... ]
> 
> Hi, the frame engine can be configured with a range of wan mac addresses and
> a range of lan mac addresses via registers that set the top 24 bits and then
> 2 registers that form a range of the low 24 bits.
> 
> Documentation says that packets that fall into this mac address range either
> on the lan side or the wan side are to be treated as layer 3 packages and if
> a packet is not then it will be handled as a layer 2 packet.
> 
> The exact implication of this and if it actually matters is unknown. But
> traffic that comes in on an interface that is not matched by an acceleration
> flow is usually forwarded to the cpu for further processing.

The assumption here is the mac addresses are read from the SNAND or eMMC and
they all share the upper bits. I will fix the issue with a separated patch for
net tree.

Regards,
Lorenzo

> 
> MvH
> Benjamin Larsson

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