* Re: [PATCH net] net: gso: Fix skb_segment splat when splitting gso_size mangled skb having linear-headed frag_list
From: Shmulik Ladkani @ 2019-09-06 15:37 UTC (permalink / raw)
To: Willem de Bruijn, Eric Dumazet, Alexander Duyck
Cc: Daniel Borkmann, eyal, netdev, Shmulik Ladkani
In-Reply-To: <CAF=yD-JB6TMQuyaxzLX8=9CZZF+Zk5EmniSkx_F81bVc87XqJw@mail.gmail.com>
On Fri, 6 Sep 2019 10:49:55 -0400
Willem de Bruijn <willemdebruijn.kernel@gmail.com> wrote:
> But I wonder whether it is a given that head_skb has headlen.
This is what I observed for GRO packets that do have headlen frag_list
members: the 'head_skb' itself had a headlen too, and its head was
built using the original gso_size (similar to the frag_list members).
Maybe Eric can comment better.
> Btw, it seems slightly odd to me tot test head_frag before testing
> headlen in the v2 patch.
Requested by Alexander. I'm fine either way.
Thanks
Shmulik
^ permalink raw reply
* Re: [PATCH net] net: gso: Fix skb_segment splat when splitting gso_size mangled skb having linear-headed frag_list
From: Alexander Duyck @ 2019-09-06 15:42 UTC (permalink / raw)
To: Shmulik Ladkani
Cc: Willem de Bruijn, Eric Dumazet, Daniel Borkmann, eyal, netdev,
Shmulik Ladkani
In-Reply-To: <20190906183707.3eaacd79@pixies>
On Fri, Sep 6, 2019 at 8:37 AM Shmulik Ladkani <shmulik@metanetworks.com> wrote:
>
> On Fri, 6 Sep 2019 10:49:55 -0400
> Willem de Bruijn <willemdebruijn.kernel@gmail.com> wrote:
>
> > But I wonder whether it is a given that head_skb has headlen.
>
> This is what I observed for GRO packets that do have headlen frag_list
> members: the 'head_skb' itself had a headlen too, and its head was
> built using the original gso_size (similar to the frag_list members).
>
> Maybe Eric can comment better.
>
> > Btw, it seems slightly odd to me tot test head_frag before testing
> > headlen in the v2 patch.
>
> Requested by Alexander. I'm fine either way.
Yeah, my thought on that was "do we care about the length if the data
is stored in a head_frag?". I suppose you could flip the logic and
make it "do we care about it being a head_frag if there is no data
there?". The reason I had suggested the head_frag test first was
because it was a single test bit whereas the length requires reading
two fields and doing a comparison.
For either ordering it is fine by me. So if we need to feel free to
swap those two tests for a v3.
Reviewed-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
^ permalink raw reply
* Re: [PATCH bpf-next v10 2/4] bpf: new helper to obtain namespace data from current task New bpf helper bpf_get_current_pidns_info.
From: Al Viro @ 2019-09-06 15:46 UTC (permalink / raw)
To: Carlos Neira; +Cc: netdev, yhs, ebiederm, brouer, bpf
In-Reply-To: <20190906152435.GW1131@ZenIV.linux.org.uk>
On Fri, Sep 06, 2019 at 04:24:35PM +0100, Al Viro wrote:
> > + tmp = kmalloc(fnamesize, GFP_ATOMIC);
> > + if (unlikely(!tmp)) {
> > + __putname(fname);
> > + ret = -ENOMEM;
> > + goto clear;
> > + }
> > +
> > + tmp->name = (char *)fname;
> > + fname = tmp;
> > + len = strlen(pidns_path) + 1;
> > + memcpy((char *)fname->name, pidns_path, len);
> > + fname->uptr = NULL;
> > + fname->aname = NULL;
> > + fname->refcnt = 1;
> > +
> > + ret = filename_lookup(AT_FDCWD, fname, 0, &kp, NULL);
> > + if (ret)
> > + goto clear;
>
> Where do I begin?
> * getname_kernel() is there for purpose
> * so's kern_path(), damnit
Oh, and filename_lookup() *CAN* sleep, obviously. So that
GFP_ATOMIC above is completely pointless.
> > +
> > + inode = d_backing_inode(kp.dentry);
> > + pidns_info->dev = (u32)inode->i_rdev;
Why are plaing with device number, anyway? And why would it
be anything other than 0?
^ permalink raw reply
* Re: [PATCH net-next,v3 0/4] flow_offload: update mangle action representation
From: Pablo Neira Ayuso @ 2019-09-06 15:58 UTC (permalink / raw)
To: Edward Cree
Cc: netfilter-devel, davem, netdev, jakub.kicinski, jiri, saeedm,
vishal, vladbu
In-Reply-To: <be6eee6b-9d58-f0f7-571b-7e473612e2b3@solarflare.com>
Hi Edward,
On Fri, Sep 06, 2019 at 04:13:17PM +0100, Edward Cree wrote:
> On 06/09/2019 15:50, Pablo Neira Ayuso wrote:
> > On Fri, Sep 06, 2019 at 02:37:16PM +0100, Edward Cree wrote:
[...]
> >> So an IPv6 address mangle only comes as a single action if it's from
> >> netfilter, not if it's coming from TC pedit.
> > Driver gets one single action from tc/netfilter (and potentially
> > ethtool if it would support for this), it comes as a single action
> > from both subsystems:
> >
> > front-end -----> flow_rule API -----> drivers
> >
> > Front-end need to translate their representation to this
> > FLOW_ACTION_MANGLE layout.
> >
> > By front-end, I refer to ethtool/netfilter/tc.
>
> In your patch, flow_action_mangle() looks only at the offset and type
> (add vs. set) of each pedit, coalesces them if compatible (so, unless
> I'm misreading the code, it _will_ coalesce adjacent pedits to
> contiguous fields like UDP sport & dport, unlike what you said),
> because it doesn't know whether two contiguous pedits are part of the
> same field or not (it doesn't have any knowledge of 'fields' at all).
In tc pedit ex, those are _indeed_ two separated actions:
* One to mangle UDP sport.
* One to mangle UDP dport.
They are _not_ one as you describe above.
The coalesce routine I made does _not_ coalesce fields in two
different actions.
> And for you to change that, while still coalescing IPv6 pedits, you
> would need flow_action_mangle() to know what fields each pedit is in.
In the particular case of IPv6 address, 'tc pedit ex' generates one
single action with 4 nkeys. So this is:
* One action to mangle four 32-bits words (the number of words in tc
pedit is stored in the nkeys field).
The coalesce routine I made in this case merges the four 32-bits words
into one single action.
[...]
> >> Yes, but we don't add code/features to the kernel based on what we
> >> *could* use it for later
> > This is already useful: Look at the cxgb driver in particular, it's
> > way easier to read.
>
> Have you tested it? Again, I might be misreading, but it looks like
> your flow_action_mangle() *will* coalesce sport & dport, which it
> appears will break that cxgb code.
Because sport and dport are not place in the same action by tc pedit
ex, _that cannot happen_.
> > Other existing drivers do not need to do things like:
> >
> > case round_down(offsetof(struct iphdr, tos), 4):
> >
> > and the play with masks to infer if the user wants to mangle the TOS
> > field, they can just do:
> >
> > case offsetof(struct iphdr, tos):
> >
> > which is way more natural representation.
>
> Proper thing to do is have helper functions available to drivers to test
> the pedit, and not just switch on the offset. Why do I say that?
>
> Well, consider a pedit on UDP dport, with mask 0x00ff (network endian).
> Now as a u32 pedit that's 0x000000ff offset 0, so field-blind offset
> calculation (ffs in flow_action_mangle_entry()) will turn that into
> offset 3 mask 0xff. Now driver does
> switch(offset) { /* 3 */
> case offsetof(struct udphdr, dest): /* 2 */
> /* Whoops, we never get here! */
> }
>
> Do you see the problem?
This scenario you describe cannot _work_ right now, with the existing
code. Without my patchset, this scenario you describe does _not_ work,
The drivers in the tree need a mask of 0xffff to infer that this is
UDP dport.
The 'tc pedit ex' infrastructure does not allow for the scenario that
you describe above.
No driver in the tree allow for what you describe already.
^ permalink raw reply
* Re: [PATCH bpf-next v10 2/4] bpf: new helper to obtain namespace data from current task New bpf helper bpf_get_current_pidns_info.
From: Al Viro @ 2019-09-06 16:00 UTC (permalink / raw)
To: Carlos Neira; +Cc: netdev, yhs, ebiederm, brouer, bpf
In-Reply-To: <20190906154647.GA19707@ZenIV.linux.org.uk>
On Fri, Sep 06, 2019 at 04:46:47PM +0100, Al Viro wrote:
> > Where do I begin?
> > * getname_kernel() is there for purpose
> > * so's kern_path(), damnit
>
> Oh, and filename_lookup() *CAN* sleep, obviously. So that
> GFP_ATOMIC above is completely pointless.
>
> > > +
> > > + inode = d_backing_inode(kp.dentry);
> > > + pidns_info->dev = (u32)inode->i_rdev;
In the original variant of patchset it used to be ->i_sb->s_dev,
which is also bloody strange - you are not asking filename_lookup()
to follow symlinks, so you'd get that of whatever filesystem
/proc/self/ns resides on.
->i_rdev use makes no sense whatsoever - it's a symlink and
neither it nor its target are device nodes; ->i_rdev will be
left zero for both.
What data are you really trying to get there?
^ permalink raw reply
* [net-next 00/11] nfp: implement firmware loading policy
From: Simon Horman @ 2019-09-06 16:00 UTC (permalink / raw)
To: David Miller
Cc: Jakub Kicinski, netdev, oss-drivers, Dirk van der Merwe,
Simon Horman
Hi Dave,
I am handling maintenance of the nfp diver in Jakub's absence while he is
on vacation this week and next, and I am sending this patchset in that
capacity.
Regarding the patches, Dirk says:
This series adds configuration capabilities to the firmware loading policy of
the NFP driver.
NFP firmware loading is controlled via three HWinfo keys which can be set per
device: 'abi_drv_reset', 'abi_drv_load_ifc' and 'app_fw_from_flash'.
Refer to patch #11 for more detail on how these control the firmware loading.
In order to configure the full extend of FW loading policy, a new devlink
parameter has been introduced, 'reset_dev_on_drv_probe', which controls if the
driver should reset the device when it's probed. This, inconjunction with the
existing 'fw_load_policy' (extended to include a 'disk' option) provides the
means to tweak the NFP HWinfo keys as required by users.
Patches 1 and 2 adds the devlink modifications and patches 3 through 9 adds the
support into the NFP driver. Furthermore, the last 2 patches are documentation
only.
Dirk van der Merwe (11):
devlink: extend 'fw_load_policy' values
devlink: add 'reset_dev_on_drv_probe' param
nfp: nsp: add support for fw_loaded command
nfp: nsp: add support for optional hwinfo lookup
nfp: nsp: add support for hwinfo set operation
nfp: honor FW reset and loading policies
nfp: add devlink param infrastructure
nfp: devlink: add 'fw_load_policy' support
nfp: devlink: add 'reset_dev_on_drv_probe' support
kdoc: fix nfp_fw_load documentation
Documentation: nfp: add nfp driver specific notes
.../networking/device_drivers/netronome/nfp.rst | 133 +++++++++++
Documentation/networking/devlink-params-nfp.txt | 5 +
Documentation/networking/devlink-params.txt | 16 ++
drivers/net/ethernet/netronome/nfp/Makefile | 1 +
drivers/net/ethernet/netronome/nfp/devlink_param.c | 253 +++++++++++++++++++++
drivers/net/ethernet/netronome/nfp/nfp_main.c | 141 +++++++++---
drivers/net/ethernet/netronome/nfp/nfp_main.h | 5 +
drivers/net/ethernet/netronome/nfp/nfp_net_main.c | 7 +
.../net/ethernet/netronome/nfp/nfpcore/nfp_nsp.c | 77 ++++++-
.../net/ethernet/netronome/nfp/nfpcore/nfp_nsp.h | 29 +++
include/net/devlink.h | 4 +
include/uapi/linux/devlink.h | 8 +
net/core/devlink.c | 5 +
13 files changed, 654 insertions(+), 30 deletions(-)
create mode 100644 Documentation/networking/device_drivers/netronome/nfp.rst
create mode 100644 Documentation/networking/devlink-params-nfp.txt
create mode 100644 drivers/net/ethernet/netronome/nfp/devlink_param.c
--
2.11.0
^ permalink raw reply
* [net-next 01/11] devlink: extend 'fw_load_policy' values
From: Simon Horman @ 2019-09-06 16:00 UTC (permalink / raw)
To: David Miller
Cc: Jakub Kicinski, netdev, oss-drivers, Dirk van der Merwe,
Simon Horman
In-Reply-To: <20190906160101.14866-1-simon.horman@netronome.com>
From: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
Add the 'disk' value to the generic 'fw_load_policy' devlink parameter.
This value indicates that firmware should always be loaded from disk
only.
Signed-off-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
Signed-off-by: Simon Horman <simon.horman@netronome.com>
---
Documentation/networking/devlink-params.txt | 2 ++
include/uapi/linux/devlink.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/Documentation/networking/devlink-params.txt b/Documentation/networking/devlink-params.txt
index 2d26434ddcf8..fadb5436188d 100644
--- a/Documentation/networking/devlink-params.txt
+++ b/Documentation/networking/devlink-params.txt
@@ -48,4 +48,6 @@ fw_load_policy [DEVICE, GENERIC]
Load firmware version preferred by the driver.
* DEVLINK_PARAM_FW_LOAD_POLICY_VALUE_FLASH (1)
Load firmware currently stored in flash.
+ * DEVLINK_PARAM_FW_LOAD_POLICY_VALUE_DISK (2)
+ Load firmware currently available on host's disk.
Type: u8
diff --git a/include/uapi/linux/devlink.h b/include/uapi/linux/devlink.h
index 546e75dd74ac..c25cc29a6647 100644
--- a/include/uapi/linux/devlink.h
+++ b/include/uapi/linux/devlink.h
@@ -202,6 +202,7 @@ enum devlink_param_cmode {
enum devlink_param_fw_load_policy_value {
DEVLINK_PARAM_FW_LOAD_POLICY_VALUE_DRIVER,
DEVLINK_PARAM_FW_LOAD_POLICY_VALUE_FLASH,
+ DEVLINK_PARAM_FW_LOAD_POLICY_VALUE_DISK,
};
enum {
--
2.11.0
^ permalink raw reply related
* [net-next 02/11] devlink: add 'reset_dev_on_drv_probe' param
From: Simon Horman @ 2019-09-06 16:00 UTC (permalink / raw)
To: David Miller
Cc: Jakub Kicinski, netdev, oss-drivers, Dirk van der Merwe,
Simon Horman
In-Reply-To: <20190906160101.14866-1-simon.horman@netronome.com>
From: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
Add the 'reset_dev_on_drv_probe' devlink parameter, controlling the
device reset policy on driver probe.
This parameter is useful in conjunction with the existing
'fw_load_policy' parameter.
Signed-off-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
Signed-off-by: Simon Horman <simon.horman@netronome.com>
---
Documentation/networking/devlink-params.txt | 14 ++++++++++++++
include/net/devlink.h | 4 ++++
include/uapi/linux/devlink.h | 7 +++++++
net/core/devlink.c | 5 +++++
4 files changed, 30 insertions(+)
diff --git a/Documentation/networking/devlink-params.txt b/Documentation/networking/devlink-params.txt
index fadb5436188d..f9e30d686243 100644
--- a/Documentation/networking/devlink-params.txt
+++ b/Documentation/networking/devlink-params.txt
@@ -51,3 +51,17 @@ fw_load_policy [DEVICE, GENERIC]
* DEVLINK_PARAM_FW_LOAD_POLICY_VALUE_DISK (2)
Load firmware currently available on host's disk.
Type: u8
+
+reset_dev_on_drv_probe [DEVICE, GENERIC]
+ Controls the device's reset policy on driver probe.
+ Valid values:
+ * DEVLINK_PARAM_RESET_DEV_VALUE_UNKNOWN (0)
+ Unknown or invalid value.
+ * DEVLINK_PARAM_RESET_DEV_VALUE_ALWAYS (1)
+ Always reset device on driver probe.
+ * DEVLINK_PARAM_RESET_DEV_VALUE_NEVER (2)
+ Never reset device on driver probe.
+ * DEVLINK_PARAM_RESET_DEV_VALUE_DISK (3)
+ Reset only if device firmware can be found in the
+ filesystem.
+ Type: u8
diff --git a/include/net/devlink.h b/include/net/devlink.h
index 460bc629d1a4..d880de5b8d3a 100644
--- a/include/net/devlink.h
+++ b/include/net/devlink.h
@@ -398,6 +398,7 @@ enum devlink_param_generic_id {
DEVLINK_PARAM_GENERIC_ID_MSIX_VEC_PER_PF_MAX,
DEVLINK_PARAM_GENERIC_ID_MSIX_VEC_PER_PF_MIN,
DEVLINK_PARAM_GENERIC_ID_FW_LOAD_POLICY,
+ DEVLINK_PARAM_GENERIC_ID_RESET_DEV,
/* add new param generic ids above here*/
__DEVLINK_PARAM_GENERIC_ID_MAX,
@@ -428,6 +429,9 @@ enum devlink_param_generic_id {
#define DEVLINK_PARAM_GENERIC_FW_LOAD_POLICY_NAME "fw_load_policy"
#define DEVLINK_PARAM_GENERIC_FW_LOAD_POLICY_TYPE DEVLINK_PARAM_TYPE_U8
+#define DEVLINK_PARAM_GENERIC_RESET_DEV_NAME "reset_dev_on_drv_probe"
+#define DEVLINK_PARAM_GENERIC_RESET_DEV_TYPE DEVLINK_PARAM_TYPE_U8
+
#define DEVLINK_PARAM_GENERIC(_id, _cmodes, _get, _set, _validate) \
{ \
.id = DEVLINK_PARAM_GENERIC_ID_##_id, \
diff --git a/include/uapi/linux/devlink.h b/include/uapi/linux/devlink.h
index c25cc29a6647..3172d1b3329f 100644
--- a/include/uapi/linux/devlink.h
+++ b/include/uapi/linux/devlink.h
@@ -205,6 +205,13 @@ enum devlink_param_fw_load_policy_value {
DEVLINK_PARAM_FW_LOAD_POLICY_VALUE_DISK,
};
+enum devlink_param_reset_dev_value {
+ DEVLINK_PARAM_RESET_DEV_VALUE_UNKNOWN,
+ DEVLINK_PARAM_RESET_DEV_VALUE_ALWAYS,
+ DEVLINK_PARAM_RESET_DEV_VALUE_NEVER,
+ DEVLINK_PARAM_RESET_DEV_VALUE_DISK,
+};
+
enum {
DEVLINK_ATTR_STATS_RX_PACKETS, /* u64 */
DEVLINK_ATTR_STATS_RX_BYTES, /* u64 */
diff --git a/net/core/devlink.c b/net/core/devlink.c
index 6e52d639dac6..e8bc96f104a7 100644
--- a/net/core/devlink.c
+++ b/net/core/devlink.c
@@ -2852,6 +2852,11 @@ static const struct devlink_param devlink_param_generic[] = {
.name = DEVLINK_PARAM_GENERIC_FW_LOAD_POLICY_NAME,
.type = DEVLINK_PARAM_GENERIC_FW_LOAD_POLICY_TYPE,
},
+ {
+ .id = DEVLINK_PARAM_GENERIC_ID_RESET_DEV,
+ .name = DEVLINK_PARAM_GENERIC_RESET_DEV_NAME,
+ .type = DEVLINK_PARAM_GENERIC_RESET_DEV_TYPE,
+ },
};
static int devlink_param_generic_verify(const struct devlink_param *param)
--
2.11.0
^ permalink raw reply related
* [net-next 04/11] nfp: nsp: add support for optional hwinfo lookup
From: Simon Horman @ 2019-09-06 16:00 UTC (permalink / raw)
To: David Miller
Cc: Jakub Kicinski, netdev, oss-drivers, Dirk van der Merwe,
Simon Horman
In-Reply-To: <20190906160101.14866-1-simon.horman@netronome.com>
From: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
There are cases where we want to read a hwinfo entry from the NFP, and
if it doesn't exist, use a default value instead.
To support this, we must silence warning/error messages when the hwinfo
entry doesn't exist since this is a valid use case. The NSP command
structure provides the ability to silence command errors, in which case
the caller should log any command errors appropriately. Protocol errors
are unaffected by this.
Signed-off-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: Simon Horman <simon.horman@netronome.com>
---
.../net/ethernet/netronome/nfp/nfpcore/nfp_nsp.c | 52 ++++++++++++++++++++--
.../net/ethernet/netronome/nfp/nfpcore/nfp_nsp.h | 2 +
2 files changed, 50 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_nsp.c b/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_nsp.c
index b4c5dc5f7404..deee91cbf1b2 100644
--- a/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_nsp.c
+++ b/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_nsp.c
@@ -144,6 +144,8 @@ struct nfp_nsp {
* @option: NFP SP Command Argument
* @buf: NFP SP Buffer Address
* @error_cb: Callback for interpreting option if error occurred
+ * @error_quiet:Don't print command error/warning. Protocol errors are still
+ * logged.
*/
struct nfp_nsp_command_arg {
u16 code;
@@ -152,6 +154,7 @@ struct nfp_nsp_command_arg {
u32 option;
u64 buf;
void (*error_cb)(struct nfp_nsp *state, u32 ret_val);
+ bool error_quiet;
};
/**
@@ -406,8 +409,10 @@ __nfp_nsp_command(struct nfp_nsp *state, const struct nfp_nsp_command_arg *arg)
err = FIELD_GET(NSP_STATUS_RESULT, reg);
if (err) {
- nfp_warn(cpp, "Result (error) code set: %d (%d) command: %d\n",
- -err, (int)ret_val, arg->code);
+ if (!arg->error_quiet)
+ nfp_warn(cpp, "Result (error) code set: %d (%d) command: %d\n",
+ -err, (int)ret_val, arg->code);
+
if (arg->error_cb)
arg->error_cb(state, ret_val);
else
@@ -892,12 +897,14 @@ int nfp_nsp_load_stored_fw(struct nfp_nsp *state)
}
static int
-__nfp_nsp_hwinfo_lookup(struct nfp_nsp *state, void *buf, unsigned int size)
+__nfp_nsp_hwinfo_lookup(struct nfp_nsp *state, void *buf, unsigned int size,
+ bool optional)
{
struct nfp_nsp_command_buf_arg hwinfo_lookup = {
{
.code = SPCODE_HWINFO_LOOKUP,
.option = size,
+ .error_quiet = optional,
},
.in_buf = buf,
.in_size = size,
@@ -914,7 +921,7 @@ int nfp_nsp_hwinfo_lookup(struct nfp_nsp *state, void *buf, unsigned int size)
size = min_t(u32, size, NFP_HWINFO_LOOKUP_SIZE);
- err = __nfp_nsp_hwinfo_lookup(state, buf, size);
+ err = __nfp_nsp_hwinfo_lookup(state, buf, size, false);
if (err)
return err;
@@ -926,6 +933,43 @@ int nfp_nsp_hwinfo_lookup(struct nfp_nsp *state, void *buf, unsigned int size)
return 0;
}
+int nfp_nsp_hwinfo_lookup_optional(struct nfp_nsp *state, void *buf,
+ unsigned int size, const char *default_val)
+{
+ int err;
+
+ /* Ensure that the default value is usable irrespective of whether
+ * it is actually going to be used.
+ */
+ if (strnlen(default_val, size) == size)
+ return -EINVAL;
+
+ if (!nfp_nsp_has_hwinfo_lookup(state)) {
+ strcpy(buf, default_val);
+ return 0;
+ }
+
+ size = min_t(u32, size, NFP_HWINFO_LOOKUP_SIZE);
+
+ err = __nfp_nsp_hwinfo_lookup(state, buf, size, true);
+ if (err) {
+ if (err == -ENOENT) {
+ strcpy(buf, default_val);
+ return 0;
+ }
+
+ nfp_err(state->cpp, "NSP HWinfo lookup failed: %d\n", err);
+ return err;
+ }
+
+ if (strnlen(buf, size) == size) {
+ nfp_err(state->cpp, "NSP HWinfo value not NULL-terminated\n");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
int nfp_nsp_fw_loaded(struct nfp_nsp *state)
{
const struct nfp_nsp_command_arg arg = {
diff --git a/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_nsp.h b/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_nsp.h
index 4ceecff347c6..a8985c2eb1f1 100644
--- a/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_nsp.h
+++ b/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_nsp.h
@@ -22,6 +22,8 @@ int nfp_nsp_write_flash(struct nfp_nsp *state, const struct firmware *fw);
int nfp_nsp_mac_reinit(struct nfp_nsp *state);
int nfp_nsp_load_stored_fw(struct nfp_nsp *state);
int nfp_nsp_hwinfo_lookup(struct nfp_nsp *state, void *buf, unsigned int size);
+int nfp_nsp_hwinfo_lookup_optional(struct nfp_nsp *state, void *buf,
+ unsigned int size, const char *default_val);
int nfp_nsp_fw_loaded(struct nfp_nsp *state);
int nfp_nsp_read_module_eeprom(struct nfp_nsp *state, int eth_index,
unsigned int offset, void *data,
--
2.11.0
^ permalink raw reply related
* [net-next 05/11] nfp: nsp: add support for hwinfo set operation
From: Simon Horman @ 2019-09-06 16:00 UTC (permalink / raw)
To: David Miller
Cc: Jakub Kicinski, netdev, oss-drivers, Dirk van der Merwe,
Simon Horman
In-Reply-To: <20190906160101.14866-1-simon.horman@netronome.com>
From: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
Add support for the NSP HWinfo set command. This closely follows the
HWinfo lookup command.
Signed-off-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: Simon Horman <simon.horman@netronome.com>
---
drivers/net/ethernet/netronome/nfp/nfpcore/nfp_nsp.c | 15 +++++++++++++++
drivers/net/ethernet/netronome/nfp/nfpcore/nfp_nsp.h | 6 ++++++
2 files changed, 21 insertions(+)
diff --git a/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_nsp.c b/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_nsp.c
index deee91cbf1b2..f18e787fa9ad 100644
--- a/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_nsp.c
+++ b/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_nsp.c
@@ -96,6 +96,7 @@ enum nfp_nsp_cmd {
SPCODE_NSP_IDENTIFY = 13, /* Read NSP version */
SPCODE_FW_STORED = 16, /* If no FW loaded, load flash app FW */
SPCODE_HWINFO_LOOKUP = 17, /* Lookup HWinfo with overwrites etc. */
+ SPCODE_HWINFO_SET = 18, /* Set HWinfo entry */
SPCODE_FW_LOADED = 19, /* Is application firmware loaded */
SPCODE_VERSIONS = 21, /* Report FW versions */
SPCODE_READ_SFF_EEPROM = 22, /* Read module EEPROM */
@@ -970,6 +971,20 @@ int nfp_nsp_hwinfo_lookup_optional(struct nfp_nsp *state, void *buf,
return 0;
}
+int nfp_nsp_hwinfo_set(struct nfp_nsp *state, void *buf, unsigned int size)
+{
+ struct nfp_nsp_command_buf_arg hwinfo_set = {
+ {
+ .code = SPCODE_HWINFO_SET,
+ .option = size,
+ },
+ .in_buf = buf,
+ .in_size = size,
+ };
+
+ return nfp_nsp_command_buf(state, &hwinfo_set);
+}
+
int nfp_nsp_fw_loaded(struct nfp_nsp *state)
{
const struct nfp_nsp_command_arg arg = {
diff --git a/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_nsp.h b/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_nsp.h
index a8985c2eb1f1..055fda05880d 100644
--- a/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_nsp.h
+++ b/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_nsp.h
@@ -24,6 +24,7 @@ int nfp_nsp_load_stored_fw(struct nfp_nsp *state);
int nfp_nsp_hwinfo_lookup(struct nfp_nsp *state, void *buf, unsigned int size);
int nfp_nsp_hwinfo_lookup_optional(struct nfp_nsp *state, void *buf,
unsigned int size, const char *default_val);
+int nfp_nsp_hwinfo_set(struct nfp_nsp *state, void *buf, unsigned int size);
int nfp_nsp_fw_loaded(struct nfp_nsp *state);
int nfp_nsp_read_module_eeprom(struct nfp_nsp *state, int eth_index,
unsigned int offset, void *data,
@@ -44,6 +45,11 @@ static inline bool nfp_nsp_has_hwinfo_lookup(struct nfp_nsp *state)
return nfp_nsp_get_abi_ver_minor(state) > 24;
}
+static inline bool nfp_nsp_has_hwinfo_set(struct nfp_nsp *state)
+{
+ return nfp_nsp_get_abi_ver_minor(state) > 25;
+}
+
static inline bool nfp_nsp_has_fw_loaded(struct nfp_nsp *state)
{
return nfp_nsp_get_abi_ver_minor(state) > 25;
--
2.11.0
^ permalink raw reply related
* [net-next 03/11] nfp: nsp: add support for fw_loaded command
From: Simon Horman @ 2019-09-06 16:00 UTC (permalink / raw)
To: David Miller
Cc: Jakub Kicinski, netdev, oss-drivers, Dirk van der Merwe,
Simon Horman
In-Reply-To: <20190906160101.14866-1-simon.horman@netronome.com>
From: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
Add support for the simple command that indicates whether application
firmware is loaded.
Signed-off-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: Simon Horman <simon.horman@netronome.com>
---
drivers/net/ethernet/netronome/nfp/nfpcore/nfp_nsp.c | 10 ++++++++++
drivers/net/ethernet/netronome/nfp/nfpcore/nfp_nsp.h | 6 ++++++
2 files changed, 16 insertions(+)
diff --git a/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_nsp.c b/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_nsp.c
index 9a08623c325d..b4c5dc5f7404 100644
--- a/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_nsp.c
+++ b/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_nsp.c
@@ -96,6 +96,7 @@ enum nfp_nsp_cmd {
SPCODE_NSP_IDENTIFY = 13, /* Read NSP version */
SPCODE_FW_STORED = 16, /* If no FW loaded, load flash app FW */
SPCODE_HWINFO_LOOKUP = 17, /* Lookup HWinfo with overwrites etc. */
+ SPCODE_FW_LOADED = 19, /* Is application firmware loaded */
SPCODE_VERSIONS = 21, /* Report FW versions */
SPCODE_READ_SFF_EEPROM = 22, /* Read module EEPROM */
};
@@ -925,6 +926,15 @@ int nfp_nsp_hwinfo_lookup(struct nfp_nsp *state, void *buf, unsigned int size)
return 0;
}
+int nfp_nsp_fw_loaded(struct nfp_nsp *state)
+{
+ const struct nfp_nsp_command_arg arg = {
+ .code = SPCODE_FW_LOADED,
+ };
+
+ return __nfp_nsp_command(state, &arg);
+}
+
int nfp_nsp_versions(struct nfp_nsp *state, void *buf, unsigned int size)
{
struct nfp_nsp_command_buf_arg versions = {
diff --git a/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_nsp.h b/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_nsp.h
index 22ee6985ee1c..4ceecff347c6 100644
--- a/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_nsp.h
+++ b/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_nsp.h
@@ -22,6 +22,7 @@ int nfp_nsp_write_flash(struct nfp_nsp *state, const struct firmware *fw);
int nfp_nsp_mac_reinit(struct nfp_nsp *state);
int nfp_nsp_load_stored_fw(struct nfp_nsp *state);
int nfp_nsp_hwinfo_lookup(struct nfp_nsp *state, void *buf, unsigned int size);
+int nfp_nsp_fw_loaded(struct nfp_nsp *state);
int nfp_nsp_read_module_eeprom(struct nfp_nsp *state, int eth_index,
unsigned int offset, void *data,
unsigned int len, unsigned int *read_len);
@@ -41,6 +42,11 @@ static inline bool nfp_nsp_has_hwinfo_lookup(struct nfp_nsp *state)
return nfp_nsp_get_abi_ver_minor(state) > 24;
}
+static inline bool nfp_nsp_has_fw_loaded(struct nfp_nsp *state)
+{
+ return nfp_nsp_get_abi_ver_minor(state) > 25;
+}
+
static inline bool nfp_nsp_has_versions(struct nfp_nsp *state)
{
return nfp_nsp_get_abi_ver_minor(state) > 27;
--
2.11.0
^ permalink raw reply related
* [net-next 06/11] nfp: honor FW reset and loading policies
From: Simon Horman @ 2019-09-06 16:00 UTC (permalink / raw)
To: David Miller
Cc: Jakub Kicinski, netdev, oss-drivers, Dirk van der Merwe,
Simon Horman
In-Reply-To: <20190906160101.14866-1-simon.horman@netronome.com>
From: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
The firmware reset and loading policies can be controlled with the
combination of three hwinfo keys, 'abi_drv_reset', 'abi_drv_load_ifc'
and 'app_fw_from_flash'.
'app_fw_from_flash' defines which firmware should take precedence,
'Disk', 'Flash' or the 'Preferred' firmware. When 'Preferred'
is selected, the management firmware makes the decision on which
firmware will be loaded by comparing versions of the flash firmware
and the host supplied firmware.
'abi_drv_reset' defines when the driver should reset the firmware when
the driver is probed, either 'Disk' if firmware was found on disk,
'Always' reset or 'Never' reset. Note that the device is always reset
on driver unload if firmware was loaded when the driver was probed.
'abi_drv_load_ifc' defines a list of PF devices allowed to load FW on
the device.
Furthermore, we limit the cases to where the driver will unload firmware
again when the driver is removed to only when firmware was loaded by the
driver and only if this particular device was the only one that could
have loaded firmware. This is needed to avoid firmware being removed
while in use on multi-host platforms.
Signed-off-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
Signed-off-by: Simon Horman <simon.horman@netronome.com>
---
drivers/net/ethernet/netronome/nfp/nfp_main.c | 139 +++++++++++++++++----
drivers/net/ethernet/netronome/nfp/nfp_main.h | 2 +
.../net/ethernet/netronome/nfp/nfpcore/nfp_nsp.h | 15 +++
3 files changed, 131 insertions(+), 25 deletions(-)
diff --git a/drivers/net/ethernet/netronome/nfp/nfp_main.c b/drivers/net/ethernet/netronome/nfp/nfp_main.c
index 81679647e842..0d8649024505 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_main.c
+++ b/drivers/net/ethernet/netronome/nfp/nfp_main.c
@@ -352,7 +352,7 @@ nfp_net_fw_request(struct pci_dev *pdev, struct nfp_pf *pf, const char *name)
err = request_firmware_direct(&fw, name, &pdev->dev);
nfp_info(pf->cpp, " %s: %s\n",
- name, err ? "not found" : "found, loading...");
+ name, err ? "not found" : "found");
if (err)
return NULL;
@@ -430,6 +430,33 @@ nfp_net_fw_find(struct pci_dev *pdev, struct nfp_pf *pf)
return nfp_net_fw_request(pdev, pf, fw_name);
}
+static int
+nfp_get_fw_policy_value(struct pci_dev *pdev, struct nfp_nsp *nsp,
+ const char *key, const char *default_val, int max_val,
+ int *value)
+{
+ char hwinfo[64];
+ long hi_val;
+ int err;
+
+ snprintf(hwinfo, sizeof(hwinfo), key);
+ err = nfp_nsp_hwinfo_lookup_optional(nsp, hwinfo, sizeof(hwinfo),
+ default_val);
+ if (err)
+ return err;
+
+ err = kstrtol(hwinfo, 0, &hi_val);
+ if (err || hi_val < 0 || hi_val > max_val) {
+ dev_warn(&pdev->dev,
+ "Invalid value '%s' from '%s', ignoring\n",
+ hwinfo, key);
+ err = kstrtol(default_val, 0, &hi_val);
+ }
+
+ *value = hi_val;
+ return err;
+}
+
/**
* nfp_net_fw_load() - Load the firmware image
* @pdev: PCI Device structure
@@ -441,44 +468,106 @@ nfp_net_fw_find(struct pci_dev *pdev, struct nfp_pf *pf)
static int
nfp_fw_load(struct pci_dev *pdev, struct nfp_pf *pf, struct nfp_nsp *nsp)
{
- const struct firmware *fw;
+ bool do_reset, fw_loaded = false;
+ const struct firmware *fw = NULL;
+ int err, reset, policy, ifcs = 0;
+ char *token, *ptr;
+ char hwinfo[64];
u16 interface;
- int err;
+
+ snprintf(hwinfo, sizeof(hwinfo), "abi_drv_load_ifc");
+ err = nfp_nsp_hwinfo_lookup_optional(nsp, hwinfo, sizeof(hwinfo),
+ NFP_NSP_DRV_LOAD_IFC_DEFAULT);
+ if (err)
+ return err;
interface = nfp_cpp_interface(pf->cpp);
- if (NFP_CPP_INTERFACE_UNIT_of(interface) != 0) {
- /* Only Unit 0 should reset or load firmware */
+ ptr = hwinfo;
+ while ((token = strsep(&ptr, ","))) {
+ unsigned long interface_hi;
+
+ err = kstrtoul(token, 0, &interface_hi);
+ if (err) {
+ dev_err(&pdev->dev,
+ "Failed to parse interface '%s': %d\n",
+ token, err);
+ return err;
+ }
+
+ ifcs++;
+ if (interface == interface_hi)
+ break;
+ }
+
+ if (!token) {
dev_info(&pdev->dev, "Firmware will be loaded by partner\n");
return 0;
}
+ err = nfp_get_fw_policy_value(pdev, nsp, "abi_drv_reset",
+ NFP_NSP_DRV_RESET_DEFAULT,
+ NFP_NSP_DRV_RESET_NEVER, &reset);
+ if (err)
+ return err;
+
+ err = nfp_get_fw_policy_value(pdev, nsp, "app_fw_from_flash",
+ NFP_NSP_APP_FW_LOAD_DEFAULT,
+ NFP_NSP_APP_FW_LOAD_PREF, &policy);
+ if (err)
+ return err;
+
fw = nfp_net_fw_find(pdev, pf);
- if (!fw) {
- if (nfp_nsp_has_stored_fw_load(nsp))
- nfp_nsp_load_stored_fw(nsp);
- return 0;
+ do_reset = reset == NFP_NSP_DRV_RESET_ALWAYS ||
+ (fw && reset == NFP_NSP_DRV_RESET_DISK);
+
+ if (do_reset) {
+ dev_info(&pdev->dev, "Soft-resetting the NFP\n");
+ err = nfp_nsp_device_soft_reset(nsp);
+ if (err < 0) {
+ dev_err(&pdev->dev,
+ "Failed to soft reset the NFP: %d\n", err);
+ goto exit_release_fw;
+ }
}
- dev_info(&pdev->dev, "Soft-reset, loading FW image\n");
- err = nfp_nsp_device_soft_reset(nsp);
- if (err < 0) {
- dev_err(&pdev->dev, "Failed to soft reset the NFP: %d\n",
- err);
- goto exit_release_fw;
- }
+ if (fw && policy != NFP_NSP_APP_FW_LOAD_FLASH) {
+ if (nfp_nsp_has_fw_loaded(nsp) && nfp_nsp_fw_loaded(nsp))
+ goto exit_release_fw;
- err = nfp_nsp_load_fw(nsp, fw);
- if (err < 0) {
- dev_err(&pdev->dev, "FW loading failed: %d\n", err);
- goto exit_release_fw;
+ err = nfp_nsp_load_fw(nsp, fw);
+ if (err < 0) {
+ dev_err(&pdev->dev, "FW loading failed: %d\n",
+ err);
+ goto exit_release_fw;
+ }
+ dev_info(&pdev->dev, "Finished loading FW image\n");
+ fw_loaded = true;
+ } else if (policy != NFP_NSP_APP_FW_LOAD_DISK &&
+ nfp_nsp_has_stored_fw_load(nsp)) {
+ /* Don't propagate this error to stick with legacy driver
+ * behavior, failure will be detected later during init.
+ */
+ if (!nfp_nsp_load_stored_fw(nsp))
+ dev_info(&pdev->dev, "Finished loading stored FW image\n");
+
+ /* Don't flag the fw_loaded in this case since other devices
+ * may reuse the firmware when configured this way
+ */
+ } else {
+ dev_warn(&pdev->dev, "Didn't load firmware, please update flash or reconfigure card\n");
}
- dev_info(&pdev->dev, "Finished loading FW image\n");
-
exit_release_fw:
release_firmware(fw);
- return err < 0 ? err : 1;
+ /* We don't want to unload firmware when other devices may still be
+ * dependent on it, which could be the case if there are multiple
+ * devices that could load firmware.
+ */
+ if (fw_loaded && ifcs == 1)
+ pf->unload_fw_on_remove = true;
+
+ return err < 0 ? err : fw_loaded;
}
static void
@@ -704,7 +793,7 @@ static int nfp_pci_probe(struct pci_dev *pdev,
err_fw_unload:
kfree(pf->rtbl);
nfp_mip_close(pf->mip);
- if (pf->fw_loaded)
+ if (pf->unload_fw_on_remove)
nfp_fw_unload(pf);
kfree(pf->eth_tbl);
kfree(pf->nspi);
@@ -744,7 +833,7 @@ static void __nfp_pci_shutdown(struct pci_dev *pdev, bool unload_fw)
vfree(pf->dumpspec);
kfree(pf->rtbl);
nfp_mip_close(pf->mip);
- if (unload_fw && pf->fw_loaded)
+ if (unload_fw && pf->unload_fw_on_remove)
nfp_fw_unload(pf);
destroy_workqueue(pf->wq);
diff --git a/drivers/net/ethernet/netronome/nfp/nfp_main.h b/drivers/net/ethernet/netronome/nfp/nfp_main.h
index b7211f200d22..bd6450b0f23f 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_main.h
+++ b/drivers/net/ethernet/netronome/nfp/nfp_main.h
@@ -64,6 +64,7 @@ struct nfp_dumpspec {
* @limit_vfs: Number of VFs supported by firmware (~0 for PCI limit)
* @num_vfs: Number of SR-IOV VFs enabled
* @fw_loaded: Is the firmware loaded?
+ * @unload_fw_on_remove:Do we need to unload firmware on driver removal?
* @ctrl_vnic: Pointer to the control vNIC if available
* @mip: MIP handle
* @rtbl: RTsym table
@@ -110,6 +111,7 @@ struct nfp_pf {
unsigned int num_vfs;
bool fw_loaded;
+ bool unload_fw_on_remove;
struct nfp_net *ctrl_vnic;
diff --git a/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_nsp.h b/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_nsp.h
index 055fda05880d..1531c1870020 100644
--- a/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_nsp.h
+++ b/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_nsp.h
@@ -102,6 +102,21 @@ enum nfp_eth_fec {
#define NFP_FEC_REED_SOLOMON BIT(NFP_FEC_REED_SOLOMON_BIT)
#define NFP_FEC_DISABLED BIT(NFP_FEC_DISABLED_BIT)
+/* Defines the valid values of the 'abi_drv_reset' hwinfo key */
+#define NFP_NSP_DRV_RESET_DISK 0
+#define NFP_NSP_DRV_RESET_ALWAYS 1
+#define NFP_NSP_DRV_RESET_NEVER 2
+#define NFP_NSP_DRV_RESET_DEFAULT "0"
+
+/* Defines the valid values of the 'app_fw_from_flash' hwinfo key */
+#define NFP_NSP_APP_FW_LOAD_DISK 0
+#define NFP_NSP_APP_FW_LOAD_FLASH 1
+#define NFP_NSP_APP_FW_LOAD_PREF 2
+#define NFP_NSP_APP_FW_LOAD_DEFAULT "2"
+
+/* Define the default value for the 'abi_drv_load_ifc' key */
+#define NFP_NSP_DRV_LOAD_IFC_DEFAULT "0x10ff"
+
/**
* struct nfp_eth_table - ETH table information
* @count: number of table entries
--
2.11.0
^ permalink raw reply related
* [net-next 08/11] nfp: devlink: add 'fw_load_policy' support
From: Simon Horman @ 2019-09-06 16:00 UTC (permalink / raw)
To: David Miller
Cc: Jakub Kicinski, netdev, oss-drivers, Dirk van der Merwe,
Simon Horman
In-Reply-To: <20190906160101.14866-1-simon.horman@netronome.com>
From: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
Add support for the 'fw_load_policy' devlink parameter. The FW load
policy is controlled by the 'app_fw_from_flash' hwinfo key.
Remap the values from devlink to the hwinfo key and back.
Signed-off-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
Signed-off-by: Simon Horman <simon.horman@netronome.com>
---
Documentation/networking/devlink-params-nfp.txt | 2 +
drivers/net/ethernet/netronome/nfp/devlink_param.c | 165 +++++++++++++++++++++
2 files changed, 167 insertions(+)
create mode 100644 Documentation/networking/devlink-params-nfp.txt
diff --git a/Documentation/networking/devlink-params-nfp.txt b/Documentation/networking/devlink-params-nfp.txt
new file mode 100644
index 000000000000..85b1e36f73a8
--- /dev/null
+++ b/Documentation/networking/devlink-params-nfp.txt
@@ -0,0 +1,2 @@
+fw_load_policy [DEVICE, GENERIC]
+ Configuration mode: permanent
diff --git a/drivers/net/ethernet/netronome/nfp/devlink_param.c b/drivers/net/ethernet/netronome/nfp/devlink_param.c
index aece98586e32..d9c74cfba560 100644
--- a/drivers/net/ethernet/netronome/nfp/devlink_param.c
+++ b/drivers/net/ethernet/netronome/nfp/devlink_param.c
@@ -3,10 +3,175 @@
#include <net/devlink.h>
+#include "nfpcore/nfp.h"
#include "nfpcore/nfp_nsp.h"
#include "nfp_main.h"
+/**
+ * struct nfp_devlink_param_u8_arg - Devlink u8 parameter get/set arguments
+ * @hwinfo_name: HWinfo key name
+ * @default_hi_val: Default HWinfo value if HWinfo doesn't exist
+ * @invalid_dl_val: Devlink value to use if HWinfo is unknown/invalid.
+ * -errno if there is no unknown/invalid value available
+ * @hi_to_dl: HWinfo to devlink value mapping
+ * @dl_to_hi: Devlink to hwinfo value mapping
+ * @max_dl_val: Maximum devlink value supported, for validation only
+ * @max_hi_val: Maximum HWinfo value supported, for validation only
+ */
+struct nfp_devlink_param_u8_arg {
+ const char *hwinfo_name;
+ const char *default_hi_val;
+ int invalid_dl_val;
+ u8 hi_to_dl[4];
+ u8 dl_to_hi[4];
+ u8 max_dl_val;
+ u8 max_hi_val;
+};
+
+static const struct nfp_devlink_param_u8_arg nfp_devlink_u8_args[] = {
+ [DEVLINK_PARAM_GENERIC_ID_FW_LOAD_POLICY] = {
+ .hwinfo_name = "app_fw_from_flash",
+ .default_hi_val = NFP_NSP_APP_FW_LOAD_DEFAULT,
+ .invalid_dl_val = -EINVAL,
+ .hi_to_dl = {
+ [NFP_NSP_APP_FW_LOAD_DISK] =
+ DEVLINK_PARAM_FW_LOAD_POLICY_VALUE_DISK,
+ [NFP_NSP_APP_FW_LOAD_FLASH] =
+ DEVLINK_PARAM_FW_LOAD_POLICY_VALUE_FLASH,
+ [NFP_NSP_APP_FW_LOAD_PREF] =
+ DEVLINK_PARAM_FW_LOAD_POLICY_VALUE_DRIVER,
+ },
+ .dl_to_hi = {
+ [DEVLINK_PARAM_FW_LOAD_POLICY_VALUE_DRIVER] =
+ NFP_NSP_APP_FW_LOAD_PREF,
+ [DEVLINK_PARAM_FW_LOAD_POLICY_VALUE_FLASH] =
+ NFP_NSP_APP_FW_LOAD_FLASH,
+ [DEVLINK_PARAM_FW_LOAD_POLICY_VALUE_DISK] =
+ NFP_NSP_APP_FW_LOAD_DISK,
+ },
+ .max_dl_val = DEVLINK_PARAM_FW_LOAD_POLICY_VALUE_DISK,
+ .max_hi_val = NFP_NSP_APP_FW_LOAD_PREF,
+ },
+};
+
+static int
+nfp_devlink_param_u8_get(struct devlink *devlink, u32 id,
+ struct devlink_param_gset_ctx *ctx)
+{
+ const struct nfp_devlink_param_u8_arg *arg;
+ struct nfp_pf *pf = devlink_priv(devlink);
+ struct nfp_nsp *nsp;
+ char hwinfo[32];
+ long value;
+ int err;
+
+ if (id >= ARRAY_SIZE(nfp_devlink_u8_args))
+ return -EOPNOTSUPP;
+
+ arg = &nfp_devlink_u8_args[id];
+
+ nsp = nfp_nsp_open(pf->cpp);
+ if (IS_ERR(nsp)) {
+ err = PTR_ERR(nsp);
+ nfp_warn(pf->cpp, "can't access NSP: %d\n", err);
+ return err;
+ }
+
+ snprintf(hwinfo, sizeof(hwinfo), arg->hwinfo_name);
+ err = nfp_nsp_hwinfo_lookup_optional(nsp, hwinfo, sizeof(hwinfo),
+ arg->default_hi_val);
+ if (err) {
+ nfp_warn(pf->cpp, "HWinfo lookup failed: %d\n", err);
+ goto exit_close_nsp;
+ }
+
+ err = kstrtol(hwinfo, 0, &value);
+ if (err || value < 0 || value > arg->max_hi_val) {
+ nfp_warn(pf->cpp, "HWinfo '%s' value %li invalid\n",
+ arg->hwinfo_name, value);
+
+ if (arg->invalid_dl_val >= 0)
+ ctx->val.vu8 = arg->invalid_dl_val;
+ else
+ err = arg->invalid_dl_val;
+
+ goto exit_close_nsp;
+ }
+
+ ctx->val.vu8 = arg->hi_to_dl[value];
+
+exit_close_nsp:
+ nfp_nsp_close(nsp);
+ return err;
+}
+
+static int
+nfp_devlink_param_u8_set(struct devlink *devlink, u32 id,
+ struct devlink_param_gset_ctx *ctx)
+{
+ const struct nfp_devlink_param_u8_arg *arg;
+ struct nfp_pf *pf = devlink_priv(devlink);
+ struct nfp_nsp *nsp;
+ char hwinfo[32];
+ int err;
+
+ if (id >= ARRAY_SIZE(nfp_devlink_u8_args))
+ return -EOPNOTSUPP;
+
+ arg = &nfp_devlink_u8_args[id];
+
+ nsp = nfp_nsp_open(pf->cpp);
+ if (IS_ERR(nsp)) {
+ err = PTR_ERR(nsp);
+ nfp_warn(pf->cpp, "can't access NSP: %d\n", err);
+ return err;
+ }
+
+ /* Note the value has already been validated. */
+ snprintf(hwinfo, sizeof(hwinfo), "%s=%u",
+ arg->hwinfo_name, arg->dl_to_hi[ctx->val.vu8]);
+ err = nfp_nsp_hwinfo_set(nsp, hwinfo, sizeof(hwinfo));
+ if (err) {
+ nfp_warn(pf->cpp, "HWinfo set failed: %d\n", err);
+ goto exit_close_nsp;
+ }
+
+exit_close_nsp:
+ nfp_nsp_close(nsp);
+ return err;
+}
+
+static int
+nfp_devlink_param_u8_validate(struct devlink *devlink, u32 id,
+ union devlink_param_value val,
+ struct netlink_ext_ack *extack)
+{
+ const struct nfp_devlink_param_u8_arg *arg;
+
+ if (id >= ARRAY_SIZE(nfp_devlink_u8_args))
+ return -EOPNOTSUPP;
+
+ arg = &nfp_devlink_u8_args[id];
+
+ if (val.vu8 > arg->max_dl_val) {
+ NL_SET_ERR_MSG_MOD(extack, "parameter out of range");
+ return -EINVAL;
+ }
+
+ if (val.vu8 == arg->invalid_dl_val) {
+ NL_SET_ERR_MSG_MOD(extack, "unknown/invalid value specified");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static const struct devlink_param nfp_devlink_params[] = {
+ DEVLINK_PARAM_GENERIC(FW_LOAD_POLICY,
+ BIT(DEVLINK_PARAM_CMODE_PERMANENT),
+ nfp_devlink_param_u8_get,
+ nfp_devlink_param_u8_set,
+ nfp_devlink_param_u8_validate),
};
static int nfp_devlink_supports_params(struct nfp_pf *pf)
--
2.11.0
^ permalink raw reply related
* [net-next 11/11] Documentation: nfp: add nfp driver specific notes
From: Simon Horman @ 2019-09-06 16:01 UTC (permalink / raw)
To: David Miller
Cc: Jakub Kicinski, netdev, oss-drivers, Dirk van der Merwe,
Simon Horman
In-Reply-To: <20190906160101.14866-1-simon.horman@netronome.com>
From: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
This adds the initial documentation for the NFP driver specific
documentation.
Right now, only basic information is provided about acquiring firmware
and configuring device firmware loading.
Original driver documentation can be found here:
https://github.com/Netronome/nfp-drv-kmods/blob/master/README.md
Signed-off-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
Signed-off-by: Simon Horman <simon.horman@netronome.com>
---
.../networking/device_drivers/netronome/nfp.rst | 133 +++++++++++++++++++++
1 file changed, 133 insertions(+)
create mode 100644 Documentation/networking/device_drivers/netronome/nfp.rst
diff --git a/Documentation/networking/device_drivers/netronome/nfp.rst b/Documentation/networking/device_drivers/netronome/nfp.rst
new file mode 100644
index 000000000000..6c08ac8b5147
--- /dev/null
+++ b/Documentation/networking/device_drivers/netronome/nfp.rst
@@ -0,0 +1,133 @@
+.. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+
+=============================================
+Netronome Flow Processor (NFP) Kernel Drivers
+=============================================
+
+Copyright (c) 2019, Netronome Systems, Inc.
+
+Contents
+========
+
+- `Overview`_
+- `Acquiring Firmware`_
+
+Overview
+========
+
+This driver supports Netronome's line of Flow Processor devices,
+including the NFP4000, NFP5000, and NFP6000 models, which are also
+incorporated in the company's family of Agilio SmartNICs. The SR-IOV
+physical and virtual functions for these devices are supported by
+the driver.
+
+Acquiring Firmware
+==================
+
+The NFP4000 and NFP6000 devices require application specific firmware
+to function. Application firmware can be located either on the host file system
+or in the device flash (if supported by management firmware).
+
+Firmware files on the host filesystem contain card type (`AMDA-*` string), media
+config etc. They should be placed in `/lib/firmware/netronome` directory to
+load firmware from the host file system.
+
+Firmware for basic NIC operation is available in the upstream
+`linux-firmware.git` repository.
+
+Firmware in NVRAM
+-----------------
+
+Recent versions of management firmware supports loading application
+firmware from flash when the host driver gets probed. The firmware loading
+policy configuration may be used to configure this feature appropriately.
+
+Devlink or ethtool can be used to update the application firmware on the device
+flash by providing the appropriate `nic_AMDA*.nffw` file to the respective
+command. Users need to take care to write the correct firmware image for the
+card and media configuration to flash.
+
+Available storage space in flash depends on the card being used.
+
+Dealing with multiple projects
+------------------------------
+
+NFP hardware is fully programmable therefore there can be different
+firmware images targeting different applications.
+
+When using application firmware from host, we recommend placing
+actual firmware files in application-named subdirectories in
+`/lib/firmware/netronome` and linking the desired files, e.g.::
+
+ $ tree /lib/firmware/netronome/
+ /lib/firmware/netronome/
+ ├── bpf
+ │ ├── nic_AMDA0081-0001_1x40.nffw
+ │ └── nic_AMDA0081-0001_4x10.nffw
+ ├── flower
+ │ ├── nic_AMDA0081-0001_1x40.nffw
+ │ └── nic_AMDA0081-0001_4x10.nffw
+ ├── nic
+ │ ├── nic_AMDA0081-0001_1x40.nffw
+ │ └── nic_AMDA0081-0001_4x10.nffw
+ ├── nic_AMDA0081-0001_1x40.nffw -> bpf/nic_AMDA0081-0001_1x40.nffw
+ └── nic_AMDA0081-0001_4x10.nffw -> bpf/nic_AMDA0081-0001_4x10.nffw
+
+ 3 directories, 8 files
+
+You may need to use hard instead of symbolic links on distributions
+which use old `mkinitrd` command instead of `dracut` (e.g. Ubuntu).
+
+After changing firmware files you may need to regenerate the initramfs
+image. Initramfs contains drivers and firmware files your system may
+need to boot. Refer to the documentation of your distribution to find
+out how to update initramfs. Good indication of stale initramfs
+is system loading wrong driver or firmware on boot, but when driver is
+later reloaded manually everything works correctly.
+
+Selecting firmware per device
+-----------------------------
+
+Most commonly all cards on the system use the same type of firmware.
+If you want to load specific firmware image for a specific card, you
+can use either the PCI bus address or serial number. Driver will print
+which files it's looking for when it recognizes a NFP device::
+
+ nfp: Looking for firmware file in order of priority:
+ nfp: netronome/serial-00-12-34-aa-bb-cc-10-ff.nffw: not found
+ nfp: netronome/pci-0000:02:00.0.nffw: not found
+ nfp: netronome/nic_AMDA0081-0001_1x40.nffw: found, loading...
+
+In this case if file (or link) called *serial-00-12-34-aa-bb-5d-10-ff.nffw*
+or *pci-0000:02:00.0.nffw* is present in `/lib/firmware/netronome` this
+firmware file will take precedence over `nic_AMDA*` files.
+
+Note that `serial-*` and `pci-*` files are **not** automatically included
+in initramfs, you will have to refer to documentation of appropriate tools
+to find out how to include them.
+
+Firmware loading policy
+-----------------------
+
+Firmware loading policy is controlled via three HWinfo parameters
+stored as key value pairs in the device flash:
+
+app_fw_from_flash
+ Defines which firmware should take precedence, 'Disk' (0), 'Flash' (1) or
+ the 'Preferred' (2) firmware. When 'Preferred' is selected, the management
+ firmware makes the decision over which firmware will be loaded by comparing
+ versions of the flash firmware and the host supplied firmware.
+ This variable is configurable using the 'fw_load_policy'
+ devlink parameter.
+
+abi_drv_reset
+ Defines if the driver should reset the firmware when
+ the driver is probed, either 'Disk' (0) if firmware was found on disk,
+ 'Always' (1) reset or 'Never' (2) reset. Note that the device is always
+ reset on driver unload if firmware was loaded when the driver was probed.
+ This variable is configurable using the 'reset_dev_on_drv_probe'
+ devlink parameter.
+
+abi_drv_load_ifc
+ Defines a list of PF devices allowed to load FW on the device.
+ This variable is not currently user configurable.
--
2.11.0
^ permalink raw reply related
* [net-next 07/11] nfp: add devlink param infrastructure
From: Simon Horman @ 2019-09-06 16:00 UTC (permalink / raw)
To: David Miller
Cc: Jakub Kicinski, netdev, oss-drivers, Dirk van der Merwe,
Simon Horman
In-Reply-To: <20190906160101.14866-1-simon.horman@netronome.com>
From: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
Register devlink parameters for driver use. Subsequent patches will add
support for specific parameters.
In order to support devlink parameters, the management firmware needs to
be able to lookup and set hwinfo keys.
Signed-off-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
Signed-off-by: Simon Horman <simon.horman@netronome.com>
---
drivers/net/ethernet/netronome/nfp/Makefile | 1 +
drivers/net/ethernet/netronome/nfp/devlink_param.c | 60 ++++++++++++++++++++++
drivers/net/ethernet/netronome/nfp/nfp_main.h | 3 ++
drivers/net/ethernet/netronome/nfp/nfp_net_main.c | 7 +++
4 files changed, 71 insertions(+)
create mode 100644 drivers/net/ethernet/netronome/nfp/devlink_param.c
diff --git a/drivers/net/ethernet/netronome/nfp/Makefile b/drivers/net/ethernet/netronome/nfp/Makefile
index 2805641965f3..d31772ae511d 100644
--- a/drivers/net/ethernet/netronome/nfp/Makefile
+++ b/drivers/net/ethernet/netronome/nfp/Makefile
@@ -17,6 +17,7 @@ nfp-objs := \
nfpcore/nfp_target.o \
ccm.o \
ccm_mbox.o \
+ devlink_param.o \
nfp_asm.o \
nfp_app.o \
nfp_app_nic.o \
diff --git a/drivers/net/ethernet/netronome/nfp/devlink_param.c b/drivers/net/ethernet/netronome/nfp/devlink_param.c
new file mode 100644
index 000000000000..aece98586e32
--- /dev/null
+++ b/drivers/net/ethernet/netronome/nfp/devlink_param.c
@@ -0,0 +1,60 @@
+// SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+/* Copyright (C) 2019 Netronome Systems, Inc. */
+
+#include <net/devlink.h>
+
+#include "nfpcore/nfp_nsp.h"
+#include "nfp_main.h"
+
+static const struct devlink_param nfp_devlink_params[] = {
+};
+
+static int nfp_devlink_supports_params(struct nfp_pf *pf)
+{
+ struct nfp_nsp *nsp;
+ bool supported;
+ int err;
+
+ nsp = nfp_nsp_open(pf->cpp);
+ if (IS_ERR(nsp)) {
+ err = PTR_ERR(nsp);
+ dev_err(&pf->pdev->dev, "Failed to access the NSP: %d\n", err);
+ return err;
+ }
+
+ supported = nfp_nsp_has_hwinfo_lookup(nsp) &&
+ nfp_nsp_has_hwinfo_set(nsp);
+
+ nfp_nsp_close(nsp);
+ return supported;
+}
+
+int nfp_devlink_params_register(struct nfp_pf *pf)
+{
+ struct devlink *devlink = priv_to_devlink(pf);
+ int err;
+
+ err = nfp_devlink_supports_params(pf);
+ if (err <= 0)
+ return err;
+
+ err = devlink_params_register(devlink, nfp_devlink_params,
+ ARRAY_SIZE(nfp_devlink_params));
+ if (err)
+ return err;
+
+ devlink_params_publish(devlink);
+ return 0;
+}
+
+void nfp_devlink_params_unregister(struct nfp_pf *pf)
+{
+ int err;
+
+ err = nfp_devlink_supports_params(pf);
+ if (err <= 0)
+ return;
+
+ devlink_params_unregister(priv_to_devlink(pf), nfp_devlink_params,
+ ARRAY_SIZE(nfp_devlink_params));
+}
diff --git a/drivers/net/ethernet/netronome/nfp/nfp_main.h b/drivers/net/ethernet/netronome/nfp/nfp_main.h
index bd6450b0f23f..5d5812fd9317 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_main.h
+++ b/drivers/net/ethernet/netronome/nfp/nfp_main.h
@@ -187,4 +187,7 @@ int nfp_shared_buf_pool_get(struct nfp_pf *pf, unsigned int sb, u16 pool_index,
int nfp_shared_buf_pool_set(struct nfp_pf *pf, unsigned int sb,
u16 pool_index, u32 size,
enum devlink_sb_threshold_type threshold_type);
+
+int nfp_devlink_params_register(struct nfp_pf *pf);
+void nfp_devlink_params_unregister(struct nfp_pf *pf);
#endif /* NFP_MAIN_H */
diff --git a/drivers/net/ethernet/netronome/nfp/nfp_net_main.c b/drivers/net/ethernet/netronome/nfp/nfp_net_main.c
index 986464d4a206..47addac104fe 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_net_main.c
+++ b/drivers/net/ethernet/netronome/nfp/nfp_net_main.c
@@ -711,6 +711,10 @@ int nfp_net_pci_probe(struct nfp_pf *pf)
if (err)
goto err_devlink_unreg;
+ err = nfp_devlink_params_register(pf);
+ if (err)
+ goto err_shared_buf_unreg;
+
mutex_lock(&pf->lock);
pf->ddir = nfp_net_debugfs_device_add(pf->pdev);
@@ -744,6 +748,8 @@ int nfp_net_pci_probe(struct nfp_pf *pf)
err_clean_ddir:
nfp_net_debugfs_dir_clean(&pf->ddir);
mutex_unlock(&pf->lock);
+ nfp_devlink_params_unregister(pf);
+err_shared_buf_unreg:
nfp_shared_buf_unregister(pf);
err_devlink_unreg:
cancel_work_sync(&pf->port_refresh_work);
@@ -773,6 +779,7 @@ void nfp_net_pci_remove(struct nfp_pf *pf)
mutex_unlock(&pf->lock);
+ nfp_devlink_params_unregister(pf);
nfp_shared_buf_unregister(pf);
devlink_unregister(priv_to_devlink(pf));
--
2.11.0
^ permalink raw reply related
* [net-next 10/11] kdoc: fix nfp_fw_load documentation
From: Simon Horman @ 2019-09-06 16:01 UTC (permalink / raw)
To: David Miller
Cc: Jakub Kicinski, netdev, oss-drivers, Dirk van der Merwe,
Simon Horman
In-Reply-To: <20190906160101.14866-1-simon.horman@netronome.com>
From: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
Fixed the incorrect prefix for the 'nfp_fw_load' function.
Signed-off-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: Simon Horman <simon.horman@netronome.com>
---
drivers/net/ethernet/netronome/nfp/nfp_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/netronome/nfp/nfp_main.c b/drivers/net/ethernet/netronome/nfp/nfp_main.c
index 0d8649024505..c8ad9b701c3e 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_main.c
+++ b/drivers/net/ethernet/netronome/nfp/nfp_main.c
@@ -458,7 +458,7 @@ nfp_get_fw_policy_value(struct pci_dev *pdev, struct nfp_nsp *nsp,
}
/**
- * nfp_net_fw_load() - Load the firmware image
+ * nfp_fw_load() - Load the firmware image
* @pdev: PCI Device structure
* @pf: NFP PF Device structure
* @nsp: NFP SP handle
--
2.11.0
^ permalink raw reply related
* [net-next 09/11] nfp: devlink: add 'reset_dev_on_drv_probe' support
From: Simon Horman @ 2019-09-06 16:00 UTC (permalink / raw)
To: David Miller
Cc: Jakub Kicinski, netdev, oss-drivers, Dirk van der Merwe,
Simon Horman
In-Reply-To: <20190906160101.14866-1-simon.horman@netronome.com>
From: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
Add support for the 'reset_dev_on_drv_probe' devlink parameter. The
reset control policy is controlled by the 'abi_drv_reset' hwinfo key.
Signed-off-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
Signed-off-by: Simon Horman <simon.horman@netronome.com>
---
Documentation/networking/devlink-params-nfp.txt | 3 +++
drivers/net/ethernet/netronome/nfp/devlink_param.c | 28 ++++++++++++++++++++++
2 files changed, 31 insertions(+)
diff --git a/Documentation/networking/devlink-params-nfp.txt b/Documentation/networking/devlink-params-nfp.txt
index 85b1e36f73a8..43e4d4034865 100644
--- a/Documentation/networking/devlink-params-nfp.txt
+++ b/Documentation/networking/devlink-params-nfp.txt
@@ -1,2 +1,5 @@
fw_load_policy [DEVICE, GENERIC]
Configuration mode: permanent
+
+reset_dev_on_drv_probe [DEVICE, GENERIC]
+ Configuration mode: permanent
diff --git a/drivers/net/ethernet/netronome/nfp/devlink_param.c b/drivers/net/ethernet/netronome/nfp/devlink_param.c
index d9c74cfba560..df5a5c88ee76 100644
--- a/drivers/net/ethernet/netronome/nfp/devlink_param.c
+++ b/drivers/net/ethernet/netronome/nfp/devlink_param.c
@@ -52,6 +52,29 @@ static const struct nfp_devlink_param_u8_arg nfp_devlink_u8_args[] = {
.max_dl_val = DEVLINK_PARAM_FW_LOAD_POLICY_VALUE_DISK,
.max_hi_val = NFP_NSP_APP_FW_LOAD_PREF,
},
+ [DEVLINK_PARAM_GENERIC_ID_RESET_DEV] = {
+ .hwinfo_name = "abi_drv_reset",
+ .default_hi_val = NFP_NSP_DRV_RESET_DEFAULT,
+ .invalid_dl_val = DEVLINK_PARAM_RESET_DEV_VALUE_UNKNOWN,
+ .hi_to_dl = {
+ [NFP_NSP_DRV_RESET_ALWAYS] =
+ DEVLINK_PARAM_RESET_DEV_VALUE_ALWAYS,
+ [NFP_NSP_DRV_RESET_NEVER] =
+ DEVLINK_PARAM_RESET_DEV_VALUE_NEVER,
+ [NFP_NSP_DRV_RESET_DISK] =
+ DEVLINK_PARAM_RESET_DEV_VALUE_DISK,
+ },
+ .dl_to_hi = {
+ [DEVLINK_PARAM_RESET_DEV_VALUE_ALWAYS] =
+ NFP_NSP_DRV_RESET_ALWAYS,
+ [DEVLINK_PARAM_RESET_DEV_VALUE_NEVER] =
+ NFP_NSP_DRV_RESET_NEVER,
+ [DEVLINK_PARAM_RESET_DEV_VALUE_DISK] =
+ NFP_NSP_DRV_RESET_DISK,
+ },
+ .max_dl_val = DEVLINK_PARAM_RESET_DEV_VALUE_DISK,
+ .max_hi_val = NFP_NSP_DRV_RESET_NEVER,
+ }
};
static int
@@ -172,6 +195,11 @@ static const struct devlink_param nfp_devlink_params[] = {
nfp_devlink_param_u8_get,
nfp_devlink_param_u8_set,
nfp_devlink_param_u8_validate),
+ DEVLINK_PARAM_GENERIC(RESET_DEV,
+ BIT(DEVLINK_PARAM_CMODE_PERMANENT),
+ nfp_devlink_param_u8_get,
+ nfp_devlink_param_u8_set,
+ nfp_devlink_param_u8_validate),
};
static int nfp_devlink_supports_params(struct nfp_pf *pf)
--
2.11.0
^ permalink raw reply related
* Re: [PULL] vhost, virtio: last minute fixes
From: pr-tracker-bot @ 2019-09-06 16:05 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Linus Torvalds, kvm, virtualization, netdev, linux-kernel,
jasowang, jiangkidd, linyunsheng, mst, namit, tiwei.bie
In-Reply-To: <20190906094103-mutt-send-email-mst@kernel.org>
The pull request you sent on Fri, 6 Sep 2019 09:41:03 -0400:
> git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/9d098a6234c135c3fd1692fc451908b5c2a43244
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
^ permalink raw reply
* Re: [PATCH v3 bpf-next 2/3] bpf: implement CAP_BPF
From: kbuild test robot @ 2019-09-06 16:20 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: kbuild-all, davem, daniel, peterz, luto, netdev, bpf, kernel-team,
linux-api
In-Reply-To: <20190904184335.360074-2-ast@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 2159 bytes --]
Hi Alexei,
I love your patch! Perhaps something to improve:
[auto build test WARNING on bpf-next/master]
url: https://github.com/0day-ci/linux/commits/Alexei-Starovoitov/capability-introduce-CAP_BPF-and-CAP_TRACING/20190906-215814
base: https://kernel.googlesource.com/pub/scm/linux/kernel/git/bpf/bpf-next.git master
config: x86_64-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.4.0-11) 7.4.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
All warnings (new ones prefixed by >>):
kernel//bpf/syscall.c: In function 'bpf_prog_test_run':
>> kernel//bpf/syscall.c:2087:6: warning: the address of 'capable_bpf_net_admin' will always evaluate as 'true' [-Waddress]
if (!capable_bpf_net_admin)
^
vim +2087 kernel//bpf/syscall.c
2080
2081 static int bpf_prog_test_run(const union bpf_attr *attr,
2082 union bpf_attr __user *uattr)
2083 {
2084 struct bpf_prog *prog;
2085 int ret = -ENOTSUPP;
2086
> 2087 if (!capable_bpf_net_admin)
2088 /* test_run callback is available for networking progs only.
2089 * Add capable_bpf_tracing() above when tracing progs become runable.
2090 */
2091 return -EPERM;
2092 if (CHECK_ATTR(BPF_PROG_TEST_RUN))
2093 return -EINVAL;
2094
2095 if ((attr->test.ctx_size_in && !attr->test.ctx_in) ||
2096 (!attr->test.ctx_size_in && attr->test.ctx_in))
2097 return -EINVAL;
2098
2099 if ((attr->test.ctx_size_out && !attr->test.ctx_out) ||
2100 (!attr->test.ctx_size_out && attr->test.ctx_out))
2101 return -EINVAL;
2102
2103 prog = bpf_prog_get(attr->test.prog_fd);
2104 if (IS_ERR(prog))
2105 return PTR_ERR(prog);
2106
2107 if (prog->aux->ops->test_run)
2108 ret = prog->aux->ops->test_run(prog, attr, uattr);
2109
2110 bpf_prog_put(prog);
2111 return ret;
2112 }
2113
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 70222 bytes --]
^ permalink raw reply
* Re: Need more information on "ifi_change" in "struct ifinfomsg"
From: dhan lin @ 2019-09-06 16:39 UTC (permalink / raw)
To: Nicolas Dichtel; +Cc: netdev
In-Reply-To: <16579c2d-d0b7-179f-5381-3803118a8972@6wind.com>
Nicolas,
Thanks a lot, for the clarification.
On Fri, 6 Sep 2019 at 20:26, Nicolas Dichtel <nicolas.dichtel@6wind.com> wrote:
>
> Le 06/09/2019 à 07:08, dhan lin a écrit :
> > Hi All,
> >
> > There is a field called ifi_change in "struct ifinfomsg". man page for
> > rtnetlink says its for future use and should be always set to
> > 0xFFFFFFFF.
> >
> > But ive run some sample tests, to confirm the value is not as per man
> > pages explanation.
> > Its 0 most of the times and non-zero sometimes.
> >
> > I've the following question,
> >
> > Is ifi_change set only when there is a state change in interface values?
> ifi_change indicates which flags (ifi_flags) have changed.
> It does not cover other changes.
>
>
> Regards,
> Nicolas
^ permalink raw reply
* Re: [PATCH bpf-next 0/6] selftests/bpf: move sockopt tests under test_progs
From: Alexei Starovoitov @ 2019-09-06 16:42 UTC (permalink / raw)
To: Stanislav Fomichev
Cc: Andrii Nakryiko, Stanislav Fomichev, Networking, bpf,
David S. Miller, Alexei Starovoitov, Daniel Borkmann
In-Reply-To: <20190906151808.GD2101@mini-arch>
On Fri, Sep 06, 2019 at 08:18:08AM -0700, Stanislav Fomichev wrote:
> On 09/06, Andrii Nakryiko wrote:
> > On Wed, Sep 4, 2019 at 4:03 PM Alexei Starovoitov
> > <alexei.starovoitov@gmail.com> wrote:
> > >
> > > On Wed, Sep 04, 2019 at 09:25:03AM -0700, Stanislav Fomichev wrote:
> > > > Now that test_progs is shaping into more generic test framework,
> > > > let's convert sockopt tests to it. This requires adding
> > > > a helper to create and join a cgroup first (test__join_cgroup).
> > > > Since we already hijack stdout/stderr that shouldn't be
> > > > a problem (cgroup helpers log to stderr).
> > > >
> > > > The rest of the patches just move sockopt tests files under prog_tests/
> > > > and do the required small adjustments.
> > >
> > > Looks good. Thank you for working on it.
> > > Could you de-verbose setsockopt test a bit?
> > > #23/32 setsockopt: deny write ctx->retval:OK
> > > #23/33 setsockopt: deny read ctx->retval:OK
> > > #23/34 setsockopt: deny writing to ctx->optval:OK
> > > #23/35 setsockopt: deny writing to ctx->optval_end:OK
> > > #23/36 setsockopt: allow IP_TOS <= 128:OK
> > > #23/37 setsockopt: deny IP_TOS > 128:OK
> > > 37 subtests is a bit too much spam.
> >
> > If we merged test_btf into test_progs, we'd have >150 subtests, which
> > would be pretty verbose as well. But the benefit of subtest is that
> > you can run just that sub-test and debug/verify just it, without all
> > the rest stuff.
> >
> > So I'm wondering, if too many lines of default output is the only
> > problem, should we just not output per-subtest line by default?
> Ack, we can output per-subtest line if it fails so it's easy to re-run;
> otherwise, hiding by default sounds good. I'll prepare a v3 sometime
> today; Alexei, let us know if you disagree.
If the subtests are runnable and useful individually it's good to have
them as subtests.
I think in the above I misread them as a sequence of sub-checks that needs
to happen before actual test result.
Looking at test_sockopt.c I see that they're separate tests,
so yeah keep them.
No need to hide by default or extra flags.
Let me look at v1 and v2 again...
^ permalink raw reply
* Re: [PATCH net] net: gso: Fix skb_segment splat when splitting gso_size mangled skb having linear-headed frag_list
From: Willem de Bruijn @ 2019-09-06 16:44 UTC (permalink / raw)
To: Alexander Duyck
Cc: Shmulik Ladkani, Willem de Bruijn, Eric Dumazet, Daniel Borkmann,
eyal, netdev, Shmulik Ladkani
In-Reply-To: <CAKgT0Ufd40gmaW7eLu3sRHd=4CeY9WNmgRBUzNt5_+0tEKEMvA@mail.gmail.com>
On Fri, Sep 6, 2019 at 11:44 AM Alexander Duyck
<alexander.duyck@gmail.com> wrote:
>
> On Fri, Sep 6, 2019 at 8:37 AM Shmulik Ladkani <shmulik@metanetworks.com> wrote:
> >
> > On Fri, 6 Sep 2019 10:49:55 -0400
> > Willem de Bruijn <willemdebruijn.kernel@gmail.com> wrote:
> >
> > > But I wonder whether it is a given that head_skb has headlen.
> >
> > This is what I observed for GRO packets that do have headlen frag_list
> > members: the 'head_skb' itself had a headlen too, and its head was
> > built using the original gso_size (similar to the frag_list members).
That makes sense.
I was thinking of, say, a driver that combines napi_gro_frags with a
copy break optimization. But given that gso_size is the same for all
segments expect perhaps the last, all those segments will have taken
the same path.
And if we're wrong we'll find out soon enough and can return to this
topic yet again. skb_segment really puts the fun in function.
> >
> > Maybe Eric can comment better.
> >
> > > Btw, it seems slightly odd to me tot test head_frag before testing
> > > headlen in the v2 patch.
> >
> > Requested by Alexander. I'm fine either way.
>
> Yeah, my thought on that was "do we care about the length if the data
> is stored in a head_frag?". I suppose you could flip the logic and
> make it "do we care about it being a head_frag if there is no data
> there?". The reason I had suggested the head_frag test first was
> because it was a single test bit whereas the length requires reading
> two fields and doing a comparison.
>
> For either ordering it is fine by me. So if we need to feel free to
> swap those two tests for a v3.
Got it. I don't feel strongly either. No need for a v3 for that.
> Reviewed-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
^ permalink raw reply
* Re: [PATCH net-next,v3 0/4] flow_offload: update mangle action representation
From: Edward Cree @ 2019-09-06 16:49 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: netfilter-devel, davem, netdev, jakub.kicinski, jiri, saeedm,
vishal, vladbu
In-Reply-To: <20190906155804.v4lviltxs72a45tq@salvia>
On 06/09/2019 16:58, Pablo Neira Ayuso wrote:
> In tc pedit ex, those are _indeed_ two separated actions:
I read the code again and I get it now, there's double iteration
already over tcf_exts_for_each_action and tcf_pedit_nkeys, and
it's only within the latter that you coalesce.
However, have you considered that iproute2 (i.e. tc tool) isn't
guaranteed to be the only userland consumer of the TC uAPI? For all
we know there could be another user out there producing things like
a single pedit action with two keys, same offset but different
masks, to mangle sport & dport separately, which your code now
_would_ coalesce into a single mangle. I don't know if that would
lead to any problems, but I want to be sure you've thought about it ;)
>> Proper thing to do is have helper functions available to drivers to test
>> the pedit, and not just switch on the offset. Why do I say that?
>>
>> Well, consider a pedit on UDP dport, with mask 0x00ff (network endian).
>> Now as a u32 pedit that's 0x000000ff offset 0, so field-blind offset
>> calculation (ffs in flow_action_mangle_entry()) will turn that into
>> offset 3 mask 0xff. Now driver does
>> switch(offset) { /* 3 */
>> case offsetof(struct udphdr, dest): /* 2 */
>> /* Whoops, we never get here! */
>> }
>>
>> Do you see the problem?
> This scenario you describe cannot _work_ right now, with the existing
> code. Without my patchset, this scenario you describe does _not_ work,
>
> The drivers in the tree need a mask of 0xffff to infer that this is
> UDP dport.
>
> The 'tc pedit ex' infrastructure does not allow for the scenario that
> you describe above.
>
> No driver in the tree allow for what you describe already.
Looks to me like existing nfp_fl_set_tport() handles just fine any
arbitrary mask across the u32 that contains UDP sport & dport.
And the uAPI we have to maintain is the uAPI we expose, not the subset
that iproute2 uses. I could write a patched tc tool *today* that does
a pedit of 'UDP header, offset 0, mask 0xff0000ff' and the nfp driver
would accept that fine (no idea what the fw / chip would do with it,
but presumably it works or Netronome folks would have put checks in),
whereas with your patch it'll complain "invalid pedit L4 action"
because the mask isn't all-1s.
And if I made it produce my example from above, mask 0x000000ff, you'd
calculate an offset of 3 and hit the other error, "unsupported section
of L4 header", which again would have worked before.
^ permalink raw reply
* Re: [PATCH bpf-next 0/6] selftests/bpf: move sockopt tests under test_progs
From: Alexei Starovoitov @ 2019-09-06 17:02 UTC (permalink / raw)
To: Stanislav Fomichev
Cc: Andrii Nakryiko, Stanislav Fomichev, Networking, bpf,
David S. Miller, Alexei Starovoitov, Daniel Borkmann
In-Reply-To: <20190906164233.npuhtaeoezpp2dol@ast-mbp.dhcp.thefacebook.com>
On Fri, Sep 6, 2019 at 9:42 AM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
>
> On Fri, Sep 06, 2019 at 08:18:08AM -0700, Stanislav Fomichev wrote:
> > On 09/06, Andrii Nakryiko wrote:
> > > On Wed, Sep 4, 2019 at 4:03 PM Alexei Starovoitov
> > > <alexei.starovoitov@gmail.com> wrote:
> > > >
> > > > On Wed, Sep 04, 2019 at 09:25:03AM -0700, Stanislav Fomichev wrote:
> > > > > Now that test_progs is shaping into more generic test framework,
> > > > > let's convert sockopt tests to it. This requires adding
> > > > > a helper to create and join a cgroup first (test__join_cgroup).
> > > > > Since we already hijack stdout/stderr that shouldn't be
> > > > > a problem (cgroup helpers log to stderr).
> > > > >
> > > > > The rest of the patches just move sockopt tests files under prog_tests/
> > > > > and do the required small adjustments.
> > > >
> > > > Looks good. Thank you for working on it.
> > > > Could you de-verbose setsockopt test a bit?
> > > > #23/32 setsockopt: deny write ctx->retval:OK
> > > > #23/33 setsockopt: deny read ctx->retval:OK
> > > > #23/34 setsockopt: deny writing to ctx->optval:OK
> > > > #23/35 setsockopt: deny writing to ctx->optval_end:OK
> > > > #23/36 setsockopt: allow IP_TOS <= 128:OK
> > > > #23/37 setsockopt: deny IP_TOS > 128:OK
> > > > 37 subtests is a bit too much spam.
> > >
> > > If we merged test_btf into test_progs, we'd have >150 subtests, which
> > > would be pretty verbose as well. But the benefit of subtest is that
> > > you can run just that sub-test and debug/verify just it, without all
> > > the rest stuff.
> > >
> > > So I'm wondering, if too many lines of default output is the only
> > > problem, should we just not output per-subtest line by default?
> > Ack, we can output per-subtest line if it fails so it's easy to re-run;
> > otherwise, hiding by default sounds good. I'll prepare a v3 sometime
> > today; Alexei, let us know if you disagree.
>
> If the subtests are runnable and useful individually it's good to have
> them as subtests.
> I think in the above I misread them as a sequence of sub-checks that needs
> to happen before actual test result.
> Looking at test_sockopt.c I see that they're separate tests,
> so yeah keep them.
> No need to hide by default or extra flags.
> Let me look at v1 and v2 again...
I applied v1 set. Thanks!
^ permalink raw reply
* Re: [PATCH 0/7] libbpf: Fix cast away const qualifiers in btf.h
From: Alexei Starovoitov @ 2019-09-06 17:03 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: Jiri Olsa, Alexei Starovoitov, Daniel Borkmann,
netdev@vger.kernel.org, bpf@vger.kernel.org, Yonghong Song,
Martin Lau
In-Reply-To: <62e760de-e746-c512-350a-c2188a2bb3ed@fb.com>
On Fri, Sep 6, 2019 at 2:09 AM Andrii Nakryiko <andriin@fb.com> wrote:
>
> On 9/6/19 8:31 AM, Jiri Olsa wrote:
> > hi,
> > when including btf.h in bpftrace, I'm getting -Wcast-qual warnings like:
> >
> > bpf/btf.h: In function ‘btf_var_secinfo* btf_var_secinfos(const btf_type*)’:
> > bpf/btf.h:302:41: warning: cast from type ‘const btf_type*’ to type
> > ‘btf_var_secinfo*’ casts away qualifiers [-Wcast-qual]
> > 302 | return (struct btf_var_secinfo *)(t + 1);
> > | ^
> >
> > I changed the btf.h header to comply with -Wcast-qual checks
> > and used const cast away casting in libbpf objects, where it's
>
> Hey Jiri,
>
> We made all those helper funcs return non-const structs intentionally to
> improve their usability and avoid all those casts that you added back.
>
> Also, those helpers are now part of public API, so we can't just change
> them to const, as it can break existing users easily.
>
> If there is a need to run with -Wcast-qual, we should probably disable
> those checks where appropriate in libbpf code.
>
> So this will be a NACK from me, sorry.
Same opinion. This gcc warning is bogus.
^ permalink raw reply
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