From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from esa.microchip.iphmx.com (esa.microchip.iphmx.com [68.232.154.123]) (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 7A0D43597B; Tue, 3 Mar 2026 15:59:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=68.232.154.123 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772553557; cv=none; b=GUSydA+LxFcP2fXxElKqjth4vZsK4ZLtIV7dBrcHg60dmM2ZfiFfmJLcoWakSw+tW/Rfxybf5/7OIdLYB+jTDPNtuwRE37o7PbfxZCE0rF25CFW1CRUlPw5KGnP6FHR+09FrWcbI2nyQW13S8zDYdZblb2xQJ54WYhO0gL6Stp8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772553557; c=relaxed/simple; bh=2Znm2hKjnv23W5ZRgd7ir3fctbTedgRdOChcu0QH9A8=; h=Message-ID:Subject:From:To:CC:Date:In-Reply-To:References: Content-Type:MIME-Version; b=QGhtFd2mNqGzVIZuHFUgW0kiVqcuG6bUKa8EzsRPK+unYPG0zCrPOuGhCPkaXUZxVHancZRxVnGfwZATgqPC/kEpY7GK/wZQhLomMqLFxd31zTsCUxfjPhWl/kijvB66g77BCP5HE07PclsKBlr3uhlZEom2ppZ0ubKYBVEo0MA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=microchip.com; spf=pass smtp.mailfrom=microchip.com; dkim=pass (2048-bit key) header.d=microchip.com header.i=@microchip.com header.b=ggDR9wFY; arc=none smtp.client-ip=68.232.154.123 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=microchip.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=microchip.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=microchip.com header.i=@microchip.com header.b="ggDR9wFY" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=microchip.com; i=@microchip.com; q=dns/txt; s=mchp; t=1772553556; x=1804089556; h=message-id:subject:from:to:cc:date:in-reply-to: references:content-transfer-encoding:mime-version; bh=2Znm2hKjnv23W5ZRgd7ir3fctbTedgRdOChcu0QH9A8=; b=ggDR9wFYcL7oQ8ijHOEH2dY9gi2dftJpFYVCyinJ6IAk9gmq8rNBXyOJ bMep+1WDapY4Vn8T5geAjfIDHxh4VDaRVaKFaEcJ1AymFQCRdhrUxPYYZ rnja/89KY+lFyhNgKekU45TT1tNPnKC5b9BYAU9mapCy4uLA43w2ZETHb sUPQwn6wiEoYRpD1B+creb61NoddAPz5zUpTfr45iP8HLXwpxXbz26syk zK+ytuEk0eSqVD7U3srsWNtDpTV14lVmdyfJu/RQml3YhUAIFZ7qQmWpG yQYCyHNxXyurvdR9+w5j6dh7z6udhq00vLeC7XuTHmb1EQy99aZN5CEjM g==; X-CSE-ConnectionGUID: 9GrmsO/UR6GTr11tFUNC4A== X-CSE-MsgGUID: agjHm55oSKid2moc5j8eLQ== X-IronPort-AV: E=Sophos;i="6.21,322,1763449200"; d="scan'208";a="53407437" X-Amp-Result: SKIPPED(no attachment in message) Received: from unknown (HELO email.microchip.com) ([170.129.1.10]) by esa4.microchip.iphmx.com with ESMTP/TLS/ECDHE-RSA-AES128-GCM-SHA256; 03 Mar 2026 08:59:09 -0700 Received: from chn-vm-ex04.mchp-main.com (10.10.85.152) by chn-vm-ex04.mchp-main.com (10.10.85.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.58; Tue, 3 Mar 2026 08:58:52 -0700 Received: from DEN-DL-M77643.microsemi.net (10.10.85.11) by chn-vm-ex04.mchp-main.com (10.10.85.152) with Microsoft SMTP Server id 15.1.2507.58 via Frontend Transport; Tue, 3 Mar 2026 08:58:48 -0700 Message-ID: <1ceeb7fb0abc89f4b384c9d73b7d29c73bb8d53b.camel@microchip.com> Subject: Re: [PATCH net-next 1/8] net: dsa: add tag driver for LAN9645X From: Jens Emil Schulz Ostergaard To: Andrew Lunn CC: , Vladimir Oltean , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , "Simon Horman" , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Woojung Huh , Russell King , "Steen Hegelund" , Daniel Machon , , , Date: Tue, 3 Mar 2026 16:58:48 +0100 In-Reply-To: References: <20260303-dsa_lan9645x_switch_driver_base-v1-0-bff8ca1396f5@microchip.com> <20260303-dsa_lan9645x_switch_driver_base-v1-1-bff8ca1396f5@microchip.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.44.4-0ubuntu2.1 Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 On Tue, 2026-03-03 at 15:13 +0100, Andrew Lunn wrote: >=20 > > +#define LAN9645X_VALIDATE_FIELD(_fld, _fld_sz) = \ > > +do { \ > > + BUILD_BUG_ON_MSG((_fld_sz) > 32, "IFH field size wider than 32.")= ;\ > > + BUILD_BUG_ON_MSG((_fld_sz) =3D=3D 0, "IFH field size of 0."); = \ > > + BUILD_BUG_ON_MSG((_fld) + (_fld_sz) > LAN9645X_IFH_BITS, \ > > + "IFH field overflows IFH"); \ > > +} while (0) > > + > > +#define LAN9645X_IFH_GET(_ifh, _fld) \ > > +({ \ > > + LAN9645X_VALIDATE_FIELD(_fld, _fld##_SZ);\ > > + lan9645x_ifh_get((_ifh), (_fld), _fld##_SZ); \ > > +}) > > + > > +#define LAN9645X_IFH_SET(_ifh, _fld, _val) \ > > +({ \ > > + LAN9645X_VALIDATE_FIELD(_fld, _fld##_SZ);\ > > + lan9645x_ifh_set((_ifh), (_val), (_fld), _fld##_SZ); \ > > +}) >=20 > If you change the BUILD_BUG_ON_MSG() to static_assert(), you can do > the checks in global scope, rather than in a function call. You can > then call lan9645x_ifh_set() directly, without the macro. >=20 Do you mean global scope static_assert() for all fields, and then remove the SET/GET macros? My idea here was to get the validation for the fields used, provided the macros are used at least. Can I do something similar with static_assert or would I have to do all the fields globally up front? > > +static inline void lan9645x_ifh_set(u8 *ifh, u32 val, size_t pos, size= _t length) >=20 > These functions are big enough i would place them into the .c file. > Then, normally, i would say, please don't use inline in a C file. But > here we are in the fast path. Have you tried this with and without the > inline? How does it change the object size and performance? >=20 I did test performance back when I first implemented this. I had some issue= s getting gcc to inline the functions, and that hurt performance quite a bit. But I did not look at object size though. I moved them to the header so I c= ould add the inline. I can move them to the .c file in the next version. > > diff --git a/net/dsa/Kconfig b/net/dsa/Kconfig > > index 5ed8c704636d..8592cccde7ff 100644 > > --- a/net/dsa/Kconfig > > +++ b/net/dsa/Kconfig > > @@ -211,4 +211,14 @@ config NET_DSA_TAG_YT921X > > Say Y or M if you want to enable support for tagging frames for > > Motorcomm YT921x switches. > >=20 > > +config NET_DSA_TAG_LAN9645X > > + tristate "Tag driver for Lan9645x switches" > > + help > > + Say Y or M if you want to enable NPI tagging for the Lan9645x s= witches. > > + In this mode, the frames over the Ethernet CPU port are prepend= ed with > > + a hardware-defined injection/extraction frame header. > > + On injection a 28 byte internal frame header (IFH) is used. On > > + extraction a 16 byte prefix is prepended before the internal fr= ame > > + header. This prefix starts with a broadcast MAC, to ease passag= e > > + through the host side RX filter. >=20 > The sorting in DSA is a bit hit and miss. The Kconfig file is however > sorted. Please insert before the Lantiq tag driver. >=20 I will move it before the Lantiq (NET_DSA_TAG_GSWIP) in the next version. > > endif > > diff --git a/net/dsa/Makefile b/net/dsa/Makefile > > index bf7247759a64..dddcd85c81ce 100644 > > --- a/net/dsa/Makefile > > +++ b/net/dsa/Makefile > > @@ -42,6 +42,7 @@ obj-$(CONFIG_NET_DSA_TAG_TRAILER) +=3D tag_trailer.o > > obj-$(CONFIG_NET_DSA_TAG_VSC73XX_8021Q) +=3D tag_vsc73xx_8021q.o > > obj-$(CONFIG_NET_DSA_TAG_XRS700X) +=3D tag_xrs700x.o > > obj-$(CONFIG_NET_DSA_TAG_YT921X) +=3D tag_yt921x.o > > +obj-$(CONFIG_NET_DSA_TAG_LAN9645X) +=3D tag_lan9645x.o >=20 > Also sorted. >=20 > Andrew I will move this before the MTK in the next version. Thanks, Emil