From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pidgin.makrotopia.org (pidgin.makrotopia.org [185.142.180.65]) (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 BCDEF10A1E; Wed, 28 Jan 2026 01:38:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.142.180.65 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769564332; cv=none; b=nYWN8UnB3WMQUzBdmUpJZUZZ3/ddPuSExqkfnDLyF48WtMO5JEAuCDXz1PeDhET4IT+RF3UbdULTBpp/J01c27HneEXVsOUHFUQbAwvgemwfmud2XbtrwCpm+bgd6gldgWS+aJ8VFZDoF57HfoTup4jBotSV14qv+eXW0hZX+5k= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769564332; c=relaxed/simple; bh=E+LMQtobqNeqqaw4wHk4HwVp+Oa8DY+zHi8isomu0u4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=n302i/bmmfeU1SNtLajs11O6QNHw5PA+Dp6lgkqHiNK/UJXUJEPDF+BM08397wrw9CjfeOSq8nd+B1eJXefKkSFmu8gi8HT/C778KlqCGqTMulOQAcgfDdIt6cvzzy57L2m7bUV5Ls9+lgftyGaETrJuEL63kAlT8v0Suq4/nIU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=makrotopia.org; spf=pass smtp.mailfrom=makrotopia.org; arc=none smtp.client-ip=185.142.180.65 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=makrotopia.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=makrotopia.org Received: from local by pidgin.makrotopia.org with esmtpsa (TLS1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.99) (envelope-from ) id 1vkuW1-000000003lK-38Ef; Wed, 28 Jan 2026 01:38:41 +0000 Date: Wed, 28 Jan 2026 01:38:38 +0000 From: Daniel Golle To: Vladimir Oltean Cc: Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Heiner Kallweit , Russell King , Simon Horman , netdev@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Frank Wunderlich , Chad Monroe , Cezary Wilmanski , Avinash Jayaraman , Bing tao Xu , Liang Xu , Juraj Povazanec , "Fanni (Fang-Yi) Chan" , "Benny (Ying-Tsan) Weng" , "Livia M. Rosu" , John Crispin Subject: Re: [PATCH net-next v9 0/4] net: dsa: initial support for MaxLinear MxL862xx switches Message-ID: References: <20260127225643.qe4lpeyjmtl6flc4@skbuf> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260127225643.qe4lpeyjmtl6flc4@skbuf> On Wed, Jan 28, 2026 at 12:56:43AM +0200, Vladimir Oltean wrote: > On Tue, Jan 27, 2026 at 09:37:40PM +0000, Daniel Golle wrote: > > This series adds very basic DSA support for the MaxLinear MxL86252 > > (5 PHY ports) and MxL86282 (8 PHY ports) switches. > > > > MxL862xx integrates a firmware running on an embedded processor (running > > Zephyr RTOS). Host interaction uses a simple netlink-like API transported > > over MDIO/MMD. > > > > This series includes only what's needed to pass traffic between user > > ports and the CPU port: relayed MDIO to internal PHYs, basic port > > enable/disable, and CPU-port special tagging. > > Follow up series will bring bridge, VLAN, ... offloading, > > I'm surprised the Kconfig help text says: > > These switches have two 10GE SerDes interfaces, one typically > used as CPU port. > > yet only PHY_INTERFACE_MODE_INTERNAL is set in phylink supported_interfaces. > You're also not making any mention of future SerDes support. What's up > with that, how do the SerDes ports currently work and how are they > described? (as internal?!) Oh, sure, I'm obviously going to add both SerDes interfaces which support various interface modes as phylink_pcs instances in a follow-up series. I was planning to do basic bridge offloading and FDB access first, then SerDes PCS, then LAG, then VLAN, and then last but not least using the 802.1Q-based special tag (LoC of just that feature is almost as much as all the rest together in the vendor driver). > > > and support for using a 802.1Q-based special tag instead of the > > proprietary 8-byte tag. > > Why is that? Using an 802.1Q-based special tag is advantageous in some situations, for example PPE offloading engines typically do support 802.1Q and 802.1ad VLANs, but do not support any special tag apart from those of the same vendor (eg. MediaTek's PPE supports MediaTek's 4-byte special tag, but includes "plain" 802.1Q or 802.1ad/Q-in-Q as part of the tuple identifying a flow). Hence by implementing an 802.1Q-based tag one can benefit from better performance, less CPU load and less energy consumption when combining these switches with router SoCs of other vendors if they implementing "picky" offloading fast-paths. > > Another (related) question. You have this comment in tag_mxl862xx.c: > > /* switch firmware expects ports to be counted starting from 1 */ > > from which I don't completely understand how is the firmware involved > (does it process the tags?). Would the expectation also apply to the > 802.1Q based tagger? No. The 802.1Q-based tagger is basically implemented entirely by setting up additional bridges, virtual bridge ports and special VLAN forwarding rules. It takes more than just "switching" the tag protocol... But hence it can be implemented in pretty much any way we want. > > What's the real story behind port index 0? Does it really not exist, or > is it some attempt to hide an internal port that's not supposed to be used? It's just an oddity of the management firmware which runs on the switch. Port ID 0 has special meaning, physical ports are counted started from 1. For example, when adding FDB entries, port_id == 0 means not specifying a port (eg. for filter rules). However, it *is* weird that BIT(0) of any portmap isn't ever used in the driver, and it looks like it could be like you describe below. I will ask. > > If the latter, I guess something like the snippet below (seen in > arch/arm64/boot/dts/freescale/fsl-lx2160a-bluebox3.dts) would simplify > the driver by a bit: > > ethernet-switch@0 { > ... > ethernet-ports { > ... > /* Microcontroller port */ > port@0 { > reg = <0>; > status = "disabled"; > }; This construct could never the less help to make things more easy and less annoying to deal with. I might just start counting from reg = <1> in DT and have a dummy/reserved port 0. Always having add/substract 1 is often confusing because then you have to remember if a port number or mask stored in some structure or variable denotes the DSA perspective or the switch firmware perspective. Unifying the two would definitely be beneficial. I can give that a short tomorrow.