From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 64B9930BF5C; Fri, 10 Apr 2026 11:52:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775821977; cv=none; b=Yrr3z+f8of0XwBsEIPZUuzMUBzDiURB2mSxpHEHH4GQfGGp0XmrfS6hE2J957bpgEcttIRA9KSU6Ayl4cWpY7NWm8C6rTn3K+DO24zFjFi9Q566SoiFdq0Ps3STD19/io5gEfGQVhcbvW+afFuxA7yYLaDr08lloVOZQmXdGffc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775821977; c=relaxed/simple; bh=Y4GnJSxmVoLcOsU28nVNoZ44KeRm+qtdWi6Re7neJws=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=lHzfbkMjBMVo+Zc4mV334bnPdG8nEeB2Ldr8thRdSQqlmK9Z0W1FSAyUmvZAkS7R5tPnfMmnPt/SIDxQ9MYmzMQjmBXZIQGQ9R3yeMlbMAwvqcIHmvs1ODbv7sHdoG+I6s4ooI1glUL2n2KSuyRzVDcNavX/X86D72+1riNrgfw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=u8hkTLvd; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="u8hkTLvd" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 88B71C19421; Fri, 10 Apr 2026 11:52:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1775821977; bh=Y4GnJSxmVoLcOsU28nVNoZ44KeRm+qtdWi6Re7neJws=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=u8hkTLvdwmNEtlQbPxwGhpXKFahK7mAw84EdneFSvzt8h2dssZtDjOraINVgKLXVw zCFVOJJr0UaOhh3JHtuGLlFl8kL6eLsvcRTOdeI0ZbjWyJ98VN9BOtayLeSX6jRPfm XsbIfNl2jY9BmQNkieqFqSIKunfkAPedZWAkKJ/x8aygtpXTGcCFXbt/t/4o0Ns7g8 TLmmIjcEwypFAgvyUOTa55Gs406EdHlufYK2P5Tv5HN2ZRcLTIoZZccpEWgBC6HmBM CZHB2dAjbMS+jd/Ke1lK6d62Orvfk1YtmGHmghdTeu8RPdsjOVplos307CCBnyvzl4 prUynAYuTiZGA== Date: Fri, 10 Apr 2026 13:52:54 +0200 From: Lorenzo Bianconi To: Benjamin Larsson Cc: Jakub Kicinski , andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com, pabeni@redhat.com, robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org, ansuelsmth@gmail.com, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, netdev@vger.kernel.org, devicetree@vger.kernel.org Subject: Re: [PATCH net-next v3 04/12] net: airoha: Rely on net_device pointer in HTB callbacks Message-ID: References: <20260406-airoha-eth-multi-serdes-v3-4-ab6ea49d59ff@kernel.org> <20260410025722.1809973-1-kuba@kernel.org> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="i1NM/Tit3uG0u/BY" Content-Disposition: inline In-Reply-To: --i1NM/Tit3uG0u/BY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > 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 > >=20 > > 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. > >=20 >=20 > [...] >=20 > > > + fallthrough; > > > + } > > > + case AIROHA_GDM2_IDX: > > > + /* GDM2 is always used as wan */ > > > + dev->flags |=3D PRIV_FLAG_WAN; > > > break; > > > default: > > > break; > > > } > > > - for (i =3D 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); > >=20 > > 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? > >=20 > > If so, could this cause only the last initialized LAN device to have it= s MAC > > correctly programmed into the hardware, leading to dropped unicast > > packets for the other LAN interfaces? > >=20 > > > + > > > + if (!airoha_is_lan_gdm_dev(dev) && > > > + (port->id =3D=3D AIROHA_GDM3_IDX || port->id =3D=3D AIROHA_GDM4= _IDX)) { > > > + int err; > >=20 > > [ ... ] >=20 > 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 t= hen > 2 registers that form a range of the low 24 bits. >=20 > Documentation says that packets that fall into this mac address range eit= her > 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. >=20 > 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 accelerat= ion > 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 >=20 > MvH > Benjamin Larsson --i1NM/Tit3uG0u/BY Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQTquNwa3Txd3rGGn7Y6cBh0uS2trAUCadjklgAKCRA6cBh0uS2t rOALAQDChwhT+q+W9kV8svjw4vYBOXlgu4gRACeUn8gsl1GgfQD9HP1z0i1xfifR 9EwKX95S/PvAovnwKbRE5sYz1v1dGQY= =Za20 -----END PGP SIGNATURE----- --i1NM/Tit3uG0u/BY--