[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y2/BeNsW4EH9v+Mv@lunn.ch>
Date: Sat, 12 Nov 2022 16:53:28 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Saeed Mahameed <saeed@...nel.org>
Cc: Jakub Kicinski <kuba@...nel.org>,
David Thompson <davthompson@...dia.com>, davem@...emloft.net,
edumazet@...gle.com, pabeni@...hat.com, netdev@...r.kernel.org,
cai.huoqing@...ux.dev, brgl@...ev.pl, limings@...dia.com,
chenhao288@...ilicon.com, huangguangbin2@...wei.com,
Asmaa Mnebhi <asmaa@...dia.com>
Subject: Re: [PATCH net-next v2 3/4] mlxbf_gige: add BlueField-3 Serdes
configuration
> > The recommendation is to come up with a format for a binary file, load
> > it via FW loader and then parse in the kernel?
>
> By FW loader you mean request_firmware() functionality ?
>
> I am not advocating for black magic tables of course :), but how do we
> avoid them if request_firmware() will be an overkill to configure such a
> simple device? Express such data in a developer friendly c structures
> with somewhat sensible field names?
Do you think anybody other than your company has the ability to change
these values? Is there useful documentation about what they do, even
if it is under NDA? Why would somebody actually need to change them?
Is here functionally here which you don't support but the community
might like to add?
Expressing the data in a developer friendly C structure only really
make sense if there is a small collection of developers out there who
have the skills, documentation and maybe equipment to actually make
meaningful changes.
I don't like making it harder to some clever people to hack new stuff
into your drivers, but there are so few contributions from the
community to your drivers that it might as well be black magic, and
just load the values from a file.
Andrew
Powered by blists - more mailing lists