* [PATCH REPOST net 1/2] net/mlx4: Move the tunnel steering helper function to mlx4_core
From: Or Gerlitz @ 2014-08-27 13:47 UTC (permalink / raw)
To: davem; +Cc: netdev, amirv, Or Gerlitz
In-Reply-To: <1409147269-21472-1-git-send-email-ogerlitz@mellanox.com>
Move the function which we use to set VXLAN DMFS (flow-steering) rules
from mlx4_en to mlx4_core. This refactoring will allow the mlx4_ib driver
to call the helper for the use case of user-space RAW Ethernet QPs, such
that they can serve VXLAN traffic too.
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 31 +------------------
drivers/net/ethernet/mellanox/mlx4/mcg.c | 38 ++++++++++++++++++++++++
include/linux/mlx4/device.h | 3 ++
3 files changed, 43 insertions(+), 29 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
index bb536aa..abddcf8 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
@@ -474,39 +474,12 @@ static int mlx4_en_tunnel_steer_add(struct mlx4_en_priv *priv, unsigned char *ad
int qpn, u64 *reg_id)
{
int err;
- struct mlx4_spec_list spec_eth_outer = { {NULL} };
- struct mlx4_spec_list spec_vxlan = { {NULL} };
- struct mlx4_spec_list spec_eth_inner = { {NULL} };
-
- struct mlx4_net_trans_rule rule = {
- .queue_mode = MLX4_NET_TRANS_Q_FIFO,
- .exclusive = 0,
- .allow_loopback = 1,
- .promisc_mode = MLX4_FS_REGULAR,
- .priority = MLX4_DOMAIN_NIC,
- };
-
- __be64 mac_mask = cpu_to_be64(MLX4_MAC_MASK << 16);
if (priv->mdev->dev->caps.tunnel_offload_mode != MLX4_TUNNEL_OFFLOAD_MODE_VXLAN)
return 0; /* do nothing */
- rule.port = priv->port;
- rule.qpn = qpn;
- INIT_LIST_HEAD(&rule.list);
-
- spec_eth_outer.id = MLX4_NET_TRANS_RULE_ID_ETH;
- memcpy(spec_eth_outer.eth.dst_mac, addr, ETH_ALEN);
- memcpy(spec_eth_outer.eth.dst_mac_msk, &mac_mask, ETH_ALEN);
-
- spec_vxlan.id = MLX4_NET_TRANS_RULE_ID_VXLAN; /* any vxlan header */
- spec_eth_inner.id = MLX4_NET_TRANS_RULE_ID_ETH; /* any inner eth header */
-
- list_add_tail(&spec_eth_outer.list, &rule.list);
- list_add_tail(&spec_vxlan.list, &rule.list);
- list_add_tail(&spec_eth_inner.list, &rule.list);
-
- err = mlx4_flow_attach(priv->mdev->dev, &rule, reg_id);
+ err = mlx4_tunnel_steer_add(priv->mdev->dev, addr, priv->port, qpn,
+ MLX4_DOMAIN_NIC, reg_id);
if (err) {
en_err(priv, "failed to add vxlan steering rule, err %d\n", err);
return err;
diff --git a/drivers/net/ethernet/mellanox/mlx4/mcg.c b/drivers/net/ethernet/mellanox/mlx4/mcg.c
index d80e7a6..ca0f98c 100644
--- a/drivers/net/ethernet/mellanox/mlx4/mcg.c
+++ b/drivers/net/ethernet/mellanox/mlx4/mcg.c
@@ -1020,6 +1020,44 @@ int mlx4_flow_detach(struct mlx4_dev *dev, u64 reg_id)
}
EXPORT_SYMBOL_GPL(mlx4_flow_detach);
+int mlx4_tunnel_steer_add(struct mlx4_dev *dev, unsigned char *addr,
+ int port, int qpn, u16 prio, u64 *reg_id)
+{
+ int err;
+ struct mlx4_spec_list spec_eth_outer = { {NULL} };
+ struct mlx4_spec_list spec_vxlan = { {NULL} };
+ struct mlx4_spec_list spec_eth_inner = { {NULL} };
+
+ struct mlx4_net_trans_rule rule = {
+ .queue_mode = MLX4_NET_TRANS_Q_FIFO,
+ .exclusive = 0,
+ .allow_loopback = 1,
+ .promisc_mode = MLX4_FS_REGULAR,
+ };
+
+ __be64 mac_mask = cpu_to_be64(MLX4_MAC_MASK << 16);
+
+ rule.port = port;
+ rule.qpn = qpn;
+ rule.priority = prio;
+ INIT_LIST_HEAD(&rule.list);
+
+ spec_eth_outer.id = MLX4_NET_TRANS_RULE_ID_ETH;
+ memcpy(spec_eth_outer.eth.dst_mac, addr, ETH_ALEN);
+ memcpy(spec_eth_outer.eth.dst_mac_msk, &mac_mask, ETH_ALEN);
+
+ spec_vxlan.id = MLX4_NET_TRANS_RULE_ID_VXLAN; /* any vxlan header */
+ spec_eth_inner.id = MLX4_NET_TRANS_RULE_ID_ETH; /* any inner eth header */
+
+ list_add_tail(&spec_eth_outer.list, &rule.list);
+ list_add_tail(&spec_vxlan.list, &rule.list);
+ list_add_tail(&spec_eth_inner.list, &rule.list);
+
+ err = mlx4_flow_attach(dev, &rule, reg_id);
+ return err;
+}
+EXPORT_SYMBOL(mlx4_tunnel_steer_add);
+
int mlx4_FLOW_STEERING_IB_UC_QP_RANGE(struct mlx4_dev *dev, u32 min_range_qpn,
u32 max_range_qpn)
{
diff --git a/include/linux/mlx4/device.h b/include/linux/mlx4/device.h
index 071f6b2..511c6e0 100644
--- a/include/linux/mlx4/device.h
+++ b/include/linux/mlx4/device.h
@@ -1196,6 +1196,9 @@ int mlx4_map_sw_to_hw_steering_id(struct mlx4_dev *dev,
enum mlx4_net_trans_rule_id id);
int mlx4_hw_rule_sz(struct mlx4_dev *dev, enum mlx4_net_trans_rule_id id);
+int mlx4_tunnel_steer_add(struct mlx4_dev *dev, unsigned char *addr,
+ int port, int qpn, u16 prio, u64 *reg_id);
+
void mlx4_sync_pkey_table(struct mlx4_dev *dev, int slave, int port,
int i, int val);
--
1.7.1
^ permalink raw reply related
* [PATCH REPOST net 0/2] Setup mlx4 user space Ethernet QPs to properly handle VXLAN
From: Or Gerlitz @ 2014-08-27 13:47 UTC (permalink / raw)
To: davem; +Cc: netdev, amirv, Or Gerlitz
Hi Dave,
A repost -- with Gerrit labels removed
This short series fixes the mlx4 driver setting of user space Ethernet QPs
(e.g those opened by DPDK applications) such that they will properly handle
VXLAN traffic/offloads
Or.
Or Gerlitz (2):
net/mlx4: Move the tunnel steering helper function to mlx4_core
mlx4: Set user-space raw Ethernet QPs to properly handle VXLAN traffic
drivers/infiniband/hw/mlx4/main.c | 30 +++++++++++++++++++
drivers/infiniband/hw/mlx4/qp.c | 8 ++++-
drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 31 +------------------
drivers/net/ethernet/mellanox/mlx4/mcg.c | 38 ++++++++++++++++++++++++
include/linux/mlx4/device.h | 3 ++
5 files changed, 80 insertions(+), 30 deletions(-)
^ permalink raw reply
* [PATCH net 0/2] Setup mlx4 user space Ethernet QPs to properly handle VXLAN
From: Or Gerlitz @ 2014-08-27 13:44 UTC (permalink / raw)
To: davem; +Cc: netdev, amirv, Or Gerlitz
Hi Dave,
This short series fixes the mlx4 driver setting of user space Ethernet QPs
(e.g those opened by DPDK applications) such that they will properly handle
VXLAN traffic/offloads
Or.
Or Gerlitz (2):
net/mlx4: Move the tunnel steering helper function to mlx4_core
mlx4: Set user-space raw Ethernet QPs to properly handle VXLAN traffic
drivers/infiniband/hw/mlx4/main.c | 30 +++++++++++++++++++
drivers/infiniband/hw/mlx4/qp.c | 8 ++++-
drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 31 +------------------
drivers/net/ethernet/mellanox/mlx4/mcg.c | 38 ++++++++++++++++++++++++
include/linux/mlx4/device.h | 3 ++
5 files changed, 80 insertions(+), 30 deletions(-)
^ permalink raw reply
* [PATCH net 1/2] net/mlx4: Move the tunnel steering helper function to mlx4_core
From: Or Gerlitz @ 2014-08-27 13:44 UTC (permalink / raw)
To: davem; +Cc: netdev, amirv, Or Gerlitz
In-Reply-To: <1409147079-18826-1-git-send-email-ogerlitz@mellanox.com>
Move the function which we use to set VXLAN DMFS (flow-steering) rules
from mlx4_en to mlx4_core. This refactoring will allow the mlx4_ib driver
to call the helper for the use case of user-space RAW Ethernet QPs, such
that they can serve VXLAN traffic too.
Issue: 360382
Change-Id: I9e92c874953df22f1fbcfe409400797517f517b4
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 31 +------------------
drivers/net/ethernet/mellanox/mlx4/mcg.c | 38 ++++++++++++++++++++++++
include/linux/mlx4/device.h | 3 ++
3 files changed, 43 insertions(+), 29 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
index bb536aa..abddcf8 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
@@ -474,39 +474,12 @@ static int mlx4_en_tunnel_steer_add(struct mlx4_en_priv *priv, unsigned char *ad
int qpn, u64 *reg_id)
{
int err;
- struct mlx4_spec_list spec_eth_outer = { {NULL} };
- struct mlx4_spec_list spec_vxlan = { {NULL} };
- struct mlx4_spec_list spec_eth_inner = { {NULL} };
-
- struct mlx4_net_trans_rule rule = {
- .queue_mode = MLX4_NET_TRANS_Q_FIFO,
- .exclusive = 0,
- .allow_loopback = 1,
- .promisc_mode = MLX4_FS_REGULAR,
- .priority = MLX4_DOMAIN_NIC,
- };
-
- __be64 mac_mask = cpu_to_be64(MLX4_MAC_MASK << 16);
if (priv->mdev->dev->caps.tunnel_offload_mode != MLX4_TUNNEL_OFFLOAD_MODE_VXLAN)
return 0; /* do nothing */
- rule.port = priv->port;
- rule.qpn = qpn;
- INIT_LIST_HEAD(&rule.list);
-
- spec_eth_outer.id = MLX4_NET_TRANS_RULE_ID_ETH;
- memcpy(spec_eth_outer.eth.dst_mac, addr, ETH_ALEN);
- memcpy(spec_eth_outer.eth.dst_mac_msk, &mac_mask, ETH_ALEN);
-
- spec_vxlan.id = MLX4_NET_TRANS_RULE_ID_VXLAN; /* any vxlan header */
- spec_eth_inner.id = MLX4_NET_TRANS_RULE_ID_ETH; /* any inner eth header */
-
- list_add_tail(&spec_eth_outer.list, &rule.list);
- list_add_tail(&spec_vxlan.list, &rule.list);
- list_add_tail(&spec_eth_inner.list, &rule.list);
-
- err = mlx4_flow_attach(priv->mdev->dev, &rule, reg_id);
+ err = mlx4_tunnel_steer_add(priv->mdev->dev, addr, priv->port, qpn,
+ MLX4_DOMAIN_NIC, reg_id);
if (err) {
en_err(priv, "failed to add vxlan steering rule, err %d\n", err);
return err;
diff --git a/drivers/net/ethernet/mellanox/mlx4/mcg.c b/drivers/net/ethernet/mellanox/mlx4/mcg.c
index d80e7a6..ca0f98c 100644
--- a/drivers/net/ethernet/mellanox/mlx4/mcg.c
+++ b/drivers/net/ethernet/mellanox/mlx4/mcg.c
@@ -1020,6 +1020,44 @@ int mlx4_flow_detach(struct mlx4_dev *dev, u64 reg_id)
}
EXPORT_SYMBOL_GPL(mlx4_flow_detach);
+int mlx4_tunnel_steer_add(struct mlx4_dev *dev, unsigned char *addr,
+ int port, int qpn, u16 prio, u64 *reg_id)
+{
+ int err;
+ struct mlx4_spec_list spec_eth_outer = { {NULL} };
+ struct mlx4_spec_list spec_vxlan = { {NULL} };
+ struct mlx4_spec_list spec_eth_inner = { {NULL} };
+
+ struct mlx4_net_trans_rule rule = {
+ .queue_mode = MLX4_NET_TRANS_Q_FIFO,
+ .exclusive = 0,
+ .allow_loopback = 1,
+ .promisc_mode = MLX4_FS_REGULAR,
+ };
+
+ __be64 mac_mask = cpu_to_be64(MLX4_MAC_MASK << 16);
+
+ rule.port = port;
+ rule.qpn = qpn;
+ rule.priority = prio;
+ INIT_LIST_HEAD(&rule.list);
+
+ spec_eth_outer.id = MLX4_NET_TRANS_RULE_ID_ETH;
+ memcpy(spec_eth_outer.eth.dst_mac, addr, ETH_ALEN);
+ memcpy(spec_eth_outer.eth.dst_mac_msk, &mac_mask, ETH_ALEN);
+
+ spec_vxlan.id = MLX4_NET_TRANS_RULE_ID_VXLAN; /* any vxlan header */
+ spec_eth_inner.id = MLX4_NET_TRANS_RULE_ID_ETH; /* any inner eth header */
+
+ list_add_tail(&spec_eth_outer.list, &rule.list);
+ list_add_tail(&spec_vxlan.list, &rule.list);
+ list_add_tail(&spec_eth_inner.list, &rule.list);
+
+ err = mlx4_flow_attach(dev, &rule, reg_id);
+ return err;
+}
+EXPORT_SYMBOL(mlx4_tunnel_steer_add);
+
int mlx4_FLOW_STEERING_IB_UC_QP_RANGE(struct mlx4_dev *dev, u32 min_range_qpn,
u32 max_range_qpn)
{
diff --git a/include/linux/mlx4/device.h b/include/linux/mlx4/device.h
index 071f6b2..511c6e0 100644
--- a/include/linux/mlx4/device.h
+++ b/include/linux/mlx4/device.h
@@ -1196,6 +1196,9 @@ int mlx4_map_sw_to_hw_steering_id(struct mlx4_dev *dev,
enum mlx4_net_trans_rule_id id);
int mlx4_hw_rule_sz(struct mlx4_dev *dev, enum mlx4_net_trans_rule_id id);
+int mlx4_tunnel_steer_add(struct mlx4_dev *dev, unsigned char *addr,
+ int port, int qpn, u16 prio, u64 *reg_id);
+
void mlx4_sync_pkey_table(struct mlx4_dev *dev, int slave, int port,
int i, int val);
--
1.7.1
^ permalink raw reply related
* [PATCH net 2/2] mlx4: Set user-space raw Ethernet QPs to properly handle VXLAN traffic
From: Or Gerlitz @ 2014-08-27 13:44 UTC (permalink / raw)
To: davem; +Cc: netdev, amirv, Or Gerlitz
In-Reply-To: <1409147079-18826-1-git-send-email-ogerlitz@mellanox.com>
Raw Ethernet QPs opened from user-space lack the proper setup to
recieve/handle VXLAN traffic when VXLAN offloads are enabled.
Fix that by adding a tunnel steering rule on top of the normal unicast
steering rule and set the tunnel_type field in the QP context.
Issue: 360382
Change-Id: I2198e871a581d2447156672630c026582489a5a9
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
---
drivers/infiniband/hw/mlx4/main.c | 30 ++++++++++++++++++++++++++++++
drivers/infiniband/hw/mlx4/qp.c | 8 +++++++-
2 files changed, 37 insertions(+), 1 deletions(-)
diff --git a/drivers/infiniband/hw/mlx4/main.c b/drivers/infiniband/hw/mlx4/main.c
index e1e558a..af82563 100644
--- a/drivers/infiniband/hw/mlx4/main.c
+++ b/drivers/infiniband/hw/mlx4/main.c
@@ -1089,6 +1089,30 @@ static int __mlx4_ib_destroy_flow(struct mlx4_dev *dev, u64 reg_id)
return err;
}
+static int mlx4_ib_tunnel_steer_add(struct ib_qp *qp, struct ib_flow_attr *flow_attr,
+ u64 *reg_id)
+{
+ void *ib_flow;
+ union ib_flow_spec *ib_spec;
+ struct mlx4_dev *dev = to_mdev(qp->device)->dev;
+ int err = 0;
+
+ if (dev->caps.tunnel_offload_mode != MLX4_TUNNEL_OFFLOAD_MODE_VXLAN)
+ return 0; /* do nothing */
+
+ ib_flow = flow_attr + 1;
+ ib_spec = (union ib_flow_spec *)ib_flow;
+
+ if (ib_spec->type != IB_FLOW_SPEC_ETH || flow_attr->num_of_specs != 1)
+ return 0; /* do nothing */
+
+ err = mlx4_tunnel_steer_add(to_mdev(qp->device)->dev, ib_spec->eth.val.dst_mac,
+ flow_attr->port, qp->qp_num,
+ MLX4_DOMAIN_UVERBS | (flow_attr->priority & 0xff),
+ reg_id);
+ return err;
+}
+
static struct ib_flow *mlx4_ib_create_flow(struct ib_qp *qp,
struct ib_flow_attr *flow_attr,
int domain)
@@ -1136,6 +1160,12 @@ static struct ib_flow *mlx4_ib_create_flow(struct ib_qp *qp,
i++;
}
+ if (i < ARRAY_SIZE(type) && flow_attr->type == IB_FLOW_ATTR_NORMAL) {
+ err = mlx4_ib_tunnel_steer_add(qp, flow_attr, &mflow->reg_id[i]);
+ if (err)
+ goto err_free;
+ }
+
return &mflow->ibflow;
err_free:
diff --git a/drivers/infiniband/hw/mlx4/qp.c b/drivers/infiniband/hw/mlx4/qp.c
index 6778045..efb9eff 100644
--- a/drivers/infiniband/hw/mlx4/qp.c
+++ b/drivers/infiniband/hw/mlx4/qp.c
@@ -1677,9 +1677,15 @@ static int __mlx4_ib_modify_qp(struct ib_qp *ibqp,
}
}
- if (qp->ibqp.qp_type == IB_QPT_RAW_PACKET)
+ if (qp->ibqp.qp_type == IB_QPT_RAW_PACKET) {
context->pri_path.ackto = (context->pri_path.ackto & 0xf8) |
MLX4_IB_LINK_TYPE_ETH;
+ if (dev->dev->caps.tunnel_offload_mode == MLX4_TUNNEL_OFFLOAD_MODE_VXLAN) {
+ /* set QP to receive both tunneled & non-tunneled packets */
+ if (!(context->flags & (1 << MLX4_RSS_QPC_FLAG_OFFSET)))
+ context->srqn = cpu_to_be32(7 << 28);
+ }
+ }
if (ibqp->qp_type == IB_QPT_UD && (new_state == IB_QPS_RTR)) {
int is_eth = rdma_port_get_link_layer(
--
1.7.1
^ permalink raw reply related
* Re: IPv6 Policy based routing not working.
From: Tushar Shinde @ 2014-08-27 13:41 UTC (permalink / raw)
To: Hannes Frederic Sowa; +Cc: netdev
In-Reply-To: <1409119546.11976.11.camel@localhost>
ping6 command uses SO_BINDTODEVICE but it looks it is not working. The
source address in fib6 rule match is 0:::0
strace ping6 -I eth0 2001:2::20 2> t
socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP) = 4
setsockopt(4, SOL_SOCKET, SO_BINDTODEVICE, "eth0\0", 5) = 0
connect(4, {sa_family=AF_INET6, sin6_port=htons(1025),
inet_pton(AF_INET6, "2001:2::20", &sin6_addr), sin6_flowinfo=0,
sin6_scope_id=0}, 28) = -1 ENETUNREACH (Network is unreachable)
I think there is problem with so_binddevice. need to dig further.
Tushar
On Wed, Aug 27, 2014 at 11:35 AM, Hannes Frederic Sowa
<hannes@stressinduktion.org> wrote:
> On Mi, 2014-08-27 at 11:32 +0530, Tushar Shinde wrote:
>> So do we need to always use ipv6 address to bind unlike ipv4?
>
> No, I think SO_BINDTODEVICE should work. But ping6 does not use it, so
> one could add support for this to ping with a new option.
>
> ping6 uses cmsg with undefined ipv6 source address but set ifindex and
> that's not at all like SO_BINDTODEVICE.
>
> Bye,
> Hannes
>
>
^ permalink raw reply
* [PATCH net] tg3: prevent ifup/ifdown during PCI error recovery
From: Ivan Vecera @ 2014-08-27 13:01 UTC (permalink / raw)
To: netdev; +Cc: Prashant Sreedharan, Michael Chan
The patch fixes race conditions between PCI error recovery callbacks and
potential ifup/ifdown.
First, if ifup (tg3_open) is called between tg3_io_error_detected() and
tg3_io_resume() then tp->timer is armed twice before expiry. Once during
tg3_open() and again during tg3_io_resume(). This results in BUG
at kernel/time/timer.c:945.
Second, if ifdown (tg3_close) is called between tg3_io_error_detected()
and tg3_io_resume() then tg3_napi_disable() is called twice without
a tg3_napi_enable between. Once during tg3_io_error_detected() and again
during tg3_close(). The tg3_io_resume() then hangs on rtnl_lock().
Cc: Prashant Sreedharan <prashant@broadcom.com>
Cc: Michael Chan <mchan@broadcom.com>
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
---
drivers/net/ethernet/broadcom/tg3.c | 10 ++++++++++
drivers/net/ethernet/broadcom/tg3.h | 1 +
2 files changed, 11 insertions(+)
diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c
index 3ac5d23..8d9c774 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -11617,6 +11617,9 @@ static int tg3_open(struct net_device *dev)
struct tg3 *tp = netdev_priv(dev);
int err;
+ if (tp->pcierr_recovery)
+ return -EAGAIN;
+
if (tp->fw_needed) {
err = tg3_request_firmware(tp);
if (tg3_asic_rev(tp) == ASIC_REV_57766) {
@@ -11674,6 +11677,9 @@ static int tg3_close(struct net_device *dev)
{
struct tg3 *tp = netdev_priv(dev);
+ if (tp->pcierr_recovery)
+ return -EAGAIN;
+
tg3_ptp_fini(tp);
tg3_stop(tp);
@@ -17561,6 +17567,7 @@ static int tg3_init_one(struct pci_dev *pdev,
tp->rx_mode = TG3_DEF_RX_MODE;
tp->tx_mode = TG3_DEF_TX_MODE;
tp->irq_sync = 1;
+ tp->pcierr_recovery = false;
if (tg3_debug > 0)
tp->msg_enable = tg3_debug;
@@ -18071,6 +18078,8 @@ static pci_ers_result_t tg3_io_error_detected(struct pci_dev *pdev,
rtnl_lock();
+ tp->pcierr_recovery = true;
+
/* We probably don't have netdev yet */
if (!netdev || !netif_running(netdev))
goto done;
@@ -18195,6 +18204,7 @@ static void tg3_io_resume(struct pci_dev *pdev)
tg3_phy_start(tp);
done:
+ tp->pcierr_recovery = false;
rtnl_unlock();
}
diff --git a/drivers/net/ethernet/broadcom/tg3.h b/drivers/net/ethernet/broadcom/tg3.h
index 461acca..31c9f82 100644
--- a/drivers/net/ethernet/broadcom/tg3.h
+++ b/drivers/net/ethernet/broadcom/tg3.h
@@ -3407,6 +3407,7 @@ struct tg3 {
struct device *hwmon_dev;
bool link_up;
+ bool pcierr_recovery;
};
/* Accessor macros for chip and asic attributes
--
1.8.5.5
^ permalink raw reply related
* [PATCH] carl9170: tx: Replace rcu_assign_pointer() with RCU_INIT_POINTER()
From: Andreea-Cristina Bernat @ 2014-08-27 13:27 UTC (permalink / raw)
To: chunkeey, linville, linux-wireless, netdev, linux-kernel; +Cc: paulmck
According to RCU_INIT_POINTER()'s block comment 3.a, it can be used if
"3. The referenced data structure has already been exposed to readers either
at compile time or via rcu_assign_pointer() -and-
a. You have not made -any- reader-visible changes to this structure since
then".
This case fulfills the conditions above because between the rcu_dereference()
call (cvif = rcu_dereference(ar->beacon_iter);) and the rcu_assign_pointer()
call there is no update of the "cvif" variable.
Therefore, this patch makes the replacement.
The following Coccinelle semantic patch was used:
@@
identifier v;
@@
v = rcu_dereference(...);
... when != rcu_dereference(...);
when != v = ...;
when != (<+...v...+>)++;
when != \(memcpy\|memset\)(...);
(
- rcu_assign_pointer
+ RCU_INIT_POINTER
(..., v);
|
if(...) {
... when != v = ...;
- rcu_assign_pointer
+ RCU_INIT_POINTER
(..., v);
... when any
}
)
Because there are cases where between a “rcu_dereference()” call and a
“rcu_assign_pointer()” call might be updates of the value that interests us,
the Coccinelle semantic patch ignores them and replaces with
"RCU_INIT_POINTER()" only when the update is not happening.
Signed-off-by: Andreea-Cristina Bernat <bernat.ada@gmail.com>
---
drivers/net/wireless/ath/carl9170/tx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/carl9170/tx.c b/drivers/net/wireless/ath/carl9170/tx.c
index 4cadfd4..ae86a600 100644
--- a/drivers/net/wireless/ath/carl9170/tx.c
+++ b/drivers/net/wireless/ath/carl9170/tx.c
@@ -1557,7 +1557,7 @@ static struct carl9170_vif_info *carl9170_pick_beaconing_vif(struct ar9170 *ar)
}
out:
- rcu_assign_pointer(ar->beacon_iter, cvif);
+ RCU_INIT_POINTER(ar->beacon_iter, cvif);
return cvif;
}
--
1.9.1
^ permalink raw reply related
* Re: [PATCH 0/2] Get rid of ndo_xmit_flush
From: Eric Dumazet @ 2014-08-27 13:23 UTC (permalink / raw)
To: Hannes Frederic Sowa
Cc: David Miller, netdev, therbert, jhs, edumazet, jeffrey.t.kirsher,
rusty, dborkman, brouer
In-Reply-To: <1409142672.26515.24.camel@localhost>
On Wed, 2014-08-27 at 14:31 +0200, Hannes Frederic Sowa wrote:
> One thing one should keep in mind is, that there must be a skb available
> to trigger the flush, maybe this will hurt us one day.
>
> Thinking more about it should we go with a coccinelle script and
> replace/extend ndo_start_xmit with an additional argument?
This will be a pain for backports and things like that.
skb->xmit_more is a bit annoying, because it consumes one bit in all
skbs, while it could be one byte per cpu as ndo_start_xmit() is called
while BH are disabled.
It also forces a cache line dirtying, that will hurt qdisc like HTB
where skbs can be cooked/enqueued by remote cpus.
Also, most drivers will never benefit from this new infra.
Mellanox mlx4 uses the Blue Frame trick to avoid the iowrite() cost.
I am afraid Jesper tests are not complete to truly have a picture of the
extra costs, because he made sure no false sharing was possible (A
single cpu does everything and keeps skb in its cache)
^ permalink raw reply
* Re: [PATCH 0/4] net: stmmac: Enable Intel Quark SoC X1000 Ethernet support
From: Giuseppe CAVALLARO @ 2014-08-27 12:52 UTC (permalink / raw)
To: Kweh Hock Leong, David S. Miller; +Cc: netdev, LKML, Ong Boon Leong, Rayagond K
In-Reply-To: <cover.1409123378.git.hock.leong.kweh@intel.com>
On 8/27/2014 12:32 PM, Kweh Hock Leong wrote:
> From: "Kweh, Hock Leong" <hock.leong.kweh@intel.com>
>
> Hi,
>
> Intel Quark X1000 SoC has 2 Ethernet controllers integrated on chip and they are
> PCI devices. We adopted the stmmac_pci driver and added on code to support Intel
> Quark SoC X1000 by creating the patchset below. The patchset has been built and
> tested on Galileo board and found to be working as expected.
>
> We believe that the changes are transparent to other non Intel Quark platform.
> Please help to review the code change and feedback if there is any concern.
hello and thx for these patches that at first glance look ok to me.
Just some minor remark, in the stmmac I try to align the function
parameters with the open parenthesis (devm_kzalloc in your case in not
aligned).
Added on copy also Rayagond he tested PCI. I cannot do any test because
I have no PCI cards.
peppe
>
> Thank you very much.
>
> Kweh, Hock Leong (4):
> net: stmmac: enhance to support multiple device instances
> net: stmmac: better code manageability with platform data struct
> net: stmmac: add support for Intel Quark X1000
> net: stmmac: add MSI support for Intel Quark X1000
>
> drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 195 +++++++++++++++++++---
> 1 file changed, 172 insertions(+), 23 deletions(-)
>
^ permalink raw reply
* Re: [PATCH 0/2] Get rid of ndo_xmit_flush
From: Hannes Frederic Sowa @ 2014-08-27 12:31 UTC (permalink / raw)
To: David Miller
Cc: netdev, therbert, jhs, edumazet, jeffrey.t.kirsher, rusty,
dborkman, brouer
In-Reply-To: <20140825.163458.1117073971092495452.davem@davemloft.net>
On Mo, 2014-08-25 at 16:34 -0700, David Miller wrote:
> Given Jesper's performance numbers, it's not the way to go.
>
> Instead, go with a signalling scheme via new boolean skb->xmit_more.
>
> This has several advantages:
>
> 1) Nearly trivial driver support, just protect the tail pointer
> update with the skb->xmit_more check.
One thing one should keep in mind is, that there must be a skb available
to trigger the flush, maybe this will hurt us one day.
Thinking more about it should we go with a coccinelle script and
replace/extend ndo_start_xmit with an additional argument?
We can also add a new function pointer and call that instead of
ndo_start_xmit. I think only the callq *%rax hurts performance.
Bye,
Hannes
^ permalink raw reply
* Re: [PATCH 0/2] Get rid of ndo_xmit_flush
From: Jesper Dangaard Brouer @ 2014-08-27 12:19 UTC (permalink / raw)
To: David Miller
Cc: netdev, therbert, jhs, hannes, edumazet, jeffrey.t.kirsher, rusty,
dborkman, brouer
In-Reply-To: <20140825.163458.1117073971092495452.davem@davemloft.net>
On Mon, 25 Aug 2014 16:34:58 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:
> Given Jesper's performance numbers, it's not the way to go.
>
> Instead, go with a signalling scheme via new boolean skb->xmit_more.
>
> This has several advantages:
>
> 1) Nearly trivial driver support, just protect the tail pointer
> update with the skb->xmit_more check.
>
> 2) No extra indirect calls in the non-deferral cases.
Even-though it is obvious that this new API skb->xmit_more will not
hurt performance, especially given skb->xmit_more is always 0 in this
kernel, I've still run my pktgen performance tests.
Compared to baseline[1]: (averaged 5609929 pps) (details below signature)
* (1/5609929*10^9)-(1/5603728*10^9) = -0.197ns
As expected, this API does not hurt performance (as -0.197ns is below
our accuracy levels).
[1] http://thread.gmane.org/gmane.linux.network/327254/focus=327838
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Sr. Network Kernel Developer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
Results: on branch bulking02
----------------------------
Kernel with skb->xmit_more API.
Kernel at:
* commit a3d1214688d ("neigh: document gc_thresh2")
With no HT:
* ethtool -C eth5 rx-usecs 30
* tuned-adm profile latency-performance
Results (pktgen):
* instant rx:1 tx:5604056 pps n:250 average: rx:1 tx:5604013 pps
(instant variation TX 0.001 ns (min:-0.114 max:0.104) RX 0.000 ns)
* instant rx:1 tx:5603388 pps n:87 average: rx:1 tx:5603872 pps
(instant variation TX -0.015 ns (min:-0.031 max:0.060) RX 0.000 ns)
* instant rx:1 tx:5604332 pps n:429 average: rx:1 tx:5603300 pps
(instant variation TX 0.033 ns (min:-0.094 max:0.881) RX 0.000 ns)
* Average: (5604013+5603872+5603300)/3 = 5603728
Compared to baseline: (averaged 5609929 pps)
* (1/5609929*10^9)-(1/5603728*10^9) = -0.197ns
^ permalink raw reply
* Re: [net-next v3 1/3] udp: Expand UDP tunnel common APIs
From: Eric Dumazet @ 2014-08-27 11:45 UTC (permalink / raw)
To: Andy Zhou; +Cc: David Miller, netdev@vger.kernel.org
In-Reply-To: <CACzMAJ+naPV=UjnVBhTEnj8iJQHEpKk78g=AkDR9xnXhOo9xbQ@mail.gmail.com>
On Tue, 2014-08-26 at 22:01 -0700, Andy Zhou wrote:
> Which RCU rule are you referring to?
The most elementary ones, like observing rcu grace period before
freeing ?
udp_tunnel_sock_release() is obviously wrong, or needs an appropriate
documentation.
Please carefully read Documentation/RCU/checklist.txt and tell us why
you believe your code is correct, either in the changelog or using
comments.
^ permalink raw reply
* Re: [RFC PATCH net-next 1/3] ixgbe: support netdev_ops->ndo_xmit_flush()
From: Jesper Dangaard Brouer @ 2014-08-27 11:34 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Daniel Borkmann, davem, netdev, Daniel Borkmann,
Hannes Frederic Sowa, Florian Westphal
In-Reply-To: <20140825140721.162a6c91@redhat.com>
On Mon, 25 Aug 2014 14:07:21 +0200
Jesper Dangaard Brouer <brouer@redhat.com> wrote:
> On Sun, 24 Aug 2014 15:42:16 +0200
> Daniel Borkmann <dborkman@redhat.com> wrote:
>
> > This implements the deferred tail pointer flush API for the ixgbe
> > driver. Similar version also proposed longer time ago by Alexander Duyck.
>
> I've run some benchmarks with this patch only, which actually shows a
> performance regression.
>
[...]
>
> Still a small regression: -14187 pps
> * In nanosec: (1/1562539*10^9)-(1/1548352*10^9) = -5.86 ns
>
> I was not expecting this "slowdown", with this rather simple use of the
> new ndo_xmit_flush API. Can anyone explain why this is happening?
I've re-run this experiment with more accuracy, e.g. C-state tuning, no
Hyper-Threading, and using pktgen. See desc in thread subj: "Get rid of
ndo_xmit_flush"[1].
DaveM was right in reverting this API, according to my new more
accurate measurements, the conclusion is the same, this API hurts performance.
Compared to baseline, with this patch (except not using mmiowb()):
* (1/5609929*10^9)-(1/5388719*10^9) = -7.32 ns
Details below signature.
[1] http://thread.gmane.org/gmane.linux.network/327502/focus=327803
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Sr. Network Kernel Developer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
Base setup
==========
BIOS: Disabled HT (Hyper-Threading)
Setup commands:
sudo killall irqbalance
base_device_setup.sh eth4 # calls set_irq_affinity
base_device_setup.sh eth5
netfilter_unload_modules.sh
sudo ethtool -C eth5 rx-usecs 30
sudo tuned-adm profile latency-performance
pktgen cmdline:
./example03.sh -i eth5 -d 192.168.21.4 -m 00:12:c0:80:1d:54
(SKB_CLONE="100000" and no UDP port random)
Vanilla kernel for baselining, just **before**:
* commit 4798248e4e02 ("net: Add ops->ndo_xmit_flush()").
Thus at:
* commit 4c83acbc565d53 ("ipv6: White-space cleansing : gaps between function and symbol export").
With no HT:
* ethtool -C eth5 rx-usecs 30
* tuned-adm profile latency-performance
Results (pktgen):
* instant rx:2 tx:5620736 pps n:120 average: rx:1 tx:5618140 pps
(instant variation TX 0.082 ns (min:-0.088 max:0.147) RX 0.000 ns)
* instant rx:1 tx:5622300 pps n:250 average: rx:1 tx:5619732 pps
(instant variation TX 0.081 ns (min:-0.858 max:0.098) RX 0.000 ns)
* accuracy: (1/5618140*10^9)-(1/5619732*10^9) = 0.05 ns
* instant rx:1 tx:5618692 pps n:120 average: rx:1 tx:5617469 pps
(instant variation TX 0.039 ns (min:-0.043 max:0.045) RX 0.000 ns)
* accuracy: (1/5619732*10^9)-(1/5617469*10^9) = -0.072 ns
* (reboot same kernel)
* Some hickup:
* instant rx:1 tx:5610140 pps n:190 average: rx:1 tx:5587229 pps
(instant variation TX 0.731 ns (min:-2.612 max:2.627) RX 0.000 ns)
* accuracy: (1/5587229*10^9)-(1/5617469*10^9) = 0.963 ns
* accuracy: (1/5587229*10^9)-(1/5619732*10^9) = 1.035 ns
* instant rx:1 tx:5607568 pps n:120 average: rx:1 tx:5606006 pps
(instant variation TX 0.050 ns (min:-0.855 max:0.066) RX 0.000 ns)
* instant rx:1 tx:5608168 pps n:120 average: rx:1 tx:5611001 pps
(instant variation TX -0.090 ns (min:-0.156 max:0.100) RX 0.000 ns)
* Average: (5618140+5619732+5617469+5587229+5606006+5611001)/6 = 5609929 pps
Results: on branch 'ndo_xmit_flush'
-----------------------------------
Kernel at:
* commit fe88e6dd8b9 ("Merge branch 'ndo_xmit_flush'")
Sending out ixgbe, which in this kernel does not have the defined the
ndo_xmit_flush function.
With no HT:
* ethtool -C eth5 rx-usecs 30
* tuned-adm profile latency-performance
Results (pktgen):
* instant rx:1 tx:5600404 pps n:161 average: rx:1 tx:5600257 pps
(instant variation TX 0.005 ns (min:-0.047 max:0.050) RX 0.000 ns)
* instant rx:1 tx:5594840 pps n:120 average: rx:1 tx:5595316 pps
(instant variation TX -0.015 ns (min:-0.028 max:0.025) RX 0.000 ns)
* instant rx:1 tx:5599644 pps n:140 average: rx:1 tx:5599155 pps
(instant variation TX 0.016 ns (min:-0.074 max:0.059) RX 0.000 ns)
* instant rx:1 tx:5601296 pps n:75 average: rx:1 tx:5599074 pps
(instant variation TX 0.071 ns (min:-0.051 max:0.087) RX 0.000 ns)
* Averaged: (5600257+5595316+5599155+5599074)/4 = 5598450 pps
Compared to baseline: (averaged 5609929 pps)
* (1/5609929*10^9)-(1/5598450*10^9) = -0.365ns
Conclusion: When ndo_xmit_flush is not active in driver, performance
is the same, as 0.365ns difference is below our accuracy level.
Results: on branch bulking01
----------------------------
Kernel at:
* commit fe88e6dd8b9 ("Merge branch 'ndo_xmit_flush'")
* Plus ixgbe support netdev_ops->ndo_xmit_flush()
With no HT:
* ethtool -C eth5 rx-usecs 30
* tuned-adm profile latency-performance
Results (pktgen):
* instant rx:1 tx:5387528 pps n:170 average: rx:1 tx:5387842 pps
(instant variation TX -0.011 ns (min:-0.193 max:0.125) RX 0.000 ns)
* instant rx:1 tx:5387588 pps n:212 average: rx:1 tx:5387930 pps
(instant variation TX -0.012 ns (min:-0.852 max:0.177) RX 0.000 ns)
* instant rx:1 tx:5391172 pps n:70 average: rx:1 tx:5389684 pps
(instant variation TX 0.051 ns (min:-0.097 max:0.087) RX 0.000 ns)
* instant rx:1 tx:5388444 pps n:150 average: rx:1 tx:5389421 pps
(instant variation TX -0.034 ns (min:-1.014 max:0.092) RX 0.000 ns
* Average: (5387842+5387930+5389684+5389421)/4 = 5388719
Compared to baseline: (averaged 5609929 pps)
* (1/5609929*10^9)-(1/5388719*10^9) = -7.32 ns
Conclusion: When ndo_xmit_flush is ACTIVE in the driver, then this new
API of calling ndo_xmit_flush(), hurts performance.
^ permalink raw reply
* Re: [RFC] net: ipv4: drop unicast encapsulated in L2 multicast
From: Johannes Berg @ 2014-08-27 11:29 UTC (permalink / raw)
To: Julian Anastasov
Cc: David Miller, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <alpine.LFD.2.11.1408271255230.2348-c1lBKlETG9EWAawoAK+ZAw@public.gmane.org>
On Wed, 2014-08-27 at 13:23 +0300, Julian Anastasov wrote:
> CLUSTERIP works in LOCAL_IN. My preference is to
> add checks in every protocol where it is missing but if
> you prefer a global check, ip_local_deliver_finish() is
> a good place: CLUSTERIP already changed pkt_type to
> PACKET_HOST. For example:
>
> if (!(skb_rtable(skb)->rt_flags &
> (RTCF_BROADCAST | RTCF_MULTICAST)) &&
> (skb->pkt_type == PACKET_BROADCAST ||
> skb->pkt_type == PACKET_MULTICAST)) {
> kfree_skb(skb);
> return;
> }
>
> By this way we protect the local stack globally.
I suppose that'd work then?
> BTW, what kind of packets (protocol) we want to drop? UDP?
All IP protocols, this comes either from the IPv4 RFC (1122) or from the
wireless issue which affects all protocols.
> As for ip_forward(), there is already check for
> PACKET_HOST.
>
> Not sure, may be a MIB counter for such drops
> would be useful.
Yeah, maybe, not sure.
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] net: rds: Don't allocate rds_sock on stack
From: Mark Brown @ 2014-08-27 10:46 UTC (permalink / raw)
To: David Miller; +Cc: chien.yen, rds-devel, netdev, linaro-kernel
In-Reply-To: <20140826.082906.614050508596912545.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 889 bytes --]
On Tue, Aug 26, 2014 at 08:29:06AM -0700, David Miller wrote:
> From: Mark Brown <broonie@kernel.org>
> > I agree that the existing code looks like it could be improved even more
> > but please bear in mind that I'm just looking for a clean build (we've
> > got less than 20 warnings in allmodconfig including staging at the
> > minute) rather than actively working on this code in particular - I've
> > no ability to do more than build testing here.
> I understand that, but please fix this bug properly.
Please set the expectation among the networking developers that their
code should compile cleanly on all architectures; currently the
networking code (mostly drivers rather than the core) is the single
biggest source of warnings outside of staging and if we are requring
things like this then that presents a substantial barrier to others
contributing to addressing the warnings.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH RFC] lib/rhashtable: allow users to set the minimum shifts of shrinking
From: Thomas Graf @ 2014-08-27 10:34 UTC (permalink / raw)
To: Ying Xue; +Cc: davem, eric.dumazet, netdev
In-Reply-To: <1409129851-11630-1-git-send-email-ying.xue@windriver.com>
On 08/27/14 at 04:57pm, Ying Xue wrote:
> diff --git a/lib/rhashtable.c b/lib/rhashtable.c
> index a2c7881..1466e2d 100644
> --- a/lib/rhashtable.c
> +++ b/lib/rhashtable.c
> @@ -293,12 +293,15 @@ EXPORT_SYMBOL_GPL(rhashtable_expand);
> int rhashtable_shrink(struct rhashtable *ht, gfp_t flags)
> {
> struct bucket_table *ntbl, *tbl = rht_dereference(ht->tbl, ht);
> + size_t min_shift = ilog2(HASH_MIN_SIZE);
> struct rhash_head __rcu **pprev;
> unsigned int i;
>
> ASSERT_RHT_MUTEX(ht);
>
> - if (tbl->size <= HASH_MIN_SIZE)
> + if (ht->p.min_shift)
> + min_shift = max(ht->p.min_shift, min_shift);
> + if (ht->shift <= min_shift)
> return 0;
I like it. Can you translate HASH_MIN_SIZE to .minshift in
rhashtable_init()? That way we only have to deal with .min_shift in
rhashtable_shrink().
Note that shrinking can also be disabled by not providing a
.shrink_decision function in rhashtable_params if the shrinking is
too expensive for your case.
> -static size_t rounded_hashtable_size(unsigned int nelem)
> +static size_t rounded_hashtable_size(struct rhashtable_params *params)
> {
> - return max(roundup_pow_of_two(nelem * 4 / 3), HASH_MIN_SIZE);
> + size_t size = HASH_MIN_SIZE;
> +
> + if (params->min_shift)
> + size = max((1UL << params->min_shift), HASH_MIN_SIZE);
> +
> + return max(roundup_pow_of_two(params->nelem_hint * 4 / 3), size);
> }
Same here. If you merge the provided .min_shift with HASH_MIN_SIZE
in rhashtable_init() before calculating the size, the above logic
can be simplified a lot.
^ permalink raw reply
* [PATCH 3/4] net: stmmac: add support for Intel Quark X1000
From: Kweh Hock Leong @ 2014-08-27 10:32 UTC (permalink / raw)
To: David S. Miller, Giuseppe Cavallaro
Cc: netdev, LKML, Ong Boon Leong, Kweh Hock Leong
In-Reply-To: <cover.1409123378.git.hock.leong.kweh@intel.com>
From: "Kweh, Hock Leong" <hock.leong.kweh@intel.com>
The Intel Quark SoC X1000 provides two 10/100 Mbps Ethernet MAC
controllers which may or may not be connected to PHY on board.
This MAC controller only supports RMII PHY.
Besides adding Quark PCI ID to this driver, this patch introduces
run-time board detection through DMI and MAC-PHY configuration
function used by stmmac_default_data() during initialization.
It fills up the phy_address to -1 for Galileo and Galileo Gen2
boards to indicate that the 2nd Ethernet MAC controller is not
connected to any PHY.
The implementation takes into consideration for future expansion in
Quark series boards that may have different PHY address that is
linked to its MAC controllers.
This piece of work is derived from Bryan O'Donoghue's initial work for
Quark X1000 enabling.
Signed-off-by: Kweh, Hock Leong <hock.leong.kweh@intel.com>
Reviewed-by: Ong, Boon Leong <boon.leong.ong@intel.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 86 ++++++++++++++++++++--
1 file changed, 81 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
index 40290da..81e48f4 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
@@ -24,16 +24,19 @@
*******************************************************************************/
#include <linux/pci.h>
+#include <linux/dmi.h>
#include "stmmac.h"
static int instance_id = 1;
+static void quark_run_time_config(int chip_id, struct pci_dev *pdev);
enum chip {
CHIP_STMICRO = 0,
+ CHIP_QUARK_X1000,
};
-/* A struct for platform specific information which will be
- * used in stmmac_default_data function for initialization
+/* A struct for platform specific information which is used
+ * in stmmac_default_data function for initialization
*/
struct platform_data {
int phy_addr;
@@ -46,7 +49,9 @@ struct platform_data {
int (*phy_reset)(void *priv);
unsigned int phy_mask;
int pbl;
+ int fixed_burst;
int burst_len;
+ void (*rt_config)(int chip_id, struct pci_dev *pdev);
};
static struct platform_data platform_info[] = {
@@ -61,15 +66,76 @@ static struct platform_data platform_info[] = {
.phy_reset = NULL,
.phy_mask = 0,
.pbl = 32,
+ .fixed_burst = 0,
.burst_len = DMA_AXI_BLEN_256,
+ .rt_config = NULL,
},
+ [CHIP_QUARK_X1000] = {
+ .phy_addr = 1,
+ .interface = PHY_INTERFACE_MODE_RMII,
+ .clk_csr = 2,
+ .has_gmac = 1,
+ .force_sf_dma_mode = 1,
+ .multicast_filter_bins = HASH_TABLE_SIZE,
+ .unicast_filter_entries = 1,
+ .phy_reset = NULL,
+ .phy_mask = 0,
+ .pbl = 16,
+ .fixed_burst = 1,
+ .burst_len = DMA_AXI_BLEN_256,
+ .rt_config = &quark_run_time_config,
+ },
+};
+
+/* This struct is used to associate PCI Function ID of MAC controller
+ * on a board, discovered via DMI, with phy_address. It is also used
+ * to describe if that MAC controller is connected with PHY.
+ */
+struct intel_quark_platform {
+ int pci_func_num;
+ const char *board_name;
+ int phy_address;
};
-static void stmmac_default_data(struct plat_stmmacenet_data *plat,
- int chip_id)
+static struct intel_quark_platform quark_x1000_phy_info[] = {
+ {
+ .pci_func_num = 7,
+ .board_name = "Galileo",
+ /* Galileo ethernet port 2 does not connect to any PHY */
+ .phy_address = -1,
+ },
+ {
+ .pci_func_num = 7,
+ .board_name = "GalileoGen2",
+ /* Galileo Gen2 ethernet port 2 does not connect to any PHY */
+ .phy_address = -1,
+ },
+};
+
+static void quark_run_time_config(int chip_id, struct pci_dev *pdev)
+{
+ const char *board_name = dmi_get_system_info(DMI_BOARD_NAME);
+ int i;
+ int func_num = PCI_FUNC(pdev->devfn);
+
+ if (!board_name)
+ return;
+
+ for (i = 0; i < ARRAY_SIZE(quark_x1000_phy_info); i++) {
+ if ((!strcmp(quark_x1000_phy_info[i].board_name, board_name)) &&
+ quark_x1000_phy_info[i].pci_func_num == func_num)
+ platform_info[chip_id].phy_addr =
+ quark_x1000_phy_info[i].phy_address;
+ }
+}
+
+static int stmmac_default_data(struct plat_stmmacenet_data *plat,
+ int chip_id, struct pci_dev *pdev)
{
struct platform_data *chip_plat_dat = &platform_info[chip_id];
+ if (chip_plat_dat->rt_config)
+ chip_plat_dat->rt_config(chip_id, pdev);
plat->bus_id = instance_id++;
plat->phy_addr = chip_plat_dat->phy_addr;
plat->interface = chip_plat_dat->interface;
@@ -84,7 +150,13 @@ static void stmmac_default_data(struct plat_stmmacenet_data *plat,
plat->mdio_bus_data->phy_mask = chip_plat_dat->phy_mask;
plat->dma_cfg->pbl = chip_plat_dat->pbl;
+ plat->dma_cfg->fixed_burst = chip_plat_dat->fixed_burst;
plat->dma_cfg->burst_len = chip_plat_dat->burst_len;
+
+ /* Refuse to load the driver and register net device
+ * if MAC controller does not connect to any PHY interface
+ */
+ return (plat->phy_addr != -1) ? 0 : -ENODEV;
}
/**
@@ -158,7 +230,9 @@ static int stmmac_pci_probe(struct pci_dev *pdev,
goto err_out;
}
- stmmac_default_data(plat_dat, id->driver_data);
+ ret = stmmac_default_data(plat_dat, id->driver_data, pdev);
+ if (ret)
+ goto err_out;
priv = stmmac_dvr_probe(&pdev->dev, plat_dat, addr);
if (IS_ERR(priv)) {
@@ -230,11 +304,13 @@ static int stmmac_pci_resume(struct pci_dev *pdev)
#define STMMAC_VENDOR_ID 0x700
#define STMMAC_DEVICE_ID 0x1108
+#define STMMAC_QUARK_X1000_ID 0x0937
static const struct pci_device_id stmmac_id_table[] = {
{PCI_DEVICE(STMMAC_VENDOR_ID, STMMAC_DEVICE_ID), PCI_ANY_ID,
PCI_ANY_ID, CHIP_STMICRO},
{PCI_VDEVICE(STMICRO, PCI_DEVICE_ID_STMICRO_MAC), CHIP_STMICRO},
+ {PCI_VDEVICE(INTEL, STMMAC_QUARK_X1000_ID), CHIP_QUARK_X1000},
{}
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH 4/4] net: stmmac: add MSI support for Intel Quark X1000
From: Kweh Hock Leong @ 2014-08-27 10:32 UTC (permalink / raw)
To: David S. Miller, Giuseppe Cavallaro
Cc: netdev, LKML, Ong Boon Leong, Kweh Hock Leong
In-Reply-To: <cover.1409123378.git.hock.leong.kweh@intel.com>
From: "Kweh, Hock Leong" <hock.leong.kweh@intel.com>
In Intel Quark SoC X1000, both of the Ethernet controllers support
MSI interrupt handling. This patch enables them to use MSI interrupt
servicing in stmmac_pci for Intel Quark X1000.
Signed-off-by: Kweh, Hock Leong <hock.leong.kweh@intel.com>
Reviewed-by: Ong, Boon Leong <boon.leong.ong@intel.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 19 +++++++++++++++----
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
index 81e48f4..36e36d5 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
@@ -52,6 +52,7 @@ struct platform_data {
int fixed_burst;
int burst_len;
void (*rt_config)(int chip_id, struct pci_dev *pdev);
+ int support_msi;
};
static struct platform_data platform_info[] = {
@@ -69,6 +70,7 @@ static struct platform_data platform_info[] = {
.fixed_burst = 0,
.burst_len = DMA_AXI_BLEN_256,
.rt_config = NULL,
+ .support_msi = 0,
},
[CHIP_QUARK_X1000] = {
.phy_addr = 1,
@@ -84,6 +86,7 @@ static struct platform_data platform_info[] = {
.fixed_burst = 1,
.burst_len = DMA_AXI_BLEN_256,
.rt_config = &quark_run_time_config,
+ .support_msi = 1,
},
};
@@ -211,7 +214,7 @@ static int stmmac_pci_probe(struct pci_dev *pdev,
plat_dat = devm_kzalloc(&pdev->dev, sizeof(*plat_dat), GFP_KERNEL);
if (!plat_dat) {
ret = -ENOMEM;
- goto err_out;
+ goto err_out_alloc_failed;
}
plat_dat->mdio_bus_data = devm_kzalloc(&pdev->dev,
@@ -219,7 +222,7 @@ static int stmmac_pci_probe(struct pci_dev *pdev,
GFP_KERNEL);
if (!plat_dat->mdio_bus_data) {
ret = -ENOMEM;
- goto err_out;
+ goto err_out_alloc_failed;
}
plat_dat->dma_cfg = devm_kzalloc(&pdev->dev,
@@ -227,12 +230,15 @@ static int stmmac_pci_probe(struct pci_dev *pdev,
GFP_KERNEL);
if (!plat_dat->dma_cfg) {
ret = -ENOMEM;
- goto err_out;
+ goto err_out_alloc_failed;
}
ret = stmmac_default_data(plat_dat, id->driver_data, pdev);
if (ret)
- goto err_out;
+ goto err_out_alloc_failed;
+
+ if (platform_info[id->driver_data].support_msi)
+ pci_enable_msi(pdev);
priv = stmmac_dvr_probe(&pdev->dev, plat_dat, addr);
if (IS_ERR(priv)) {
@@ -250,6 +256,9 @@ static int stmmac_pci_probe(struct pci_dev *pdev,
return 0;
err_out:
+ if (platform_info[id->driver_data].support_msi)
+ pci_disable_msi(pdev);
+err_out_alloc_failed:
pci_clear_master(pdev);
err_out_map_failed:
pci_release_regions(pdev);
@@ -273,6 +282,8 @@ static void stmmac_pci_remove(struct pci_dev *pdev)
stmmac_dvr_remove(ndev);
+ if (pci_dev_msi_enabled(pdev))
+ pci_disable_msi(pdev);
pci_iounmap(pdev, priv->ioaddr);
pci_release_regions(pdev);
pci_disable_device(pdev);
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/4] net: stmmac: better code manageability with platform data struct
From: Kweh Hock Leong @ 2014-08-27 10:32 UTC (permalink / raw)
To: David S. Miller, Giuseppe Cavallaro
Cc: netdev, LKML, Ong Boon Leong, Kweh Hock Leong
In-Reply-To: <cover.1409123378.git.hock.leong.kweh@intel.com>
From: "Kweh, Hock Leong" <hock.leong.kweh@intel.com>
Introduce additional struct to hold platform info for pci device. It
is used to store features that are supported by specific chip vendor.
This code change helps to expand further to support more platform
vendors and this implementation promotes better code manageability
and keep code base clean. In addition, this patch adds mcast & ucast
filter configuration in pci driver.
Signed-off-by: Kweh, Hock Leong <hock.leong.kweh@intel.com>
Reviewed-by: Ong, Boon Leong <boon.leong.ong@intel.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 76 +++++++++++++++++-----
1 file changed, 60 insertions(+), 16 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
index 9d98935..40290da 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
@@ -28,20 +28,63 @@
static int instance_id = 1;
-static void stmmac_default_data(struct plat_stmmacenet_data *plat_dat)
+enum chip {
+ CHIP_STMICRO = 0,
+};
+
+/* A struct for platform specific information which will be
+ * used in stmmac_default_data function for initialization
+ */
+struct platform_data {
+ int phy_addr;
+ int interface;
+ int clk_csr;
+ int has_gmac;
+ int force_sf_dma_mode;
+ int multicast_filter_bins;
+ int unicast_filter_entries;
+ int (*phy_reset)(void *priv);
+ unsigned int phy_mask;
+ int pbl;
+ int burst_len;
+};
+
+static struct platform_data platform_info[] = {
+ [CHIP_STMICRO] = {
+ .phy_addr = 0,
+ .interface = PHY_INTERFACE_MODE_GMII,
+ .clk_csr = 2,
+ .has_gmac = 1,
+ .force_sf_dma_mode = 1,
+ .multicast_filter_bins = HASH_TABLE_SIZE,
+ .unicast_filter_entries = 1,
+ .phy_reset = NULL,
+ .phy_mask = 0,
+ .pbl = 32,
+ .burst_len = DMA_AXI_BLEN_256,
+ },
+};
+
+static void stmmac_default_data(struct plat_stmmacenet_data *plat,
+ int chip_id)
{
- plat_dat->bus_id = instance_id++;
- plat_dat->phy_addr = 0;
- plat_dat->interface = PHY_INTERFACE_MODE_GMII;
- plat_dat->clk_csr = 2; /* clk_csr_i = 20-35MHz & MDC = clk_csr_i/16 */
- plat_dat->has_gmac = 1;
- plat_dat->force_sf_dma_mode = 1;
-
- plat_dat->mdio_bus_data->phy_reset = NULL;
- plat_dat->mdio_bus_data->phy_mask = 0;
-
- plat_dat->dma_cfg->pbl = 32;
- plat_dat->dma_cfg->burst_len = DMA_AXI_BLEN_256;
+ struct platform_data *chip_plat_dat = &platform_info[chip_id];
+
+ plat->bus_id = instance_id++;
+ plat->phy_addr = chip_plat_dat->phy_addr;
+ plat->interface = chip_plat_dat->interface;
+ /* clk_csr_i = 20-35MHz & MDC = clk_csr_i/16 */
+ plat->clk_csr = chip_plat_dat->clk_csr;
+ plat->has_gmac = chip_plat_dat->has_gmac;
+ plat->force_sf_dma_mode = chip_plat_dat->force_sf_dma_mode;
+ plat->multicast_filter_bins = chip_plat_dat->multicast_filter_bins;
+ plat->unicast_filter_entries = chip_plat_dat->unicast_filter_entries;
+
+ plat->mdio_bus_data->phy_reset = chip_plat_dat->phy_reset;
+ plat->mdio_bus_data->phy_mask = chip_plat_dat->phy_mask;
+
+ plat->dma_cfg->pbl = chip_plat_dat->pbl;
+ plat->dma_cfg->burst_len = chip_plat_dat->burst_len;
}
/**
@@ -115,7 +158,7 @@ static int stmmac_pci_probe(struct pci_dev *pdev,
goto err_out;
}
- stmmac_default_data(plat_dat);
+ stmmac_default_data(plat_dat, id->driver_data);
priv = stmmac_dvr_probe(&pdev->dev, plat_dat, addr);
if (IS_ERR(priv)) {
@@ -189,8 +232,9 @@ static int stmmac_pci_resume(struct pci_dev *pdev)
#define STMMAC_DEVICE_ID 0x1108
static const struct pci_device_id stmmac_id_table[] = {
- {PCI_DEVICE(STMMAC_VENDOR_ID, STMMAC_DEVICE_ID)},
- {PCI_DEVICE(PCI_VENDOR_ID_STMICRO, PCI_DEVICE_ID_STMICRO_MAC)},
+ {PCI_DEVICE(STMMAC_VENDOR_ID, STMMAC_DEVICE_ID), PCI_ANY_ID,
+ PCI_ANY_ID, CHIP_STMICRO},
+ {PCI_VDEVICE(STMICRO, PCI_DEVICE_ID_STMICRO_MAC), CHIP_STMICRO},
{}
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/4] net: stmmac: enhance to support multiple device instances
From: Kweh Hock Leong @ 2014-08-27 10:32 UTC (permalink / raw)
To: David S. Miller, Giuseppe Cavallaro
Cc: netdev, LKML, Ong Boon Leong, Kweh Hock Leong
In-Reply-To: <cover.1409123378.git.hock.leong.kweh@intel.com>
From: "Kweh, Hock Leong" <hock.leong.kweh@intel.com>
The original stmmac_pci code only supports single ethernet controller
instance. This modification allows the driver to support multiple
stmicro ethernet controller instances by converting the static global
variables plat_dat, mdio_data & dma_cfg to dynamic allocation.
This piece of work is derived from Bryan O'Donoghue's initial work for
Quark X1000 enabling.
Signed-off-by: Kweh, Hock Leong <hock.leong.kweh@intel.com>
Reviewed-by: Ong, Boon Leong <boon.leong.ong@intel.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 60 ++++++++++++++--------
1 file changed, 39 insertions(+), 21 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
index 655a23b..9d98935 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
@@ -26,27 +26,22 @@
#include <linux/pci.h>
#include "stmmac.h"
-static struct plat_stmmacenet_data plat_dat;
-static struct stmmac_mdio_bus_data mdio_data;
-static struct stmmac_dma_cfg dma_cfg;
+static int instance_id = 1;
-static void stmmac_default_data(void)
+static void stmmac_default_data(struct plat_stmmacenet_data *plat_dat)
{
- memset(&plat_dat, 0, sizeof(struct plat_stmmacenet_data));
- plat_dat.bus_id = 1;
- plat_dat.phy_addr = 0;
- plat_dat.interface = PHY_INTERFACE_MODE_GMII;
- plat_dat.clk_csr = 2; /* clk_csr_i = 20-35MHz & MDC = clk_csr_i/16 */
- plat_dat.has_gmac = 1;
- plat_dat.force_sf_dma_mode = 1;
-
- mdio_data.phy_reset = NULL;
- mdio_data.phy_mask = 0;
- plat_dat.mdio_bus_data = &mdio_data;
-
- dma_cfg.pbl = 32;
- dma_cfg.burst_len = DMA_AXI_BLEN_256;
- plat_dat.dma_cfg = &dma_cfg;
+ plat_dat->bus_id = instance_id++;
+ plat_dat->phy_addr = 0;
+ plat_dat->interface = PHY_INTERFACE_MODE_GMII;
+ plat_dat->clk_csr = 2; /* clk_csr_i = 20-35MHz & MDC = clk_csr_i/16 */
+ plat_dat->has_gmac = 1;
+ plat_dat->force_sf_dma_mode = 1;
+
+ plat_dat->mdio_bus_data->phy_reset = NULL;
+ plat_dat->mdio_bus_data->phy_mask = 0;
+
+ plat_dat->dma_cfg->pbl = 32;
+ plat_dat->dma_cfg->burst_len = DMA_AXI_BLEN_256;
}
/**
@@ -67,6 +62,7 @@ static int stmmac_pci_probe(struct pci_dev *pdev,
int ret = 0;
void __iomem *addr = NULL;
struct stmmac_priv *priv = NULL;
+ struct plat_stmmacenet_data *plat_dat;
int i;
/* Enable pci device */
@@ -97,9 +93,31 @@ static int stmmac_pci_probe(struct pci_dev *pdev,
}
pci_set_master(pdev);
- stmmac_default_data();
+ plat_dat = devm_kzalloc(&pdev->dev, sizeof(*plat_dat), GFP_KERNEL);
+ if (!plat_dat) {
+ ret = -ENOMEM;
+ goto err_out;
+ }
+
+ plat_dat->mdio_bus_data = devm_kzalloc(&pdev->dev,
+ sizeof(*plat_dat->mdio_bus_data),
+ GFP_KERNEL);
+ if (!plat_dat->mdio_bus_data) {
+ ret = -ENOMEM;
+ goto err_out;
+ }
+
+ plat_dat->dma_cfg = devm_kzalloc(&pdev->dev,
+ sizeof(*plat_dat->dma_cfg),
+ GFP_KERNEL);
+ if (!plat_dat->dma_cfg) {
+ ret = -ENOMEM;
+ goto err_out;
+ }
+
+ stmmac_default_data(plat_dat);
- priv = stmmac_dvr_probe(&(pdev->dev), &plat_dat, addr);
+ priv = stmmac_dvr_probe(&pdev->dev, plat_dat, addr);
if (IS_ERR(priv)) {
pr_err("%s: main driver probe failed", __func__);
ret = PTR_ERR(priv);
--
1.7.9.5
^ permalink raw reply related
* [PATCH 0/4] net: stmmac: Enable Intel Quark SoC X1000 Ethernet support
From: Kweh Hock Leong @ 2014-08-27 10:32 UTC (permalink / raw)
To: David S. Miller, Giuseppe Cavallaro
Cc: netdev, LKML, Ong Boon Leong, Kweh Hock Leong
From: "Kweh, Hock Leong" <hock.leong.kweh@intel.com>
Hi,
Intel Quark X1000 SoC has 2 Ethernet controllers integrated on chip and they are
PCI devices. We adopted the stmmac_pci driver and added on code to support Intel
Quark SoC X1000 by creating the patchset below. The patchset has been built and
tested on Galileo board and found to be working as expected.
We believe that the changes are transparent to other non Intel Quark platform.
Please help to review the code change and feedback if there is any concern.
Thank you very much.
Kweh, Hock Leong (4):
net: stmmac: enhance to support multiple device instances
net: stmmac: better code manageability with platform data struct
net: stmmac: add support for Intel Quark X1000
net: stmmac: add MSI support for Intel Quark X1000
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 195 +++++++++++++++++++---
1 file changed, 172 insertions(+), 23 deletions(-)
--
1.7.9.5
^ permalink raw reply
* Re: [RFC] net: ipv4: drop unicast encapsulated in L2 multicast
From: Julian Anastasov @ 2014-08-27 10:23 UTC (permalink / raw)
To: Johannes Berg
Cc: David Miller, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1409130792.2505.5.camel-8Nb76shvtaUJvtFkdXX2HixXY32XiHfO@public.gmane.org>
Hello,
On Wed, 27 Aug 2014, Johannes Berg wrote:
> On Fri, 2014-08-22 at 10:54 -0700, David Miller wrote:
>
> > > Is this place better, after checking for RTN_BROADCAST?
> > >
> > > /* ARP link-layer broadcasts are acceptable here */
> > > if ((skb->pkt_type == PACKET_BROADCAST ||
> > > skb->pkt_type == PACKET_MULTICAST) &&
> > > skb->protocol == htons(ETH_P_IP))
> > > goto e_inval;
> >
> > Indeed, this would make ARP happier, but that still leaves open the
> > issue of CLUSTERIP.
>
> Unfortunately, I have no idea how to determine that CLUSTERIP is active
> here? Do we need to tag frames, or would a sysctl work?
>
> Or should we go back to the drawing board and not make this change in
> the IP stack at all? But parsing all the IP layer in the wireless stack
> is really quite ugly as well.
CLUSTERIP works in LOCAL_IN. My preference is to
add checks in every protocol where it is missing but if
you prefer a global check, ip_local_deliver_finish() is
a good place: CLUSTERIP already changed pkt_type to
PACKET_HOST. For example:
if (!(skb_rtable(skb)->rt_flags &
(RTCF_BROADCAST | RTCF_MULTICAST)) &&
(skb->pkt_type == PACKET_BROADCAST ||
skb->pkt_type == PACKET_MULTICAST)) {
kfree_skb(skb);
return;
}
By this way we protect the local stack globally.
BTW, what kind of packets (protocol) we want to drop? UDP?
As for ip_forward(), there is already check for
PACKET_HOST.
Not sure, may be a MIB counter for such drops
would be useful.
Regards
--
Julian Anastasov <ja-FgGsKACvmQM@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] mac80211: Replace rcu_dereference() with rcu_access_pointer()
From: Johannes Berg @ 2014-08-27 10:14 UTC (permalink / raw)
To: Andreea-Cristina Bernat
Cc: linville-2XuSBdqkA4R54TAoqtyWWQ, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
paulmck-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8
In-Reply-To: <20140817131801.GA24286@ada>
On Sun, 2014-08-17 at 16:18 +0300, Andreea-Cristina Bernat wrote:
> The "rcu_dereference()" calls are used directly in conditions.
> Since their return values are never dereferenced it is recommended to
> use "rcu_access_pointer()" instead of "rcu_dereference()".
> Therefore, this patch makes the replacements.
Applied, thanks.
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: BCM4313 & brcmsmac & 3.12: only semi-working?
From: Michael Tokarev @ 2014-08-27 10:02 UTC (permalink / raw)
To: Arend van Spriel; +Cc: brcm80211-dev-list, linux-wireless, netdev
In-Reply-To: <53FCFE1A.3060508@broadcom.com>
27.08.2014 01:37, Arend van Spriel wrote:
> On 08/26/14 18:15, Michael Tokarev wrote:
[]
> Well, sorry about that. I did see the other messages fly by and noticed you were using the wl driver so assumed you were fine with that.
That's past already. I had several issues with wl driver,
and current issue is that even the latest (Aug-2014) version
of wl driver doesn't work with current kernel. So I can't
really even compare wl and brcmsmac, -- in kernels < 3.16
brcmsmac does not work, but wl can't be compiled for 3.16,
and using different kernels for comparison is a bit wrong
because there may be differences in other areas.
> Admittedly the brcmsmac got very little attention as all our resources were put on brcmfmac.
That happens. :)
[]
> Ok. Let's put frustration aside and make an effort. So could you make a trace using trace-cmd utility. The log can get quite big. The brcmsmac driver needs to be built with CONFIG_BRCM_TRACING enabled. Please execute the following commands (assuming you use ubuntu with network-manager):
>
> $ sudo stop network-manager
> $ sudo insmod brcmfmac.ko
> $ sudo trace-cmd record -e brcmsmac:*
>
> In another terminal:
>
> $ sudo start network-manager
>
> The trace-cmd must be stopped using ctrl-c.
Okay. This turned out to be not so simple.
My initial attempt indicated that brcmsmac in 3.16 does
not work at all. This isn't actually true - subsequent
attempts shows that it works. I was ready to conclude
the problem is fixed (after transferring several gigs
of data over wifi, with tracing enabled or disabled,
after fresh boot or after reboot from wl-enabled kernel,
etc - it all worked.
Until I hit the same stall as I described initially, the
same which happened numerous times with kernel 3.12 ($subj).
After several mins of transferring it stalled. But this
time (unlike with 3.12), it continued after about 30 secs.
So, while my initial test of 3.16 indicated the prob is still
here, at the same (or even worse) state, I can't really
reproduce it, at least in a reliable way. There's something
wrong still, but at least current version is significantly
more useful than before (in a hope it wont stall at the
very wrong moment exactly ;).
There's one more difference between brcmsmac and wl -- with
wl, I see significantly better speed, -- it is about 5MB/sec,
while with brcmsmac it jumps between 2.0..4.5MB/sec (with
58..65Mbps connection rate in both cases). Here's a typical
iwconfig output for brcmsmac version:
wlan0 IEEE 802.11bgn ESSID:"mjt"
Mode:Managed Frequency:2.412 GHz Access Point: 64:70:02:29:D9:30
Bit Rate=65 Mb/s Tx-Power=19 dBm
Retry short limit:7 RTS thr:off Fragment thr:off
Power Management:off
Link Quality=58/70 Signal level=-61 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:56355 Invalid misc:472 Missed beacon:0
I'll keep trying/testing various cases, in attempt to
understand what's going on. For now, I can't provide the
requested traces (it wont be very useful, I guess).
BTW, are there other things not implemented in brcmsmac?
I see the module reminds about power management, what
does it mean? Anything else missing?
Thank you!
/mjt
^ 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