linux-kernel - RE: [PATCH net-next v4 1/2] net: stmmac: Refactor VLAN implementation

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] [day] [month] [year] [list]

Message-ID:
 <BN8PR03MB507352B608A7E90E5017E017B4812@BN8PR03MB5073.namprd03.prod.outlook.com>
Date: Mon, 28 Apr 2025 08:34:33 +0000
From: "Ng, Boon Khai" <boon.khai.ng@...era.com>
To: Simon Horman <horms@...nel.org>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-stm32@...md-mailman.stormreply.com"
	<linux-stm32@...md-mailman.stormreply.com>,
	"linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "bpf@...r.kernel.org" <bpf@...r.kernel.org>,
	Andrew Lunn <andrew+netdev@...n.ch>, "David S . Miller"
	<davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski
	<kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Maxime Coquelin
	<mcoquelin.stm32@...il.com>, Alexandre Torgue <alexandre.torgue@...s.st.com>,
	Russell King <linux@...linux.org.uk>, Alexei Starovoitov <ast@...nel.org>,
	Daniel Borkmann <daniel@...earbox.net>, Jesper Dangaard Brouer
	<hawk@...nel.org>, John Fastabend <john.fastabend@...il.com>, Furong Xu
	<0x1207@...il.com>, "Gerlach, Matthew" <matthew.gerlach@...era.com>, "Ang,
 Tien Sung" <tien.sung.ang@...era.com>, "Tham, Mun Yew"
	<mun.yew.tham@...era.com>, "G Thomas, Rohan" <rohan.g.thomas@...era.com>
Subject: RE: [PATCH net-next v4 1/2] net: stmmac: Refactor VLAN implementation

> 
> Here the XGMAC_FILTER_VTFE bit of XGMAC_PACKET_FILTER is set.
> However, this logic does not appear in vlan_update_hash()
> 

Hi Simon,

This is a bit tricky when combining both implementations,
but it seems to be a software difference rather than a hardware one. 
According to the documentation, the VTFE bit is located at the same
offset for both.

Comparing dwmac4 and dwxgmac2, the VTFE bit is enabled in
different places:

In dwmac4, it is set in dwmac4_set_filter().
In dwxgmac2, it is set in dwxgmac2_update_vlan_hash().

>From my testing, both approaches work. I ported the
code from dwmac4 to stmmac_vlan.c and verified it on
dwxgmac2 successfully.

> 
> And likewise, here value is based on reading from XGMAC_VLAN_TAG.
> Whereas in vlan_update_hash is constructed without reading from
> XGMAC_VLAN_TAG.

Both drivers write to VLAN_TAG, but they differ in when they read it.
dwmac4 reads VLAN_TAG at the start of the function.

dwxgmac2 reads it within each if block.
The difference seems intentional: in dwxgmac2, the same value
variable is used to program both XGMAC_PACKET_FILTER and
XGMAC_VLAN_TAG, so reading VLAN_TAG at 
the beginning would be overwritten anyway.

When merging into stmmac_vlan.c, I believe we can
consolidate both paths cleanly and avoid discrepancies, 
which aligns with Andrew's goal of combining them.

> 
> Can I clarify that this is intentional and that vlan_update_hash(), which is based
> on the DWMAC4 implementation, will also work for DWXGMAC IP?
> 

Yes, based on my tests and the documentation (same register offsets),
 it works for DWXGMAC IP as well.

> 
> I am curious to know why readl_poll_timeout() isn't used here as was the case
> in dwmac4_write_vlan_filter().

This was my oversight when porting from older dwmac4 code. 
As Russell pointed out, I will update it to use the latest dwmac4 
VLAN handling code in v5.

Regards,
Boon Khai.