* Re: [PATCH net-next v2 00/10] net: phy: Add support for 2.5GBASET PHYs
From: Maxime Chevallier @ 2019-02-11 7:46 UTC (permalink / raw)
To: Heiner Kallweit
Cc: davem, Andrew Lunn, netdev, linux-kernel, Florian Fainelli,
Russell King, linux-arm-kernel, Antoine Tenart, thomas.petazzoni,
gregory.clement, miquel.raynal, nadavh, stefanc, mw
In-Reply-To: <81c340ea-54b0-1abf-94af-b8dc4ee83e3a@gmail.com>
Hello Heiner,
>Hi Maxime,
>
>Andrew and me are working on Aquantia PHY support and he handed over
>to me a patch series which includes parts of the first version of your
>series. Having said that I'm especially interested in your patches
>5 and 6. Because your series is somewhat bigger and there are a few
>review comments, preparing the next round may take time.
>
>I'd propose that you extract generic patches being submission-ready
>and split the patch series into two. I think the following patches
>would be candidates for the first series: 2, 3, 5, 6
>(provided they have no dependency on the other patches)
>Based on that both of us can go on with our work.
Sure, I'll sent that shortly. Thanks for the help,
Maxime
^ permalink raw reply
* Re: [PATCH net-next 0/2] Revert wake_on_lan devlink parameter
From: David Miller @ 2019-02-11 7:35 UTC (permalink / raw)
To: vasundhara-v.volam; +Cc: michael.chan, jiri, netdev
In-Reply-To: <CAACQVJpyD2EW0d=sUAz6h1rk9A0iNQZUhH5aC9iAJrCZpsX60A@mail.gmail.com>
From: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
Date: Mon, 11 Feb 2019 10:09:23 +0530
> On Sat, Feb 9, 2019 at 12:37 PM David Miller <davem@davemloft.net> wrote:
>>
>> From: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
>> Date: Fri, 8 Feb 2019 14:43:08 +0530
>>
>> > As per discussion with Jakub Kicinski and Michal Kubecek,
>> > this will be better addressed by soon-too-come ethtool netlink
>> > API with additional indication that given WoL configuration request
>> > is supposed to be persisted.
>> >
>> > Retain bnxt_en code for devlink port param table registration.
>> > There will be follow up patches to add some devlink port params
>> > for bnxt_en driver.
>>
>> Please fix the kbuild robot reported build failure and repost.
> David, second patch in this patchset has already taken care of all
> this failures.
> Could you please apply both patches together?
You cannot break bisection like this.
If they cannot be separated, resubmit the change as one patch.
^ permalink raw reply
* Re: [Patch net 2/3] net_sched: fix a memory leak in cls_tcindex
From: Cong Wang @ 2019-02-11 7:19 UTC (permalink / raw)
To: kbuild test robot
Cc: kbuild-all, Linux Kernel Network Developers, Jamal Hadi Salim,
Jiri Pirko
In-Reply-To: <201902111051.xRYMeLJl%fengguang.wu@intel.com>
On Sun, Feb 10, 2019 at 6:15 PM kbuild test robot <lkp@intel.com> wrote:
>
> Hi Cong,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on net/master]
>
> url: https://github.com/0day-ci/linux/commits/Cong-Wang/net_sched-some-fixes-for-cls_tcindex/20190211-095057
> config: i386-randconfig-x002-201906 (attached as .config)
> compiler: gcc-8 (Debian 8.2.0-14) 8.2.0
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=i386
>
> All errors (new ones prefixed by >>):
>
> net/sched/cls_tcindex.c: In function 'tcindex_alloc_perfect_hash':
> >> net/sched/cls_tcindex.c:301:22: error: 'struct tcf_exts' has no member named 'net'
> cp->perfect[i].exts.net = net;
Yeah, looks like I missed the CONFIG_CLS_ACT=n case.
Let me think about how to fix it properly.
Thanks!
^ permalink raw reply
* [RFC iproute2] devlink: add support for updating device flash
From: Jakub Kicinski @ 2019-02-11 6:59 UTC (permalink / raw)
To: davem, jiri; +Cc: netdev, oss-drivers, mkubecek, andrew, Jakub Kicinski
In-Reply-To: <20190211065923.22670-1-jakub.kicinski@netronome.com>
Add new command for updating flash of devices via devlink API.
Example:
$ cp flash-boot.bin /lib/firmware/
$ devlink dev flash pci/0000:05:00.0 file flash-boot.bin
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
---
devlink/devlink.c | 54 ++++++++++++++++++++++++++++++++++++++++++
man/man8/devlink-dev.8 | 29 +++++++++++++++++++++++
2 files changed, 83 insertions(+)
diff --git a/devlink/devlink.c b/devlink/devlink.c
index d823512a4030..dd5f153eddc6 100644
--- a/devlink/devlink.c
+++ b/devlink/devlink.c
@@ -199,6 +199,8 @@ static void ifname_map_free(struct ifname_map *ifname_map)
#define DL_OPT_REGION_SNAPSHOT_ID BIT(22)
#define DL_OPT_REGION_ADDRESS BIT(23)
#define DL_OPT_REGION_LENGTH BIT(24)
+#define DL_OPT_FLASH_FILE_NAME BIT(25)
+#define DL_OPT_FLASH_TARGET_ID BIT(26)
struct dl_opts {
uint32_t present; /* flags of present items */
@@ -230,6 +232,8 @@ struct dl_opts {
uint32_t region_snapshot_id;
uint64_t region_address;
uint64_t region_length;
+ const char *flash_file_name;
+ uint32_t flash_target_id;
};
struct dl {
@@ -1185,6 +1189,20 @@ static int dl_argv_parse(struct dl *dl, uint32_t o_required,
if (err)
return err;
o_found |= DL_OPT_REGION_LENGTH;
+ } else if (dl_argv_match(dl, "file") &&
+ (o_all & DL_OPT_FLASH_FILE_NAME)) {
+ dl_arg_inc(dl);
+ err = dl_argv_str(dl, &opts->flash_file_name);
+ if (err)
+ return err;
+ o_found |= DL_OPT_FLASH_FILE_NAME;
+ } else if (dl_argv_match(dl, "target") &&
+ (o_all & DL_OPT_FLASH_TARGET_ID)) {
+ dl_arg_inc(dl);
+ err = dl_argv_uint32_t(dl, &opts->flash_target_id);
+ if (err)
+ return err;
+ o_found |= DL_OPT_FLASH_TARGET_ID;
} else {
pr_err("Unknown option \"%s\"\n", dl_argv(dl));
return -EINVAL;
@@ -1389,6 +1407,12 @@ static void dl_opts_put(struct nlmsghdr *nlh, struct dl *dl)
if (opts->present & DL_OPT_REGION_LENGTH)
mnl_attr_put_u64(nlh, DEVLINK_ATTR_REGION_CHUNK_LEN,
opts->region_length);
+ if (opts->present & DL_OPT_FLASH_FILE_NAME)
+ mnl_attr_put_strz(nlh, DEVLINK_ATTR_FLASH_UPDATE_FILE_NAME,
+ opts->flash_file_name);
+ if (opts->present & DL_OPT_FLASH_TARGET_ID)
+ mnl_attr_put_u32(nlh, DEVLINK_ATTR_FLASH_UPDATE_TARGET_ID,
+ opts->flash_target_id);
}
static int dl_argv_parse_put(struct nlmsghdr *nlh, struct dl *dl,
@@ -1451,6 +1475,7 @@ static void cmd_dev_help(void)
pr_err(" devlink dev param show [DEV name PARAMETER]\n");
pr_err(" devlink dev reload DEV\n");
pr_err(" devlink dev info [ DEV ]\n");
+ pr_err(" devlink dev flash DEV file PATH [ target ID ]\n");
}
static bool cmp_arr_last_handle(struct dl *dl, const char *bus_name,
@@ -2583,6 +2608,32 @@ static int cmd_dev_info(struct dl *dl)
return err;
}
+static void cmd_dev_flash_help(void)
+{
+ pr_err("Usage: devlink dev flash DEV file PATH [ target ID ]\n");
+}
+
+static int cmd_dev_flash(struct dl *dl)
+{
+ struct nlmsghdr *nlh;
+ int err;
+
+ if (dl_argv_match(dl, "help") || dl_no_arg(dl)) {
+ cmd_dev_flash_help();
+ return 0;
+ }
+
+ nlh = mnlg_msg_prepare(dl->nlg, DEVLINK_CMD_FLASH_UPDATE,
+ NLM_F_REQUEST | NLM_F_ACK);
+
+ err = dl_argv_parse_put(nlh, dl, DL_OPT_HANDLE | DL_OPT_FLASH_FILE_NAME,
+ DL_OPT_FLASH_TARGET_ID);
+ if (err)
+ return err;
+
+ return _mnlg_socket_sndrcv(dl->nlg, nlh, NULL, NULL);
+}
+
static int cmd_dev(struct dl *dl)
{
if (dl_argv_match(dl, "help")) {
@@ -2604,6 +2655,9 @@ static int cmd_dev(struct dl *dl)
} else if (dl_argv_match(dl, "info")) {
dl_arg_inc(dl);
return cmd_dev_info(dl);
+ } else if (dl_argv_match(dl, "flash")) {
+ dl_arg_inc(dl);
+ return cmd_dev_flash(dl);
}
pr_err("Command \"%s\" not found\n", dl_argv(dl));
return -ENOENT;
diff --git a/man/man8/devlink-dev.8 b/man/man8/devlink-dev.8
index 47838371fecd..dda35fb09ee0 100644
--- a/man/man8/devlink-dev.8
+++ b/man/man8/devlink-dev.8
@@ -69,6 +69,16 @@ devlink-dev \- devlink device configuration
.IR DEV
.RI "]"
+.ti -8
+.BR "devlink dev flash"
+.IR DEV
+.BR file
+.IR PATH
+.RI "["
+.BR target
+.IR ID
+.RI "]"
+
.SH "DESCRIPTION"
.SS devlink dev show - display devlink device attributes
@@ -177,6 +187,25 @@ versions may differ after flash has been updated, but before reboot.
- specifies the devlink device to show.
If this argument is omitted all devices are listed.
+.SS devlink dev flash - write device's non-volatile memory.
+
+.PP
+.I "DEV"
+- specifies the devlink device to write to.
+
+.BR file
+.I PATH
+- Path to the file which will be written into device's flash. The path needs
+to be relative to one of the directories searched by the kernel firmware loaded,
+such as /lib/firmware.
+
+.BR target
+.I ID
+- If device stores multiple firmware images in non-volatile memory, this
+parameter may be used to indicate which firmware image should be written.
+The default value of 0 means that all regions should be updated.
+Interpretation of other values is driver-dependent.
+
.SH "EXAMPLES"
.PP
devlink dev show
--
2.19.2
^ permalink raw reply related
* [RFC 3/3] nfp: devlink: allow flashing the device via devlink
From: Jakub Kicinski @ 2019-02-11 6:59 UTC (permalink / raw)
To: davem, jiri; +Cc: netdev, oss-drivers, mkubecek, andrew, Jakub Kicinski
In-Reply-To: <20190211065923.22670-1-jakub.kicinski@netronome.com>
Devlink now allows updating device flash. Implement this
callback.
Compared to ethtool update we no longer have to release
the networking locks - devlink doesn't take them.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
---
.../net/ethernet/netronome/nfp/nfp_devlink.c | 9 ++++
drivers/net/ethernet/netronome/nfp/nfp_main.c | 44 +++++++++++++++++++
drivers/net/ethernet/netronome/nfp/nfp_main.h | 2 +
.../ethernet/netronome/nfp/nfp_net_ethtool.c | 39 ++--------------
4 files changed, 59 insertions(+), 35 deletions(-)
diff --git a/drivers/net/ethernet/netronome/nfp/nfp_devlink.c b/drivers/net/ethernet/netronome/nfp/nfp_devlink.c
index 080a301f379e..ee45a6f9030a 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_devlink.c
+++ b/drivers/net/ethernet/netronome/nfp/nfp_devlink.c
@@ -330,6 +330,14 @@ nfp_devlink_info_get(struct devlink *devlink, struct devlink_info_req *req,
return err;
}
+static int
+nfp_devlink_flash_update(struct devlink *devlink, const char *path,
+ u32 target, struct netlink_ext_ack *extack)
+{
+ return nfp_flash_update_common(devlink_priv(devlink), path, target,
+ extack);
+}
+
const struct devlink_ops nfp_devlink_ops = {
.port_split = nfp_devlink_port_split,
.port_unsplit = nfp_devlink_port_unsplit,
@@ -338,6 +346,7 @@ const struct devlink_ops nfp_devlink_ops = {
.eswitch_mode_get = nfp_devlink_eswitch_mode_get,
.eswitch_mode_set = nfp_devlink_eswitch_mode_set,
.info_get = nfp_devlink_info_get,
+ .flash_update = nfp_devlink_flash_update,
};
int nfp_devlink_port_register(struct nfp_app *app, struct nfp_port *port)
diff --git a/drivers/net/ethernet/netronome/nfp/nfp_main.c b/drivers/net/ethernet/netronome/nfp/nfp_main.c
index 6c10e8d119e4..3f55575c2929 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_main.c
+++ b/drivers/net/ethernet/netronome/nfp/nfp_main.c
@@ -300,6 +300,50 @@ static int nfp_pcie_sriov_configure(struct pci_dev *pdev, int num_vfs)
return nfp_pcie_sriov_enable(pdev, num_vfs);
}
+int nfp_flash_update_common(struct nfp_pf *pf, const char *path,
+ u32 target, struct netlink_ext_ack *extack)
+{
+ struct device *dev = &pf->pdev->dev;
+ const struct firmware *fw;
+ struct nfp_nsp *nsp;
+ int err;
+
+ if (target != ETHTOOL_FLASH_ALL_REGIONS)
+ return -EOPNOTSUPP;
+
+ nsp = nfp_nsp_open(pf->cpp);
+ if (IS_ERR(nsp)) {
+ err = PTR_ERR(nsp);
+ if (extack)
+ NL_SET_ERR_MSG_MOD(extack, "can't access NSP");
+ else
+ dev_err(dev, "Failed to access the NSP: %d\n", err);
+ return err;
+ }
+
+ err = request_firmware_direct(&fw, path, dev);
+ if (err) {
+ NL_SET_ERR_MSG_MOD(extack,
+ "unable to read flash file from disk");
+ goto exit_close_nsp;
+ }
+
+ dev_info(dev, "Please be patient while writing flash image: %s\n",
+ path);
+
+ err = nfp_nsp_write_flash(nsp, fw);
+ if (err < 0)
+ goto exit_release_fw;
+ dev_info(dev, "Finished writing flash image\n");
+ err = 0;
+
+exit_release_fw:
+ release_firmware(fw);
+exit_close_nsp:
+ nfp_nsp_close(nsp);
+ return err;
+}
+
static const struct firmware *
nfp_net_fw_request(struct pci_dev *pdev, struct nfp_pf *pf, const char *name)
{
diff --git a/drivers/net/ethernet/netronome/nfp/nfp_main.h b/drivers/net/ethernet/netronome/nfp/nfp_main.h
index a3613a2e0aa5..6e4b509017c1 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_main.h
+++ b/drivers/net/ethernet/netronome/nfp/nfp_main.h
@@ -164,6 +164,8 @@ nfp_pf_map_rtsym(struct nfp_pf *pf, const char *name, const char *sym_fmt,
unsigned int min_size, struct nfp_cpp_area **area);
int nfp_mbox_cmd(struct nfp_pf *pf, u32 cmd, void *in_data, u64 in_length,
void *out_data, u64 out_length);
+int nfp_flash_update_common(struct nfp_pf *pf, const char *path,
+ u32 target, struct netlink_ext_ack *extack);
enum nfp_dump_diag {
NFP_DUMP_NSP_DIAG = 0,
diff --git a/drivers/net/ethernet/netronome/nfp/nfp_net_ethtool.c b/drivers/net/ethernet/netronome/nfp/nfp_net_ethtool.c
index cb9c512abc76..244b60f406c2 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_net_ethtool.c
+++ b/drivers/net/ethernet/netronome/nfp/nfp_net_ethtool.c
@@ -1237,52 +1237,21 @@ static int nfp_net_set_channels(struct net_device *netdev,
static int
nfp_net_flash_device(struct net_device *netdev, struct ethtool_flash *flash)
{
- const struct firmware *fw;
struct nfp_app *app;
- struct nfp_nsp *nsp;
- struct device *dev;
- int err;
-
- if (flash->region != ETHTOOL_FLASH_ALL_REGIONS)
- return -EOPNOTSUPP;
+ int ret;
app = nfp_app_from_netdev(netdev);
if (!app)
return -EOPNOTSUPP;
- dev = &app->pdev->dev;
-
- nsp = nfp_nsp_open(app->cpp);
- if (IS_ERR(nsp)) {
- err = PTR_ERR(nsp);
- dev_err(dev, "Failed to access the NSP: %d\n", err);
- return err;
- }
-
- err = request_firmware_direct(&fw, flash->data, dev);
- if (err)
- goto exit_close_nsp;
-
- dev_info(dev, "Please be patient while writing flash image: %s\n",
- flash->data);
dev_hold(netdev);
rtnl_unlock();
-
- err = nfp_nsp_write_flash(nsp, fw);
- if (err < 0) {
- dev_err(dev, "Flash write failed: %d\n", err);
- goto exit_rtnl_lock;
- }
- dev_info(dev, "Finished writing flash image\n");
-
-exit_rtnl_lock:
+ ret = nfp_flash_update_common(app->pf, flash->data, flash->region,
+ NULL);
rtnl_lock();
dev_put(netdev);
- release_firmware(fw);
-exit_close_nsp:
- nfp_nsp_close(nsp);
- return err;
+ return ret;
}
static const struct ethtool_ops nfp_net_ethtool_ops = {
--
2.19.2
^ permalink raw reply related
* [RFC 2/3] ethtool: add compat for flash update
From: Jakub Kicinski @ 2019-02-11 6:59 UTC (permalink / raw)
To: davem, jiri; +Cc: netdev, oss-drivers, mkubecek, andrew, Jakub Kicinski
In-Reply-To: <20190211065923.22670-1-jakub.kicinski@netronome.com>
If driver does not support ethtool flash update operation
call into devlink.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
---
include/net/devlink.h | 9 +++++++++
net/core/devlink.c | 31 +++++++++++++++++++++++++++++++
net/core/ethtool.c | 12 +++++++++---
3 files changed, 49 insertions(+), 3 deletions(-)
diff --git a/include/net/devlink.h b/include/net/devlink.h
index 55b3478b1291..8fdadd0a43ce 100644
--- a/include/net/devlink.h
+++ b/include/net/devlink.h
@@ -1202,11 +1202,20 @@ devlink_health_report(struct devlink_health_reporter *reporter,
#if IS_REACHABLE(CONFIG_NET_DEVLINK)
void devlink_compat_running_version(struct net_device *dev,
char *buf, size_t len);
+int devlink_compat_flash_update(struct net_device *dev, const char *file_name,
+ u32 target);
#else
static inline void
devlink_compat_running_version(struct net_device *dev, char *buf, size_t len)
{
}
+
+static inline int
+devlink_compat_flash_update(struct net_device *dev, const char *file_name,
+ u32 target)
+{
+ return -EOPNOTSUPP;
+}
#endif
#endif /* _NET_DEVLINK_H_ */
diff --git a/net/core/devlink.c b/net/core/devlink.c
index a4b5e194e33e..fb1b0982281b 100644
--- a/net/core/devlink.c
+++ b/net/core/devlink.c
@@ -6435,6 +6435,37 @@ void devlink_compat_running_version(struct net_device *dev,
mutex_unlock(&devlink_mutex);
}
+int devlink_compat_flash_update(struct net_device *dev, const char *file_name,
+ u32 target)
+{
+ struct devlink_port *devlink_port;
+ struct devlink *devlink;
+
+ mutex_lock(&devlink_mutex);
+ list_for_each_entry(devlink, &devlink_list, list) {
+ mutex_lock(&devlink->lock);
+ list_for_each_entry(devlink_port, &devlink->port_list, list) {
+ int ret = -EOPNOTSUPP;
+
+ if (devlink_port->type != DEVLINK_PORT_TYPE_ETH ||
+ devlink_port->type_dev != dev)
+ continue;
+
+ mutex_unlock(&devlink_mutex);
+ if (devlink->ops->flash_update)
+ ret = devlink->ops->flash_update(devlink,
+ file_name,
+ target, NULL);
+ mutex_unlock(&devlink->lock);
+ return ret;
+ }
+ mutex_unlock(&devlink->lock);
+ }
+ mutex_unlock(&devlink_mutex);
+
+ return -EOPNOTSUPP;
+}
+
static int __init devlink_module_init(void)
{
return genl_register_family(&devlink_nl_family);
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index d2c47cdf25da..389782ccd4c5 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -2038,11 +2038,17 @@ static noinline_for_stack int ethtool_flash_device(struct net_device *dev,
if (copy_from_user(&efl, useraddr, sizeof(efl)))
return -EFAULT;
+ efl.data[ETHTOOL_FLASH_MAX_FILENAME - 1] = 0;
- if (!dev->ethtool_ops->flash_device)
- return -EOPNOTSUPP;
+ if (!dev->ethtool_ops->flash_device) {
+ int ret;
- efl.data[ETHTOOL_FLASH_MAX_FILENAME - 1] = 0;
+ rtnl_unlock();
+ ret = devlink_compat_flash_update(dev, efl.data, efl.region);
+ rtnl_lock();
+
+ return ret;
+ }
return dev->ethtool_ops->flash_device(dev, &efl);
}
--
2.19.2
^ permalink raw reply related
* [RFC 1/3] devlink: add flash update command
From: Jakub Kicinski @ 2019-02-11 6:59 UTC (permalink / raw)
To: davem, jiri; +Cc: netdev, oss-drivers, mkubecek, andrew, Jakub Kicinski
In-Reply-To: <20190211065923.22670-1-jakub.kicinski@netronome.com>
Add devlink flash update command. Advanced NICs have firmware
stored in flash and often cryptographically secured. Updating
that flash is handled by management firmware. Ethtool has a
flash update command which served us well, however, it has two
shortcomings:
- it takes rtnl_lock unnecessarily - really flash update has
nothing to do with networking, so using a networking device
as a handle is suboptimal, which leads us to the second one:
- it requires a functioning netdev - in case device enters an
error state and can't spawn a netdev (e.g. communication
with the device fails) there is no netdev to use as a handle
for flashing.
Devlink already has the ability to report the firmware versions,
now with the ability to update the firmware/flash we will be
able to recover devices in bad state.
To enable easy interoperability with ethtool add the target
partition ID. We may or may not add a different method of
identification, but there is no such immediate need.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
---
include/net/devlink.h | 2 ++
include/uapi/linux/devlink.h | 6 ++++++
net/core/devlink.c | 30 ++++++++++++++++++++++++++++++
3 files changed, 38 insertions(+)
diff --git a/include/net/devlink.h b/include/net/devlink.h
index 07660fe4c0e3..55b3478b1291 100644
--- a/include/net/devlink.h
+++ b/include/net/devlink.h
@@ -529,6 +529,8 @@ struct devlink_ops {
struct netlink_ext_ack *extack);
int (*info_get)(struct devlink *devlink, struct devlink_info_req *req,
struct netlink_ext_ack *extack);
+ int (*flash_update)(struct devlink *devlink, const char *path,
+ u32 target, struct netlink_ext_ack *extack);
};
static inline void *devlink_priv(struct devlink *devlink)
diff --git a/include/uapi/linux/devlink.h b/include/uapi/linux/devlink.h
index 72d9f7c89190..f4417283fd1b 100644
--- a/include/uapi/linux/devlink.h
+++ b/include/uapi/linux/devlink.h
@@ -103,6 +103,8 @@ enum devlink_command {
DEVLINK_CMD_HEALTH_REPORTER_DUMP_GET,
DEVLINK_CMD_HEALTH_REPORTER_DUMP_CLEAR,
+ DEVLINK_CMD_FLASH_UPDATE,
+
/* add new commands above here */
__DEVLINK_CMD_MAX,
DEVLINK_CMD_MAX = __DEVLINK_CMD_MAX - 1
@@ -326,6 +328,10 @@ enum devlink_attr {
DEVLINK_ATTR_HEALTH_REPORTER_DUMP_TS, /* u64 */
DEVLINK_ATTR_HEALTH_REPORTER_GRACEFUL_PERIOD, /* u64 */
DEVLINK_ATTR_HEALTH_REPORTER_AUTO_RECOVER, /* u8 */
+
+ DEVLINK_ATTR_FLASH_UPDATE_FILE_NAME, /* string */
+ DEVLINK_ATTR_FLASH_UPDATE_TARGET_ID, /* u32 */
+
/* add new attributes above here, update the policy in devlink.c */
__DEVLINK_ATTR_MAX,
diff --git a/net/core/devlink.c b/net/core/devlink.c
index 46c468a1f3dc..a4b5e194e33e 100644
--- a/net/core/devlink.c
+++ b/net/core/devlink.c
@@ -2660,6 +2660,27 @@ static int devlink_nl_cmd_reload(struct sk_buff *skb, struct genl_info *info)
return devlink->ops->reload(devlink, info->extack);
}
+static int devlink_nl_cmd_flash_update(struct sk_buff *skb,
+ struct genl_info *info)
+{
+ struct devlink *devlink = info->user_ptr[0];
+ const char *file_name;
+ u32 target = 0;
+
+ if (!devlink->ops->flash_update)
+ return -EOPNOTSUPP;
+
+ if (!info->attrs[DEVLINK_ATTR_FLASH_UPDATE_FILE_NAME])
+ return -EINVAL;
+ file_name = nla_data(info->attrs[DEVLINK_ATTR_FLASH_UPDATE_FILE_NAME]);
+
+ if (info->attrs[DEVLINK_ATTR_FLASH_UPDATE_TARGET_ID])
+ target = nla_get_u32(info->attrs[DEVLINK_ATTR_FLASH_UPDATE_TARGET_ID]);
+
+ return devlink->ops->flash_update(devlink, file_name, target,
+ info->extack);
+}
+
static const struct devlink_param devlink_param_generic[] = {
{
.id = DEVLINK_PARAM_GENERIC_ID_INT_ERR_RESET,
@@ -4876,6 +4897,8 @@ static const struct nla_policy devlink_nl_policy[DEVLINK_ATTR_MAX + 1] = {
[DEVLINK_ATTR_HEALTH_REPORTER_NAME] = { .type = NLA_NUL_STRING },
[DEVLINK_ATTR_HEALTH_REPORTER_GRACEFUL_PERIOD] = { .type = NLA_U64 },
[DEVLINK_ATTR_HEALTH_REPORTER_AUTO_RECOVER] = { .type = NLA_U8 },
+ [DEVLINK_ATTR_FLASH_UPDATE_FILE_NAME] = { .type = NLA_NUL_STRING },
+ [DEVLINK_ATTR_FLASH_UPDATE_TARGET_ID] = { .type = NLA_U32 },
};
static const struct genl_ops devlink_nl_ops[] = {
@@ -5164,6 +5187,13 @@ static const struct genl_ops devlink_nl_ops[] = {
.internal_flags = DEVLINK_NL_FLAG_NEED_DEVLINK |
DEVLINK_NL_FLAG_NO_LOCK,
},
+ {
+ .cmd = DEVLINK_CMD_FLASH_UPDATE,
+ .doit = devlink_nl_cmd_flash_update,
+ .policy = devlink_nl_policy,
+ .flags = GENL_ADMIN_PERM,
+ .internal_flags = DEVLINK_NL_FLAG_NEED_DEVLINK,
+ },
};
static struct genl_family devlink_nl_family __ro_after_init = {
--
2.19.2
^ permalink raw reply related
* [RFC 0/3] devlink: add the ability to update device flash
From: Jakub Kicinski @ 2019-02-11 6:59 UTC (permalink / raw)
To: davem, jiri; +Cc: netdev, oss-drivers, mkubecek, andrew, Jakub Kicinski
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
^ permalink raw reply
* [net] tipc: fix link session and re-establish issues
From: Tuong Lien @ 2019-02-11 6:29 UTC (permalink / raw)
To: davem, jon.maloy, ying.xue, netdev; +Cc: tipc-discussion
When a link endpoint is re-created (e.g. after a node reboot or
interface reset), the link session number is varied by random, the peer
endpoint will be synced with this new session number before the link is
re-established.
However, there is a shortcoming in this mechanism that can lead to the
link never re-established or faced with a failure then. It happens when
the peer endpoint is ready in ESTABLISHING state, the 'peer_session' as
well as the 'in_session' flag have been set, but suddenly this link
endpoint leaves. When it comes back with a random session number, there
are two situations possible:
1/ If the random session number is larger than (or equal to) the
previous one, the peer endpoint will be updated with this new session
upon receipt of a RESET_MSG from this endpoint, and the link can be re-
established as normal. Otherwise, all the RESET_MSGs from this endpoint
will be rejected by the peer. In turn, when this link endpoint receives
one ACTIVATE_MSG from the peer, it will move to ESTABLISHED and start
to send STATE_MSGs, but again these messages will be dropped by the
peer due to wrong session.
The peer link endpoint can still become ESTABLISHED after receiving a
traffic message from this endpoint (e.g. a BCAST_PROTOCOL or
NAME_DISTRIBUTOR), but since all the STATE_MSGs are invalid, the link
will be forced down sooner or later!
Even in case the random session number is larger than the previous one,
it can be that the ACTIVATE_MSG from the peer arrives first, and this
link endpoint moves quickly to ESTABLISHED without sending out any
RESET_MSG yet. Consequently, the peer link will not be updated with the
new session number, and the same link failure scenario as above will
happen.
2/ Another situation can be that, the peer link endpoint was reset due
to any reasons in the meantime, its link state was set to RESET from
ESTABLISHING but still in session, i.e. the 'in_session' flag is not
reset...
Now, if the random session number from this endpoint is less than the
previous one, all the RESET_MSGs from this endpoint will be rejected by
the peer. In the other direction, when this link endpoint receives a
RESET_MSG from the peer, it moves to ESTABLISHING and starts to send
ACTIVATE_MSGs, but all these messages will be rejected by the peer too.
As a result, the link cannot be re-established but gets stuck with this
link endpoint in state ESTABLISHING and the peer in RESET!
Solution:
===========
This link endpoint should not go directly to ESTABLISHED when getting
ACTIVATE_MSG from the peer which may belong to the old session if the
link was re-created. To ensure the session to be correct before the
link is re-established, the peer endpoint in ESTABLISHING state will
send back the last session number in ACTIVATE_MSG for a verification at
this endpoint. Then, if needed, a new and more appropriate session
number will be regenerated to force a re-synch first.
In addition, when a link in ESTABLISHING state is reset, its state will
move to RESET according to the link FSM, along with resetting the
'in_session' flag (and the other data) as a normal link reset, it will
also be deleted if requested.
The solution is backward compatible.
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Acked-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Tuong Lien <tuong.t.lien@dektech.com.au>
---
net/tipc/link.c | 15 +++++++++++++++
net/tipc/msg.h | 22 ++++++++++++++++++++++
net/tipc/node.c | 11 ++++++-----
3 files changed, 43 insertions(+), 5 deletions(-)
diff --git a/net/tipc/link.c b/net/tipc/link.c
index ac306d17f8ad..631e21cd4256 100644
--- a/net/tipc/link.c
+++ b/net/tipc/link.c
@@ -1425,6 +1425,10 @@ static void tipc_link_build_proto_msg(struct tipc_link *l, int mtyp, bool probe,
l->rcv_unacked = 0;
} else {
/* RESET_MSG or ACTIVATE_MSG */
+ if (mtyp == ACTIVATE_MSG) {
+ msg_set_dest_session_valid(hdr, 1);
+ msg_set_dest_session(hdr, l->peer_session);
+ }
msg_set_max_pkt(hdr, l->advertised_mtu);
strcpy(data, l->if_name);
msg_set_size(hdr, INT_H_SIZE + TIPC_MAX_IF_NAME);
@@ -1642,6 +1646,17 @@ static int tipc_link_proto_rcv(struct tipc_link *l, struct sk_buff *skb,
rc = tipc_link_fsm_evt(l, LINK_FAILURE_EVT);
break;
}
+
+ /* If this endpoint was re-created while peer was ESTABLISHING
+ * it doesn't know current session number. Force re-synch.
+ */
+ if (mtyp == ACTIVATE_MSG && msg_dest_session_valid(hdr) &&
+ l->session != msg_dest_session(hdr)) {
+ if (less(l->session, msg_dest_session(hdr)))
+ l->session = msg_dest_session(hdr) + 1;
+ break;
+ }
+
/* ACTIVATE_MSG serves as PEER_RESET if link is already down */
if (mtyp == RESET_MSG || !link_is_up(l))
rc = tipc_link_fsm_evt(l, LINK_PEER_RESET_EVT);
diff --git a/net/tipc/msg.h b/net/tipc/msg.h
index a0924956bb61..d7e4b8b93f9d 100644
--- a/net/tipc/msg.h
+++ b/net/tipc/msg.h
@@ -360,6 +360,28 @@ static inline void msg_set_bcast_ack(struct tipc_msg *m, u16 n)
msg_set_bits(m, 1, 0, 0xffff, n);
}
+/* Note: reusing bits in word 1 for ACTIVATE_MSG only, to re-synch
+ * link peer session number
+ */
+static inline bool msg_dest_session_valid(struct tipc_msg *m)
+{
+ return msg_bits(m, 1, 16, 0x1);
+}
+
+static inline void msg_set_dest_session_valid(struct tipc_msg *m, bool valid)
+{
+ msg_set_bits(m, 1, 16, 0x1, valid);
+}
+
+static inline u16 msg_dest_session(struct tipc_msg *m)
+{
+ return msg_bits(m, 1, 0, 0xffff);
+}
+
+static inline void msg_set_dest_session(struct tipc_msg *m, u16 n)
+{
+ msg_set_bits(m, 1, 0, 0xffff, n);
+}
/*
* Word 2
diff --git a/net/tipc/node.c b/net/tipc/node.c
index db2a6c3e0be9..2dc4919ab23c 100644
--- a/net/tipc/node.c
+++ b/net/tipc/node.c
@@ -830,15 +830,16 @@ static void tipc_node_link_down(struct tipc_node *n, int bearer_id, bool delete)
tipc_node_write_lock(n);
if (!tipc_link_is_establishing(l)) {
__tipc_node_link_down(n, &bearer_id, &xmitq, &maddr);
- if (delete) {
- kfree(l);
- le->link = NULL;
- n->link_cnt--;
- }
} else {
/* Defuse pending tipc_node_link_up() */
+ tipc_link_reset(l);
tipc_link_fsm_evt(l, LINK_RESET_EVT);
}
+ if (delete) {
+ kfree(l);
+ le->link = NULL;
+ n->link_cnt--;
+ }
trace_tipc_node_link_down(n, true, "node link down or deleted!");
tipc_node_write_unlock(n);
if (delete)
--
2.13.7
^ permalink raw reply related
* Re: [PATCH bpf-next v4 0/2] libbpf: adding AF_XDP support
From: Jean-Mickael Guerin @ 2019-02-11 6:33 UTC (permalink / raw)
To: Magnus Karlsson
Cc: bjorn.topel, ast, daniel, netdev, jakub.kicinski, bjorn.topel,
qi.z.zhang, brouer, xiaolong.ye
In-Reply-To: <1549631126-29067-1-git-send-email-magnus.karlsson@intel.com>
Hi Magnus,
> * In a future release, I am planning on adding a higher level data
> plane interface too. This will be based around recvmsg and sendmsg
> with the use of struct iovec for batching, without the user having
> to know anything about the underlying four rings of an AF_XDP
> socket. There will be one semantic difference though from the
> standard recvmsg and that is that the kernel will fill in the iovecs
> instead of the application. But the rest should be the same as the
> libc versions so that application writers feel at home.
You might consider recvmmsg() and sendmmsg() (bulk of multi segments packets?)
Jean-Mickael
^ permalink raw reply
* [PATCH] Documentation: fix some freescale dpio-driver.rst warnings
From: Randy Dunlap @ 2019-02-11 6:32 UTC (permalink / raw)
To: netdev@vger.kernel.org
Cc: Stuart Yoder, Laurentiu Tudor, Ioana Radulescu, Madalin Bucur,
David Miller, linux-doc@vger.kernel.org
From: Randy Dunlap <rdunlap@infradead.org>
Fix markup warnings for one list by using correct list syntax.
Fix markup warnings for another list by using blank lines before the
list.
Documentation/networking/device_drivers/freescale/dpaa2/dpio-driver.rst:30: WARNING: Unexpected indentation.
Documentation/networking/device_drivers/freescale/dpaa2/dpio-driver.rst:143: WARNING: Unexpected indentation.
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Stuart Yoder <stuyoder@gmail.com>
Cc: Laurentiu Tudor <laurentiu.tudor@nxp.com>
Cc: Ioana Radulescu <ruxandra.radulescu@nxp.com>
Cc: netdev@vger.kernel.org
Cc: Madalin Bucur <madalin.bucur@nxp.com>
---
This still leaves 2 other warnings that I don't yet see how to fix.
Documentation/networking/device_drivers/freescale/dpaa2/dpio-driver.rst | 14 +++++-----
1 file changed, 7 insertions(+), 7 deletions(-)
--- lnx-50-rc6.orig/Documentation/networking/device_drivers/freescale/dpaa2/dpio-driver.rst
+++ lnx-50-rc6/Documentation/networking/device_drivers/freescale/dpaa2/dpio-driver.rst
@@ -27,11 +27,12 @@ Driver Overview
The DPIO driver is bound to DPIO objects discovered on the fsl-mc bus and
provides services that:
- A) allow other drivers, such as the Ethernet driver, to enqueue and dequeue
+
+ A. allow other drivers, such as the Ethernet driver, to enqueue and dequeue
frames for their respective objects
- B) allow drivers to register callbacks for data availability notifications
+ B. allow drivers to register callbacks for data availability notifications
when data becomes available on a queue or channel
- C) allow drivers to manage hardware buffer pools
+ C. allow drivers to manage hardware buffer pools
The Linux DPIO driver consists of 3 primary components--
DPIO object driver-- fsl-mc driver that manages the DPIO object
@@ -140,11 +141,10 @@ QBman portal interface (qbman-portal.c)
The qbman-portal component provides APIs to do the low level hardware
bit twiddling for operations such as:
- -initializing Qman software portals
-
- -building and sending portal commands
- -portal interrupt configuration and processing
+ - initializing Qman software portals
+ - building and sending portal commands
+ - portal interrupt configuration and processing
The qbman-portal APIs are not public to other drivers, and are
only used by dpio-service.
^ permalink raw reply
* Re: r8169 Driver - Poor Network Performance Since Kernel 4.19
From: David Chang @ 2019-02-11 6:23 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: Realtek linux nic maintainers, netdev, Martti Laaksonen
In-Reply-To: <856b3a75-5daf-6ce8-7fa3-0405e3cefe97@gmail.com>
Hi Heiner,
Sorry for late!
On Feb 05, 2019 at 19:50:30 +0100, Heiner Kallweit wrote:
> Hi David,
>
> meanwhile there's the following bug report matching what reported.
> It's even the same chip version (RTL8168h).
> https://bugzilla.redhat.com/show_bug.cgi?id=1671958
>
> Symptom there is also a significant number of rx_missed packets.
> Could you try what I mentioned there last:
> Try building a kernel with the call to rtl_hw_aspm_clkreq_enable(tp, true) at the
> end of rtl_hw_start_8168h_1() being disabled.
Will do.
Thanks,
David Chang
> Heiner
>
>
> On 31.01.2019 03:32, David Chang wrote:
> > Hi,
> >
> > We had a similr case here.
> > - Realtek r8169 receive performance regression in kernel 4.19
> > https://bugzilla.suse.com/show_bug.cgi?id=1119649
> >
> > kernel: r8169 0000:01:00.0 eth0: RTL8168h/8111h, XID 54100880
> > The major symptom is there are many rx_missed count.
> >
> >
> > On Jan 30, 2019 at 20:15:45 +0100, Heiner Kallweit wrote:
> >> Hi Peter,
> >>
> >> recently I had somebody where pcie_aspm=off for whatever reason didn't
> >> do the trick, can you also check with pcie_aspm.policy=performance.
> >
> > We will give it a try later.
> >
> >> And please check with "ethtool -S <if>" whether the chip statistics
> >> show a significant number of errors.
> >>
> >> If this doesn't help you may have to bisect to find the offending commit.
> >
> > We had tried fallback driver to a few previous commits as following,
> > but with no luck.
> >
> > 9675931e6b65 r8169: re-enable MSI-X on RTL8168g (v4.19)
> > 098b01ad9837 r8169: don't include asm headers directly (v4.19-rc1)
> > a2965f12fde6 r8169: remove rtl8169_set_speed_xmii (v4.19-rc1)
> > 6fcf9b1d4d6c r8169: fix runtime suspend (v4.19-rc1)
> > e397286b8e89 r8169: remove TBI 1000BaseX support (v4.19-rc1)
> >
> > Thanks,
> > David Chang
> >
> >>
> >> Heiner
> >>
> >>
> >> On 30.01.2019 10:59, Peter Ceiley wrote:
> >>> Hi Heiner,
> >>>
> >>> I tried disabling the ASPM using the pcie_aspm=off kernel parameter
> >>> and this made no difference.
> >>>
> >>> I tried compiling the 4.18.16 r8169.c with the 4.19.18 source and
> >>> subsequently loaded the module in the running 4.19.18 kernel. I can
> >>> confirm that this immediately resolved the issue and access to the NFS
> >>> shares operated as expected.
> >>>
> >>> I presume this means it is an issue with the r8169 driver included in
> >>> 4.19 onwards?
> >>>
> >>> To answer your last questions:
> >>>
> >>> Base Board Information
> >>> Manufacturer: Alienware
> >>> Product Name: 0PGRP5
> >>> Version: A02
> >>>
> >>> ... and yes, the RTL8168 is the onboard network chip.
> >>>
> >>> Regards,
> >>>
> >>> Peter.
> >>>
> >>> On Tue, 29 Jan 2019 at 17:44, Heiner Kallweit <hkallweit1@gmail.com> wrote:
> >>>>
> >>>> Hi Peter,
> >>>>
> >>>> I think the vendor driver doesn't enable ASPM per default.
> >>>> So it's worth a try to disable ASPM in the BIOS or via sysfs.
> >>>> Few older systems seem to have issues with ASPM, what kind of
> >>>> system / mainboard are you using? The RTL8168 is the onboard
> >>>> network chip?
> >>>>
> >>>> Rgds, Heiner
> >>>>
> >>>>
> >>>> On 29.01.2019 07:20, Peter Ceiley wrote:
> >>>>> Hi Heiner,
> >>>>>
> >>>>> Thanks, I'll do some more testing. It might not be the driver - I
> >>>>> assumed it was due to the fact that using the r8168 driver 'resolves'
> >>>>> the issue. I'll see if I can test the r8169.c on top of 4.19 - this is
> >>>>> a good idea.
> >>>>>
> >>>>> Cheers,
> >>>>>
> >>>>> Peter.
> >>>>>
> >>>>> On Tue, 29 Jan 2019 at 17:16, Heiner Kallweit <hkallweit1@gmail.com> wrote:
> >>>>>>
> >>>>>> Hi Peter,
> >>>>>>
> >>>>>> at a first glance it doesn't look like a typical driver issue.
> >>>>>> What you could do:
> >>>>>>
> >>>>>> - Test the r8169.c from 4.18 on top of 4.19.
> >>>>>>
> >>>>>> - Check whether disabling ASPM (/sys/module/pcie_aspm) has an effect.
> >>>>>>
> >>>>>> - Bisect between 4.18 and 4.19 to find the offending commit.
> >>>>>>
> >>>>>> Any specific reason why you think root cause is in the driver and not
> >>>>>> elsewhere in the network subsystem?
> >>>>>>
> >>>>>> Heiner
> >>>>>>
> >>>>>>
> >>>>>> On 28.01.2019 23:10, Peter Ceiley wrote:
> >>>>>>> Hi Heiner,
> >>>>>>>
> >>>>>>> Thanks for getting back to me.
> >>>>>>>
> >>>>>>> No, I don't use jumbo packets.
> >>>>>>>
> >>>>>>> Bandwidth is *generally* good, and iperf results to my NAS provide
> >>>>>>> over 900 Mbits/s in both circumstances. The issue seems to appear when
> >>>>>>> establishing a connection and is most notable, for example, on my
> >>>>>>> mounted NFS shares where it takes seconds (up to 10's of seconds on
> >>>>>>> larger directories) to list the contents of each directory. Once a
> >>>>>>> transfer begins on a file, I appear to get good bandwidth.
> >>>>>>>
> >>>>>>> I'm unsure of the best scientific data to provide you in order to
> >>>>>>> troubleshoot this issue. Running the following
> >>>>>>>
> >>>>>>> netstat -s |grep retransmitted
> >>>>>>>
> >>>>>>> shows a steady increase in retransmitted segments each time I list the
> >>>>>>> contents of a remote directory, for example, running 'ls' on a
> >>>>>>> directory containing 345 media files did the following using kernel
> >>>>>>> 4.19.18:
> >>>>>>>
> >>>>>>> increased retransmitted segments by 21 and the 'time' command showed
> >>>>>>> the following:
> >>>>>>> real 0m19.867s
> >>>>>>> user 0m0.012s
> >>>>>>> sys 0m0.036s
> >>>>>>>
> >>>>>>> The same command shows no retransmitted segments running kernel
> >>>>>>> 4.18.16 and 'time' showed:
> >>>>>>> real 0m0.300s
> >>>>>>> user 0m0.004s
> >>>>>>> sys 0m0.007s
> >>>>>>>
> >>>>>>> ifconfig does not show any RX/TX errors nor dropped packets in either case.
> >>>>>>>
> >>>>>>> dmesg XID:
> >>>>>>> [ 2.979984] r8169 0000:03:00.0 eth0: RTL8168g/8111g,
> >>>>>>> f8:b1:56:fe:67:e0, XID 4c000800, IRQ 32
> >>>>>>>
> >>>>>>> # lspci -vv
> >>>>>>> 03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
> >>>>>>> RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c)
> >>>>>>> Subsystem: Dell RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
> >>>>>>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> >>>>>>> ParErr- Stepping- SERR- FastB2B- DisINTx+
> >>>>>>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> >>>>>>> <TAbort- <MAbort- >SERR- <PERR- INTx-
> >>>>>>> Latency: 0, Cache Line Size: 64 bytes
> >>>>>>> Interrupt: pin A routed to IRQ 19
> >>>>>>> Region 0: I/O ports at d000 [size=256]
> >>>>>>> Region 2: Memory at f7b00000 (64-bit, non-prefetchable) [size=4K]
> >>>>>>> Region 4: Memory at f2100000 (64-bit, prefetchable) [size=16K]
> >>>>>>> Capabilities: [40] Power Management version 3
> >>>>>>> Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA
> >>>>>>> PME(D0+,D1+,D2+,D3hot+,D3cold+)
> >>>>>>> Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
> >>>>>>> Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
> >>>>>>> Address: 0000000000000000 Data: 0000
> >>>>>>> Capabilities: [70] Express (v2) Endpoint, MSI 01
> >>>>>>> DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s
> >>>>>>> <512ns, L1 <64us
> >>>>>>> ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
> >>>>>>> SlotPowerLimit 10.000W
> >>>>>>> DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq-
> >>>>>>> RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
> >>>>>>> MaxPayload 128 bytes, MaxReadReq 4096 bytes
> >>>>>>> DevSta: CorrErr+ NonFatalErr- FatalErr- UnsupReq- AuxPwr+ TransPend-
> >>>>>>> LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit
> >>>>>>> Latency L0s unlimited, L1 <64us
> >>>>>>> ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp+
> >>>>>>> LnkCtl: ASPM L1 Enabled; RCB 64 bytes Disabled- CommClk+
> >>>>>>> ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
> >>>>>>> LnkSta: Speed 2.5GT/s (ok), Width x1 (ok)
> >>>>>>> TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
> >>>>>>> DevCap2: Completion Timeout: Range ABCD, TimeoutDis+, LTR+,
> >>>>>>> OBFF Via message/WAKE#
> >>>>>>> AtomicOpsCap: 32bit- 64bit- 128bitCAS-
> >>>>>>> DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR+,
> >>>>>>> OBFF Disabled
> >>>>>>> AtomicOpsCtl: ReqEn-
> >>>>>>> LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-
> >>>>>>> Transmit Margin: Normal Operating Range,
> >>>>>>> EnterModifiedCompliance- ComplianceSOS-
> >>>>>>> Compliance De-emphasis: -6dB
> >>>>>>> LnkSta2: Current De-emphasis Level: -6dB,
> >>>>>>> EqualizationComplete-, EqualizationPhase1-
> >>>>>>> EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
> >>>>>>> Capabilities: [b0] MSI-X: Enable+ Count=4 Masked-
> >>>>>>> Vector table: BAR=4 offset=00000000
> >>>>>>> PBA: BAR=4 offset=00000800
> >>>>>>> Capabilities: [d0] Vital Product Data
> >>>>>>> pcilib: sysfs_read_vpd: read failed: Input/output error
> >>>>>>> Not readable
> >>>>>>> Capabilities: [100 v1] Advanced Error Reporting
> >>>>>>> UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt-
> >>>>>>> RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
> >>>>>>> UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt-
> >>>>>>> RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
> >>>>>>> UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt-
> >>>>>>> RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
> >>>>>>> CESta: RxErr+ BadTLP+ BadDLLP+ Rollover- Timeout+ AdvNonFatalErr-
> >>>>>>> CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+
> >>>>>>> AERCap: First Error Pointer: 00, ECRCGenCap+ ECRCGenEn-
> >>>>>>> ECRCChkCap+ ECRCChkEn-
> >>>>>>> MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap-
> >>>>>>> HeaderLog: 00000000 00000000 00000000 00000000
> >>>>>>> Capabilities: [140 v1] Virtual Channel
> >>>>>>> Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
> >>>>>>> Arb: Fixed- WRR32- WRR64- WRR128-
> >>>>>>> Ctrl: ArbSelect=Fixed
> >>>>>>> Status: InProgress-
> >>>>>>> VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
> >>>>>>> Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
> >>>>>>> Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01
> >>>>>>> Status: NegoPending- InProgress-
> >>>>>>> Capabilities: [160 v1] Device Serial Number 01-00-00-00-68-4c-e0-00
> >>>>>>> Capabilities: [170 v1] Latency Tolerance Reporting
> >>>>>>> Max snoop latency: 71680ns
> >>>>>>> Max no snoop latency: 71680ns
> >>>>>>> Kernel driver in use: r8169
> >>>>>>> Kernel modules: r8169
> >>>>>>>
> >>>>>>> Please let me know if you have any other ideas in terms of testing.
> >>>>>>>
> >>>>>>> Thanks!
> >>>>>>>
> >>>>>>> Peter.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On Tue, 29 Jan 2019 at 05:28, Heiner Kallweit <hkallweit1@gmail.com> wrote:
> >>>>>>>>
> >>>>>>>> On 28.01.2019 12:13, Peter Ceiley wrote:
> >>>>>>>>> Hi,
> >>>>>>>>>
> >>>>>>>>> I have been experiencing very poor network performance since Kernel
> >>>>>>>>> 4.19 and I'm confident it's related to the r8169 driver.
> >>>>>>>>>
> >>>>>>>>> I have no issue with kernel versions 4.18 and prior. I am experiencing
> >>>>>>>>> this issue in kernels 4.19 and 4.20 (currently running/testing with
> >>>>>>>>> 4.20.4 & 4.19.18).
> >>>>>>>>>
> >>>>>>>>> If someone could guide me in the right direction, I'm happy to help
> >>>>>>>>> troubleshoot this issue. Note that I have been keeping an eye on one
> >>>>>>>>> issue related to loading of the PHY driver, however, my symptoms
> >>>>>>>>> differ in that I still have a network connection. I have attempted to
> >>>>>>>>> reload the driver on a running system, but this does not improve the
> >>>>>>>>> situation.
> >>>>>>>>>
> >>>>>>>>> Using the proprietary r8168 driver returns my device to proper working order.
> >>>>>>>>>
> >>>>>>>>> lshw shows:
> >>>>>>>>> description: Ethernet interface
> >>>>>>>>> product: RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
> >>>>>>>>> vendor: Realtek Semiconductor Co., Ltd.
> >>>>>>>>> physical id: 0
> >>>>>>>>> bus info: pci@0000:03:00.0
> >>>>>>>>> logical name: enp3s0
> >>>>>>>>> version: 0c
> >>>>>>>>> serial:
> >>>>>>>>> size: 1Gbit/s
> >>>>>>>>> capacity: 1Gbit/s
> >>>>>>>>> width: 64 bits
> >>>>>>>>> clock: 33MHz
> >>>>>>>>> capabilities: pm msi pciexpress msix vpd bus_master cap_list
> >>>>>>>>> ethernet physical tp aui bnc mii fibre 10bt 10bt-fd 100bt 100bt-fd
> >>>>>>>>> 1000bt-fd autonegotiation
> >>>>>>>>> configuration: autonegotiation=on broadcast=yes driver=r8169
> >>>>>>>>> duplex=full firmware=rtl8168g-2_0.0.1 02/06/13 ip=192.168.1.25
> >>>>>>>>> latency=0 link=yes multicast=yes port=MII speed=1Gbit/s
> >>>>>>>>> resources: irq:19 ioport:d000(size=256)
> >>>>>>>>> memory:f7b00000-f7b00fff memory:f2100000-f2103fff
> >>>>>>>>>
> >>>>>>>>> Kind Regards,
> >>>>>>>>>
> >>>>>>>>> Peter.
> >>>>>>>>>
> >>>>>>>> Hi Peter,
> >>>>>>>>
> >>>>>>>> the description "poor network performance" is quite vague, therefore:
> >>>>>>>>
> >>>>>>>> - Can you provide any measurements?
> >>>>>>>> - iperf results before and after
> >>>>>>>> - statistics about dropped packets (rx and/or tx)
> >>>>>>>> - Do you use jumbo packets?
> >>>>>>>>
> >>>>>>>> Also help would be a "lspci -vv" output for the network card and
> >>>>>>>> the dmesg output line with the chip XID.
> >>>>>>>>
> >>>>>>>> Heiner
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
>
>
^ permalink raw reply
* Re: [PATCH net-next 0/2] Revert wake_on_lan devlink parameter
From: Vasundhara Volam @ 2019-02-11 4:39 UTC (permalink / raw)
To: David Miller; +Cc: michael.chan@broadcom.com, Jiri Pirko, Netdev
In-Reply-To: <20190208.230707.337997172178002602.davem@davemloft.net>
On Sat, Feb 9, 2019 at 12:37 PM David Miller <davem@davemloft.net> wrote:
>
> From: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
> Date: Fri, 8 Feb 2019 14:43:08 +0530
>
> > As per discussion with Jakub Kicinski and Michal Kubecek,
> > this will be better addressed by soon-too-come ethtool netlink
> > API with additional indication that given WoL configuration request
> > is supposed to be persisted.
> >
> > Retain bnxt_en code for devlink port param table registration.
> > There will be follow up patches to add some devlink port params
> > for bnxt_en driver.
>
> Please fix the kbuild robot reported build failure and repost.
David, second patch in this patchset has already taken care of all
this failures.
Could you please apply both patches together?
^ permalink raw reply
* Re: [PATCH bpf] xsk: add missing smp_rmb() in xsk_mmap
From: Alexei Starovoitov @ 2019-02-11 4:08 UTC (permalink / raw)
To: Magnus Karlsson; +Cc: bjorn.topel, ast, daniel, netdev
In-Reply-To: <1549631630-29208-1-git-send-email-magnus.karlsson@intel.com>
On Fri, Feb 08, 2019 at 02:13:50PM +0100, Magnus Karlsson wrote:
> All the setup code in AF_XDP is protected by a mutex with the
> exception of the mmap code that cannot use it. To make sure that a
> process banging on the mmap call at the same time as another process
> is setting up the socket, smp_wmb() calls were added in the umem
> registration code and the queue creation code, so that the published
> structures that xsk_mmap needs would be consistent. However, the
> corresponding smp_rmb() calls were not added to the xsk_mmap
> code. This patch adds these calls.
>
> Fixes: 37b076933a8e3 ("xsk: add missing write- and data-dependency barrier")
> Fixes: c0c77d8fb787c ("xsk: add user memory registration support sockopt")
> Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com>
Applied, Thanks
^ permalink raw reply
* Re: [PATCH bpf-next 3/3] selftests: bpf: centre kernel bpf objects under new subdir "kern_progs"
From: Alexei Starovoitov @ 2019-02-11 4:06 UTC (permalink / raw)
To: Jiong Wang; +Cc: daniel, netdev, oss-drivers
In-Reply-To: <1549647681-13818-4-git-send-email-jiong.wang@netronome.com>
On Fri, Feb 08, 2019 at 05:41:21PM +0000, Jiong Wang wrote:
> At the moment, all kernel bpf objects are listed under BPF_OBJ_FILES.
> Listing them manually sometimes causing patch conflict when people are
> adding new testcases simultaneously.
>
> It is better to centre all the related source files under a subdir
> "kern_progs", then auto-generate the object file list.
>
> Suggested-by: Alexei Starovoitov <ast@kernel.org>
> Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> Signed-off-by: Jiong Wang <jiong.wang@netronome.com>
> ---
> tools/testing/selftests/bpf/Makefile | 26 +++++-----------------
> .../selftests/bpf/{ => kern_progs}/bpf_flow.c | 0
> .../selftests/bpf/{ => kern_progs}/connect4_prog.c | 0
> .../selftests/bpf/{ => kern_progs}/connect6_prog.c | 0
> .../selftests/bpf/{ => kern_progs}/dev_cgroup.c | 0
Thanks a lot for the patch.
A tiny bit of bikeshedding...
'kern_progs' feels a bit too long and awkward to type.
May be just 'progs' ?
^ permalink raw reply
* Re: [PATCH bpf-next 2/3] selftests: bpf: extend sub-register mode compilation to all bpf object files
From: Alexei Starovoitov @ 2019-02-11 4:04 UTC (permalink / raw)
To: Jiong Wang; +Cc: daniel, netdev, oss-drivers
In-Reply-To: <1549647681-13818-3-git-send-email-jiong.wang@netronome.com>
On Fri, Feb 08, 2019 at 05:41:20PM +0000, Jiong Wang wrote:
> At the moment, we only do extra sub-register mode compilation on bpf object
> files used by "test_progs". These object files are really loaded and
> executed.
>
> This patch further extends sub-register mode compilation to all bpf object
> files, even those without corresponding runtime tests. Because this could
> help testing LLVM sub-register code-gen, kernel bpf selftest has much more
> C testcases with reasonable size and complexity compared with LLVM
> testsuite which only contains unit tests.
>
> There were some file duplication inside BPF_OBJ_FILES_DUAL_COMPILE which
> is removed now.
>
> Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> Signed-off-by: Jiong Wang <jiong.wang@netronome.com>
> ---
> tools/testing/selftests/bpf/Makefile | 21 ++++++++-------------
> 1 file changed, 8 insertions(+), 13 deletions(-)
>
> diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile
> index 383d2ff..70b2570 100644
> --- a/tools/testing/selftests/bpf/Makefile
> +++ b/tools/testing/selftests/bpf/Makefile
> @@ -35,20 +35,15 @@ BPF_OBJ_FILES = \
> sendmsg4_prog.o sendmsg6_prog.o test_lirc_mode2_kern.o \
> get_cgroup_id_kern.o socket_cookie_prog.o test_select_reuseport_kern.o \
> test_skb_cgroup_id_kern.o bpf_flow.o netcnt_prog.o test_xdp_vlan.o \
> - xdp_dummy.o test_map_in_map.o test_spin_lock.o test_map_lock.o
> -
> -# Objects are built with default compilation flags and with sub-register
> -# code-gen enabled.
> -BPF_OBJ_FILES_DUAL_COMPILE = \
> - test_pkt_access.o test_pkt_access.o test_xdp.o test_adjust_tail.o \
> - test_l4lb.o test_l4lb_noinline.o test_xdp_noinline.o test_tcp_estats.o \
> + xdp_dummy.o test_map_in_map.o test_spin_lock.o test_map_lock.o \
> + test_pkt_access.o test_xdp.o test_adjust_tail.o test_l4lb.o \
> + test_l4lb_noinline.o test_xdp_noinline.o test_tcp_estats.o \
> test_obj_id.o test_pkt_md_access.o test_tracepoint.o \
> - test_stacktrace_map.o test_stacktrace_map.o test_stacktrace_build_id.o \
> - test_stacktrace_build_id.o test_get_stack_rawtp.o \
> - test_get_stack_rawtp.o test_tracepoint.o test_sk_lookup_kern.o \
> - test_queue_map.o test_stack_map.o
> + test_stacktrace_map.o test_stacktrace_build_id.o \
> + test_get_stack_rawtp.o test_sk_lookup_kern.o test_queue_map.o \
> + test_stack_map.o
>
> -TEST_GEN_FILES = $(BPF_OBJ_FILES) $(BPF_OBJ_FILES_DUAL_COMPILE)
> +TEST_GEN_FILES = $(BPF_OBJ_FILES)
>
> # Also test sub-register code-gen if LLVM + kernel both has eBPF v3 processor
> # support which is the first version to contain both ALU32 and JMP32
> @@ -58,7 +53,7 @@ SUBREG_CODEGEN := $(shell echo "int cal(int a) { return a > 0; }" | \
> $(LLC) -mattr=+alu32 -mcpu=probe 2>&1 | \
> grep 'if w')
build and test servers can be different.
Would it make sense to use -mcpu=v3 instead of -mcpu=probe ?
Also while testing test_progs_32 fails like this:
libbpf: failed to open ./bpf_flow.o: No such file or directory
libbpf: failed to open ./test_spin_lock.o: No such file or directory
test_spin_lock:bpf_prog_load errno 2
Do you see the same ?
^ permalink raw reply
* Re: [PATCH bpf] bpf: only adjust gso_size on bytestream protocols
From: Alexei Starovoitov @ 2019-02-11 4:00 UTC (permalink / raw)
To: Willem de Bruijn; +Cc: netdev, ast, daniel, posk.devel, dja, Willem de Bruijn
In-Reply-To: <20190207195416.27082-1-willemdebruijn.kernel@gmail.com>
On Thu, Feb 07, 2019 at 02:54:16PM -0500, Willem de Bruijn wrote:
> From: Willem de Bruijn <willemb@google.com>
>
> bpf_skb_change_proto and bpf_skb_adjust_room change skb header length.
> For GSO packets they adjust gso_size to maintain the same MTU.
>
> The gso size can only be safely adjusted on bytestream protocols.
> Commit d02f51cbcf12 ("bpf: fix bpf_skb_adjust_net/bpf_skb_proto_xlat
> to deal with gso sctp skbs") excluded SKB_GSO_SCTP.
>
> Since then type SKB_GSO_UDP_L4 has been added, whose contents are one
> gso_size unit per datagram. Also exclude these.
>
> Move from a blacklist to a whitelist check to future proof against
> additional such new GSO types, e.g., for fraglist based GRO.
>
> Fixes: bec1f6f69736 ("udp: generate gso with UDP_SEGMENT")
> Signed-off-by: Willem de Bruijn <willemb@google.com>
Applied to bpf tree.
I agree that whitelist approach is the most appropriate.
^ permalink raw reply
* Re: [PATCH v2 bpf-next 0/7] Add __sk_buff->sk, bpf_tcp_sock, BPF_FUNC_tcp_sock and BPF_FUNC_sk_fullsock
From: Alexei Starovoitov @ 2019-02-11 3:55 UTC (permalink / raw)
To: Martin KaFai Lau
Cc: netdev, Alexei Starovoitov, Daniel Borkmann, kernel-team,
Lawrence Brakmo
In-Reply-To: <20190210072220.1530061-1-kafai@fb.com>
On Sat, Feb 09, 2019 at 11:22:20PM -0800, Martin KaFai Lau wrote:
> This series adds __sk_buff->sk, "struct bpf_tcp_sock",
> BPF_FUNC_sk_fullsock and BPF_FUNC_tcp_sock. Together, they provide
> a common way to expose the members of "struct tcp_sock" and
> "struct bpf_sock" for the bpf_prog to access.
>
> The patch series first adds a bpf_sock pointer to __sk_buff
> and a new helper BPF_FUNC_sk_fullsock.
>
> It then adds BPF_FUNC_tcp_sock to get a bpf_tcp_sock
> pointer from a bpf_sock pointer.
>
> The current use case is to allow a cg_skb_bpf_prog to provide
> per cgroup traffic policing/shaping.
>
> Please see individual patch for details.
>
> v2:
> - Patch 1 depends on
> commit d623876646be ("bpf: Fix narrow load on a bpf_sock returned from sk_lookup()")
> in the bpf branch.
> - Add sk_to_full_sk() to bpf_sk_fullsock() and bpf_tcp_sock()
> such that there is a way to access the listener's sk and tcp_sk
> when __sk_buff->sk is a request_sock.
> The comments in the uapi bpf.h is updated accordingly.
> - bpf_ctx_range_till() is used in bpf_sock_common_is_valid_access()
> in patch 1. Saved a few lines.
> - Patch 2 is new in v2 and it adds "state", "dst_ip4", "dst_ip6" and
> "dst_port" to the bpf_sock. Narrow load is allowed on them.
> The "state" (i.e. sk_state) has already been used in
> INET_DIAG (e.g. ss -t) and getsockopt(TCP_INFO).
> - While at it in the new patch 2, also allow narrow load on some
> existing fields of the bpf_sock, which are "family", "type", "protocol"
> and "src_port". Only allow loading from first byte for now.
> i.e. does not allow narrow load starting from the 2nd byte.
> - Add some narrow load tests to the test_verifier's sock.c
Daniel,
I believe this new revision addresses your concerns exactly as we discussed.
So I pushed it to bpf-next.
please double check that it's what you expected.
We can always revert.
Thanks everyone!
^ permalink raw reply
* [PATCH net-next v3] ipmr: ip6mr: Create new sockopt to clear mfc cache or vifs
From: Callum Sinclair @ 2019-02-11 3:54 UTC (permalink / raw)
To: davem, kuznet, yoshfuji, nikolay, netdev, linux-kernel
Cc: nicolas.dichtel, Callum Sinclair
In-Reply-To: <20190211035412.29218-1-callum.sinclair@alliedtelesis.co.nz>
v1 -> v2:
Implemented additional flags for static entries
v2 -> v3:
Cleaned up flag logic so any combination of routes can be cleared.
Fixed style errors
Fixed incorrect flag values
Currently the only way to clear the forwarding cache was to delete the
entries one by one using the MRT_DEL_MFC socket option or to destroy and
recreate the socket.
Create a new socket option which with the use of optional flags can
clear any combination of multicast entries (static or not static) and
multicast vifs (static or not static).
Calling the new socket option MRT_FLUSH with the flags MRT_FLUSH_MFC and
MRT_FLUSH_VIFS will clear all entries and vifs on the socket except for
static entries.
Signed-off-by: Callum Sinclair <callum.sinclair@alliedtelesis.co.nz>
---
include/uapi/linux/mroute.h | 9 ++++-
include/uapi/linux/mroute6.h | 9 ++++-
net/ipv4/ipmr.c | 73 ++++++++++++++++++++-------------
net/ipv6/ip6mr.c | 78 +++++++++++++++++++++++-------------
4 files changed, 112 insertions(+), 57 deletions(-)
diff --git a/include/uapi/linux/mroute.h b/include/uapi/linux/mroute.h
index 5d37a9ccce63..11c8c1fc1124 100644
--- a/include/uapi/linux/mroute.h
+++ b/include/uapi/linux/mroute.h
@@ -28,12 +28,19 @@
#define MRT_TABLE (MRT_BASE+9) /* Specify mroute table ID */
#define MRT_ADD_MFC_PROXY (MRT_BASE+10) /* Add a (*,*|G) mfc entry */
#define MRT_DEL_MFC_PROXY (MRT_BASE+11) /* Del a (*,*|G) mfc entry */
-#define MRT_MAX (MRT_BASE+11)
+#define MRT_FLUSH (MRT_BASE+12) /* Flush all mfc entries and/or vifs */
+#define MRT_MAX (MRT_BASE+12)
#define SIOCGETVIFCNT SIOCPROTOPRIVATE /* IP protocol privates */
#define SIOCGETSGCNT (SIOCPROTOPRIVATE+1)
#define SIOCGETRPF (SIOCPROTOPRIVATE+2)
+/* MRT_FLUSH optional flags */
+#define MRT_FLUSH_MFC 1 /* Flush multicast entries */
+#define MRT_FLUSH_MFC_STATIC 2 /* Flush static multicast entries */
+#define MRT_FLUSH_VIFS 4 /* Flush multicast vifs */
+#define MRT_FLUSH_VIFS_STATIC 8 /* Flush static multicast vifs */
+
#define MAXVIFS 32
typedef unsigned long vifbitmap_t; /* User mode code depends on this lot */
typedef unsigned short vifi_t;
diff --git a/include/uapi/linux/mroute6.h b/include/uapi/linux/mroute6.h
index 9999cc006390..ac84ef11b29c 100644
--- a/include/uapi/linux/mroute6.h
+++ b/include/uapi/linux/mroute6.h
@@ -31,12 +31,19 @@
#define MRT6_TABLE (MRT6_BASE+9) /* Specify mroute table ID */
#define MRT6_ADD_MFC_PROXY (MRT6_BASE+10) /* Add a (*,*|G) mfc entry */
#define MRT6_DEL_MFC_PROXY (MRT6_BASE+11) /* Del a (*,*|G) mfc entry */
-#define MRT6_MAX (MRT6_BASE+11)
+#define MRT6_FLUSH (MRT6_BASE+12) /* Flush all mfc entries and/or vifs */
+#define MRT6_MAX (MRT6_BASE+12)
#define SIOCGETMIFCNT_IN6 SIOCPROTOPRIVATE /* IP protocol privates */
#define SIOCGETSGCNT_IN6 (SIOCPROTOPRIVATE+1)
#define SIOCGETRPF (SIOCPROTOPRIVATE+2)
+/* MRT6_FLUSH optional flags */
+#define MRT6_FLUSH_MFC 1 /* Flush multicast entries */
+#define MRT6_FLUSH_MFC_STATIC 2 /* Flush static multicast entries */
+#define MRT6_FLUSH_VIFS 4 /* Flushing multicast vifs */
+#define MRT6_FLUSH_VIFS_STATIC 8 /* Flush static multicast vifs */
+
#define MAXMIFS 32
typedef unsigned long mifbitmap_t; /* User mode code depends on this lot */
typedef unsigned short mifi_t;
diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
index e536970557dd..2c95ef8cf224 100644
--- a/net/ipv4/ipmr.c
+++ b/net/ipv4/ipmr.c
@@ -110,7 +110,7 @@ static int ipmr_cache_report(struct mr_table *mrt,
static void mroute_netlink_event(struct mr_table *mrt, struct mfc_cache *mfc,
int cmd);
static void igmpmsg_netlink_event(struct mr_table *mrt, struct sk_buff *pkt);
-static void mroute_clean_tables(struct mr_table *mrt, bool all);
+static void mroute_clean_tables(struct mr_table *mrt, int flags);
static void ipmr_expire_process(struct timer_list *t);
#ifdef CONFIG_IP_MROUTE_MULTIPLE_TABLES
@@ -415,7 +415,8 @@ static struct mr_table *ipmr_new_table(struct net *net, u32 id)
static void ipmr_free_table(struct mr_table *mrt)
{
del_timer_sync(&mrt->ipmr_expire_timer);
- mroute_clean_tables(mrt, true);
+ mroute_clean_tables(mrt, MRT_FLUSH_VIFS | MRT_FLUSH_VIFS_STATIC |
+ MRT_FLUSH_MFC | MRT_FLUSH_MFC_STATIC);
rhltable_destroy(&mrt->mfc_hash);
kfree(mrt);
}
@@ -1296,7 +1297,7 @@ static int ipmr_mfc_add(struct net *net, struct mr_table *mrt,
}
/* Close the multicast socket, and clear the vif tables etc */
-static void mroute_clean_tables(struct mr_table *mrt, bool all)
+static void mroute_clean_tables(struct mr_table *mrt, int flags)
{
struct net *net = read_pnet(&mrt->net);
struct mr_mfc *c, *tmp;
@@ -1305,35 +1306,42 @@ static void mroute_clean_tables(struct mr_table *mrt, bool all)
int i;
/* Shut down all active vif entries */
- for (i = 0; i < mrt->maxvif; i++) {
- if (!all && (mrt->vif_table[i].flags & VIFF_STATIC))
- continue;
- vif_delete(mrt, i, 0, &list);
+ if (flags & (MRT_FLUSH_VIFS | MRT_FLUSH_VIFS_STATIC)) {
+ for (i = 0; i < mrt->maxvif; i++) {
+ if (((mrt->vif_table[i].flags & VIFF_STATIC) &&
+ !(flags & MRT_FLUSH_VIFS_STATIC)) ||
+ (!(mrt->vif_table[i].flags & VIFF_STATIC) && !(flags & MRT_FLUSH)))
+ continue;
+ vif_delete(mrt, i, 0, &list);
+ }
+ unregister_netdevice_many(&list);
}
- unregister_netdevice_many(&list);
/* Wipe the cache */
- list_for_each_entry_safe(c, tmp, &mrt->mfc_cache_list, list) {
- if (!all && (c->mfc_flags & MFC_STATIC))
- continue;
- rhltable_remove(&mrt->mfc_hash, &c->mnode, ipmr_rht_params);
- list_del_rcu(&c->list);
- cache = (struct mfc_cache *)c;
- call_ipmr_mfc_entry_notifiers(net, FIB_EVENT_ENTRY_DEL, cache,
- mrt->id);
- mroute_netlink_event(mrt, cache, RTM_DELROUTE);
- mr_cache_put(c);
- }
-
- if (atomic_read(&mrt->cache_resolve_queue_len) != 0) {
- spin_lock_bh(&mfc_unres_lock);
- list_for_each_entry_safe(c, tmp, &mrt->mfc_unres_queue, list) {
- list_del(&c->list);
+ if (flags & (MRT_FLUSH_MFC | MRT_FLUSH_MFC_STATIC)) {
+ list_for_each_entry_safe(c, tmp, &mrt->mfc_cache_list, list) {
+ if (((c->mfc_flags & MFC_STATIC) && !(flags & MRT_FLUSH_MFC_STATIC)) ||
+ (!(c->mfc_flags & MFC_STATIC) && !(flags & MRT_FLUSH_MFC)))
+ continue;
+ rhltable_remove(&mrt->mfc_hash, &c->mnode, ipmr_rht_params);
+ list_del_rcu(&c->list);
cache = (struct mfc_cache *)c;
+ call_ipmr_mfc_entry_notifiers(net, FIB_EVENT_ENTRY_DEL, cache,
+ mrt->id);
mroute_netlink_event(mrt, cache, RTM_DELROUTE);
- ipmr_destroy_unres(mrt, cache);
+ mr_cache_put(c);
+ }
+
+ if (atomic_read(&mrt->cache_resolve_queue_len) != 0) {
+ spin_lock_bh(&mfc_unres_lock);
+ list_for_each_entry_safe(c, tmp, &mrt->mfc_unres_queue, list) {
+ list_del(&c->list);
+ cache = (struct mfc_cache *)c;
+ mroute_netlink_event(mrt, cache, RTM_DELROUTE);
+ ipmr_destroy_unres(mrt, cache);
+ }
+ spin_unlock_bh(&mfc_unres_lock);
}
- spin_unlock_bh(&mfc_unres_lock);
}
}
@@ -1354,7 +1362,7 @@ static void mrtsock_destruct(struct sock *sk)
NETCONFA_IFINDEX_ALL,
net->ipv4.devconf_all);
RCU_INIT_POINTER(mrt->mroute_sk, NULL);
- mroute_clean_tables(mrt, false);
+ mroute_clean_tables(mrt, MRT_FLUSH_VIFS | MRT_FLUSH_MFC);
}
}
rtnl_unlock();
@@ -1479,6 +1487,17 @@ int ip_mroute_setsockopt(struct sock *sk, int optname, char __user *optval,
sk == rtnl_dereference(mrt->mroute_sk),
parent);
break;
+ case MRT_FLUSH:
+ if (optlen != sizeof(val)) {
+ ret = -EINVAL;
+ break;
+ }
+ if (get_user(val, (int __user *)optval)) {
+ ret = -EFAULT;
+ break;
+ }
+ mroute_clean_tables(mrt, val);
+ break;
/* Control PIM assert. */
case MRT_ASSERT:
if (optlen != sizeof(val)) {
diff --git a/net/ipv6/ip6mr.c b/net/ipv6/ip6mr.c
index cc01aa3f2b5e..c6909b5e927c 100644
--- a/net/ipv6/ip6mr.c
+++ b/net/ipv6/ip6mr.c
@@ -97,7 +97,7 @@ static void mr6_netlink_event(struct mr_table *mrt, struct mfc6_cache *mfc,
static void mrt6msg_netlink_event(struct mr_table *mrt, struct sk_buff *pkt);
static int ip6mr_rtm_dumproute(struct sk_buff *skb,
struct netlink_callback *cb);
-static void mroute_clean_tables(struct mr_table *mrt, bool all);
+static void mroute_clean_tables(struct mr_table *mrt, int flags);
static void ipmr_expire_process(struct timer_list *t);
#ifdef CONFIG_IPV6_MROUTE_MULTIPLE_TABLES
@@ -393,7 +393,8 @@ static struct mr_table *ip6mr_new_table(struct net *net, u32 id)
static void ip6mr_free_table(struct mr_table *mrt)
{
del_timer_sync(&mrt->ipmr_expire_timer);
- mroute_clean_tables(mrt, true);
+ mroute_clean_tables(mrt, MRT6_FLUSH_VIFS | MRT6_FLUSH_VIFS_STATIC |
+ MRT6_FLUSH_MFC | MRT6_FLUSH_MFC_STATIC);
rhltable_destroy(&mrt->mfc_hash);
kfree(mrt);
}
@@ -1496,42 +1497,49 @@ static int ip6mr_mfc_add(struct net *net, struct mr_table *mrt,
* Close the multicast socket, and clear the vif tables etc
*/
-static void mroute_clean_tables(struct mr_table *mrt, bool all)
+static void mroute_clean_tables(struct mr_table *mrt, int flags)
{
struct mr_mfc *c, *tmp;
LIST_HEAD(list);
int i;
/* Shut down all active vif entries */
- for (i = 0; i < mrt->maxvif; i++) {
- if (!all && (mrt->vif_table[i].flags & VIFF_STATIC))
- continue;
- mif6_delete(mrt, i, 0, &list);
+ if (flags & (MRT6_FLUSH_VIFS | MRT6_FLUSH_VIFS_STATIC)) {
+ for (i = 0; i < mrt->maxvif; i++) {
+ if (((mrt->vif_table[i].flags & VIFF_STATIC) &&
+ !(flags & MRT6_FLUSH_VIFS_STATIC)) ||
+ (!(mrt->vif_table[i].flags & VIFF_STATIC) && !(flags & MRT6_FLUSH_VIFS)))
+ continue;
+ mif6_delete(mrt, i, 0, &list);
+ }
+ unregister_netdevice_many(&list);
}
- unregister_netdevice_many(&list);
/* Wipe the cache */
- list_for_each_entry_safe(c, tmp, &mrt->mfc_cache_list, list) {
- if (!all && (c->mfc_flags & MFC_STATIC))
- continue;
- rhltable_remove(&mrt->mfc_hash, &c->mnode, ip6mr_rht_params);
- list_del_rcu(&c->list);
- call_ip6mr_mfc_entry_notifiers(read_pnet(&mrt->net),
- FIB_EVENT_ENTRY_DEL,
- (struct mfc6_cache *)c, mrt->id);
- mr6_netlink_event(mrt, (struct mfc6_cache *)c, RTM_DELROUTE);
- mr_cache_put(c);
- }
+ if (flags & (MRT6_FLUSH_MFC | MRT6_FLUSH_MFC_STATIC)) {
+ list_for_each_entry_safe(c, tmp, &mrt->mfc_cache_list, list) {
+ if (((c->mfc_flags & MFC_STATIC) && !(flags & MRT6_FLUSH_MFC_STATIC)) ||
+ (!(c->mfc_flags & MFC_STATIC) && !(flags & MRT6_FLUSH_MFC)))
+ continue;
+ rhltable_remove(&mrt->mfc_hash, &c->mnode, ip6mr_rht_params);
+ list_del_rcu(&c->list);
+ call_ip6mr_mfc_entry_notifiers(read_pnet(&mrt->net),
+ FIB_EVENT_ENTRY_DEL,
+ (struct mfc6_cache *)c, mrt->id);
+ mr6_netlink_event(mrt, (struct mfc6_cache *)c, RTM_DELROUTE);
+ mr_cache_put(c);
+ }
- if (atomic_read(&mrt->cache_resolve_queue_len) != 0) {
- spin_lock_bh(&mfc_unres_lock);
- list_for_each_entry_safe(c, tmp, &mrt->mfc_unres_queue, list) {
- list_del(&c->list);
- mr6_netlink_event(mrt, (struct mfc6_cache *)c,
- RTM_DELROUTE);
- ip6mr_destroy_unres(mrt, (struct mfc6_cache *)c);
+ if (atomic_read(&mrt->cache_resolve_queue_len) != 0) {
+ spin_lock_bh(&mfc_unres_lock);
+ list_for_each_entry_safe(c, tmp, &mrt->mfc_unres_queue, list) {
+ list_del(&c->list);
+ mr6_netlink_event(mrt, (struct mfc6_cache *)c,
+ RTM_DELROUTE);
+ ip6mr_destroy_unres(mrt, (struct mfc6_cache *)c);
+ }
+ spin_unlock_bh(&mfc_unres_lock);
}
- spin_unlock_bh(&mfc_unres_lock);
}
}
@@ -1587,7 +1595,7 @@ int ip6mr_sk_done(struct sock *sk)
NETCONFA_IFINDEX_ALL,
net->ipv6.devconf_all);
- mroute_clean_tables(mrt, false);
+ mroute_clean_tables(mrt, MRT6_FLUSH_VIFS | MRT6_FLUSH_MFC);
err = 0;
break;
}
@@ -1703,6 +1711,20 @@ int ip6_mroute_setsockopt(struct sock *sk, int optname, char __user *optval, uns
rtnl_unlock();
return ret;
+ case MRT6_FLUSH:
+ {
+ int flags;
+
+ if (optlen != sizeof(flags))
+ return -EINVAL;
+ if (get_user(flags, (int __user *)optval))
+ return -EFAULT;
+ rtnl_lock();
+ mroute_clean_tables(mrt, flags);
+ rtnl_unlock();
+ return 0;
+ }
+
/*
* Control PIM assert (to activate pim will activate assert)
*/
--
2.20.1
^ permalink raw reply related
* [PATCH net-next v3] ipmr: ip6mr: Create new sockopt to clear mfc cache or vifs
From: Callum Sinclair @ 2019-02-11 3:54 UTC (permalink / raw)
To: davem, kuznet, yoshfuji, nikolay, netdev, linux-kernel
Cc: nicolas.dichtel, Callum Sinclair
Created a way to clear the multicast forwarding cache on a socket
without having to either remove the entries manually using the delete
entry socket option or destroy and recreate the multicast socket.
Calling the socket option MRT_FLUSH will allow any combination of the
four flag options to be cleared.
MRT_FLUSH_MFC will clear all non static mfc entries
MRT_FLUSH_MFC_STATIC will clear all static mfc entries
MRT_FLUSH_VIFS will clear all non static interfaces
MRT_FLUSH_VIFS_STATIC will clear all static interfaces.
Callum Sinclair (1):
ipmr: ip6mr: Create new sockopt to clear mfc cache or vifs
include/uapi/linux/mroute.h | 9 ++++-
include/uapi/linux/mroute6.h | 9 ++++-
net/ipv4/ipmr.c | 73 ++++++++++++++++++++-------------
net/ipv6/ip6mr.c | 78 +++++++++++++++++++++++-------------
4 files changed, 112 insertions(+), 57 deletions(-)
--
2.20.1
^ permalink raw reply
* Re: [PATCH bpf] bpf: Fix narrow load on a bpf_sock returned from sk_lookup()
From: Alexei Starovoitov @ 2019-02-11 3:54 UTC (permalink / raw)
To: Martin Lau
Cc: netdev@vger.kernel.org, Alexei Starovoitov, Daniel Borkmann,
Kernel Team, Joe Stringer
In-Reply-To: <20190210071513.o56emdqcb23xtng3@kafai-mbp.dhcp.thefacebook.com>
On Sun, Feb 10, 2019 at 07:15:17AM +0000, Martin Lau wrote:
> > > Fixes: c64b7983288e ("bpf: Add PTR_TO_SOCKET verifier type")
> > > Cc: Joe Stringer <joe@wand.net.nz>
> > > Signed-off-by: Martin KaFai Lau <kafai@fb.com>
> >
> > Applied to bpf tree.
> Thanks!
>
> >
> > Martin, if your is_fullsock work depends on it, I can apply the fix
> > to bpf-next as well. Just let me know.
> Yes, the is_fullsock work depends on it.
> I should have mentioned it in this commit log.
Ok. I've pushed it to bpf-next as well.
Last time we discusses this scenario at netconf and agreed that git should
do the right thing, since commit is the same.
I think this is a case where I think it makes sense to give it a shot.
If we get issues during pulls/merges it will be a lesson to avoid
such things in the future, but if we don't try it we won't know.
So applied.
^ permalink raw reply
* linux-next: manual merge of the phy-next tree with the net-next tree
From: Stephen Rothwell @ 2019-02-11 3:42 UTC (permalink / raw)
To: Kishon Vijay Abraham I, David Miller, Networking
Cc: Linux Next Mailing List, Linux Kernel Mailing List, Russell King,
Miquel Raynal, Igal Liberman, Evan Wang, Grzegorz Jaszczyk
[-- Attachment #1: Type: text/plain, Size: 2998 bytes --]
Hi all,
Today's linux-next merge of the phy-next tree got conflicts in:
drivers/phy/marvell/Kconfig
drivers/phy/marvell/Makefile
between commit:
14dc100b4411 ("phy: armada38x: add common phy support")
from the net-next tree and commit:
9695375a3f4a ("phy: add A3700 COMPHY support")
cc8b7a0ae866 ("phy: add A3700 UTMI PHY driver")
from the phy-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/phy/marvell/Kconfig
index 224ea4e6a46d,b8e9dd38ad0d..000000000000
--- a/drivers/phy/marvell/Kconfig
+++ b/drivers/phy/marvell/Kconfig
@@@ -21,16 -21,27 +21,37 @@@ config PHY_BERLIN_US
help
Enable this to support the USB PHY on Marvell Berlin SoCs.
+ config PHY_MVEBU_A3700_COMPHY
+ tristate "Marvell A3700 comphy driver"
+ depends on ARCH_MVEBU || COMPILE_TEST
+ depends on OF
+ depends on HAVE_ARM_SMCCC
+ default y
+ select GENERIC_PHY
+ help
+ This driver allows to control the comphy, a hardware block providing
+ shared serdes PHYs on Marvell Armada 3700. Its serdes lanes can be
+ used by various controllers: Ethernet, SATA, USB3, PCIe.
+
+ config PHY_MVEBU_A3700_UTMI
+ tristate "Marvell A3700 UTMI driver"
+ depends on ARCH_MVEBU || COMPILE_TEST
+ depends on OF
+ default y
+ select GENERIC_PHY
+ help
+ Enable this to support Marvell A3700 UTMI PHY driver.
+
+config PHY_MVEBU_A38X_COMPHY
+ tristate "Marvell Armada 38x comphy driver"
+ depends on ARCH_MVEBU || COMPILE_TEST
+ depends on OF
+ select GENERIC_PHY
+ help
+ This driver allows to control the comphy, an hardware block providing
+ shared serdes PHYs on Marvell Armada 38x. Its serdes lanes can be
+ used by various controllers (Ethernet, sata, usb, PCIe...).
+
config PHY_MVEBU_CP110_COMPHY
tristate "Marvell CP110 comphy driver"
depends on ARCH_MVEBU || COMPILE_TEST
diff --cc drivers/phy/marvell/Makefile
index 59b6c03ef756,82f291cf59ee..000000000000
--- a/drivers/phy/marvell/Makefile
+++ b/drivers/phy/marvell/Makefile
@@@ -2,7 -2,8 +2,9 @@@
obj-$(CONFIG_ARMADA375_USBCLUSTER_PHY) += phy-armada375-usb2.o
obj-$(CONFIG_PHY_BERLIN_SATA) += phy-berlin-sata.o
obj-$(CONFIG_PHY_BERLIN_USB) += phy-berlin-usb.o
+ obj-$(CONFIG_PHY_MVEBU_A3700_COMPHY) += phy-mvebu-a3700-comphy.o
+ obj-$(CONFIG_PHY_MVEBU_A3700_UTMI) += phy-mvebu-a3700-utmi.o
+obj-$(CONFIG_PHY_MVEBU_A38X_COMPHY) += phy-armada38x-comphy.o
obj-$(CONFIG_PHY_MVEBU_CP110_COMPHY) += phy-mvebu-cp110-comphy.o
obj-$(CONFIG_PHY_MVEBU_SATA) += phy-mvebu-sata.o
obj-$(CONFIG_PHY_PXA_28NM_HSIC) += phy-pxa-28nm-hsic.o
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH net-next v2 3/5] devlink: add a generic board.manufacture version name
From: Jakub Kicinski @ 2019-02-11 3:35 UTC (permalink / raw)
To: davem, jiri; +Cc: netdev, oss-drivers, Jakub Kicinski
In-Reply-To: <20190211033531.12928-1-jakub.kicinski@netronome.com>
At Jiri's suggestion add a generic "board.manufacture"
version identifier.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
---
Documentation/networking/devlink-info-versions.rst | 5 +++++
include/net/devlink.h | 2 ++
2 files changed, 7 insertions(+)
diff --git a/Documentation/networking/devlink-info-versions.rst b/Documentation/networking/devlink-info-versions.rst
index 7d4ecf6b6f34..c79ad8593383 100644
--- a/Documentation/networking/devlink-info-versions.rst
+++ b/Documentation/networking/devlink-info-versions.rst
@@ -14,6 +14,11 @@ board.rev
Board design revision.
+board.manufacture
+=================
+
+An identifier of the company or the facility which produced the part.
+
fw.mgmt
=======
diff --git a/include/net/devlink.h b/include/net/devlink.h
index 2b384a38911b..07660fe4c0e3 100644
--- a/include/net/devlink.h
+++ b/include/net/devlink.h
@@ -435,6 +435,8 @@ enum devlink_param_wol_types {
#define DEVLINK_INFO_VERSION_GENERIC_BOARD_ID "board.id"
/* Revision of board design */
#define DEVLINK_INFO_VERSION_GENERIC_BOARD_REV "board.rev"
+/* Maker of the board */
+#define DEVLINK_INFO_VERSION_GENERIC_BOARD_MANUFACTURE "board.manufacture"
/* Control processor FW version */
#define DEVLINK_INFO_VERSION_GENERIC_FW_MGMT "fw.mgmt"
--
2.19.2
^ permalink raw reply related
* [PATCH net-next v2 4/5] nfp: devlink: use the generic manufacture identifier instead of vendor
From: Jakub Kicinski @ 2019-02-11 3:35 UTC (permalink / raw)
To: davem, jiri; +Cc: netdev, oss-drivers, Jakub Kicinski
In-Reply-To: <20190211033531.12928-1-jakub.kicinski@netronome.com>
Vendor may sound ambiguous, let's rename the fab string to
"board.manufacture" (which was just added as a generic identifier).
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
---
drivers/net/ethernet/netronome/nfp/nfp_devlink.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/netronome/nfp/nfp_devlink.c b/drivers/net/ethernet/netronome/nfp/nfp_devlink.c
index dddbb0575be9..bf4e124dbdd2 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_devlink.c
+++ b/drivers/net/ethernet/netronome/nfp/nfp_devlink.c
@@ -178,7 +178,7 @@ static const struct nfp_devlink_versions_simple {
} nfp_devlink_versions_hwinfo[] = {
{ DEVLINK_INFO_VERSION_GENERIC_BOARD_ID, "assembly.partno", },
{ DEVLINK_INFO_VERSION_GENERIC_BOARD_REV, "assembly.revision", },
- { "board.vendor", /* fab */ "assembly.vendor", },
+ { DEVLINK_INFO_VERSION_GENERIC_BOARD_MANUFACTURE, "assembly.vendor", },
{ "board.model", /* code name */ "assembly.model", },
};
--
2.19.2
^ permalink raw reply related
* [PATCH net-next v2 5/5] nfp: devlink: include vendor/product info in serial number
From: Jakub Kicinski @ 2019-02-11 3:35 UTC (permalink / raw)
To: davem, jiri; +Cc: netdev, oss-drivers, Jakub Kicinski
In-Reply-To: <20190211033531.12928-1-jakub.kicinski@netronome.com>
The manufacturing team requests we include vendor and product
in the serial number field, as the serial number itself is not
unique across manufacturing facilities and products.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
---
.../net/ethernet/netronome/nfp/nfp_devlink.c | 21 ++++++++++++++++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/netronome/nfp/nfp_devlink.c b/drivers/net/ethernet/netronome/nfp/nfp_devlink.c
index bf4e124dbdd2..080a301f379e 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_devlink.c
+++ b/drivers/net/ethernet/netronome/nfp/nfp_devlink.c
@@ -258,18 +258,33 @@ nfp_devlink_info_get(struct devlink *devlink, struct devlink_info_req *req,
struct netlink_ext_ack *extack)
{
struct nfp_pf *pf = devlink_priv(devlink);
+ const char *sn, *vendor, *part;
struct nfp_nsp *nsp;
char *buf = NULL;
- const char *sn;
int err;
err = devlink_info_driver_name_put(req, "nfp");
if (err)
return err;
+ vendor = nfp_hwinfo_lookup(pf->hwinfo, "assembly.vendor");
+ part = nfp_hwinfo_lookup(pf->hwinfo, "assembly.partno");
sn = nfp_hwinfo_lookup(pf->hwinfo, "assembly.serial");
- if (sn) {
- err = devlink_info_serial_number_put(req, sn);
+ if (vendor && part && sn) {
+ char *buf;
+
+ buf = kmalloc(strlen(vendor) + strlen(part) + strlen(sn) + 1,
+ GFP_KERNEL);
+ if (!buf)
+ return -ENOMEM;
+
+ buf[0] = '\0';
+ strcat(buf, vendor);
+ strcat(buf, part);
+ strcat(buf, sn);
+
+ err = devlink_info_serial_number_put(req, buf);
+ kfree(buf);
if (err)
return err;
}
--
2.19.2
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox