Re: [PATCH v2 net] net: aquantia: memory corruption on jumbo frames
From: Igor Russkikh
Date: Tue, 18 Sep 2018 11:28:55 +0300
>
>>> Fixes: 018423e90bee ("net: ethernet: aquantia: Add ring support code")
>>>
>>> Reported-by: Friedemann Gerold
>>> Reported-by: Michael Rauch
>>> Signed-off-by: Friedemann Gerold
>>> Tested-by: Nikita Danilov
>>> Signed-off-by: Igor Russkikh
>>
>> APplied and queued up for -stable.
>
> Hi David, I see this was applied to net-next tree only.
> Can we have it in net? We consider it as critical flaw.
Sorry about that, fixed.
[PATCH v2 net-next 7/9] bnxt_en: Add a driver specific gre_ver_check devlink parameter.
This patch adds following driver-specific permanent mode boolean
parameter.
gre_ver_check - Generic Routing Encapsulation(GRE) version check
will be enabled in the device. If disabled, device skips version
checking for GRE packets.
Cc: Michael Chan
Signed-off-by: Vasundhara Volam
---
drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c | 24 ++-
drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h | 1 +
2 files changed, 24 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
index 7dc754b..fdeb4e5 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
@@ -21,6 +21,11 @@
#endif /* CONFIG_BNXT_SRIOV */
};
+enum bnxt_dl_param_id {
+ BNXT_DEVLINK_PARAM_ID_BASE = DEVLINK_PARAM_GENERIC_ID_MAX,
+ BNXT_DEVLINK_PARAM_ID_GRE_VER_CHECK,
+};
+
static const struct bnxt_dl_nvm_param nvm_params[] = {
{DEVLINK_PARAM_GENERIC_ID_ENABLE_SRIOV, NVM_OFF_ENABLE_SRIOV,
BNXT_NVM_SHARED_CFG, 1},
@@ -30,6 +35,8 @@
NVM_OFF_MSIX_VEC_PER_PF_MAX, BNXT_NVM_SHARED_CFG, 10},
{DEVLINK_PARAM_GENERIC_ID_MSIX_VEC_PER_PF_MIN,
NVM_OFF_MSIX_VEC_PER_PF_MIN, BNXT_NVM_SHARED_CFG, 7},
+ {BNXT_DEVLINK_PARAM_ID_GRE_VER_CHECK, NVM_OFF_DIS_GRE_VER_CHECK,
+BNXT_NVM_SHARED_CFG, 1},
};
static int bnxt_hwrm_nvm_req(struct bnxt *bp, u32 param_id, void *msg,
@@ -109,9 +116,15 @@ static int bnxt_dl_nvm_param_get(struct devlink *dl, u32
id,
{
struct hwrm_nvm_get_variable_input req = {0};
struct bnxt *bp = bnxt_get_bp_from_dl(dl);
+ int rc;
bnxt_hwrm_cmd_hdr_init(bp, &req, HWRM_NVM_GET_VARIABLE, -1, -1);
- return bnxt_hwrm_nvm_req(bp, id, &req, sizeof(req), &ctx->val);
+ rc = bnxt_hwrm_nvm_req(bp, id, &req, sizeof(req), &ctx->val);
+ if (!rc)
+ if (id == BNXT_DEVLINK_PARAM_ID_GRE_VER_CHECK)
+ ctx->val.vbool = !ctx->val.vbool;
+
+ return rc;
}
static int bnxt_dl_nvm_param_set(struct devlink *dl, u32 id,
@@ -121,6 +134,10 @@ static int bnxt_dl_nvm_param_set(struct devlink *dl, u32
id,
struct bnxt *bp = bnxt_get_bp_from_dl(dl);
bnxt_hwrm_cmd_hdr_init(bp, &req, HWRM_NVM_SET_VARIABLE, -1, -1);
+
+ if (id == BNXT_DEVLINK_PARAM_ID_GRE_VER_CHECK)
+ ctx->val.vbool = !ctx->val.vbool;
+
return bnxt_hwrm_nvm_req(bp, id, &req, sizeof(req), &ctx->val);
}
@@ -161,6 +178,11 @@ static int bnxt_dl_msix_validate(struct devlink *dl, u32
id,
BIT(DEVLINK_PARAM_CMODE_PERMANENT),
bnxt_dl_nvm_param_get, bnxt_dl_nvm_param_set,
bnxt_dl_msix_validate),
+ DEVLINK_PARAM_DRIVER(BNXT_DEVLINK_PARAM_ID_GRE_VER_CHECK,
+"gre_ver_check", DEVLINK_PARAM_TYPE_BOOL,
+BIT(DEVLINK_PARAM_CMODE_PERMANENT),
+bnxt_dl_nvm_param_get, bnxt_dl_nvm_param_set,
+NULL),
};
int bnxt_dl_register(struct bnxt *bp)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h
b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h
index 0e67c05..e36e41a 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h
@@ -37,6 +37,7 @@ static inline void bnxt_link_bp_to_dl(struct bnxt *bp, struct
devlink *dl)
#define NVM_OFF_MSIX_VEC_PER_PF_MIN114
#define NVM_OFF_IGNORE_ARI 164
#define NVM_OFF_HW_TC_OFFLOAD 170
+#define NVM_OFF_DIS_GRE_VER_CHECK 171
#define NVM_OFF_ENABLE_SRIOV 401
#define BNXT_MSIX_VEC_MAX 1280
--
1.8.3.1
[PATCH v2 net-next 4/9] bnxt_en: Use ignore_ari devlink parameter
This patch adds support for ignore_ari generic permanent mode
devlink parameter. This parameter is disabled by default. It can be
enabled using devlink param commands.
ignore_ari - If enabled, device ignores ARI(Alternate Routing ID)
capability, even when platforms has the support and creates same number
of partitions when platform does not support ARI capability.
Cc: Michael Chan
Signed-off-by: Vasundhara Volam
---
drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c | 6 ++
drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h | 2 ++
2 files changed, 8 insertions(+)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
index f3b9fbc..58e3061 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
@@ -24,6 +24,8 @@
static const struct bnxt_dl_nvm_param nvm_params[] = {
{DEVLINK_PARAM_GENERIC_ID_ENABLE_SRIOV, NVM_OFF_ENABLE_SRIOV,
BNXT_NVM_SHARED_CFG, 1},
+ {DEVLINK_PARAM_GENERIC_ID_IGNORE_ARI, NVM_OFF_IGNORE_ARI,
+BNXT_NVM_SHARED_CFG, 1},
};
static int bnxt_hwrm_nvm_req(struct bnxt *bp, u32 param_id, void *msg,
@@ -105,6 +107,10 @@ static int bnxt_dl_nvm_param_set(struct devlink *dl, u32
id,
BIT(DEVLINK_PARAM_CMODE_PERMANENT),
bnxt_dl_nvm_param_get, bnxt_dl_nvm_param_set,
NULL),
+ DEVLINK_PARAM_GENERIC(IGNORE_ARI,
+ BIT(DEVLINK_PARAM_CMODE_PERMANENT),
+ bnxt_dl_nvm_param_get, bnxt_dl_nvm_param_set,
+ NULL),
};
int bnxt_dl_register(struct bnxt *bp)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h
b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h
index 2f68dc0..da146492 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h
@@ -33,6 +33,8 @@ static inline void bnxt_link_bp_to_dl(struct bnxt *bp, struct
devlink *dl)
}
}
+#define NVM_OFF_IGNORE_ARI 164
+#define NVM_OFF_HW_TC_OFFLOAD 170
#define NVM_OFF_ENABLE_SRIOV 401
enum bnxt_nvm_dir_type {
--
1.8.3.1
[PATCH v2 net-next 1/9] devlink: Add generic parameter ignore_ari
ignore_ari - Device ignores ARI(Alternate Routing ID) capability,
even when platforms has the support and creates same number of
partitions when platform does not support ARI capability.
Cc: Jiri Pirko
Cc: Michael Chan
Signed-off-by: Vasundhara Volam
---
include/net/devlink.h | 4
net/core/devlink.c| 5 +
2 files changed, 9 insertions(+)
diff --git a/include/net/devlink.h b/include/net/devlink.h
index b9b89d6..90d8343 100644
--- a/include/net/devlink.h
+++ b/include/net/devlink.h
@@ -362,6 +362,7 @@ enum devlink_param_generic_id {
DEVLINK_PARAM_GENERIC_ID_MAX_MACS,
DEVLINK_PARAM_GENERIC_ID_ENABLE_SRIOV,
DEVLINK_PARAM_GENERIC_ID_REGION_SNAPSHOT,
+ DEVLINK_PARAM_GENERIC_ID_IGNORE_ARI,
/* add new param generic ids above here*/
__DEVLINK_PARAM_GENERIC_ID_MAX,
@@ -380,6 +381,9 @@ enum devlink_param_generic_id {
#define DEVLINK_PARAM_GENERIC_REGION_SNAPSHOT_NAME "region_snapshot_enable"
#define DEVLINK_PARAM_GENERIC_REGION_SNAPSHOT_TYPE DEVLINK_PARAM_TYPE_BOOL
+#define DEVLINK_PARAM_GENERIC_IGNORE_ARI_NAME "ignore_ari"
+#define DEVLINK_PARAM_GENERIC_IGNORE_ARI_TYPE DEVLINK_PARAM_TYPE_BOOL
+
#define DEVLINK_PARAM_GENERIC(_id, _cmodes, _get, _set, _validate) \
{ \
.id = DEVLINK_PARAM_GENERIC_ID_##_id, \
diff --git a/net/core/devlink.c b/net/core/devlink.c
index 65fc366..6b08ad6 100644
--- a/net/core/devlink.c
+++ b/net/core/devlink.c
@@ -2676,6 +2676,11 @@ static int devlink_nl_cmd_reload(struct sk_buff *skb,
struct genl_info *info)
.name = DEVLINK_PARAM_GENERIC_REGION_SNAPSHOT_NAME,
.type = DEVLINK_PARAM_GENERIC_REGION_SNAPSHOT_TYPE,
},
+ {
+ .id = DEVLINK_PARAM_GENERIC_ID_IGNORE_ARI,
+ .name = DEVLINK_PARAM_GENERIC_IGNORE_ARI_NAME,
+ .type = DEVLINK_PARAM_GENERIC_IGNORE_ARI_TYPE,
+ },
};
static int devlink_param_generic_verify(const struct devlink_param *param)
--
1.8.3.1
[PATCH v2 net-next 2/9] devlink: Add generic parameter msix_vec_per_pf_max
msix_vec_per_pf_max - This param sets the number of MSIX vectors
that the device requests from the host on driver initialization.
This value is set in the device which is applicable per PF.
Cc: Jiri Pirko
Cc: Michael Chan
Signed-off-by: Vasundhara Volam
---
include/net/devlink.h | 4
net/core/devlink.c| 5 +
2 files changed, 9 insertions(+)
diff --git a/include/net/devlink.h b/include/net/devlink.h
index 90d8343..59be17b 100644
--- a/include/net/devlink.h
+++ b/include/net/devlink.h
@@ -363,6 +363,7 @@ enum devlink_param_generic_id {
DEVLINK_PARAM_GENERIC_ID_ENABLE_SRIOV,
DEVLINK_PARAM_GENERIC_ID_REGION_SNAPSHOT,
DEVLINK_PARAM_GENERIC_ID_IGNORE_ARI,
+ DEVLINK_PARAM_GENERIC_ID_MSIX_VEC_PER_PF_MAX,
/* add new param generic ids above here*/
__DEVLINK_PARAM_GENERIC_ID_MAX,
@@ -384,6 +385,9 @@ enum devlink_param_generic_id {
#define DEVLINK_PARAM_GENERIC_IGNORE_ARI_NAME "ignore_ari"
#define DEVLINK_PARAM_GENERIC_IGNORE_ARI_TYPE DEVLINK_PARAM_TYPE_BOOL
+#define DEVLINK_PARAM_GENERIC_MSIX_VEC_PER_PF_MAX_NAME "msix_vec_per_pf_max"
+#define DEVLINK_PARAM_GENERIC_MSIX_VEC_PER_PF_MAX_TYPE DEVLINK_PARAM_TYPE_U32
+
#define DEVLINK_PARAM_GENERIC(_id, _cmodes, _get, _set, _validate) \
{ \
.id = DEVLINK_PARAM_GENERIC_ID_##_id, \
diff --git a/net/core/devlink.c b/net/core/devlink.c
index 6b08ad6..7e0ac2e 100644
--- a/net/core/devlink.c
+++ b/net/core/devlink.c
@@ -2681,6 +2681,11 @@ static int devlink_nl_cmd_reload(struct sk_buff *skb,
struct genl_info *info)
.name = DEVLINK_PARAM_GENERIC_IGNORE_ARI_NAME,
.type = DEVLINK_PARAM_GENERIC_IGNORE_ARI_TYPE,
},
+ {
+ .id = DEVLINK_PARAM_GENERIC_ID_MSIX_VEC_PER_PF_MAX,
+ .name = DEVLINK_PARAM_GENERIC_MSIX_VEC_PER_PF_MAX_NAME,
+ .type = DEVLINK_PARAM_GENERIC_MSIX_VEC_PER_PF_MAX_TYPE,
+ },
};
static int devlink_param_generic_verify(const struct devlink_param *param)
--
1.8.3.1
[PATCH v2 net-next 9/9] devlink: Add Documentation/networking/devlink-params-bnxt.txt
This patch adds a new file to add information about configuration parameters that are supported by bnxt_en driver via devlink. Cc: "David S. Miller" Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Cc: Jiri Pirko Cc: Michael Chan Signed-off-by: Vasundhara Volam --- Documentation/networking/devlink-params-bnxt.txt | 35 1 file changed, 35 insertions(+) create mode 100644 Documentation/networking/devlink-params-bnxt.txt diff --git a/Documentation/networking/devlink-params-bnxt.txt b/Documentation/networking/devlink-params-bnxt.txt new file mode 100644 index 000..ca7c457 --- /dev/null +++ b/Documentation/networking/devlink-params-bnxt.txt @@ -0,0 +1,35 @@ +enable_sriov [DEVICE, GENERIC] + Enable Single Root I/O Virtualisation (SRIOV) in + the device. + Type: Boolean + Configuration mode: Permanent + +ignore_ari [DEVICE, GENERIC] + Ignore Alternative Routing-ID Interpretation (ARI) + capability. If enabled, adapter will ignore ARI + capability even when platforms has the support + enabled and creates same number of partitions when + platform does not support ARI. + Type: Boolean + Configuration mode: Permanent + +msix_vec_per_pf_max[DEVICE, GENERIC] + Provides the maximum number of MSIX interrupts that + a device can create. Value is same across all + physical functions (PFs) in the device. + Type: u32 + Configuration mode: Permanent + +msix_vec_per_pf_min[DEVICE, GENERIC] + Provides the minimum number of MSIX interrupts required + or the device initialization. Value is same across all + physical functions (PFs) in the device. + Type: u32 + Configuration mode: Permanent + +gre_ver_check [DEVICE, DRIVER-SPECIFIC] + Generic Routing Encapsulation (GRE) version check will + be enabled in the device. If disabled, device skips + version checking for incoming packets. + Type: Boolean + Configuration mode: Permanent -- 1.8.3.1
[PATCH v2 net-next 8/9] devlink: Add Documentation/networking/devlink-params.txt
This patch adds a new file to add information about some of the generic configuration parameters set via devlink. Cc: "David S. Miller" Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Cc: Jiri Pirko Cc: Michael Chan Signed-off-by: Vasundhara Volam --- Documentation/networking/devlink-params.txt | 42 + 1 file changed, 42 insertions(+) create mode 100644 Documentation/networking/devlink-params.txt diff --git a/Documentation/networking/devlink-params.txt b/Documentation/networking/devlink-params.txt new file mode 100644 index 000..ae444ff --- /dev/null +++ b/Documentation/networking/devlink-params.txt @@ -0,0 +1,42 @@ +Devlink configuration parameters + +Following is the list of configuration parameters via devlink interface. +Each parameter can be generic or driver specific and are device level +parameters. + +Note that the driver-specific files should contain the generic params +they support to, with supported config modes. + +Each parameter can be set in different configuration modes: + runtime - set while driver is running, no reset required. + driverinit - applied while driver initializes, requires restart + driver by devlink reload command. + permanent - written to device's non-volatile memory, hard reset + required. + +Following is the list of parameters: + +enable_sriov [DEVICE, GENERIC] + Enable Single Root I/O Virtualisation (SRIOV) in + the device. + Type: Boolean + +ignore_ari [DEVICE, GENERIC] + Ignore Alternative Routing-ID Interpretation (ARI) + capability. If enabled, adapter will ignore ARI + capability even when platforms has the support + enabled and creates same number of partitions when + platform does not support ARI. + Type: Boolean + +msix_vec_per_pf_max[DEVICE, GENERIC] + Provides the maximum number of MSIX interrupts that + a device can create. Value is same across all + physical functions (PFs) in the device. + Type: u32 + +msix_vec_per_pf_min[DEVICE, GENERIC] + Provides the minimum number of MSIX interrupts required + for the device initialization. Value is same across all + physical functions (PFs) in the device. + Type: u32 -- 1.8.3.1
[PATCH v2 net-next 3/9] devlink: Add generic parameter msix_vec_per_pf_min
msix_vec_per_pf_min - This param sets the number of minimal MSIX
vectors required for the device initialization. This value is set
in the device which limits MSIX vectors per PF.
Cc: Jiri Pirko
Cc: Michael Chan
Signed-off-by: Vasundhara Volam
---
include/net/devlink.h | 4
net/core/devlink.c| 5 +
2 files changed, 9 insertions(+)
diff --git a/include/net/devlink.h b/include/net/devlink.h
index 59be17b..361f525 100644
--- a/include/net/devlink.h
+++ b/include/net/devlink.h
@@ -364,6 +364,7 @@ enum devlink_param_generic_id {
DEVLINK_PARAM_GENERIC_ID_REGION_SNAPSHOT,
DEVLINK_PARAM_GENERIC_ID_IGNORE_ARI,
DEVLINK_PARAM_GENERIC_ID_MSIX_VEC_PER_PF_MAX,
+ DEVLINK_PARAM_GENERIC_ID_MSIX_VEC_PER_PF_MIN,
/* add new param generic ids above here*/
__DEVLINK_PARAM_GENERIC_ID_MAX,
@@ -388,6 +389,9 @@ enum devlink_param_generic_id {
#define DEVLINK_PARAM_GENERIC_MSIX_VEC_PER_PF_MAX_NAME "msix_vec_per_pf_max"
#define DEVLINK_PARAM_GENERIC_MSIX_VEC_PER_PF_MAX_TYPE DEVLINK_PARAM_TYPE_U32
+#define DEVLINK_PARAM_GENERIC_MSIX_VEC_PER_PF_MIN_NAME "msix_vec_per_pf_min"
+#define DEVLINK_PARAM_GENERIC_MSIX_VEC_PER_PF_MIN_TYPE DEVLINK_PARAM_TYPE_U32
+
#define DEVLINK_PARAM_GENERIC(_id, _cmodes, _get, _set, _validate) \
{ \
.id = DEVLINK_PARAM_GENERIC_ID_##_id, \
diff --git a/net/core/devlink.c b/net/core/devlink.c
index 7e0ac2e..8faf889 100644
--- a/net/core/devlink.c
+++ b/net/core/devlink.c
@@ -2686,6 +2686,11 @@ static int devlink_nl_cmd_reload(struct sk_buff *skb,
struct genl_info *info)
.name = DEVLINK_PARAM_GENERIC_MSIX_VEC_PER_PF_MAX_NAME,
.type = DEVLINK_PARAM_GENERIC_MSIX_VEC_PER_PF_MAX_TYPE,
},
+ {
+ .id = DEVLINK_PARAM_GENERIC_ID_MSIX_VEC_PER_PF_MIN,
+ .name = DEVLINK_PARAM_GENERIC_MSIX_VEC_PER_PF_MIN_NAME,
+ .type = DEVLINK_PARAM_GENERIC_MSIX_VEC_PER_PF_MIN_TYPE,
+ },
};
static int devlink_param_generic_verify(const struct devlink_param *param)
--
1.8.3.1
[PATCH v2 net-next 6/9] bnxt_en: Use msix_vec_per_pf_max and msix_vec_per_pf_min devlink params.
This patch adds support for following generic permanent mode
devlink parameters. They can be modified using devlink param
commands.
msix_vec_per_pf_max - This param sets the number of MSIX vectors
that the device requests from the host on driver initialization.
This value is set in the device which limits MSIX vectors per PF.
msix_vec_per_pf_min - This param sets the number of minimal MSIX
vectors required for the device initialization. Value 0 indicates
a default value is selected. This value is set in the device which
limits MSIX vectors per PF.
Cc: Michael Chan
Signed-off-by: Vasundhara Volam
---
drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c | 50 ++-
drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h | 5 +++
2 files changed, 53 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
index 1b25e3a..7dc754b 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
@@ -26,6 +26,10 @@
BNXT_NVM_SHARED_CFG, 1},
{DEVLINK_PARAM_GENERIC_ID_IGNORE_ARI, NVM_OFF_IGNORE_ARI,
BNXT_NVM_SHARED_CFG, 1},
+ {DEVLINK_PARAM_GENERIC_ID_MSIX_VEC_PER_PF_MAX,
+NVM_OFF_MSIX_VEC_PER_PF_MAX, BNXT_NVM_SHARED_CFG, 10},
+ {DEVLINK_PARAM_GENERIC_ID_MSIX_VEC_PER_PF_MIN,
+NVM_OFF_MSIX_VEC_PER_PF_MIN, BNXT_NVM_SHARED_CFG, 7},
};
static int bnxt_hwrm_nvm_req(struct bnxt *bp, u32 param_id, void *msg,
@@ -54,8 +58,22 @@ static int bnxt_hwrm_nvm_req(struct bnxt *bp, u32 param_id,
void *msg,
idx = bp->pf.fw_fid - BNXT_FIRST_PF_FID;
bytesize = roundup(nvm_param.num_bits, BITS_PER_BYTE) / BITS_PER_BYTE;
- if (nvm_param.num_bits == 1)
- buf = &val->vbool;
+ switch (bytesize) {
+ case 1:
+ if (nvm_param.num_bits == 1)
+ buf = &val->vbool;
+ else
+ buf = &val->vu8;
+ break;
+ case 2:
+ buf = &val->vu16;
+ break;
+ case 4:
+ buf = &val->vu32;
+ break;
+ default:
+ return -EFAULT;
+ }
data_addr = dma_zalloc_coherent(&bp->pdev->dev, bytesize,
&data_dma_addr, GFP_KERNEL);
@@ -106,6 +124,26 @@ static int bnxt_dl_nvm_param_set(struct devlink *dl, u32
id,
return bnxt_hwrm_nvm_req(bp, id, &req, sizeof(req), &ctx->val);
}
+static int bnxt_dl_msix_validate(struct devlink *dl, u32 id,
+union devlink_param_value val,
+struct netlink_ext_ack *extack)
+{
+ int max_val;
+
+ if (id == DEVLINK_PARAM_GENERIC_ID_MSIX_VEC_PER_PF_MAX)
+ max_val = BNXT_MSIX_VEC_MAX;
+
+ if (id == DEVLINK_PARAM_GENERIC_ID_MSIX_VEC_PER_PF_MIN)
+ max_val = BNXT_MSIX_VEC_MIN_MAX;
+
+ if (val.vu32 < 0 || val.vu32 > max_val) {
+ NL_SET_ERR_MSG_MOD(extack, "MSIX value is exceeding the range");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static const struct devlink_param bnxt_dl_params[] = {
DEVLINK_PARAM_GENERIC(ENABLE_SRIOV,
BIT(DEVLINK_PARAM_CMODE_PERMANENT),
@@ -115,6 +153,14 @@ static int bnxt_dl_nvm_param_set(struct devlink *dl, u32
id,
BIT(DEVLINK_PARAM_CMODE_PERMANENT),
bnxt_dl_nvm_param_get, bnxt_dl_nvm_param_set,
NULL),
+ DEVLINK_PARAM_GENERIC(MSIX_VEC_PER_PF_MAX,
+ BIT(DEVLINK_PARAM_CMODE_PERMANENT),
+ bnxt_dl_nvm_param_get, bnxt_dl_nvm_param_set,
+ bnxt_dl_msix_validate),
+ DEVLINK_PARAM_GENERIC(MSIX_VEC_PER_PF_MIN,
+ BIT(DEVLINK_PARAM_CMODE_PERMANENT),
+ bnxt_dl_nvm_param_get, bnxt_dl_nvm_param_set,
+ bnxt_dl_msix_validate),
};
int bnxt_dl_register(struct bnxt *bp)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h
b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h
index da146492..0e67c05 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h
@@ -33,10 +33,15 @@ static inline void bnxt_link_bp_to_dl(struct bnxt *bp,
struct devlink *dl)
}
}
+#define NVM_OFF_MSIX_VEC_PER_PF_MAX108
+#define NVM_OFF_MSIX_VEC_PER_PF_MIN114
#define NVM_OFF_IGNORE_ARI 164
#define NVM_OFF_HW_TC_OFFLOAD 170
#define NVM_OFF_ENABLE_SRIOV 401
+#define BNXT_MSIX_VEC_MAX 1280
+#define BNXT_MSIX_VEC_MIN_MAX 128
+
enum bnxt_nvm_dir_type {
BNXT_NVM_SHARED_CFG = 40,
BNXT_NVM_PORT_CFG,
--
1.8.3.1
[PATCH v2 net-next 0/9] bnxt_en: devlink param updates
This patchset adds support for 3 generic and 1 driver-specific devlink parameters. Add documentation for these configuration parameters. Also, this patchset adds support to return proper error code if HWRM_NVM_GET/SET_VARIABLE commands return error code HWRM_ERR_CODE_RESOURCE_ACCESS_DENIED. v1->v2: -Remove hw_tc_offload parameter. -Update all patches with Cc of MAINTAINERS. -Add more description in commit message for device specific parameter. -Add a new Documentation/networking/devlink-params.txt with some generic devlink parameters information. -Add a new Documentation/networking/devlink-params-bnxt_en.txt with devlink parameters information that are supported by bnxt_en driver. Vasundhara Volam (9): devlink: Add generic parameter ignore_ari devlink: Add generic parameter msix_vec_per_pf_max devlink: Add generic parameter msix_vec_per_pf_min bnxt_en: Use ignore_ari devlink parameter bnxt_en: return proper error when FW returns HWRM_ERR_CODE_RESOURCE_ACCESS_DENIED bnxt_en: Use msix_vec_per_pf_max and msix_vec_per_pf_min devlink params. bnxt_en: Add a driver specific gre_ver_check devlink parameter. devlink: Add Documentation/networking/devlink-params.txt devlink: Add Documentation/networking/devlink-params-bnxt.txt Documentation/networking/devlink-params-bnxt.txt | 35 + Documentation/networking/devlink-params.txt | 42 +++ drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c | 86 +-- drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h | 8 +++ include/net/devlink.h | 12 net/core/devlink.c| 15 6 files changed, 194 insertions(+), 4 deletions(-) create mode 100644 Documentation/networking/devlink-params-bnxt.txt create mode 100644 Documentation/networking/devlink-params.txt -- 1.8.3.1
[PATCH v2 net-next 5/9] bnxt_en: return proper error when FW returns HWRM_ERR_CODE_RESOURCE_ACCESS_DENIED
Return proper error code when Firmware returns
HWRM_ERR_CODE_RESOURCE_ACCESS_DENIED for HWRM_NVM_GET/SET_VARIABLE
commands.
Cc: Michael Chan
Signed-off-by: Vasundhara Volam
---
drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
index 58e3061..1b25e3a 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
@@ -77,8 +77,12 @@ static int bnxt_hwrm_nvm_req(struct bnxt *bp, u32 param_id,
void *msg,
memcpy(buf, data_addr, bytesize);
dma_free_coherent(&bp->pdev->dev, bytesize, data_addr, data_dma_addr);
- if (rc)
+ if (rc == HWRM_ERR_CODE_RESOURCE_ACCESS_DENIED) {
+ netdev_err(bp->dev, "PF does not have admin privileges to
modify NVM config\n");
+ return -EACCES;
+ } else if (rc) {
return -EIO;
+ }
return 0;
}
--
1.8.3.1
Re: [PATCH net 00/15] netpoll: avoid capture effects for NAPI drivers
From: Eric Dumazet Date: Fri, 21 Sep 2018 15:27:37 -0700 > As diagnosed by Song Liu, ndo_poll_controller() can > be very dangerous on loaded hosts, since the cpu > calling ndo_poll_controller() might steal all NAPI > contexts (for all RX/TX queues of the NIC). > > This capture, showing one ksoftirqd eating all cycles > can last for unlimited amount of time, since one > cpu is generally not able to drain all the queues under load. > > It seems that all networking drivers that do use NAPI > for their TX completions, should not provide a ndo_poll_controller() : > > Most NAPI drivers have netpoll support already handled > in core networking stack, since netpoll_poll_dev() > uses poll_napi(dev) to iterate through registered > NAPI contexts for a device. > > This patch series take care of the first round, we will > handle other drivers in future rounds. Series applied, thanks Eric.
Re: [PATCH net-next] mlxsw: Make MLXSW_SP1_FWREV_MINOR a hard requirement
On Mon, Sep 24, 2018 at 12:04:17AM +0200, Andrew Lunn wrote: > On Mon, Sep 24, 2018 at 12:51:00AM +0300, Ido Schimmel wrote: > > On Sun, Sep 23, 2018 at 10:58:09PM +0200, Andrew Lunn wrote: > > > > Therefore tweak the check to accept any FW version that is: > > > > > > > > - on the same branch as the preferred version, and > > > > - the same as or newer than the preferred version. > > > > > > Hi Ido > > > > > > Do you print this information out? If the check fails, it would be > > > useful to know what the minimal version is. > > > > Hi Andrew, > > > > Yes, we do print it. It is the version the driver will try to load > > during initialization in case current version is incompatible: > > > > dev_info(mlxsw_sp->bus_info->dev, "Flashing firmware using file %s\n", > > fw_filename); > > Ah. O.K. Thanks. > > But doesn't that mean you reflash the device with the minimum version, > when in fact there could be a much newer version in /lib/firmware? No, because we always enforce the latest version we post to linux-firmware. We try to keep firmware updates at a minimum, so if we decided to post a new version it's either because the driver now requires a feature from this version (which makes older versions incompatible) or because a critical bug was fixed in that version.
Re: [PATCH net-next] mlxsw: Make MLXSW_SP1_FWREV_MINOR a hard requirement
On Mon, Sep 24, 2018 at 12:51:00AM +0300, Ido Schimmel wrote: > On Sun, Sep 23, 2018 at 10:58:09PM +0200, Andrew Lunn wrote: > > > Therefore tweak the check to accept any FW version that is: > > > > > > - on the same branch as the preferred version, and > > > - the same as or newer than the preferred version. > > > > Hi Ido > > > > Do you print this information out? If the check fails, it would be > > useful to know what the minimal version is. > > Hi Andrew, > > Yes, we do print it. It is the version the driver will try to load > during initialization in case current version is incompatible: > > dev_info(mlxsw_sp->bus_info->dev, "Flashing firmware using file %s\n", >fw_filename); Ah. O.K. Thanks. But doesn't that mean you reflash the device with the minimum version, when in fact there could be a much newer version in /lib/firmware? Andrew
Re: [PATCH net-next] mlxsw: Make MLXSW_SP1_FWREV_MINOR a hard requirement
On Sun, Sep 23, 2018 at 10:58:09PM +0200, Andrew Lunn wrote: > > Therefore tweak the check to accept any FW version that is: > > > > - on the same branch as the preferred version, and > > - the same as or newer than the preferred version. > > Hi Ido > > Do you print this information out? If the check fails, it would be > useful to know what the minimal version is. Hi Andrew, Yes, we do print it. It is the version the driver will try to load during initialization in case current version is incompatible: dev_info(mlxsw_sp->bus_info->dev, "Flashing firmware using file %s\n", fw_filename);
[net-next:master 13/221] drivers/net//ethernet/ni/nixge.c:145:2: note: in expansion of macro 'nixge_hw_dma_bd_set_addr'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git master head: 12ba7e1045521ec9f251c93ae0a6735cc3f42337 commit: 7e8d5755be0e6c92d3b86a85e54c6a550b1910c5 [13/221] net: nixge: Add support for 64-bit platforms config: i386-randconfig-x075-09240403 (attached as .config) compiler: gcc-7 (Debian 7.3.0-1) 7.3.0 reproduce: git checkout 7e8d5755be0e6c92d3b86a85e54c6a550b1910c5 # save the attached .config to linux build tree make ARCH=i386 All warnings (new ones prefixed by >>): drivers/net//ethernet/ni/nixge.c: In function 'nixge_hw_dma_bd_release': drivers/net//ethernet/ni/nixge.c:254:9: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] skb = (struct sk_buff *) ^ In file included from include/linux/skbuff.h:17:0, from include/linux/if_ether.h:23, from include/linux/etherdevice.h:25, from drivers/net//ethernet/ni/nixge.c:7: drivers/net//ethernet/ni/nixge.c: In function 'nixge_hw_dma_bd_init': drivers/net//ethernet/ni/nixge.c:130:37: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] (bd)->field##_lo = lower_32_bits(((u64)addr)); \ ^ include/linux/kernel.h:234:33: note: in definition of macro 'lower_32_bits' #define lower_32_bits(n) ((u32)(n)) ^ >> drivers/net//ethernet/ni/nixge.c:145:2: note: in expansion of macro >> 'nixge_hw_dma_bd_set_addr' nixge_hw_dma_bd_set_addr((bd), sw_id_offset, (addr)) ^~~~ >> drivers/net//ethernet/ni/nixge.c:326:3: note: in expansion of macro >> 'nixge_hw_dma_bd_set_offset' nixge_hw_dma_bd_set_offset(&priv->rx_bd_v[i], skb); ^~ drivers/net//ethernet/ni/nixge.c:131:37: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] (bd)->field##_hi = upper_32_bits(((u64)addr)); \ ^ include/linux/kernel.h:228:35: note: in definition of macro 'upper_32_bits' #define upper_32_bits(n) ((u32)(((n) >> 16) >> 16)) ^ >> drivers/net//ethernet/ni/nixge.c:145:2: note: in expansion of macro >> 'nixge_hw_dma_bd_set_addr' nixge_hw_dma_bd_set_addr((bd), sw_id_offset, (addr)) ^~~~ >> drivers/net//ethernet/ni/nixge.c:326:3: note: in expansion of macro >> 'nixge_hw_dma_bd_set_offset' nixge_hw_dma_bd_set_offset(&priv->rx_bd_v[i], skb); ^~ drivers/net//ethernet/ni/nixge.c: In function 'nixge_recv': drivers/net//ethernet/ni/nixge.c:604:9: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] skb = (struct sk_buff *)nixge_hw_dma_bd_get_addr(cur_p, ^ In file included from include/linux/skbuff.h:17:0, from include/linux/if_ether.h:23, from include/linux/etherdevice.h:25, from drivers/net//ethernet/ni/nixge.c:7: drivers/net//ethernet/ni/nixge.c:130:37: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] (bd)->field##_lo = lower_32_bits(((u64)addr)); \ ^ include/linux/kernel.h:234:33: note: in definition of macro 'lower_32_bits' #define lower_32_bits(n) ((u32)(n)) ^ >> drivers/net//ethernet/ni/nixge.c:145:2: note: in expansion of macro >> 'nixge_hw_dma_bd_set_addr' nixge_hw_dma_bd_set_addr((bd), sw_id_offset, (addr)) ^~~~ drivers/net//ethernet/ni/nixge.c:646:3: note: in expansion of macro 'nixge_hw_dma_bd_set_offset' nixge_hw_dma_bd_set_offset(cur_p, new_skb); ^~ drivers/net//ethernet/ni/nixge.c:131:37: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] (bd)->field##_hi = upper_32_bits(((u64)addr)); \ ^ include/linux/kernel.h:228:35: note: in definition of macro 'upper_32_bits' #define upper_32_bits(n) ((u32)(((n) >> 16) >> 16)) ^ >> drivers/net//ethernet/ni/nixge.c:145:2: note: in expansion of macro >> 'nixge_hw_dma_bd_set_addr' nixge_hw_dma_bd_set_addr((bd), sw_id_offset, (addr)) ^~~~ drivers/net//ethernet/ni/nixge.c:646:3: note: in expansion of macro 'nixge_hw_dma_bd_set_offset' nixge_hw_dma_bd_set_offset(cur_p, new_skb); ^~ vim +/nixge_hw_dma_bd_set_addr +145 drivers/net//ethernet/ni/nixge.c > 7 #include 8 #include 9 #include 10 #include 11 #include 12 #include 13 #include 14 #include 15 #include 16 #include 17 #include 18 #include 19 #include 20 #include 21 22 #define TX_BD_NUM
Re: [PATCH net-next] mlxsw: Make MLXSW_SP1_FWREV_MINOR a hard requirement
> Therefore tweak the check to accept any FW version that is: > > - on the same branch as the preferred version, and > - the same as or newer than the preferred version. Hi Ido Do you print this information out? If the check fails, it would be useful to know what the minimal version is. Andrew
Syrian Rescue
Dear Sir/Madam, My name is Rybak Ahmed from Syria. I am a miner and i wish to introduce my Gold/Diamonds funds which I and my partner sold. Because of the constant war going on in our country my partner and his family are all dead.Hence i take this upon myself to find trustworthy partners who will be able to partner with me to obtain the document needed, in order for us to receive our $6,200,000.00 which is currently in Bank of America escrow account. Please note that my attorney/broker will discuss further with you as to what is needed to obtain the change of name, from my partner's to yours. Your share will be 30% and send me 70% to my account that I will give you after you have receive the US$6,200,000.00 (six million and two hundred thousand dollars).You have nothing to lose. Just indicate your readiness by writing me back to my e-mail Looking forward to your interest. Sincerely, Rybak Ahmed
Re: [PATCH net 00/15] netpoll: avoid capture effects for NAPI drivers
On Sun, Sep 23, 2018 at 12:29 PM David Miller wrote: > > From: Eric Dumazet > Date: Fri, 21 Sep 2018 15:27:37 -0700 > > > As diagnosed by Song Liu, ndo_poll_controller() can > > be very dangerous on loaded hosts, since the cpu > > calling ndo_poll_controller() might steal all NAPI > > contexts (for all RX/TX queues of the NIC). > > > > This capture, showing one ksoftirqd eating all cycles > > can last for unlimited amount of time, since one > > cpu is generally not able to drain all the queues under load. > > > > It seems that all networking drivers that do use NAPI > > for their TX completions, should not provide a ndo_poll_controller() : > > > > Most NAPI drivers have netpoll support already handled > > in core networking stack, since netpoll_poll_dev() > > uses poll_napi(dev) to iterate through registered > > NAPI contexts for a device. > > I'm having trouble understanding the difference. > > If the drivers are processing all of the RX/TX queue draining by hand > in their ndo_poll_controller() method, how is that different from the > generic code walking all of the registererd NAPI instances one by one? (resent in plain text mode this time) Reading poll_napi() and poll_one_napi() I thought that we were using NAPI_STATE_NPSVC and cmpxchg(&napi->poll_owner, -1, cpu) to _temporary_ [1] own each napi at a time. But I do see we also have this part at the beginning of poll_one_napi() : if (!test_bit(NAPI_STATE_SCHED, &napi->state)) return; So we probably should remove it. (The normal napi->poll() calls would not proceed since napi->poll_owner would not be -1) [1] While if a cpu succeeds into setting NAPI_STATE_SCHED, it means it has to own it as long as the napi->poll() does not call napi_complete_done(), and this can be forever (the capture effect) Basically calling napi_schedule() is the dangerous part. I believe busy_polling and netpoll are the same intruders (as they can run on arbitrary cpus). But netpoll is far more problematic since it iterates through all RX/TX queues.
Re: [PATCH net v2] net: phy: fix WoL handling when suspending the PHY
On 23.09.2018 18:49, Florian Fainelli wrote:
>
>
> On September 23, 2018 6:38:21 AM PDT, Heiner Kallweit
> wrote:
>> Actually there's nothing wrong with the two changes marked as "Fixes",
>> they just revealed a problem which has been existing before.
>> After having switched r8169 to phylib it was reported that WoL from
>> shutdown doesn't work any longer (WoL from suspend isn't affected).
>> Reason is that during shutdown phy_disconnect()->phy_detach()->
>> phy_suspend() is called.
>> A similar issue occurs when the phylib state machine calls
>> phy_suspend() when handling state PHY_HALTED.
>>
>> Core of the problem is that phy_suspend() suspends the PHY when it
>> should not due to WoL. phy_suspend() checks for WoL already, but this
>> works only if the PHY driver handles WoL (what is rarely the case).
>> Typically WoL is handled by the MAC driver.
>>
>> phylib knows about this and handles it in mdio_bus_phy_may_suspend(),
>> but that's used only when suspending the system, not in other cases
>> like shutdown.
>>
>> Therefore factor out the relevant check from
>> mdio_bus_phy_may_suspend() to a new function phy_may_suspend() and
>> use it in phy_suspend().
>>
>> Last but not least change phy_detach() to call phy_suspend() before
>> attached_dev is set to NULL. phy_suspend() accesses attached_dev
>> when checking whether the MAC driver activated WoL.
>
> The rationale for the change makes sense but I am worried about a couple of
> things:
>
> - we have seen drivers fail to call SET_NETDEV_DEV() correctly, or sometimes
> it is made possible because they are Device Tree only objects without a
> backing parent struct device (CONFIG_OF makes it possible), so we could be
> missing some cases here but this is not a big deal
>
> - most Ethernet controller implementations typically set the device as a
> wake-up enabled device when an user issues the appropriate ethtool -s iface
> wol and not at driver probe or ndo_open() time. There are
> exceptions like ASIX USB Ethernet adapters that AFAIR are wake-up enabled all
> the time. The main concern here is that at the time of suspend
> device_may_wakeup() evaluates to true and we keep the PHY on even though the
> driver/user was not requesting for WoL per-se
>
> What you encode here is definitely the behavior that Ethernet controllers
> should have, but we should also audit drivers that use PHYLIB and implement
> WoL that this is not going to regresses their power management or ability to
> wake up from PHY, and finally, that there is not redundant code already in
> place.
>
Good points. It's somehow unfortunate that we don't have a clear info
whether WoL is enabled for a netdevice or not. Instead we have to
evaluate different hints and make an educated guess (which can be
wrong like in the potential cases you described).
One idea that comes to my mind: Add a flag wol_enabled to struct net_device
and set it in ethtool_set_wol. Then we could use this new flag in phy_suspend().
This would transparently fix the issue for the most common cases.
Still we would have to think about cases like WoL being enabled w/o explicitly
configuring it (e.g. BIOS enables WoL).
What do you think?
>>
>> Fixes: f1e911d5d0df ("r8169: add basic phylib support")
>> Fixes: e8cfd9d6c772 ("net: phy: call state machine synchronously in
>> phy_stop")
>> Signed-off-by: Heiner Kallweit
>> ---
>> v2:
>> - improved commit message
>> - reduced scope of patch, don't touch functionality of
>> mdio_bus_phy_suspend and mdio_bus_phy_resume
>> ---
>> drivers/net/phy/phy_device.c | 42 ++--
>> 1 file changed, 26 insertions(+), 16 deletions(-)
>>
>> diff --git a/drivers/net/phy/phy_device.c
>> b/drivers/net/phy/phy_device.c
>> index af64a9320..4cab94bae 100644
>> --- a/drivers/net/phy/phy_device.c
>> +++ b/drivers/net/phy/phy_device.c
>> @@ -75,6 +75,26 @@ extern struct phy_driver genphy_10g_driver;
>> static LIST_HEAD(phy_fixup_list);
>> static DEFINE_MUTEX(phy_fixup_lock);
>>
>> +static bool phy_may_suspend(struct phy_device *phydev)
>> +{
>> +struct net_device *netdev = phydev->attached_dev;
>> +
>> +if (!netdev)
>> +return true;
>> +
>> +/* Don't suspend PHY if the attached netdev parent may wakeup.
>> + * The parent may point to a PCI device, as in tg3 driver.
>> + */
>> +if (netdev->dev.parent && device_may_wakeup(netdev->dev.parent))
>> +return false;
>> +
>> +/* Also don't suspend PHY if the netdev itself may wakeup. This
>> + * is the case for devices w/o underlaying pwr. mgmt. aware bus,
>> + * e.g. SoC devices.
>> + */
>> +return !device_may_wakeup(&netdev->dev);
>> +}
>> +
>> #ifdef CONFIG_PM
>> static bool mdio_bus_phy_may_suspend(struct phy_device *phydev)
>> {
>> @@ -93,20 +113,7 @@ static bool mdio_bus_phy_may_suspend(struct
>> phy_device *phydev)
>> if (!netdev)
>> return !phydev->suspended;
>>
>> -/* Don't suspend PHY if the attached netdev paren
Re: [PATCH net 00/15] netpoll: avoid capture effects for NAPI drivers
From: Eric Dumazet Date: Fri, 21 Sep 2018 15:27:37 -0700 > As diagnosed by Song Liu, ndo_poll_controller() can > be very dangerous on loaded hosts, since the cpu > calling ndo_poll_controller() might steal all NAPI > contexts (for all RX/TX queues of the NIC). > > This capture, showing one ksoftirqd eating all cycles > can last for unlimited amount of time, since one > cpu is generally not able to drain all the queues under load. > > It seems that all networking drivers that do use NAPI > for their TX completions, should not provide a ndo_poll_controller() : > > Most NAPI drivers have netpoll support already handled > in core networking stack, since netpoll_poll_dev() > uses poll_napi(dev) to iterate through registered > NAPI contexts for a device. I'm having trouble understanding the difference. If the drivers are processing all of the RX/TX queue draining by hand in their ndo_poll_controller() method, how is that different from the generic code walking all of the registererd NAPI instances one by one?
Re: [PATCH net] devlink: double free in devlink_resource_fill()
Fri, Sep 21, 2018 at 10:07:55AM CEST, dan.carpen...@oracle.com wrote:
>Smatch reports that devlink_dpipe_send_and_alloc_skb() frees the skb
>on error so this is a double free. We fixed a bunch of these bugs in
>commit 7fe4d6dcbcb4 ("devlink: Remove redundant free on error path") but
>we accidentally overlooked this one.
>
>Fixes: d9f9b9a4d05f ("devlink: Add support for resource abstraction")
>Signed-off-by: Dan Carpenter
Acked-by: Jiri Pirko
Re: [PATCH net] af_key: free SKBs under RCU protection
On 09/20/2018 12:25 PM, stran...@codeaurora.org wrote:
> Perhaps a cleaner solution here is to always clone the SKB in
> pfkey_broadcast_one(). That will ensure that the two kfree_skb() calls
> in pfkey_broadcast() will never be passed an SKB with sock_rfree() as
> its destructor, and we can avoid this race condition.
Yes, this whole idea of avoiding the cloning is brain dead.
Better play safe and having a straightforward implementation.
I suggest something like this (I could not reproduce the bug with the syzkaller
repro)
Note that I removed the sock_hold(sk)/sock_put(sk) pair as this is useless.
The only time GFP_KERNEL might be used is when the sk is already owned by the
caller.
net/key/af_key.c | 40 +++-
1 file changed, 15 insertions(+), 25 deletions(-)
diff --git a/net/key/af_key.c b/net/key/af_key.c
index
9d61266526e767770d9a1ce184ac8cdd59de309a..7da629d5971712d5219528c55bad869bb084a343
100644
--- a/net/key/af_key.c
+++ b/net/key/af_key.c
@@ -196,30 +196,22 @@ static int pfkey_release(struct socket *sock)
return 0;
}
-static int pfkey_broadcast_one(struct sk_buff *skb, struct sk_buff **skb2,
- gfp_t allocation, struct sock *sk)
+static int pfkey_broadcast_one(struct sk_buff *skb, gfp_t allocation,
+ struct sock *sk)
{
int err = -ENOBUFS;
- sock_hold(sk);
- if (*skb2 == NULL) {
- if (refcount_read(&skb->users) != 1) {
- *skb2 = skb_clone(skb, allocation);
- } else {
- *skb2 = skb;
- refcount_inc(&skb->users);
- }
- }
- if (*skb2 != NULL) {
- if (atomic_read(&sk->sk_rmem_alloc) <= sk->sk_rcvbuf) {
- skb_set_owner_r(*skb2, sk);
- skb_queue_tail(&sk->sk_receive_queue, *skb2);
- sk->sk_data_ready(sk);
- *skb2 = NULL;
- err = 0;
- }
+ if (atomic_read(&sk->sk_rmem_alloc) > sk->sk_rcvbuf)
+ return err;
+
+ skb = skb_clone(skb, allocation);
+
+ if (skb) {
+ skb_set_owner_r(skb, sk);
+ skb_queue_tail(&sk->sk_receive_queue, skb);
+ sk->sk_data_ready(sk);
+ err = 0;
}
- sock_put(sk);
return err;
}
@@ -234,7 +226,6 @@ static int pfkey_broadcast(struct sk_buff *skb, gfp_t
allocation,
{
struct netns_pfkey *net_pfkey = net_generic(net, pfkey_net_id);
struct sock *sk;
- struct sk_buff *skb2 = NULL;
int err = -ESRCH;
/* XXX Do we need something like netlink_overrun? I think
@@ -253,7 +244,7 @@ static int pfkey_broadcast(struct sk_buff *skb, gfp_t
allocation,
* socket.
*/
if (pfk->promisc)
- pfkey_broadcast_one(skb, &skb2, GFP_ATOMIC, sk);
+ pfkey_broadcast_one(skb, GFP_ATOMIC, sk);
/* the exact target will be processed later */
if (sk == one_sk)
@@ -268,7 +259,7 @@ static int pfkey_broadcast(struct sk_buff *skb, gfp_t
allocation,
continue;
}
- err2 = pfkey_broadcast_one(skb, &skb2, GFP_ATOMIC, sk);
+ err2 = pfkey_broadcast_one(skb, GFP_ATOMIC, sk);
/* Error is cleared after successful sending to at least one
* registered KM */
@@ -278,9 +269,8 @@ static int pfkey_broadcast(struct sk_buff *skb, gfp_t
allocation,
rcu_read_unlock();
if (one_sk != NULL)
- err = pfkey_broadcast_one(skb, &skb2, allocation, one_sk);
+ err = pfkey_broadcast_one(skb, allocation, one_sk);
- kfree_skb(skb2);
kfree_skb(skb);
return err;
}
Re: [PATCH net v2] net: phy: fix WoL handling when suspending the PHY
On September 23, 2018 6:38:21 AM PDT, Heiner Kallweit
wrote:
>Actually there's nothing wrong with the two changes marked as "Fixes",
>they just revealed a problem which has been existing before.
>After having switched r8169 to phylib it was reported that WoL from
>shutdown doesn't work any longer (WoL from suspend isn't affected).
>Reason is that during shutdown phy_disconnect()->phy_detach()->
>phy_suspend() is called.
>A similar issue occurs when the phylib state machine calls
>phy_suspend() when handling state PHY_HALTED.
>
>Core of the problem is that phy_suspend() suspends the PHY when it
>should not due to WoL. phy_suspend() checks for WoL already, but this
>works only if the PHY driver handles WoL (what is rarely the case).
>Typically WoL is handled by the MAC driver.
>
>phylib knows about this and handles it in mdio_bus_phy_may_suspend(),
>but that's used only when suspending the system, not in other cases
>like shutdown.
>
>Therefore factor out the relevant check from
>mdio_bus_phy_may_suspend() to a new function phy_may_suspend() and
>use it in phy_suspend().
>
>Last but not least change phy_detach() to call phy_suspend() before
>attached_dev is set to NULL. phy_suspend() accesses attached_dev
>when checking whether the MAC driver activated WoL.
The rationale for the change makes sense but I am worried about a couple of
things:
- we have seen drivers fail to call SET_NETDEV_DEV() correctly, or sometimes it
is made possible because they are Device Tree only objects without a backing
parent struct device (CONFIG_OF makes it possible), so we could be missing some
cases here but this is not a big deal
- most Ethernet controller implementations typically set the device as a
wake-up enabled device when an user issues the appropriate ethtool -s iface wol
and not at driver probe or ndo_open() time. There are exceptions
like ASIX USB Ethernet adapters that AFAIR are wake-up enabled all the time.
The main concern here is that at the time of suspend device_may_wakeup()
evaluates to true and we keep the PHY on even though the driver/user was not
requesting for WoL per-se
What you encode here is definitely the behavior that Ethernet controllers
should have, but we should also audit drivers that use PHYLIB and implement WoL
that this is not going to regresses their power management or ability to wake
up from PHY, and finally, that there is not redundant code already in place.
>
>Fixes: f1e911d5d0df ("r8169: add basic phylib support")
>Fixes: e8cfd9d6c772 ("net: phy: call state machine synchronously in
>phy_stop")
>Signed-off-by: Heiner Kallweit
>---
>v2:
>- improved commit message
>- reduced scope of patch, don't touch functionality of
> mdio_bus_phy_suspend and mdio_bus_phy_resume
>---
> drivers/net/phy/phy_device.c | 42 ++--
> 1 file changed, 26 insertions(+), 16 deletions(-)
>
>diff --git a/drivers/net/phy/phy_device.c
>b/drivers/net/phy/phy_device.c
>index af64a9320..4cab94bae 100644
>--- a/drivers/net/phy/phy_device.c
>+++ b/drivers/net/phy/phy_device.c
>@@ -75,6 +75,26 @@ extern struct phy_driver genphy_10g_driver;
> static LIST_HEAD(phy_fixup_list);
> static DEFINE_MUTEX(phy_fixup_lock);
>
>+static bool phy_may_suspend(struct phy_device *phydev)
>+{
>+ struct net_device *netdev = phydev->attached_dev;
>+
>+ if (!netdev)
>+ return true;
>+
>+ /* Don't suspend PHY if the attached netdev parent may wakeup.
>+ * The parent may point to a PCI device, as in tg3 driver.
>+ */
>+ if (netdev->dev.parent && device_may_wakeup(netdev->dev.parent))
>+ return false;
>+
>+ /* Also don't suspend PHY if the netdev itself may wakeup. This
>+ * is the case for devices w/o underlaying pwr. mgmt. aware bus,
>+ * e.g. SoC devices.
>+ */
>+ return !device_may_wakeup(&netdev->dev);
>+}
>+
> #ifdef CONFIG_PM
> static bool mdio_bus_phy_may_suspend(struct phy_device *phydev)
> {
>@@ -93,20 +113,7 @@ static bool mdio_bus_phy_may_suspend(struct
>phy_device *phydev)
> if (!netdev)
> return !phydev->suspended;
>
>- /* Don't suspend PHY if the attached netdev parent may wakeup.
>- * The parent may point to a PCI device, as in tg3 driver.
>- */
>- if (netdev->dev.parent && device_may_wakeup(netdev->dev.parent))
>- return false;
>-
>- /* Also don't suspend PHY if the netdev itself may wakeup. This
>- * is the case for devices w/o underlaying pwr. mgmt. aware bus,
>- * e.g. SoC devices.
>- */
>- if (device_may_wakeup(&netdev->dev))
>- return false;
>-
>- return true;
>+ return phy_may_suspend(phydev);
> }
>
> static int mdio_bus_phy_suspend(struct device *dev)
>@@ -1132,9 +1139,9 @@ void phy_detach(struct phy_device *phydev)
> sysfs_remove_link(&dev->dev.kobj, "phydev");
> sysfs_remove_link(&phydev->mdio.dev.kobj, "attached_dev");
> }
>+ phy_suspend(p
[PATCH net-next] mlxsw: Make MLXSW_SP1_FWREV_MINOR a hard requirement
From: Petr Machata Up until now, mlxsw tolerated firmware versions that weren't exactly matching the required version, if the branch number matched. That allowed the users to test various firmware versions as long as they were on the right branch. On the other hand, it made it impossible for mlxsw to put a hard lower bound on a version that fixes all problems known to date. If a user had a somewhat older FW version installed, mlxsw would start up just fine, possibly performing non-optimally as it would use features that trigger problematic behavior. Therefore tweak the check to accept any FW version that is: - on the same branch as the preferred version, and - the same as or newer than the preferred version. Signed-off-by: Petr Machata Reviewed-by: Jiri Pirko Signed-off-by: Ido Schimmel --- drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c index 1fc20263b15b..33a024274a1f 100644 --- a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c +++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c @@ -331,7 +331,10 @@ static int mlxsw_sp_fw_rev_validate(struct mlxsw_sp *mlxsw_sp) return -EINVAL; } if (MLXSW_SP_FWREV_MINOR_TO_BRANCH(rev->minor) == - MLXSW_SP_FWREV_MINOR_TO_BRANCH(req_rev->minor)) + MLXSW_SP_FWREV_MINOR_TO_BRANCH(req_rev->minor) && + (rev->minor > req_rev->minor || +(rev->minor == req_rev->minor && + rev->subminor >= req_rev->subminor))) return 0; dev_info(mlxsw_sp->bus_info->dev, "The firmware version %d.%d.%d is incompatible with the driver\n", -- 2.17.1
Re: [PATCH RFT net-next 0/2] net: phy: Eliminate unnecessary soft
Hi, On Tue, Sep 18, 2018 at 06:35:03PM -0700, Florian Fainelli wrote: > Hi all, > > This patch series eliminates unnecessary software resets of the PHY. > This should hopefully not break anybody's hardware; but I would > appreciate testing to make sure this is is the case. > > Sorry for this long email list, I wanted to make sure I reached out to > all people who made changes to the Marvell PHY driver. > > Thank you! > > Florian Fainelli (2): > net: phy: Stop with excessive soft reset > net: phy: marvell: Avoid unnecessary soft reset > > drivers/net/phy/marvell.c| 63 > drivers/net/phy/phy_device.c | 2 -- > 2 files changed, 21 insertions(+), 44 deletions(-) > > -- > 2.17.1 > I tested your patches on our board with a Marvell 88E1510. Looks good! Tested-by: Clemens Gruber Clemens
[PATCH net v2] net: phy: fix WoL handling when suspending the PHY
Actually there's nothing wrong with the two changes marked as "Fixes",
they just revealed a problem which has been existing before.
After having switched r8169 to phylib it was reported that WoL from
shutdown doesn't work any longer (WoL from suspend isn't affected).
Reason is that during shutdown phy_disconnect()->phy_detach()->
phy_suspend() is called.
A similar issue occurs when the phylib state machine calls
phy_suspend() when handling state PHY_HALTED.
Core of the problem is that phy_suspend() suspends the PHY when it
should not due to WoL. phy_suspend() checks for WoL already, but this
works only if the PHY driver handles WoL (what is rarely the case).
Typically WoL is handled by the MAC driver.
phylib knows about this and handles it in mdio_bus_phy_may_suspend(),
but that's used only when suspending the system, not in other cases
like shutdown.
Therefore factor out the relevant check from
mdio_bus_phy_may_suspend() to a new function phy_may_suspend() and
use it in phy_suspend().
Last but not least change phy_detach() to call phy_suspend() before
attached_dev is set to NULL. phy_suspend() accesses attached_dev
when checking whether the MAC driver activated WoL.
Fixes: f1e911d5d0df ("r8169: add basic phylib support")
Fixes: e8cfd9d6c772 ("net: phy: call state machine synchronously in phy_stop")
Signed-off-by: Heiner Kallweit
---
v2:
- improved commit message
- reduced scope of patch, don't touch functionality of
mdio_bus_phy_suspend and mdio_bus_phy_resume
---
drivers/net/phy/phy_device.c | 42 ++--
1 file changed, 26 insertions(+), 16 deletions(-)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index af64a9320..4cab94bae 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -75,6 +75,26 @@ extern struct phy_driver genphy_10g_driver;
static LIST_HEAD(phy_fixup_list);
static DEFINE_MUTEX(phy_fixup_lock);
+static bool phy_may_suspend(struct phy_device *phydev)
+{
+ struct net_device *netdev = phydev->attached_dev;
+
+ if (!netdev)
+ return true;
+
+ /* Don't suspend PHY if the attached netdev parent may wakeup.
+* The parent may point to a PCI device, as in tg3 driver.
+*/
+ if (netdev->dev.parent && device_may_wakeup(netdev->dev.parent))
+ return false;
+
+ /* Also don't suspend PHY if the netdev itself may wakeup. This
+* is the case for devices w/o underlaying pwr. mgmt. aware bus,
+* e.g. SoC devices.
+*/
+ return !device_may_wakeup(&netdev->dev);
+}
+
#ifdef CONFIG_PM
static bool mdio_bus_phy_may_suspend(struct phy_device *phydev)
{
@@ -93,20 +113,7 @@ static bool mdio_bus_phy_may_suspend(struct phy_device
*phydev)
if (!netdev)
return !phydev->suspended;
- /* Don't suspend PHY if the attached netdev parent may wakeup.
-* The parent may point to a PCI device, as in tg3 driver.
-*/
- if (netdev->dev.parent && device_may_wakeup(netdev->dev.parent))
- return false;
-
- /* Also don't suspend PHY if the netdev itself may wakeup. This
-* is the case for devices w/o underlaying pwr. mgmt. aware bus,
-* e.g. SoC devices.
-*/
- if (device_may_wakeup(&netdev->dev))
- return false;
-
- return true;
+ return phy_may_suspend(phydev);
}
static int mdio_bus_phy_suspend(struct device *dev)
@@ -1132,9 +1139,9 @@ void phy_detach(struct phy_device *phydev)
sysfs_remove_link(&dev->dev.kobj, "phydev");
sysfs_remove_link(&phydev->mdio.dev.kobj, "attached_dev");
}
+ phy_suspend(phydev);
phydev->attached_dev->phydev = NULL;
phydev->attached_dev = NULL;
- phy_suspend(phydev);
phydev->phylink = NULL;
phy_led_triggers_unregister(phydev);
@@ -1171,9 +1178,12 @@ int phy_suspend(struct phy_device *phydev)
struct ethtool_wolinfo wol = { .cmd = ETHTOOL_GWOL };
int ret = 0;
+ if (phydev->suspended)
+ return 0;
+
/* If the device has WOL enabled, we cannot suspend the PHY */
phy_ethtool_get_wol(phydev, &wol);
- if (wol.wolopts)
+ if (wol.wolopts || !phy_may_suspend(phydev))
return -EBUSY;
if (phydev->drv && phydrv->suspend)
--
2.19.0
Re: [PATCH net v2] net: phy: fix WoL handling when suspending the PHY
Sorry, this patch was accidentally sent as reply.
On 23.09.2018 15:33, Heiner Kallweit wrote:
> Actually there's nothing wrong with the two changes marked as "Fixes",
> they just revealed a problem which has been existing before.
> After having switched r8169 to phylib it was reported that WoL from
> shutdown doesn't work any longer (WoL from suspend isn't affected).
> Reason is that during shutdown phy_disconnect()->phy_detach()->
> phy_suspend() is called.
> A similar issue occurs when the phylib state machine calls
> phy_suspend() when handling state PHY_HALTED.
>
> Core of the problem is that phy_suspend() suspends the PHY when it
> should not due to WoL. phy_suspend() checks for WoL already, but this
> works only if the PHY driver handles WoL (what is rarely the case).
> Typically WoL is handled by the MAC driver.
>
> phylib knows about this and handles it in mdio_bus_phy_may_suspend(),
> but that's used only when suspending the system, not in other cases
> like shutdown.
>
> Therefore factor out the relevant check from
> mdio_bus_phy_may_suspend() to a new function phy_may_suspend() and
> use it in phy_suspend().
>
> Last but not least change phy_detach() to call phy_suspend() before
> attached_dev is set to NULL. phy_suspend() accesses attached_dev
> when checking whether the MAC driver activated WoL.
>
> Fixes: f1e911d5d0df ("r8169: add basic phylib support")
> Fixes: e8cfd9d6c772 ("net: phy: call state machine synchronously in phy_stop")
> Signed-off-by: Heiner Kallweit
> ---
> v2:
> - improved commit message
> - reduced scope of patch, don't touch functionality of
> mdio_bus_phy_suspend and mdio_bus_phy_resume
> ---
> drivers/net/phy/phy_device.c | 42 ++--
> 1 file changed, 26 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
> index af64a9320..4cab94bae 100644
> --- a/drivers/net/phy/phy_device.c
> +++ b/drivers/net/phy/phy_device.c
> @@ -75,6 +75,26 @@ extern struct phy_driver genphy_10g_driver;
> static LIST_HEAD(phy_fixup_list);
> static DEFINE_MUTEX(phy_fixup_lock);
>
> +static bool phy_may_suspend(struct phy_device *phydev)
> +{
> + struct net_device *netdev = phydev->attached_dev;
> +
> + if (!netdev)
> + return true;
> +
> + /* Don't suspend PHY if the attached netdev parent may wakeup.
> + * The parent may point to a PCI device, as in tg3 driver.
> + */
> + if (netdev->dev.parent && device_may_wakeup(netdev->dev.parent))
> + return false;
> +
> + /* Also don't suspend PHY if the netdev itself may wakeup. This
> + * is the case for devices w/o underlaying pwr. mgmt. aware bus,
> + * e.g. SoC devices.
> + */
> + return !device_may_wakeup(&netdev->dev);
> +}
> +
> #ifdef CONFIG_PM
> static bool mdio_bus_phy_may_suspend(struct phy_device *phydev)
> {
> @@ -93,20 +113,7 @@ static bool mdio_bus_phy_may_suspend(struct phy_device
> *phydev)
> if (!netdev)
> return !phydev->suspended;
>
> - /* Don't suspend PHY if the attached netdev parent may wakeup.
> - * The parent may point to a PCI device, as in tg3 driver.
> - */
> - if (netdev->dev.parent && device_may_wakeup(netdev->dev.parent))
> - return false;
> -
> - /* Also don't suspend PHY if the netdev itself may wakeup. This
> - * is the case for devices w/o underlaying pwr. mgmt. aware bus,
> - * e.g. SoC devices.
> - */
> - if (device_may_wakeup(&netdev->dev))
> - return false;
> -
> - return true;
> + return phy_may_suspend(phydev);
> }
>
> static int mdio_bus_phy_suspend(struct device *dev)
> @@ -1132,9 +1139,9 @@ void phy_detach(struct phy_device *phydev)
> sysfs_remove_link(&dev->dev.kobj, "phydev");
> sysfs_remove_link(&phydev->mdio.dev.kobj, "attached_dev");
> }
> + phy_suspend(phydev);
> phydev->attached_dev->phydev = NULL;
> phydev->attached_dev = NULL;
> - phy_suspend(phydev);
> phydev->phylink = NULL;
>
> phy_led_triggers_unregister(phydev);
> @@ -1171,9 +1178,12 @@ int phy_suspend(struct phy_device *phydev)
> struct ethtool_wolinfo wol = { .cmd = ETHTOOL_GWOL };
> int ret = 0;
>
> + if (phydev->suspended)
> + return 0;
> +
> /* If the device has WOL enabled, we cannot suspend the PHY */
> phy_ethtool_get_wol(phydev, &wol);
> - if (wol.wolopts)
> + if (wol.wolopts || !phy_may_suspend(phydev))
> return -EBUSY;
>
> if (phydev->drv && phydrv->suspend)
>
[PATCH net v2] net: phy: fix WoL handling when suspending the PHY
Actually there's nothing wrong with the two changes marked as "Fixes",
they just revealed a problem which has been existing before.
After having switched r8169 to phylib it was reported that WoL from
shutdown doesn't work any longer (WoL from suspend isn't affected).
Reason is that during shutdown phy_disconnect()->phy_detach()->
phy_suspend() is called.
A similar issue occurs when the phylib state machine calls
phy_suspend() when handling state PHY_HALTED.
Core of the problem is that phy_suspend() suspends the PHY when it
should not due to WoL. phy_suspend() checks for WoL already, but this
works only if the PHY driver handles WoL (what is rarely the case).
Typically WoL is handled by the MAC driver.
phylib knows about this and handles it in mdio_bus_phy_may_suspend(),
but that's used only when suspending the system, not in other cases
like shutdown.
Therefore factor out the relevant check from
mdio_bus_phy_may_suspend() to a new function phy_may_suspend() and
use it in phy_suspend().
Last but not least change phy_detach() to call phy_suspend() before
attached_dev is set to NULL. phy_suspend() accesses attached_dev
when checking whether the MAC driver activated WoL.
Fixes: f1e911d5d0df ("r8169: add basic phylib support")
Fixes: e8cfd9d6c772 ("net: phy: call state machine synchronously in phy_stop")
Signed-off-by: Heiner Kallweit
---
v2:
- improved commit message
- reduced scope of patch, don't touch functionality of
mdio_bus_phy_suspend and mdio_bus_phy_resume
---
drivers/net/phy/phy_device.c | 42 ++--
1 file changed, 26 insertions(+), 16 deletions(-)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index af64a9320..4cab94bae 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -75,6 +75,26 @@ extern struct phy_driver genphy_10g_driver;
static LIST_HEAD(phy_fixup_list);
static DEFINE_MUTEX(phy_fixup_lock);
+static bool phy_may_suspend(struct phy_device *phydev)
+{
+ struct net_device *netdev = phydev->attached_dev;
+
+ if (!netdev)
+ return true;
+
+ /* Don't suspend PHY if the attached netdev parent may wakeup.
+* The parent may point to a PCI device, as in tg3 driver.
+*/
+ if (netdev->dev.parent && device_may_wakeup(netdev->dev.parent))
+ return false;
+
+ /* Also don't suspend PHY if the netdev itself may wakeup. This
+* is the case for devices w/o underlaying pwr. mgmt. aware bus,
+* e.g. SoC devices.
+*/
+ return !device_may_wakeup(&netdev->dev);
+}
+
#ifdef CONFIG_PM
static bool mdio_bus_phy_may_suspend(struct phy_device *phydev)
{
@@ -93,20 +113,7 @@ static bool mdio_bus_phy_may_suspend(struct phy_device
*phydev)
if (!netdev)
return !phydev->suspended;
- /* Don't suspend PHY if the attached netdev parent may wakeup.
-* The parent may point to a PCI device, as in tg3 driver.
-*/
- if (netdev->dev.parent && device_may_wakeup(netdev->dev.parent))
- return false;
-
- /* Also don't suspend PHY if the netdev itself may wakeup. This
-* is the case for devices w/o underlaying pwr. mgmt. aware bus,
-* e.g. SoC devices.
-*/
- if (device_may_wakeup(&netdev->dev))
- return false;
-
- return true;
+ return phy_may_suspend(phydev);
}
static int mdio_bus_phy_suspend(struct device *dev)
@@ -1132,9 +1139,9 @@ void phy_detach(struct phy_device *phydev)
sysfs_remove_link(&dev->dev.kobj, "phydev");
sysfs_remove_link(&phydev->mdio.dev.kobj, "attached_dev");
}
+ phy_suspend(phydev);
phydev->attached_dev->phydev = NULL;
phydev->attached_dev = NULL;
- phy_suspend(phydev);
phydev->phylink = NULL;
phy_led_triggers_unregister(phydev);
@@ -1171,9 +1178,12 @@ int phy_suspend(struct phy_device *phydev)
struct ethtool_wolinfo wol = { .cmd = ETHTOOL_GWOL };
int ret = 0;
+ if (phydev->suspended)
+ return 0;
+
/* If the device has WOL enabled, we cannot suspend the PHY */
phy_ethtool_get_wol(phydev, &wol);
- if (wol.wolopts)
+ if (wol.wolopts || !phy_may_suspend(phydev))
return -EBUSY;
if (phydev->drv && phydrv->suspend)
--
2.19.0
Re: [PATCH net-next 1/5] net: allow binding socket in a VRF when there's an unbound socket
Hi Robert,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on net-next/master]
url:
https://github.com/0day-ci/linux/commits/Mike-Manning/vrf-allow-simultaneous-service-instances-in-default-and-other-VRFs/20180923-162308
config: i386-randconfig-x0-09231642 (attached as .config)
compiler: gcc-5 (Debian 5.5.0-3) 5.4.1 20171010
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
In file included from include/net/tcp.h:36:0,
from net/ipv6/af_inet6.c:51:
include/net/inet_hashtables.h: In function 'inet_sk_bound_dev_eq':
>> include/net/inet_hashtables.h:196:28: error: 'struct netns_ipv4' has no
>> member named 'sysctl_tcp_l3mdev_accept'
return !sdif || net->ipv4.sysctl_tcp_l3mdev_accept;
^
vim +196 include/net/inet_hashtables.h
191
192 static inline bool inet_sk_bound_dev_eq(struct net *net, int
bound_dev_if,
193 int dif, int sdif)
194 {
195 if (!bound_dev_if)
> 196 return !sdif || net->ipv4.sysctl_tcp_l3mdev_accept;
197 return bound_dev_if == dif || bound_dev_if == sdif;
198 }
199
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH net-next 1/5] net: allow binding socket in a VRF when there's an unbound socket
Hi Robert,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on net-next/master]
url:
https://github.com/0day-ci/linux/commits/Mike-Manning/vrf-allow-simultaneous-service-instances-in-default-and-other-VRFs/20180923-162308
config: x86_64-randconfig-x004-201838 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
In file included from include/net/tcp.h:36:0,
from net/core/sock.c:143:
include/net/inet_hashtables.h: In function 'inet_sk_bound_dev_eq':
>> include/net/inet_hashtables.h:196:29: error: 'struct netns_ipv4' has no
>> member named 'sysctl_tcp_l3mdev_accept'; did you mean
>> 'sysctl_tcp_fwmark_accept'?
return !sdif || net->ipv4.sysctl_tcp_l3mdev_accept;
^~~~
sysctl_tcp_fwmark_accept
vim +196 include/net/inet_hashtables.h
191
192 static inline bool inet_sk_bound_dev_eq(struct net *net, int
bound_dev_if,
193 int dif, int sdif)
194 {
195 if (!bound_dev_if)
> 196 return !sdif || net->ipv4.sysctl_tcp_l3mdev_accept;
197 return bound_dev_if == dif || bound_dev_if == sdif;
198 }
199
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
[PATCH] iavh: fix a typo
This trivial patch fixes a typo in iavf.h.
Signed-off-by: Rami Rosen
---
drivers/net/ethernet/intel/iavf/iavf.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/iavf/iavf.h
b/drivers/net/ethernet/intel/iavf/iavf.h
index a512f7521841..272d76b733aa 100644
--- a/drivers/net/ethernet/intel/iavf/iavf.h
+++ b/drivers/net/ethernet/intel/iavf/iavf.h
@@ -342,7 +342,7 @@ struct iavf_adapter {
struct iavf_channel_config ch_config;
u8 num_tc;
struct list_head cloud_filter_list;
- /* lock to protest access to the cloud filter list */
+ /* lock to protect access to the cloud filter list */
spinlock_t cloud_filter_list_lock;
u16 num_cloud_filters;
};
--
2.17.1
