Re: [PATCH net-next v5 1/5] net: dsa: wire flash_update devlink callback to drivers

Andrew Lunn <[email protected]>
Newsgroups org.kernel.vger.linux-doc,org.kernel.vger.linux-kernel,org.kernel.vger.netdev
Message-ID <[email protected]>
On Sat, Jul 25, 2026 at 03:15:35AM +0100, Daniel Golle wrote:
> Add a devlink_flash_update callback to dsa_switch_ops so that DSA
> drivers can support devlink dev flash without open-coding the devlink
> plumbing. Unlike the other trampolines in net/dsa/devlink.c, the
> flash_update op is only installed for switches whose driver implements
> the callback: the devlink core rejects flash requests up front when the
> op is absent, before fetching the firmware file from userspace, and an
> unconditionally present trampoline would defeat that early check and
> let unsupported requests block on request_firmware() only to fail with
> -EOPNOTSUPP afterwards.

> +/* The devlink core rejects flash requests up front when the flash_update
> + * op is absent, before fetching the firmware file from userspace. Only
> + * install the op for switches whose driver implements it, so that
> + * unsupported requests keep failing early.
> + */
> +#define DSA_DEVLINK_OPS							\
> +	.info_get			= dsa_devlink_info_get,		\
> +	.sb_pool_get			= dsa_devlink_sb_pool_get,	\
> +	.sb_pool_set			= dsa_devlink_sb_pool_set,	\
> +	.sb_port_pool_get		= dsa_devlink_sb_port_pool_get,	\
> +	.sb_port_pool_set		= dsa_devlink_sb_port_pool_set,	\
> +	.sb_tc_pool_bind_get		= dsa_devlink_sb_tc_pool_bind_get, \
> +	.sb_tc_pool_bind_set		= dsa_devlink_sb_tc_pool_bind_set, \
> +	.sb_occ_snapshot		= dsa_devlink_sb_occ_snapshot,	\
> +	.sb_occ_max_clear		= dsa_devlink_sb_occ_max_clear,	\
> +	.sb_occ_port_pool_get		= dsa_devlink_sb_occ_port_pool_get, \
>  	.sb_occ_tc_port_bind_get	= dsa_devlink_sb_occ_tc_port_bind_get,
> +
> +static const struct devlink_ops dsa_devlink_ops = {
> +	DSA_DEVLINK_OPS
> +};

Is this going to scale? How many different permutations are there?

Firmware upgrade is an infrequent operation, so do we actually care
about a request_firmware() which might turn out to be pointless? I
personally would prefer to avoid the scalability issue and just return
-EOPNOTSUPP.

	Andrew
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.