From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sonic314-22.consmr.mail.ne1.yahoo.com (sonic314-22.consmr.mail.ne1.yahoo.com [66.163.189.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7E38A1427A for ; Sun, 17 May 2026 07:12:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=66.163.189.148 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779001924; cv=none; b=j2/ZZRN/bJ06BfcBMYCP/CiaiZKxV+sB8W45FLni/wvl2EHyysJ9Il7cHfg88xA2eOg/810WhkWDlUgULENZXw711SydykYRTJbF5YQgID3r5YC3cInDETS7jMTTlQRSXIc8e/9D/GOdmMfqNo0qK1aOfqusHaY3jk95vaGuZi8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779001924; c=relaxed/simple; bh=W42+bh+AN0wWT/bejzYcTPCDS3JMPkEfRl6VbOqD4o4=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=B89u29mieFxEM2tCuOlCm6VhClqXLC0LP5o2atIgPDqt20gc/ejwx59WhjuKmOdIpDotqpbr6qcULKOTDBk0jfqwl1eNKF9HvjBJpIHisBsb7m3pcVYpxhO0GlbocI3Y3Dv9IR4Dtz6B7DfiMrKEVmY2piQGujmPy5YZzhxIRIM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=yahoo.com; spf=pass smtp.mailfrom=yahoo.com; dkim=pass (2048-bit key) header.d=yahoo.com header.i=@yahoo.com header.b=BpVRo7Ib; arc=none smtp.client-ip=66.163.189.148 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=yahoo.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=yahoo.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=yahoo.com header.i=@yahoo.com header.b="BpVRo7Ib" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1779001921; bh=mX7woosI9CQkNgA6oJNCXGUH9GTMSUXYEf/Pv/zp7IA=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From:Subject:Reply-To; b=BpVRo7IbyE4BhYZGEac6NdLyRz7i//op5GAziW8m/AsXxvpNxeHzqOVQziY8XtySzNiub+g4ghweyEdiUO6Py2KA+JDlvxlZG3IN+ScF+FS4LL7Wr6mbYqtNHaqhgSOg4hmk+Ir8+xqMNRYWw9Dns9HZgARI5SsXrRHx7uU2l9b4Gl3JQa6xDMVTehY7Lo9UZthuxoisjRoQsLOHQKN4DxpE0wqxqyMcWIaNkzKCiBMtt+hjtj+7K9pPJSAeeU6OINVqbq26+lgatGrS+uwgwoTpQwaqZ68BbtmwGNOMqm5dhsYlwAQnPmvHosVDgw9ANARj2ADKEN6DG/YJ8DPbOw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1779001921; bh=lKn6Uh/NZK+j7TG4QRxB14WfUKGH44LdoqOwRtuTEk+=; h=X-Sonic-MF:Date:Subject:To:From:From:Subject; b=RhSFXWGvPBVLR2QuKUSKefQWvfuTakXAzA0UYNr5Qgot5ytBfts4eOh3iXQb9y9Sxue+a6befYup+dpmf0F8KqhkFCnMtonwNYGWDdDT4DFRNnBzPQBhBbeRP6D0y858W+oviWwRKrjjLXxdZTvaZTzvnj7neqlb4NXOknIM2div287KIa210NpNYAfLGeTNhTD7o2/rm/9JhDjDCzKoqk4S3Qz5NPnKmXiX3JFJrVa/aay1pgn+PAT0iRx7cWmEXf1lkUrJKFqG5DNioks0bAV7w9VXcMwhL3MxcngSIoVM4hDwUhQqUywe+oBqqXJ9bHL8eOUEj72ppYJkxapSww== X-YMail-OSG: av27AGIVM1k2apDtDkZIa5p4108zk1TM7TnaQx99B5TuZtD.uN67.hCwlhDMM7X lJgceHUK3drIq0EtBsSCtFL3nFs6li2_TxsBvxHpOVt1ojgMU5jA1352fPE4k.GuqpS_c6pIsftx UdPngIW0ydaETr0HLSECm14vHX7XLLIb3t6XmLi1fYoIHDAZBQ2CRDcY8hWG.LfL_Nplgl6BBKIM Nc8IIcQ07gFH6lBSKIj3mJ4Z57PfB_rw617WoM2428IWVBQvgtlC9EGYe8qFplb9JEWqxNxLikv3 FPV9MHhqU1Ggb7OniAqNcCCzJvqnKAZ_eFrfO4lwhRtNkcV0AiEZdMFKGLnMyodEh5n.Feu28NYE 6z1qlQaqkyXCc.NmPW73j9GPFSLeePNVcauaJl1HpBSmbX9riG7gdJaMc281Rhe5_LL7YLDMHLYr uOGXt5_vmms2SqA8WRr6NJyEQi0Vg0hwp5C4L_fIKtC1HIuJSg1PKKvyRXysGMKPLfmYhxyotFF8 bVQXMqDWwAp2YTIOQtsvSk1KMonLgtdjvIGYq.TpPWVb6RV81C2ZWXdxvTUGk6UnFKo1NZO71.P5 6iZrDGgskU49IBNSfrYH4vbjaAwFvrl3amBf9MWNabKRXCEhC1rv6E4ceBqxOEK5pSqeNgPJPrr_ L64G_7SMwFYD8SwBoh9PadcVg2QV4y63hdAG_XcfbmWsX9uwHYIFMpobuQJwMDBJAs24h56Wgqk4 MJ1O9PU13AAvG1NHtd99jUT6mOp2QrPB4rU_0GRV85wVPepntVmx16v.HBcQk_0.cO3hsAoE43MJ RdUsvbmnU7Jlid6gHEYN8xv0WeRGuGSUP7S5mP2IvgGphqYVlkT6ri87LwtHkojMiwfMHdDcg71C pTZi5qPajgUU8atIG.3oAWA52ydbN_eU59IFNRW3HMhWwq5xAofvQmpmk8NOUeaOp.oOJ8jHub.h lT9LAjpqylqBgsnEi5wCAVz2iBIngpg3iXkMAJS3rWrrZHOuAC9H.SJHHIVpgQMWlTuaLXhK3dLh 77.Ormm8QyJF_BNwOLkalYFFzk0c28kzrvz4ZXQsfYGRVLLGB8zem43zWmeSv2zjWhQwprJ_T1cs 8qXtjr4dpB7KRQ5kWFAhs7w35sp83i9x9KGJqGEJ5w4QF3B2jXZ7.QbnbkuL1n.DInS2UIq8bsCY tlsJaS1ga4XwyyDm1elhIJa1i2xZX8EGAwj6bBrRzfz2YslqmSE70o6a2vpfeTDswcGFvjxZ7Axy OSBZw1CG5QiQqvmGq_S59GEhIe6yZLeJSyDYCEjqkGUUnOTQa7hAMOEshyacmaKIfP9HQMY7vpik f_VO0pyjLPpYyWSVLTR5Ak48m4u6yogKpmy1jUZNrZwS8PDYGLkupXEDGyD7jk1uU9PRSxp4.kws aQVMSxi_ONisEXk10CgQHxo3D4Xj434HKAfBIgtNiEf_1QPrJYayguYroylMpZgnrR.MuywtJWFE urTGzDv12loZb541sTFDcQ7p4nqIQWEKU2CrNMXg7LpJTDBGp7H4GdhmuKrQXVH1uER5lgUiTr3_ lP.2g1Jrkhqsk2v.1Jzn4qBUMpc.cgmKRQhhB7DzK_Wtjgb54HB_8q38zsfkwu4bEW8DbFwkXseY HRf7CM0Z4BIKcNzPCoNEisNynmkKkQsh6X7xL1VwiHkDJpr3MUaZTRCv1cHT9mkcbVXSKaBuuuGa wAsSHPTR50s6AbsxqFtog.7Uhdwpm3kKe2nwgYYkSSEI3qEEC0ypx1GcZL62sRmkeWMIXbZNvb3. 62IlH78Nbm8GlbjH.A_HPtHYRLXoBbpg.jD7eOAqw0LDucBOlHWA9rJT.vh4oWBXi1VczUEe.5ZD TODVmLEOQac1nW4wevm1ntNJgRjPTQbQoLqHJELWhlLjdCfBe_iN8MMTCHpiz_C83j7N4l_ElCNw pi9RDaJA0SpOxDFiM0tLJjjEzLFmFDm5RD0y7rbsAXdfdJ2ofUP9IlYqCbImM6wByQlN_AnX65y7 _OScZtaUJZZVcSyDNgcheLmKFZN3WATtL47SbFV6pEDR8HGCsq3m0w3EVhTOKoYIhduXW.4PTbCz f5_1I435qBYMBIW7dpHgTeo3B95gwgIfZ._RqzDvvI_Dklw.MchFgun09jYDdyASn6ZUTHz7tqKF AxzNtcg1sKeiS5PTz79OulO6Y9Dz3Bq1hYw6GDFHykDNiFh7TuPWA9CTELB8yDfur.LEgV5SDtTF vaJeIMTogMVSjCgtBDnLx7qUyKPKlUBEKDkUb4Maq6srk_kGDOkaw49Gn52Q8tTiIRLyEGtueAxj VR4u3O.KpONsyOzo1WoT4d.foo4rkTlm.12Vm0gKmIgIb9w-- X-Sonic-MF: X-Sonic-ID: bc5eede1-969f-408a-80ee-c1c399b04dca Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.ne1.yahoo.com with HTTP; Sun, 17 May 2026 07:12:01 +0000 Received: by hermes--production-ir2-89844b765-vmp7w (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID ef2b852bfea421f08da7457608ddab95; Sun, 17 May 2026 07:01:44 +0000 (UTC) Message-ID: Date: Sun, 17 May 2026 09:01:40 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [net-next PATCH v4 5/8] net: dsa: realtek: rtl8365mb: add VLAN support To: Luiz Angelo Daros de Luca , Andrew Lunn , Vladimir Oltean , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Linus Walleij , =?UTF-8?Q?Alvin_=C5=A0ipraga?= , Yury Norov , Rasmus Villemoes , Russell King Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Yury Norov , Abdulkader Alrezej References: <20260516-realtek_forward-v4-0-8b6d6a1eefdc@gmail.com> <20260516-realtek_forward-v4-5-8b6d6a1eefdc@gmail.com> Content-Language: pl From: Mieczyslaw Nalewaj In-Reply-To: <20260516-realtek_forward-v4-5-8b6d6a1eefdc@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Mailer: WebService/1.1.25725 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo On 5/16/2026 5:46 AM, Luiz Angelo Daros de Luca wrote: > From: Alvin Šipraga > > Realtek RTL8365MB switches (a.k.a. RTL8367C family) use two different > structures for VLANs: > > - VLAN4K: A full table with 4096 entries defining port membership and > tagging. > - VLANMC: A smaller table with 32 entries used primarily for PVID > assignment. > > In this hardware, a port's PVID must point to an index in the VLANMC > table rather than a VID directly. Since the VLANMC table is limited to > 32 entries, the driver implements a dynamic allocation scheme to > maximize resource usage: > > - VLAN4K is treated by the driver as the source of truth for membership. > - A VLANMC entry is only allocated when a port is configured to use a > specific VID as its PVID. > - VLANMC entries are deleted when no longer needed as a PVID by any port. > > Although VLANMC has a members field, the switch only checks membership > in the VLAN4K table. However, when a corresponding VLAN entry also exists > in VLANMC, this driver keeps both membership configurations in sync. > > VLANMC index 0, although a valid entry, is reserved in this driver as a > neutral PVID value for ports not using a specific PVID. > > In the subsequent RTL8367D switch family, VLANMC table was > removed and PVID assignment was delegated to a dedicated set of > registers. > > All ports start isolated, forwarding exclusively to CPU ports, and > with VLAN transparent, ignoring VLAN membership. Once a member in a > bridge, the port isolation is expanded to include the bridge members. > When that bridge enables VLAN filtering, the VLAN transparent feature is > disabled, letting the switch filter based on VLAN setup. > > The use of FIELD_PREP for reconstructing LO/HI values was suggested by > Yury Norov. > > Fix for vlan_setup and vlan_filtering was suggested by Abdulkader > Alrezej. > > Suggested-by: Yury Norov > Suggested-by: Abdulkader Alrezej > Co-developed-by: Alvin Šipraga > Signed-off-by: Alvin Šipraga > Reviewed-by: Linus Walleij > Signed-off-by: Luiz Angelo Daros de Luca > [...] > @@ -1196,6 +1258,195 @@ static void rtl8365mb_port_stp_state_set(struct dsa_switch *ds, int port, > val << RTL8365MB_MSTI_CTRL_PORT_STATE_OFFSET(port)); > } > > +static int rtl8365mb_port_set_transparent(struct realtek_priv *priv, > + int igr_port, int egr_port, > + bool enable) > +{ > + dev_dbg(priv->dev, "%s transparent VLAN from %d to %d\n", > + enable ? "Enable" : "Disable", igr_port, egr_port); > + > + /* "Transparent" between the two ports means that packets forwarded by > + * igr_port and egressed on egr_port will not be filtered by the usual > + * VLAN membership settings. > + */ > + return regmap_update_bits(priv->map, > + RTL8365MB_VLAN_EGRESS_TRANSPARENT_REG(egr_port), > + BIT(igr_port), enable ? BIT(igr_port) : 0); > +} > + > +static int rtl8365mb_port_set_ingress_filtering(struct realtek_priv *priv, > + int port, bool enable) > +{ > + /* Ingress filtering enabled: Discard VLAN-tagged frames if the port is > + * not a member of the VLAN with which the packet is associated. > + * Untagged packets will also be discarded unless the port has a PVID > + * programmed. Priority-tagged frames are treated as untagged frames. > + * > + * Ingress filtering disabled: Accept all tagged and untagged frames. > + */ > + return regmap_update_bits(priv->map, RTL8365MB_VLAN_INGRESS_REG, > + RTL8365MB_VLAN_INGRESS_FILTER_PORT_EN_MASK(port), > + enable ? > + RTL8365MB_VLAN_INGRESS_FILTER_PORT_EN_MASK(port) : > + 0); > +} > + > +static int > +rtl8365mb_port_set_vlan_egress_mode(struct realtek_priv *priv, int port, > + enum rtl8365mb_vlan_egress_mode mode) > +{ > + u32 val; > + > + val = FIELD_PREP(RTL8365MB_PORT_MISC_CFG_VLAN_EGRESS_MODE_MASK, mode); > + return regmap_update_bits(priv->map, > + RTL8365MB_PORT_MISC_CFG_REG(port), > + RTL8365MB_PORT_MISC_CFG_VLAN_EGRESS_MODE_MASK, val); > +} > + > +static int rtl8365mb_port_vlan_filtering(struct dsa_switch *ds, int port, > + bool vlan_filtering, > + struct netlink_ext_ack *extack) > +{ > + enum rtl8365mb_vlan_egress_mode mode; > + struct realtek_priv *priv = ds->priv; > + struct dsa_port *dp; > + int ret; > + > + dev_dbg(priv->dev, "port %d: %s VLAN filtering\n", port, > + vlan_filtering ? "enable" : "disable"); > + > + /* When vlan filter is enable/disabled in a bridge, this function is > + * called for all member ports. We need to enable/disable ingress > + * VLAN membership check. > + */ > + ret = rtl8365mb_port_set_ingress_filtering(priv, port, vlan_filtering); > + if (ret) > + return ret; > + > + /* However, we also enable/disable egress filtering because the switch > + * still consider the egress interface VLAN membership to forward the > + * traffic. We enable/disable that check disabling/enabling transparent > + * VLAN between the ingress port and all other available ports. > + */ > + dsa_switch_for_each_available_port(dp, ds) { > + /* port isolation will still keep traffic inside the bridge */ > + ret = rtl8365mb_port_set_transparent(priv, port, dp->index, > + !vlan_filtering); > + if (ret) > + goto undo_transparent; > + } > + > + /* When VLAN filtering is disabled, preserve frames exactly as received. > + * Otherwise, the VLAN egress pipeline may still alter tag state > + * according to VLAN membership and untag configuration. > + */ > + if (vlan_filtering) > + mode = RTL8365MB_VLAN_EGRESS_MODE_ORIGINAL; > + else > + mode = RTL8365MB_VLAN_EGRESS_MODE_REAL_KEEP; > + > + ret = rtl8365mb_port_set_vlan_egress_mode(priv, port, mode); > + if (ret) > + goto undo_transparent; > + > + return ret; > + > +undo_transparent: > + /* It will also try to undo the failed port if the error happened > + * inside the transparent VLAN loop but that might be inocuous. > + */ > + dsa_switch_for_each_port_continue_reverse(dp, ds) { > + if (dsa_port_is_unused((dp))) - typo inocuous - innocuous - redundant inner parens around dp in dsa_port_is_dsa((dp))