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(¶ms.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, ¶ms, 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
next 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®