* Re: [PATCH net-next v3 06/10] net/mlx5e: Change Mellanox references in DIM code
From: Saeed Mahameed @ 2018-01-09 7:06 UTC (permalink / raw)
To: Andy Gospodarek, netdev; +Cc: mchan, talgi, ogerlitz, Andy Gospodarek
In-Reply-To: <1515478402-6048-7-git-send-email-andy@greyhouse.net>
On 01/08/2018 10:13 PM, Andy Gospodarek wrote:
> From: Andy Gospodarek <gospo@broadcom.com>
>
> Change all appropriate mlx5_am* and MLX5_AM* references to net_dim and
> NET_DIM, respectively, in code that handles dynamic interrupt
> moderation. Also change all references from 'am' to 'dim' when used as
> local variables and add generic profile references.
>
> Signed-off-by: Andy Gospodarek <gospo@broadcom.com>
> Acked-by: Tal Gilboa <talgi@mellanox.com>
> Acked-by: Saeed Mahameed <saeedm@mellanox.com>
> ---
> drivers/net/ethernet/mellanox/mlx5/core/en.h | 9 +-
> drivers/net/ethernet/mellanox/mlx5/core/en_dim.c | 14 +-
> .../net/ethernet/mellanox/mlx5/core/en_ethtool.c | 6 +-
> drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 40 ++-
> drivers/net/ethernet/mellanox/mlx5/core/en_txrx.c | 8 +-
> drivers/net/ethernet/mellanox/mlx5/core/net_dim.c | 286 ++++++++++-----------
> drivers/net/ethernet/mellanox/mlx5/core/net_dim.h | 63 ++---
> 7 files changed, 225 insertions(+), 201 deletions(-)
>
[...]
>
> #define IS_SIGNIFICANT_DIFF(val, ref) \
> (((100 * abs((val) - (ref))) / (ref)) > 10) /* more than 10% difference */
>
> -static int mlx5e_am_stats_compare(struct mlx5e_rx_am_stats *curr,
> - struct mlx5e_rx_am_stats *prev)
> +static int net_dim_stats_compare(struct net_dim_stats *curr,
> + struct net_dim_stats *prev)
> {
> if (!prev->bpms)
> - return curr->bpms ? MLX5E_AM_STATS_BETTER :
> - MLX5E_AM_STATS_SAME;
> + return curr->bpms ? NET_DIM_STATS_BETTER :
> + NET_DIM_STATS_SAME;
>
> if (IS_SIGNIFICANT_DIFF(curr->bpms, prev->bpms))
> - return (curr->bpms > prev->bpms) ? MLX5E_AM_STATS_BETTER :
> - MLX5E_AM_STATS_WORSE;
> + return (curr->bpms > prev->bpms) ? NET_DIM_STATS_BETTER :
> + NET_DIM_STATS_WORSE;
>
Hey Andy,
I am currently reviewing a patch internally that fixes a bug in this
area, prev->ppms can be 0 and could cause IS_SIGNIFICANT_DIFF ouch !
same goes for prev->eppm, for some reason we had a broken assumption
that if ppms is 0 for some reason then the bpms is 0 and the above
condition will cover us.
Anyway the patch will go to net, which means when this series gets
accepted then net-next will fail to merge with net and we need to
manually push the fix to the new DIM library.
But for now I don't think anything is required for this series other
than bringing this division by 0 issue and the future merge conflict to
your attention.
> if (IS_SIGNIFICANT_DIFF(curr->ppms, prev->ppms))
> - return (curr->ppms > prev->ppms) ? MLX5E_AM_STATS_BETTER :
> - MLX5E_AM_STATS_WORSE;
> + return (curr->ppms > prev->ppms) ? NET_DIM_STATS_BETTER :
> + NET_DIM_STATS_WORSE;
>
> if (IS_SIGNIFICANT_DIFF(curr->epms, prev->epms))
> - return (curr->epms < prev->epms) ? MLX5E_AM_STATS_BETTER :
> - MLX5E_AM_STATS_WORSE;
> + return (curr->epms < prev->epms) ? NET_DIM_STATS_BETTER :
> + NET_DIM_STATS_WORSE;
>
> - return MLX5E_AM_STATS_SAME;
> + return NET_DIM_STATS_SAME;
> }
>
^ permalink raw reply
* Re: [PATCH net-next v3 09/10] bnxt_en: add support for software dynamic interrupt moderation
From: Michael Chan @ 2018-01-09 7:07 UTC (permalink / raw)
To: Andy Gospodarek
Cc: Netdev, michael.chan@broadcom.com, talgi, ogerlitz,
Andy Gospodarek
In-Reply-To: <1515478402-6048-10-git-send-email-andy@greyhouse.net>
On Mon, Jan 8, 2018 at 10:13 PM, Andy Gospodarek <andy@greyhouse.net> wrote:
> From: Andy Gospodarek <gospo@broadcom.com>
>
> This implements the changes needed for the bnxt_en driver to add support
> for dynamic interrupt moderation per ring.
>
> This does add additional counters in the receive path, but testing shows
> that any additional instructions are offset by throughput gain when the
> default configuration is for low latency.
>
> Signed-off-by: Andy Gospodarek <gospo@broadcom.com>
> Cc: Michael Chan <mchan@broadcom.com>
Acked-by: Michael Chan <michael.chan@broadcom.com>
^ permalink raw reply
* Re: [PATCH net-next v3 06/10] net/mlx5e: Change Mellanox references in DIM code
From: Saeed Mahameed @ 2018-01-09 7:09 UTC (permalink / raw)
To: Andy Gospodarek, netdev; +Cc: mchan, talgi, ogerlitz, Andy Gospodarek
In-Reply-To: <47ddff01-23f9-5364-0dd4-b7c921512812@mellanox.com>
On 01/08/2018 11:06 PM, Saeed Mahameed wrote:
>
>
> On 01/08/2018 10:13 PM, Andy Gospodarek wrote:
>> From: Andy Gospodarek <gospo@broadcom.com>
>>
>> Change all appropriate mlx5_am* and MLX5_AM* references to net_dim and
>> NET_DIM, respectively, in code that handles dynamic interrupt
>> moderation. Also change all references from 'am' to 'dim' when used as
>> local variables and add generic profile references.
>>
>> Signed-off-by: Andy Gospodarek <gospo@broadcom.com>
>> Acked-by: Tal Gilboa <talgi@mellanox.com>
>> Acked-by: Saeed Mahameed <saeedm@mellanox.com>
>> ---
>> drivers/net/ethernet/mellanox/mlx5/core/en.h | 9 +-
>> drivers/net/ethernet/mellanox/mlx5/core/en_dim.c | 14 +-
>> .../net/ethernet/mellanox/mlx5/core/en_ethtool.c | 6 +-
>> drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 40 ++-
>> drivers/net/ethernet/mellanox/mlx5/core/en_txrx.c | 8 +-
>> drivers/net/ethernet/mellanox/mlx5/core/net_dim.c | 286
>> ++++++++++-----------
>> drivers/net/ethernet/mellanox/mlx5/core/net_dim.h | 63 ++---
>> 7 files changed, 225 insertions(+), 201 deletions(-)
>>
>
> [...]
>
>> #define IS_SIGNIFICANT_DIFF(val, ref) \
>> (((100 * abs((val) - (ref))) / (ref)) > 10) /* more than 10%
>> difference */
>> -static int mlx5e_am_stats_compare(struct mlx5e_rx_am_stats *curr,
>> - struct mlx5e_rx_am_stats *prev)
>> +static int net_dim_stats_compare(struct net_dim_stats *curr,
>> + struct net_dim_stats *prev)
>> {
>> if (!prev->bpms)
>> - return curr->bpms ? MLX5E_AM_STATS_BETTER :
>> - MLX5E_AM_STATS_SAME;
>> + return curr->bpms ? NET_DIM_STATS_BETTER :
>> + NET_DIM_STATS_SAME;
>> if (IS_SIGNIFICANT_DIFF(curr->bpms, prev->bpms))
>> - return (curr->bpms > prev->bpms) ? MLX5E_AM_STATS_BETTER :
>> - MLX5E_AM_STATS_WORSE;
>> + return (curr->bpms > prev->bpms) ? NET_DIM_STATS_BETTER :
>> + NET_DIM_STATS_WORSE;
>
> Hey Andy,
>
> I am currently reviewing a patch internally that fixes a bug in this
> area, prev->ppms can be 0 and could cause IS_SIGNIFICANT_DIFF ouch !
I meant cause division by 0 in "IS_SIGNIFICANT_DIFF"
> same goes for prev->eppm, for some reason we had a broken assumption
> that if ppms is 0 for some reason then the bpms is 0 and the above
> condition will cover us.
>
> Anyway the patch will go to net, which means when this series gets
> accepted then net-next will fail to merge with net and we need to
> manually push the fix to the new DIM library.
>
> But for now I don't think anything is required for this series other
> than bringing this division by 0 issue and the future merge conflict to
> your attention.
>
>> if (IS_SIGNIFICANT_DIFF(curr->ppms, prev->ppms))
>> - return (curr->ppms > prev->ppms) ? MLX5E_AM_STATS_BETTER :
>> - MLX5E_AM_STATS_WORSE;
>> + return (curr->ppms > prev->ppms) ? NET_DIM_STATS_BETTER :
>> + NET_DIM_STATS_WORSE;
>> if (IS_SIGNIFICANT_DIFF(curr->epms, prev->epms))
>> - return (curr->epms < prev->epms) ? MLX5E_AM_STATS_BETTER :
>> - MLX5E_AM_STATS_WORSE;
>> + return (curr->epms < prev->epms) ? NET_DIM_STATS_BETTER :
>> + NET_DIM_STATS_WORSE;
>> - return MLX5E_AM_STATS_SAME;
>> + return NET_DIM_STATS_SAME;
>> }
^ permalink raw reply
* Re: [PATCH] ath9k: add a quirk to set use_msi automatically
From: Kalle Valo @ 2018-01-09 7:29 UTC (permalink / raw)
To: AceLan Kao, Larry.Finger
Cc: QCA ath9k Development, linux-wireless, netdev, linux-kernel
In-Reply-To: <1515461962-27129-1-git-send-email-acelan.kao@canonical.com>
AceLan Kao <acelan.kao@canonical.com> writes:
> Some platform(BIOS) blocks legacy interrupts (INTx), and only allows MSI
> for WLAN device. So adding a quirk to list those machines and set
> use_msi automatically.
> Adding the following platforms to the quirk.
> Dell Inspiron 24-3460
> Dell Inspiron 3472
> Dell Inspiron 14-3473
> Dell Vostro 3262
> Dell Vostro 15-3572
>
> Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
[...]
> @@ -96,6 +97,56 @@ static const struct ieee80211_tpt_blink ath9k_tpt_blink[] = {
> };
> #endif
>
> +static int __init set_use_msi(const struct dmi_system_id *dmi)
> +{
> + ath9k_use_msi = 1;
> + return 1;
> +}
> +
> +static const struct dmi_system_id ath9k_quirks[] __initconst = {
> + {
> + .callback = set_use_msi,
> + .ident = "Dell Inspiron 24-3460",
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
> + DMI_MATCH(DMI_PRODUCT_NAME, "Inspiron 24-3460"),
> + },
> + },
Larry, didn't rtlwifi have similar situation that with certain laptops
users were required to enable a module parameter to get the device
working? I think rtlwifi should do the same as AceLan does here as then
the user would not need to manually set the module parameter.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH net-next 1/3] ethtool: Ensure new ring parameters are within bounds during SRINGPARAM
From: Tariq Toukan @ 2018-01-09 7:30 UTC (permalink / raw)
To: Jakub Kicinski, Tariq Toukan
Cc: David S. Miller, netdev, Eran Ben Elisha, Eugenia Emantayev
In-Reply-To: <20180108182342.084c5d60@cakuba.netronome.com>
On 09/01/2018 4:23 AM, Jakub Kicinski wrote:
> On Mon, 8 Jan 2018 16:00:24 +0200, Tariq Toukan wrote:
>> From: Eugenia Emantayev <eugenia@mellanox.com>
>>
>> Add a sanity check to ensure that all requested ring parameters
>> are within bounds, which should reduce errors in driver implementation.
>
> (y)
>
>> Signed-off-by: Eugenia Emantayev <eugenia@mellanox.com>
>> Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
>> ---
>> net/core/ethtool.c | 13 +++++++++++--
>> 1 file changed, 11 insertions(+), 2 deletions(-)
>>
>> diff --git a/net/core/ethtool.c b/net/core/ethtool.c
>> index 50a79203043b..9ea7cd52fde0 100644
>> --- a/net/core/ethtool.c
>> +++ b/net/core/ethtool.c
>> @@ -1704,14 +1704,23 @@ static int ethtool_get_ringparam(struct net_device *dev, void __user *useraddr)
>>
>> static int ethtool_set_ringparam(struct net_device *dev, void __user *useraddr)
>> {
>> - struct ethtool_ringparam ringparam;
>> + struct ethtool_ringparam ringparam, max = { .cmd = ETHTOOL_GRINGPARAM };
>>
>> - if (!dev->ethtool_ops->set_ringparam)
>> + if (!dev->ethtool_ops->set_ringparam || !dev->ethtool_ops->get_ringparam)
>> return -EOPNOTSUPP;
>>
>> if (copy_from_user(&ringparam, useraddr, sizeof(ringparam)))
>> return -EFAULT;
>>
>> + dev->ethtool_ops->get_ringparam(dev, &max);
>
> Perhaps check the return value here? It's pretty unlikely but
> get_ringparam may fail.
>
get_ringparam NDO returns void.
>> + /* ensure new ring parameters are within the maximums */
>> + if (ringparam.rx_pending > max.rx_max_pending ||
>> + ringparam.rx_mini_pending > max.rx_mini_max_pending ||
>> + ringparam.rx_jumbo_pending > max.rx_jumbo_max_pending ||
>> + ringparam.tx_pending > max.tx_max_pending)
>> + return -EINVAL;
>> +
>> return dev->ethtool_ops->set_ringparam(dev, &ringparam);
>> }
>>
^ permalink raw reply
* [patch iproute2 v7 2/2] tc: Add batchsize feature for filter and actions
From: Chris Mi @ 2018-01-09 6:59 UTC (permalink / raw)
To: netdev; +Cc: gerlitz.or, stephen, dsahern, marcelo.leitner, phil
In-Reply-To: <20180109065908.19754-1-chrism@mellanox.com>
Currently in tc batch mode, only one command is read from the batch
file and sent to kernel to process. With this support, at most 128
commands can be accumulated before sending to kernel.
Now it only works for the following successive commands:
filter and actions add/delete/change/replace.
Signed-off-by: Chris Mi <chrism@mellanox.com>
---
tc/m_action.c | 60 +++++++++++++++++----------
tc/tc.c | 127 ++++++++++++++++++++++++++++++++++++++++++++++++++-------
tc/tc_common.h | 5 ++-
tc/tc_filter.c | 97 +++++++++++++++++++++++++------------------
4 files changed, 210 insertions(+), 79 deletions(-)
diff --git a/tc/m_action.c b/tc/m_action.c
index fc422364..e5c53a80 100644
--- a/tc/m_action.c
+++ b/tc/m_action.c
@@ -546,40 +546,56 @@ bad_val:
return ret;
}
+struct tc_action_req {
+ struct nlmsghdr n;
+ struct tcamsg t;
+ char buf[MAX_MSG];
+};
+
static int tc_action_modify(int cmd, unsigned int flags,
- int *argc_p, char ***argv_p)
+ int *argc_p, char ***argv_p,
+ void *buf)
{
- int argc = *argc_p;
+ struct tc_action_req *req, action_req;
char **argv = *argv_p;
+ struct rtattr *tail;
+ int argc = *argc_p;
+ struct iovec iov;
int ret = 0;
- struct {
- struct nlmsghdr n;
- struct tcamsg t;
- char buf[MAX_MSG];
- } req = {
- .n.nlmsg_len = NLMSG_LENGTH(sizeof(struct tcamsg)),
- .n.nlmsg_flags = NLM_F_REQUEST | flags,
- .n.nlmsg_type = cmd,
- .t.tca_family = AF_UNSPEC,
- };
- struct rtattr *tail = NLMSG_TAIL(&req.n);
+
+ if (buf)
+ req = buf;
+ else
+ req = &action_req;
+
+ req->n.nlmsg_len = NLMSG_LENGTH(sizeof(struct tcamsg));
+ req->n.nlmsg_flags = NLM_F_REQUEST | flags;
+ req->n.nlmsg_type = cmd;
+ req->t.tca_family = AF_UNSPEC;
+ tail = NLMSG_TAIL(&req->n);
argc -= 1;
argv += 1;
- if (parse_action(&argc, &argv, TCA_ACT_TAB, &req.n)) {
+ if (parse_action(&argc, &argv, TCA_ACT_TAB, &req->n)) {
fprintf(stderr, "Illegal \"action\"\n");
return -1;
}
- tail->rta_len = (void *) NLMSG_TAIL(&req.n) - (void *) tail;
+ tail->rta_len = (void *) NLMSG_TAIL(&req->n) - (void *) tail;
+
+ *argc_p = argc;
+ *argv_p = argv;
- if (rtnl_talk(&rth, &req.n, NULL) < 0) {
+ iov.iov_base = &req->n;
+ iov.iov_len = req->n.nlmsg_len;
+
+ if (buf)
+ return 0;
+
+ if (rtnl_talk_iov(&rth, &iov, 1, NULL) < 0) {
fprintf(stderr, "We have an error talking to the kernel\n");
ret = -1;
}
- *argc_p = argc;
- *argv_p = argv;
-
return ret;
}
@@ -679,7 +695,7 @@ bad_val:
return ret;
}
-int do_action(int argc, char **argv)
+int do_action(int argc, char **argv, void *buf)
{
int ret = 0;
@@ -689,12 +705,12 @@ int do_action(int argc, char **argv)
if (matches(*argv, "add") == 0) {
ret = tc_action_modify(RTM_NEWACTION,
NLM_F_EXCL | NLM_F_CREATE,
- &argc, &argv);
+ &argc, &argv, buf);
} else if (matches(*argv, "change") == 0 ||
matches(*argv, "replace") == 0) {
ret = tc_action_modify(RTM_NEWACTION,
NLM_F_CREATE | NLM_F_REPLACE,
- &argc, &argv);
+ &argc, &argv, buf);
} else if (matches(*argv, "delete") == 0) {
argc -= 1;
argv += 1;
diff --git a/tc/tc.c b/tc/tc.c
index ad9f07e9..f32e4978 100644
--- a/tc/tc.c
+++ b/tc/tc.c
@@ -193,16 +193,16 @@ static void usage(void)
" -nm | -nam[es] | { -cf | -conf } path } | -j[son]\n");
}
-static int do_cmd(int argc, char **argv)
+static int do_cmd(int argc, char **argv, void *buf)
{
if (matches(*argv, "qdisc") == 0)
return do_qdisc(argc-1, argv+1);
if (matches(*argv, "class") == 0)
return do_class(argc-1, argv+1);
if (matches(*argv, "filter") == 0)
- return do_filter(argc-1, argv+1);
+ return do_filter(argc-1, argv+1, buf);
if (matches(*argv, "actions") == 0)
- return do_action(argc-1, argv+1);
+ return do_action(argc-1, argv+1, buf);
if (matches(*argv, "monitor") == 0)
return do_tcmonitor(argc-1, argv+1);
if (matches(*argv, "exec") == 0)
@@ -217,11 +217,39 @@ static int do_cmd(int argc, char **argv)
return -1;
}
+static bool batchsize_enabled(int argc, char *argv[])
+{
+ if (argc < 2)
+ return false;
+ if ((strcmp(argv[0], "filter") && strcmp(argv[0], "action"))
+ || (strcmp(argv[1], "add") && strcmp(argv[1], "delete")
+ && strcmp(argv[1], "change") && strcmp(argv[1], "replace")))
+ return false;
+
+ return true;
+}
+
+struct batch_buf {
+ struct batch_buf *next;
+ char buf[16420]; /* sizeof (struct nlmsghdr) +
+ sizeof (struct tcmsg) +
+ MAX_MSG */
+};
+
static int batch(const char *name)
{
- char *line = NULL;
+ struct batch_buf *head = NULL, *tail = NULL, *buf;
+ char *largv[100], *largv_next[100];
+ char *line, *line_next = NULL;
+ bool bs_enabled_next = false;
+ bool bs_enabled = false;
+ bool lastline = false;
+ int largc, largc_next;
+ bool bs_enabled_saved;
+ int batchsize = 0;
size_t len = 0;
- int ret = 0;
+ int ret = 0, i;
+ bool send;
batch_mode = 1;
if (name && strcmp(name, "-") != 0) {
@@ -240,23 +268,92 @@ static int batch(const char *name)
}
cmdlineno = 0;
- while (getcmdline(&line, &len, stdin) != -1) {
- char *largv[100];
- int largc;
+ if (getcmdline(&line, &len, stdin) == -1)
+ goto Exit;
+ largc = makeargs(line, largv, 100);
+ bs_enabled = batchsize_enabled(largc, largv);
+ bs_enabled_saved = bs_enabled;
+ do {
+ if (getcmdline(&line_next, &len, stdin) == -1)
+ lastline = true;
+
+ largc_next = makeargs(line_next, largv_next, 100);
+ bs_enabled_next = batchsize_enabled(largc_next, largv_next);
+ if (bs_enabled) {
+ buf = calloc(1, sizeof (struct batch_buf));
+ if (head == NULL) {
+ head = tail = buf;
+ buf->next = NULL;
+ } else {
+ buf->next = NULL;
+ tail->next = buf;
+ tail = buf;
+ }
+ ++batchsize;
+ }
+
+ /*
+ * In batch mode, if we haven't accumulated enough commands
+ * and this is not the last command and this command & next
+ * command both support the batchsize feature, don't send the
+ * message immediately.
+ */
+ if (!lastline && bs_enabled && bs_enabled_next
+ && batchsize != MSG_IOV_MAX)
+ send = false;
+ else
+ send = true;
+
+ line = line_next;
+ line_next = NULL;
+ len = 0;
+ bs_enabled_saved = bs_enabled;
+ bs_enabled = bs_enabled_next;
+ bs_enabled_next = false;
- largc = makeargs(line, largv, 100);
if (largc == 0)
continue; /* blank line */
- if (do_cmd(largc, largv)) {
- fprintf(stderr, "Command failed %s:%d\n", name, cmdlineno);
+ ret = do_cmd(largc, largv, tail == NULL ? NULL : tail->buf);
+ if (ret != 0) {
+ fprintf(stderr, "Command failed %s:%d\n", name,
+ cmdlineno - 1);
ret = 1;
if (!force)
break;
}
- }
- if (line)
- free(line);
+ largc = largc_next;
+ for (i = 0; i < largc; i ++)
+ largv[i] = largv_next[i];
+
+ if (send && bs_enabled_saved) {
+ struct iovec *iov, *iovs;
+ struct nlmsghdr *n;
+ iov = iovs = malloc(batchsize * sizeof (struct iovec));
+ for (buf = head; buf != NULL; buf = buf->next, ++iov) {
+ n = (struct nlmsghdr *)&buf->buf;
+ iov->iov_base = n;
+ iov->iov_len = n->nlmsg_len;
+ }
+
+ ret = rtnl_talk_iov(&rth, iovs, batchsize, NULL);
+ if (ret < 0) {
+ fprintf(stderr, "Command failed %s:%d\n", name,
+ cmdlineno - (batchsize + ret) - 1);
+ return 2;
+ }
+ for (buf = head; buf != NULL; buf = head) {
+ head = buf->next;
+ free(buf);
+ }
+ head = tail = NULL;
+ batchsize = 0;
+ free(iovs);
+ }
+ } while (!lastline);
+
+Exit:
+ free(line);
rtnl_close(&rth);
return ret;
@@ -341,7 +438,7 @@ int main(int argc, char **argv)
goto Exit;
}
- ret = do_cmd(argc-1, argv+1);
+ ret = do_cmd(argc-1, argv+1, NULL);
Exit:
rtnl_close(&rth);
diff --git a/tc/tc_common.h b/tc/tc_common.h
index 264fbdac..59018da5 100644
--- a/tc/tc_common.h
+++ b/tc/tc_common.h
@@ -1,13 +1,14 @@
/* SPDX-License-Identifier: GPL-2.0 */
#define TCA_BUF_MAX (64*1024)
+#define MSG_IOV_MAX 128
extern struct rtnl_handle rth;
extern int do_qdisc(int argc, char **argv);
extern int do_class(int argc, char **argv);
-extern int do_filter(int argc, char **argv);
-extern int do_action(int argc, char **argv);
+extern int do_filter(int argc, char **argv, void *buf);
+extern int do_action(int argc, char **argv, void *buf);
extern int do_tcmonitor(int argc, char **argv);
extern int do_exec(int argc, char **argv);
diff --git a/tc/tc_filter.c b/tc/tc_filter.c
index 545cc3a1..7db4964b 100644
--- a/tc/tc_filter.c
+++ b/tc/tc_filter.c
@@ -42,28 +42,38 @@ static void usage(void)
"OPTIONS := ... try tc filter add <desired FILTER_KIND> help\n");
}
-static int tc_filter_modify(int cmd, unsigned int flags, int argc, char **argv)
+struct tc_filter_req {
+ struct nlmsghdr n;
+ struct tcmsg t;
+ char buf[MAX_MSG];
+};
+
+static int tc_filter_modify(int cmd, unsigned int flags, int argc, char **argv,
+ void *buf)
{
- struct {
- struct nlmsghdr n;
- struct tcmsg t;
- char buf[MAX_MSG];
- } req = {
- .n.nlmsg_len = NLMSG_LENGTH(sizeof(struct tcmsg)),
- .n.nlmsg_flags = NLM_F_REQUEST | flags,
- .n.nlmsg_type = cmd,
- .t.tcm_family = AF_UNSPEC,
- };
+ struct tc_filter_req *req, filter_req;
struct filter_util *q = NULL;
- __u32 prio = 0;
- __u32 protocol = 0;
- int protocol_set = 0;
- __u32 chain_index;
+ struct tc_estimator est = {};
+ char k[FILTER_NAMESZ] = {};
int chain_index_set = 0;
+ char d[IFNAMSIZ] = {};
+ int protocol_set = 0;
char *fhandle = NULL;
- char d[IFNAMSIZ] = {};
- char k[FILTER_NAMESZ] = {};
- struct tc_estimator est = {};
+ __u32 protocol = 0;
+ __u32 chain_index;
+ struct iovec iov;
+ __u32 prio = 0;
+ int ret;
+
+ if (buf)
+ req = buf;
+ else
+ req = &filter_req;
+
+ req->n.nlmsg_len = NLMSG_LENGTH(sizeof(struct tcmsg));
+ req->n.nlmsg_flags = NLM_F_REQUEST | flags;
+ req->n.nlmsg_type = cmd;
+ req->t.tcm_family = AF_UNSPEC;
if (cmd == RTM_NEWTFILTER && flags & NLM_F_CREATE)
protocol = htons(ETH_P_ALL);
@@ -75,37 +85,37 @@ static int tc_filter_modify(int cmd, unsigned int flags, int argc, char **argv)
duparg("dev", *argv);
strncpy(d, *argv, sizeof(d)-1);
} else if (strcmp(*argv, "root") == 0) {
- if (req.t.tcm_parent) {
+ if (req->t.tcm_parent) {
fprintf(stderr,
"Error: \"root\" is duplicate parent ID\n");
return -1;
}
- req.t.tcm_parent = TC_H_ROOT;
+ req->t.tcm_parent = TC_H_ROOT;
} else if (strcmp(*argv, "ingress") == 0) {
- if (req.t.tcm_parent) {
+ if (req->t.tcm_parent) {
fprintf(stderr,
"Error: \"ingress\" is duplicate parent ID\n");
return -1;
}
- req.t.tcm_parent = TC_H_MAKE(TC_H_CLSACT,
+ req->t.tcm_parent = TC_H_MAKE(TC_H_CLSACT,
TC_H_MIN_INGRESS);
} else if (strcmp(*argv, "egress") == 0) {
- if (req.t.tcm_parent) {
+ if (req->t.tcm_parent) {
fprintf(stderr,
"Error: \"egress\" is duplicate parent ID\n");
return -1;
}
- req.t.tcm_parent = TC_H_MAKE(TC_H_CLSACT,
+ req->t.tcm_parent = TC_H_MAKE(TC_H_CLSACT,
TC_H_MIN_EGRESS);
} else if (strcmp(*argv, "parent") == 0) {
__u32 handle;
NEXT_ARG();
- if (req.t.tcm_parent)
+ if (req->t.tcm_parent)
duparg("parent", *argv);
if (get_tc_classid(&handle, *argv))
invarg("Invalid parent ID", *argv);
- req.t.tcm_parent = handle;
+ req->t.tcm_parent = handle;
} else if (strcmp(*argv, "handle") == 0) {
NEXT_ARG();
if (fhandle)
@@ -152,26 +162,26 @@ static int tc_filter_modify(int cmd, unsigned int flags, int argc, char **argv)
argc--; argv++;
}
- req.t.tcm_info = TC_H_MAKE(prio<<16, protocol);
+ req->t.tcm_info = TC_H_MAKE(prio<<16, protocol);
if (chain_index_set)
- addattr32(&req.n, sizeof(req), TCA_CHAIN, chain_index);
+ addattr32(&req->n, sizeof(*req), TCA_CHAIN, chain_index);
if (k[0])
- addattr_l(&req.n, sizeof(req), TCA_KIND, k, strlen(k)+1);
+ addattr_l(&req->n, sizeof(*req), TCA_KIND, k, strlen(k)+1);
if (d[0]) {
ll_init_map(&rth);
- req.t.tcm_ifindex = ll_name_to_index(d);
- if (req.t.tcm_ifindex == 0) {
+ req->t.tcm_ifindex = ll_name_to_index(d);
+ if (req->t.tcm_ifindex == 0) {
fprintf(stderr, "Cannot find device \"%s\"\n", d);
return 1;
}
}
if (q) {
- if (q->parse_fopt(q, fhandle, argc, argv, &req.n))
+ if (q->parse_fopt(q, fhandle, argc, argv, &req->n))
return 1;
} else {
if (fhandle) {
@@ -190,10 +200,17 @@ static int tc_filter_modify(int cmd, unsigned int flags, int argc, char **argv)
}
if (est.ewma_log)
- addattr_l(&req.n, sizeof(req), TCA_RATE, &est, sizeof(est));
+ addattr_l(&req->n, sizeof(*req), TCA_RATE, &est, sizeof(est));
- if (rtnl_talk(&rth, &req.n, NULL) < 0) {
- fprintf(stderr, "We have an error talking to the kernel\n");
+ iov.iov_base = &req->n;
+ iov.iov_len = req->n.nlmsg_len;
+
+ if (buf)
+ return 0;
+
+ ret = rtnl_talk_iov(&rth, &iov, 1, NULL);
+ if (ret < 0) {
+ fprintf(stderr, "We have an error talking to the kernel, %d\n", ret);
return 2;
}
@@ -636,20 +653,20 @@ static int tc_filter_list(int argc, char **argv)
return 0;
}
-int do_filter(int argc, char **argv)
+int do_filter(int argc, char **argv, void *buf)
{
if (argc < 1)
return tc_filter_list(0, NULL);
if (matches(*argv, "add") == 0)
return tc_filter_modify(RTM_NEWTFILTER, NLM_F_EXCL|NLM_F_CREATE,
- argc-1, argv+1);
+ argc-1, argv+1, buf);
if (matches(*argv, "change") == 0)
- return tc_filter_modify(RTM_NEWTFILTER, 0, argc-1, argv+1);
+ return tc_filter_modify(RTM_NEWTFILTER, 0, argc-1, argv+1, buf);
if (matches(*argv, "replace") == 0)
return tc_filter_modify(RTM_NEWTFILTER, NLM_F_CREATE, argc-1,
- argv+1);
+ argv+1, buf);
if (matches(*argv, "delete") == 0)
- return tc_filter_modify(RTM_DELTFILTER, 0, argc-1, argv+1);
+ return tc_filter_modify(RTM_DELTFILTER, 0, argc-1, argv+1, buf);
if (matches(*argv, "get") == 0)
return tc_filter_get(RTM_GETTFILTER, 0, argc-1, argv+1);
if (matches(*argv, "list") == 0 || matches(*argv, "show") == 0
--
2.14.3
^ permalink raw reply related
* Re: [PATCH net-next 1/3] ethtool: Ensure new ring parameters are within bounds during SRINGPARAM
From: Jakub Kicinski @ 2018-01-09 7:35 UTC (permalink / raw)
To: Tariq Toukan; +Cc: David S. Miller, netdev, Eran Ben Elisha, Eugenia Emantayev
In-Reply-To: <d87fd32a-474f-fccf-fecc-29301e592869@mellanox.com>
On Tue, 9 Jan 2018 09:30:05 +0200
Tariq Toukan <tariqt@mellanox.com> wrote:
> >> diff --git a/net/core/ethtool.c b/net/core/ethtool.c
> >> index 50a79203043b..9ea7cd52fde0 100644
> >> --- a/net/core/ethtool.c
> >> +++ b/net/core/ethtool.c
> >> @@ -1704,14 +1704,23 @@ static int ethtool_get_ringparam(struct
> >> net_device *dev, void __user *useraddr)
> >> static int ethtool_set_ringparam(struct net_device *dev, void
> >> __user *useraddr) {
> >> - struct ethtool_ringparam ringparam;
> >> + struct ethtool_ringparam ringparam, max = { .cmd =
> >> ETHTOOL_GRINGPARAM };
> >> - if (!dev->ethtool_ops->set_ringparam)
> >> + if (!dev->ethtool_ops->set_ringparam
> >> || !dev->ethtool_ops->get_ringparam) return -EOPNOTSUPP;
> >>
> >> if (copy_from_user(&ringparam, useraddr,
> >> sizeof(ringparam))) return -EFAULT;
> >>
> >> + dev->ethtool_ops->get_ringparam(dev, &max);
> >
> > Perhaps check the return value here? It's pretty unlikely but
> > get_ringparam may fail.
> >
>
> get_ringparam NDO returns void.
Ah, you're right, I looked at the return of ethtool_get_ringparam().
^ permalink raw reply
* Re: [PATCH net-next 00/18] ipv6: Align nexthop behaviour with IPv4
From: Ido Schimmel @ 2018-01-09 8:04 UTC (permalink / raw)
To: David Ahern
Cc: Ido Schimmel, netdev, davem, roopa, nicolas.dichtel, weiwan,
kafai, yoshfuji, mlxsw
In-Reply-To: <5c10b955-161d-9cb1-edd1-7a49d88e46ad@gmail.com>
On Sun, Jan 07, 2018 at 10:20:11AM -0700, David Ahern wrote:
> One of many follow on changes that would be beneficial is to remove the
> idev dereference in the hot path to check the
> ignore_routes_with_linkdown sysctl.
When a netdev loses its carrier we can set the RTNH_F_DEAD flag for all
the nexthops using it as their nexthop device, in case the sysctl is
set. Similarly, when the sysctl is toggled we can walk the routing
tables and toggle the flag where appropriate.
You have a different idea?
Thanks for reviewing!
^ permalink raw reply
* Re: BUG: 4.14.11 unable to handle kernel NULL pointer dereference in xfrm_lookup
From: Steffen Klassert @ 2018-01-09 8:19 UTC (permalink / raw)
To: Tobias Hommel; +Cc: netdev
In-Reply-To: <20180108135347.3gvr5dhkzqb7pzhm@arbeitstier>
On Mon, Jan 08, 2018 at 02:53:48PM +0100, Tobias Hommel wrote:
...
> [ 439.095554] BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
> [ 439.103664] IP: xfrm_lookup+0x2a/0x7d0
> [ 439.107551] PGD 0 P4D 0
> [ 439.110144] Oops: 0000 [#1] SMP PTI
> [ 439.113653] Modules linked in:
> [ 439.116774] CPU: 6 PID: 0 Comm: swapper/6 Not tainted 4.14.12 #1
> [ 439.122900] Hardware name: To be filled by O.E.M. CAR-2051/CAR, BIOS 1.01 07/11/2016
> [ 439.130769] task: ffff8cf33b0ea280 task.stack: ffff9492c0090000
> [ 439.136726] RIP: 0010:xfrm_lookup+0x2a/0x7d0
> [ 439.141005] RSP: 0018:ffff8cf33fd83bd0 EFLAGS: 00010246
> [ 439.146315] RAX: 0000000000000000 RBX: ffffffff87074080 RCX: 0000000000000000
> [ 439.153537] RDX: ffff8cf33fd83c48 RSI: 0000000000000000 RDI: ffffffff87074080
> [ 439.160780] RBP: ffffffff87074080 R08: 0000000000000002 R09: 0000000000000000
> [ 439.167958] R10: 0000000000000020 R11: 0000000000000020 R12: ffff8cf33fd83c48
> [ 439.175115] R13: 0000000000000000 R14: 0000000000000002 R15: ffff8cf33b240078
> [ 439.182337] FS: 0000000000000000(0000) GS:ffff8cf33fd80000(0000) knlGS:0000000000000000
> [ 439.190456] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 439.196227] CR2: 0000000000000020 CR3: 000000013200a000 CR4: 00000000001006e0
> [ 439.203386] Call Trace:
> [ 439.205869] <IRQ>
> [ 439.207886] __xfrm_route_forward+0xa4/0x110
> [ 439.212195] ip_forward+0x3da/0x450
> [ 439.215696] ? ip_rcv_finish+0x61/0x390
> [ 439.219542] ip_rcv+0x2b5/0x380
> [ 439.222716] ? inet_del_offload+0x30/0x30
> [ 439.226736] __netif_receive_skb_core+0x751/0xb00
> [ 439.231469] ? netif_receive_skb_internal+0x47/0xf0
> [ 439.236391] netif_receive_skb_internal+0x47/0xf0
> [ 439.241150] napi_gro_flush+0x50/0x70
> [ 439.244831] napi_complete_done+0x90/0xd0
> [ 439.248872] igb_poll+0x8fd/0xe80
> [ 439.252190] net_rx_action+0x1fc/0x310
> [ 439.255978] __do_softirq+0xd5/0x1cf
> [ 439.259584] irq_exit+0xa3/0xb0
> [ 439.262763] do_IRQ+0x45/0xc0
> [ 439.265772] common_interrupt+0x95/0x95
> [ 439.269609] </IRQ>
> [ 439.271733] RIP: 0010:cpuidle_enter_state+0x120/0x200
> [ 439.276810] RSP: 0018:ffff9492c0093eb8 EFLAGS: 00000282 ORIG_RAX: ffffffffffffff5d
> [ 439.284436] RAX: ffff8cf33fd9ea80 RBX: 0000000000000002 RCX: 000000663c21ea0f
> [ 439.291604] RDX: 0000000000000000 RSI: 00000000355556ca RDI: 0000000000000000
> [ 439.298772] RBP: ffff8cf33fda71e8 R08: 0000000000000003 R09: 0000000000000018
> [ 439.305930] R10: 00000000ffffffff R11: 000000000000057c R12: 000000663c21ea0f
> [ 439.313089] R13: 000000663c1c6c33 R14: 0000000000000002 R15: 0000000000000000
> [ 439.320259] ? cpuidle_enter_state+0x11c/0x200
> [ 439.324740] do_idle+0xd6/0x170
> [ 439.327885] cpu_startup_entry+0x67/0x70
> [ 439.331837] start_secondary+0x167/0x190
> [ 439.335788] secondary_startup_64+0xa5/0xb0
> [ 439.340001] Code: 00 41 57 41 56 45 89 c6 41 55 41 54 49 89 f5 55 53 49 89 d4 48 89 fb 48 83 ec 40 65 48 8b 04 25 28 00 00 00 48 89 44 24 38 31 c0 <48> 8b 46 20 48 85 c9 44 0f b7 38 c7 44 24 0c 00 00 00 00 0f 84
> [ 439.358988] RIP: xfrm_lookup+0x2a/0x7d0 RSP: ffff8cf33fd83bd0
> [ 439.364759] CR2: 0000000000000020
> [ 439.368105] ---[ end trace c6b298b556ea7769 ]---
> [ 439.372752] Kernel panic - not syncing: Fatal exception in interrupt
> [ 439.379255] Kernel Offset: 0x5000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
> [ 439.390029] Rebooting in 10 seconds..
...
> 0000000000004230 <xfrm_lookup>:
> 4230: 41 57 push %r15
> 4232: 41 56 push %r14
> 4234: 45 89 c6 mov %r8d,%r14d
> 4237: 41 55 push %r13
> 4239: 41 54 push %r12
> 423b: 49 89 f5 mov %rsi,%r13
> 423e: 55 push %rbp
> 423f: 53 push %rbx
> 4240: 49 89 d4 mov %rdx,%r12
> 4243: 48 89 fb mov %rdi,%rbx
> 4246: 48 83 ec 40 sub $0x40,%rsp
> 424a: 65 48 8b 04 25 28 00 mov %gs:0x28,%rax
> 4251: 00 00
> 4253: 48 89 44 24 38 mov %rax,0x38(%rsp)
> 4258: 31 c0 xor %eax,%eax
> 425a: 48 8b 46 20 mov 0x20(%rsi),%rax
The above is the failing instruction, RSI holds the second argument
of the called function which is a NULL pointer. The second argument
of xfrm_lookup() is dst_orig, so it is as I thought. Now let's find
out why. I don't see anything obvious, so we need to narrow it down.
> CONFIG_INET_ESP=y
> CONFIG_INET_ESP_OFFLOAD=y
You have CONFIG_INET_ESP_OFFLOAD enabled, this is new maybe it
still has some problems. You should not hit an offload codepath
because all your SAs are configured with UDP encapsulation which
is still not supported with offload.
Please try to disable GRO on both interfaces and see what happens:
ethtool -K eth0 gro off
ethtool -K eth1 gro off
Then disable CONFIG_INET_ESP_OFFLOAD and try again.
This should show us if this feature is responsible for the bug.
^ permalink raw reply
* Re: [V2] wcn36xx: fix incorrect assignment to msg_body.min_ch_time
From: Kalle Valo @ 2018-01-09 8:20 UTC (permalink / raw)
To: Colin Ian King
Cc: Eugene Krasnikov, wcn36xx, linux-wireless, netdev,
kernel-janitors, linux-kernel
In-Reply-To: <20171229090732.14928-1-colin.king@canonical.com>
Colin Ian King <colin.king@canonical.com> wrote:
> The second assignment to msg_body.min_ch_time is incorrect, it
> should actually be to msg_body.max_ch_time.
>
> Thanks to Bjorn Andersson for identifying the correct way to fix
> this as my original fix was incorrect.
>
> Detected by CoverityScan, CID#1463042 ("Unused Value")
>
> Fixes: 2f3bef4b247e ("wcn36xx: Add hardware scan offload support")
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
4c8cf8df2f42 wcn36xx: fix incorrect assignment to msg_body.min_ch_time
--
https://patchwork.kernel.org/patch/10136929/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* [PATCH net, v2] of_mdio: avoid MDIO bus removal when a PHY is missing
From: Madalin Bucur @ 2018-01-09 8:33 UTC (permalink / raw)
To: andrew, f.fainelli, davem
Cc: geert+renesas, robh+dt, frowand.list, netdev, devicetree,
linux-kernel, Madalin Bucur
If one of the child devices is missing the of_mdiobus_register_phy()
call will return -ENODEV. When a missing device is encountered the
registration of the remaining PHYs is stopped and the MDIO bus will
fail to register. Propagate all errors except ENODEV to avoid it.
Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
---
v2: add an error print for the first change; the second place has
some noise aleady generated by the exing code
drivers/of/of_mdio.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
index 3481e69..a249370 100644
--- a/drivers/of/of_mdio.c
+++ b/drivers/of/of_mdio.c
@@ -231,8 +231,14 @@ int of_mdiobus_register(struct mii_bus *mdio, struct device_node *np)
rc = of_mdiobus_register_phy(mdio, child, addr);
else
rc = of_mdiobus_register_device(mdio, child, addr);
- if (rc)
- goto unregister;
+
+ if (rc == -ENODEV)
+ dev_err(&mdio->dev,
+ "MDIO device at address %d is missing.\n",
+ addr);
+ else
+ if (rc)
+ goto unregister;
}
if (!scanphys)
@@ -255,7 +261,7 @@ int of_mdiobus_register(struct mii_bus *mdio, struct device_node *np)
if (of_mdiobus_child_is_phy(child)) {
rc = of_mdiobus_register_phy(mdio, child, addr);
- if (rc)
+ if (rc && rc != -ENODEV)
goto unregister;
}
}
--
2.1.0
^ permalink raw reply related
* Re: [PATCH v2] b43: Replace mdelay with usleep_range in b43_radio_2057_init_post
From: Greg KH @ 2018-01-09 8:35 UTC (permalink / raw)
To: Jia-Ju Bai
Cc: Larry.Finger, kvalo, kstewart, johannes.berg, tiwai, colin.king,
andrew.zaborowski, linux-kernel, linux-wireless, netdev, b43-dev
In-Reply-To: <1515462006-6144-1-git-send-email-baijiaju1990@gmail.com>
On Tue, Jan 09, 2018 at 09:40:06AM +0800, Jia-Ju Bai wrote:
> b43_radio_2057_init_post is not called in an interrupt handler
> nor holding a spinlock.
> The function mdelay in it can be replaced with usleep_range,
> to reduce busy wait.
>
> Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
> ---
> v2:
> * Replace mdelay with usleep_range, instead of msleep in v1.
> Thank Larry for good advice.
> ---
> drivers/net/wireless/broadcom/b43/phy_n.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/broadcom/b43/phy_n.c b/drivers/net/wireless/broadcom/b43/phy_n.c
> index a5557d7..f2a2f41 100644
> --- a/drivers/net/wireless/broadcom/b43/phy_n.c
> +++ b/drivers/net/wireless/broadcom/b43/phy_n.c
> @@ -1031,7 +1031,7 @@ static void b43_radio_2057_init_post(struct b43_wldev *dev)
>
> b43_radio_set(dev, R2057_RFPLL_MISC_CAL_RESETN, 0x78);
> b43_radio_set(dev, R2057_XTAL_CONFIG2, 0x80);
> - mdelay(2);
> + usleep_range(2000, 3000);
Where did 3000 come from? Are you sure about that?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH net, v2] of_mdio: avoid MDIO bus removal when a PHY is missing
From: Geert Uytterhoeven @ 2018-01-09 8:35 UTC (permalink / raw)
To: Madalin-cristian Bucur
Cc: Andrew Lunn, Florian Fainelli, David S. Miller,
Geert Uytterhoeven, Rob Herring, Frank Rowand, netdev, devicetree,
Linux Kernel Mailing List
In-Reply-To: <1515486819-8954-1-git-send-email-madalin.bucur@nxp.com>
Hi Madalin,
On Tue, Jan 9, 2018 at 9:33 AM, Madalin Bucur <madalin.bucur@nxp.com> wrote:
> If one of the child devices is missing the of_mdiobus_register_phy()
> call will return -ENODEV. When a missing device is encountered the
> registration of the remaining PHYs is stopped and the MDIO bus will
> fail to register. Propagate all errors except ENODEV to avoid it.
>
> Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
Thanks for your patch!
> ---
> v2: add an error print for the first change; the second place has
> some noise aleady generated by the exing code
>
> drivers/of/of_mdio.c | 12 +++++++++---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
> index 3481e69..a249370 100644
> --- a/drivers/of/of_mdio.c
> +++ b/drivers/of/of_mdio.c
> @@ -231,8 +231,14 @@ int of_mdiobus_register(struct mii_bus *mdio, struct device_node *np)
> rc = of_mdiobus_register_phy(mdio, child, addr);
> else
> rc = of_mdiobus_register_device(mdio, child, addr);
> - if (rc)
> - goto unregister;
> +
> + if (rc == -ENODEV)
> + dev_err(&mdio->dev,
> + "MDIO device at address %d is missing.\n",
> + addr);
> + else
> + if (rc)
You can merge the two lines above into a single line.
> + goto unregister;
... dropping the need to reindent the above line.
> }
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 0/2] net: dsa: lan9303: check error value from devm_gpiod_get_optional()
From: Phil Reid @ 2018-01-09 8:38 UTC (permalink / raw)
To: Egil Hjelmeland, andrew, vivien.didelot, f.fainelli, netdev,
linux-kernel, bianpan2016, stable
In-Reply-To: <7efb44a6-d8f1-6c00-e966-efc9329075e4@egil-hjelmeland.no>
On 7/01/2018 00:54, Egil Hjelmeland wrote:
> Den 13. nov. 2017 09:07, skrev Phil Reid:
>> Replaces Pan Bian <bianpan2016@163.com> patch
>> "net: dsa: lan9303: correctly check return value of devm_gpiod_get_optional"
>>
>> Errors need to be prograted back from probe.
>>
>> Note: I have only compile tested the code as I don't have the hardware.
>>
>> Phil Reid (2):
>> net: dsa: lan9303: make lan9303_handle_reset() a void function
>> net: dsa: lan9303: check error value from devm_gpiod_get_optional()
>>
>> drivers/net/dsa/lan9303-core.c | 21 ++++++++++++---------
>> 1 file changed, 12 insertions(+), 9 deletions(-)
>>
>
> Evidently this one did not make it through. Do you care to rebase and try again?
>
> Thanks
> Egil
>
>
Sure I'll give it another go.
--
Regards
Phil Reid
^ permalink raw reply
* Re: [PATCH v2] b43: Replace mdelay with usleep_range in b43_radio_2057_init_post
From: Jia-Ju Bai @ 2018-01-09 8:39 UTC (permalink / raw)
To: Greg KH
Cc: Larry.Finger, kvalo, kstewart, johannes.berg, tiwai, colin.king,
andrew.zaborowski, linux-kernel, linux-wireless, netdev, b43-dev
In-Reply-To: <20180109083541.GA13460@kroah.com>
On 2018/1/9 16:35, Greg KH wrote:
> On Tue, Jan 09, 2018 at 09:40:06AM +0800, Jia-Ju Bai wrote:
>> b43_radio_2057_init_post is not called in an interrupt handler
>> nor holding a spinlock.
>> The function mdelay in it can be replaced with usleep_range,
>> to reduce busy wait.
>>
>> Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
>> ---
>> v2:
>> * Replace mdelay with usleep_range, instead of msleep in v1.
>> Thank Larry for good advice.
>> ---
>> drivers/net/wireless/broadcom/b43/phy_n.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/wireless/broadcom/b43/phy_n.c b/drivers/net/wireless/broadcom/b43/phy_n.c
>> index a5557d7..f2a2f41 100644
>> --- a/drivers/net/wireless/broadcom/b43/phy_n.c
>> +++ b/drivers/net/wireless/broadcom/b43/phy_n.c
>> @@ -1031,7 +1031,7 @@ static void b43_radio_2057_init_post(struct b43_wldev *dev)
>>
>> b43_radio_set(dev, R2057_RFPLL_MISC_CAL_RESETN, 0x78);
>> b43_radio_set(dev, R2057_XTAL_CONFIG2, 0x80);
>> - mdelay(2);
>> + usleep_range(2000, 3000);
> Where did 3000 come from? Are you sure about that?
I am not very sure, and I use it according to Larry's message:
> I had negative comments on one of those due to the possibility of
> msleep(2) extending as long as 20 msec. Until the author, or someone
> else, can test that this is OK, then the mdelay(2) can only be
> replaced with usleep_range(2000, 3000).
Thanks,
Jia-Ju Bai
^ permalink raw reply
* Re: [PATCH 07/18] [media] uvcvideo: prevent bounds-check bypass via speculative execution
From: Laurent Pinchart @ 2018-01-09 8:40 UTC (permalink / raw)
To: Greg KH
Cc: Dan Williams, linux-kernel, linux-arch, alan, peterz, netdev,
tglx, Mauro Carvalho Chehab, torvalds, Elena Reshetova,
linux-media
In-Reply-To: <20180106094026.GA11525@kroah.com>
Hi Greg,
On Saturday, 6 January 2018 11:40:26 EET Greg KH wrote:
> On Sat, Jan 06, 2018 at 10:09:07AM +0100, Greg KH wrote:
> > On Fri, Jan 05, 2018 at 05:10:32PM -0800, Dan Williams wrote:
> >> Static analysis reports that 'index' may be a user controlled value that
> >> is used as a data dependency to read 'pin' from the
> >> 'selector->baSourceID' array. In order to avoid potential leaks of
> >> kernel memory values, block speculative execution of the instruction
> >> stream that could issue reads based on an invalid value of 'pin'.
> >>
> >> Based on an original patch by Elena Reshetova.
> >>
> >> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> >> Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
> >> Cc: linux-media@vger.kernel.org
> >> Signed-off-by: Elena Reshetova <elena.reshetova@intel.com>
> >> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> >> ---
> >>
> >> drivers/media/usb/uvc/uvc_v4l2.c | 7 +++++--
> >> 1 file changed, 5 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/media/usb/uvc/uvc_v4l2.c
> >> b/drivers/media/usb/uvc/uvc_v4l2.c index 3e7e283a44a8..7442626dc20e
> >> 100644
> >> --- a/drivers/media/usb/uvc/uvc_v4l2.c
> >> +++ b/drivers/media/usb/uvc/uvc_v4l2.c
> >> @@ -22,6 +22,7 @@
> >> #include <linux/mm.h>
> >> #include <linux/wait.h>
> >> #include <linux/atomic.h>
> >> +#include <linux/compiler.h>
> >>
> >> #include <media/v4l2-common.h>
> >> #include <media/v4l2-ctrls.h>
> >> @@ -810,6 +811,7 @@ static int uvc_ioctl_enum_input(struct file *file,
> >> void *fh,
> >> struct uvc_entity *iterm = NULL;
> >> u32 index = input->index;
> >> int pin = 0;
> >> + __u8 *elem;
> >>
> >> if (selector == NULL ||
> >> (chain->dev->quirks & UVC_QUIRK_IGNORE_SELECTOR_UNIT)) {
> >> @@ -820,8 +822,9 @@ static int uvc_ioctl_enum_input(struct file *file,
> >> void *fh,
> >> break;
> >> }
> >> pin = iterm->id;
> >> - } else if (index < selector->bNrInPins) {
> >> - pin = selector->baSourceID[index];
> >> + } else if ((elem = nospec_array_ptr(selector->baSourceID, index,
> >> + selector->bNrInPins))) {
> >> + pin = *elem;
> >
> > I dug through this before, and I couldn't find where index came from
> > userspace, I think seeing the coverity rule would be nice.
>
> Ok, I take it back, this looks correct. Ugh, the v4l ioctl api is
> crazy complex (rightfully so), it's amazing that coverity could navigate
> that whole thing :)
>
> While I'm all for fixing this type of thing, I feel like we need to do
> something "else" for this as playing whack-a-mole for this pattern is
> going to be a never-ending battle for all drivers for forever.
That's my concern too, as even if we managed to find and fix all the
occurrences of the problematic patterns (and we won't), new ones will keep
being merged all the time.
> Either we need some way to mark this data path to make it easy for tools
> like sparse to flag easily, or we need to catch the issue in the driver
> subsystems, which unfortunatly, would harm the drivers that don't have
> this type of issue (like here.)
But how would you do so ?
> I'm guessing that other operating systems, which don't have the luxury
> of auditing all of their drivers are going for the "big hammer in the
> subsystem" type of fix, right?
Other operating systems that ship closed-source drivers authored by hardware
vendors and not reviewed by third parties will likely stay vulnerable forever.
That's a small concern though as I expect those drivers to contain much large
security holes anyway.
> I don't have a good answer for this, but if there was some better way to
> rewrite these types of patterns to just prevent the need for the
> nospec_array_ptr() type thing, that might be the best overall for
> everyone. Much like ebpf did with their changes. That way a simple
> coccinelle rule would be able to catch the pattern and rewrite it.
>
> Or am I just dreaming?
Likely, but sometimes dreams come true :-) Do you have an idea how this could
be done ?
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH] doc: clarification about setting SO_ZEROCOPY
From: Kornilios Kourtis @ 2018-01-09 8:52 UTC (permalink / raw)
To: netdev; +Cc: Willem de Bruijn
Signed-off-by: Kornilios Kourtis <kou@zurich.ibm.com>
---
Documentation/networking/msg_zerocopy.rst | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/networking/msg_zerocopy.rst b/Documentation/networking/msg_zerocopy.rst
index 77f6d7e..c3380f4 100644
--- a/Documentation/networking/msg_zerocopy.rst
+++ b/Documentation/networking/msg_zerocopy.rst
@@ -72,6 +72,10 @@ this flag, a process must first signal intent by setting a socket option:
if (setsockopt(fd, SOL_SOCKET, SO_ZEROCOPY, &one, sizeof(one)))
error(1, errno, "setsockopt zerocopy");
+Setting the socket option only works when the socket is in its initial
+(TCP_CLOSED) state. Trying to set the option for a socket returned by accept(),
+for example, will lead to an EBUSY error. In this case, the option should be set
+to the listening socket and it will be inherited by the accepted sockets.
Transmission
------------
--
2.4.3
^ permalink raw reply related
* [PATCH net-next v3 0/4] net: mvpp2: 1000BaseX and 2500BaseX support
From: Antoine Tenart @ 2018-01-09 8:59 UTC (permalink / raw)
To: davem, kishon
Cc: thomas.petazzoni, andrew, ymarkman, netdev, Antoine Tenart, linux,
linux-kernel, nadavh, miquel.raynal, gregory.clement, stefanc, mw,
linux-arm-kernel
Hi all,
This series adds 1000BaseX and 2500BaseX support to the Marvell PPv2
driver. In order to use it, the 2.5 SGMII mode is added in the Marvell
common PHY driver (cp110-comphy).
This was tested on a mcbin.
All patches should probably go through net-next as patch 4/4 depends on
patch 1/4 to build and work.
Please note the two mvpp2 patches do not conflict with the ACPI series
v2 Marcin sent a few days ago, and the two series can be processed in
parallel. (Marcin is aware of me sending this series).
Thanks!
Antoine
Since v2:
- Added a comment before mvpp22_comphy_init() about the different PHY modes
used and why they differ between the PPv2 driver and the COMPHY one.
Since v1:
- s/PHY_MODE_SGMII_2_5G/PHY_MODE_2500SGMII/
- Fixed a build error in 'net: mvpp2: 1000baseX support' (which was solved in
the 2500baseX support one, but the bisection was broken).
- Removed the dt patches, as the fourth network interface on the mcbin also
needs PHYLINK support in the PPv2 driver to be correctly supported.
Antoine Tenart (4):
phy: add 2.5G SGMII mode to the phy_mode enum
phy: cp110-comphy: 2.5G SGMII mode
net: mvpp2: 1000baseX support
net: mvpp2: 2500baseX support
drivers/net/ethernet/marvell/mvpp2.c | 77 ++++++++++++++++++++++++----
drivers/phy/marvell/phy-mvebu-cp110-comphy.c | 17 ++++--
include/linux/phy/phy.h | 1 +
3 files changed, 82 insertions(+), 13 deletions(-)
--
2.14.3
^ permalink raw reply
* [PATCH net-next v3 1/4] phy: add 2.5G SGMII mode to the phy_mode enum
From: Antoine Tenart @ 2018-01-09 8:59 UTC (permalink / raw)
To: davem, kishon
Cc: Antoine Tenart, andrew, gregory.clement, linux, mw, stefanc,
ymarkman, thomas.petazzoni, miquel.raynal, nadavh, netdev,
linux-arm-kernel, linux-kernel
In-Reply-To: <20180109085945.11916-1-antoine.tenart@free-electrons.com>
This patch adds one more generic PHY mode to the phy_mode enum, to allow
configuring generic PHYs to the 2.5G SGMII mode by using the set_mode
callback.
Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
---
include/linux/phy/phy.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index 4f8423a948d5..5a80e9de3686 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -28,6 +28,7 @@ enum phy_mode {
PHY_MODE_USB_DEVICE,
PHY_MODE_USB_OTG,
PHY_MODE_SGMII,
+ PHY_MODE_2500SGMII,
PHY_MODE_10GKR,
PHY_MODE_UFS_HS_A,
PHY_MODE_UFS_HS_B,
--
2.14.3
^ permalink raw reply related
* [PATCH net-next v3 2/4] phy: cp110-comphy: 2.5G SGMII mode
From: Antoine Tenart @ 2018-01-09 8:59 UTC (permalink / raw)
To: davem, kishon
Cc: thomas.petazzoni, andrew, ymarkman, netdev, Antoine Tenart, linux,
linux-kernel, nadavh, miquel.raynal, gregory.clement, stefanc, mw,
linux-arm-kernel
In-Reply-To: <20180109085945.11916-1-antoine.tenart@free-electrons.com>
This patch allow the CP100 comphy to configure some lanes in the
2.5G SGMII mode. This mode is quite close to SGMII and uses nearly the
same code path.
Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
---
drivers/phy/marvell/phy-mvebu-cp110-comphy.c | 17 ++++++++++++++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/phy/marvell/phy-mvebu-cp110-comphy.c b/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
index a0d522154cdf..4ef429250d7b 100644
--- a/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
+++ b/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
@@ -135,19 +135,25 @@ struct mvebu_comhy_conf {
static const struct mvebu_comhy_conf mvebu_comphy_cp110_modes[] = {
/* lane 0 */
MVEBU_COMPHY_CONF(0, 1, PHY_MODE_SGMII, 0x1),
+ MVEBU_COMPHY_CONF(0, 1, PHY_MODE_2500SGMII, 0x1),
/* lane 1 */
MVEBU_COMPHY_CONF(1, 2, PHY_MODE_SGMII, 0x1),
+ MVEBU_COMPHY_CONF(1, 2, PHY_MODE_2500SGMII, 0x1),
/* lane 2 */
MVEBU_COMPHY_CONF(2, 0, PHY_MODE_SGMII, 0x1),
+ MVEBU_COMPHY_CONF(2, 0, PHY_MODE_2500SGMII, 0x1),
MVEBU_COMPHY_CONF(2, 0, PHY_MODE_10GKR, 0x1),
/* lane 3 */
MVEBU_COMPHY_CONF(3, 1, PHY_MODE_SGMII, 0x2),
+ MVEBU_COMPHY_CONF(3, 1, PHY_MODE_2500SGMII, 0x2),
/* lane 4 */
MVEBU_COMPHY_CONF(4, 0, PHY_MODE_SGMII, 0x2),
+ MVEBU_COMPHY_CONF(4, 0, PHY_MODE_2500SGMII, 0x2),
MVEBU_COMPHY_CONF(4, 0, PHY_MODE_10GKR, 0x2),
MVEBU_COMPHY_CONF(4, 1, PHY_MODE_SGMII, 0x1),
/* lane 5 */
MVEBU_COMPHY_CONF(5, 2, PHY_MODE_SGMII, 0x1),
+ MVEBU_COMPHY_CONF(5, 2, PHY_MODE_2500SGMII, 0x1),
};
struct mvebu_comphy_priv {
@@ -206,6 +212,10 @@ static void mvebu_comphy_ethernet_init_reset(struct mvebu_comphy_lane *lane,
if (mode == PHY_MODE_10GKR)
val |= MVEBU_COMPHY_SERDES_CFG0_GEN_RX(0xe) |
MVEBU_COMPHY_SERDES_CFG0_GEN_TX(0xe);
+ else if (mode == PHY_MODE_2500SGMII)
+ val |= MVEBU_COMPHY_SERDES_CFG0_GEN_RX(0x8) |
+ MVEBU_COMPHY_SERDES_CFG0_GEN_TX(0x8) |
+ MVEBU_COMPHY_SERDES_CFG0_HALF_BUS;
else if (mode == PHY_MODE_SGMII)
val |= MVEBU_COMPHY_SERDES_CFG0_GEN_RX(0x6) |
MVEBU_COMPHY_SERDES_CFG0_GEN_TX(0x6) |
@@ -296,13 +306,13 @@ static int mvebu_comphy_init_plls(struct mvebu_comphy_lane *lane,
return 0;
}
-static int mvebu_comphy_set_mode_sgmii(struct phy *phy)
+static int mvebu_comphy_set_mode_sgmii(struct phy *phy, enum phy_mode mode)
{
struct mvebu_comphy_lane *lane = phy_get_drvdata(phy);
struct mvebu_comphy_priv *priv = lane->priv;
u32 val;
- mvebu_comphy_ethernet_init_reset(lane, PHY_MODE_SGMII);
+ mvebu_comphy_ethernet_init_reset(lane, mode);
val = readl(priv->base + MVEBU_COMPHY_RX_CTRL1(lane->id));
val &= ~MVEBU_COMPHY_RX_CTRL1_CLK8T_EN;
@@ -487,7 +497,8 @@ static int mvebu_comphy_power_on(struct phy *phy)
switch (lane->mode) {
case PHY_MODE_SGMII:
- ret = mvebu_comphy_set_mode_sgmii(phy);
+ case PHY_MODE_2500SGMII:
+ ret = mvebu_comphy_set_mode_sgmii(phy, lane->mode);
break;
case PHY_MODE_10GKR:
ret = mvebu_comphy_set_mode_10gkr(phy);
--
2.14.3
^ permalink raw reply related
* [PATCH net-next v3 3/4] net: mvpp2: 1000baseX support
From: Antoine Tenart @ 2018-01-09 8:59 UTC (permalink / raw)
To: davem, kishon
Cc: thomas.petazzoni, andrew, ymarkman, netdev, Antoine Tenart, linux,
linux-kernel, nadavh, miquel.raynal, gregory.clement, stefanc, mw,
linux-arm-kernel
In-Reply-To: <20180109085945.11916-1-antoine.tenart@free-electrons.com>
This patch adds the 1000Base-X PHY mode support in the Marvell PPv2
driver. 1000Base-X is quite close the SGMII and uses nearly the same
code path.
Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
---
drivers/net/ethernet/marvell/mvpp2.c | 45 ++++++++++++++++++++++++++++--------
1 file changed, 35 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2.c b/drivers/net/ethernet/marvell/mvpp2.c
index a19760736b71..257a6b99b4ca 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -4501,6 +4501,7 @@ static int mvpp22_gop_init(struct mvpp2_port *port)
mvpp22_gop_init_rgmii(port);
break;
case PHY_INTERFACE_MODE_SGMII:
+ case PHY_INTERFACE_MODE_1000BASEX:
mvpp22_gop_init_sgmii(port);
break;
case PHY_INTERFACE_MODE_10GKR:
@@ -4538,7 +4539,8 @@ static void mvpp22_gop_unmask_irq(struct mvpp2_port *port)
u32 val;
if (phy_interface_mode_is_rgmii(port->phy_interface) ||
- port->phy_interface == PHY_INTERFACE_MODE_SGMII) {
+ port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
/* Enable the GMAC link status irq for this port */
val = readl(port->base + MVPP22_GMAC_INT_SUM_MASK);
val |= MVPP22_GMAC_INT_SUM_MASK_LINK_STAT;
@@ -4568,7 +4570,8 @@ static void mvpp22_gop_mask_irq(struct mvpp2_port *port)
}
if (phy_interface_mode_is_rgmii(port->phy_interface) ||
- port->phy_interface == PHY_INTERFACE_MODE_SGMII) {
+ port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
val = readl(port->base + MVPP22_GMAC_INT_SUM_MASK);
val &= ~MVPP22_GMAC_INT_SUM_MASK_LINK_STAT;
writel(val, port->base + MVPP22_GMAC_INT_SUM_MASK);
@@ -4580,7 +4583,8 @@ static void mvpp22_gop_setup_irq(struct mvpp2_port *port)
u32 val;
if (phy_interface_mode_is_rgmii(port->phy_interface) ||
- port->phy_interface == PHY_INTERFACE_MODE_SGMII) {
+ port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
val = readl(port->base + MVPP22_GMAC_INT_MASK);
val |= MVPP22_GMAC_INT_MASK_LINK_STAT;
writel(val, port->base + MVPP22_GMAC_INT_MASK);
@@ -4605,6 +4609,7 @@ static int mvpp22_comphy_init(struct mvpp2_port *port)
switch (port->phy_interface) {
case PHY_INTERFACE_MODE_SGMII:
+ case PHY_INTERFACE_MODE_1000BASEX:
mode = PHY_MODE_SGMII;
break;
case PHY_INTERFACE_MODE_10GKR:
@@ -4625,7 +4630,8 @@ static void mvpp2_port_mii_gmac_configure_mode(struct mvpp2_port *port)
{
u32 val;
- if (port->phy_interface == PHY_INTERFACE_MODE_SGMII) {
+ if (port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
val = readl(port->base + MVPP22_GMAC_CTRL_4_REG);
val |= MVPP22_CTRL4_SYNC_BYPASS_DIS | MVPP22_CTRL4_DP_CLK_SEL |
MVPP22_CTRL4_QSGMII_BYPASS_ACTIVE;
@@ -4640,9 +4646,11 @@ static void mvpp2_port_mii_gmac_configure_mode(struct mvpp2_port *port)
writel(val, port->base + MVPP22_GMAC_CTRL_4_REG);
}
- /* The port is connected to a copper PHY */
val = readl(port->base + MVPP2_GMAC_CTRL_0_REG);
- val &= ~MVPP2_GMAC_PORT_TYPE_MASK;
+ if (port->phy_interface == PHY_INTERFACE_MODE_1000BASEX)
+ val |= MVPP2_GMAC_PORT_TYPE_MASK;
+ else
+ val &= ~MVPP2_GMAC_PORT_TYPE_MASK;
writel(val, port->base + MVPP2_GMAC_CTRL_0_REG);
val = readl(port->base + MVPP2_GMAC_AUTONEG_CONFIG);
@@ -4651,6 +4659,19 @@ static void mvpp2_port_mii_gmac_configure_mode(struct mvpp2_port *port)
MVPP2_GMAC_AN_DUPLEX_EN;
if (port->phy_interface == PHY_INTERFACE_MODE_SGMII)
val |= MVPP2_GMAC_IN_BAND_AUTONEG;
+
+ if (port->phy_interface == PHY_INTERFACE_MODE_1000BASEX)
+ /* 1000BaseX port cannot negotiate speed nor can it
+ * negotiate duplex: they are always operating with a
+ * fixed speed of 1000Mbps in full duplex, so force
+ * 1000 speed and full duplex here.
+ */
+ val |= MVPP2_GMAC_CONFIG_GMII_SPEED |
+ MVPP2_GMAC_CONFIG_FULL_DUPLEX;
+ else
+ val |= MVPP2_GMAC_AN_SPEED_EN |
+ MVPP2_GMAC_AN_DUPLEX_EN;
+
writel(val, port->base + MVPP2_GMAC_AUTONEG_CONFIG);
}
@@ -4671,7 +4692,8 @@ static void mvpp2_port_mii_gmac_configure(struct mvpp2_port *port)
/* Configure the PCS and in-band AN */
val = readl(port->base + MVPP2_GMAC_CTRL_2_REG);
- if (port->phy_interface == PHY_INTERFACE_MODE_SGMII) {
+ if (port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
val |= MVPP2_GMAC_INBAND_AN_MASK | MVPP2_GMAC_PCS_ENABLE_MASK;
} else if (phy_interface_mode_is_rgmii(port->phy_interface)) {
val &= ~MVPP2_GMAC_PCS_ENABLE_MASK;
@@ -4733,7 +4755,8 @@ static void mvpp2_port_mii_set(struct mvpp2_port *port)
mvpp22_port_mii_set(port);
if (phy_interface_mode_is_rgmii(port->phy_interface) ||
- port->phy_interface == PHY_INTERFACE_MODE_SGMII)
+ port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX)
mvpp2_port_mii_gmac_configure(port);
else if (port->phy_interface == PHY_INTERFACE_MODE_10GKR)
mvpp2_port_mii_xlg_configure(port);
@@ -4810,7 +4833,8 @@ static void mvpp2_port_loopback_set(struct mvpp2_port *port)
else
val &= ~MVPP2_GMAC_GMII_LB_EN_MASK;
- if (port->phy_interface == PHY_INTERFACE_MODE_SGMII)
+ if (port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX)
val |= MVPP2_GMAC_PCS_LB_EN_MASK;
else
val &= ~MVPP2_GMAC_PCS_LB_EN_MASK;
@@ -6023,7 +6047,8 @@ static irqreturn_t mvpp2_link_status_isr(int irq, void *dev_id)
link = true;
}
} else if (phy_interface_mode_is_rgmii(port->phy_interface) ||
- port->phy_interface == PHY_INTERFACE_MODE_SGMII) {
+ port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
val = readl(port->base + MVPP22_GMAC_INT_STAT);
if (val & MVPP22_GMAC_INT_STAT_LINK) {
event = true;
--
2.14.3
^ permalink raw reply related
* [PATCH net-next v3 4/4] net: mvpp2: 2500baseX support
From: Antoine Tenart @ 2018-01-09 8:59 UTC (permalink / raw)
To: davem, kishon
Cc: Antoine Tenart, andrew, gregory.clement, linux, mw, stefanc,
ymarkman, thomas.petazzoni, miquel.raynal, nadavh, netdev,
linux-arm-kernel, linux-kernel
In-Reply-To: <20180109085945.11916-1-antoine.tenart@free-electrons.com>
This patch adds the 2500Base-X PHY mode support in the Marvell PPv2
driver. 2500Base-X is quite close to 1000Base-X and SGMII modes and uses
nearly the same code path.
Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
---
drivers/net/ethernet/marvell/mvpp2.c | 50 +++++++++++++++++++++++++++++-------
1 file changed, 41 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2.c b/drivers/net/ethernet/marvell/mvpp2.c
index 257a6b99b4ca..290f891421d1 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -4502,6 +4502,7 @@ static int mvpp22_gop_init(struct mvpp2_port *port)
break;
case PHY_INTERFACE_MODE_SGMII:
case PHY_INTERFACE_MODE_1000BASEX:
+ case PHY_INTERFACE_MODE_2500BASEX:
mvpp22_gop_init_sgmii(port);
break;
case PHY_INTERFACE_MODE_10GKR:
@@ -4540,7 +4541,8 @@ static void mvpp22_gop_unmask_irq(struct mvpp2_port *port)
if (phy_interface_mode_is_rgmii(port->phy_interface) ||
port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
- port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX ||
+ port->phy_interface == PHY_INTERFACE_MODE_2500BASEX) {
/* Enable the GMAC link status irq for this port */
val = readl(port->base + MVPP22_GMAC_INT_SUM_MASK);
val |= MVPP22_GMAC_INT_SUM_MASK_LINK_STAT;
@@ -4571,7 +4573,8 @@ static void mvpp22_gop_mask_irq(struct mvpp2_port *port)
if (phy_interface_mode_is_rgmii(port->phy_interface) ||
port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
- port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX ||
+ port->phy_interface == PHY_INTERFACE_MODE_2500BASEX) {
val = readl(port->base + MVPP22_GMAC_INT_SUM_MASK);
val &= ~MVPP22_GMAC_INT_SUM_MASK_LINK_STAT;
writel(val, port->base + MVPP22_GMAC_INT_SUM_MASK);
@@ -4584,7 +4587,8 @@ static void mvpp22_gop_setup_irq(struct mvpp2_port *port)
if (phy_interface_mode_is_rgmii(port->phy_interface) ||
port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
- port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX ||
+ port->phy_interface == PHY_INTERFACE_MODE_2500BASEX) {
val = readl(port->base + MVPP22_GMAC_INT_MASK);
val |= MVPP22_GMAC_INT_MASK_LINK_STAT;
writel(val, port->base + MVPP22_GMAC_INT_MASK);
@@ -4599,6 +4603,16 @@ static void mvpp22_gop_setup_irq(struct mvpp2_port *port)
mvpp22_gop_unmask_irq(port);
}
+/* Sets the PHY mode of the COMPHY (which configures the serdes lanes).
+ *
+ * The PHY mode used by the PPv2 driver comes from the network subsystem, while
+ * the one given to the COMPHY comes from the generic PHY subsystem. Hence they
+ * differ.
+ *
+ * The COMPHY configures the serdes lanes regardless of the actual use of the
+ * lanes by the physical layer. This is why configurations like
+ * "PPv2 (2500BaseX) - COMPHY (2500SGMII)" are valid.
+ */
static int mvpp22_comphy_init(struct mvpp2_port *port)
{
enum phy_mode mode;
@@ -4612,6 +4626,9 @@ static int mvpp22_comphy_init(struct mvpp2_port *port)
case PHY_INTERFACE_MODE_1000BASEX:
mode = PHY_MODE_SGMII;
break;
+ case PHY_INTERFACE_MODE_2500BASEX:
+ mode = PHY_MODE_2500SGMII;
+ break;
case PHY_INTERFACE_MODE_10GKR:
mode = PHY_MODE_10GKR;
break;
@@ -4631,7 +4648,8 @@ static void mvpp2_port_mii_gmac_configure_mode(struct mvpp2_port *port)
u32 val;
if (port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
- port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX ||
+ port->phy_interface == PHY_INTERFACE_MODE_2500BASEX) {
val = readl(port->base + MVPP22_GMAC_CTRL_4_REG);
val |= MVPP22_CTRL4_SYNC_BYPASS_DIS | MVPP22_CTRL4_DP_CLK_SEL |
MVPP22_CTRL4_QSGMII_BYPASS_ACTIVE;
@@ -4647,7 +4665,8 @@ static void mvpp2_port_mii_gmac_configure_mode(struct mvpp2_port *port)
}
val = readl(port->base + MVPP2_GMAC_CTRL_0_REG);
- if (port->phy_interface == PHY_INTERFACE_MODE_1000BASEX)
+ if (port->phy_interface == PHY_INTERFACE_MODE_1000BASEX ||
+ port->phy_interface == PHY_INTERFACE_MODE_2500BASEX)
val |= MVPP2_GMAC_PORT_TYPE_MASK;
else
val &= ~MVPP2_GMAC_PORT_TYPE_MASK;
@@ -4660,6 +4679,11 @@ static void mvpp2_port_mii_gmac_configure_mode(struct mvpp2_port *port)
if (port->phy_interface == PHY_INTERFACE_MODE_SGMII)
val |= MVPP2_GMAC_IN_BAND_AUTONEG;
+ /* Clear all fields we may want to explicitly set below */
+ val &= ~(MVPP2_GMAC_CONFIG_FULL_DUPLEX | MVPP2_GMAC_CONFIG_GMII_SPEED |
+ MVPP2_GMAC_CONFIG_MII_SPEED | MVPP2_GMAC_AN_SPEED_EN |
+ MVPP2_GMAC_AN_DUPLEX_EN);
+
if (port->phy_interface == PHY_INTERFACE_MODE_1000BASEX)
/* 1000BaseX port cannot negotiate speed nor can it
* negotiate duplex: they are always operating with a
@@ -4668,6 +4692,10 @@ static void mvpp2_port_mii_gmac_configure_mode(struct mvpp2_port *port)
*/
val |= MVPP2_GMAC_CONFIG_GMII_SPEED |
MVPP2_GMAC_CONFIG_FULL_DUPLEX;
+ else if (port->phy_interface == PHY_INTERFACE_MODE_2500BASEX)
+ val |= MVPP2_GMAC_CONFIG_GMII_SPEED |
+ MVPP2_GMAC_CONFIG_MII_SPEED |
+ MVPP2_GMAC_CONFIG_FULL_DUPLEX;
else
val |= MVPP2_GMAC_AN_SPEED_EN |
MVPP2_GMAC_AN_DUPLEX_EN;
@@ -4693,7 +4721,8 @@ static void mvpp2_port_mii_gmac_configure(struct mvpp2_port *port)
/* Configure the PCS and in-band AN */
val = readl(port->base + MVPP2_GMAC_CTRL_2_REG);
if (port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
- port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX ||
+ port->phy_interface == PHY_INTERFACE_MODE_2500BASEX) {
val |= MVPP2_GMAC_INBAND_AN_MASK | MVPP2_GMAC_PCS_ENABLE_MASK;
} else if (phy_interface_mode_is_rgmii(port->phy_interface)) {
val &= ~MVPP2_GMAC_PCS_ENABLE_MASK;
@@ -4756,7 +4785,8 @@ static void mvpp2_port_mii_set(struct mvpp2_port *port)
if (phy_interface_mode_is_rgmii(port->phy_interface) ||
port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
- port->phy_interface == PHY_INTERFACE_MODE_1000BASEX)
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX ||
+ port->phy_interface == PHY_INTERFACE_MODE_2500BASEX)
mvpp2_port_mii_gmac_configure(port);
else if (port->phy_interface == PHY_INTERFACE_MODE_10GKR)
mvpp2_port_mii_xlg_configure(port);
@@ -4834,7 +4864,8 @@ static void mvpp2_port_loopback_set(struct mvpp2_port *port)
val &= ~MVPP2_GMAC_GMII_LB_EN_MASK;
if (port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
- port->phy_interface == PHY_INTERFACE_MODE_1000BASEX)
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX ||
+ port->phy_interface == PHY_INTERFACE_MODE_2500BASEX)
val |= MVPP2_GMAC_PCS_LB_EN_MASK;
else
val &= ~MVPP2_GMAC_PCS_LB_EN_MASK;
@@ -6048,7 +6079,8 @@ static irqreturn_t mvpp2_link_status_isr(int irq, void *dev_id)
}
} else if (phy_interface_mode_is_rgmii(port->phy_interface) ||
port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
- port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX ||
+ port->phy_interface == PHY_INTERFACE_MODE_2500BASEX) {
val = readl(port->base + MVPP22_GMAC_INT_STAT);
if (val & MVPP22_GMAC_INT_STAT_LINK) {
event = true;
--
2.14.3
^ permalink raw reply related
* Re: [Intel-wired-lan] [PATCH 01/27] timecounter: Make cyclecounter struct part of timecounter struct
From: Sagar Arun Kamble @ 2018-01-09 9:01 UTC (permalink / raw)
To: Brown, Aaron F, linux-kernel@vger.kernel.org
Cc: alsa-devel@alsa-project.org, linux-rdma@vger.kernel.org,
netdev@vger.kernel.org, Richard Cochran, Stephen Boyd,
Chris Wilson, John Stultz, intel-wired-lan@lists.osuosl.org,
Thomas Gleixner, kvmarm@lists.cs.columbia.edu,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <309B89C4C689E141A5FF6A0C5FB2118B8C734DF8@ORSMSX101.amr.corp.intel.com>
Thanks Aaron.
Regards,
Sagar
On 1/9/2018 3:50 AM, Brown, Aaron F wrote:
>> From: Intel-wired-lan [mailto:intel-wired-lan-bounces@osuosl.org] On
>> Behalf Of Sagar Arun Kamble
>> Sent: Thursday, December 14, 2017 11:38 PM
>> To: linux-kernel@vger.kernel.org
>> Cc: alsa-devel@alsa-project.org; linux-rdma@vger.kernel.org;
>> netdev@vger.kernel.org; Richard Cochran <richardcochran@gmail.com>;
>> Stephen Boyd <sboyd@codeaurora.org>; Chris Wilson <chris@chris-
>> wilson.co.uk>; John Stultz <john.stultz@linaro.org>; intel-wired-
>> lan@lists.osuosl.org; Thomas Gleixner <tglx@linutronix.de>; Kamble, Sagar A
>> <sagar.a.kamble@intel.com>; kvmarm@lists.cs.columbia.edu; linux-arm-
>> kernel@lists.infradead.org
>> Subject: [Intel-wired-lan] [PATCH 01/27] timecounter: Make cyclecounter
>> struct part of timecounter struct
>>
>> There is no real need for the users of timecounters to define cyclecounter
>> and timecounter variables separately. Since timecounter will always be
>> based on cyclecounter, have cyclecounter struct as member of timecounter
>> struct.
>>
>> v2: Rebase.
>>
>> Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
>> Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
>> Cc: Chris Wilson <chris@chris-wilson.co.uk>
>> Cc: Richard Cochran <richardcochran@gmail.com>
>> Cc: John Stultz <john.stultz@linaro.org>
>> Cc: Thomas Gleixner <tglx@linutronix.de>
>> Cc: Stephen Boyd <sboyd@codeaurora.org>
>> Cc: linux-kernel@vger.kernel.org
>> Cc: linux-arm-kernel@lists.infradead.org
>> Cc: netdev@vger.kernel.org
>> Cc: intel-wired-lan@lists.osuosl.org
>> Cc: linux-rdma@vger.kernel.org
>> Cc: alsa-devel@alsa-project.org
>> Cc: kvmarm@lists.cs.columbia.edu
>> Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> (Intel drivers)
>> ---
>> arch/microblaze/kernel/timer.c | 20 ++++++------
>> drivers/clocksource/arm_arch_timer.c | 19 ++++++------
>> drivers/net/ethernet/amd/xgbe/xgbe-dev.c | 3 +-
>> drivers/net/ethernet/amd/xgbe/xgbe-ptp.c | 9 +++---
>> drivers/net/ethernet/amd/xgbe/xgbe.h | 1 -
>> drivers/net/ethernet/broadcom/bnx2x/bnx2x.h | 1 -
>> drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 20 ++++++------
>> drivers/net/ethernet/freescale/fec.h | 1 -
>> drivers/net/ethernet/freescale/fec_ptp.c | 30 +++++++++---------
>> drivers/net/ethernet/intel/e1000e/e1000.h | 1 -
>> drivers/net/ethernet/intel/e1000e/netdev.c | 27 ++++++++--------
>> drivers/net/ethernet/intel/e1000e/ptp.c | 2 +-
>> drivers/net/ethernet/intel/igb/igb.h | 1 -
>> drivers/net/ethernet/intel/igb/igb_ptp.c | 25 ++++++++-------
>> drivers/net/ethernet/intel/ixgbe/ixgbe.h | 1 -
>> drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c | 17 +++++-----
>> drivers/net/ethernet/mellanox/mlx4/en_clock.c | 28 ++++++++---------
>> drivers/net/ethernet/mellanox/mlx4/mlx4_en.h | 1 -
>> .../net/ethernet/mellanox/mlx5/core/lib/clock.c | 34 ++++++++++----------
>> drivers/net/ethernet/qlogic/qede/qede_ptp.c | 20 ++++++------
>> drivers/net/ethernet/ti/cpts.c | 36 ++++++++++++----------
>> drivers/net/ethernet/ti/cpts.h | 1 -
>> include/linux/mlx5/driver.h | 1 -
>> include/linux/timecounter.h | 4 +--
>> include/sound/hdaudio.h | 1 -
>> kernel/time/timecounter.c | 28 ++++++++---------
>> sound/hda/hdac_stream.c | 7 +++--
>> virt/kvm/arm/arch_timer.c | 6 ++--
>> 28 files changed, 163 insertions(+), 182 deletions(-)
>>
> For Intel e1000e and igb drivers:
> Tested-by: Aaron Brown <aaron.f.brown@intel.com>
^ permalink raw reply
* Re: BUG: 4.14.11 unable to handle kernel NULL pointer dereference in xfrm_lookup
From: Tobias Hommel @ 2018-01-09 9:06 UTC (permalink / raw)
To: Steffen Klassert; +Cc: netdev
In-Reply-To: <20180109081939.qs2nrkuvmi3lw2dl@gauss3.secunet.de>
[-- Attachment #1: Type: text/plain, Size: 5736 bytes --]
On Tue, Jan 09, 2018 at 09:19:39AM +0100, Steffen Klassert wrote:
> On Mon, Jan 08, 2018 at 02:53:48PM +0100, Tobias Hommel wrote:
>
> ...
>
> > [ 439.095554] BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
> > [ 439.103664] IP: xfrm_lookup+0x2a/0x7d0
> > [ 439.107551] PGD 0 P4D 0
> > [ 439.110144] Oops: 0000 [#1] SMP PTI
> > [ 439.113653] Modules linked in:
> > [ 439.116774] CPU: 6 PID: 0 Comm: swapper/6 Not tainted 4.14.12 #1
> > [ 439.122900] Hardware name: To be filled by O.E.M. CAR-2051/CAR, BIOS 1.01 07/11/2016
> > [ 439.130769] task: ffff8cf33b0ea280 task.stack: ffff9492c0090000
> > [ 439.136726] RIP: 0010:xfrm_lookup+0x2a/0x7d0
> > [ 439.141005] RSP: 0018:ffff8cf33fd83bd0 EFLAGS: 00010246
> > [ 439.146315] RAX: 0000000000000000 RBX: ffffffff87074080 RCX: 0000000000000000
> > [ 439.153537] RDX: ffff8cf33fd83c48 RSI: 0000000000000000 RDI: ffffffff87074080
> > [ 439.160780] RBP: ffffffff87074080 R08: 0000000000000002 R09: 0000000000000000
> > [ 439.167958] R10: 0000000000000020 R11: 0000000000000020 R12: ffff8cf33fd83c48
> > [ 439.175115] R13: 0000000000000000 R14: 0000000000000002 R15: ffff8cf33b240078
> > [ 439.182337] FS: 0000000000000000(0000) GS:ffff8cf33fd80000(0000) knlGS:0000000000000000
> > [ 439.190456] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > [ 439.196227] CR2: 0000000000000020 CR3: 000000013200a000 CR4: 00000000001006e0
> > [ 439.203386] Call Trace:
> > [ 439.205869] <IRQ>
> > [ 439.207886] __xfrm_route_forward+0xa4/0x110
> > [ 439.212195] ip_forward+0x3da/0x450
> > [ 439.215696] ? ip_rcv_finish+0x61/0x390
> > [ 439.219542] ip_rcv+0x2b5/0x380
> > [ 439.222716] ? inet_del_offload+0x30/0x30
> > [ 439.226736] __netif_receive_skb_core+0x751/0xb00
> > [ 439.231469] ? netif_receive_skb_internal+0x47/0xf0
> > [ 439.236391] netif_receive_skb_internal+0x47/0xf0
> > [ 439.241150] napi_gro_flush+0x50/0x70
> > [ 439.244831] napi_complete_done+0x90/0xd0
> > [ 439.248872] igb_poll+0x8fd/0xe80
> > [ 439.252190] net_rx_action+0x1fc/0x310
> > [ 439.255978] __do_softirq+0xd5/0x1cf
> > [ 439.259584] irq_exit+0xa3/0xb0
> > [ 439.262763] do_IRQ+0x45/0xc0
> > [ 439.265772] common_interrupt+0x95/0x95
> > [ 439.269609] </IRQ>
> > [ 439.271733] RIP: 0010:cpuidle_enter_state+0x120/0x200
> > [ 439.276810] RSP: 0018:ffff9492c0093eb8 EFLAGS: 00000282 ORIG_RAX: ffffffffffffff5d
> > [ 439.284436] RAX: ffff8cf33fd9ea80 RBX: 0000000000000002 RCX: 000000663c21ea0f
> > [ 439.291604] RDX: 0000000000000000 RSI: 00000000355556ca RDI: 0000000000000000
> > [ 439.298772] RBP: ffff8cf33fda71e8 R08: 0000000000000003 R09: 0000000000000018
> > [ 439.305930] R10: 00000000ffffffff R11: 000000000000057c R12: 000000663c21ea0f
> > [ 439.313089] R13: 000000663c1c6c33 R14: 0000000000000002 R15: 0000000000000000
> > [ 439.320259] ? cpuidle_enter_state+0x11c/0x200
> > [ 439.324740] do_idle+0xd6/0x170
> > [ 439.327885] cpu_startup_entry+0x67/0x70
> > [ 439.331837] start_secondary+0x167/0x190
> > [ 439.335788] secondary_startup_64+0xa5/0xb0
> > [ 439.340001] Code: 00 41 57 41 56 45 89 c6 41 55 41 54 49 89 f5 55 53 49 89 d4 48 89 fb 48 83 ec 40 65 48 8b 04 25 28 00 00 00 48 89 44 24 38 31 c0 <48> 8b 46 20 48 85 c9 44 0f b7 38 c7 44 24 0c 00 00 00 00 0f 84
> > [ 439.358988] RIP: xfrm_lookup+0x2a/0x7d0 RSP: ffff8cf33fd83bd0
> > [ 439.364759] CR2: 0000000000000020
> > [ 439.368105] ---[ end trace c6b298b556ea7769 ]---
> > [ 439.372752] Kernel panic - not syncing: Fatal exception in interrupt
> > [ 439.379255] Kernel Offset: 0x5000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
> > [ 439.390029] Rebooting in 10 seconds..
>
> ...
>
> > 0000000000004230 <xfrm_lookup>:
> > 4230: 41 57 push %r15
> > 4232: 41 56 push %r14
> > 4234: 45 89 c6 mov %r8d,%r14d
> > 4237: 41 55 push %r13
> > 4239: 41 54 push %r12
> > 423b: 49 89 f5 mov %rsi,%r13
> > 423e: 55 push %rbp
> > 423f: 53 push %rbx
> > 4240: 49 89 d4 mov %rdx,%r12
> > 4243: 48 89 fb mov %rdi,%rbx
> > 4246: 48 83 ec 40 sub $0x40,%rsp
> > 424a: 65 48 8b 04 25 28 00 mov %gs:0x28,%rax
> > 4251: 00 00
> > 4253: 48 89 44 24 38 mov %rax,0x38(%rsp)
> > 4258: 31 c0 xor %eax,%eax
> > 425a: 48 8b 46 20 mov 0x20(%rsi),%rax
>
>
> The above is the failing instruction, RSI holds the second argument
> of the called function which is a NULL pointer. The second argument
> of xfrm_lookup() is dst_orig, so it is as I thought. Now let's find
> out why. I don't see anything obvious, so we need to narrow it down.
>
> > CONFIG_INET_ESP=y
> > CONFIG_INET_ESP_OFFLOAD=y
>
> You have CONFIG_INET_ESP_OFFLOAD enabled, this is new maybe it
> still has some problems. You should not hit an offload codepath
> because all your SAs are configured with UDP encapsulation which
> is still not supported with offload.
>
> Please try to disable GRO on both interfaces and see what happens:
>
> ethtool -K eth0 gro off
> ethtool -K eth1 gro off
I actually already tried that with only eth1 off, to verify I turned offloading
off for both interfaces. The same problem: see attached panic.gro_off.log
>
> Then disable CONFIG_INET_ESP_OFFLOAD and try again.
Rebuild with CONFIG_INET_ESP_OFFLOAD disabled, same problem: see attached
panic.esp_offload_disabled.log
>
> This should show us if this feature is responsible for the bug.
>
I will try narrowing down the problem by trying out some older kernels for now.
[-- Attachment #2: panic.esp_offload_disabled.log --]
[-- Type: text/plain, Size: 3344 bytes --]
[ 510.217190] BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
[ 510.225167] IP: xfrm_lookup+0x2a/0x7d0
[ 510.228934] PGD 0 P4D 0
[ 510.231508] Oops: 0000 [#1] SMP PTI
[ 510.235006] Modules linked in:
[ 510.238085] CPU: 5 PID: 0 Comm: swapper/5 Not tainted 4.14.12 #2
[ 510.244116] Hardware name: To be filled by O.E.M. CAR-2051/CAR, BIOS 1.01 07/11/2016
[ 510.251881] task: ffff9cb6bb0e8000 task.stack: ffffb2ffc0088000
[ 510.257829] RIP: 0010:xfrm_lookup+0x2a/0x7d0
[ 510.262127] RSP: 0018:ffff9cb6bfd43c40 EFLAGS: 00010246
[ 510.267387] RAX: 0000000000000000 RBX: ffffffff83074080 RCX: 0000000000000000
[ 510.274570] RDX: ffff9cb6bfd43cb8 RSI: 0000000000000000 RDI: ffffffff83074080
[ 510.281729] RBP: ffffffff83074080 R08: 0000000000000002 R09: 0000000000000001
[ 510.288888] R10: 0000000000000032 R11: 0000000000000000 R12: ffff9cb6bfd43cb8
[ 510.296055] R13: 0000000000000000 R14: 0000000000000002 R15: ffff9cb6bb244078
[ 510.303215] FS: 0000000000000000(0000) GS:ffff9cb6bfd40000(0000) knlGS:0000000000000000
[ 510.311361] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 510.317135] CR2: 0000000000000020 CR3: 000000014c00a000 CR4: 00000000001006e0
[ 510.324317] Call Trace:
[ 510.326798] <IRQ>
[ 510.328855] __xfrm_route_forward+0xa4/0x110
[ 510.333152] ip_forward+0x3da/0x450
[ 510.336644] ? ip_rcv_finish+0x61/0x390
[ 510.340507] ip_rcv+0x2b5/0x380
[ 510.343654] ? inet_del_offload+0x30/0x30
[ 510.347693] __netif_receive_skb_core+0x751/0xb00
[ 510.352426] ? inet_gro_receive+0x1fb/0x2b0
[ 510.356646] ? netif_receive_skb_internal+0x47/0xf0
[ 510.361550] netif_receive_skb_internal+0x47/0xf0
[ 510.366284] napi_gro_receive+0x70/0x90
[ 510.370132] gro_cell_poll+0x53/0x90
[ 510.373736] net_rx_action+0x1fc/0x310
[ 510.377518] __do_softirq+0xd5/0x1cf
[ 510.381123] irq_exit+0xa3/0xb0
[ 510.384294] do_IRQ+0x45/0xc0
[ 510.387282] common_interrupt+0x95/0x95
[ 510.391148] </IRQ>
[ 510.393272] RIP: 0010:cpuidle_enter_state+0x120/0x200
[ 510.398350] RSP: 0018:ffffb2ffc008beb8 EFLAGS: 00000282 ORIG_RAX: ffffffffffffff3c
[ 510.405967] RAX: ffff9cb6bfd5ea80 RBX: 0000000000000002 RCX: 00000076cb4fb64c
[ 510.413150] RDX: 0000000000000000 RSI: 00000000355556ca RDI: 0000000000000000
[ 510.420326] RBP: ffff9cb6bfd671e8 R08: 0000000000000003 R09: 0000000000000018
[ 510.427485] R10: 00000000ffffffff R11: 0000000000000139 R12: 00000076cb4fb64c
[ 510.434695] R13: 00000076cb468ed2 R14: 0000000000000002 R15: 0000000000000000
[ 510.441866] ? cpuidle_enter_state+0x11c/0x200
[ 510.446330] do_idle+0xd6/0x170
[ 510.449491] cpu_startup_entry+0x67/0x70
[ 510.453443] start_secondary+0x167/0x190
[ 510.457397] secondary_startup_64+0xa5/0xb0
[ 510.461616] Code: 00 41 57 41 56 45 89 c6 41 55 41 54 49 89 f5 55 53 49 89 d4 48 89 fb 48 83 ec 40 65 48 8b 04 25 28 00 00 00 48 89 44 24 38 31 c0 <48> 8b 46 20 48 85 c9 44 0f b7 38 c7 44 24 0c 00 00 00 00 0f 84
[ 510.480605] RIP: xfrm_lookup+0x2a/0x7d0 RSP: ffff9cb6bfd43c40
[ 510.486411] CR2: 0000000000000020
[ 510.489758] ---[ end trace dc7eee0efd22329c ]---
[ 510.494411] Kernel panic - not syncing: Fatal exception in interrupt
[ 510.500923] Kernel Offset: 0x1000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[ 510.511676] Rebooting in 10 seconds..
[-- Attachment #3: panic.gro_off.log --]
[-- Type: text/plain, Size: 2711 bytes --]
[ 1425.327056] BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
[ 1425.335100] IP: xfrm_lookup+0x2a/0x7d0
[ 1425.339062] PGD 0 P4D 0
[ 1425.341645] Oops: 0000 [#1] SMP PTI
[ 1425.345275] Modules linked in:
[ 1425.348484] CPU: 2 PID: 22 Comm: ksoftirqd/2 Not tainted 4.14.12 #1
[ 1425.354958] Hardware name: To be filled by O.E.M. CAR-2051/CAR, BIOS 1.01 07/11/2016
[ 1425.363044] task: ffff986b3b210000 task.stack: ffff9c23000f0000
[ 1425.369234] RIP: 0010:xfrm_lookup+0x2a/0x7d0
[ 1425.373667] RSP: 0018:ffff9c23000f3b20 EFLAGS: 00010246
[ 1425.379032] RAX: 0000000000000000 RBX: ffffffff8e074080 RCX: 0000000000000000
[ 1425.386505] RDX: ffff9c23000f3b98 RSI: 0000000000000000 RDI: ffffffff8e074080
[ 1425.394062] RBP: ffffffff8e074080 R08: 0000000000000002 R09: 0000000000000000
[ 1425.401420] R10: 0000000000000020 R11: 0000000000000020 R12: ffff9c23000f3b98
[ 1425.408786] R13: 0000000000000000 R14: 0000000000000002 R15: ffff986b3b244078
[ 1425.416162] FS: 0000000000000000(0000) GS:ffff986b3fc80000(0000) knlGS:0000000000000000
[ 1425.424568] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1425.430566] CR2: 0000000000000020 CR3: 000000006e00a000 CR4: 00000000001006e0
[ 1425.437940] Call Trace:
[ 1425.440486] __xfrm_route_forward+0xa4/0x110
[ 1425.444886] ip_forward+0x3da/0x450
[ 1425.448552] ? ip_rcv_finish+0x61/0x390
[ 1425.452519] ip_rcv+0x2b5/0x380
[ 1425.455727] ? inet_del_offload+0x30/0x30
[ 1425.459896] __netif_receive_skb_core+0x751/0xb00
[ 1425.464819] ? __alloc_pages_nodemask+0xc6/0x1f0
[ 1425.469723] ? netif_receive_skb_internal+0x47/0xf0
[ 1425.474931] netif_receive_skb_internal+0x47/0xf0
[ 1425.479768] napi_gro_receive+0x70/0x90
[ 1425.483781] igb_poll+0x600/0xe80
[ 1425.487283] ? xfrm4_dst_destroy+0x6d/0x90
[ 1425.491544] net_rx_action+0x1fc/0x310
[ 1425.495465] __do_softirq+0xd5/0x1cf
[ 1425.499156] run_ksoftirqd+0x14/0x30
[ 1425.502943] smpboot_thread_fn+0xf9/0x150
[ 1425.507250] kthread+0xf2/0x130
[ 1425.510577] ? sort_range+0x20/0x20
[ 1425.514269] ? kthread_park+0x60/0x60
[ 1425.518021] ret_from_fork+0x1f/0x30
[ 1425.521757] Code: 00 41 57 41 56 45 89 c6 41 55 41 54 49 89 f5 55 53 49 89 d4 48 89 fb 48 83 ec 40 65 48 8b 04 25 28 00 00 00 48 89 44 24 38 31 c0 <48> 8b 46 20 48 85 c9 44 0f b7 38 c7 44 24 0c 00 00 00 00 0f 84
[ 1425.541379] RIP: xfrm_lookup+0x2a/0x7d0 RSP: ffff9c23000f3b20
[ 1425.547367] CR2: 0000000000000020
[ 1425.550748] ---[ end trace 9cc9a035940887e0 ]---
[ 1425.555444] Kernel panic - not syncing: Fatal exception in interrupt
[ 1425.562184] Kernel Offset: 0xc000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[ 1425.572955] Rebooting in 10 seconds..
^ permalink raw reply
* Re: [PATCH v2] b43: Replace mdelay with usleep_range in b43_radio_2057_init_post
From: Arend van Spriel @ 2018-01-09 9:07 UTC (permalink / raw)
To: Jia-Ju Bai, Greg KH
Cc: Larry.Finger, kvalo, kstewart, johannes.berg, tiwai, colin.king,
andrew.zaborowski, linux-kernel, linux-wireless, netdev, b43-dev
In-Reply-To: <4201e8cd-81ba-ab7d-2a0d-af957c5dfed6@gmail.com>
On 1/9/2018 9:39 AM, Jia-Ju Bai wrote:
>
>
> On 2018/1/9 16:35, Greg KH wrote:
>> On Tue, Jan 09, 2018 at 09:40:06AM +0800, Jia-Ju Bai wrote:
>>> b43_radio_2057_init_post is not called in an interrupt handler
>>> nor holding a spinlock.
>>> The function mdelay in it can be replaced with usleep_range,
>>> to reduce busy wait.
>>>
>>> Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
>>> ---
>>> v2:
>>> * Replace mdelay with usleep_range, instead of msleep in v1.
>>> Thank Larry for good advice.
>>> ---
>>> drivers/net/wireless/broadcom/b43/phy_n.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/net/wireless/broadcom/b43/phy_n.c
>>> b/drivers/net/wireless/broadcom/b43/phy_n.c
>>> index a5557d7..f2a2f41 100644
>>> --- a/drivers/net/wireless/broadcom/b43/phy_n.c
>>> +++ b/drivers/net/wireless/broadcom/b43/phy_n.c
>>> @@ -1031,7 +1031,7 @@ static void b43_radio_2057_init_post(struct
>>> b43_wldev *dev)
>>> b43_radio_set(dev, R2057_RFPLL_MISC_CAL_RESETN, 0x78);
>>> b43_radio_set(dev, R2057_XTAL_CONFIG2, 0x80);
>>> - mdelay(2);
>>> + usleep_range(2000, 3000);
>> Where did 3000 come from? Are you sure about that?
>
> I am not very sure, and I use it according to Larry's message:
Hi Jia-Ju Bai,
The duration here is for settling the registers so hardware can pick it
up. Right after this they are written again. Now this is during
initialization of the radio so not time critical, but probably anything
in the range of 2000..3000 would also have been fine.
Regards,
Arend
^ 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