* Re: [PATCH net 0/4] s390/qeth: fixes 2017-12-13
From: David Miller @ 2017-12-15 16:31 UTC (permalink / raw)
To: jwi; +Cc: netdev, linux-s390, schwidefsky, heiko.carstens, raspl, ubraun
In-Reply-To: <20171213175632.100561-1-jwi@linux.vnet.ibm.com>
From: Julian Wiedmann <jwi@linux.vnet.ibm.com>
Date: Wed, 13 Dec 2017 18:56:28 +0100
> some more patches for 4.15, that fix multiple issues with IP Takeover
> configuration in qeth.
> Please queue them up for stable kernels as well (4.9 and newer).
Series applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH] ip_gre: fix wrong return value of erspan_rcv
From: William Tu @ 2017-12-15 16:26 UTC (permalink / raw)
To: Haishuang Yan
Cc: David S. Miller, Alexey Kuznetsov, Hideaki YOSHIFUJI,
Linux Kernel Network Developers, linux-kernel
In-Reply-To: <1513305976-20707-1-git-send-email-yanhaishuang@cmss.chinamobile.com>
On Thu, Dec 14, 2017 at 6:46 PM, Haishuang Yan
<yanhaishuang@cmss.chinamobile.com> wrote:
> If pskb_may_pull return failed, return PACKET_REJECT instead of -ENOMEM.
>
> Fixes: 84e54fe0a5ea ("gre: introduce native tunnel support for ERSPAN")
> Cc: William Tu <u9012063@gmail.com>
> Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
> ---
Thanks for the patch.
I think the other way is simply to just 'goto drop', freeing the skb
in erspan_rcv(), instead of 'return PACKET_REJECT'. I'm ok either way.
Acked-by: William Tu <u9012063@gmail.com>
^ permalink raw reply
* Re: [PATCH] net: phy: marvell: avoid pause mode on SGMII-to-Copper for 88e151x
From: David Miller @ 2017-12-15 16:15 UTC (permalink / raw)
To: linux; +Cc: andrew, f.fainelli, jon, netdev
In-Reply-To: <20171215154540.GT10595@n2100.armlinux.org.uk>
From: Russell King - ARM Linux <linux@armlinux.org.uk>
Date: Fri, 15 Dec 2017 15:45:40 +0000
> Sorry about that, not quite sure how that happened, but here's a
> replacement patch. I assume patchwork will do the right thing by
> including the patch in this mail...
Please use fresh patch postings when posting a new or fixed version
of a patch.
Otherwsie I have to manually edit what ends up in patchwork in order
to get rid of the quoted discussion text and other irrelevant material
in the commit message.
Thank you.
^ permalink raw reply
* Re: pull request (net-next): ipsec-next 2017-12-15
From: David Miller @ 2017-12-15 16:10 UTC (permalink / raw)
To: steffen.klassert; +Cc: herbert, netdev
In-Reply-To: <20171215121952.20745-1-steffen.klassert@secunet.com>
From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Fri, 15 Dec 2017 13:19:47 +0100
> 1) Currently we can add or update socket policies, but
> not clear them. Support clearing of socket policies
> too. From Lorenzo Colitti.
>
> 2) Add documentation for the xfrm device offload api.
> From Shannon Nelson.
>
> 3) Fix IPsec extended sequence numbers (ESN) for
> IPsec offloading. From Yossef Efraim.
>
> 4) xfrm_dev_state_add function returns success even for
> unsupported options, fix this to fail in such cases.
> From Yossef Efraim.
>
> 5) Remove a redundant xfrm_state assignment.
> From Aviv Heller.
>
> Please pull or let me know if there are problems.
Pulled, thank you Steffen.
^ permalink raw reply
* [PATCH] net: phy: marvell: avoid pause mode on SGMII-to-Copper for 88e151x
From: Russell King @ 2017-12-15 16:10 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli; +Cc: netdev
Observed on the 88e1512 in SGMII-to-Copper mode, negotiating pause
is unreliable. While the pause bits can be set in the advertisment
register, they clear shortly after negotiation with a link partner
commences irrespective of the cause of the negotiation.
While these bits may be correctly conveyed to the link partner on the
first negotiation, a subsequent negotiation (eg, due to negotiation
restart by the link partner, or reconnection of the cable) will result
in the link partner seeing these bits as zero, while the kernel
believes that it has advertised pause modes.
This leads to the local kernel evaluating (eg) symmetric pause mode,
while the remote end evaluates that we have no pause mode capability.
Since we can't guarantee the advertisment, disable pause mode support
with this PHY when used in SGMII-to-Copper mode.
The 88e1510 in RGMII-to-Copper mode appears to behave correctly.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
drivers/net/phy/marvell.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index b5a8f750e433..2510acc0feb0 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -879,6 +879,8 @@ static int m88e1510_config_init(struct phy_device *phydev)
/* SGMII-to-Copper mode initialization */
if (phydev->interface == PHY_INTERFACE_MODE_SGMII) {
+ u32 pause;
+
/* Select page 18 */
err = marvell_set_page(phydev, 18);
if (err < 0)
@@ -902,6 +904,16 @@ static int m88e1510_config_init(struct phy_device *phydev)
err = marvell_set_page(phydev, MII_MARVELL_COPPER_PAGE);
if (err < 0)
return err;
+
+ /* There appears to be a bug in the 88e1512 when used in
+ * SGMII to copper mode, where the AN advertisment register
+ * clears the pause bits each time a negotiation occurs.
+ * This means we can never be truely sure what was advertised,
+ * so disable Pause support.
+ */
+ pause = SUPPORTED_Pause | SUPPORTED_Asym_Pause;
+ phydev->supported &= ~pause;
+ phydev->advertising &= ~pause;
}
return m88e1121_config_init(phydev);
--
2.7.4
^ permalink raw reply related
* [PATCH 3/3] phylink: fix locking asserts
From: Russell King @ 2017-12-15 16:09 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli; +Cc: netdev
In-Reply-To: <20171215160344.GU10595@n2100.armlinux.org.uk>
Use ASSERT_RTNL() rather than WARN_ON(!lockdep_rtnl_is_held()) which
stops working when lockdep fires, and we end up with lots of warnings.
Fixes: 9525ae83959b ("phylink: add phylink infrastructure")
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
drivers/net/phy/phylink.c | 34 +++++++++++++++++-----------------
1 file changed, 17 insertions(+), 17 deletions(-)
diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
index c89b8c63f16a..de1d65bc977c 100644
--- a/drivers/net/phy/phylink.c
+++ b/drivers/net/phy/phylink.c
@@ -804,7 +804,7 @@ void phylink_disconnect_phy(struct phylink *pl)
{
struct phy_device *phy;
- WARN_ON(!lockdep_rtnl_is_held());
+ ASSERT_RTNL();
phy = pl->phydev;
if (phy) {
@@ -874,7 +874,7 @@ EXPORT_SYMBOL_GPL(phylink_mac_change);
*/
void phylink_start(struct phylink *pl)
{
- WARN_ON(!lockdep_rtnl_is_held());
+ ASSERT_RTNL();
netdev_info(pl->netdev, "configuring for %s/%s link mode\n",
phylink_an_mode_str(pl->link_an_mode),
@@ -914,7 +914,7 @@ EXPORT_SYMBOL_GPL(phylink_start);
*/
void phylink_stop(struct phylink *pl)
{
- WARN_ON(!lockdep_rtnl_is_held());
+ ASSERT_RTNL();
if (pl->phydev)
phy_stop(pl->phydev);
@@ -938,7 +938,7 @@ EXPORT_SYMBOL_GPL(phylink_stop);
*/
void phylink_ethtool_get_wol(struct phylink *pl, struct ethtool_wolinfo *wol)
{
- WARN_ON(!lockdep_rtnl_is_held());
+ ASSERT_RTNL();
wol->supported = 0;
wol->wolopts = 0;
@@ -963,7 +963,7 @@ int phylink_ethtool_set_wol(struct phylink *pl, struct ethtool_wolinfo *wol)
{
int ret = -EOPNOTSUPP;
- WARN_ON(!lockdep_rtnl_is_held());
+ ASSERT_RTNL();
if (pl->phydev)
ret = phy_ethtool_set_wol(pl->phydev, wol);
@@ -1008,7 +1008,7 @@ int phylink_ethtool_ksettings_get(struct phylink *pl,
{
struct phylink_link_state link_state;
- WARN_ON(!lockdep_rtnl_is_held());
+ ASSERT_RTNL();
if (pl->phydev) {
phy_ethtool_ksettings_get(pl->phydev, kset);
@@ -1061,7 +1061,7 @@ int phylink_ethtool_ksettings_set(struct phylink *pl,
struct phylink_link_state config;
int ret;
- WARN_ON(!lockdep_rtnl_is_held());
+ ASSERT_RTNL();
if (kset->base.autoneg != AUTONEG_DISABLE &&
kset->base.autoneg != AUTONEG_ENABLE)
@@ -1162,7 +1162,7 @@ int phylink_ethtool_nway_reset(struct phylink *pl)
{
int ret = 0;
- WARN_ON(!lockdep_rtnl_is_held());
+ ASSERT_RTNL();
if (pl->phydev)
ret = phy_restart_aneg(pl->phydev);
@@ -1180,7 +1180,7 @@ EXPORT_SYMBOL_GPL(phylink_ethtool_nway_reset);
void phylink_ethtool_get_pauseparam(struct phylink *pl,
struct ethtool_pauseparam *pause)
{
- WARN_ON(!lockdep_rtnl_is_held());
+ ASSERT_RTNL();
pause->autoneg = !!(pl->link_config.pause & MLO_PAUSE_AN);
pause->rx_pause = !!(pl->link_config.pause & MLO_PAUSE_RX);
@@ -1198,7 +1198,7 @@ int phylink_ethtool_set_pauseparam(struct phylink *pl,
{
struct phylink_link_state *config = &pl->link_config;
- WARN_ON(!lockdep_rtnl_is_held());
+ ASSERT_RTNL();
if (!phylink_test(pl->supported, Pause) &&
!phylink_test(pl->supported, Asym_Pause))
@@ -1284,7 +1284,7 @@ int phylink_get_eee_err(struct phylink *pl)
{
int ret = 0;
- WARN_ON(!lockdep_rtnl_is_held());
+ ASSERT_RTNL();
if (pl->phydev)
ret = phy_get_eee_err(pl->phydev);
@@ -1302,7 +1302,7 @@ int phylink_ethtool_get_eee(struct phylink *pl, struct ethtool_eee *eee)
{
int ret = -EOPNOTSUPP;
- WARN_ON(!lockdep_rtnl_is_held());
+ ASSERT_RTNL();
if (pl->phydev)
ret = phy_ethtool_get_eee(pl->phydev, eee);
@@ -1320,7 +1320,7 @@ int phylink_ethtool_set_eee(struct phylink *pl, struct ethtool_eee *eee)
{
int ret = -EOPNOTSUPP;
- WARN_ON(!lockdep_rtnl_is_held());
+ ASSERT_RTNL();
if (pl->phydev)
ret = phy_ethtool_set_eee(pl->phydev, eee);
@@ -1510,7 +1510,7 @@ int phylink_mii_ioctl(struct phylink *pl, struct ifreq *ifr, int cmd)
struct mii_ioctl_data *mii = if_mii(ifr);
int ret;
- WARN_ON(!lockdep_rtnl_is_held());
+ ASSERT_RTNL();
if (pl->phydev) {
/* PHYs only exist for MLO_AN_PHY and SGMII */
@@ -1578,7 +1578,7 @@ static int phylink_sfp_module_insert(void *upstream,
port = sfp_parse_port(pl->sfp_bus, id, support);
iface = sfp_parse_interface(pl->sfp_bus, id);
- WARN_ON(!lockdep_rtnl_is_held());
+ ASSERT_RTNL();
switch (iface) {
case PHY_INTERFACE_MODE_SGMII:
@@ -1647,7 +1647,7 @@ static void phylink_sfp_link_down(void *upstream)
{
struct phylink *pl = upstream;
- WARN_ON(!lockdep_rtnl_is_held());
+ ASSERT_RTNL();
set_bit(PHYLINK_DISABLE_LINK, &pl->phylink_disable_state);
flush_work(&pl->resolve);
@@ -1659,7 +1659,7 @@ static void phylink_sfp_link_up(void *upstream)
{
struct phylink *pl = upstream;
- WARN_ON(!lockdep_rtnl_is_held());
+ ASSERT_RTNL();
clear_bit(PHYLINK_DISABLE_LINK, &pl->phylink_disable_state);
phylink_run_resolve(pl);
--
2.7.4
^ permalink raw reply related
* [PATCH 2/3] sfp: fix EEPROM reading in the case of non-SFF8472 SFPs
From: Russell King @ 2017-12-15 16:09 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli; +Cc: netdev
In-Reply-To: <20171215160344.GU10595@n2100.armlinux.org.uk>
The EEPROM reading was trying to read from the second EEPROM address
if we requested the last byte from the SFF8079 EEPROM, which caused a
failure when the second EEPROM is not present. Discovered with a
S-RJ01 SFP module. Fix this.
Fixes: 73970055450e ("sfp: add SFP module support")
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
drivers/net/phy/sfp.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
index 1a958c7b912d..ee6b2e041171 100644
--- a/drivers/net/phy/sfp.c
+++ b/drivers/net/phy/sfp.c
@@ -724,20 +724,19 @@ static int sfp_module_eeprom(struct sfp *sfp, struct ethtool_eeprom *ee,
len = min_t(unsigned int, last, ETH_MODULE_SFF_8079_LEN);
len -= first;
- ret = sfp->read(sfp, false, first, data, len);
+ ret = sfp_read(sfp, false, first, data, len);
if (ret < 0)
return ret;
first += len;
data += len;
}
- if (first >= ETH_MODULE_SFF_8079_LEN &&
- first < ETH_MODULE_SFF_8472_LEN) {
+ if (first < ETH_MODULE_SFF_8472_LEN && last > ETH_MODULE_SFF_8079_LEN) {
len = min_t(unsigned int, last, ETH_MODULE_SFF_8472_LEN);
len -= first;
first -= ETH_MODULE_SFF_8079_LEN;
- ret = sfp->read(sfp, true, first, data, len);
+ ret = sfp_read(sfp, true, first, data, len);
if (ret < 0)
return ret;
}
--
2.7.4
^ permalink raw reply related
* [PATCH 1/3] sfp: fix non-detection of PHY
From: Russell King @ 2017-12-15 16:09 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli; +Cc: netdev
In-Reply-To: <20171215160344.GU10595@n2100.armlinux.org.uk>
The detection of a PHY changed in commit e98a3aabf85f ("mdio_bus: don't
return NULL from mdiobus_scan()") which now causes sfp to print an
error message. Update for this change.
Fixes: 73970055450e ("sfp: add SFP module support")
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
drivers/net/phy/sfp.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
index 96511557eb2c..1a958c7b912d 100644
--- a/drivers/net/phy/sfp.c
+++ b/drivers/net/phy/sfp.c
@@ -356,12 +356,12 @@ static void sfp_sm_probe_phy(struct sfp *sfp)
msleep(T_PHY_RESET_MS);
phy = mdiobus_scan(sfp->i2c_mii, SFP_PHY_ADDR);
- if (IS_ERR(phy)) {
- dev_err(sfp->dev, "mdiobus scan returned %ld\n", PTR_ERR(phy));
+ if (phy == ERR_PTR(-ENODEV)) {
+ dev_info(sfp->dev, "no PHY detected\n");
return;
}
- if (!phy) {
- dev_info(sfp->dev, "no PHY detected\n");
+ if (IS_ERR(phy)) {
+ dev_err(sfp->dev, "mdiobus scan returned %ld\n", PTR_ERR(phy));
return;
}
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 03/20] batman-adv: Add License-Filename to GPL-2.0 files
From: David Miller @ 2017-12-15 16:08 UTC (permalink / raw)
To: sw; +Cc: netdev, b.a.t.m.a.n, sven
In-Reply-To: <20171215114320.13645-4-sw@simonwunderlich.de>
From: Simon Wunderlich <sw@simonwunderlich.de>
Date: Fri, 15 Dec 2017 12:43:03 +0100
> The FSFE REUSE practices [1] recommend to add a "License-Filename" tag to
> files which don't contain the complete license text. The GPL-2.0 files
> usually only have a small notice at the beginning of the file. The longer
> license is usually stored in a separate file and therefore should be
> referenced accordingly.
Nothing else in entire kernel tree uses this.
I strongly discourage you from doing something at this level that is
not in accordance with some kind of precendence or official
recommendation for the rest of the kernel project.
If you want this to start happening, discuss it on a global scale
on lkml.
I'm definitely not pulling this tree with these changes in it.
Sorrry.
^ permalink raw reply
* [PATCH 0/3] More SFP/phylink fixes
From: Russell King - ARM Linux @ 2017-12-15 16:03 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli; +Cc: netdev
Hi,
This series fixes a few more bits with sfp/phylink, particularly
confusion with the right way to test for the RTNL mutex being
held, a change in 2016 to the mdiobus_scan() behaviour that wasn't
noticed, and a fix for reading module EEPROMs.
drivers/net/phy/phylink.c | 34 +++++++++++++++++-----------------
drivers/net/phy/sfp.c | 15 +++++++--------
2 files changed, 24 insertions(+), 25 deletions(-)
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* Re: ixgbe tuning reset when XDP is setup
From: John Fastabend @ 2017-12-15 16:03 UTC (permalink / raw)
To: David Miller, eric
Cc: netdev, xdp-newbies, pmanev, Alexander Duyck, Emil Tantilov
In-Reply-To: <20171215.105338.2092740911243038177.davem@davemloft.net>
On 12/15/2017 07:53 AM, David Miller wrote:
> From: Eric Leblond <eric@regit.org>
> Date: Fri, 15 Dec 2017 11:24:46 +0100
>
>> Hello,
>>
>> When using an ixgbe card with Suricata we are using the following
>> commands to get a symmetric hash on RSS load balancing:
>>
>> ./set_irq_affinity 0-15 eth3
>> ethtool -X eth3 hkey 6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A equal 16
>> ethtool -x eth3
>> ethtool -n eth3
>>
>> Then we start Suricata.
>>
>> In my current experiment on XDP, I have Suricata that inject the eBPF
>> program when starting. The consequence of that when using an ixgbe card
>> is that the load balancing get reset and all interrupts are reaching
>> the first core.
>
> This definitely should _not_ be a side effect of enabling XDP on a device.
>
Agreed, CC Emil and Alex we should restore these settings after the
reconfiguration done to support a queue per core.
.John
^ permalink raw reply
* Re: [PATCH 0/4] pull request for net: batman-adv 2017-12-15
From: David Miller @ 2017-12-15 16:02 UTC (permalink / raw)
To: sw; +Cc: netdev, b.a.t.m.a.n
In-Reply-To: <20171215113143.12852-1-sw@simonwunderlich.de>
From: Simon Wunderlich <sw@simonwunderlich.de>
Date: Fri, 15 Dec 2017 12:31:39 +0100
> here are a couple of fixes which we would like to see integrated into net.
>
> Please pull or let me know of any problem!
Pulled, thanks Simon.
^ permalink raw reply
* Re: [PATCH net-next] net: dsa: bcm_sf2: Update compatible string for 7278B0
From: David Miller @ 2017-12-15 15:57 UTC (permalink / raw)
To: f.fainelli-Re5JQEeQqe8AvxtiuMwx3w
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, andrew-g2DYL2Zd6BY,
vivien.didelot-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171215015941.32443-1-f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Thu, 14 Dec 2017 17:59:40 -0800
> Update the compatible string and Device Tree binding document for
> 7278B0.
>
> Signed-off-by: Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Applied.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 net-next 0/8] Hisilicon Network Subsystem 3 VF Ethernet Driver
From: David Miller @ 2017-12-15 15:55 UTC (permalink / raw)
To: pombredanne
Cc: salil.mehta, yisen.zhuang, lipeng321, mehta.salil.lnk, netdev,
linux-kernel, linux-rdma, linuxarm
In-Reply-To: <CAOFm3uGEwqVN1zLDRBWcZ+nctqwvVbVc-5cH8wFHPs+POkvBVg@mail.gmail.com>
From: Philippe Ombredanne <pombredanne@nexb.com>
Date: Fri, 15 Dec 2017 11:28:15 +0100
> Salil,
>
> On Thu, Dec 14, 2017 at 7:03 PM, Salil Mehta <salil.mehta@huawei.com> wrote:
>> This patch-set contains the support of the HNS3 (Hisilicon Network Subsystem 3)
>> Virtual Function Ethernet driver for hip08 family of SoCs. The Physical Function
>> driver is already part of the Linux mainline.
>>
>> This VF driver has its Hardware Compatibility Layer and has commom/unified ENET
>> layer/client/ethtool code with the PF driver. It also has support of mailbox to
>> communicate with the HNS3 PF driver. The basic architecture of VF driver is
>> derivative of the PF driver. Just like PF driver, this driver is also PCI
>> Express based.
>>
> <snip>
>
>> Change Log Summary:
>> Patch V4: Addressed SPDX related comment by Philippe Ombredanne
>> Patch V3: Addressed SPDX change requested by Philippe Ombredanne
>
> Thank you.
>
> For the use of SPDX tags (and this only!) you have my cheerful ack for
> the whole patch set.
>
> Acked-by: Philippe Ombredanne <pombredanne@nexb.com>
Series applied.
^ permalink raw reply
* Re: ixgbe tuning reset when XDP is setup
From: David Miller @ 2017-12-15 15:53 UTC (permalink / raw)
To: eric; +Cc: netdev, xdp-newbies, pmanev
In-Reply-To: <1513333486.28703.9.camel@regit.org>
From: Eric Leblond <eric@regit.org>
Date: Fri, 15 Dec 2017 11:24:46 +0100
> Hello,
>
> When using an ixgbe card with Suricata we are using the following
> commands to get a symmetric hash on RSS load balancing:
>
> ./set_irq_affinity 0-15 eth3
> ethtool -X eth3 hkey 6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A equal 16
> ethtool -x eth3
> ethtool -n eth3
>
> Then we start Suricata.
>
> In my current experiment on XDP, I have Suricata that inject the eBPF
> program when starting. The consequence of that when using an ixgbe card
> is that the load balancing get reset and all interrupts are reaching
> the first core.
This definitely should _not_ be a side effect of enabling XDP on a device.
^ permalink raw reply
* Re: [RFT/RFC net-next 0/2] net: dsa: Plug in PHYLINK support
From: Egil Hjelmeland @ 2017-12-15 15:51 UTC (permalink / raw)
To: Florian Fainelli, netdev
Cc: rmk+kernel, sean.wang, john, kernel, Woojung.Huh, vivien.didelot,
andrew
In-Reply-To: <20171215002850.27862-1-f.fainelli@gmail.com>
Hi
Den 15. des. 2017 01:28, skrev Florian Fainelli:
> Hi all,
>
> This patch series replaces the existing PHYLIB integration with PHYLINK which
> is a superior solution since we need to support a collection of fixed links,
> integrated PHYs, SFP, non-pluggable SFPs etc.
>
> I am expecting quite a lot of breakage, for a number of reasons:
>
> - PHYLINK does not create a PHY device for fixed links (MLO_AN_FIXED), which
> means that user-facing port (not DSA, not CPU) need to be explicitly handled
> with phylink_mac_ops now
>
FWIW: We (zenitel) does not use fixed-link on user-port. I gave the
patches a spin on our board with lan9303. As expected: no breakage.
Egil
^ permalink raw reply
* Re: v4.15-rc2 on thinkpad x60: ethernet stopped working
From: David Miller @ 2017-12-15 15:52 UTC (permalink / raw)
To: pavel
Cc: nix.or.die, bpoirier, lsorense, aaron.f.brown, jeffrey.t.kirsher,
linux-kernel, intel-wired-lan, netdev
In-Reply-To: <20171215092849.GB15090@amd>
From: Pavel Machek <pavel@ucw.cz>
Date: Fri, 15 Dec 2017 10:28:49 +0100
> Hi!
>
>> >In v4.15-rc2+, network manager can not see my ethernet card, and
>> >manual attempts to ifconfig it up did not really help, either.
>> >
>> >Card is:
>> >
>> >02:00.0 Ethernet controller: Intel Corporation 82573L Gigabit Ethernet
>> >Controller
> ....
>> >Any ideas ?
>>
>> Yes , 19110cfbb34d4af0cdfe14cd243f3b09dc95b013 broke it.
>>
>> See:
>> https://bugzilla.kernel.org/show_bug.cgi?id=198047
>>
>> Fix there :
>> https://marc.info/?l=linux-kernel&m=151272209903675&w=2
>
> I don't see the patch in latest mainline. Not having ethernet
> is... somehow annoying. What is going on there?
Generally speaking, e1000 maintainence has been handled very poorly over
the past few years, I have to say.
Fixes take forever to propagate even when someone other than the
maintainer provides a working and tested fix, just like this case.
Jeff, please take e1000 maintainence seriously and get these critical
bug fixes propagated.
Thank you.
^ permalink raw reply
* Re: [PATCH] net: phy: marvell: avoid pause mode on SGMII-to-Copper for 88e151x
From: Andrew Lunn @ 2017-12-15 15:48 UTC (permalink / raw)
To: Russell King - ARM Linux; +Cc: David Miller, f.fainelli, jon, netdev
In-Reply-To: <20171215154540.GT10595@n2100.armlinux.org.uk>
> Sorry about that, not quite sure how that happened, but here's a
> replacement patch. I assume patchwork will do the right thing by
> including the patch in this mail...
Hi Russell
No, it does not. You need to submit a whole new patch.
Andrew
^ permalink raw reply
* Re: [patch net] mlxsw: spectrum: Disable MAC learning for ovs port
From: David Miller @ 2017-12-15 15:48 UTC (permalink / raw)
To: jiri; +Cc: netdev, yuvalm, idosch, mlxsw
In-Reply-To: <20171215074421.2776-1-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Fri, 15 Dec 2017 08:44:21 +0100
> From: Yuval Mintz <yuvalm@mellanox.com>
>
> Learning is currently enabled for ports which are OVS slaves -
> even though OVS doesn't need this indication.
> Since we're not associating a fid with the port, HW would continuously
> notify driver of learned [& aged] MACs which would be logged as errors.
>
> Fixes: 2b94e58df58c ("mlxsw: spectrum: Allow ports to work under OVS master")
> Signed-off-by: Yuval Mintz <yuvalm@mellanox.com>
> Reviewed-by: Ido Schimmel <idosch@mellanox.com>
> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH] net: qcom/emac: Reduce timeout for mdio read/write
From: Andrew Lunn @ 2017-12-15 15:47 UTC (permalink / raw)
To: Hemanth Puranik; +Cc: netdev, linux-kernel, Timur Tabi
In-Reply-To: <1513348558-10906-1-git-send-email-hpuranik@codeaurora.org>
On Fri, Dec 15, 2017 at 08:05:58PM +0530, Hemanth Puranik wrote:
> Currently mdio read/write takes around ~115us as the timeout
> between status check is set to 100us.
> By reducing the timeout to 1us mdio read/write takes ~15us to
> complete. This improves the link up event response.
>
> Signed-off-by: Hemanth Puranik <hpuranik@codeaurora.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH] net: phy: marvell: enable a errata for 88E1145
From: David Miller @ 2017-12-15 15:47 UTC (permalink / raw)
To: qiang.zhao; +Cc: andrew, f.fainelli, netdev
In-Reply-To: <20171215061332.42133-1-qiang.zhao@nxp.com>
From: Zhao Qiang <qiang.zhao@nxp.com>
Date: Fri, 15 Dec 2017 14:13:32 +0800
> The patch below
> commit f2899788353c ("net: phy: marvell: Limit errata to 88m1101")
> limit a errata's scope to 88E1101.
> However, 88E1145 also need this errata, set config_aneg to
> m88e1101_config_aneg for 88E1145
>
> Signed-off-by: Zhao Qiang <qiang.zhao@nxp.com>
The proper way to say that a patch fixes a particular commit it to
reference it in a "Fixes: " tag, like this:
====================
Fixes: f2899788353c ("net: phy: marvell: Limit errata to 88m1101")
Signed-off-by: Zhao Qiang <qiang.zhao@nxp.com>
====================
And then you don't need to reference it explicitly in your commit
message, you can just instead say:
Limit 88m1101 autoneg errata to 88E1145 as well.
Please fix up your submission like this and resubmit.
Thank you.
^ permalink raw reply
* Re: [PATCH] net: phy: marvell: avoid pause mode on SGMII-to-Copper for 88e151x
From: Russell King - ARM Linux @ 2017-12-15 15:45 UTC (permalink / raw)
To: David Miller; +Cc: andrew, f.fainelli, jon, netdev
In-Reply-To: <20171213.161423.1305694719573286723.davem@davemloft.net>
On Wed, Dec 13, 2017 at 04:14:23PM -0500, David Miller wrote:
> From: Russell King <rmk+kernel@armlinux.org.uk>
> Date: Wed, 13 Dec 2017 09:22:09 +0000
>
> > @@ -924,6 +924,16 @@ static int m88e1510_config_init(struct phy_device *phydev)
> > err = marvell_set_page(phydev, MII_MARVELL_COPPER_PAGE);
> > if (err < 0)
> > return err;
> > +
> > + /* There appears to be a bug in the 88e1512 when used in
> > + * SGMII to copper mode, where the AN advertisment register
> > + * clears the pause bits each time a negotiation occurs.
> > + * This means we can never be truely sure what was advertised,
> > + * so disable Pause support.
> > + */
> > + pause = SUPPORTED_Pause | SUPPORTED_Asym_Pause;
> > + phydev->supported &= ~pause;
> > + phydev->advertising &= ~pause;
> > }
> >
>
> This function doesn't have a local 'pause' variable in any of my trees.
>
> I wonder what you generated this against, and even more importantly, what
> tree the reviewers were considering when looking at this patch :)
Sorry about that, not quite sure how that happened, but here's a
replacement patch. I assume patchwork will do the right thing by
including the patch in this mail...
8<====
From: Russell King <rmk+kernel@armlinux.org.uk>
Subject: [PATCH] net: phy: marvell: avoid pause mode on SGMII-to-Copper for
88e151x
Observed on the 88e1512 in SGMII-to-Copper mode, negotiating pause
is unreliable. While the pause bits can be set in the advertisment
register, they clear shortly after negotiation with a link partner
commences irrespective of the cause of the negotiation.
While these bits may be correctly conveyed to the link partner on the
first negotiation, a subsequent negotiation (eg, due to negotiation
restart by the link partner, or reconnection of the cable) will result
in the link partner seeing these bits as zero, while the kernel
believes that it has advertised pause modes.
This leads to the local kernel evaluating (eg) symmetric pause mode,
while the remote end evaluates that we have no pause mode capability.
Since we can't guarantee the advertisment, disable pause mode support
with this PHY when used in SGMII-to-Copper mode.
The 88e1510 in RGMII-to-Copper mode appears to behave correctly.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
drivers/net/phy/marvell.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index b5a8f750e433..2510acc0feb0 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -879,6 +879,8 @@ static int m88e1510_config_init(struct phy_device *phydev)
/* SGMII-to-Copper mode initialization */
if (phydev->interface == PHY_INTERFACE_MODE_SGMII) {
+ u32 pause;
+
/* Select page 18 */
err = marvell_set_page(phydev, 18);
if (err < 0)
@@ -902,6 +904,16 @@ static int m88e1510_config_init(struct phy_device *phydev)
err = marvell_set_page(phydev, MII_MARVELL_COPPER_PAGE);
if (err < 0)
return err;
+
+ /* There appears to be a bug in the 88e1512 when used in
+ * SGMII to copper mode, where the AN advertisment register
+ * clears the pause bits each time a negotiation occurs.
+ * This means we can never be truely sure what was advertised,
+ * so disable Pause support.
+ */
+ pause = SUPPORTED_Pause | SUPPORTED_Asym_Pause;
+ phydev->supported &= ~pause;
+ phydev->advertising &= ~pause;
}
return m88e1121_config_init(phydev);
--
2.7.4
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply related
* Re: [PATCH v3 net-next 0/3] add VLAN support to DSA MT7530
From: David Miller @ 2017-12-15 15:35 UTC (permalink / raw)
To: sean.wang
Cc: andrew, f.fainelli, vivien.didelot, netdev, linux-kernel,
linux-mediatek
In-Reply-To: <cover.1513312600.git.sean.wang@mediatek.com>
From: <sean.wang@mediatek.com>
Date: Fri, 15 Dec 2017 12:46:59 +0800
> From: Sean Wang <sean.wang@mediatek.com>
>
> Changes sicne v2:
> update to the latest code base from net-next and fix up all building
> errors with -Werror.
>
> Changes since v1:
> - fix up the typo
> - prefer ordering declarations longest to shortest
> - update that vlan_prepare callback should not change any state
> - use lower case letter for function naming
>
> The patchset extends DSA MT7530 to VLAN support through filling required
> callbacks in patch 1 and merging the special tag with VLAN tag in patch 2
> for allowing that the hardware can handle these packets with VID from the
> CPU port.
This one builds :-) Series applied, thanks.
^ permalink raw reply
* Re: [PATCH] net: qcom/emac: Reduce timeout for mdio read/write
From: Timur Tabi @ 2017-12-15 15:20 UTC (permalink / raw)
To: Hemanth Puranik, netdev, linux-kernel
In-Reply-To: <1513348558-10906-1-git-send-email-hpuranik@codeaurora.org>
On 12/15/2017 08:35 AM, Hemanth Puranik wrote:
> Currently mdio read/write takes around ~115us as the timeout
> between status check is set to 100us.
> By reducing the timeout to 1us mdio read/write takes ~15us to
> complete. This improves the link up event response.
>
> Signed-off-by: Hemanth Puranik<hpuranik@codeaurora.org>
Acked-by: Timur Tabi <timur@codeaurora.org>
--
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
* net-next lan9303 and CONFIG_NET_DSA_LEGACY
From: Egil Hjelmeland @ 2017-12-15 14:51 UTC (permalink / raw)
To: andrew, Vivien Didelot, Florian Fainelli; +Cc: netdev
Hi
I found that our lan9303 board is unable to receive network data unless
CONFIG_NET_DSA_LEGACY is set. Is that a problem with the driver, or our
DTS? (imx28)
ahb@80080000 {
mac0: ethernet@800f0000 {
clocks = <&clks 57>, <&clks 57>, <&clks 64>;
clock-names = "ipg", "ahb", "enet_out";
phy-mode = "rmii";
pinctrl-names = "default";
pinctrl-0 = <&mac0_pins_a>;
status = "okay";
fixed-link {
speed = <100>;
full-duplex;
};
mdio {
#address-cells = <1>;
#size-cells = <0>;
switch: switch-phy@0 {
compatible = "smsc,lan9303-mdio";
reg = <0>;
reset-gpios = <&gpio2 7 GPIO_ACTIVE_LOW >;
reset-duration = <10>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
label = "cpu";
ethernet = <&mac0>;
phy-mode = "rmii";
fixed-link {
speed = <100>;
full-duplex;
};
};
port@1 { /* external port 1 */
reg = <1>;
label = "sw1";
phy-mode = "rmii";
};
port@2 { /* external port 2 */
reg = <2>;
label = "sw2";
phy-mode = "rmii";
};
};
};
};
};
};
Any advise would be appreciated.
Egil
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox