mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: netdev-bot+sashiko@kernel.org
To: daniel@makrotopia.org
Cc: jiri@resnulli.us, davem@davemloft.net, edumazet@google.com,
	kuba@kernel.org, pabeni@redhat.com, horms@kernel.org,
	corbet@lwn.net, skhan@linuxfoundation.org, rdunlap@infradead.org,
	gregkh@linuxfoundation.org, rafael@kernel.org, dakr@kernel.org,
	andrew@lunn.ch, olteanv@gmail.com, netdev@vger.kernel.org,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	driver-core@lists.linux.dev
Subject: Re: [PATCH net-next v15 1/6] net: dsa: add devlink flash_update callback to dsa_switch_ops
Date: Mon, 14 Sep 2026 18:34:51 +0000	[thread overview]
Message-ID: <178941089199.22033.6731579125161335389@kernel.org> (raw)
In-Reply-To: =?utf-8?q?=3Ca35ce7431d32ff6802e1bd1d5f0988756cd91e82=2E1789175?= =?utf-8?q?618=2Egit=2Edaniel=40makrotopia=2Eorg=3E?=

Thank you for your contribution! Sashiko AI review found 1 potential
issue(s) to consider:

Critical: 0 · High: 0 · Medium: 0 · Low: 1

- [Low] net/dsa/devlink.c installs `.flash_update =
  dsa_devlink_flash_update` unconditionally in the single shared…

--

net: dsa: add devlink flash_update callback to dsa_switch_ops

This adds a devlink_flash_update callback to dsa_switch_ops and a
trampoline in net/dsa/devlink.c that forwards devlink dev flash requests
to the driver. The trampoline is installed unconditionally in
dsa_devlink_ops and returns -EOPNOTSUPP when the driver does not
implement the callback.

> diff --git a/net/dsa/devlink.c b/net/dsa/devlink.c
> index ed342f345692b..25311a87cbc56 100644
> --- a/net/dsa/devlink.c
> +++ b/net/dsa/devlink.c
> @@ -20,6 +20,18 @@ static int dsa_devlink_info_get(struct devlink *dl,
>  	return -EOPNOTSUPP;
>  }
>  
> +static int dsa_devlink_flash_update(struct devlink *dl,
> +				    struct devlink_flash_update_params *params,
> +				    struct netlink_ext_ack *extack)
> +{
> +	struct dsa_switch *ds = dsa_devlink_to_ds(dl);
> +
> +	if (!ds->ops->devlink_flash_update)
> +		return -EOPNOTSUPP;
> +
> +	return ds->ops->devlink_flash_update(ds, params, extack);
> +}
> +

[ ... ]

> @@ -169,6 +181,7 @@ dsa_devlink_sb_occ_tc_port_bind_get(struct devlink_port *dlp,
>  
>  static const struct devlink_ops dsa_devlink_ops = {
>  	.info_get			= dsa_devlink_info_get,
> +	.flash_update			= dsa_devlink_flash_update,

[Severity: Low]
Since dsa_devlink_ops is shared by every DSA switch, does this make
devlink->ops->flash_update non-NULL even for the majority of drivers that
do not set ds->ops->devlink_flash_update?

The devlink core uses that pointer as the capability gate for the whole
feature, in devlink_nl_flash_update_doit():

	if (!devlink->ops->flash_update)
		return -EOPNOTSUPP;
	...
	ret = request_firmware_direct(&params.fw, file_name, devlink->dev);
	if (ret) {
		NL_SET_ERR_MSG_ATTR(info->extack, nla_file_name,
				    "failed to locate the requested firmware file");
		return ret;
	}

	devlink_flash_update_begin_notify(devlink);
	ret = devlink->ops->flash_update(devlink, &params, info->extack);
	devlink_flash_update_end_notify(devlink);

With that early return now unreachable for DSA, two behaviour changes seem
to follow for switches that do not implement the callback:

- devlink dev flash with a missing or unreadable file returns -ENOENT with
  the extack "failed to locate the requested firmware file" instead of the
  previous -EOPNOTSUPP, which hides the fact that the device cannot be
  flashed at all.

- a DEVLINK_CMD_FLASH_UPDATE / DEVLINK_CMD_FLASH_UPDATE_END notification
  pair is multicast for a device where no flash takes place.

Does the same apply to the legacy ioctl path?  DSA user ports have no
ethtool_ops->flash_device, so ethtool_flash_device() falls back to the
attached devlink instance:

	if (!dev->ethtool_ops->flash_device) {
		req->devlink = netdev_to_devlink_get(dev);
		return 0;
	}

and devlink_compat_flash_update() carries the same gate that is now dead
for DSA:

	if (!devlink->ops->flash_update) {
		ret = -EOPNOTSUPP;
		goto out_unlock;
	}

so ethtool -f swpN file would read the file and emit the begin/end
notifications before failing.

There is also devlink_flash_component_get(), which infers component-update
support from ops->info_get being non-NULL; DSA's info_get trampoline is
installed unconditionally too, so a component request on a switch without
either callback now gets past that check as well.

The commit message covers part of this:

    the devlink core will then have fetched the firmware file from
    userspace before the request fails, which is acceptable for an
    operation as infrequent as a firmware update.

Could the errno change from -EOPNOTSUPP to -ENOENT and the emitted
FLASH_UPDATE/FLASH_UPDATE_END notifications be mentioned there as well, or
alternatively the ops table selected based on
ds->ops->devlink_flash_update?

>  	.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,

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/cover.1789175618.git.daniel%40makrotopia.org

             reply	other threads:[~2026-09-14 18:34 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-14 18:34 netdev-bot+sashiko [this message]
  -- strict thread matches above, loose matches on Subject: below --
2026-09-13 18:00 [PATCH net-next v15 0/6] net: dsa: mxl862xx: devlink flash and rescue Daniel Golle
2026-09-13 18:01 ` [PATCH net-next v15 1/6] net: dsa: add devlink flash_update callback to dsa_switch_ops Daniel Golle

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=178941089199.22033.6731579125161335389@kernel.org \
    --to=netdev-bot+sashiko@kernel.org \
    --cc=andrew@lunn.ch \
    --cc=corbet@lwn.net \
    --cc=dakr@kernel.org \
    --cc=daniel@makrotopia.org \
    --cc=davem@davemloft.net \
    --cc=driver-core@lists.linux.dev \
    --cc=edumazet@google.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=horms@kernel.org \
    --cc=jiri@resnulli.us \
    --cc=kuba@kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=pabeni@redhat.com \
    --cc=rafael@kernel.org \
    --cc=rdunlap@infradead.org \
    --cc=skhan@linuxfoundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®