netdev - RE: [PATCH net-next 05/13] net: enetc: add debugfs interface to dump MAC filter

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:
 <PAXPR04MB8510C38BC40EB0E6D95F726888102@PAXPR04MB8510.eurprd04.prod.outlook.com>
Date: Mon, 6 Jan 2025 02:19:06 +0000
From: Wei Fang <wei.fang@....com>
To: Andrew Lunn <andrew@...n.ch>
CC: Claudiu Manoil <claudiu.manoil@....com>, Vladimir Oltean
	<vladimir.oltean@....com>, Clark Wang <xiaoning.wang@....com>,
	"andrew+netdev@...n.ch" <andrew+netdev@...n.ch>, "davem@...emloft.net"
	<davem@...emloft.net>, "edumazet@...gle.com" <edumazet@...gle.com>,
	"kuba@...nel.org" <kuba@...nel.org>, "pabeni@...hat.com" <pabeni@...hat.com>,
	"christophe.leroy@...roup.eu" <christophe.leroy@...roup.eu>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
	"linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "imx@...ts.linux.dev"
	<imx@...ts.linux.dev>
Subject: RE: [PATCH net-next 05/13] net: enetc: add debugfs interface to dump
 MAC filter

> Subject: Re: [PATCH net-next 05/13] net: enetc: add debugfs interface to dump
> MAC filter
> 
> On Fri, Jan 03, 2025 at 02:06:01PM +0800, Wei Fang wrote:
> > ENETC's MAC filter consists of hash MAC filter and exact MAC filter. Hash
> > MAC filter is a 64-entry hash table consisting of two 32-bit registers.
> > Exact MAC filter is implemented by configuring MAC address filter table
> > through command BD ring. The table is stored in ENETC's internal memory
> > and needs to be read through command BD ring. In order to facilitate
> > debugging, added a debugfs interface to get the relevant information
> > about MAC filter.
> 
> How do other drivers do this?

I don't know about other vendor's hardware, but IMO, if the configuration is
done through registers, we only need to debug through some tools that read
and write registers, such as devmem2. I also saw some drivers added debugfs
interface, such as Intel, Huawei, Marvell, etc. I think they also added it to
facilitate obtaining some debugging information.

> 
> You should only use debugfs if there is no standard way to accomplish
> something. And if there is no standard way, you should be thinking is
> this a common feature other drivers will need, and if so, add a
> standard mechanism.
> 
> You will get pushback for using debugfs as a bumping ground without
> adding some justification that debugfs is the only possible solution.
> 

IMO, standard methods are only suitable for extracting common
information, but each vendor's implementation is not uniform, and the
specific details are also different. It is impossible to obtain every detail
information through standard methods. The purpose of adding debugfs
is just to facilitate debugging, so we need to obtain all the detailed
information, so I think the debugfs interface is good, which allows us to
obtain every specific information in all NETC tables.