[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20190211065923.22670-1-jakub.kicinski@netronome.com>
Date: Sun, 10 Feb 2019 22:59:19 -0800
From: Jakub Kicinski <jakub.kicinski@...ronome.com>
To: davem@...emloft.net, jiri@...nulli.us
Cc: netdev@...r.kernel.org, oss-drivers@...ronome.com,
mkubecek@...e.cz, andrew@...n.ch,
Jakub Kicinski <jakub.kicinski@...ronome.com>
Subject: [RFC 0/3] devlink: add the ability to update device flash
Hi!
This series is the second step to allow trouble shooting and recovering
devices in bad state without the use of netdevs as handles. We can
already query FW versions over devlink, now we add the ability to update
the FW. This will allow drivers to implement some from of "limp-mode"
where the device can't really be used for networking and hence has no
netdev, but we can interrogate it over devlink and fix the broken FW.
Small but nice advantage of devlink is that it only holds the devlink
instance lock during flashing, unlike ethtool which holds rtnl_lock().
Sending as RFC due to impending conflicts.
Jakub Kicinski (3):
devlink: add flash update command
ethtool: add compat for flash update
nfp: devlink: allow flashing the device via devlink
.../net/ethernet/netronome/nfp/nfp_devlink.c | 47 +++++++++++++-
include/net/devlink.h | 11 ++++
include/uapi/linux/devlink.h | 6 ++
net/core/devlink.c | 61 +++++++++++++++++++
net/core/ethtool.c | 12 +++-
5 files changed, 133 insertions(+), 4 deletions(-)
--
2.19.2
Powered by blists - more mailing lists