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

[Saeed Mahameed <saeed@kernel.org>]

On 16 Nov 08:30, Jakub Kicinski wrote:
>On Mon, 14 Nov 2022 17:13:05 -0800 Jakub Kicinski wrote:
>> On Tue, 15 Nov 2022 02:06:19 +0100 Andrew Lunn wrote:
>> > > 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.
>> >
>> > I wondered about that, but i'm not sure initdata works for modules,
>> > and for hot pluggable devices like PCIe, you never know when another
>> > one might appear and you need the tables.
>>
>> Right, I meant that the request_firmware() version can discard
>> the tables. I shouldn't have said tables :)
>
>Saeed, David, are you looking into this? The problem come up again
>in a Realtek USB conversation.
>
>The task is so small and well defined I'm pretty sure I can get some
>aspiring kernel developer at Meta to knock it off in a few days.
>

Give me a couple of days and will let you know what's the verdict.
I sent David and Asmaa the links to read up on Request Firmware. Still
waiting for a response.

>FWIW the structure of a file I had in mind would be something like this:
>
># Section 0 - strings (must be section 0)
> # header
> u32 type:   1   # string section
> u32 length: n   # length excluding header and pads
> u32 name:   0   # offset to the name in str section
> u32 pad:    0   # align to 8B
> # data
> .str\0table_abc\0table_def\0some_other_string\0
> # pad, align to 8B
> \0\0\0\0\0\0\0
>
># Section 1 - table_abc
> # header
> u32 type:   2   # 32b/32b table
> u32 length: 64  # length excluding header and pads
> u32 name:   5   # offset to the name in str section
> u32 pad:    0
> # data
> [ 0x210, 0xc00ff ]
> [ 0x214, 0xffeee ]
> [ 0x218, 0xdeaddd ]
> [ 0x21c, 0xc4ee5e ]
> [ 0x220, 0xc00ff ]
> [ 0x224, 0xffeee ]
> [ 0x228, 0xdeaddd ]
> [ 0x22c, 0xc4ee5e ]
>
>etc.
>
>Use:
>	struct fw_table32 *abc, *def;
>
>	fw = request_firmware("whatever_name.ftb");
>	
>	abc = fw_table_get(fw, "table_abc");
>	/* use abc */
>

abc is just a byte buffer ? right ?

>	def = fw_table_get(fw, "table_def");
>	/* use def */
>

And what goes here? any constraints on how the driver must interpret
and handle abc/def blobs ? 

>	release_firmware(fw)

What if the same abc blob structure/table format is used to setup dynamic link
properties, say via ethtool -s ? Then the whole request firmware will be
redundant since "struct abc {};" must be defined in the driver src code.

I like the idea, i am just trying to figure how we are going to define it
and how developers will differentiate between when to use this or when to
use standard APIs to setup their devices.