linux-kernel - Re: [PATCH net] net: enetc: fix wrong TPID registers and remove dead branch

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250530165434.xzdroce3i2mmwxcf@skbuf>
Date: Fri, 30 May 2025 19:54:34 +0300
From: Vladimir Oltean <vladimir.oltean@....com>
To: Wei Fang <wei.fang@....com>
Cc: claudiu.manoil@....com, xiaoning.wang@....com, andrew+netdev@...n.ch,
	davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
	pabeni@...hat.com, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, imx@...ts.linux.dev
Subject: Re: [PATCH net] net: enetc: fix wrong TPID registers and remove dead
 branch

Hi Wei,

On Fri, May 30, 2025 at 05:00:12PM +0800, Wei Fang wrote:
> Both PF and VF have rx-vlan-offload enabled, however, the PCVLANR1/2
> registers are resources controlled by PF, so VF cannot access these
> two registers. Fortunately, the hardware provides SICVLANR1/2 registers
> for each SI to reflect the value of PCVLANR1/2 registers. Therefore,
> use SICVLANR1/2 instead of PCVLANR1/2.
> 
> In addition, since ENETC_RXBD_FLAG_TPID is defined as GENMASK(1, 0),
> the possible values are only 0, 1, 2, 3, so the default branch will
> never be true, so remove the default branch.
> 
> Fixes: 827b6fd04651 ("net: enetc: fix incorrect TPID when receiving 802.1ad tagged packets")
> Signed-off-by: Wei Fang <wei.fang@....com>

I see what the patch is trying to do, but how did you test/reproduce this?
The CVLANR1/CVLANR2 registers are by default zero, and the driver
doesn't write them, so I guess custom TPID values are never recognized
in net-next. In such situations, I believe fixing a bug that has no
consequences should also be considered net-next material (and net-next
is currently closed until June 8th).

> ---
>  drivers/net/ethernet/freescale/enetc/enetc.c    | 12 +++++-------
>  drivers/net/ethernet/freescale/enetc/enetc_hw.h |  5 +++--
>  2 files changed, 8 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/net/ethernet/freescale/enetc/enetc.c b/drivers/net/ethernet/freescale/enetc/enetc.c
> index dcc3fbac3481..e4287725832e 100644
> --- a/drivers/net/ethernet/freescale/enetc/enetc.c
> +++ b/drivers/net/ethernet/freescale/enetc/enetc.c
> @@ -1375,6 +1375,7 @@ static void enetc_get_offloads(struct enetc_bdr *rx_ring,
>  	}
>  
>  	if (le16_to_cpu(rxbd->r.flags) & ENETC_RXBD_FLAG_VLAN) {
> +		struct enetc_hw *hw = &priv->si->hw;
>  		__be16 tpid = 0;
>  
>  		switch (le16_to_cpu(rxbd->r.flags) & ENETC_RXBD_FLAG_TPID) {
> @@ -1385,15 +1386,12 @@ static void enetc_get_offloads(struct enetc_bdr *rx_ring,
>  			tpid = htons(ETH_P_8021AD);
>  			break;
>  		case 2:
> -			tpid = htons(enetc_port_rd(&priv->si->hw,
> -						   ENETC_PCVLANR1));
> +			tpid = htons(enetc_rd_hot(hw, ENETC_SICVLANR1) &
> +				     SICVLANR_ETYPE);
>  			break;
>  		case 3:
> -			tpid = htons(enetc_port_rd(&priv->si->hw,
> -						   ENETC_PCVLANR2));
> -			break;
> -		default:
> -			break;
> +			tpid = htons(enetc_rd_hot(hw, ENETC_SICVLANR2) &
> +				     SICVLANR_ETYPE);
>  		}
>  
>  		__vlan_hwaccel_put_tag(skb, tpid, le16_to_cpu(rxbd->r.vlan_opt));
> diff --git a/drivers/net/ethernet/freescale/enetc/enetc_hw.h b/drivers/net/ethernet/freescale/enetc/enetc_hw.h
> index 4098f01479bc..0385aa66a391 100644
> --- a/drivers/net/ethernet/freescale/enetc/enetc_hw.h
> +++ b/drivers/net/ethernet/freescale/enetc/enetc_hw.h
> @@ -43,6 +43,9 @@
>  
>  #define ENETC_SIPMAR0	0x80
>  #define ENETC_SIPMAR1	0x84
> +#define ENETC_SICVLANR1	0x90
> +#define ENETC_SICVLANR2	0x94
> +#define  SICVLANR_ETYPE	GENMASK(15, 0)
>  
>  /* VF-PF Message passing */
>  #define ENETC_DEFAULT_MSG_SIZE	1024	/* and max size */
> @@ -178,8 +181,6 @@ enum enetc_bdr_type {TX, RX};
>  #define ENETC_PSIPMAR0(n)	(0x0100 + (n) * 0x8) /* n = SI index */
>  #define ENETC_PSIPMAR1(n)	(0x0104 + (n) * 0x8)
>  #define ENETC_PVCLCTR		0x0208
> -#define ENETC_PCVLANR1		0x0210
> -#define ENETC_PCVLANR2		0x0214

I think you can leave these definitions in place. They will be useful if
we ever add support for custom TPIDs. Having the definitions doesn't
increase the compiled driver footprint in any way.

>  #define ENETC_VLAN_TYPE_C	BIT(0)
>  #define ENETC_VLAN_TYPE_S	BIT(1)
>  #define ENETC_PVCLCTR_OVTPIDL(bmp)	((bmp) & 0xff) /* VLAN_TYPE */
> -- 
> 2.34.1
>