* [PATCH net-next v2 4/4] bpf: add __must_check attributes to refcount manipulating helpers
From: Daniel Borkmann @ 2016-11-16 0:04 UTC (permalink / raw)
To: davem
Cc: alexei.starovoitov, bblanco, zhiyisun, ranas, saeedm, netdev,
Daniel Borkmann
In-Reply-To: <cover.1479253024.git.daniel@iogearbox.net>
Helpers like bpf_prog_add(), bpf_prog_inc(), bpf_map_inc() can fail
with an error, so make sure the caller properly checks their return
value and not just ignores it (which could worst-case lead to use
after free).
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
---
include/linux/bpf.h | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index 01c1487..69d0a7f 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -233,14 +233,14 @@ u64 bpf_event_output(struct bpf_map *map, u64 flags, void *meta, u64 meta_size,
struct bpf_prog *bpf_prog_get(u32 ufd);
struct bpf_prog *bpf_prog_get_type(u32 ufd, enum bpf_prog_type type);
-struct bpf_prog *bpf_prog_add(struct bpf_prog *prog, int i);
+struct bpf_prog * __must_check bpf_prog_add(struct bpf_prog *prog, int i);
void bpf_prog_sub(struct bpf_prog *prog, int i);
-struct bpf_prog *bpf_prog_inc(struct bpf_prog *prog);
+struct bpf_prog * __must_check bpf_prog_inc(struct bpf_prog *prog);
void bpf_prog_put(struct bpf_prog *prog);
struct bpf_map *bpf_map_get_with_uref(u32 ufd);
struct bpf_map *__bpf_map_get(struct fd f);
-struct bpf_map *bpf_map_inc(struct bpf_map *map, bool uref);
+struct bpf_map * __must_check bpf_map_inc(struct bpf_map *map, bool uref);
void bpf_map_put_with_uref(struct bpf_map *map);
void bpf_map_put(struct bpf_map *map);
int bpf_map_precharge_memlock(u32 pages);
@@ -299,7 +299,8 @@ static inline struct bpf_prog *bpf_prog_get_type(u32 ufd,
{
return ERR_PTR(-EOPNOTSUPP);
}
-static inline struct bpf_prog *bpf_prog_add(struct bpf_prog *prog, int i)
+static inline struct bpf_prog * __must_check bpf_prog_add(struct bpf_prog *prog,
+ int i)
{
return ERR_PTR(-EOPNOTSUPP);
}
@@ -311,7 +312,8 @@ static inline void bpf_prog_sub(struct bpf_prog *prog, int i)
static inline void bpf_prog_put(struct bpf_prog *prog)
{
}
-static inline struct bpf_prog *bpf_prog_inc(struct bpf_prog *prog)
+
+static inline struct bpf_prog * __must_check bpf_prog_inc(struct bpf_prog *prog)
{
return ERR_PTR(-EOPNOTSUPP);
}
--
1.9.3
^ permalink raw reply related
* [PATCH net-next v2 3/4] bpf, mlx5: drop priv->xdp_prog reference on netdev cleanup
From: Daniel Borkmann @ 2016-11-16 0:04 UTC (permalink / raw)
To: davem
Cc: alexei.starovoitov, bblanco, zhiyisun, ranas, saeedm, netdev,
Daniel Borkmann
In-Reply-To: <cover.1479253024.git.daniel@iogearbox.net>
mlx5e_xdp_set() is currently the only place where we drop reference on the
prog sitting in priv->xdp_prog when it's exchanged by a new one. We also
need to make sure that we eventually release that reference, for example,
in case the netdev is dismantled.
Fixes: 86994156c736 ("net/mlx5e: XDP fast RX drop bpf programs support")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
---
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
index cf26672..60fe54c 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
@@ -3715,6 +3715,9 @@ static void mlx5e_nic_cleanup(struct mlx5e_priv *priv)
if (MLX5_CAP_GEN(mdev, vport_group_manager))
mlx5_eswitch_unregister_vport_rep(esw, 0);
+
+ if (priv->xdp_prog)
+ bpf_prog_put(priv->xdp_prog);
}
static int mlx5e_init_nic_rx(struct mlx5e_priv *priv)
--
1.9.3
^ permalink raw reply related
* [PATCH net-next v2 0/4] Couple of BPF refcount fixes for mlx5
From: Daniel Borkmann @ 2016-11-16 0:04 UTC (permalink / raw)
To: davem
Cc: alexei.starovoitov, bblanco, zhiyisun, ranas, saeedm, netdev,
Daniel Borkmann
Various mlx5 bugs on eBPF refcount handling found during review.
Last patch in series adds a __must_check to BPF helpers to make
sure we won't run into it again w/o compiler complaining first.
v1 -> v2:
- After discussion with Alexei, we agreed upon rebasing the
patches against net-next.
- Since net-next, I've also added the __must_check to enforce
future users to check for errors.
- Fixed up commit message #2.
- Simplify assignment from patch #1 based on Saeed's feedback
on previous set.
Thanks a lot!
Daniel Borkmann (4):
bpf, mlx5: fix mlx5e_create_rq taking reference on prog
bpf, mlx5: fix various refcount issues in mlx5e_xdp_set
bpf, mlx5: drop priv->xdp_prog reference on netdev cleanup
bpf: add __must_check attributes to refcount manipulating helpers
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 41 ++++++++++++++++++-----
include/linux/bpf.h | 12 ++++---
kernel/bpf/syscall.c | 1 +
3 files changed, 40 insertions(+), 14 deletions(-)
--
1.9.3
^ permalink raw reply
* [PATCH net-next v2 1/4] bpf, mlx5: fix mlx5e_create_rq taking reference on prog
From: Daniel Borkmann @ 2016-11-16 0:04 UTC (permalink / raw)
To: davem
Cc: alexei.starovoitov, bblanco, zhiyisun, ranas, saeedm, netdev,
Daniel Borkmann
In-Reply-To: <cover.1479253024.git.daniel@iogearbox.net>
In mlx5e_create_rq(), when creating a new queue, we call bpf_prog_add() but
without checking the return value. bpf_prog_add() can fail since 92117d8443bc
("bpf: fix refcnt overflow"), so we really must check it. Take the reference
right when we assign it to the rq from priv->xdp_prog, and just drop the
reference on error path. Destruction in mlx5e_destroy_rq() looks good, though.
Fixes: 86994156c736 ("net/mlx5e: XDP fast RX drop bpf programs support")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
---
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 13 +++++++++----
kernel/bpf/syscall.c | 1 +
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
index 16a9a10..ab0c336 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
@@ -513,7 +513,13 @@ static int mlx5e_create_rq(struct mlx5e_channel *c,
rq->channel = c;
rq->ix = c->ix;
rq->priv = c->priv;
- rq->xdp_prog = priv->xdp_prog;
+
+ rq->xdp_prog = priv->xdp_prog ? bpf_prog_inc(priv->xdp_prog) : NULL;
+ if (IS_ERR(rq->xdp_prog)) {
+ err = PTR_ERR(rq->xdp_prog);
+ rq->xdp_prog = NULL;
+ goto err_rq_wq_destroy;
+ }
rq->buff.map_dir = DMA_FROM_DEVICE;
if (rq->xdp_prog)
@@ -590,12 +596,11 @@ static int mlx5e_create_rq(struct mlx5e_channel *c,
rq->page_cache.head = 0;
rq->page_cache.tail = 0;
- if (rq->xdp_prog)
- bpf_prog_add(rq->xdp_prog, 1);
-
return 0;
err_rq_wq_destroy:
+ if (rq->xdp_prog)
+ bpf_prog_put(rq->xdp_prog);
mlx5_wq_destroy(&rq->wq_ctrl);
return err;
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index ce1b7de..eb15498 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -696,6 +696,7 @@ struct bpf_prog *bpf_prog_inc(struct bpf_prog *prog)
{
return bpf_prog_add(prog, 1);
}
+EXPORT_SYMBOL_GPL(bpf_prog_inc);
static struct bpf_prog *__bpf_prog_get(u32 ufd, enum bpf_prog_type *type)
{
--
1.9.3
^ permalink raw reply related
* [PATCH net-next v2 2/4] bpf, mlx5: fix various refcount issues in mlx5e_xdp_set
From: Daniel Borkmann @ 2016-11-16 0:04 UTC (permalink / raw)
To: davem
Cc: alexei.starovoitov, bblanco, zhiyisun, ranas, saeedm, netdev,
Daniel Borkmann
In-Reply-To: <cover.1479253024.git.daniel@iogearbox.net>
There are multiple issues in mlx5e_xdp_set():
1) The batched bpf_prog_add() is currently not checked for errors! When
doing so, it should be done at an earlier point in time to makes sure
that we cannot fail anymore at the time we want to set the program for
each channel. This only means that we have to undo the bpf_prog_add()
in case we return due to required reset.
2) When swapping the priv->xdp_prog, then no extra reference count must be
taken since we got that from call path via dev_change_xdp_fd() already.
Otherwise, we'd never be able to free the program. Also, bpf_prog_add()
without checking the return code could fail.
Fixes: 86994156c736 ("net/mlx5e: XDP fast RX drop bpf programs support")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
---
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 25 ++++++++++++++++++-----
1 file changed, 20 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
index ab0c336..cf26672 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
@@ -3142,6 +3142,17 @@ static int mlx5e_xdp_set(struct net_device *netdev, struct bpf_prog *prog)
goto unlock;
}
+ if (prog) {
+ /* num_channels is invariant here, so we can take the
+ * batched reference right upfront.
+ */
+ prog = bpf_prog_add(prog, priv->params.num_channels);
+ if (IS_ERR(prog)) {
+ err = PTR_ERR(prog);
+ goto unlock;
+ }
+ }
+
was_opened = test_bit(MLX5E_STATE_OPENED, &priv->state);
/* no need for full reset when exchanging programs */
reset = (!priv->xdp_prog || !prog);
@@ -3149,10 +3160,10 @@ static int mlx5e_xdp_set(struct net_device *netdev, struct bpf_prog *prog)
if (was_opened && reset)
mlx5e_close_locked(netdev);
- /* exchange programs */
+ /* exchange programs, extra prog reference we got from caller
+ * as long as we don't fail from this point onwards.
+ */
old_prog = xchg(&priv->xdp_prog, prog);
- if (prog)
- bpf_prog_add(prog, 1);
if (old_prog)
bpf_prog_put(old_prog);
@@ -3163,12 +3174,11 @@ static int mlx5e_xdp_set(struct net_device *netdev, struct bpf_prog *prog)
mlx5e_open_locked(netdev);
if (!test_bit(MLX5E_STATE_OPENED, &priv->state) || reset)
- goto unlock;
+ goto unlock_put;
/* exchanging programs w/o reset, we update ref counts on behalf
* of the channels RQs here.
*/
- bpf_prog_add(prog, priv->params.num_channels);
for (i = 0; i < priv->params.num_channels; i++) {
struct mlx5e_channel *c = priv->channel[i];
@@ -3190,6 +3200,11 @@ static int mlx5e_xdp_set(struct net_device *netdev, struct bpf_prog *prog)
unlock:
mutex_unlock(&priv->state_lock);
return err;
+unlock_put:
+ /* reference on priv->xdp_prog is still held at this point */
+ if (prog)
+ bpf_prog_sub(prog, priv->params.num_channels);
+ goto unlock;
}
static bool mlx5e_xdp_attached(struct net_device *dev)
--
1.9.3
^ permalink raw reply related
* [PATCH net] net: dsa: b53: Fix VLAN usage and how we treat CPU port
From: Florian Fainelli @ 2016-11-15 23:58 UTC (permalink / raw)
To: netdev; +Cc: davem, andrew, vivien.didelot, knaack.h, Florian Fainelli
We currently have a fundamental problem in how we treat the CPU port and
its VLAN membership. As soon as a second VLAN is configured to be
untagged, the CPU automatically becomes untagged for that VLAN as well,
and yet, we don't gracefully make sure that the CPU becomes tagged in
the other VLANs it could be a member of. This results in only one VLAN
being effectively usable from the CPU's perspective.
Instead of having some pretty complex logic which tries to maintain the
CPU port's default VLAN and its untagged properties, just do something
very simple which consists in neither altering the CPU port's PVID
settings, nor its untagged settings:
- whenever a VLAN is added, the CPU is automatically a member of this
VLAN group, as a tagged member
- PVID settings for downstream ports do not alter the CPU port's PVID
since it now is part of all VLANs in the system
This means that a typical example where e.g: LAN ports are in VLAN1, and
WAN port is in VLAN2, now require having two VLAN interfaces for the
host to properly terminate and send traffic from/to.
Fixes: Fixes: a2482d2ce349 ("net: dsa: b53: Plug in VLAN support")
Reported-by: Hartmut Knaack <knaack.h@gmx.de>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
David,
Can you queue this for -stable so it makes it into 4.8.4?
Thank you!
drivers/net/dsa/b53/b53_common.c | 16 ++++------------
1 file changed, 4 insertions(+), 12 deletions(-)
diff --git a/drivers/net/dsa/b53/b53_common.c b/drivers/net/dsa/b53/b53_common.c
index 7717b19dc806..947adda3397d 100644
--- a/drivers/net/dsa/b53/b53_common.c
+++ b/drivers/net/dsa/b53/b53_common.c
@@ -962,9 +962,10 @@ static void b53_vlan_add(struct dsa_switch *ds, int port,
vl->members |= BIT(port) | BIT(cpu_port);
if (untagged)
- vl->untag |= BIT(port) | BIT(cpu_port);
+ vl->untag |= BIT(port);
else
- vl->untag &= ~(BIT(port) | BIT(cpu_port));
+ vl->untag &= ~BIT(port);
+ vl->untag &= ~BIT(cpu_port);
b53_set_vlan_entry(dev, vid, vl);
b53_fast_age_vlan(dev, vid);
@@ -973,8 +974,6 @@ static void b53_vlan_add(struct dsa_switch *ds, int port,
if (pvid) {
b53_write16(dev, B53_VLAN_PAGE, B53_VLAN_PORT_DEF_TAG(port),
vlan->vid_end);
- b53_write16(dev, B53_VLAN_PAGE, B53_VLAN_PORT_DEF_TAG(cpu_port),
- vlan->vid_end);
b53_fast_age_vlan(dev, vid);
}
}
@@ -984,7 +983,6 @@ static int b53_vlan_del(struct dsa_switch *ds, int port,
{
struct b53_device *dev = ds->priv;
bool untagged = vlan->flags & BRIDGE_VLAN_INFO_UNTAGGED;
- unsigned int cpu_port = dev->cpu_port;
struct b53_vlan *vl;
u16 vid;
u16 pvid;
@@ -997,8 +995,6 @@ static int b53_vlan_del(struct dsa_switch *ds, int port,
b53_get_vlan_entry(dev, vid, vl);
vl->members &= ~BIT(port);
- if ((vl->members & BIT(cpu_port)) == BIT(cpu_port))
- vl->members = 0;
if (pvid == vid) {
if (is5325(dev) || is5365(dev))
@@ -1007,18 +1003,14 @@ static int b53_vlan_del(struct dsa_switch *ds, int port,
pvid = 0;
}
- if (untagged) {
+ if (untagged)
vl->untag &= ~(BIT(port));
- if ((vl->untag & BIT(cpu_port)) == BIT(cpu_port))
- vl->untag = 0;
- }
b53_set_vlan_entry(dev, vid, vl);
b53_fast_age_vlan(dev, vid);
}
b53_write16(dev, B53_VLAN_PAGE, B53_VLAN_PORT_DEF_TAG(port), pvid);
- b53_write16(dev, B53_VLAN_PAGE, B53_VLAN_PORT_DEF_TAG(cpu_port), pvid);
b53_fast_age_vlan(dev, pvid);
return 0;
--
2.9.3
^ permalink raw reply related
* Re: [PATCH] lan78xx: relocate mdix setting to phy driver
From: Florian Fainelli @ 2016-11-15 23:47 UTC (permalink / raw)
To: Woojung.Huh, davem; +Cc: andrew, netdev, UNGLinuxDriver
In-Reply-To: <9235D6609DB808459E95D78E17F2E43D40965635@CHN-SV-EXMX02.mchp-main.com>
On 11/15/2016 01:57 PM, Woojung.Huh@microchip.com wrote:
> From: Woojung Huh <woojung.huh@microchip.com>
>
> Relocate mdix code to phy driver to be called at config_init().
>
> Signed-off-by: Woojung Huh <woojung.huh@microchip.com>
> ---
> drivers/net/phy/microchip.c | 43 +++++++++++++++++++++++++-
> drivers/net/usb/lan78xx.c | 73 ++-------------------------------------------
> 2 files changed, 45 insertions(+), 71 deletions(-)
>
> diff --git a/drivers/net/phy/microchip.c b/drivers/net/phy/microchip.c
> index 7c00e50..13553df 100644
> --- a/drivers/net/phy/microchip.c
> +++ b/drivers/net/phy/microchip.c
> @@ -106,6 +106,47 @@ static int lan88xx_set_wol(struct phy_device *phydev,
> return 0;
> }
>
> +static void lan88xx_set_mdix(struct phy_device *phydev)
> +{
> + int buf;
> +
> + if (phydev->mdix == ETH_TP_MDI) {
> + phy_write(phydev, LAN88XX_EXT_PAGE_ACCESS,
> + LAN88XX_EXT_PAGE_SPACE_1);
Should you take this write out of the if/else
> + buf = phy_read(phydev, LAN88XX_EXT_MODE_CTRL);
And this one too
> + buf &= ~LAN88XX_EXT_MODE_CTRL_MDIX_MASK_;
> + phy_write(phydev, LAN88XX_EXT_MODE_CTRL,
> + buf | LAN88XX_EXT_MODE_CTRL_MDI_);
> + phy_write(phydev, LAN88XX_EXT_PAGE_ACCESS,
> + LAN88XX_EXT_PAGE_SPACE_0);
And this one too as well
> + } else if (phydev->mdix == ETH_TP_MDI_X) {
switch/case statement would be more appropriate and it would be easier
to add support for future possible modes.
And once you take the write/read/write out of the switch case, it's just
a matter of translating phydev->mdix into the appropriate mask value to
write.
So essentially, this comes down to:
static void lan88xx_set_mdix(struct phy_device *phydev)
{
int buf;
int mask_val;
switch (phydev->mdix) {
case ETH_TP_MDI:
mask_val = LAN88XX_EXT_MODE_CTRL_MDI_;
break;
case ETH_TP_MDI_X:
mask_val = LAN88XX_EXT_MODE_CTRL_MDI_X_;
break;
case ETH_TP_MDI_AUTO:
mask_val = LAN88XX_EXT_MODE_CTRL_AUTO_MDIX_:
break:
default:
return;
}
phy_write(phydev, LAN88XX_EXT_PAGE_ACCESS,
LAN88XX_EXT_PAGE_SPACE_1);
buf = phy_read(phydev, LAN88XX_EXT_MODE_CTRL);
buf &= ~LAN88XX_EXT_MODE_CTRL_MDIX_MASK_;
buf |= mask_val;
phy_write(phydev, LAN88XX_EXT_MODE_CTRL, buf);
phy_write(phydev, LAN88XX_EXT_PAGE_ACCESS,
LAN88XX_EXT_PAGE_SPACE_0);
}
I leave it up to you whether you need to do this now, or as a subsequent
clean up patch.
--
Florian
^ permalink raw reply
* RE: [ovs-dev] [PATCH net-next v13 0/8] openvswitch: support for layer 3 encapsulated packets
From: Yang, Yi Y @ 2016-11-15 23:16 UTC (permalink / raw)
To: Thadeu Lima de Souza Cascardo, Jiri Benc, netdev@vger.kernel.org
Cc: dev@openvswitch.org, Simon Horman, egarver@redhat.com
In-Reply-To: <7ABC8850-9773-4457-907E-7ACC3180A590@cascardo.eti.br>
Got it, thanks, I'll follow your discussion thread.
-----Original Message-----
From: Thadeu Lima de Souza Cascardo [mailto:cascardo@cascardo.eti.br]
Sent: Wednesday, November 16, 2016 3:01 AM
To: Yang, Yi Y <yi.y.yang@intel.com>; Jiri Benc <jbenc@redhat.com>; netdev@vger.kernel.org
Cc: dev@openvswitch.org; Simon Horman <simon.horman@netronome.com>; egarver@redhat.com
Subject: Re: [ovs-dev] [PATCH net-next v13 0/8] openvswitch: support for layer 3 encapsulated packets
On November 15, 2016 11:57:21 AM GMT-02:00, "Yang, Yi Y" <yi.y.yang@intel.com> wrote:
>Hi, Jiri
>
>I'm very glad to see you're continuing this work :-), I asked Simon
>about this twice, but nobody replies. I also remember Cascardo has a
>patch set to collaborate with this patch set, I asked Cascardo, but
>nobody responds, will you continue to do Cascardo's " create tunnel
>devices using rtnetlink interface" patch set? I test the old one v3,
>that can work with vxlan module in kernel, but if I build ovs with
>option " --with-linux=/lib/modules/`uname -r`/build", ovs vxlan module
>is built in vport_vxlan module, when I create vxlan-gpe port, kernel
>will automatically load vxlan module in the kernel instead of using the
>APIs in vport_vxlan module.
>
>Cascardo, are you still working on this?
>
>-----Original Message-----
>From: netdev-owner@vger.kernel.org
>[mailto:netdev-owner@vger.kernel.org] On Behalf Of Jiri Benc
>Sent: Thursday, November 10, 2016 11:28 PM
>To: netdev@vger.kernel.org
>Cc: dev@openvswitch.org; Pravin Shelar <pshelar@ovn.org>; Lorand Jakab
><lojakab@cisco.com>; Simon Horman <simon.horman@netronome.com>
>Subject: [PATCH net-next v13 0/8] openvswitch: support for layer 3
>encapsulated packets
>
>At the core of this patch set is removing the assumption in Open
>vSwitch datapath that all packets have Ethernet header.
>
>The implementation relies on the presence of pop_eth and push_eth
>actions in datapath flows to facilitate adding and removing Ethernet
>headers as appropriate. The construction of such flows is left up to
>user-space.
>
>This series is based on work by Simon Horman, Lorand Jakab, Thomas
>Morin and others. I kept Lorand's and Simon's s-o-b in the patches that
>are derived from v11 to record their authorship of parts of the code.
>
>Changes from v12 to v13:
>
>* Addressed Pravin's feedback.
>* Removed the GRE vport conversion patch; L3 GRE ports should be
>created by
> rtnetlink instead.
>
>Main changes from v11 to v12:
>
>* The patches were restructured and split differently for easier
>review.
>* They were rebased and adjusted to the current net-next. Especially
>MPLS handling is different (and easier) thanks to the recent MPLS GSO
>rework.
>* Several bugs were discovered and fixed. The most notable is fragment
>handling: header adjustment for ARPHRD_NONE devices on tx needs to be
>done after refragmentation, not before it. This required significant
>changes in the patchset. Another one is stricter checking of attributes
>(match on
>L2
> vs. L3 packet) at the kernel level.
>* Instead of is_layer3 bool, a mac_proto field is used.
>
>Jiri Benc (8):
> openvswitch: use hard_header_len instead of hardcoded ETH_HLEN
> openvswitch: add mac_proto field to the flow key
> openvswitch: pass mac_proto to ovs_vport_send
> openvswitch: support MPLS push and pop for L3 packets
> openvswitch: add processing of L3 packets
> openvswitch: netlink: support L3 packets
> openvswitch: add Ethernet push and pop actions
> openvswitch: allow L3 netdev ports
>
> include/uapi/linux/openvswitch.h | 15 ++++
> net/openvswitch/actions.c | 111 +++++++++++++++++-------
> net/openvswitch/datapath.c | 13 +--
> net/openvswitch/flow.c | 105 +++++++++++++++++------
> net/openvswitch/flow.h | 22 +++++
>net/openvswitch/flow_netlink.c | 179
>++++++++++++++++++++++++++-------------
> net/openvswitch/vport-netdev.c | 9 +-
> net/openvswitch/vport.c | 31 +++++--
> net/openvswitch/vport.h | 2 +-
> 9 files changed, 353 insertions(+), 134 deletions(-)
>
>--
>1.8.3.1
>
>_______________________________________________
>dev mailing list
>dev@openvswitch.org
>https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Hi.
I am still working on this. Just see my recent discussion with Pravin about the way to support out of tree drivers. If you have any opinion on that, please share on that thread, preferably with a patch. It's likely that Eric Garver will take this task as he was already working with me.
Cascardo.
^ permalink raw reply
* Re: [net-next 1/2] net: ethernet: slicoss: add slicoss gigabit ethernet driver
From: Lino Sanfilippo @ 2016-11-15 23:14 UTC (permalink / raw)
To: Andrew Lunn
Cc: devel, Florian Fainelli, gregkh, linux-kernel, liodot, netdev,
davem
In-Reply-To: <20161115230317.GG23231@lunn.ch>
On 16.11.2016 00:03, Andrew Lunn wrote:
>> >>>>> + val = MII_BMCR << 16 | SLIC_PCR_AUTONEG |
>> >>>>> + SLIC_PCR_AUTONEG_RST;
>> >>>>> + slic_write(sdev, SLIC_REG_WPHY, val);
>
>> Thats essentially what I meant by setting a flag in the irq handler. The mdio
>> function would have to check somehow if the irq has been fired (be it by means
>> of a flag or a completion that is set by the irq handler and checked by the
>> mdio function). So I agree that it should work (if reading via the AP command
>> is actually possible).
>
> It seems odd you have a nice simple way to do writes, but reads are
> very complex. There might be a simple read method hiding somewhere.
>
> Andrew
>
I agree, it IS odd :).
But concerning reading the phy this is all I can see in the original source code:
http://lxr.free-electrons.com/source/drivers/staging/slicoss/slichw.h#L516
I strongly suspect that "RPHY" stand for "read phy". The only one who may
know for sure if there is another/better way is Christopher Harrer. He is also on CC
but I am not sure if he actually follows this discussion.
Lino
^ permalink raw reply
* Re: [net-next 1/2] net: ethernet: slicoss: add slicoss gigabit ethernet driver
From: Andrew Lunn @ 2016-11-15 23:03 UTC (permalink / raw)
To: Lino Sanfilippo
Cc: devel, Florian Fainelli, gregkh, linux-kernel, liodot, netdev,
davem
In-Reply-To: <c645c726-dbe2-108d-c79a-d8db350a13b8@gmx.de>
> >>>>> + val = MII_BMCR << 16 | SLIC_PCR_AUTONEG |
> >>>>> + SLIC_PCR_AUTONEG_RST;
> >>>>> + slic_write(sdev, SLIC_REG_WPHY, val);
> Thats essentially what I meant by setting a flag in the irq handler. The mdio
> function would have to check somehow if the irq has been fired (be it by means
> of a flag or a completion that is set by the irq handler and checked by the
> mdio function). So I agree that it should work (if reading via the AP command
> is actually possible).
It seems odd you have a nice simple way to do writes, but reads are
very complex. There might be a simple read method hiding somewhere.
Andrew
^ permalink raw reply
* Re: [net-next 1/2] net: ethernet: slicoss: add slicoss gigabit ethernet driver
From: Lino Sanfilippo @ 2016-11-15 22:54 UTC (permalink / raw)
To: Florian Fainelli, Andrew Lunn
Cc: davem, charrer, liodot, gregkh, devel, linux-kernel, netdev
In-Reply-To: <41c0c732-0935-1625-b88d-c084e5000a6c@gmail.com>
On 15.11.2016 23:39, Florian Fainelli wrote:
> On 11/15/2016 02:34 PM, Lino Sanfilippo wrote:
>> On 15.11.2016 22:59, Andrew Lunn wrote:
>>>> The link state is retrieved by a command to the application processor that is running
>>>> on the network card. Also the register to set the phy configuration is write-only, so
>>>> it is not even possible to do the usual mdio bit-banging in the Phy read() and write()
>>>> functions (however there seems to be another application processor command reserved
>>>> for retrieving the PHY settings, but I have not tried it yet).
>>>
>>>>> + val = MII_BMCR << 16 | SLIC_PCR_AUTONEG |
>>>>> + SLIC_PCR_AUTONEG_RST;
>>>>> + slic_write(sdev, SLIC_REG_WPHY, val);
>>>
>>> This actually looks a lot like an MDIO write operation. The upper 16
>>> bits are the register, and the lower 16 bits are the data. What you
>>> don't have is the address. But maybe it is limited to one address.
>>>
>>> If the processor command reserved for read works in a similar way, you
>>> have enough to do an MDIO bus.
>>>
>>
>> Ok, I will give it a try. Reading values via the application processor
>> is a bit awkward though, since it requires an address to a dma area as part of
>> the command and then the AP informs the driver via irq that the dma memory has
>> been written. So probably the irq handler will have to set some flag and
>> the mdio_read() function will have to poll for that flag in place of doing
>> bit-banging a register.
>
> That's a bit unusual compared to typical controllers that are usually
> memory-mapped and that you can either write to, read/poll to know about
> completion. I suppose that you could still have a mdiobus implementation
> that is able to read to/from PHYs by submitting a command to the AP,
> wait on a completion structure, and have the interrupt handler do the
> completion of the command?
>
Thats essentially what I meant by setting a flag in the irq handler. The mdio
function would have to check somehow if the irq has been fired (be it by means
of a flag or a completion that is set by the irq handler and checked by the
mdio function). So I agree that it should work (if reading via the AP command
is actually possible).
Lino
^ permalink raw reply
* Re: linux-next: net->netns_ids is used after calling idr_destroy for it
From: Andrei Vagin @ 2016-11-15 22:45 UTC (permalink / raw)
To: Cong Wang; +Cc: Nicolas Dichtel, Linux Kernel Network Developers
In-Reply-To: <CANaxB-y0_veL0hfdskXrix66FzydTSQ=MXOkmw72RsFqcXj9Pw@mail.gmail.com>
On Tue, Nov 15, 2016 at 2:21 PM, Andrei Vagin <avagin@gmail.com> wrote:
> On Tue, Nov 15, 2016 at 1:07 PM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
>> On Tue, Nov 15, 2016 at 12:48 PM, Andrei Vagin <avagin@gmail.com> wrote:
>>> On Tue, Nov 15, 2016 at 10:50 AM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
>>>> On Tue, Nov 15, 2016 at 10:04 AM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
>>>>> On Mon, Nov 14, 2016 at 10:23 PM, Andrei Vagin <avagin@gmail.com> wrote:
>>>>>> Hi Nicolas,
>>>>>>
>>>>>> cleanup_net() calls idr_destroy(net->netns_ids) for network namespaces
>>>>>> and then it calls unregister_netdevice_many() which calls
>>>>>> idr_alloc(net0>netns_ids). It looks wrong, doesn't it?
>>>>>>
>>>>>
>>>>> netns id is designed to allocate lazily, but yeah it makes no sense
>>>>> to allocate id for the netns being destroyed, not to mention idr is freed.
>>>>>
>>>>> I will send a patch.
>>>>
>>>> Could you try the attached patch? I just did some quick netns creation/destroy
>>>> tests.
>>>
>>> Here is another fail:
>>>
>>> unreferenced object 0xffff94153912a0c0 (size 2096):
>>> comm "ip", pid 29175, jiffies 4294954213 (age 137.624s)
>>> hex dump (first 32 bytes):
>>> 00 00 00 00 00 00 00 00 00 b2 3b 1d 15 94 ff ff ..........;.....
>>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>>> backtrace:
>>> [<ffffffffac865c1a>] kmemleak_alloc+0x4a/0xa0
>>> [<ffffffffac243b38>] kmem_cache_alloc+0x128/0x280
>>> [<ffffffffac42f5ab>] idr_layer_alloc+0x2b/0x90
>>> [<ffffffffac42f9cd>] idr_get_empty_slot+0x34d/0x370
>>> [<ffffffffac42fa4e>] idr_alloc+0x5e/0x110
>>> [<ffffffffac70ac3d>] __peernet2id_alloc+0x6d/0x90
>>> [<ffffffffac70bda5>] peernet2id_alloc+0x55/0xb0
>>> [<ffffffffac731246>] rtnl_fill_ifinfo+0xaa6/0x10a0
>>> [<ffffffffac7330a3>] rtmsg_ifinfo_build_skb+0x73/0xd0
>>> [<ffffffffac7125e1>] rollback_registered_many+0x2a1/0x3a0
>>> [<ffffffffac712779>] __unregister_netdevice_many+0x29/0x80
>>> [<ffffffffac7127e3>] unregister_netdevice_many+0x13/0x20
>>> [<ffffffffc02dc4ce>] macvlan_device_event+0x13e/0x235 [macvlan]
>>> [<ffffffffac0bef2a>] notifier_call_chain+0x4a/0x70
>>> [<ffffffffac0bf066>] raw_notifier_call_chain+0x16/0x20
>>> [<ffffffffac710205>] call_netdevice_notifiers_info+0x35/0x60
>>>
>>
>> Oh, drivers send rtmsg in notifiers too, hmm.
>>
>>>
>>> What do you think about calling idr_destroy() at the final step in
>>> cleanup_net()? In this case we can avoid this sort of problems in a
>>> future.
>>
>> This was my first idea too, but it looks more risky than my approach.
>>
>> Also, rtmsg is really not needed because the netns is being destroyed,
>> no one cares about it here.
>
> I would like to agree with you here, but looks like sockets with
> NETLINK_F_LISTEN_ALL_NSID are able to catch these messages.
Actually I found that I was wrong.
do_one_broadcast() sends a notification only if a device network
namespace has an id in a socket netns. But cleanup_net() removes all
id-s to a target namespace, so just ignore my last comment.
Thanks,
Andrei
^ permalink raw reply
* Re: [net-next 1/2] net: ethernet: slicoss: add slicoss gigabit ethernet driver
From: Florian Fainelli @ 2016-11-15 22:39 UTC (permalink / raw)
To: Lino Sanfilippo, Andrew Lunn
Cc: davem, charrer, liodot, gregkh, devel, linux-kernel, netdev
In-Reply-To: <86165d2b-f9d5-a380-9bb0-f77c12691eb6@gmx.de>
On 11/15/2016 02:34 PM, Lino Sanfilippo wrote:
> On 15.11.2016 22:59, Andrew Lunn wrote:
>>> The link state is retrieved by a command to the application processor that is running
>>> on the network card. Also the register to set the phy configuration is write-only, so
>>> it is not even possible to do the usual mdio bit-banging in the Phy read() and write()
>>> functions (however there seems to be another application processor command reserved
>>> for retrieving the PHY settings, but I have not tried it yet).
>>
>>>> + val = MII_BMCR << 16 | SLIC_PCR_AUTONEG |
>>>> + SLIC_PCR_AUTONEG_RST;
>>>> + slic_write(sdev, SLIC_REG_WPHY, val);
>>
>> This actually looks a lot like an MDIO write operation. The upper 16
>> bits are the register, and the lower 16 bits are the data. What you
>> don't have is the address. But maybe it is limited to one address.
>>
>> If the processor command reserved for read works in a similar way, you
>> have enough to do an MDIO bus.
>>
>
> Ok, I will give it a try. Reading values via the application processor
> is a bit awkward though, since it requires an address to a dma area as part of
> the command and then the AP informs the driver via irq that the dma memory has
> been written. So probably the irq handler will have to set some flag and
> the mdio_read() function will have to poll for that flag in place of doing
> bit-banging a register.
That's a bit unusual compared to typical controllers that are usually
memory-mapped and that you can either write to, read/poll to know about
completion. I suppose that you could still have a mdiobus implementation
that is able to read to/from PHYs by submitting a command to the AP,
wait on a completion structure, and have the interrupt handler do the
completion of the command?
--
Florian
^ permalink raw reply
* Re: [net-next 1/2] net: ethernet: slicoss: add slicoss gigabit ethernet driver
From: Lino Sanfilippo @ 2016-11-15 22:34 UTC (permalink / raw)
To: Andrew Lunn
Cc: Florian Fainelli, davem, charrer, liodot, gregkh, devel,
linux-kernel, netdev
In-Reply-To: <20161115215907.GF23231@lunn.ch>
On 15.11.2016 22:59, Andrew Lunn wrote:
>> The link state is retrieved by a command to the application processor that is running
>> on the network card. Also the register to set the phy configuration is write-only, so
>> it is not even possible to do the usual mdio bit-banging in the Phy read() and write()
>> functions (however there seems to be another application processor command reserved
>> for retrieving the PHY settings, but I have not tried it yet).
>
>>> + val = MII_BMCR << 16 | SLIC_PCR_AUTONEG |
>>> + SLIC_PCR_AUTONEG_RST;
>>> + slic_write(sdev, SLIC_REG_WPHY, val);
>
> This actually looks a lot like an MDIO write operation. The upper 16
> bits are the register, and the lower 16 bits are the data. What you
> don't have is the address. But maybe it is limited to one address.
>
> If the processor command reserved for read works in a similar way, you
> have enough to do an MDIO bus.
>
Ok, I will give it a try. Reading values via the application processor
is a bit awkward though, since it requires an address to a dma area as part of
the command and then the AP informs the driver via irq that the dma memory has
been written. So probably the irq handler will have to set some flag and
the mdio_read() function will have to poll for that flag in place of doing
bit-banging a register.
> If you can get the read working look at registers 2 and 3. Compare
> what you get with the values at the end of marvell.c.
>
Will do, thank you!
Lino
^ permalink raw reply
* Re: linux-next: net->netns_ids is used after calling idr_destroy for it
From: Andrei Vagin @ 2016-11-15 22:21 UTC (permalink / raw)
To: Cong Wang; +Cc: Nicolas Dichtel, Linux Kernel Network Developers
In-Reply-To: <CAM_iQpXYvGnaf=AAD5EJYqQ7WApjRyUResN+0Z_Bq1Xt8G8zQQ@mail.gmail.com>
On Tue, Nov 15, 2016 at 1:07 PM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> On Tue, Nov 15, 2016 at 12:48 PM, Andrei Vagin <avagin@gmail.com> wrote:
>> On Tue, Nov 15, 2016 at 10:50 AM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
>>> On Tue, Nov 15, 2016 at 10:04 AM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
>>>> On Mon, Nov 14, 2016 at 10:23 PM, Andrei Vagin <avagin@gmail.com> wrote:
>>>>> Hi Nicolas,
>>>>>
>>>>> cleanup_net() calls idr_destroy(net->netns_ids) for network namespaces
>>>>> and then it calls unregister_netdevice_many() which calls
>>>>> idr_alloc(net0>netns_ids). It looks wrong, doesn't it?
>>>>>
>>>>
>>>> netns id is designed to allocate lazily, but yeah it makes no sense
>>>> to allocate id for the netns being destroyed, not to mention idr is freed.
>>>>
>>>> I will send a patch.
>>>
>>> Could you try the attached patch? I just did some quick netns creation/destroy
>>> tests.
>>
>> Here is another fail:
>>
>> unreferenced object 0xffff94153912a0c0 (size 2096):
>> comm "ip", pid 29175, jiffies 4294954213 (age 137.624s)
>> hex dump (first 32 bytes):
>> 00 00 00 00 00 00 00 00 00 b2 3b 1d 15 94 ff ff ..........;.....
>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>> backtrace:
>> [<ffffffffac865c1a>] kmemleak_alloc+0x4a/0xa0
>> [<ffffffffac243b38>] kmem_cache_alloc+0x128/0x280
>> [<ffffffffac42f5ab>] idr_layer_alloc+0x2b/0x90
>> [<ffffffffac42f9cd>] idr_get_empty_slot+0x34d/0x370
>> [<ffffffffac42fa4e>] idr_alloc+0x5e/0x110
>> [<ffffffffac70ac3d>] __peernet2id_alloc+0x6d/0x90
>> [<ffffffffac70bda5>] peernet2id_alloc+0x55/0xb0
>> [<ffffffffac731246>] rtnl_fill_ifinfo+0xaa6/0x10a0
>> [<ffffffffac7330a3>] rtmsg_ifinfo_build_skb+0x73/0xd0
>> [<ffffffffac7125e1>] rollback_registered_many+0x2a1/0x3a0
>> [<ffffffffac712779>] __unregister_netdevice_many+0x29/0x80
>> [<ffffffffac7127e3>] unregister_netdevice_many+0x13/0x20
>> [<ffffffffc02dc4ce>] macvlan_device_event+0x13e/0x235 [macvlan]
>> [<ffffffffac0bef2a>] notifier_call_chain+0x4a/0x70
>> [<ffffffffac0bf066>] raw_notifier_call_chain+0x16/0x20
>> [<ffffffffac710205>] call_netdevice_notifiers_info+0x35/0x60
>>
>
> Oh, drivers send rtmsg in notifiers too, hmm.
>
>>
>> What do you think about calling idr_destroy() at the final step in
>> cleanup_net()? In this case we can avoid this sort of problems in a
>> future.
>
> This was my first idea too, but it looks more risky than my approach.
>
> Also, rtmsg is really not needed because the netns is being destroyed,
> no one cares about it here.
I would like to agree with you here, but looks like sockets with
NETLINK_F_LISTEN_ALL_NSID are able to catch these messages.
^ permalink raw reply
* [PATCH net-next 2/2] amd-xgbe: Fix maximum GPIO value check
From: Tom Lendacky @ 2016-11-15 22:11 UTC (permalink / raw)
To: netdev; +Cc: colin.king, David Miller, dan.carpenter
In-Reply-To: <20161115221055.12403.90574.stgit@tlendack-t1.amdoffice.net>
The GPIO support in the hardware allows for up to 16 GPIO pins, enumerated
from 0 to 15. The driver uses the wrong value (16) to validate the GPIO
pin range in the routines to set and clear the GPIO output pins. Update
the code to use the correct value (15).
Reported-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
drivers/net/ethernet/amd/xgbe/xgbe-dev.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-dev.c b/drivers/net/ethernet/amd/xgbe/xgbe-dev.c
index 30056e2..aaf0350 100644
--- a/drivers/net/ethernet/amd/xgbe/xgbe-dev.c
+++ b/drivers/net/ethernet/amd/xgbe/xgbe-dev.c
@@ -1099,7 +1099,7 @@ static int xgbe_clr_gpio(struct xgbe_prv_data *pdata, unsigned int gpio)
{
unsigned int reg;
- if (gpio > 16)
+ if (gpio > 15)
return -EINVAL;
reg = XGMAC_IOREAD(pdata, MAC_GPIOSR);
@@ -1114,7 +1114,7 @@ static int xgbe_set_gpio(struct xgbe_prv_data *pdata, unsigned int gpio)
{
unsigned int reg;
- if (gpio > 16)
+ if (gpio > 15)
return -EINVAL;
reg = XGMAC_IOREAD(pdata, MAC_GPIOSR);
^ permalink raw reply related
* [PATCH net-next 1/2] amd-xgbe: Fix possible uninitialized variable
From: Tom Lendacky @ 2016-11-15 22:11 UTC (permalink / raw)
To: netdev; +Cc: colin.king, David Miller, dan.carpenter
In-Reply-To: <20161115221055.12403.90574.stgit@tlendack-t1.amdoffice.net>
The debugfs support in the driver uses a common routine to write the
debugfs values. In this routine, if the input file position is non-zero
then the write routine will not return an error and an output parameter
will not have been set. Because an error isn't returned an uninitialized
value will be written into a register.
Fix the common write routine to return an error if the input file position
is non-zero, which will propagate back to the caller.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
drivers/net/ethernet/amd/xgbe/xgbe-debugfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-debugfs.c b/drivers/net/ethernet/amd/xgbe/xgbe-debugfs.c
index 0c0140d..7546b66 100644
--- a/drivers/net/ethernet/amd/xgbe/xgbe-debugfs.c
+++ b/drivers/net/ethernet/amd/xgbe/xgbe-debugfs.c
@@ -153,7 +153,7 @@ static ssize_t xgbe_common_write(const char __user *buffer, size_t count,
int ret;
if (*ppos != 0)
- return 0;
+ return -EINVAL;
if (count >= sizeof(workarea))
return -ENOSPC;
^ permalink raw reply related
* [PATCH net-next 0/2] amd-xgbe: AMD XGBE driver updates 2016-11-15
From: Tom Lendacky @ 2016-11-15 22:10 UTC (permalink / raw)
To: netdev; +Cc: colin.king, David Miller, dan.carpenter
This patch series addresses some minor issues found in the recently
accepted patch series for the AMD XGBE driver.
The following fixes are included in this driver update series:
- Fix a possibly uninitialized variable in the debugfs support
- Fix the GPIO pin number constraint check
This patch series is based on net-next.
---
Tom Lendacky (2):
amd-xgbe: Fix possible uninitialized variable
amd-xgbe: Fix maximum GPIO value check
drivers/net/ethernet/amd/xgbe/xgbe-debugfs.c | 2 +-
drivers/net/ethernet/amd/xgbe/xgbe-dev.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
--
Tom Lendacky
^ permalink raw reply
* Re: [PATCH] net: bnx2: use new api ethtool_{get|set}_link_ksettings
From: David Miller @ 2016-11-15 22:05 UTC (permalink / raw)
To: tremyfr; +Cc: rasesh.mody, harish.patil, Dept-GELinuxNICDev, netdev,
linux-kernel
In-Reply-To: <1479076426-9024-1-git-send-email-tremyfr@gmail.com>
From: Philippe Reynes <tremyfr@gmail.com>
Date: Sun, 13 Nov 2016 23:33:46 +0100
> The ethtool api {get|set}_settings is deprecated.
> We move this driver to new api {get|set}_link_ksettings.
>
> Signed-off-by: Philippe Reynes <tremyfr@gmail.com>
Applied.
^ permalink raw reply
* Re: [net-next 1/2] net: ethernet: slicoss: add slicoss gigabit ethernet driver
From: Andrew Lunn @ 2016-11-15 21:59 UTC (permalink / raw)
To: Lino Sanfilippo
Cc: Florian Fainelli, davem, charrer, liodot, gregkh, devel,
linux-kernel, netdev
In-Reply-To: <0d1b4dee-11bb-3605-699c-ea417484cb68@gmx.de>
> The link state is retrieved by a command to the application processor that is running
> on the network card. Also the register to set the phy configuration is write-only, so
> it is not even possible to do the usual mdio bit-banging in the Phy read() and write()
> functions (however there seems to be another application processor command reserved
> for retrieving the PHY settings, but I have not tried it yet).
>> + val = MII_BMCR << 16 | SLIC_PCR_AUTONEG |
>> + SLIC_PCR_AUTONEG_RST;
>> + slic_write(sdev, SLIC_REG_WPHY, val);
This actually looks a lot like an MDIO write operation. The upper 16
bits are the register, and the lower 16 bits are the data. What you
don't have is the address. But maybe it is limited to one address.
If the processor command reserved for read works in a similar way, you
have enough to do an MDIO bus.
> Please also note that I do not have any datasheets or other documentation for the hardware,
> all I have as a reference is the driver code in staging. So I do not know which
> PHYs are actually used (the comments in the code mention Marvell and Cicada but this is
> not very specific).
If you can get the read working look at registers 2 and 3. Compare
what you get with the values at the end of marvell.c.
Andrew
^ permalink raw reply
* [PATCH] lan78xx: relocate mdix setting to phy driver
From: Woojung.Huh @ 2016-11-15 21:57 UTC (permalink / raw)
To: davem; +Cc: f.fainelli, andrew, netdev, UNGLinuxDriver
From: Woojung Huh <woojung.huh@microchip.com>
Relocate mdix code to phy driver to be called at config_init().
Signed-off-by: Woojung Huh <woojung.huh@microchip.com>
---
drivers/net/phy/microchip.c | 43 +++++++++++++++++++++++++-
drivers/net/usb/lan78xx.c | 73 ++-------------------------------------------
2 files changed, 45 insertions(+), 71 deletions(-)
diff --git a/drivers/net/phy/microchip.c b/drivers/net/phy/microchip.c
index 7c00e50..13553df 100644
--- a/drivers/net/phy/microchip.c
+++ b/drivers/net/phy/microchip.c
@@ -106,6 +106,47 @@ static int lan88xx_set_wol(struct phy_device *phydev,
return 0;
}
+static void lan88xx_set_mdix(struct phy_device *phydev)
+{
+ int buf;
+
+ if (phydev->mdix == ETH_TP_MDI) {
+ phy_write(phydev, LAN88XX_EXT_PAGE_ACCESS,
+ LAN88XX_EXT_PAGE_SPACE_1);
+ buf = phy_read(phydev, LAN88XX_EXT_MODE_CTRL);
+ buf &= ~LAN88XX_EXT_MODE_CTRL_MDIX_MASK_;
+ phy_write(phydev, LAN88XX_EXT_MODE_CTRL,
+ buf | LAN88XX_EXT_MODE_CTRL_MDI_);
+ phy_write(phydev, LAN88XX_EXT_PAGE_ACCESS,
+ LAN88XX_EXT_PAGE_SPACE_0);
+ } else if (phydev->mdix == ETH_TP_MDI_X) {
+ phy_write(phydev, LAN88XX_EXT_PAGE_ACCESS,
+ LAN88XX_EXT_PAGE_SPACE_1);
+ buf = phy_read(phydev, LAN88XX_EXT_MODE_CTRL);
+ buf &= ~LAN88XX_EXT_MODE_CTRL_MDIX_MASK_;
+ phy_write(phydev, LAN88XX_EXT_MODE_CTRL,
+ buf | LAN88XX_EXT_MODE_CTRL_MDI_X_);
+ phy_write(phydev, LAN88XX_EXT_PAGE_ACCESS,
+ LAN88XX_EXT_PAGE_SPACE_0);
+ } else if (phydev->mdix == ETH_TP_MDI_AUTO) {
+ phy_write(phydev, LAN88XX_EXT_PAGE_ACCESS,
+ LAN88XX_EXT_PAGE_SPACE_1);
+ buf = phy_read(phydev, LAN88XX_EXT_MODE_CTRL);
+ buf &= ~LAN88XX_EXT_MODE_CTRL_MDIX_MASK_;
+ phy_write(phydev, LAN88XX_EXT_MODE_CTRL,
+ buf | LAN88XX_EXT_MODE_CTRL_AUTO_MDIX_);
+ phy_write(phydev, LAN88XX_EXT_PAGE_ACCESS,
+ LAN88XX_EXT_PAGE_SPACE_0);
+ }
+}
+
+static int lan88xx_config_aneg(struct phy_device *phydev)
+{
+ lan88xx_set_mdix(phydev);
+
+ return genphy_config_aneg(phydev);
+}
+
static struct phy_driver microchip_phy_driver[] = {
{
.phy_id = 0x0007c130,
@@ -120,7 +161,7 @@ static struct phy_driver microchip_phy_driver[] = {
.remove = lan88xx_remove,
.config_init = genphy_config_init,
- .config_aneg = genphy_config_aneg,
+ .config_aneg = lan88xx_config_aneg,
.read_status = genphy_read_status,
.ack_interrupt = lan88xx_phy_ack_interrupt,
diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c
index bcd9010..affc3b4 100644
--- a/drivers/net/usb/lan78xx.c
+++ b/drivers/net/usb/lan78xx.c
@@ -1476,62 +1476,12 @@ static void lan78xx_set_msglevel(struct net_device *net, u32 level)
dev->msg_enable = level;
}
-static int lan78xx_get_mdix_status(struct net_device *net)
-{
- struct phy_device *phydev = net->phydev;
- int buf;
-
- phy_write(phydev, LAN88XX_EXT_PAGE_ACCESS, LAN88XX_EXT_PAGE_SPACE_1);
- buf = phy_read(phydev, LAN88XX_EXT_MODE_CTRL);
- phy_write(phydev, LAN88XX_EXT_PAGE_ACCESS, LAN88XX_EXT_PAGE_SPACE_0);
-
- return buf;
-}
-
-static void lan78xx_set_mdix_status(struct net_device *net, __u8 mdix_ctrl)
-{
- struct lan78xx_net *dev = netdev_priv(net);
- struct phy_device *phydev = net->phydev;
- int buf;
-
- if (mdix_ctrl == ETH_TP_MDI) {
- phy_write(phydev, LAN88XX_EXT_PAGE_ACCESS,
- LAN88XX_EXT_PAGE_SPACE_1);
- buf = phy_read(phydev, LAN88XX_EXT_MODE_CTRL);
- buf &= ~LAN88XX_EXT_MODE_CTRL_MDIX_MASK_;
- phy_write(phydev, LAN88XX_EXT_MODE_CTRL,
- buf | LAN88XX_EXT_MODE_CTRL_MDI_);
- phy_write(phydev, LAN88XX_EXT_PAGE_ACCESS,
- LAN88XX_EXT_PAGE_SPACE_0);
- } else if (mdix_ctrl == ETH_TP_MDI_X) {
- phy_write(phydev, LAN88XX_EXT_PAGE_ACCESS,
- LAN88XX_EXT_PAGE_SPACE_1);
- buf = phy_read(phydev, LAN88XX_EXT_MODE_CTRL);
- buf &= ~LAN88XX_EXT_MODE_CTRL_MDIX_MASK_;
- phy_write(phydev, LAN88XX_EXT_MODE_CTRL,
- buf | LAN88XX_EXT_MODE_CTRL_MDI_X_);
- phy_write(phydev, LAN88XX_EXT_PAGE_ACCESS,
- LAN88XX_EXT_PAGE_SPACE_0);
- } else if (mdix_ctrl == ETH_TP_MDI_AUTO) {
- phy_write(phydev, LAN88XX_EXT_PAGE_ACCESS,
- LAN88XX_EXT_PAGE_SPACE_1);
- buf = phy_read(phydev, LAN88XX_EXT_MODE_CTRL);
- buf &= ~LAN88XX_EXT_MODE_CTRL_MDIX_MASK_;
- phy_write(phydev, LAN88XX_EXT_MODE_CTRL,
- buf | LAN88XX_EXT_MODE_CTRL_AUTO_MDIX_);
- phy_write(phydev, LAN88XX_EXT_PAGE_ACCESS,
- LAN88XX_EXT_PAGE_SPACE_0);
- }
- dev->mdix_ctrl = mdix_ctrl;
-}
-
static int lan78xx_get_link_ksettings(struct net_device *net,
struct ethtool_link_ksettings *cmd)
{
struct lan78xx_net *dev = netdev_priv(net);
struct phy_device *phydev = net->phydev;
int ret;
- int buf;
ret = usb_autopm_get_interface(dev->intf);
if (ret < 0)
@@ -1539,20 +1489,6 @@ static int lan78xx_get_link_ksettings(struct net_device *net,
ret = phy_ethtool_ksettings_get(phydev, cmd);
- buf = lan78xx_get_mdix_status(net);
-
- buf &= LAN88XX_EXT_MODE_CTRL_MDIX_MASK_;
- if (buf == LAN88XX_EXT_MODE_CTRL_AUTO_MDIX_) {
- cmd->base.eth_tp_mdix = ETH_TP_MDI_AUTO;
- cmd->base.eth_tp_mdix_ctrl = ETH_TP_MDI_AUTO;
- } else if (buf == LAN88XX_EXT_MODE_CTRL_MDI_) {
- cmd->base.eth_tp_mdix = ETH_TP_MDI;
- cmd->base.eth_tp_mdix_ctrl = ETH_TP_MDI;
- } else if (buf == LAN88XX_EXT_MODE_CTRL_MDI_X_) {
- cmd->base.eth_tp_mdix = ETH_TP_MDI_X;
- cmd->base.eth_tp_mdix_ctrl = ETH_TP_MDI_X;
- }
-
usb_autopm_put_interface(dev->intf);
return ret;
@@ -1570,9 +1506,6 @@ static int lan78xx_set_link_ksettings(struct net_device *net,
if (ret < 0)
return ret;
- if (dev->mdix_ctrl != cmd->base.eth_tp_mdix_ctrl)
- lan78xx_set_mdix_status(net, cmd->base.eth_tp_mdix_ctrl);
-
/* change speed & duplex */
ret = phy_ethtool_ksettings_set(phydev, cmd);
@@ -2024,6 +1957,9 @@ static int lan78xx_phy_init(struct lan78xx_net *dev)
phydev->irq = 0;
netdev_dbg(dev->net, "phydev->irq = %d\n", phydev->irq);
+ /* set to AUTOMDIX */
+ phydev->mdix = ETH_TP_MDI_AUTO;
+
ret = phy_connect_direct(dev->net, phydev,
lan78xx_link_status_change,
PHY_INTERFACE_MODE_GMII);
@@ -2033,9 +1969,6 @@ static int lan78xx_phy_init(struct lan78xx_net *dev)
return -EIO;
}
- /* set to AUTOMDIX */
- lan78xx_set_mdix_status(dev->net, ETH_TP_MDI_AUTO);
-
/* MAC doesn't support 1000T Half */
phydev->supported &= ~SUPPORTED_1000baseT_Half;
--
2.7.4
^ permalink raw reply related
* Re: [Intel-wired-lan] [PATCH v2] e1000e: free IRQ regardless of __E1000_DOWN
From: Baicar, Tyler @ 2016-11-15 21:50 UTC (permalink / raw)
To: Neftin, Sasha, jeffrey.t.kirsher, intel-wired-lan, netdev,
linux-kernel, okaya, timur
In-Reply-To: <70121f26-2d5a-528f-04f5-30a97b93a585@intel.com>
On 11/13/2016 2:25 AM, Neftin, Sasha wrote:
> On 11/13/2016 10:34 AM, Neftin, Sasha wrote:
>> On 11/11/2016 12:35 AM, Baicar, Tyler wrote:
>>> Hello Sasha,
>>>
>>> On 11/9/2016 11:19 PM, Neftin, Sasha wrote:
>>>> On 11/9/2016 11:41 PM, Tyler Baicar wrote:
>>>>> Move IRQ free code so that it will happen regardless of the
>>>>> __E1000_DOWN bit. Currently the e1000e driver only releases its IRQ
>>>>> if the __E1000_DOWN bit is cleared. This is not sufficient because
>>>>> it is possible for __E1000_DOWN to be set without releasing the IRQ.
>>>>> In such a situation, we will hit a kernel bug later in e1000_remove
>>>>> because the IRQ still has action since it was never freed. A
>>>>> secondary bus reset can cause this case to happen.
>>>>>
>>>>> Signed-off-by: Tyler Baicar <tbaicar@codeaurora.org>
>>>>> ---
>>>>> drivers/net/ethernet/intel/e1000e/netdev.c | 3 ++-
>>>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c
>>>>> b/drivers/net/ethernet/intel/e1000e/netdev.c
>>>>> index 7017281..36cfcb0 100644
>>>>> --- a/drivers/net/ethernet/intel/e1000e/netdev.c
>>>>> +++ b/drivers/net/ethernet/intel/e1000e/netdev.c
>>>>> @@ -4679,12 +4679,13 @@ int e1000e_close(struct net_device *netdev)
>>>>> if (!test_bit(__E1000_DOWN, &adapter->state)) {
>>>>> e1000e_down(adapter, true);
>>>>> - e1000_free_irq(adapter);
>>>>> /* Link status message must follow this format */
>>>>> pr_info("%s NIC Link is Down\n", adapter->netdev->name);
>>>>> }
>>>>> + e1000_free_irq(adapter);
>>>>> +
>>>>> napi_disable(&adapter->napi);
>>>>> e1000e_free_tx_resources(adapter->tx_ring);
>>>>>
>>>> I would like not recommend insert this change. This change related
>>>> driver state machine, we afraid from lot of synchronization problem and
>>>> issues.
>>>> We need keep e1000_free_irq in loop and check for 'test_bit' ready.
>>> What do you mean here? There is no loop. If __E1000_DOWN is set then we
>>> will never free the IRQ.
>>>
>>>> Another point, does before execute secondary bus reset your SW back up
>>>> pcie configuration space as properly?
>>> After a secondary bus reset, the link needs to recover and go back to a
>>> working state after 1 second.
>>>
>>> From the callstack, the issue is happening while removing the endpoint
>>> from the system, before applying the secondary bus reset.
>>>
>>> The order of events is
>>> 1. remove the drivers
>>> 2. cause a secondary bus reset
>>> 3. wait 1 second
>> Actually, this is too much, usually link up in less than 100ms.You can
>> check Data Link Layer indication.
>>> 4. recover the link
>>>
>>> callstack:
>>> free_msi_irqs+0x6c/0x1a8
>>> pci_disable_msi+0xb0/0x148
>>> e1000e_reset_interrupt_capability+0x60/0x78
>>> e1000_remove+0xc8/0x180
>>> pci_device_remove+0x48/0x118
>>> __device_release_driver+0x80/0x108
>>> device_release_driver+0x2c/0x40
>>> pci_stop_bus_device+0xa0/0xb0
>>> pci_stop_bus_device+0x3c/0xb0
>>> pci_stop_root_bus+0x54/0x80
>>> acpi_pci_root_remove+0x28/0x64
>>> acpi_bus_trim+0x6c/0xa4
>>> acpi_device_hotplug+0x19c/0x3f4
>>> acpi_hotplug_work_fn+0x28/0x3c
>>> process_one_work+0x150/0x460
>>> worker_thread+0x50/0x4b8
>>> kthread+0xd4/0xe8
>>> ret_from_fork+0x10/0x50
>>>
>>> Thanks,
>>> Tyler
>>>
>> Hello Tyler,
>> Okay, we need consult more about this suggestion.
>> May I ask what is setup you run? Is there NIC or on board LAN? I would
>> like try reproduce this issue in our lab's too.
>> Also, is same issue observed with same scenario and others NIC's too?
>> Sasha
>> _______________________________________________
>> Intel-wired-lan mailing list
>> Intel-wired-lan@lists.osuosl.org
>> http://lists.osuosl.org/mailman/listinfo/intel-wired-lan
>>
> Please, specify what is device used.
Hello Sasha,
This was on a QDF2432 using an Intel PRO/1000 PT Dual Port server
adapter. I have not tried
other e1000e PCIe cards, but have not seen any similar issues with
Mellanox cards. I'm able to
reproduce it with just pulling the card out. Here is the lspci -vvv
output for this card:
0004:00:00.0 PCI bridge: Airgo Networks, Inc. Device 0400 (prog-if 00
[Normal decode])
Physical Slot: 5
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 297
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 00002000-00002fff
Memory behind bridge: 00100000-002fffff
Prefetchable memory behind bridge:
00000c0400000000-00000c04001fffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [40] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0+,D1-,D2-,D3hot+,D3cold-)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: 00000000397f0040 Data: 0000
Capabilities: [70] Express (v2) Root Port (Slot+), MSI 00
DevCap: MaxPayload 512 bytes, PhantFunc 0
ExtTag- RBE+
DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+
Unsupported+
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
MaxPayload 256 bytes, MaxReadReq 512 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq-
AuxPwr- TransPend-
LnkCap: Port #0, Speed 5GT/s, Width x8, ASPM L0s L1,
Exit Latency L0s <1us, L1 <16us
ClockPM- Surprise- LLActRep+ BwNot+ ASPMOptComp+
LnkCtl: ASPM Disabled; RCB 128 bytes Disabled- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x4, TrErr- Train- SlotClk+
DLActive+ BWMgmt- ABWMgmt-
SltCap: AttnBtn+ PwrCtrl+ MRL+ AttnInd+ PwrInd+
HotPlug+ Surprise+
Slot #5, PowerLimit 75.000W; Interlock+ NoCompl-
SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt-
HPIrq- LinkChg-
Control: AttnInd Off, PwrInd Off, Power- Interlock-
SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt-
PresDet- Interlock-
Changed: MRL- PresDet- LinkState-
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal-
PMEIntEna+ CRSVisible-
RootCap: CRSVisible-
RootSta: PME ReqID 0000, PMEStatus- PMEPending-
DevCap2: Completion Timeout: Range ABCD, TimeoutDis+,
LTR+, OBFF Not Supported ARIFwd+
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-,
LTR-, OBFF Disabled ARIFwd-
LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance-
SpeedDis-
Transmit Margin: Normal Operating Range,
EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -3.5dB,
EqualizationComplete-, EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-,
LinkEqualizationRequest-
Capabilities: [100 v2] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt-
UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt-
UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt-
UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout-
NonFatalErr-
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout-
NonFatalErr+
AERCap: First Error Pointer: 00, GenCap+ CGenEn+
ChkCap+ ChkEn+
Capabilities: [178 v1] #19
Kernel driver in use: pcieport
0004:01:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit
Ethernet Controller (rev 06)
Subsystem: Intel Corporation PRO/1000 PT Dual Port Server Adapter
Physical Slot: 5-1
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 128 bytes
Interrupt: pin A routed to IRQ 299
Region 0: Memory at c0100100000 (32-bit, non-prefetchable)
[size=128K]
Region 1: Memory at c0100120000 (32-bit, non-prefetchable)
[size=128K]
Region 2: I/O ports at 1000 [size=32]
Expansion ROM at c0100140000 [disabled] [size=128K]
Capabilities: [c8] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: 00000000397f0040 Data: 0000
Capabilities: [e0] Express (v1) Endpoint, MSI 00
DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s
<512ns, L1 <64us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset-
DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+
Unsupported+
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
MaxPayload 256 bytes, MaxReadReq 512 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq-
AuxPwr+ TransPend-
LnkCap: Port #8, Speed 2.5GT/s, Width x4, ASPM L0s,
Exit Latency L0s <4us, L1 <64us
ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x4, TrErr- Train- SlotClk+
DLActive- BWMgmt- ABWMgmt-
Capabilities: [100 v1] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt-
UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq+ ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt-
UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt-
UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout-
NonFatalErr-
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout-
NonFatalErr-
AERCap: First Error Pointer: 14, GenCap- CGenEn-
ChkCap- ChkEn-
Capabilities: [140 v1] Device Serial Number 68-05-ca-ff-ff-3e-5b-7a
Kernel driver in use: e1000e
0004:01:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit
Ethernet Controller (rev 06)
Subsystem: Intel Corporation PRO/1000 PT Dual Port Server Adapter
Physical Slot: 5-1
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 128 bytes
Interrupt: pin B routed to IRQ 301
Region 0: Memory at c0100160000 (32-bit, non-prefetchable)
[size=128K]
Region 1: Memory at c0100180000 (32-bit, non-prefetchable)
[size=128K]
Region 2: I/O ports at 1020 [size=32]
Expansion ROM at c01001a0000 [disabled] [size=128K]
Capabilities: [c8] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: 00000000397f0040 Data: 0000
Capabilities: [e0] Express (v1) Endpoint, MSI 00
DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s
<512ns, L1 <64us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset-
DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+
Unsupported+
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
MaxPayload 256 bytes, MaxReadReq 512 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq-
AuxPwr+ TransPend-
LnkCap: Port #8, Speed 2.5GT/s, Width x4, ASPM L0s,
Exit Latency L0s <4us, L1 <64us
ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x4, TrErr- Train- SlotClk+
DLActive- BWMgmt- ABWMgmt-
Capabilities: [100 v1] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt-
UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq+ ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt-
UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt-
UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout-
NonFatalErr-
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout-
NonFatalErr-
AERCap: First Error Pointer: 14, GenCap- CGenEn-
ChkCap- ChkEn-
Capabilities: [140 v1] Device Serial Number 68-05-ca-ff-ff-3e-5b-7a
Kernel driver in use: e1000e
Thanks,
Tyler
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
^ permalink raw reply
* Re: [PATCH net-next] bpf: Fix compilation warning in __bpf_lru_list_rotate_inactive
From: Alexei Starovoitov @ 2016-11-15 21:44 UTC (permalink / raw)
To: Martin KaFai Lau
Cc: netdev, David Miller, Alexei Starovoitov, Daniel Borkmann,
Kernel Team
In-Reply-To: <1479236404-3906780-1-git-send-email-kafai@fb.com>
On Tue, Nov 15, 2016 at 11:00:04AM -0800, Martin KaFai Lau wrote:
> gcc-6.2.1 gives the following warning:
> kernel/bpf/bpf_lru_list.c: In function ‘__bpf_lru_list_rotate_inactive.isra.3’:
> kernel/bpf/bpf_lru_list.c:201:28: warning: ‘next’ may be used uninitialized in this function [-Wmaybe-uninitialized]
>
> The "next" is currently initialized in the while() loop which must have >=1
> iterations.
>
> This patch initializes next to get rid of the compiler warning.
>
> Fixes: 3a08c2fd7634 ("bpf: LRU List")
> Reported-by: David Miller <davem@davemloft.net>
> Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
^ permalink raw reply
* Re: [PATCH 00/15] net: phy: Centralize auto-negotation restart
From: David Miller @ 2016-11-15 21:33 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, andrew, tremyfr
In-Reply-To: <20161115180644.3941-1-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Tue, 15 Nov 2016 10:06:29 -0800
> This patch series centralizes how ethtool::nway_reset is implemented
> by providing a PHYLIB function which calls into genphy_restart_aneg().
>
> All drivers below are converted to use this new helper function. Some
> other have specific requirements that make them not quite suitable for
> a straight forward conversion.
>
> There is another patch series which implements ethtool::nway_reset
> using the helper function introduced that depends on this patch
> series.
Series applied, thanks Florian.
^ permalink raw reply
* [PATCH net-next 4/8] net/mlx5e: Add port module event counters to ethtool stats
From: Saeed Mahameed @ 2016-11-15 21:30 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Huy Nguyen, Saeed Mahameed
In-Reply-To: <1479245407-6884-1-git-send-email-saeedm@mellanox.com>
From: Huy Nguyen <huyn@mellanox.com>
Add port module event counters to ethtool -S command
Signed-off-by: Huy Nguyen <huyn@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
.../net/ethernet/mellanox/mlx5/core/en_ethtool.c | 23 +++++++++++++++++++++-
drivers/net/ethernet/mellanox/mlx5/core/en_stats.h | 17 ++++++++++++++++
2 files changed, 39 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c b/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c
index 27ff401..b154621 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c
@@ -173,7 +173,10 @@ static int mlx5e_get_sset_count(struct net_device *dev, int sset)
NUM_VPORT_COUNTERS + NUM_PPORT_COUNTERS +
MLX5E_NUM_RQ_STATS(priv) +
MLX5E_NUM_SQ_STATS(priv) +
- MLX5E_NUM_PFC_COUNTERS(priv);
+ MLX5E_NUM_PFC_COUNTERS(priv) +
+ ARRAY_SIZE(mlx5e_pme_status_desc) +
+ ARRAY_SIZE(mlx5e_pme_error_desc);
+
case ETH_SS_PRIV_FLAGS:
return ARRAY_SIZE(mlx5e_priv_flags);
/* fallthrough */
@@ -237,6 +240,13 @@ static void mlx5e_fill_stats_strings(struct mlx5e_priv *priv, uint8_t *data)
}
}
+ /* port module event counters */
+ for (i = 0; i < ARRAY_SIZE(mlx5e_pme_status_desc); i++)
+ strcpy(data + (idx++) * ETH_GSTRING_LEN, mlx5e_pme_status_desc[i].format);
+
+ for (i = 0; i < ARRAY_SIZE(mlx5e_pme_error_desc); i++)
+ strcpy(data + (idx++) * ETH_GSTRING_LEN, mlx5e_pme_error_desc[i].format);
+
if (!test_bit(MLX5E_STATE_OPENED, &priv->state))
return;
@@ -279,6 +289,7 @@ static void mlx5e_get_ethtool_stats(struct net_device *dev,
struct ethtool_stats *stats, u64 *data)
{
struct mlx5e_priv *priv = netdev_priv(dev);
+ struct mlx5_priv *mlx5_priv;
int i, j, tc, prio, idx = 0;
unsigned long pfc_combined;
@@ -335,6 +346,16 @@ static void mlx5e_get_ethtool_stats(struct net_device *dev,
}
}
+ /* port module event counters */
+ mlx5_priv = &priv->mdev->priv;
+ for (i = 0; i < ARRAY_SIZE(mlx5e_pme_status_desc); i++)
+ data[idx++] = MLX5E_READ_CTR64_CPU(mlx5_priv->pme_stats.status_counters,
+ mlx5e_pme_status_desc, i);
+
+ for (i = 0; i < ARRAY_SIZE(mlx5e_pme_error_desc); i++)
+ data[idx++] = MLX5E_READ_CTR64_CPU(mlx5_priv->pme_stats.error_counters,
+ mlx5e_pme_error_desc, i);
+
if (!test_bit(MLX5E_STATE_OPENED, &priv->state))
return;
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_stats.h b/drivers/net/ethernet/mellanox/mlx5/core/en_stats.h
index 57452fd..b817e51 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_stats.h
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_stats.h
@@ -379,4 +379,21 @@ struct mlx5e_stats {
struct mlx5e_pport_stats pport;
};
+static const struct counter_desc mlx5e_pme_status_desc[] = {
+ { "module_plug", 0 },
+ { "module_unplug", 8 },
+};
+
+static const struct counter_desc mlx5e_pme_error_desc[] = {
+ { "module_pwr_budget_exd", 0 }, /* power budget exceed */
+ { "module_long_range", 8 }, /* long range for non MLNX cable */
+ { "module_bus_stuck", 16 }, /* bus stuck (I2C or data shorted) */
+ { "module_no_eeprom", 24 }, /* no eeprom/retry time out */
+ { "module_enforce_part", 32 }, /* enforce part number list */
+ { "module_unknown_id", 40 }, /* unknown identifier */
+ { "module_high_temp", 48 }, /* high temperature */
+ { "module_bad_shorted", 56 }, /* bad or shorted cable/module */
+ { "module_unknown_status", 64 },
+};
+
#endif /* __MLX5_EN_STATS_H__ */
--
2.7.4
^ permalink raw reply related
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