* linux-next: manual merge of the net-next tree with the mac80211 tree
From: Stephen Rothwell @ 2018-03-22 0:53 UTC (permalink / raw)
To: David Miller, Networking, Johannes Berg
Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
Ben Caradoc-Davies, Ilan Peer, Luca Coelho
[-- Attachment #1: Type: text/plain, Size: 2546 bytes --]
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
net/mac80211/debugfs.c
include/net/mac80211.h
between commit:
7c181f4fcdc6 ("mac80211: add ieee80211_hw flag for QoS NDP support")
from the mac80211 tree and commit:
94ba92713f83 ("mac80211: Call mgd_prep_tx before transmitting deauthentication")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc include/net/mac80211.h
index 2b581bd93812,2fd59ed3be00..000000000000
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@@ -2063,9 -2070,14 +2070,17 @@@ struct ieee80211_txq
* @IEEE80211_HW_SUPPORTS_TDLS_BUFFER_STA: Hardware supports buffer STA on
* TDLS links.
*
+ * @IEEE80211_HW_DOESNT_SUPPORT_QOS_NDP: The driver (or firmware) doesn't
+ * support QoS NDP for AP probing - that's most likely a driver bug.
+ *
+ * @IEEE80211_HW_DEAUTH_NEED_MGD_TX_PREP: The driver requires the
+ * mgd_prepare_tx() callback to be called before transmission of a
+ * deauthentication frame in case the association was completed but no
+ * beacon was heard. This is required in multi-channel scenarios, where the
+ * virtual interface might not be given air time for the transmission of
+ * the frame, as it is not synced with the AP/P2P GO yet, and thus the
+ * deauthentication frame might not be transmitted.
+ *
* @NUM_IEEE80211_HW_FLAGS: number of hardware flags, used for sizing arrays
*/
enum ieee80211_hw_flags {
@@@ -2109,7 -2121,7 +2124,8 @@@
IEEE80211_HW_REPORTS_LOW_ACK,
IEEE80211_HW_SUPPORTS_TX_FRAG,
IEEE80211_HW_SUPPORTS_TDLS_BUFFER_STA,
+ IEEE80211_HW_DOESNT_SUPPORT_QOS_NDP,
+ IEEE80211_HW_DEAUTH_NEED_MGD_TX_PREP,
/* keep last, obviously */
NUM_IEEE80211_HW_FLAGS
diff --cc net/mac80211/debugfs.c
index 94c7ee9df33b,a75653affbf7..000000000000
--- a/net/mac80211/debugfs.c
+++ b/net/mac80211/debugfs.c
@@@ -212,7 -212,7 +212,8 @@@ static const char *hw_flag_names[] =
FLAG(REPORTS_LOW_ACK),
FLAG(SUPPORTS_TX_FRAG),
FLAG(SUPPORTS_TDLS_BUFFER_STA),
+ FLAG(DOESNT_SUPPORT_QOS_NDP),
+ FLAG(DEAUTH_NEED_MGD_TX_PREP),
#undef FLAG
};
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [RFC PATCH 2/3] x86/io: implement 256-bit IO read and write
From: Linus Torvalds @ 2018-03-22 1:26 UTC (permalink / raw)
To: Alexander Duyck
Cc: Rahul Lakkireddy, Thomas Gleixner, x86@kernel.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
mingo@redhat.com, hpa@zytor.com, davem@davemloft.net,
akpm@linux-foundation.org, Ganesh GR, Nirranjan Kirubaharan,
Indranil Choudhury
In-Reply-To: <CAKgT0UeTHPVrxEUbEszxm1MyJsQDSLfyM8txHq=r7GVkPD37nQ@mail.gmail.com>
On Tue, Mar 20, 2018 at 7:42 AM, Alexander Duyck
<alexander.duyck@gmail.com> wrote:
>
> Instead of framing this as an enhanced version of the read/write ops
> why not look at replacing or extending something like the
> memcpy_fromio or memcpy_toio operations?
Yes, doing something like "memcpy_fromio_avx()" is much more
palatable, in that it works like the crypto functions do - if you do
big chunks, the "kernel_fpu_begin/end()" isn't nearly the issue it can
be otherwise.
Note that we definitely have seen hardware that *depends* on the
regular memcpy_fromio()" not doing big reads. I don't know how
hardware people screw it up, but it's clearly possible.
So it really needs to be an explicitly named function that basically a
driver can use to say "my hardware really likes big aligned accesses"
and explicitly ask for some AVX version if possible.
Linus
^ permalink raw reply
* [PATCH net-next v4 0/5] net: qualcomm: rmnet: Updates 2018-03-12
From: Subash Abhinov Kasiviswanathan @ 2018-03-22 1:48 UTC (permalink / raw)
To: davem, joe, netdev; +Cc: Subash Abhinov Kasiviswanathan
This series contains some minor updates for rmnet driver.
Patch 1 contains fixes for sparse warnings.
Patch 2 updates the copyright date to 2018.
Patch 3 is a cleanup in receive path.
Patch 4 has the new rmnet netlink attributes in uapi and updates the usage.
Patch 5 has the implementation of the fill_info operation.
v1->v2: Remove the force casts since the data type is changed to __be
types as mentioned by David.
v2->v3: Update copyright in files which actually had changes as
mentioned by Joe.
v3->v4: Add new netlink attributes for mux_id and flags instead of using the
the vlan attributes as mentioned by David. The rmnet specific flags are also
moved to uapi. The netlink updates are done as part of #4 and #5 has the
fill_info operation.
Subash Abhinov Kasiviswanathan (5):
net: qualcomm: rmnet: Fix casting issues
net: qualcomm: rmnet: Update copyright year to 2018
net: qualcomm: rmnet: Remove unnecessary device assignment
net: qualcomm: rmnet: Export mux_id and flags to netlink
net: qualcomm: rmnet: Implement fill_info
drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c | 73 +++++++++++++++++-----
drivers/net/ethernet/qualcomm/rmnet/rmnet_config.h | 2 +-
.../net/ethernet/qualcomm/rmnet/rmnet_handlers.c | 12 ++--
drivers/net/ethernet/qualcomm/rmnet/rmnet_map.h | 8 +--
.../ethernet/qualcomm/rmnet/rmnet_map_command.c | 4 +-
.../net/ethernet/qualcomm/rmnet/rmnet_map_data.c | 5 +-
.../net/ethernet/qualcomm/rmnet/rmnet_private.h | 8 +--
drivers/net/ethernet/qualcomm/rmnet/rmnet_vnd.c | 2 +-
include/uapi/linux/if_link.h | 21 +++++++
9 files changed, 94 insertions(+), 41 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH net-next v4 1/5] net: qualcomm: rmnet: Fix casting issues
From: Subash Abhinov Kasiviswanathan @ 2018-03-22 1:48 UTC (permalink / raw)
To: davem, joe, netdev; +Cc: Subash Abhinov Kasiviswanathan
In-Reply-To: <1521683295-22935-1-git-send-email-subashab@codeaurora.org>
Fix warnings which were reported when running with sparse
(make C=1 CF=-D__CHECK_ENDIAN__)
drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c:81:15:
warning: cast to restricted __be16
drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c:271:37:
warning: incorrect type in assignment (different base types)
expected unsigned short [unsigned] [usertype] pkt_len
got restricted __be16 [usertype] <noident>
drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c:287:29:
warning: incorrect type in assignment (different base types)
expected unsigned short [unsigned] [usertype] pkt_len
got restricted __be16 [usertype] <noident>
drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c:310:22:
warning: cast to restricted __be16
drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c:319:13:
warning: cast to restricted __be16
drivers/net/ethernet/qualcomm/rmnet/rmnet_map_command.c:49:18:
warning: cast to restricted __be16
drivers/net/ethernet/qualcomm/rmnet/rmnet_map_command.c:50:18:
warning: cast to restricted __be32
drivers/net/ethernet/qualcomm/rmnet/rmnet_map_command.c:74:21:
warning: cast to restricted __be16
Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
---
drivers/net/ethernet/qualcomm/rmnet/rmnet_map.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/qualcomm/rmnet/rmnet_map.h b/drivers/net/ethernet/qualcomm/rmnet/rmnet_map.h
index 6ce31e2..4f362df 100644
--- a/drivers/net/ethernet/qualcomm/rmnet/rmnet_map.h
+++ b/drivers/net/ethernet/qualcomm/rmnet/rmnet_map.h
@@ -23,8 +23,8 @@ struct rmnet_map_control_command {
struct {
u16 ip_family:2;
u16 reserved:14;
- u16 flow_control_seq_num;
- u32 qos_id;
+ __be16 flow_control_seq_num;
+ __be32 qos_id;
} flow_control;
u8 data[0];
};
@@ -44,7 +44,7 @@ struct rmnet_map_header {
u8 reserved_bit:1;
u8 cd_bit:1;
u8 mux_id;
- u16 pkt_len;
+ __be16 pkt_len;
} __aligned(1);
struct rmnet_map_dl_csum_trailer {
--
1.9.1
^ permalink raw reply related
* [PATCH net-next v4 2/5] net: qualcomm: rmnet: Update copyright year to 2018
From: Subash Abhinov Kasiviswanathan @ 2018-03-22 1:48 UTC (permalink / raw)
To: davem, joe, netdev; +Cc: Subash Abhinov Kasiviswanathan
In-Reply-To: <1521683295-22935-1-git-send-email-subashab@codeaurora.org>
Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
---
drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c | 2 +-
drivers/net/ethernet/qualcomm/rmnet/rmnet_config.h | 2 +-
drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c | 2 +-
drivers/net/ethernet/qualcomm/rmnet/rmnet_map.h | 2 +-
drivers/net/ethernet/qualcomm/rmnet/rmnet_map_command.c | 2 +-
drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c | 2 +-
drivers/net/ethernet/qualcomm/rmnet/rmnet_private.h | 2 +-
drivers/net/ethernet/qualcomm/rmnet/rmnet_vnd.c | 2 +-
8 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c b/drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c
index c494918..096301a 100644
--- a/drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c
+++ b/drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c
@@ -1,4 +1,4 @@
-/* Copyright (c) 2013-2017, The Linux Foundation. All rights reserved.
+/* Copyright (c) 2013-2018, The Linux Foundation. All rights reserved.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 and
diff --git a/drivers/net/ethernet/qualcomm/rmnet/rmnet_config.h b/drivers/net/ethernet/qualcomm/rmnet/rmnet_config.h
index 00e4634..0b5b5da 100644
--- a/drivers/net/ethernet/qualcomm/rmnet/rmnet_config.h
+++ b/drivers/net/ethernet/qualcomm/rmnet/rmnet_config.h
@@ -1,4 +1,4 @@
-/* Copyright (c) 2013-2014, 2016-2017 The Linux Foundation. All rights reserved.
+/* Copyright (c) 2013-2014, 2016-2018 The Linux Foundation. All rights reserved.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 and
diff --git a/drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c b/drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c
index 601edec..c758248 100644
--- a/drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c
+++ b/drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c
@@ -1,4 +1,4 @@
-/* Copyright (c) 2013-2017, The Linux Foundation. All rights reserved.
+/* Copyright (c) 2013-2018, The Linux Foundation. All rights reserved.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 and
diff --git a/drivers/net/ethernet/qualcomm/rmnet/rmnet_map.h b/drivers/net/ethernet/qualcomm/rmnet/rmnet_map.h
index 4f362df..884f1f5 100644
--- a/drivers/net/ethernet/qualcomm/rmnet/rmnet_map.h
+++ b/drivers/net/ethernet/qualcomm/rmnet/rmnet_map.h
@@ -1,4 +1,4 @@
-/* Copyright (c) 2013-2017, The Linux Foundation. All rights reserved.
+/* Copyright (c) 2013-2018, The Linux Foundation. All rights reserved.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 and
diff --git a/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_command.c b/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_command.c
index b0dbca0..afa2b86 100644
--- a/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_command.c
+++ b/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_command.c
@@ -1,4 +1,4 @@
-/* Copyright (c) 2013-2017, The Linux Foundation. All rights reserved.
+/* Copyright (c) 2013-2018, The Linux Foundation. All rights reserved.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 and
diff --git a/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c b/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c
index c74a6c5..49e420e 100644
--- a/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c
+++ b/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c
@@ -1,4 +1,4 @@
-/* Copyright (c) 2013-2017, The Linux Foundation. All rights reserved.
+/* Copyright (c) 2013-2018, The Linux Foundation. All rights reserved.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 and
diff --git a/drivers/net/ethernet/qualcomm/rmnet/rmnet_private.h b/drivers/net/ethernet/qualcomm/rmnet/rmnet_private.h
index de0143e..98365ef 100644
--- a/drivers/net/ethernet/qualcomm/rmnet/rmnet_private.h
+++ b/drivers/net/ethernet/qualcomm/rmnet/rmnet_private.h
@@ -1,4 +1,4 @@
-/* Copyright (c) 2013-2014, 2016-2017 The Linux Foundation. All rights reserved.
+/* Copyright (c) 2013-2014, 2016-2018 The Linux Foundation. All rights reserved.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 and
diff --git a/drivers/net/ethernet/qualcomm/rmnet/rmnet_vnd.c b/drivers/net/ethernet/qualcomm/rmnet/rmnet_vnd.c
index 346d310..2ea16a0 100644
--- a/drivers/net/ethernet/qualcomm/rmnet/rmnet_vnd.c
+++ b/drivers/net/ethernet/qualcomm/rmnet/rmnet_vnd.c
@@ -1,4 +1,4 @@
-/* Copyright (c) 2013-2017, The Linux Foundation. All rights reserved.
+/* Copyright (c) 2013-2018, The Linux Foundation. All rights reserved.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 and
--
1.9.1
^ permalink raw reply related
* [PATCH net-next v4 3/5] net: qualcomm: rmnet: Remove unnecessary device assignment
From: Subash Abhinov Kasiviswanathan @ 2018-03-22 1:48 UTC (permalink / raw)
To: davem, joe, netdev; +Cc: Subash Abhinov Kasiviswanathan
In-Reply-To: <1521683295-22935-1-git-send-email-subashab@codeaurora.org>
Device of the de-aggregated skb is correctly assigned after inspecting
the mux_id, so remove the assignment in rmnet_map_deaggregate().
Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
---
drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c b/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c
index 49e420e..e8f6c79 100644
--- a/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c
+++ b/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c
@@ -323,7 +323,6 @@ struct sk_buff *rmnet_map_deaggregate(struct sk_buff *skb,
if (!skbn)
return NULL;
- skbn->dev = skb->dev;
skb_reserve(skbn, RMNET_MAP_DEAGGR_HEADROOM);
skb_put(skbn, packet_len);
memcpy(skbn->data, skb->data, packet_len);
--
1.9.1
^ permalink raw reply related
* [PATCH net-next v4 4/5] net: qualcomm: rmnet: Export mux_id and flags to netlink
From: Subash Abhinov Kasiviswanathan @ 2018-03-22 1:48 UTC (permalink / raw)
To: davem, joe, netdev; +Cc: Subash Abhinov Kasiviswanathan
In-Reply-To: <1521683295-22935-1-git-send-email-subashab@codeaurora.org>
Define new netlink attributes for rmnet mux_id and flags. These
flags / mux_id were earlier using vlan flags / id respectively.
The flag bits are also moved to uapi and are renamed with
prefix RMNET_FLAG_*.
Also add the rmnet policy to handle the new netlink attributes.
Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
---
drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c | 41 +++++++++++++---------
.../net/ethernet/qualcomm/rmnet/rmnet_handlers.c | 10 +++---
.../ethernet/qualcomm/rmnet/rmnet_map_command.c | 2 +-
.../net/ethernet/qualcomm/rmnet/rmnet_map_data.c | 2 +-
.../net/ethernet/qualcomm/rmnet/rmnet_private.h | 6 ----
include/uapi/linux/if_link.h | 21 +++++++++++
6 files changed, 53 insertions(+), 29 deletions(-)
diff --git a/drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c b/drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c
index 096301a..c5b7b2a 100644
--- a/drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c
+++ b/drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c
@@ -43,6 +43,11 @@
/* Local Definitions and Declarations */
+static const struct nla_policy rmnet_policy[IFLA_RMNET_MAX + 1] = {
+ [IFLA_RMNET_MUX_ID] = { .type = NLA_U16 },
+ [IFLA_RMNET_FLAGS] = { .len = sizeof(struct ifla_rmnet_flags) },
+};
+
static int rmnet_is_real_dev_registered(const struct net_device *real_dev)
{
return rcu_access_pointer(real_dev->rx_handler) == rmnet_rx_handler;
@@ -131,7 +136,7 @@ static int rmnet_newlink(struct net *src_net, struct net_device *dev,
struct nlattr *tb[], struct nlattr *data[],
struct netlink_ext_ack *extack)
{
- u32 data_format = RMNET_INGRESS_FORMAT_DEAGGREGATION;
+ u32 data_format = RMNET_FLAGS_INGRESS_DEAGGREGATION;
struct net_device *real_dev;
int mode = RMNET_EPMODE_VND;
struct rmnet_endpoint *ep;
@@ -143,14 +148,14 @@ static int rmnet_newlink(struct net *src_net, struct net_device *dev,
if (!real_dev || !dev)
return -ENODEV;
- if (!data[IFLA_VLAN_ID])
+ if (!data[IFLA_RMNET_MUX_ID])
return -EINVAL;
ep = kzalloc(sizeof(*ep), GFP_ATOMIC);
if (!ep)
return -ENOMEM;
- mux_id = nla_get_u16(data[IFLA_VLAN_ID]);
+ mux_id = nla_get_u16(data[IFLA_RMNET_MUX_ID]);
err = rmnet_register_real_device(real_dev);
if (err)
@@ -165,10 +170,10 @@ static int rmnet_newlink(struct net *src_net, struct net_device *dev,
hlist_add_head_rcu(&ep->hlnode, &port->muxed_ep[mux_id]);
- if (data[IFLA_VLAN_FLAGS]) {
- struct ifla_vlan_flags *flags;
+ if (data[IFLA_RMNET_FLAGS]) {
+ struct ifla_rmnet_flags *flags;
- flags = nla_data(data[IFLA_VLAN_FLAGS]);
+ flags = nla_data(data[IFLA_RMNET_FLAGS]);
data_format = flags->flags & flags->mask;
}
@@ -276,10 +281,10 @@ static int rmnet_rtnl_validate(struct nlattr *tb[], struct nlattr *data[],
{
u16 mux_id;
- if (!data || !data[IFLA_VLAN_ID])
+ if (!data || !data[IFLA_RMNET_MUX_ID])
return -EINVAL;
- mux_id = nla_get_u16(data[IFLA_VLAN_ID]);
+ mux_id = nla_get_u16(data[IFLA_RMNET_MUX_ID]);
if (mux_id > (RMNET_MAX_LOGICAL_EP - 1))
return -ERANGE;
@@ -304,8 +309,8 @@ static int rmnet_changelink(struct net_device *dev, struct nlattr *tb[],
port = rmnet_get_port_rtnl(real_dev);
- if (data[IFLA_VLAN_ID]) {
- mux_id = nla_get_u16(data[IFLA_VLAN_ID]);
+ if (data[IFLA_RMNET_MUX_ID]) {
+ mux_id = nla_get_u16(data[IFLA_RMNET_MUX_ID]);
ep = rmnet_get_endpoint(port, priv->mux_id);
hlist_del_init_rcu(&ep->hlnode);
@@ -315,10 +320,10 @@ static int rmnet_changelink(struct net_device *dev, struct nlattr *tb[],
priv->mux_id = mux_id;
}
- if (data[IFLA_VLAN_FLAGS]) {
- struct ifla_vlan_flags *flags;
+ if (data[IFLA_RMNET_FLAGS]) {
+ struct ifla_rmnet_flags *flags;
- flags = nla_data(data[IFLA_VLAN_FLAGS]);
+ flags = nla_data(data[IFLA_RMNET_FLAGS]);
port->data_format = flags->flags & flags->mask;
}
@@ -327,13 +332,16 @@ static int rmnet_changelink(struct net_device *dev, struct nlattr *tb[],
static size_t rmnet_get_size(const struct net_device *dev)
{
- return nla_total_size(2) /* IFLA_VLAN_ID */ +
- nla_total_size(sizeof(struct ifla_vlan_flags)); /* IFLA_VLAN_FLAGS */
+ return
+ /* IFLA_RMNET_MUX_ID */
+ nla_total_size(2) +
+ /* IFLA_RMNET_FLAGS */
+ nla_total_size(sizeof(struct ifla_rmnet_flags));
}
struct rtnl_link_ops rmnet_link_ops __read_mostly = {
.kind = "rmnet",
- .maxtype = __IFLA_VLAN_MAX,
+ .maxtype = __IFLA_RMNET_MAX,
.priv_size = sizeof(struct rmnet_priv),
.setup = rmnet_vnd_setup,
.validate = rmnet_rtnl_validate,
@@ -341,6 +349,7 @@ struct rtnl_link_ops rmnet_link_ops __read_mostly = {
.dellink = rmnet_dellink,
.get_size = rmnet_get_size,
.changelink = rmnet_changelink,
+ .policy = rmnet_policy,
};
/* Needs either rcu_read_lock() or rtnl lock */
diff --git a/drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c b/drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c
index c758248..6fcd586 100644
--- a/drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c
+++ b/drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c
@@ -70,7 +70,7 @@ static void rmnet_set_skb_proto(struct sk_buff *skb)
u8 mux_id;
if (RMNET_MAP_GET_CD_BIT(skb)) {
- if (port->data_format & RMNET_INGRESS_FORMAT_MAP_COMMANDS)
+ if (port->data_format & RMNET_FLAGS_INGRESS_MAP_COMMANDS)
return rmnet_map_command(skb, port);
goto free_skb;
@@ -93,7 +93,7 @@ static void rmnet_set_skb_proto(struct sk_buff *skb)
skb_pull(skb, sizeof(struct rmnet_map_header));
rmnet_set_skb_proto(skb);
- if (port->data_format & RMNET_INGRESS_FORMAT_MAP_CKSUMV4) {
+ if (port->data_format & RMNET_FLAGS_INGRESS_MAP_CKSUMV4) {
if (!rmnet_map_checksum_downlink_packet(skb, len + pad))
skb->ip_summed = CHECKSUM_UNNECESSARY;
}
@@ -121,7 +121,7 @@ static void rmnet_set_skb_proto(struct sk_buff *skb)
skb_push(skb, ETH_HLEN);
}
- if (port->data_format & RMNET_INGRESS_FORMAT_DEAGGREGATION) {
+ if (port->data_format & RMNET_FLAGS_INGRESS_DEAGGREGATION) {
while ((skbn = rmnet_map_deaggregate(skb, port)) != NULL)
__rmnet_map_ingress_handler(skbn, port);
@@ -141,7 +141,7 @@ static int rmnet_map_egress_handler(struct sk_buff *skb,
additional_header_len = 0;
required_headroom = sizeof(struct rmnet_map_header);
- if (port->data_format & RMNET_EGRESS_FORMAT_MAP_CKSUMV4) {
+ if (port->data_format & RMNET_FLAGS_EGRESS_MAP_CKSUMV4) {
additional_header_len = sizeof(struct rmnet_map_ul_csum_header);
required_headroom += additional_header_len;
}
@@ -151,7 +151,7 @@ static int rmnet_map_egress_handler(struct sk_buff *skb,
goto fail;
}
- if (port->data_format & RMNET_EGRESS_FORMAT_MAP_CKSUMV4)
+ if (port->data_format & RMNET_FLAGS_EGRESS_MAP_CKSUMV4)
rmnet_map_checksum_uplink_packet(skb, orig_dev);
map_header = rmnet_map_add_map_header(skb, additional_header_len, 0);
diff --git a/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_command.c b/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_command.c
index afa2b86..78fdad0 100644
--- a/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_command.c
+++ b/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_command.c
@@ -69,7 +69,7 @@ static void rmnet_map_send_ack(struct sk_buff *skb,
struct rmnet_map_control_command *cmd;
int xmit_status;
- if (port->data_format & RMNET_INGRESS_FORMAT_MAP_CKSUMV4) {
+ if (port->data_format & RMNET_FLAGS_INGRESS_MAP_CKSUMV4) {
if (skb->len < sizeof(struct rmnet_map_header) +
RMNET_MAP_GET_LENGTH(skb) +
sizeof(struct rmnet_map_dl_csum_trailer)) {
diff --git a/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c b/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c
index e8f6c79..a6ea094 100644
--- a/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c
+++ b/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c
@@ -309,7 +309,7 @@ struct sk_buff *rmnet_map_deaggregate(struct sk_buff *skb,
maph = (struct rmnet_map_header *)skb->data;
packet_len = ntohs(maph->pkt_len) + sizeof(struct rmnet_map_header);
- if (port->data_format & RMNET_INGRESS_FORMAT_MAP_CKSUMV4)
+ if (port->data_format & RMNET_FLAGS_INGRESS_MAP_CKSUMV4)
packet_len += sizeof(struct rmnet_map_dl_csum_trailer);
if (((int)skb->len - (int)packet_len) < 0)
diff --git a/drivers/net/ethernet/qualcomm/rmnet/rmnet_private.h b/drivers/net/ethernet/qualcomm/rmnet/rmnet_private.h
index 98365ef..b9cc4f8 100644
--- a/drivers/net/ethernet/qualcomm/rmnet/rmnet_private.h
+++ b/drivers/net/ethernet/qualcomm/rmnet/rmnet_private.h
@@ -18,12 +18,6 @@
#define RMNET_NEEDED_HEADROOM 16
#define RMNET_TX_QUEUE_LEN 1000
-/* Constants */
-#define RMNET_INGRESS_FORMAT_DEAGGREGATION BIT(0)
-#define RMNET_INGRESS_FORMAT_MAP_COMMANDS BIT(1)
-#define RMNET_INGRESS_FORMAT_MAP_CKSUMV4 BIT(2)
-#define RMNET_EGRESS_FORMAT_MAP_CKSUMV4 BIT(3)
-
/* Replace skb->dev to a virtual rmnet device and pass up the stack */
#define RMNET_EPMODE_VND (1)
/* Pass the frame directly to another device with dev_queue_xmit() */
diff --git a/include/uapi/linux/if_link.h b/include/uapi/linux/if_link.h
index 11d0c0e..68699f6 100644
--- a/include/uapi/linux/if_link.h
+++ b/include/uapi/linux/if_link.h
@@ -959,4 +959,25 @@ enum {
#define IFLA_TUN_MAX (__IFLA_TUN_MAX - 1)
+/* rmnet section */
+
+#define RMNET_FLAGS_INGRESS_DEAGGREGATION (1U << 0)
+#define RMNET_FLAGS_INGRESS_MAP_COMMANDS (1U << 1)
+#define RMNET_FLAGS_INGRESS_MAP_CKSUMV4 (1U << 2)
+#define RMNET_FLAGS_EGRESS_MAP_CKSUMV4 (1U << 3)
+
+enum {
+ IFLA_RMNET_UNSPEC,
+ IFLA_RMNET_MUX_ID,
+ IFLA_RMNET_FLAGS,
+ __IFLA_RMNET_MAX,
+};
+
+#define IFLA_RMNET_MAX (__IFLA_RMNET_MAX - 1)
+
+struct ifla_rmnet_flags {
+ __u32 flags;
+ __u32 mask;
+};
+
#endif /* _UAPI_LINUX_IF_LINK_H */
--
1.9.1
^ permalink raw reply related
* [PATCH net-next v4 5/5] net: qualcomm: rmnet: Implement fill_info
From: Subash Abhinov Kasiviswanathan @ 2018-03-22 1:48 UTC (permalink / raw)
To: davem, joe, netdev; +Cc: Subash Abhinov Kasiviswanathan
In-Reply-To: <1521683295-22935-1-git-send-email-subashab@codeaurora.org>
This is needed to query the mux_id and flags of a rmnet device.
Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
---
drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c | 30 ++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c b/drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c
index c5b7b2a..38d9356 100644
--- a/drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c
+++ b/drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c
@@ -339,6 +339,35 @@ static size_t rmnet_get_size(const struct net_device *dev)
nla_total_size(sizeof(struct ifla_rmnet_flags));
}
+static int rmnet_fill_info(struct sk_buff *skb, const struct net_device *dev)
+{
+ struct rmnet_priv *priv = netdev_priv(dev);
+ struct net_device *real_dev;
+ struct ifla_rmnet_flags f;
+ struct rmnet_port *port;
+
+ real_dev = priv->real_dev;
+
+ if (!rmnet_is_real_dev_registered(real_dev))
+ return -ENODEV;
+
+ if (nla_put_u16(skb, IFLA_RMNET_MUX_ID, priv->mux_id))
+ goto nla_put_failure;
+
+ port = rmnet_get_port_rtnl(real_dev);
+
+ f.flags = port->data_format;
+ f.mask = ~0;
+
+ if (nla_put(skb, IFLA_RMNET_FLAGS, sizeof(f), &f))
+ goto nla_put_failure;
+
+ return 0;
+
+nla_put_failure:
+ return -EMSGSIZE;
+}
+
struct rtnl_link_ops rmnet_link_ops __read_mostly = {
.kind = "rmnet",
.maxtype = __IFLA_RMNET_MAX,
@@ -350,6 +379,7 @@ struct rtnl_link_ops rmnet_link_ops __read_mostly = {
.get_size = rmnet_get_size,
.changelink = rmnet_changelink,
.policy = rmnet_policy,
+ .fill_info = rmnet_fill_info,
};
/* Needs either rcu_read_lock() or rtnl lock */
--
1.9.1
^ permalink raw reply related
* Re: [PATCH net-next RFC V1 5/5] net: mdio: Add a driver for InES time stamping IP core.
From: Richard Cochran @ 2018-03-22 1:57 UTC (permalink / raw)
To: Andrew Lunn
Cc: netdev, devicetree, David Miller, Florian Fainelli, Mark Rutland,
Miroslav Lichvar, Rob Herring, Willem de Bruijn
In-Reply-To: <20180322004349.GB28402@lunn.ch>
On Thu, Mar 22, 2018 at 01:43:49AM +0100, Andrew Lunn wrote:
> On Wed, Mar 21, 2018 at 03:47:02PM -0700, Richard Cochran wrote:
> > I happy to improve the modeling, but the solution should be generic
> > and work for every MAC driver.
Let me qualify that a bit...
> Something else to think about. There are a number of MAC drivers which
> don't use phylib. All the intel drivers for example. They have their
> own MDIO and PHY code. And recently there have been a number of MAC
> drivers for hardware capable of > 1GBps which do all the PHY control
> in firmware.
>
> A phydev is optional, the MAC is mandatory.
So MACs that have a built in PHY won't work, but we don't care because
there is no way to hang another MII device in there anyhow.
We already require phylib for NETWORK_PHY_TIMESTAMPING, and so we
expect that here, too.
Many of these IP core things will be targeting arm with device tree,
and I want that to "just work" without MAC changes.
(This is exactly the same situation with DSA, BTW.)
If someone attaches an MII time stamper to a MACs whose driver does
their own thing without phylib, then they are going to have to hack
the MAC driver in any case. Such hacks will never be acceptable for
mainline because they are design specific. We really don't have to
worry about this case.
Thanks,
Richard
^ permalink raw reply
* Re: [bpf-next V2 PATCH 10/15] xdp: rhashtable with allocator ID to pointer mapping
From: Jason Wang @ 2018-03-22 2:16 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: netdev, BjörnTöpel, magnus.karlsson, eugenia,
John Fastabend, Eran Ben Elisha, Saeed Mahameed, galp,
Daniel Borkmann, Alexei Starovoitov, Tariq Toukan
In-Reply-To: <20180320152725.5ea01d34@redhat.com>
On 2018年03月20日 22:27, Jesper Dangaard Brouer wrote:
> On Tue, 20 Mar 2018 10:26:50 +0800
> Jason Wang <jasowang@redhat.com> wrote:
>
>> On 2018年03月19日 17:48, Jesper Dangaard Brouer wrote:
>>> On Fri, 16 Mar 2018 16:45:30 +0800
>>> Jason Wang <jasowang@redhat.com> wrote:
>>>
>>>> On 2018年03月10日 00:07, Jesper Dangaard Brouer wrote:
>>>>> On Fri, 9 Mar 2018 21:07:36 +0800
>>>>> Jason Wang <jasowang@redhat.com> wrote:
>>>>>
>>>>>>>>> Use the IDA infrastructure for getting a cyclic increasing ID number,
>>>>>>>>> that is used for keeping track of each registered allocator per
>>>>>>>>> RX-queue xdp_rxq_info.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Jesper Dangaard Brouer<brouer@redhat.com>
>>>>>>>> A stupid question is, can we manage to unify this ID with NAPI id?
>>>>>>> Sorry I don't understand the question?
>>>>>> I mean can we associate page poll pointer to napi_struct, record NAPI id
>>>>>> in xdp_mem_info and do lookup through NAPI id?
>>>>> No. The driver can unreg/reg a new XDP memory model,
>>>> Is there an actual use case for this?
>>> I believe this is the common use case. When attaching an XDP/bpf prog,
>>> then the driver usually want to change the RX-ring memory model
>>> (different performance trade off).
>> Right, but a single driver should only have one XDP memory model.
> No! -- a driver can have multiple XDP memory models, based on different
> performance trade offs and hardware capabilities.
>
> The mlx5 (100Gbit/s) driver/hardware is a good example, which need
> different memory models. It already support multiple RX memory models,
> depending on HW support.
So let me correct my question, not familiar with mlx5e driver but if I
understand correctly, driver (mlx5) will not change memory model during
runtime for each NAPI. So NAPI id still work in this case?
> So, I predict that we hit at performance
> limit around 42Mpps on PCIe (I can measure 36Mpps), this is due to
> PCI-express translations/sec limit. The mlx5 HW supports a compressed
> descriptor format which deliver packets in several pages (based on
> offset and len), thus lowering the needed PCIe transactions. The
> pitfall is that this comes tail room limitations, which can be okay if
> e.g. the users use-case does not involve cpumap.
>
> Plus, when a driver need to support AF_XDP zero-copy, that also count
> as another XDP memory model...
Yes or TAP zero-copy XDP. But it looks to me that we don't even need to
care about the recycling here since the pages belongs to userspace.
Thanks
^ permalink raw reply
* Re: Fw: [Bug 199109] New: pptp: kernel printk "recursion detected", and then reboot itself
From: xu heng @ 2018-03-22 2:41 UTC (permalink / raw)
To: Guillaume Nault; +Cc: Stephen Hemminger, xeb, netdev
In-Reply-To: <20180321083528.GN1351@alphalink.fr>
---- On Wed, 21 Mar 2018 16:35:28 +0800 Guillaume Nault <g.nault@alphalink.fr> wrote ----
> On Wed, Mar 21, 2018 at 09:03:57AM +0800, xu heng wrote:
> > Yes, i have tested it for 146390 seconds in my board, it's ok now. Thanks!
> >
> Feel free to add your Tested-by tag to the patch if you want to.
> Thanks for your report.
>
> Guillaume
>
> BTW, for your future exchanges on the list, please avoid top-posting.
>
I'm sorry for that, will never do that again. Thanks.
xuheng
^ permalink raw reply
* [PATCH V2 net-next] liquidio: Added support for trusted VF
From: Felix Manlunas @ 2018-03-22 6:30 UTC (permalink / raw)
To: davem
Cc: netdev, raghu.vatsavayi, derek.chickles, satananda.burla,
felix.manlunas, intiyaz.basha
From: Intiyaz Basha <intiyaz.basha@cavium.com>
When a VF is trusted, all promiscuous traffic will only be sent to that VF.
In normal operation promiscuous traffic is sent to the PF. There can be
only one trusted VF per PF
Signed-off-by: Intiyaz Basha <intiyaz.basha@cavium.com>
Signed-off-by: Felix Manlunas <felix.manlunas@cavium.com>
---
Patch Change Log:
V1 -> V2:
Used completion in place of wait queue
drivers/net/ethernet/cavium/liquidio/lio_main.c | 116 +++++++++++++++++++++
.../net/ethernet/cavium/liquidio/liquidio_common.h | 7 ++
.../net/ethernet/cavium/liquidio/octeon_device.h | 2 +
3 files changed, 125 insertions(+)
diff --git a/drivers/net/ethernet/cavium/liquidio/lio_main.c b/drivers/net/ethernet/cavium/liquidio/lio_main.c
index 140085b..21280cb 100644
--- a/drivers/net/ethernet/cavium/liquidio/lio_main.c
+++ b/drivers/net/ethernet/cavium/liquidio/lio_main.c
@@ -91,6 +91,11 @@ static int octeon_console_debug_enabled(u32 console)
*/
#define LIO_SYNC_OCTEON_TIME_INTERVAL_MS 60000
+struct lio_trusted_vf_ctx {
+ struct completion complete;
+ int status;
+};
+
struct liquidio_rx_ctl_context {
int octeon_id;
@@ -3265,10 +3270,120 @@ static int liquidio_get_vf_config(struct net_device *netdev, int vfidx,
ether_addr_copy(&ivi->mac[0], macaddr);
ivi->vlan = oct->sriov_info.vf_vlantci[vfidx] & VLAN_VID_MASK;
ivi->qos = oct->sriov_info.vf_vlantci[vfidx] >> VLAN_PRIO_SHIFT;
+ if (oct->sriov_info.trusted_vf.active &&
+ oct->sriov_info.trusted_vf.id == vfidx)
+ ivi->trusted = true;
+ else
+ ivi->trusted = false;
ivi->linkstate = oct->sriov_info.vf_linkstate[vfidx];
return 0;
}
+static void trusted_vf_callback(struct octeon_device *oct_dev,
+ u32 status, void *ptr)
+{
+ struct octeon_soft_command *sc = (struct octeon_soft_command *)ptr;
+ struct lio_trusted_vf_ctx *ctx;
+
+ ctx = (struct lio_trusted_vf_ctx *)sc->ctxptr;
+ ctx->status = status;
+
+ complete(&ctx->complete);
+}
+
+static int liquidio_send_vf_trust_cmd(struct lio *lio, int vfidx, bool trusted)
+{
+ struct octeon_device *oct = lio->oct_dev;
+ struct lio_trusted_vf_ctx *ctx;
+ struct octeon_soft_command *sc;
+ int ctx_size, retval;
+
+ ctx_size = sizeof(struct lio_trusted_vf_ctx);
+ sc = octeon_alloc_soft_command(oct, 0, 0, ctx_size);
+
+ ctx = (struct lio_trusted_vf_ctx *)sc->ctxptr;
+ init_completion(&ctx->complete);
+
+ sc->iq_no = lio->linfo.txpciq[0].s.q_no;
+
+ /* vfidx is 0 based, but vf_num (param1) is 1 based */
+ octeon_prepare_soft_command(oct, sc, OPCODE_NIC,
+ OPCODE_NIC_SET_TRUSTED_VF, 0, vfidx + 1,
+ trusted);
+
+ sc->callback = trusted_vf_callback;
+ sc->callback_arg = sc;
+ sc->wait_time = 1000;
+
+ retval = octeon_send_soft_command(oct, sc);
+ if (retval == IQ_SEND_FAILED) {
+ retval = -1;
+ } else {
+ /* Wait for response or timeout */
+ if (wait_for_completion_timeout(&ctx->complete,
+ msecs_to_jiffies(2000)))
+ retval = ctx->status;
+ else
+ retval = -1;
+ }
+
+ octeon_free_soft_command(oct, sc);
+
+ return retval;
+}
+
+static int liquidio_set_vf_trust(struct net_device *netdev, int vfidx,
+ bool setting)
+{
+ struct lio *lio = GET_LIO(netdev);
+ struct octeon_device *oct = lio->oct_dev;
+
+ if (strcmp(oct->fw_info.liquidio_firmware_version, "1.7.1") < 0) {
+ /* trusted vf is not supported by firmware older than 1.7.1 */
+ return -EOPNOTSUPP;
+ }
+
+ if (vfidx < 0 || vfidx >= oct->sriov_info.num_vfs_alloced) {
+ netif_info(lio, drv, lio->netdev, "Invalid vfidx %d\n", vfidx);
+ return -EINVAL;
+ }
+
+ if (setting) {
+ /* Set */
+
+ if (oct->sriov_info.trusted_vf.active &&
+ oct->sriov_info.trusted_vf.id == vfidx)
+ return 0;
+
+ if (oct->sriov_info.trusted_vf.active) {
+ netif_info(lio, drv, lio->netdev, "More than one trusted VF is not allowed\n");
+ return -EPERM;
+ }
+ } else {
+ /* Clear */
+
+ if (!oct->sriov_info.trusted_vf.active)
+ return 0;
+ }
+
+ if (!liquidio_send_vf_trust_cmd(lio, vfidx, setting)) {
+ if (setting) {
+ oct->sriov_info.trusted_vf.id = vfidx;
+ oct->sriov_info.trusted_vf.active = true;
+ } else {
+ oct->sriov_info.trusted_vf.active = false;
+ }
+
+ netif_info(lio, drv, lio->netdev, "VF %u is %strusted\n", vfidx,
+ setting ? "" : "not ");
+ } else {
+ netif_info(lio, drv, lio->netdev, "Failed to set VF trusted\n");
+ return -1;
+ }
+
+ return 0;
+}
+
static int liquidio_set_vf_link_state(struct net_device *netdev, int vfidx,
int linkstate)
{
@@ -3399,6 +3514,7 @@ static int liquidio_set_vf_link_state(struct net_device *netdev, int vfidx,
.ndo_set_vf_mac = liquidio_set_vf_mac,
.ndo_set_vf_vlan = liquidio_set_vf_vlan,
.ndo_get_vf_config = liquidio_get_vf_config,
+ .ndo_set_vf_trust = liquidio_set_vf_trust,
.ndo_set_vf_link_state = liquidio_set_vf_link_state,
};
diff --git a/drivers/net/ethernet/cavium/liquidio/liquidio_common.h b/drivers/net/ethernet/cavium/liquidio/liquidio_common.h
index ecc1682..82a783d 100644
--- a/drivers/net/ethernet/cavium/liquidio/liquidio_common.h
+++ b/drivers/net/ethernet/cavium/liquidio/liquidio_common.h
@@ -84,6 +84,7 @@ enum octeon_tag_type {
#define OPCODE_NIC_IF_CFG 0x09
#define OPCODE_NIC_VF_DRV_NOTICE 0x0A
#define OPCODE_NIC_INTRMOD_PARAMS 0x0B
+#define OPCODE_NIC_SET_TRUSTED_VF 0x13
#define OPCODE_NIC_SYNC_OCTEON_TIME 0x14
#define VF_DRV_LOADED 1
#define VF_DRV_REMOVED -1
@@ -918,6 +919,12 @@ struct oct_intrmod_cfg {
} s;
};
+struct lio_trusted_vf {
+ uint64_t active: 1;
+ uint64_t id : 8;
+ uint64_t reserved: 55;
+};
+
struct lio_time {
s64 sec; /* seconds */
s64 nsec; /* nanoseconds */
diff --git a/drivers/net/ethernet/cavium/liquidio/octeon_device.h b/drivers/net/ethernet/cavium/liquidio/octeon_device.h
index 63b0c75..91937cc 100644
--- a/drivers/net/ethernet/cavium/liquidio/octeon_device.h
+++ b/drivers/net/ethernet/cavium/liquidio/octeon_device.h
@@ -370,6 +370,8 @@ struct octeon_sriov_info {
u32 sriov_enabled;
+ struct lio_trusted_vf trusted_vf;
+
/*lookup table that maps DPI ring number to VF pci_dev struct pointer*/
struct pci_dev *dpiring_to_vfpcidev_lut[MAX_POSSIBLE_VFS];
--
1.8.3.1
^ permalink raw reply related
* [PATCH net 1/3] lan78xx: Set ASD in MAC_CR when EEE is enabled.
From: Raghuram Chary J @ 2018-03-22 7:41 UTC (permalink / raw)
To: davem; +Cc: netdev, unglinuxdriver, woojung.huh, raghuramchary.jallipalli
Description:
EEE does not work with lan7800 when AutoSpeed is not set.
(This can happen when EEPROM is not populated or configured incorrectly)
Root-Cause:
When EEE is enabled, the mac config register ASD is not set
i.e in default state,causing EEE fail.
Fix:
Set the register when eeprom is not present.
Fixes: 55d7de9de6c3 ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet device driver")
Signed-off-by: Raghuram Chary J <raghuramchary.jallipalli@microchip.com>
---
drivers/net/usb/lan78xx.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c
index 11176070b345..e2d26f9c0f6a 100644
--- a/drivers/net/usb/lan78xx.c
+++ b/drivers/net/usb/lan78xx.c
@@ -2351,6 +2351,7 @@ static int lan78xx_reset(struct lan78xx_net *dev)
u32 buf;
int ret = 0;
unsigned long timeout;
+ u8 sig;
ret = lan78xx_read_reg(dev, HW_CFG, &buf);
buf |= HW_CFG_LRST_;
@@ -2450,6 +2451,15 @@ static int lan78xx_reset(struct lan78xx_net *dev)
/* LAN7801 only has RGMII mode */
if (dev->chipid == ID_REV_CHIP_ID_7801_)
buf &= ~MAC_CR_GMII_EN_;
+
+ if(dev->chipid == ID_REV_CHIP_ID_7800_) {
+ ret = lan78xx_read_raw_eeprom(dev, 0, 1, &sig);
+ if ((!ret) && (sig != EEPROM_INDICATOR)) {
+ /*Implies there is no external eeprom. Set mac speed*/
+ netdev_info(dev->net, "No External EEPROM. Setting MAC Speed \n");
+ buf |= MAC_CR_AUTO_DUPLEX_ | MAC_CR_AUTO_SPEED_;
+ }
+ }
ret = lan78xx_write_reg(dev, MAC_CR, buf);
ret = lan78xx_read_reg(dev, MAC_TX, &buf);
--
2.16.2
^ permalink raw reply related
* Re: [PATCH net-next 06/12] net: stmmac: dwmac-sun8i: Use regmap_field for syscon register access
From: kbuild test robot @ 2018-03-22 7:42 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Mark Rutland, devicetree, Maxime Ripard, netdev,
Michael Turquette, Stephen Boyd, Chen-Yu Tsai, Rob Herring,
Mark Brown, kbuild-all, Corentin Labbe, Giuseppe Cavallaro,
linux-clk, linux-arm-kernel, Icenowy Zheng
In-Reply-To: <20180317092857.4396-7-wens@csie.org>
Hi Chen-Yu,
I love your patch! Perhaps something to improve:
[auto build test WARNING on next-20180309]
[also build test WARNING on v4.16-rc6]
[cannot apply to v4.16-rc4 v4.16-rc3 v4.16-rc2]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Chen-Yu-Tsai/ARM-sun8i-r40-Add-Ethernet-support/20180318-161723
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
>> drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c:82:24: sparse: symbol 'sun8i_syscon_reg_field' was not declared. Should it be static?
Please review and possibly fold the followup patch.
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* [RFC PATCH] net: stmmac: dwmac-sun8i: sun8i_syscon_reg_field can be static
From: kbuild test robot @ 2018-03-22 7:42 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Mark Rutland, devicetree, Maxime Ripard, netdev,
Michael Turquette, Stephen Boyd, Chen-Yu Tsai, Rob Herring,
Mark Brown, kbuild-all, Corentin Labbe, Giuseppe Cavallaro,
linux-clk, linux-arm-kernel, Icenowy Zheng
In-Reply-To: <20180317092857.4396-7-wens@csie.org>
Fixes: e3c10deef23c ("net: stmmac: dwmac-sun8i: Use regmap_field for syscon register access")
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
---
dwmac-sun8i.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index de93f0f..bbc0514 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -79,7 +79,7 @@ struct sunxi_priv_data {
};
/* EMAC clock register @ 0x30 in the "system control" address range */
-const struct reg_field sun8i_syscon_reg_field = {
+static const struct reg_field sun8i_syscon_reg_field = {
.reg = 0x30,
.lsb = 0,
.msb = 31,
^ permalink raw reply related
* [RFC PATCH] net: stmmac: dwmac-sun8i: sun8i_ccu_reg_field can be static
From: kbuild test robot @ 2018-03-22 8:41 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Mark Rutland, devicetree, Maxime Ripard, netdev,
Michael Turquette, Stephen Boyd, Chen-Yu Tsai, Rob Herring,
Mark Brown, kbuild-all, Corentin Labbe, Giuseppe Cavallaro,
linux-clk, linux-arm-kernel, Icenowy Zheng
In-Reply-To: <20180317092857.4396-10-wens@csie.org>
Fixes: 0e59c15b2797 ("net: stmmac: dwmac-sun8i: Add support for GMAC on Allwinner R40 SoC")
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
---
dwmac-sun8i.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index be6705e8..622fb2b 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -98,7 +98,7 @@ const struct reg_field sun8i_syscon_reg_field = {
};
/* EMAC clock register @ 0x164 in the CCU address range */
-const struct reg_field sun8i_ccu_reg_field = {
+static const struct reg_field sun8i_ccu_reg_field = {
.reg = 0x164,
.lsb = 0,
.msb = 31,
^ permalink raw reply related
* Re: [PATCH net-next 09/12] net: stmmac: dwmac-sun8i: Add support for GMAC on Allwinner R40 SoC
From: kbuild test robot @ 2018-03-22 8:41 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Mark Rutland, devicetree, Maxime Ripard, netdev,
Michael Turquette, Stephen Boyd, Chen-Yu Tsai, Rob Herring,
Mark Brown, kbuild-all, Corentin Labbe, Giuseppe Cavallaro,
linux-clk, linux-arm-kernel, Icenowy Zheng
In-Reply-To: <20180317092857.4396-10-wens@csie.org>
Hi Chen-Yu,
I love your patch! Perhaps something to improve:
[auto build test WARNING on next-20180309]
[also build test WARNING on v4.16-rc6]
[cannot apply to v4.16-rc4 v4.16-rc3 v4.16-rc2]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Chen-Yu-Tsai/ARM-sun8i-r40-Add-Ethernet-support/20180318-161723
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c:94:24: sparse: symbol 'sun8i_syscon_reg_field' was not declared. Should it be static?
>> drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c:101:24: sparse: symbol 'sun8i_ccu_reg_field' was not declared. Should it be static?
Please review and possibly fold the followup patch.
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* [PATCH] ixgbe: tweak page counting for XDP_REDIRECT
From: Björn Töpel @ 2018-03-22 9:02 UTC (permalink / raw)
To: jeffrey.t.kirsher, intel-wired-lan
Cc: Björn Töpel, magnus.karlsson, netdev, alexander.h.duyck,
alexander.duyck
From: Björn Töpel <bjorn.topel@intel.com>
The current page counting scheme assumes that the reference count
cannot decrease until the received frame is sent to the upper layers
of the networking stack. This assumption does not hold for the
XDP_REDIRECT action, since a page (pointed out by xdp_buff) can have
its reference count decreased via the xdp_do_redirect call.
To work around that, we now start off by a large page count and then
don't allow a refcount less than two.
Signed-off-by: Björn Töpel <bjorn.topel@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index fb80edbd2739..8dbb2ce06287 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -1629,7 +1629,8 @@ static bool ixgbe_alloc_mapped_page(struct ixgbe_ring *rx_ring,
bi->dma = dma;
bi->page = page;
bi->page_offset = ixgbe_rx_offset(rx_ring);
- bi->pagecnt_bias = 1;
+ page_ref_add(page, USHRT_MAX - 1);
+ bi->pagecnt_bias = USHRT_MAX;
rx_ring->rx_stats.alloc_rx_page++;
return true;
@@ -2039,8 +2040,8 @@ static bool ixgbe_can_reuse_rx_page(struct ixgbe_rx_buffer *rx_buffer)
* the pagecnt_bias and page count so that we fully restock the
* number of references the driver holds.
*/
- if (unlikely(!pagecnt_bias)) {
- page_ref_add(page, USHRT_MAX);
+ if (unlikely(pagecnt_bias == 1)) {
+ page_ref_add(page, USHRT_MAX - 1);
rx_buffer->pagecnt_bias = USHRT_MAX;
}
--
2.7.4
^ permalink raw reply related
* [PATCH v2 1/2] i40e: tweak page counting for XDP_REDIRECT
From: Björn Töpel @ 2018-03-22 9:03 UTC (permalink / raw)
To: jeffrey.t.kirsher, intel-wired-lan
Cc: Björn Töpel, magnus.karlsson, netdev, alexander.h.duyck,
alexander.duyck
From: Björn Töpel <bjorn.topel@intel.com>
This commit tweaks the page counting for XDP_REDIRECT to function
properly. XDP_REDIRECT support will be added in a future commit.
The current page counting scheme assumes that the reference count
cannot decrease until the received frame is sent to the upper layers
of the networking stack. This assumption does not hold for the
XDP_REDIRECT action, since a page (pointed out by xdp_buff) can have
its reference count decreased via the xdp_do_redirect call.
To work around that, we now start off by a large page count and then
don't allow a refcount less than two.
Signed-off-by: Björn Töpel <bjorn.topel@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_txrx.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_txrx.c b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
index e8eef9a56b6b..2f817d1466eb 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_txrx.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
@@ -1588,9 +1588,8 @@ static bool i40e_alloc_mapped_page(struct i40e_ring *rx_ring,
bi->dma = dma;
bi->page = page;
bi->page_offset = i40e_rx_offset(rx_ring);
-
- /* initialize pagecnt_bias to 1 representing we fully own page */
- bi->pagecnt_bias = 1;
+ page_ref_add(page, USHRT_MAX - 1);
+ bi->pagecnt_bias = USHRT_MAX;
return true;
}
@@ -1956,8 +1955,8 @@ static bool i40e_can_reuse_rx_page(struct i40e_rx_buffer *rx_buffer)
* the pagecnt_bias and page count so that we fully restock the
* number of references the driver holds.
*/
- if (unlikely(!pagecnt_bias)) {
- page_ref_add(page, USHRT_MAX);
+ if (unlikely(pagecnt_bias == 1)) {
+ page_ref_add(page, USHRT_MAX - 1);
rx_buffer->pagecnt_bias = USHRT_MAX;
}
--
2.7.4
^ permalink raw reply related
* [PATCH v2 2/2] i40e: add support for XDP_REDIRECT
From: Björn Töpel @ 2018-03-22 9:03 UTC (permalink / raw)
To: jeffrey.t.kirsher, intel-wired-lan
Cc: Björn Töpel, magnus.karlsson, netdev, alexander.h.duyck,
alexander.duyck
In-Reply-To: <20180322090307.14409-1-bjorn.topel@gmail.com>
From: Björn Töpel <bjorn.topel@intel.com>
The driver now acts upon the XDP_REDIRECT return action. Two new ndos
are implemented, ndo_xdp_xmit and ndo_xdp_flush.
XDP_REDIRECT action enables XDP program to redirect frames to other
netdevs.
Signed-off-by: Björn Töpel <bjorn.topel@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_main.c | 2 +
drivers/net/ethernet/intel/i40e/i40e_txrx.c | 74 +++++++++++++++++++++++++----
drivers/net/ethernet/intel/i40e/i40e_txrx.h | 2 +
3 files changed, 68 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index 79ab52276d12..2fb4261b4fd9 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -11815,6 +11815,8 @@ static const struct net_device_ops i40e_netdev_ops = {
.ndo_bridge_getlink = i40e_ndo_bridge_getlink,
.ndo_bridge_setlink = i40e_ndo_bridge_setlink,
.ndo_bpf = i40e_xdp,
+ .ndo_xdp_xmit = i40e_xdp_xmit,
+ .ndo_xdp_flush = i40e_xdp_flush,
};
/**
diff --git a/drivers/net/ethernet/intel/i40e/i40e_txrx.c b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
index 2f817d1466eb..0168611312df 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_txrx.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
@@ -2214,7 +2214,7 @@ static int i40e_xmit_xdp_ring(struct xdp_buff *xdp,
static struct sk_buff *i40e_run_xdp(struct i40e_ring *rx_ring,
struct xdp_buff *xdp)
{
- int result = I40E_XDP_PASS;
+ int err, result = I40E_XDP_PASS;
struct i40e_ring *xdp_ring;
struct bpf_prog *xdp_prog;
u32 act;
@@ -2233,6 +2233,10 @@ static struct sk_buff *i40e_run_xdp(struct i40e_ring *rx_ring,
xdp_ring = rx_ring->vsi->xdp_rings[rx_ring->queue_index];
result = i40e_xmit_xdp_ring(xdp, xdp_ring);
break;
+ case XDP_REDIRECT:
+ err = xdp_do_redirect(rx_ring->netdev, xdp, xdp_prog);
+ result = !err ? I40E_XDP_TX : I40E_XDP_CONSUMED;
+ break;
default:
bpf_warn_invalid_xdp_action(act);
case XDP_ABORTED:
@@ -2268,6 +2272,15 @@ static void i40e_rx_buffer_flip(struct i40e_ring *rx_ring,
#endif
}
+static inline void i40e_xdp_ring_update_tail(struct i40e_ring *xdp_ring)
+{
+ /* Force memory writes to complete before letting h/w
+ * know there are new descriptors to fetch.
+ */
+ wmb();
+ writel_relaxed(xdp_ring->next_to_use, xdp_ring->tail);
+}
+
/**
* i40e_clean_rx_irq - Clean completed descriptors from Rx ring - bounce buf
* @rx_ring: rx descriptor ring to transact packets on
@@ -2402,16 +2415,11 @@ static int i40e_clean_rx_irq(struct i40e_ring *rx_ring, int budget)
}
if (xdp_xmit) {
- struct i40e_ring *xdp_ring;
+ struct i40e_ring *xdp_ring =
+ rx_ring->vsi->xdp_rings[rx_ring->queue_index];
- xdp_ring = rx_ring->vsi->xdp_rings[rx_ring->queue_index];
-
- /* Force memory writes to complete before letting h/w
- * know there are new descriptors to fetch.
- */
- wmb();
-
- writel_relaxed(xdp_ring->next_to_use, xdp_ring->tail);
+ i40e_xdp_ring_update_tail(xdp_ring);
+ xdp_do_flush_map();
}
rx_ring->skb = skb;
@@ -3659,3 +3667,49 @@ netdev_tx_t i40e_lan_xmit_frame(struct sk_buff *skb, struct net_device *netdev)
return i40e_xmit_frame_ring(skb, tx_ring);
}
+
+/**
+ * i40e_xdp_xmit - Implements ndo_xdp_xmit
+ * @dev: netdev
+ * @xdp: XDP buffer
+ *
+ * Returns Zero if sent, else an error code
+ **/
+int i40e_xdp_xmit(struct net_device *dev, struct xdp_buff *xdp)
+{
+ struct i40e_netdev_priv *np = netdev_priv(dev);
+ unsigned int queue_index = smp_processor_id();
+ struct i40e_vsi *vsi = np->vsi;
+ int err;
+
+ if (test_bit(__I40E_VSI_DOWN, vsi->state))
+ return -EINVAL;
+
+ if (!i40e_enabled_xdp_vsi(vsi) || queue_index >= vsi->num_queue_pairs)
+ return -EINVAL;
+
+ err = i40e_xmit_xdp_ring(xdp, vsi->xdp_rings[queue_index]);
+ if (err != I40E_XDP_TX)
+ return -ENOMEM;
+
+ return 0;
+}
+
+/**
+ * i40e_xdp_flush - Implements ndo_xdp_flush
+ * @dev: netdev
+ **/
+void i40e_xdp_flush(struct net_device *dev)
+{
+ struct i40e_netdev_priv *np = netdev_priv(dev);
+ unsigned int queue_index = smp_processor_id();
+ struct i40e_vsi *vsi = np->vsi;
+
+ if (test_bit(__I40E_VSI_DOWN, vsi->state))
+ return;
+
+ if (!i40e_enabled_xdp_vsi(vsi) || queue_index >= vsi->num_queue_pairs)
+ return;
+
+ i40e_xdp_ring_update_tail(vsi->xdp_rings[queue_index]);
+}
diff --git a/drivers/net/ethernet/intel/i40e/i40e_txrx.h b/drivers/net/ethernet/intel/i40e/i40e_txrx.h
index 2444f338bb0c..a97e59721393 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_txrx.h
+++ b/drivers/net/ethernet/intel/i40e/i40e_txrx.h
@@ -510,6 +510,8 @@ u32 i40e_get_tx_pending(struct i40e_ring *ring, bool in_sw);
void i40e_detect_recover_hung(struct i40e_vsi *vsi);
int __i40e_maybe_stop_tx(struct i40e_ring *tx_ring, int size);
bool __i40e_chk_linearize(struct sk_buff *skb);
+int i40e_xdp_xmit(struct net_device *dev, struct xdp_buff *xdp);
+void i40e_xdp_flush(struct net_device *dev);
/**
* i40e_get_head - Retrieve head from head writeback
--
2.7.4
^ permalink raw reply related
* [PATCH net] virtio-net: Fix operstate for virtio when no VIRTIO_NET_F_STATUS
From: Jay Vosburgh @ 2018-03-22 9:05 UTC (permalink / raw)
To: netdev; +Cc: Michael S. Tsirkin, Jason Wang, David Miller, Ben Hutchings
The operstate update logic will leave an interface in the
default UNKNOWN operstate if the interface carrier state never changes
from the default carrier up state set at creation. This includes the
case of an explicit call to netif_carrier_on, as the carrier on to on
transition has no effect on operstate.
This affects virtio-net for the case that the virtio peer does
not support VIRTIO_NET_F_STATUS (the feature that provides carrier state
updates). Without this feature, the virtio specification states that
"the link should be assumed active," so, logically, the operstate should
be UP instead of UNKNOWN. This has impact on user space applications
that use the operstate to make availability decisions for the interface.
Resolve this by changing the virtio probe logic slightly to call
netif_carrier_off for both the "with" and "without" VIRTIO_NET_F_STATUS
cases, and then the existing call to netif_carrier_on for the "without"
case will cause an operstate transition.
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Jason Wang <jasowang@redhat.com>
Cc: Ben Hutchings <ben@decadent.org.uk>
Fixes: 167c25e4c550 ("virtio-net: init link state correctly")
Signed-off-by: Jay Vosburgh <jay.vosburgh@canonical.com>
---
I considered resolving this by changing linkwatch_init_dev to
unconditionally call rfc2863_policy, as that would always set operstate
for all interfaces.
This would not have any impact on most cases (as most drivers
call netif_carrier_off during probe), except for the loopback device,
which currently has an operstate of UNKNOWN (because it never does any
carrier state transitions). This change would add a round trip on the
dev_base_lock for every loopback device creation, which could have a
negative impact when creating many loopback devices, e.g., when
concurrently creating large numbers of containers.
drivers/net/virtio_net.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 23374603e4d9..7b187ec7411e 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -2857,8 +2857,8 @@ static int virtnet_probe(struct virtio_device *vdev)
/* Assume link up if device can't report link status,
otherwise get link status from config. */
+ netif_carrier_off(dev);
if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_STATUS)) {
- netif_carrier_off(dev);
schedule_work(&vi->config_work);
} else {
vi->status = VIRTIO_NET_S_LINK_UP;
--
2.14.1
^ permalink raw reply related
* Re: [PATCH][next] net: mvpp2: use correct index on array mvpp2_pools
From: Antoine Tenart @ 2018-03-22 9:24 UTC (permalink / raw)
To: Colin King
Cc: David S . Miller, Antoine Tenart, netdev, kernel-janitors,
linux-kernel
In-Reply-To: <20180321173115.1820-1-colin.king@canonical.com>
Hi Colin,
On Wed, Mar 21, 2018 at 05:31:15PM +0000, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Array mvpp2_pools is being indexed by long_log_pool, however this
> looks like a cut-n-paste bug and in fact should be short_log_pool.
>
> Detected by CoverityScan, CID#1466113 ("Copy-paste error")
>
> Fixes: 576193f2d579 ("net: mvpp2: jumbo frames support")
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Antoine Tenart <antoine.tenart@bootlin.com>
Thanks!
Antoine
> ---
> drivers/net/ethernet/marvell/mvpp2.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/marvell/mvpp2.c b/drivers/net/ethernet/marvell/mvpp2.c
> index 9bd35f2291d6..f8bc3d4a39ff 100644
> --- a/drivers/net/ethernet/marvell/mvpp2.c
> +++ b/drivers/net/ethernet/marvell/mvpp2.c
> @@ -4632,7 +4632,7 @@ static int mvpp2_swf_bm_pool_init(struct mvpp2_port *port)
> if (!port->pool_short) {
> port->pool_short =
> mvpp2_bm_pool_use(port, short_log_pool,
> - mvpp2_pools[long_log_pool].pkt_size);
> + mvpp2_pools[short_log_pool].pkt_size);
> if (!port->pool_short)
> return -ENOMEM;
>
> --
> 2.15.1
>
--
Antoine Ténart, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [v2] vhost: add vsock compat ioctl
From: Stefan Hajnoczi @ 2018-03-22 9:25 UTC (permalink / raw)
To: David Miller; +Cc: sonnyrao, netdev
In-Reply-To: <20180316.153018.1513048030981683655.davem@davemloft.net>
On Fri, Mar 16, 2018 at 7:30 PM, David Miller <davem@davemloft.net> wrote:
> Although the top level ioctls are probably size and layout compatible,
> I do not think that the deeper ioctls can be called by compat binaries
> without some translations in order for them to work.
I audited the vhost ioctl code when reviewing this patch and was
unable to find anything that would break for a 32-bit userspace
process.
drivers/vhost/net.c does the same thing already, which doesn't prove
it's correct but makes me more confident I didn't miss something while
auditing the vhost ioctl code.
Did you have a specific ioctl in mind?
Stefan
^ permalink raw reply
* Re: [PATCH net 1/3] lan78xx: Set ASD in MAC_CR when EEE is enabled.
From: Sergei Shtylyov @ 2018-03-22 9:26 UTC (permalink / raw)
To: Raghuram Chary J, davem; +Cc: netdev, unglinuxdriver, woojung.huh
In-Reply-To: <20180322074106.19987-1-raghuramchary.jallipalli@microchip.com>
Hello!
Only stylistic comments.
On 3/22/2018 10:41 AM, Raghuram Chary J wrote:
> Description:
> EEE does not work with lan7800 when AutoSpeed is not set.
> (This can happen when EEPROM is not populated or configured incorrectly)
>
> Root-Cause:
> When EEE is enabled, the mac config register ASD is not set
> i.e in default state,causing EEE fail.
Need a period after "i.e" and a space after comma.
> Fix:
> Set the register when eeprom is not present.
>
> Fixes: 55d7de9de6c3 ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet device driver")
> Signed-off-by: Raghuram Chary J <raghuramchary.jallipalli@microchip.com>
> ---
> drivers/net/usb/lan78xx.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c
> index 11176070b345..e2d26f9c0f6a 100644
> --- a/drivers/net/usb/lan78xx.c
> +++ b/drivers/net/usb/lan78xx.c
> @@ -2351,6 +2351,7 @@ static int lan78xx_reset(struct lan78xx_net *dev)
> u32 buf;
> int ret = 0;
> unsigned long timeout;
> + u8 sig;
>
> ret = lan78xx_read_reg(dev, HW_CFG, &buf);
> buf |= HW_CFG_LRST_;
> @@ -2450,6 +2451,15 @@ static int lan78xx_reset(struct lan78xx_net *dev)
> /* LAN7801 only has RGMII mode */
> if (dev->chipid == ID_REV_CHIP_ID_7801_)
> buf &= ~MAC_CR_GMII_EN_;
> +
> + if(dev->chipid == ID_REV_CHIP_ID_7800_) {
Please run your patches thru scripts/checkpatch.pl -- it would have
complained because of a missing space between *if* and (.
> + ret = lan78xx_read_raw_eeprom(dev, 0, 1, &sig);
> + if ((!ret) && (sig != EEPROM_INDICATOR)) {
No need for the inner parens here, especially the 1st pair...
> + /*Implies there is no external eeprom. Set mac speed*/
Please add space after /* and before */.
> + netdev_info(dev->net, "No External EEPROM. Setting MAC Speed \n");
> + buf |= MAC_CR_AUTO_DUPLEX_ | MAC_CR_AUTO_SPEED_;
> + }
> + }
> ret = lan78xx_write_reg(dev, MAC_CR, buf);
>
> ret = lan78xx_read_reg(dev, MAC_TX, &buf);
MBR, Sergei
^ permalink raw reply
* Re: [RFC PATCH 0/3] kernel: add support for 256-bit IO access
From: Ingo Molnar @ 2018-03-22 9:33 UTC (permalink / raw)
To: Linus Torvalds
Cc: Thomas Gleixner, David Laight, Rahul Lakkireddy, x86@kernel.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
mingo@redhat.com, hpa@zytor.com, davem@davemloft.net,
akpm@linux-foundation.org, ganeshgr@chelsio.com,
nirranjan@chelsio.com, indranil@chelsio.com, Andy Lutomirski,
Peter Zijlstra, Fenghua Yu, Eric Biggers
In-Reply-To: <CA+55aFyK6uJopBjZGyeDz0O+qzCac6AwPkJyOpuaT69inPgVgw@mail.gmail.com>
* Linus Torvalds <torvalds@linux-foundation.org> wrote:
> And the real worry is things like AVX-512 etc, which is exactly when
> things like "save and restore one ymm register" will quite likely
> clear the upper bits of the zmm register.
Yeah, I think the only valid save/restore pattern is to 100% correctly enumerate
the width of the vector registers, and use full width instructions.
Using partial registers, even though it's possible in some cases is probably a bad
idea not just due to most instructions auto-zeroing the upper portion to reduce
false dependencies, but also because 'mixed' use of partial and full register
access is known to result in penalties on a wide range of Intel CPUs, at least
according to the Agner PDFs. On AMD CPUs there's no penalty.
So what I think could be done at best is to define a full register save/restore
API, which falls back to XSAVE*/XRSTOR* if we don't have the routines for the
native vector register width. (I.e. if old kernel is used on very new CPU.)
Note that the actual AVX code could still use partial width, it's the save/restore
primitives that has to handle full width registers.
> And yes, we can have some statically patched code that takes that into account,
> and saves the whole zmm register when AVX512 is on, but the whole *point* of the
> dynamic XSAVES thing is actually that Intel wants to be able enable new
> user-space features without having to wait for OS support. Literally. That's why
> and how it was designed.
This aspect wouldn't be hurt AFAICS: to me it appears that due to glibc using
vector instructions in its memset() the AVX bits get used early on and to the
maximum, so the XINUSE for them is set for every task.
The optionality of other XSAVE based features like MPX wouldn't be hurt if the
kernel only uses vector registers.
> And saving a couple of zmm registers is actually pretty hard. They're big. Do
> you want to allocate 128 bytes of stack space, preferably 64-byte aligned, for a
> save area? No. So now it needs to be some kind of per-thread (or maybe per-CPU,
> if we're willing to continue to not preempt) special save area too.
Hm, that's indeed a nasty complication:
- While a single 128 bytes slot might work - in practice at least two vector
registers are needed to have enough parallelism and hide latencies.
- ¤t->thread.fpu.state.xsave is available almost all the time: with our
current 'direct' FPU context switching code the only time there's live data in
¤t->thread.fpu is when the task is not running. But it's not IRQ-safe.
We could probably allow irq save/restore sections to use it, as
local_irq_save()/restore() is still *much* faster than a 1-1.5K FPU context
save/restore pattern.
But I was hoping for a less restrictive model ... :-/
To have a better model and avoid the local_irq_save()/restore we could perhaps
change the IRQ model to have a per IRQ 'current' value (we have separate IRQ
stacks already), but that's quite a bit of work to transform all code that
operates on the interrupted task (scheduler and timer code).
But it's work that would be useful for other reasons as well.
With such a separation in place ¤t->thread.fpu.state.xsave would become a
generic, natural vector register save area.
> And even then, it doesn't solve the real worry of "maybe there will be odd
> interactions with future extensions that we don't even know of".
Yes, that's true, but I think we could avoid these dangers by using CPU model
based enumeration. The cost would be that vector ops would only be available on
new CPU models after an explicit opt-in. In many cases it will be a single new
constant to an existing switch() statement, easily backported as well.
> All this to do a 32-byte PIO access, with absolutely zero data right
> now on what the win is?
Ok, so that's not what I'd use it for, I'd use it:
- Speed up existing AVX (crypto, RAID) routines for smaller buffer sizes.
Right now the XSAVE*+XRSTOR* cost is significant:
x86/fpu: Cost of: XSAVE insn: 104 cycles
x86/fpu: Cost of: XRSTOR insn: 80 cycles
... and that's with just 128-bit AVX and a ~0.8K XSAVE area. The Agner PDF
lists Skylake XSAVE+XRSTOR costs at 107+122 cycles, plus there's probably a
significant amount of L1 cache churn caused by XSAVE/XRSTOR.
Most of the relevant vector instructions have a single cycle cost
on the other hand.
- To use vector ops in bulk, well-aligned memcpy(), which in many workloads
is a fair chunk of all memset() activity. A usage profile on a typical system:
galatea:~> cat /proc/sched_debug | grep hist | grep -E '[[:digit:]]{4,}$' | grep '0\]'
hist[0x0000]: 1514272
hist[0x0010]: 1905248
hist[0x0020]: 99471
hist[0x0030]: 343309
hist[0x0040]: 177874
hist[0x0080]: 190052
hist[0x00a0]: 5258
hist[0x00b0]: 2387
hist[0x00c0]: 6975
hist[0x00d0]: 5872
hist[0x0100]: 3229
hist[0x0140]: 4813
hist[0x0160]: 9323
hist[0x0200]: 12540
hist[0x0230]: 37488
hist[0x1000]: 17136
hist[0x1d80]: 225199
First column is length of the area copied, the column is usage count.
To do this I wouldn't complicate the main memset() interface in any way to
branch it off to vector ops, I'd isolate specific memcpy()'s and memset()s
(such as page table copying and page clearing) and use the simpler
vector register based primitives there.
For example we have clear_page() which is used by GFP_ZERO and by other places
is implemented on modern x86 CPUs as:
ENTRY(clear_page_erms)
movl $4096,%ecx
xorl %eax,%eax
rep stosb
ret
While for such buffer sizes the enhanced-REP string instructions are supposed
to be slightly faster than 128-bit AVX ops, for such exact page granular ops
I'm pretty sure 256-bit (and 512-bit) vector ops are faster.
- For page granular memset/memcpy it would also be interesting to investigate
whether non-temporal, cache-preserving vector ops for such known-large bulk
ops, such as VMOVNTQA, are beneficial in certain circumstances.
On x86 there's only a single non-temporal instruction to GP registers:
MOVNTI, and for stores only.
The vector instructions space is a lot richer in that regard, allowing
non-temporal loads as well which utilize fill buffers to move chunks of memory
into vector registers.
Random example: in do_cow_fault() we use copy_user_highpage() to copy the page,
which uses copy_user_page() -> copy_page(), which uses:
ENTRY(copy_page)
ALTERNATIVE "jmp copy_page_regs", "", X86_FEATURE_REP_GOOD
movl $4096/8, %ecx
rep movsq
ret
But in this COW copy case it's pretty obvious that we shouldn't keep the
_source_ page in cache. So we could use non-temporal load, which appear to make
a difference on more recent uarchs even on write-back memory ranges:
https://stackoverflow.com/questions/40096894/do-current-x86-architectures-support-non-temporal-loads-from-normal-memory
See the final graph in that entry and now the 'NT load' variant results in the
best execution time in the 4K case - and this is a limited benchmark that
doesn't measure the lower cache eviction pressure by NT loads.
( The store part is probably better done into the cache, not just due to the
SFENCE cost (which is relatively low at 40 cycles), but because it's probably
beneficial to prime the cache with a freshly COW-ed page, it's going to get
used in the near future once we return from the fault. )
etc.
- But more broadly, if we open up vector ops for smaller buffer sizes as well
then I think other kernel code would start using them as well:
- I think the BPF JIT, whose byte code machine languge is used by an
increasing number of kernel subsystems, could benefit from having vector ops.
It would possibly allow the handling of floating point types.
- We could consider implementing vector ops based copy-to-user and copy-from-user
primitives as well, for cases where we know that the dominant usage pattern is
for larger, well-aligned chunks of memory.
- Maybe we could introduce a floating point library (which falls back to a C
implementation) and simplify scheduler math. We go to ridiculous lengths to
maintain precision across a wide range of parameters, essentially implementing
128-bit fixed point math. Even 32-bit floating point math would possibly be
better than that, even if it was done via APIs.
etc.: I think the large vector processor available in modern x86 CPUs could be
utilized by the kernel as well for various purposes.
But I think that's only worth doing if vector registers and their save areas are
easily accessibly and the accesses are fundamentally IRQ safe.
> Yes, yes, I can find an Intel white-paper that talks about setting WC and then
> using xmm and ymm instructions to write a single 64-byte burst over PCIe, and I
> assume that is where the code and idea came from. But I don't actually see any
> reason why a burst of 8 regular quad-word bytes wouldn't cause a 64-byte burst
> write too.
Yeah, I'm not too convinced about the wide readq/writeq usecase either, I just
used the opportunity to outline these (very vague) plans about utilizing vector
instructions more broadly within the kernel.
> So as far as I can tell, there are basically *zero* upsides, and a lot of
> potential downsides.
I agree about the potential downsides and I think most of them can be addressed
adequately - and I think my list of upsides above is potentially significant,
especially once we have lightweight APIs to utilize individual vector registers
without having to do a full save/restore of ~1K large vector register context.
Thanks,
Ingo
^ 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