Re: [PATCH net-next v2 3/4] mlxbf_gige: add BlueField-3 Serdes configuration

[Jakub Kicinski <kuba@kernel.org>]

On Sat, 12 Nov 2022 01:52:47 -0800 Saeed Mahameed wrote:
> >Well, the patch was marked as Changes Requested so it seems that DaveM
> >concurs :) (I'm slightly desensitized to those tables because they
> >happen in WiFi relatively often.)
> >
> >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 ?

Yes, that's what I meant.

> 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?

I don't feel particularly strongly but seems like something worth
exploring. A minor advantage is that once the init is done the tables
can be discarded from memory.

> >We did have a recommendation against parsing FW files in the kernel at
> >some point, too, but perhaps this is simple enough to pass.
> >
> >Should this be shared infra? The problem is fairly common.  
> 
> Infrastructure to parse vendor Firmware ? we can't get vendors to agree on
> ethtool interface, you want them to agree on one firmware format :)?

We can keep the table format pretty much as is. What I had in mind was
basically creating a binary file format with u64 address, and u64 data.
Plus file sections to pack multiple tables into one file.
Pretty pleasant coding exercise if you ask me :)

> BTW i don't think the issue here is firmware at all, this is device
> specific config space.