linux-kernel - RE: [PATCH net-next v3 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] [thread-next>] [day] [month] [year] [list]

Message-ID:
 <BN8PR03MB5073BB4178D942835179AE68B4B82@BN8PR03MB5073.namprd03.prod.outlook.com>
Date: Mon, 21 Apr 2025 16:40:14 +0000
From: "Ng, Boon Khai" <boon.khai.ng@...era.com>
To: Furong Xu <0x1207@...il.com>
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>, "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 v3 1/2] net: stmmac: Refactor VLAN implementation

 
> Rename dwmac_vlan_ops to dwmac4_vlan_ops will be better,
> just like dwmac4_desc_ops/dwmac4_dma_ops

Hi Furong thanks for the feedback, 

This dwmac_vlan_ops is defined the same at dwmac4, dwmac510, 
and dwxgmac210, thus consolidate them in the 
same ops: dwmac_vlan_ops.

> dwxlgmac2_vlan_ops looks redundant here, another new struct contains
> totally identical members.
> 
> stmmac_do_void_callback()/stmmac_do_callback() handles NULL function
> pointers so good, we can leave the un-implemented functions as NULL.
> 
> Are you trying to avoid something undefined here?

Nope, since dwxlgmac2_vlan_ops does not hold the same ops with
dwxgmac210, dwmac4, dwmac510, this is not newly enabled, just move
over from the initial implementation on the ops assignment.

> 
> It is a good practice to only keep inside the header those definitions
> which are truly exported by stmmac_vlan.c towards external callers.
> That means those #defines which are only used within stmmac_vlan.c
> shouldn't be here, but inside stmmac_vlan.c file.

I prefer to keep all #define directives in the header file to enhance
 code readability and debugging efficiency by providing a single
reference point for developers.

Regards,
Boon Khai.