* Re: [PATCH v2 2/2] stmmac: rename it to synopsys
From: Florian Fainelli @ 2017-01-11 21:14 UTC (permalink / raw)
To: Joao Pinto, davem
Cc: lars.persson, niklass, peppe.cavallaro, alexandre.torgue, netdev
In-Reply-To: <c74e6665ca14a4ca03b38cd3442ef0644d9e250d.1484059674.git.jpinto@synopsys.com>
On 01/10/2017 06:52 AM, Joao Pinto wrote:
> This patch renames stmicro/stmmac to synopsys/ since it is a standard
> ethernet software package regarding synopsys ethernet controllers, supporting
> the majority of Synopsys Ethernet IPs. The config IDs remain the same, for
> retro-compatibility, only the description was changed.
Do re really have to do this? ST Micro were the first to upstream
support for a Synopsys IP, and it was later on identified as being
"stmicro" instead of "synopsys" (during the big driver move under
drivers/net/ethernet) whichever came first in the driver essentially "wins".
As mentioned before, although git is able to track renames, git log does
not automatically have --follow, so it can be hard for people to track
down the (new) history of the driver.
Personally, I don't see much value in doing this rename, especially when
all the driver internal structures are still going to be named with
stmmac (and please don't even think about doing a s/stmmac/snps/ inside
the driver ;)).
My 2 cents.
--
Florian
^ permalink raw reply
* [PATCH] [net] net/mlx5e: fix another -Wmaybe-uninitialized warning
From: Arnd Bergmann @ 2017-01-11 21:14 UTC (permalink / raw)
To: Saeed Mahameed, Hadar Hen Zion
Cc: Or Gerlitz, David S . Miller, netdev, linux-kernel, Arnd Bergmann
As found by Olof's build bot, today's mainline kernel gained a harmless
warning about a potential uninitalied variable reference:
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c: In function 'parse_tc_fdb_actions':
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c:769:13: warning: 'out_dev' may be used uninitialized in this function [-Wmaybe-uninitialized]
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c:811:21: note: 'out_dev' was declared here
This was introduced through the addition of an 'IS_ERR/PTR_ERR' pair that
gcc is unfortunately unable to completely figure out. Replacing it with
PTR_ERR_OR_ZERO makes the code more understandable to gcc so it no longer
warns.
Hadar Hen Zion already attempted to fix the warning earlier by adding
fake initializations, but that ended up just making the code worse without
fully addressing all warnings, so I'm reverting it now that it is no longer
needed.
In order to avoid pulling a variable declaration into the #ifdef, I'm
removing it in favor of a more readable 'if()' statement here that
has the same effect.
Link: http://arm-soc.lixom.net/buildlogs/mainline/v4.10-rc3-98-gcff3b2c/
Fixes: a42485eb0ee4 ("net/mlx5e: TC ipv4 tunnel encap offload error flow fixes")
Fixes: a757d108dc1a ("net/mlx5e: Fix kbuild warnings for uninitialized parameters")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 17 +++++++++--------
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
index 118cea5..07d83835 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
@@ -666,14 +666,15 @@ static int mlx5e_route_lookup_ipv4(struct mlx5e_priv *priv,
struct rtable *rt;
struct neighbour *n = NULL;
int ttl;
+ int ret;
+
+ if (!IS_ENABLED(CONFIG_INET))
+ return -EOPNOTSUPP;
-#if IS_ENABLED(CONFIG_INET)
rt = ip_route_output_key(dev_net(mirred_dev), fl4);
- if (IS_ERR(rt))
- return PTR_ERR(rt);
-#else
- return -EOPNOTSUPP;
-#endif
+ ret = PTR_ERR_OR_ZERO(rt);
+ if (ret)
+ return ret;
if (!switchdev_port_same_parent_id(priv->netdev, rt->dst.dev)) {
pr_warn("%s: can't offload, devices not on same HW e-switch\n", __func__);
@@ -741,8 +742,8 @@ static int mlx5e_create_encap_header_ipv4(struct mlx5e_priv *priv,
struct flowi4 fl4 = {};
char *encap_header;
int encap_size;
- __be32 saddr = 0;
- int ttl = 0;
+ __be32 saddr;
+ int ttl;
int err;
encap_header = kzalloc(max_encap_size, GFP_KERNEL);
--
2.9.0
^ permalink raw reply related
* Re: TCP using IPv4-mapped IPv6 address as source
From: Jonathan T. Leighton @ 2017-01-11 21:26 UTC (permalink / raw)
To: Eric Dumazet, Sowmini Varadhan
Cc: netdev, edumazet, Yuchung Cheng, Neal Cardwell
In-Reply-To: <1484167422.15816.1.camel@edumazet-glaptop3.roam.corp.google.com>
On 1/11/17 3:43 PM, Eric Dumazet wrote:
> On Wed, 2017-01-11 at 14:59 -0500, Sowmini Varadhan wrote:
>
>> I think the RFC states somewhere that you should never ever
>> send out a v4 mapped address on the wire.
> Can you point the exact RFC ?
>
> https://tools.ietf.org/html/rfc2765 seems to allow just that.
Link was in my original post. See table 20:
https://tools.ietf.org/html/rfc6890#page-14
> Jonathan issue is about terminating such flows in TCP stack, which is
> likely not needed/useful.
I'm sure I understand what you're saying here. There should be no flow
to terminate.
>
>
>
>
^ permalink raw reply
* Re: [PATCH net v2] netvsc: add rcu_read locking to netvsc callback
From: David Miller @ 2017-01-11 21:31 UTC (permalink / raw)
To: stephen; +Cc: netdev, sthemmin
In-Reply-To: <20170111171632.31241-1-sthemmin@microsoft.com>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Wed, 11 Jan 2017 09:16:32 -0800
> The receive callback (in tasklet context) is using RCU to get reference
> to associated VF network device but this is not safe. RCU read lock
> needs to be held. Found by running with full lockdep debugging
> enabled.
>
> Fixes: f207c10d9823 ("hv_netvsc: use RCU to protect vf_netdev")
> Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
> ---
> v2 - fix commit message
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH v2 2/2] stmmac: rename it to synopsys
From: David Miller @ 2017-01-11 21:32 UTC (permalink / raw)
To: f.fainelli
Cc: Joao.Pinto, lars.persson, niklass, peppe.cavallaro,
alexandre.torgue, netdev
In-Reply-To: <5b5a3231-eed4-ef29-b32a-a19077681dad@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Wed, 11 Jan 2017 13:14:32 -0800
> As mentioned before, although git is able to track renames, git log does
> not automatically have --follow, so it can be hard for people to track
> down the (new) history of the driver.
>
> Personally, I don't see much value in doing this rename, especially when
> all the driver internal structures are still going to be named with
> stmmac (and please don't even think about doing a s/stmmac/snps/ inside
> the driver ;)).
I agree, this could really make long term maintainence and bug fix
backporting a nightmare for a lot of people.
Please strongly reconsider, I still don't see any true value in this
rename.
^ permalink raw reply
* Re: TCP using IPv4-mapped IPv6 address as source
From: Eric Dumazet @ 2017-01-11 21:47 UTC (permalink / raw)
To: Jonathan T. Leighton
Cc: Sowmini Varadhan, netdev, edumazet, Yuchung Cheng, Neal Cardwell
In-Reply-To: <0d48793d-81f1-3666-5c47-9c2431198dc1@udel.edu>
On Wed, 2017-01-11 at 16:26 -0500, Jonathan T. Leighton wrote:
> I'm sure I understand what you're saying here. There should be no flow
> to terminate.
rfc2765 describes a way to use IPv4-mapped IPv6 packets on the wire.
What I meant by 'terminating' was that it does not tell if an end system
(a host) is allowed to natively generate these packets.
Anyway,
https://tools.ietf.org/html/draft-itojun-v6ops-v4mapped-harmful-00
(which does not appear to be an RFC), tells us this would be
dangerous ;)
^ permalink raw reply
* Re: [PATCH v2 01/13] net: ethernet: aquantia: Make and configuration files.
From: Rami Rosen @ 2017-01-11 22:05 UTC (permalink / raw)
To: Alexander Loktionov
Cc: Netdev, David VomLehn, Simon Edelhaus, Dmitrii Tarakanov,
Pavel Belous
In-Reply-To: <0b0d8974bdbfa66ab3bc4460f32f7916dd54b85a.1483999588.git.vomlehn@texas.net>
Hi,
> +++ b/drivers/net/ethernet/aquantia/Makefile
> @@ -0,0 +1,44 @@
...
...
> > +obj-$(CONFIG_AQTION) += atlantic.o
> +
> +atlantic-objs := aq_main.o \
> + aq_nic.o \
> + aq_pci_func.o \
Why twice aq_nic.o ? it appears two lines earlier:
> + aq_nic.o \
> + aq_vec.o \
> + aq_ring.o \
...
...
Regards,
Rami Rosen
^ permalink raw reply
* RE: Marvell Phy (1510) issue since v4.7 kernel
From: Kwok, WingMan @ 2017-01-11 22:18 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Karicheri, Muralidharan, netdev@vger.kernel.org
In-Reply-To: <20170110015336.GA7160@lunn.ch>
> -----Original Message-----
> From: Andrew Lunn [mailto:andrew@lunn.ch]
> Sent: Monday, January 09, 2017 8:54 PM
> To: Kwok, WingMan
> Cc: Karicheri, Muralidharan; netdev@vger.kernel.org
> Subject: Re: Marvell Phy (1510) issue since v4.7 kernel
>
> > From Marvell's brief description
> http://www.marvell.com/transceivers/alaska-gbe/,
> > it seems that 88E1510/1518 don't support fiber. Only 88E1512 does.
> In
> > that case, the fiber support patch is not applicable to
> 88E1510/1518.
>
> O.K. That makes it easier.
>
> Please add the relevant IDs to include/linux/marvell.h, and add
> entries to driver/net/phy/marvell.c for 1512 with SUPPORTED_FIBRE and
> 1510 and 1518 without.
>
> Andrew
By any chance you have the ID of 1512?
Thanks,
WingMan
^ permalink raw reply
* Re: Marvell Phy (1510) issue since v4.7 kernel
From: Andrew Lunn @ 2017-01-11 22:27 UTC (permalink / raw)
To: Kwok, WingMan; +Cc: Karicheri, Muralidharan, netdev@vger.kernel.org
In-Reply-To: <230CBA6E4B6B6B418E8730AC28E6FC7E15354AC2@DFLE11.ent.ti.com>
On Wed, Jan 11, 2017 at 10:18:02PM +0000, Kwok, WingMan wrote:
>
>
> > -----Original Message-----
> > From: Andrew Lunn [mailto:andrew@lunn.ch]
> > Sent: Monday, January 09, 2017 8:54 PM
> > To: Kwok, WingMan
> > Cc: Karicheri, Muralidharan; netdev@vger.kernel.org
> > Subject: Re: Marvell Phy (1510) issue since v4.7 kernel
> >
> > > From Marvell's brief description
> > http://www.marvell.com/transceivers/alaska-gbe/,
> > > it seems that 88E1510/1518 don't support fiber. Only 88E1512 does.
> > In
> > > that case, the fiber support patch is not applicable to
> > 88E1510/1518.
> >
> > O.K. That makes it easier.
> >
> > Please add the relevant IDs to include/linux/marvell.h, and add
> > entries to driver/net/phy/marvell.c for 1512 with SUPPORTED_FIBRE and
> > 1510 and 1518 without.
> >
> > Andrew
>
> By any chance you have the ID of 1512?
Nope, sorry.
Try Russell King.
Andrew
^ permalink raw reply
* [PATCH] net: lwtunnel: Handle lwtunnel_fill_encap failure
From: David Ahern @ 2017-01-11 22:29 UTC (permalink / raw)
To: netdev; +Cc: roopa, David Ahern
Handle failure in lwtunnel_fill_encap adding attributes to skb.
Fixes: 571e722676fe ("ipv4: support for fib route lwtunnel encap attributes")
Fixes: 19e42e451506 ("ipv6: support for fib route lwtunnel encap attributes")
Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
---
net/ipv4/fib_semantics.c | 11 +++++++----
net/ipv6/route.c | 3 ++-
2 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/net/ipv4/fib_semantics.c b/net/ipv4/fib_semantics.c
index eba1546b5031..9a375b908d01 100644
--- a/net/ipv4/fib_semantics.c
+++ b/net/ipv4/fib_semantics.c
@@ -1279,8 +1279,9 @@ int fib_dump_info(struct sk_buff *skb, u32 portid, u32 seq, int event,
nla_put_u32(skb, RTA_FLOW, fi->fib_nh[0].nh_tclassid))
goto nla_put_failure;
#endif
- if (fi->fib_nh->nh_lwtstate)
- lwtunnel_fill_encap(skb, fi->fib_nh->nh_lwtstate);
+ if (fi->fib_nh->nh_lwtstate &&
+ lwtunnel_fill_encap(skb, fi->fib_nh->nh_lwtstate) < 0)
+ goto nla_put_failure;
}
#ifdef CONFIG_IP_ROUTE_MULTIPATH
if (fi->fib_nhs > 1) {
@@ -1316,8 +1317,10 @@ int fib_dump_info(struct sk_buff *skb, u32 portid, u32 seq, int event,
nla_put_u32(skb, RTA_FLOW, nh->nh_tclassid))
goto nla_put_failure;
#endif
- if (nh->nh_lwtstate)
- lwtunnel_fill_encap(skb, nh->nh_lwtstate);
+ if (nh->nh_lwtstate &&
+ lwtunnel_fill_encap(skb, nh->nh_lwtstate) < 0)
+ goto nla_put_failure;
+
/* length of rtnetlink header + attributes */
rtnh->rtnh_len = nlmsg_get_pos(skb) - (void *) rtnh;
} endfor_nexthops(fi);
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index ce5aaf448c54..4f6b067c8753 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -3317,7 +3317,8 @@ static int rt6_fill_node(struct net *net,
if (nla_put_u8(skb, RTA_PREF, IPV6_EXTRACT_PREF(rt->rt6i_flags)))
goto nla_put_failure;
- lwtunnel_fill_encap(skb, rt->dst.lwtstate);
+ if (lwtunnel_fill_encap(skb, rt->dst.lwtstate) < 0)
+ goto nla_put_failure;
nlmsg_end(skb, nlh);
return 0;
--
2.1.4
^ permalink raw reply related
* RE: Marvell Phy (1510) issue since v4.7 kernel
From: Kwok, WingMan @ 2017-01-11 22:32 UTC (permalink / raw)
To: Andrew Lunn, rmk+kernel@arm.linux.org.uk
Cc: Karicheri, Muralidharan, netdev@vger.kernel.org
In-Reply-To: <20170111222758.GG13033@lunn.ch>
> -----Original Message-----
> From: Andrew Lunn [mailto:andrew@lunn.ch]
> Sent: Wednesday, January 11, 2017 5:28 PM
> To: Kwok, WingMan
> Cc: Karicheri, Muralidharan; netdev@vger.kernel.org
> Subject: Re: Marvell Phy (1510) issue since v4.7 kernel
>
> On Wed, Jan 11, 2017 at 10:18:02PM +0000, Kwok, WingMan wrote:
> >
> >
> > > -----Original Message-----
> > > From: Andrew Lunn [mailto:andrew@lunn.ch]
> > > Sent: Monday, January 09, 2017 8:54 PM
> > > To: Kwok, WingMan
> > > Cc: Karicheri, Muralidharan; netdev@vger.kernel.org
> > > Subject: Re: Marvell Phy (1510) issue since v4.7 kernel
> > >
> > > > From Marvell's brief description
> > > http://www.marvell.com/transceivers/alaska-gbe/,
> > > > it seems that 88E1510/1518 don't support fiber. Only 88E1512
> does.
> > > In
> > > > that case, the fiber support patch is not applicable to
> > > 88E1510/1518.
> > >
> > > O.K. That makes it easier.
> > >
> > > Please add the relevant IDs to include/linux/marvell.h, and add
> > > entries to driver/net/phy/marvell.c for 1512 with SUPPORTED_FIBRE
> and
> > > 1510 and 1518 without.
> > >
> > > Andrew
> >
> > By any chance you have the ID of 1512?
>
> Nope, sorry.
>
> Try Russell King.
>
> Andrew
Russell,
Do you have the ID of Marvell PHY 88E1512?
Thanks,
WingMan
^ permalink raw reply
* [PATCH] [v2] net: qcom/emac: grab a reference to the phydev on ACPI systems
From: Timur Tabi @ 2017-01-11 22:45 UTC (permalink / raw)
To: David Miller, netdev, johan
Commit 6ffe1c4cd0a7 ("net: qcom/emac: fix of_node and phydev leaks")
fixed the problem with reference leaks on phydev, but the fix is
device-tree specific. When the driver unloads, the reference is
dropped only on DT systems.
Instead, it's cleaner if up grab an reference on ACPI systems.
When the driver unloads, we can drop the reference without having
to check whether we're on a DT system.
Signed-off-by: Timur Tabi <timur@codeaurora.org>
---
Notes:
v2: add check for null pointer
drivers/net/ethernet/qualcomm/emac/emac-phy.c | 7 +++++++
drivers/net/ethernet/qualcomm/emac/emac.c | 6 ++----
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/qualcomm/emac/emac-phy.c b/drivers/net/ethernet/qualcomm/emac/emac-phy.c
index 99a14df..2851b4c 100644
--- a/drivers/net/ethernet/qualcomm/emac/emac-phy.c
+++ b/drivers/net/ethernet/qualcomm/emac/emac-phy.c
@@ -201,6 +201,13 @@ int emac_phy_config(struct platform_device *pdev, struct emac_adapter *adpt)
else
adpt->phydev = mdiobus_get_phy(mii_bus, phy_addr);
+ /* of_phy_find_device() claims a reference to the phydev,
+ * so we do that here manually as well. When the driver
+ * later unloads, it can unilaterally drop the reference
+ * without worrying about ACPI vs DT.
+ */
+ if (adpt->phydev)
+ get_device(&adpt->phydev->mdio.dev);
} else {
struct device_node *phy_np;
diff --git a/drivers/net/ethernet/qualcomm/emac/emac.c b/drivers/net/ethernet/qualcomm/emac/emac.c
index 6ffe192..0aac0de 100644
--- a/drivers/net/ethernet/qualcomm/emac/emac.c
+++ b/drivers/net/ethernet/qualcomm/emac/emac.c
@@ -729,8 +729,7 @@ static int emac_probe(struct platform_device *pdev)
err_undo_napi:
netif_napi_del(&adpt->rx_q.napi);
err_undo_mdiobus:
- if (!has_acpi_companion(&pdev->dev))
- put_device(&adpt->phydev->mdio.dev);
+ put_device(&adpt->phydev->mdio.dev);
mdiobus_unregister(adpt->mii_bus);
err_undo_clocks:
emac_clks_teardown(adpt);
@@ -750,8 +749,7 @@ static int emac_remove(struct platform_device *pdev)
emac_clks_teardown(adpt);
- if (!has_acpi_companion(&pdev->dev))
- put_device(&adpt->phydev->mdio.dev);
+ put_device(&adpt->phydev->mdio.dev);
mdiobus_unregister(adpt->mii_bus);
free_netdev(netdev);
--
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 related
* [PATCH] tilepro: Fix non-void return from void function
From: Joe Perches @ 2017-01-11 22:52 UTC (permalink / raw)
To: Chris Metcalf; +Cc: stephen hemminger, netdev, linux-kernel
commit bc1f44709cf2 ("net: make ndo_get_stats64 a void function")
mistakenly used a return value for this void conversion.
Fix it.
Signed-off-by: Joe Perches <joe@perches.com>
cc: stephen hemminger <stephen@networkplumber.org>
---
drivers/net/ethernet/tile/tilepro.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/net/ethernet/tile/tilepro.c b/drivers/net/ethernet/tile/tilepro.c
index 30cfea62a356..44f153713791 100644
--- a/drivers/net/ethernet/tile/tilepro.c
+++ b/drivers/net/ethernet/tile/tilepro.c
@@ -2090,12 +2090,8 @@ static void tile_net_get_stats64(struct net_device *dev,
stats->tx_bytes = tx_bytes;
stats->rx_errors = rx_errors;
stats->rx_dropped = rx_dropped;
-
- return stats;
}
-
-
/*
* Change the Ethernet Address of the NIC.
*
--
2.10.0.rc2.1.g053435c
^ permalink raw reply related
* Re: Marvell Phy (1510) issue since v4.7 kernel
From: Andrew Lunn @ 2017-01-11 22:59 UTC (permalink / raw)
To: Kwok, WingMan
Cc: rmk+kernel@arm.linux.org.uk, charles-antoine.couret@nexvision.fr,
Karicheri, Muralidharan, netdev@vger.kernel.org
In-Reply-To: <230CBA6E4B6B6B418E8730AC28E6FC7E15354AE5@DFLE11.ent.ti.com>
> looping in Charles-Antoine (author of patch
> with commit id 6cfb3bcc)
>
> Charles-Antoine,
>
> Do you have the ID of Marvell PHY 88E1512?
I suspect that is the wrong question to ask.
The Marvell driver is being loaded, so it must be using on of the IDs
in the driver. There is no ID in the driver specifically for the
88E1512. It seems like the 88E1512 uses the 88E1510 ID.
So i think the correct question should be, how can we tell the 88E1512
from the 88E1510 if they have the same ID in register 3.
It appears that for the 88E1512, page 0 are the copper registers and
page 1 is the fibre registers. Maybe the 88E1512 has an ID in page 1
register 3? Maybe the 88E1510 does not have an ID in page 1 register
3?
Andrew
^ permalink raw reply
* RE: Marvell Phy (1510) issue since v4.7 kernel
From: Kwok, WingMan @ 2017-01-11 23:09 UTC (permalink / raw)
To: Andrew Lunn
Cc: rmk+kernel@arm.linux.org.uk, charles-antoine.couret@nexvision.fr,
Karicheri, Muralidharan, netdev@vger.kernel.org
In-Reply-To: <20170111225948.GH13033@lunn.ch>
> -----Original Message-----
> From: Andrew Lunn [mailto:andrew@lunn.ch]
> Sent: Wednesday, January 11, 2017 6:00 PM
> To: Kwok, WingMan
> Cc: rmk+kernel@arm.linux.org.uk; charles-antoine.couret@nexvision.fr;
> Karicheri, Muralidharan; netdev@vger.kernel.org
> Subject: Re: Marvell Phy (1510) issue since v4.7 kernel
>
> > looping in Charles-Antoine (author of patch
> > with commit id 6cfb3bcc)
> >
> > Charles-Antoine,
> >
> > Do you have the ID of Marvell PHY 88E1512?
>
> I suspect that is the wrong question to ask.
>
> The Marvell driver is being loaded, so it must be using on of the IDs
> in the driver. There is no ID in the driver specifically for the
> 88E1512. It seems like the 88E1512 uses the 88E1510 ID.
>
> So i think the correct question should be, how can we tell the 88E1512
> from the 88E1510 if they have the same ID in register 3.
>
> It appears that for the 88E1512, page 0 are the copper registers and
> page 1 is the fibre registers. Maybe the 88E1512 has an ID in page 1
> register 3? Maybe the 88E1510 does not have an ID in page 1 register
> 3?
>
> Andrew
Andrew,
Would Charles-Antoine be the better person to submit a patch
to fix the original problem then, since he tested the original
fiber support patch with 1512? I unfortunately don't have the
datasheet for 1512, and it does not seem to be available publicly.
Regards,
WingMan
^ permalink raw reply
* [PATCH] xen-netfront: Fix Rx stall during network stress and OOM
From: Vineeth Remanan Pillai @ 2017-01-11 23:17 UTC (permalink / raw)
To: boris.ostrovsky, jgross, xen-devel, netdev, linux-kernel
Cc: Vineeth Remanan Pillai, kamatam, aliguori
During an OOM scenario, request slots could not be created as skb
allocation fails. So the netback cannot pass in packets and netfront
wrongly assumes that there is no more work to be done and it disables
polling. This causes Rx to stall.
Fix is to consider the skb allocation failure as an error and in the
event of this error, re-enable polling so that request slots could be
created when memory is available.
Signed-off-by: Vineeth Remanan Pillai <vineethp@amazon.com>
---
drivers/net/xen-netfront.c | 23 ++++++++++++++++-------
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 40f26b6..8275549 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -277,13 +277,14 @@ static struct sk_buff *xennet_alloc_one_rx_buffer(struct netfront_queue *queue)
}
-static void xennet_alloc_rx_buffers(struct netfront_queue *queue)
+static int xennet_alloc_rx_buffers(struct netfront_queue *queue)
{
RING_IDX req_prod = queue->rx.req_prod_pvt;
int notify;
+ int err = 0;
if (unlikely(!netif_carrier_ok(queue->info->netdev)))
- return;
+ return err;
for (req_prod = queue->rx.req_prod_pvt;
req_prod - queue->rx.rsp_cons < NET_RX_RING_SIZE;
@@ -295,8 +296,10 @@ static void xennet_alloc_rx_buffers(struct netfront_queue *queue)
struct xen_netif_rx_request *req;
skb = xennet_alloc_one_rx_buffer(queue);
- if (!skb)
+ if (!skb) {
+ err = -ENOMEM;
break;
+ }
id = xennet_rxidx(req_prod);
@@ -321,9 +324,9 @@ static void xennet_alloc_rx_buffers(struct netfront_queue *queue)
queue->rx.req_prod_pvt = req_prod;
/* Not enough requests? Try again later. */
- if (req_prod - queue->rx.rsp_cons < NET_RX_SLOTS_MIN) {
+ if (req_prod - queue->rx.sring->rsp_prod < NET_RX_SLOTS_MIN) {
mod_timer(&queue->rx_refill_timer, jiffies + (HZ/10));
- return;
+ return err;
}
wmb(); /* barrier so backend seens requests */
@@ -331,6 +334,8 @@ static void xennet_alloc_rx_buffers(struct netfront_queue *queue)
RING_PUSH_REQUESTS_AND_CHECK_NOTIFY(&queue->rx, notify);
if (notify)
notify_remote_via_irq(queue->rx_irq);
+
+ return err;
}
static int xennet_open(struct net_device *dev)
@@ -1046,7 +1051,7 @@ static int xennet_poll(struct napi_struct *napi, int budget)
work_done -= handle_incoming_queue(queue, &rxq);
- xennet_alloc_rx_buffers(queue);
+ err = xennet_alloc_rx_buffers(queue);
if (work_done < budget) {
int more_to_do = 0;
@@ -1054,7 +1059,11 @@ static int xennet_poll(struct napi_struct *napi, int budget)
napi_complete(napi);
RING_FINAL_CHECK_FOR_RESPONSES(&queue->rx, more_to_do);
- if (more_to_do)
+
+ /* If there is more work to do or could not allocate
+ * rx buffers, re-enable polling.
+ */
+ if (more_to_do || err != 0)
napi_schedule(napi);
}
--
2.1.2.AMZN
^ permalink raw reply related
* Re: [net PATCH 0/2] Don't use lco_csum to compute IPv4 checksum
From: Stephen Rothwell @ 2017-01-11 23:19 UTC (permalink / raw)
To: davem
Cc: Jeff Kirsher, netdev, intel-wired-lan, Alexander Duyck,
Eric Dumazet, Eli Cooper, Lance Richardson, Sven-Haegar Koch
In-Reply-To: <20161129200708.3490344a@canb.auug.org.au>
Hi Dave,
On Tue, 29 Nov 2016 20:07:08 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi Jeff,
>
> On Tue, 29 Nov 2016 10:43:04 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > On Mon, 28 Nov 2016 14:26:02 -0800 Jeff Kirsher <jeffrey.t.kirsher@intel.com> wrote:
> > >
> > > On Mon, 2016-11-28 at 10:42 -0500, Alexander Duyck wrote:
> > > > When I implemented the GSO partial support in the Intel drivers I was
> > > > using
> > > > lco_csum to compute the checksum that we needed to plug into the IPv4
> > > > checksum field in order to cancel out the data that was not a part of the
> > > > IPv4 header. However this didn't take into account that the transport
> > > > offset might be pointing to the inner transport header.
> > > >
> > > > Instead of using lco_csum I have just coded around it so that we can use
> > > > the outer IP header plus the IP header length to determine where we need
> > > > to
> > > > start our checksum and then just call csum_partial ourselves.
> > > >
> > > > This should fix the SIT issue reported on igb interfaces as well as
> > > > simliar
> > > > issues that would pop up on other Intel NICs.
> > > >
> > > > ---
> > > >
> > > > Alexander Duyck (2):
> > > > igb/igbvf: Don't use lco_csum to compute IPv4 checksum
> > > > ixgbe/ixgbevf: Don't use lco_csum to compute IPv4 checksum
> > >
> > > Stephen, I have applied Alex's patches to my net-queue tree. Can you
> > > confirm they resolve the bug seen?
> >
> > Its a bit tricky because the origin problem only happens on my
> > production server (ozlabs.org), but I will see if I can manage to just
> > remove and reload the driver ... though, the server is running a 4.7.8
> > kernel and I am wondering how well these patches will apply?
>
> We have a winner! This fixes my problem, so I can run at full speed
> with gso and tso enabled in the sit interface and tx-gso-partial
> enabled on the underlying ethernet.
>
> Thanks to everyone for diagnosis and solution.
>
> It would be nice if this fix went into the stable kernels as well so it
> will turn up in the distro kernels eventually.
It looks like these 2 commits:
516165a1e2f2 igb/igbvf: Don't use lco_csum to compute IPv4 checksum
c54cdc316dbd ixgbe/ixgbevf: Don't use lco_csum to compute IPv4 checksum
have not been sent to stable. They fix a bug introduced in v4.7-rc1
and so need to go into 4.7 and 4.8 stable trees.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* Re: Marvell Phy (1510) issue since v4.7 kernel
From: Andrew Lunn @ 2017-01-11 23:22 UTC (permalink / raw)
To: Kwok, WingMan
Cc: rmk+kernel@arm.linux.org.uk, charles-antoine.couret@nexvision.fr,
Karicheri, Muralidharan, netdev@vger.kernel.org
In-Reply-To: <230CBA6E4B6B6B418E8730AC28E6FC7E15354B2B@DFLE11.ent.ti.com>
> > So i think the correct question should be, how can we tell the 88E1512
> > from the 88E1510 if they have the same ID in register 3.
Hi WingMan
Do you know you really have a 1510? You can see it written on the
chip?
Please can you read page 18, register 30 and let us know what value
you get.
Andrew
^ permalink raw reply
* [PATCH] net: ipv4: fix table id in getroute response
From: David Ahern @ 2017-01-11 23:42 UTC (permalink / raw)
To: netdev; +Cc: David Ahern
rtm_table is an 8-bit field while table ids are allowed up to u32. Commit
709772e6e065 ("net: Fix routing tables with id > 255 for legacy software")
added the preference to set rtm_table in dumps to RT_TABLE_COMPAT if the
table id is > 255. The table id returned on get route requests should do
the same.
Fixes: c36ba6603a11 ("net: Allow user to get table id from route lookup")
Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
---
net/ipv4/route.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 0fcac8e7a2b2..709ffe67d1de 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -2472,7 +2472,7 @@ static int rt_fill_info(struct net *net, __be32 dst, __be32 src, u32 table_id,
r->rtm_dst_len = 32;
r->rtm_src_len = 0;
r->rtm_tos = fl4->flowi4_tos;
- r->rtm_table = table_id;
+ r->rtm_table = table_id < 256 ? table_id : RT_TABLE_COMPAT;
if (nla_put_u32(skb, RTA_TABLE, table_id))
goto nla_put_failure;
r->rtm_type = rt->rt_type;
--
2.1.4
^ permalink raw reply related
* Re: TCP using IPv4-mapped IPv6 address as source
From: Jonathan T. Leighton @ 2017-01-11 23:54 UTC (permalink / raw)
To: Eric Dumazet
Cc: Sowmini Varadhan, netdev, edumazet, Yuchung Cheng, Neal Cardwell
In-Reply-To: <1484171257.15816.5.camel@edumazet-glaptop3.roam.corp.google.com>
On 1/11/17 4:47 PM, Eric Dumazet wrote:
> On Wed, 2017-01-11 at 16:26 -0500, Jonathan T. Leighton wrote:
>
>> I'm sure I understand what you're saying here. There should be no flow
>> to terminate.
I think you figured out that I meant "I'm not sure I understand...".
>> rfc2765 describes a way to use IPv4-mapped IPv6 packets on the wire.
I don't agree - I didn't read rfc2765 because it's obsolete, but the
current version does not allow the use of IPv4-mapped IPv6 addresses.
rfc2765 is obsoleted by rfc6145, and that in turn by rfc7915. rfc7915
refers to both rfc6052 and rfc6219 for descriptions of the allowable
mechanisms for translating from IPv4 to IPv6, and the mechanisms in each
of those documents preclude the use of IPv4-mapped IPv6 addresses
(::ffff:0:0/96). There's no conflict with rfc6890 (BCP153), which
explicitly precludes the use of IPv4-mapped IPv6 addresses as a source
(or destination) address.
> What I meant by 'terminating' was that it does not tell if an end system
> (a host) is allowed to natively generate these packets.
>
> Anyway,
> https://tools.ietf.org/html/draft-itojun-v6ops-v4mapped-harmful-00
>
> (which does not appear to be an RFC), tells us this would be
> dangerous ;)
>
>
>
^ permalink raw reply
* RE: Marvell Phy (1510) issue since v4.7 kernel
From: Kwok, WingMan @ 2017-01-12 0:31 UTC (permalink / raw)
To: Andrew Lunn
Cc: rmk+kernel@arm.linux.org.uk, Karicheri, Muralidharan,
netdev@vger.kernel.org
In-Reply-To: <20170111232200.GI13033@lunn.ch>
> Hi WingMan
>
> Do you know you really have a 1510? You can see it written on the
> chip?
>
> Please can you read page 18, register 30 and let us know what value
> you get.
>
> Andrew
Removed Charles-Antonie from the list since the email
address is no longer valid.
Hi Andrew,
I double checked that ours is actually a 88E1514. According
to Marvell's brief description, it seems that it does support
fiber.
Reading page 18 reg 30 returns 6.
Thanks,
WingMan
^ permalink raw reply
* Re: Marvell Phy (1510) issue since v4.7 kernel
From: Andrew Lunn @ 2017-01-12 1:06 UTC (permalink / raw)
To: Kwok, WingMan
Cc: rmk+kernel@arm.linux.org.uk, Karicheri, Muralidharan,
netdev@vger.kernel.org
In-Reply-To: <230CBA6E4B6B6B418E8730AC28E6FC7E15354B66@DFLE11.ent.ti.com>
> Hi Andrew,
>
> I double checked that ours is actually a 88E1514. According
> to Marvell's brief description, it seems that it does support
> fiber.
>
> Reading page 18 reg 30 returns 6.
O.K, that is consistent. Looking at the Marvell SDK:
phy/Include/madApiDefs.h:#define MAD_SUB_88E1510 4 /* 88E1510 */
phy/Include/madApiDefs.h:#define MAD_SUB_88E1518 5 /* 88E1518 */
phy/Include/madApiDefs.h:#define MAD_SUB_88E1512 6 /* 88E1512/88E1514 */
I took another look at the patch adding Fibre support. The
suspend/resume functions are wrong.
/* Suspend the fiber mode first */
if (!(phydev->supported & SUPPORTED_FIBRE)) {
The ! should not be there. Does removing them both fix your problem?
Andrew
^ permalink raw reply
* [PATCH net-next] liquidio: remove unnecessary code
From: Felix Manlunas @ 2017-01-12 1:09 UTC (permalink / raw)
To: davem; +Cc: netdev, raghu.vatsavayi, derek.chickles, satananda.burla
Remove code that's no longer needed. It used to serve a purpose, which was
to fix a link-related bug. For a while now, the NIC firmware has had a
more elegant fix for that bug.
Signed-off-by: Felix Manlunas <felix.manlunas@cavium.com>
Signed-off-by: Derek Chickles <derek.chickles@cavium.com>
Signed-off-by: Satanand Burla <satananda.burla@cavium.com>
---
drivers/net/ethernet/cavium/liquidio/lio_main.c | 8 +-------
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/cavium/liquidio/lio_main.c b/drivers/net/ethernet/cavium/liquidio/lio_main.c
index b8b579d..cc825d5 100644
--- a/drivers/net/ethernet/cavium/liquidio/lio_main.c
+++ b/drivers/net/ethernet/cavium/liquidio/lio_main.c
@@ -2693,13 +2693,7 @@ static int liquidio_stop(struct net_device *netdev)
lio->linfo.link.s.link_up = 0;
lio->link_changes++;
- /* Pause for a moment and wait for Octeon to flush out (to the wire) any
- * egress packets that are in-flight.
- */
- set_current_state(TASK_INTERRUPTIBLE);
- schedule_timeout(msecs_to_jiffies(100));
-
- /* Now it should be safe to tell Octeon that nic interface is down. */
+ /* Tell Octeon that nic interface is down. */
send_rx_ctrl_cmd(lio, 0);
if (OCTEON_CN23XX_PF(oct)) {
^ permalink raw reply related
* RE: Marvell Phy (1510) issue since v4.7 kernel
From: Kwok, WingMan @ 2017-01-11 22:41 UTC (permalink / raw)
To: Andrew Lunn, rmk+kernel@arm.linux.org.uk,
charles-antoine.couret@nexvision.fr
Cc: Karicheri, Muralidharan, netdev@vger.kernel.org
In-Reply-To: <20170111222758.GG13033@lunn.ch>
> -----Original Message-----
> From: Kwok, WingMan
> Sent: Wednesday, January 11, 2017 5:32 PM
> To: 'Andrew Lunn'; 'rmk+kernel@arm.linux.org.uk'
> Cc: Karicheri, Muralidharan; netdev@vger.kernel.org
> Subject: RE: Marvell Phy (1510) issue since v4.7 kernel
>
>
>
> > -----Original Message-----
> > From: Andrew Lunn [mailto:andrew@lunn.ch]
> > Sent: Wednesday, January 11, 2017 5:28 PM
> > To: Kwok, WingMan
> > Cc: Karicheri, Muralidharan; netdev@vger.kernel.org
> > Subject: Re: Marvell Phy (1510) issue since v4.7 kernel
> >
> > On Wed, Jan 11, 2017 at 10:18:02PM +0000, Kwok, WingMan wrote:
> > >
> > >
> > > > -----Original Message-----
> > > > From: Andrew Lunn [mailto:andrew@lunn.ch]
> > > > Sent: Monday, January 09, 2017 8:54 PM
> > > > To: Kwok, WingMan
> > > > Cc: Karicheri, Muralidharan; netdev@vger.kernel.org
> > > > Subject: Re: Marvell Phy (1510) issue since v4.7 kernel
> > > >
> > > > > From Marvell's brief description
> > > > http://www.marvell.com/transceivers/alaska-gbe/,
> > > > > it seems that 88E1510/1518 don't support fiber. Only 88E1512
> > does.
> > > > In
> > > > > that case, the fiber support patch is not applicable to
> > > > 88E1510/1518.
> > > >
> > > > O.K. That makes it easier.
> > > >
> > > > Please add the relevant IDs to include/linux/marvell.h, and add
> > > > entries to driver/net/phy/marvell.c for 1512 with
> SUPPORTED_FIBRE
> > and
> > > > 1510 and 1518 without.
> > > >
> > > > Andrew
> > >
> > > By any chance you have the ID of 1512?
> >
> > Nope, sorry.
> >
> > Try Russell King.
> >
> > Andrew
>
> Russell,
>
> Do you have the ID of Marvell PHY 88E1512?
>
> Thanks,
> WingMan
>
looping in Charles-Antoine (author of patch
with commit id 6cfb3bcc)
Charles-Antoine,
Do you have the ID of Marvell PHY 88E1512?
Thanks,
WingMan
^ permalink raw reply
* [PATCH net-next] liquidio VF: reduce load time of module
From: Felix Manlunas @ 2017-01-12 1:40 UTC (permalink / raw)
To: davem; +Cc: netdev, raghu.vatsavayi, derek.chickles, satananda.burla
From: Prasad Kanneganti <prasad.kanneganti@cavium.com>
Reduce the load time of the VF driver by decreasing the wait time between
iterations of the loop that polls for a mailbox response from the PF. Also
change the wait time units from jiffies to milliseconds.
Signed-off-by: Prasad Kanneganti <prasad.kanneganti@cavium.com>
Signed-off-by: Felix Manlunas <felix.manlunas@cavium.com>
Signed-off-by: Raghu Vatsavayi <raghu.vatsavayi@cavium.com>
Signed-off-by: Derek Chickles <derek.chickles@cavium.com>
Signed-off-by: Satanand Burla <satananda.burla@cavium.com>
---
drivers/net/ethernet/cavium/liquidio/octeon_mailbox.c | 5 +++--
drivers/net/ethernet/cavium/liquidio/octeon_mailbox.h | 4 ++--
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/cavium/liquidio/octeon_mailbox.c b/drivers/net/ethernet/cavium/liquidio/octeon_mailbox.c
index 73696b42..201b987 100644
--- a/drivers/net/ethernet/cavium/liquidio/octeon_mailbox.c
+++ b/drivers/net/ethernet/cavium/liquidio/octeon_mailbox.c
@@ -131,6 +131,7 @@ int octeon_mbox_write(struct octeon_device *oct,
{
struct octeon_mbox *mbox = oct->mbox[mbox_cmd->q_no];
u32 count, i, ret = OCTEON_MBOX_STATUS_SUCCESS;
+ long timeout = LIO_MBOX_WRITE_WAIT_TIME;
unsigned long flags;
spin_lock_irqsave(&mbox->lock, flags);
@@ -158,7 +159,7 @@ int octeon_mbox_write(struct octeon_device *oct,
count = 0;
while (readq(mbox->mbox_write_reg) != OCTEON_PFVFSIG) {
- schedule_timeout_uninterruptible(LIO_MBOX_WRITE_WAIT_TIME);
+ schedule_timeout_uninterruptible(timeout);
if (count++ == LIO_MBOX_WRITE_WAIT_CNT) {
ret = OCTEON_MBOX_STATUS_FAILED;
break;
@@ -171,7 +172,7 @@ int octeon_mbox_write(struct octeon_device *oct,
count = 0;
while (readq(mbox->mbox_write_reg) !=
OCTEON_PFVFACK) {
- schedule_timeout_uninterruptible(10);
+ schedule_timeout_uninterruptible(timeout);
if (count++ == LIO_MBOX_WRITE_WAIT_CNT) {
ret = OCTEON_MBOX_STATUS_FAILED;
break;
diff --git a/drivers/net/ethernet/cavium/liquidio/octeon_mailbox.h b/drivers/net/ethernet/cavium/liquidio/octeon_mailbox.h
index fe60a3e..c9376fe 100644
--- a/drivers/net/ethernet/cavium/liquidio/octeon_mailbox.h
+++ b/drivers/net/ethernet/cavium/liquidio/octeon_mailbox.h
@@ -31,8 +31,8 @@
#define OCTEON_PFVFSIG 0x1122334455667788
#define OCTEON_PFVFERR 0xDEADDEADDEADDEAD
-#define LIO_MBOX_WRITE_WAIT_CNT 1000
-#define LIO_MBOX_WRITE_WAIT_TIME 10
+#define LIO_MBOX_WRITE_WAIT_CNT 1000
+#define LIO_MBOX_WRITE_WAIT_TIME msecs_to_jiffies(1)
enum octeon_mbox_cmd_status {
OCTEON_MBOX_STATUS_SUCCESS = 0,
^ 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