[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <696fb436-40f6-4a9c-af0b-2851f8450bd1@lunn.ch>
Date: Fri, 3 Jan 2025 17:25:12 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Wei Fang <wei.fang@....com>
Cc: claudiu.manoil@....com, vladimir.oltean@....com, xiaoning.wang@....com,
andrew+netdev@...n.ch, davem@...emloft.net, edumazet@...gle.com,
kuba@...nel.org, pabeni@...hat.com, christophe.leroy@...roup.eu,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
linuxppc-dev@...ts.ozlabs.org, linux-arm-kernel@...ts.infradead.org,
imx@...ts.linux.dev
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?
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.
Andrew
Powered by blists - more mailing lists