All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Saeed Mahameed <saeed@kernel.org>,
	David Thompson <davthompson@nvidia.com>
Cc: Andrew Lunn <andrew@lunn.ch>,
	davem@davemloft.net, edumazet@google.com, pabeni@redhat.com,
	netdev@vger.kernel.org, cai.huoqing@linux.dev, brgl@bgdev.pl,
	limings@nvidia.com, chenhao288@hisilicon.com,
	huangguangbin2@huawei.com, Asmaa Mnebhi <asmaa@nvidia.com>
Subject: Re: [PATCH net-next v2 3/4] mlxbf_gige: add BlueField-3 Serdes configuration
Date: Wed, 16 Nov 2022 08:30:56 -0800	[thread overview]
Message-ID: <20221116083056.016e3107@kernel.org> (raw)
In-Reply-To: <20221114171305.6af508be@kernel.org>

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.

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 */

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

	release_firmware(fw)

  reply	other threads:[~2022-11-16 16:37 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-09 22:47 [PATCH net-next v2 0/4] mlxbf_gige: add BlueField-3 support David Thompson
2022-11-09 22:47 ` [PATCH net-next v2 1/4] mlxbf_gige: add MDIO support for BlueField-3 David Thompson
2022-11-10 13:24   ` Andrew Lunn
2022-11-09 22:47 ` [PATCH net-next v2 2/4] mlxbf_gige: support 10M/100M/1G speeds on BlueField-3 David Thompson
2022-11-10 13:23   ` Andrew Lunn
2022-11-09 22:47 ` [PATCH net-next v2 3/4] mlxbf_gige: add BlueField-3 Serdes configuration David Thompson
2022-11-10 13:33   ` Andrew Lunn
2022-11-12  5:34     ` Jakub Kicinski
2022-11-12  9:52       ` Saeed Mahameed
2022-11-12 15:53         ` Andrew Lunn
2022-11-15  0:56           ` Jakub Kicinski
2022-11-15  0:50         ` Jakub Kicinski
2022-11-15  1:06           ` Andrew Lunn
2022-11-15  1:13             ` Jakub Kicinski
2022-11-16 16:30               ` Jakub Kicinski [this message]
2022-11-17  2:01                 ` Saeed Mahameed
2022-11-17  6:23                   ` Jakub Kicinski
2022-11-09 22:47 ` [PATCH net-next v2 4/4] mlxbf_gige: add "set_link_ksettings" ethtool callback David Thompson
2022-11-10 13:26   ` Andrew Lunn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20221116083056.016e3107@kernel.org \
    --to=kuba@kernel.org \
    --cc=andrew@lunn.ch \
    --cc=asmaa@nvidia.com \
    --cc=brgl@bgdev.pl \
    --cc=cai.huoqing@linux.dev \
    --cc=chenhao288@hisilicon.com \
    --cc=davem@davemloft.net \
    --cc=davthompson@nvidia.com \
    --cc=edumazet@google.com \
    --cc=huangguangbin2@huawei.com \
    --cc=limings@nvidia.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=saeed@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.