* Re: Source address fib invalidation on IPv6
From: Jason A. Donenfeld @ 2016-11-12 15:40 UTC (permalink / raw)
To: David Ahern; +Cc: Netdev, LKML, WireGuard mailing list
In-Reply-To: <CAHmME9o_AM1Lms6CJSpbjfAgcyGuRx8yqwSaNWEbSnY7gGnt6w@mail.gmail.com>
Hi again,
I've done some pretty in depth debugging now to determine exactly what
the behavior of ipv6_stub->ipv6_dst_lookup is. First I'll start with
ip_route_output_flow, which I believe to be well behaved, and then
I'll show ipv6_stub->ipv6_dst_lookup, which seems ill-behaved:
Userspace:
ip addr add 192.168.1.2/24 dev eth0
Kernelspace:
struct flowi4 fl = {
.saddr = 192.168.1.2,
.daddr = 192.168.1.99,
};
rt = ip_route_output_flow(sock_net(sock), &fl, sock);
// rt returns valid rt for routing to 192.168.1.99 from
192.168.1.2 using eth0
Userspace:
ip addr add 192.168.1.3/24 dev eth0
ip addr del 192.168.1.2/24 dev eth0
Kernelspace:
struct flowi4 fl = {
.saddr = 192.168.1.2,
.daddr = 192.168.1.99,
};
rt = ip_route_output_flow(sock_net(sock), &fl, sock);
// PTR_ERR(rt) == -EINVAL
This seems correct behavior to me, since no interface has 192.168.1.2
as a source address.
Now for the incorrect IPv6 behavior:
Userspace:
ip -6 addr add abcd::2/96 dev eth0
Kernelspace:
struct flowi6 fl = {
.saddr = abcd::2,
.daddr = abcd::99,
};
ret = ipv6_stub->ipv6_dst_lookup(sock_net(sock), sock, &dst, &fl);
// ret is 0, and dst is a non-null dst routing to abcd::99 from
abcd::2 using eth0
Userspace:
ip -6 addr add abcd::3/96 dev eth0
ip -6 addr del abcd::2/96 dev eth0
Kernelspace:
struct flowi6 fl = {
.saddr = abcd::2,
.daddr = abcd::99,
};
ret = ipv6_stub->ipv6_dst_lookup(sock_net(sock), sock, &dst, &fl);
// ret is 0, and dst is a non-null dst routing to abcd::99 from
abcd::2 using eth0 **INCORRECT BEHAVIOR!**
This seems *INCORRECT* behavior to me, since no interface has abcd::2
as a source address.
So, to summarize, the problem is that ipv6_dst_lookup will happily
return a dst even though the source IP has been removed from the
interface.
I hope this clarifies things. I await your response.
Regards,
Jason
^ permalink raw reply
* Re: Spurious code in commit 1bf40ada6290 ("amd-xgbe: Add support for clause 37 auto-negotiation"
From: Tom Lendacky @ 2016-11-12 15:47 UTC (permalink / raw)
To: Marion & Christophe JAILLET, davem
Cc: netdev, linux-kernel, Kernel Janitors
In-Reply-To: <80c6a7b3-4a03-e087-3638-7048adebbda8@wanadoo.fr>
On 11/12/2016 8:34 AM, Marion & Christophe JAILLET wrote:
> Hi,
>
> in commit 1bf40ada6290 ("amd-xgbe: Add support for clause 37
> auto-negotiation"), we can find:
>
> diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-common.h
> b/drivers/net/ethernet/amd/xgbe/xgbe-common.h
> index 695e982..8bcf4ef 100644
> --- a/drivers/net/ethernet/amd/xgbe/xgbe-common.h
> +++ b/drivers/net/ethernet/amd/xgbe/xgbe-common.h
> [...]
> #define XGBE_AN_CL37_PCS_MODE_MASK 0x06
> #define XGBE_AN_CL37_PCS_MODE_BASEX 0x00
> #define XGBE_AN_CL37_PCS_MODE_SGMII 0x04
> #define XGBE_AN_CL37_TX_CONFIG_MASK 0x08
> [...]
>
> diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-mdio.c
> b/drivers/net/ethernet/amd/xgbe/xgbe-mdio.c
> index d5bfbe4..723eb90 100644
> --- a/drivers/net/ethernet/amd/xgbe/xgbe-mdio.c
> +++ b/drivers/net/ethernet/amd/xgbe/xgbe-mdio.c
> [...]
> /* Set up the Control register */
> reg = XMDIO_READ(pdata, MDIO_MMD_VEND2, MDIO_VEND2_AN_CTRL);
> reg &= XGBE_AN_CL37_TX_CONFIG_MASK;
> reg &= XGBE_AN_CL37_PCS_MODE_MASK;
> [...]
>
> the "reg &=" statements look spurious. The 2 constants being 0x06 and
> 0x08, the current code is equivalent to "reg = 0"
>
> It is likely that "reg |=" (or "reg &= ~") was expected here.
Yes, those should have been "reg &= ~". I didn't find this in my testing
because the register is all zeroes after reset. I'll submit a patch to
fix that.
Thanks,
Tom
>
> Best regards,
> CJ
>
^ permalink raw reply
* [PATCH] net: atheros: atl1c: use new api ethtool_{get|set}_link_ksettings
From: Philippe Reynes @ 2016-11-12 16:32 UTC (permalink / raw)
To: jcliburn, chris.snook, davem; +Cc: netdev, linux-kernel, Philippe Reynes
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>
---
drivers/net/ethernet/atheros/atl1c/atl1c_ethtool.c | 54 +++++++++++---------
1 files changed, 30 insertions(+), 24 deletions(-)
diff --git a/drivers/net/ethernet/atheros/atl1c/atl1c_ethtool.c b/drivers/net/ethernet/atheros/atl1c/atl1c_ethtool.c
index 872b7ab..cfe86a2 100644
--- a/drivers/net/ethernet/atheros/atl1c/atl1c_ethtool.c
+++ b/drivers/net/ethernet/atheros/atl1c/atl1c_ethtool.c
@@ -26,46 +26,52 @@
#include "atl1c.h"
-static int atl1c_get_settings(struct net_device *netdev,
- struct ethtool_cmd *ecmd)
+static int atl1c_get_link_ksettings(struct net_device *netdev,
+ struct ethtool_link_ksettings *cmd)
{
struct atl1c_adapter *adapter = netdev_priv(netdev);
struct atl1c_hw *hw = &adapter->hw;
+ u32 supported, advertising;
- ecmd->supported = (SUPPORTED_10baseT_Half |
+ supported = (SUPPORTED_10baseT_Half |
SUPPORTED_10baseT_Full |
SUPPORTED_100baseT_Half |
SUPPORTED_100baseT_Full |
SUPPORTED_Autoneg |
SUPPORTED_TP);
if (hw->link_cap_flags & ATL1C_LINK_CAP_1000M)
- ecmd->supported |= SUPPORTED_1000baseT_Full;
+ supported |= SUPPORTED_1000baseT_Full;
- ecmd->advertising = ADVERTISED_TP;
+ advertising = ADVERTISED_TP;
- ecmd->advertising |= hw->autoneg_advertised;
+ advertising |= hw->autoneg_advertised;
- ecmd->port = PORT_TP;
- ecmd->phy_address = 0;
- ecmd->transceiver = XCVR_INTERNAL;
+ cmd->base.port = PORT_TP;
+ cmd->base.phy_address = 0;
if (adapter->link_speed != SPEED_0) {
- ethtool_cmd_speed_set(ecmd, adapter->link_speed);
+ cmd->base.speed = adapter->link_speed;
if (adapter->link_duplex == FULL_DUPLEX)
- ecmd->duplex = DUPLEX_FULL;
+ cmd->base.duplex = DUPLEX_FULL;
else
- ecmd->duplex = DUPLEX_HALF;
+ cmd->base.duplex = DUPLEX_HALF;
} else {
- ethtool_cmd_speed_set(ecmd, SPEED_UNKNOWN);
- ecmd->duplex = DUPLEX_UNKNOWN;
+ cmd->base.speed = SPEED_UNKNOWN;
+ cmd->base.duplex = DUPLEX_UNKNOWN;
}
- ecmd->autoneg = AUTONEG_ENABLE;
+ cmd->base.autoneg = AUTONEG_ENABLE;
+
+ ethtool_convert_legacy_u32_to_link_mode(cmd->link_modes.supported,
+ supported);
+ ethtool_convert_legacy_u32_to_link_mode(cmd->link_modes.advertising,
+ advertising);
+
return 0;
}
-static int atl1c_set_settings(struct net_device *netdev,
- struct ethtool_cmd *ecmd)
+static int atl1c_set_link_ksettings(struct net_device *netdev,
+ const struct ethtool_link_ksettings *cmd)
{
struct atl1c_adapter *adapter = netdev_priv(netdev);
struct atl1c_hw *hw = &adapter->hw;
@@ -74,12 +80,12 @@ static int atl1c_set_settings(struct net_device *netdev,
while (test_and_set_bit(__AT_RESETTING, &adapter->flags))
msleep(1);
- if (ecmd->autoneg == AUTONEG_ENABLE) {
+ if (cmd->base.autoneg == AUTONEG_ENABLE) {
autoneg_advertised = ADVERTISED_Autoneg;
} else {
- u32 speed = ethtool_cmd_speed(ecmd);
+ u32 speed = cmd->base.speed;
if (speed == SPEED_1000) {
- if (ecmd->duplex != DUPLEX_FULL) {
+ if (cmd->base.duplex != DUPLEX_FULL) {
if (netif_msg_link(adapter))
dev_warn(&adapter->pdev->dev,
"1000M half is invalid\n");
@@ -88,12 +94,12 @@ static int atl1c_set_settings(struct net_device *netdev,
}
autoneg_advertised = ADVERTISED_1000baseT_Full;
} else if (speed == SPEED_100) {
- if (ecmd->duplex == DUPLEX_FULL)
+ if (cmd->base.duplex == DUPLEX_FULL)
autoneg_advertised = ADVERTISED_100baseT_Full;
else
autoneg_advertised = ADVERTISED_100baseT_Half;
} else {
- if (ecmd->duplex == DUPLEX_FULL)
+ if (cmd->base.duplex == DUPLEX_FULL)
autoneg_advertised = ADVERTISED_10baseT_Full;
else
autoneg_advertised = ADVERTISED_10baseT_Half;
@@ -284,8 +290,6 @@ static int atl1c_nway_reset(struct net_device *netdev)
}
static const struct ethtool_ops atl1c_ethtool_ops = {
- .get_settings = atl1c_get_settings,
- .set_settings = atl1c_set_settings,
.get_drvinfo = atl1c_get_drvinfo,
.get_regs_len = atl1c_get_regs_len,
.get_regs = atl1c_get_regs,
@@ -297,6 +301,8 @@ static int atl1c_nway_reset(struct net_device *netdev)
.get_link = ethtool_op_get_link,
.get_eeprom_len = atl1c_get_eeprom_len,
.get_eeprom = atl1c_get_eeprom,
+ .get_link_ksettings = atl1c_get_link_ksettings,
+ .set_link_ksettings = atl1c_set_link_ksettings,
};
void atl1c_set_ethtool_ops(struct net_device *netdev)
--
1.7.4.4
^ permalink raw reply related
* 15405 netdev
From: clinicallaw @ 2016-11-12 17:09 UTC (permalink / raw)
To: netdev
[-- Attachment #1: MESSAGE_884059386788_netdev.zip --]
[-- Type: application/zip, Size: 3581 bytes --]
^ permalink raw reply
* [PATCH] ps3_gelic: fix spelling mistake in debug message
From: Colin King @ 2016-11-12 17:20 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
David S . Miller, Muhammad Falak R Wani, Christophe Jaillet,
Jarod Wilson, netdev, linuxppc-dev
Cc: linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Trivial fix to spelling mistake "unmached" to "unmatched" in
debug message.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/ethernet/toshiba/ps3_gelic_wireless.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/toshiba/ps3_gelic_wireless.c b/drivers/net/ethernet/toshiba/ps3_gelic_wireless.c
index b3abd02..eed18f8 100644
--- a/drivers/net/ethernet/toshiba/ps3_gelic_wireless.c
+++ b/drivers/net/ethernet/toshiba/ps3_gelic_wireless.c
@@ -1694,7 +1694,7 @@ struct gelic_wl_scan_info *gelic_wl_find_best_bss(struct gelic_wl_info *wl)
pr_debug("%s: bssid matched\n", __func__);
break;
} else {
- pr_debug("%s: bssid unmached\n", __func__);
+ pr_debug("%s: bssid unmatched\n", __func__);
continue;
}
}
--
2.10.2
^ permalink raw reply related
* [PATCH] net: ethernet: ixp4xx_eth: fix spelling mistake in debug message
From: Colin King @ 2016-11-12 17:44 UTC (permalink / raw)
To: Krzysztof Halasa, netdev; +Cc: linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Trivial fix to spelling mistake "successed" to "succeeded"
in debug message. Also unwrap multi-line literal string.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/ethernet/xscale/ixp4xx_eth.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/xscale/ixp4xx_eth.c b/drivers/net/ethernet/xscale/ixp4xx_eth.c
index 46cc33b..07d862d 100644
--- a/drivers/net/ethernet/xscale/ixp4xx_eth.c
+++ b/drivers/net/ethernet/xscale/ixp4xx_eth.c
@@ -708,8 +708,7 @@ static int eth_poll(struct napi_struct *napi, int budget)
if (!qmgr_stat_below_low_watermark(rxq) &&
napi_reschedule(napi)) { /* not empty again */
#if DEBUG_RX
- printk(KERN_DEBUG "%s: eth_poll"
- " napi_reschedule successed\n",
+ printk(KERN_DEBUG "%s: eth_poll napi_reschedule succeeded\n",
dev->name);
#endif
qmgr_disable_irq(rxq);
--
2.10.2
^ permalink raw reply related
* Re: Source address fib invalidation on IPv6
From: David Ahern @ 2016-11-12 18:14 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: Netdev, Hannes Frederic Sowa, LKML, WireGuard mailing list,
YOSHIFUJI Hideaki
In-Reply-To: <CAHmME9oeAuBQJguTFivYsYw4fMoc4+sgxcdS4MArN474m7NjTQ@mail.gmail.com>
On 11/12/16 8:40 AM, Jason A. Donenfeld wrote:
> Hi again,
>
> I've done some pretty in depth debugging now to determine exactly what
> the behavior of ipv6_stub->ipv6_dst_lookup is. First I'll start with
> ip_route_output_flow, which I believe to be well behaved, and then
> I'll show ipv6_stub->ipv6_dst_lookup, which seems ill-behaved:
>
> Userspace:
> ip addr add 192.168.1.2/24 dev eth0
> Kernelspace:
> struct flowi4 fl = {
> .saddr = 192.168.1.2,
> .daddr = 192.168.1.99,
> };
> rt = ip_route_output_flow(sock_net(sock), &fl, sock);
> // rt returns valid rt for routing to 192.168.1.99 from
> 192.168.1.2 using eth0
> Userspace:
> ip addr add 192.168.1.3/24 dev eth0
> ip addr del 192.168.1.2/24 dev eth0
> Kernelspace:
> struct flowi4 fl = {
> .saddr = 192.168.1.2,
> .daddr = 192.168.1.99,
> };
> rt = ip_route_output_flow(sock_net(sock), &fl, sock);
> // PTR_ERR(rt) == -EINVAL
I believe that is coming from __ip_route_output_key_hash(), line 2232 with __ip_dev_find not finding a device with that address.
Not applicable for your use case, but __ip_dev_find does not have any checks on which L3 domain the device belongs to so the check does not handle VRF for example. I'll take a look at fixing this next week.
>
> This seems correct behavior to me, since no interface has 192.168.1.2
> as a source address.
>
> Now for the incorrect IPv6 behavior:
>
> Userspace:
> ip -6 addr add abcd::2/96 dev eth0
> Kernelspace:
> struct flowi6 fl = {
> .saddr = abcd::2,
> .daddr = abcd::99,
> };
> ret = ipv6_stub->ipv6_dst_lookup(sock_net(sock), sock, &dst, &fl);
> // ret is 0, and dst is a non-null dst routing to abcd::99 from
> abcd::2 using eth0
> Userspace:
> ip -6 addr add abcd::3/96 dev eth0
> ip -6 addr del abcd::2/96 dev eth0
> Kernelspace:
> struct flowi6 fl = {
> .saddr = abcd::2,
> .daddr = abcd::99,
> };
> ret = ipv6_stub->ipv6_dst_lookup(sock_net(sock), sock, &dst, &fl);
> // ret is 0, and dst is a non-null dst routing to abcd::99 from
> abcd::2 using eth0 **INCORRECT BEHAVIOR!**
>
> This seems *INCORRECT* behavior to me, since no interface has abcd::2
> as a source address.
Gotcha. I don't see any checks that the saddr is valid similar to what IPv4 does.
I think the right place to add a check is in ip6_dst_lookup_tail():
if (!ipv6_addr_any(&fl6->saddr)) {
// saddr is valid for L3 domain
}
^ permalink raw reply
* Re: Source address fib invalidation on IPv6
From: Jason A. Donenfeld @ 2016-11-12 19:08 UTC (permalink / raw)
To: David Ahern
Cc: Netdev, Hannes Frederic Sowa, LKML, WireGuard mailing list,
YOSHIFUJI Hideaki
In-Reply-To: <0dbf5deb-bffb-4878-a268-1adb17c47676@cumulusnetworks.com>
Hi David,
On Sat, Nov 12, 2016 at 7:14 PM, David Ahern <dsa@cumulusnetworks.com> wrote:
> I believe that is coming from __ip_route_output_key_hash(), line 2232 with __ip_dev_find not finding a device with that address.
It's possible we simply are looking at different source trees, but I
have the -EINVAL return in 4.8 route.c sources happening due to the
assignment on line 2175 and the jump on line 2220.
> Not applicable for your use case, but __ip_dev_find does not have any checks on which L3 domain the device belongs to so the check does not handle VRF for example. I'll take a look at fixing this next week.
Interesting.
>
> Gotcha. I don't see any checks that the saddr is valid similar to what IPv4 does.
>
> I think the right place to add a check is in ip6_dst_lookup_tail():
> if (!ipv6_addr_any(&fl6->saddr)) {
> // saddr is valid for L3 domain
> }
Right. It should probably do the check here, and return
ERR_PTR(-EINVAL), the same as the v4 version, so that ret codes can be
checked consistently.
Thanks for looking into this. If you're backed up and would like me to
submit a patch, just let me know, and I'll give it my best shot.
Regards,
Jason
^ permalink raw reply
* Re: [PATCH] genetlink: fix unsigned int comparison with less than zero
From: Johannes Berg @ 2016-11-12 21:37 UTC (permalink / raw)
To: Cong Wang, Colin King
Cc: David S . Miller, pravin shelar, Wei Yongjun, Florian Westphal,
Tycho Andersen, Tom Herbert, Linux Kernel Network Developers,
LKML
In-Reply-To: <CAM_iQpW=q4nm97dNouSL19Cr2cEWT9xQHXAm4CNJk=AY8z_2MA@mail.gmail.com>
On Thu, 2016-11-10 at 09:11 -0800, Cong Wang wrote:
> On Thu, Nov 10, 2016 at 7:57 AM, Colin King <colin.king@canonical.com
> > wrote:
> >
> > From: Colin Ian King <colin.king@canonical.com>
> >
> > family->id is unsigned, so the less than zero check for
> > failure return from idr_alloc is never true and so the error exit
> > is never handled. Instead, assign err and check if this is less
> > than zero since this is a signed integer.
>
> Why family->id can't be just signed int? For me it should be.
I suppose it could be, since family IDs are allocated in a 16-bit range
anyway. But family IDs can also never actually be negative, so having
an unsigned int in the struct makes sense too.
I tend to think this patch is fine.
johannes
^ permalink raw reply
* [PATCH] net: atheros: atl1e: use new api ethtool_{get|set}_link_ksettings
From: Philippe Reynes @ 2016-11-12 22:16 UTC (permalink / raw)
To: jcliburn, chris.snook, davem; +Cc: netdev, linux-kernel, Philippe Reynes
The ethtool api {get|set}_settings is deprecated.
We move this driver to new api {get|set}_link_ksettings.
The previous implementation of set_settings was modifying
the value of advertising, but with the new API, it's not
possible. The structure ethtool_link_ksettings is defined
as const.
Signed-off-by: Philippe Reynes <tremyfr@gmail.com>
---
drivers/net/ethernet/atheros/atl1e/atl1e_ethtool.c | 62 +++++++++++--------
1 files changed, 36 insertions(+), 26 deletions(-)
diff --git a/drivers/net/ethernet/atheros/atl1e/atl1e_ethtool.c b/drivers/net/ethernet/atheros/atl1e/atl1e_ethtool.c
index 8e3dbd4..cb489e7 100644
--- a/drivers/net/ethernet/atheros/atl1e/atl1e_ethtool.c
+++ b/drivers/net/ethernet/atheros/atl1e/atl1e_ethtool.c
@@ -26,73 +26,83 @@
#include "atl1e.h"
-static int atl1e_get_settings(struct net_device *netdev,
- struct ethtool_cmd *ecmd)
+static int atl1e_get_link_ksettings(struct net_device *netdev,
+ struct ethtool_link_ksettings *cmd)
{
struct atl1e_adapter *adapter = netdev_priv(netdev);
struct atl1e_hw *hw = &adapter->hw;
+ u32 supported, advertising;
- ecmd->supported = (SUPPORTED_10baseT_Half |
+ supported = (SUPPORTED_10baseT_Half |
SUPPORTED_10baseT_Full |
SUPPORTED_100baseT_Half |
SUPPORTED_100baseT_Full |
SUPPORTED_Autoneg |
SUPPORTED_TP);
if (hw->nic_type == athr_l1e)
- ecmd->supported |= SUPPORTED_1000baseT_Full;
+ supported |= SUPPORTED_1000baseT_Full;
- ecmd->advertising = ADVERTISED_TP;
+ advertising = ADVERTISED_TP;
- ecmd->advertising |= ADVERTISED_Autoneg;
- ecmd->advertising |= hw->autoneg_advertised;
+ advertising |= ADVERTISED_Autoneg;
+ advertising |= hw->autoneg_advertised;
- ecmd->port = PORT_TP;
- ecmd->phy_address = 0;
- ecmd->transceiver = XCVR_INTERNAL;
+ cmd->base.port = PORT_TP;
+ cmd->base.phy_address = 0;
if (adapter->link_speed != SPEED_0) {
- ethtool_cmd_speed_set(ecmd, adapter->link_speed);
+ cmd->base.speed = adapter->link_speed;
if (adapter->link_duplex == FULL_DUPLEX)
- ecmd->duplex = DUPLEX_FULL;
+ cmd->base.duplex = DUPLEX_FULL;
else
- ecmd->duplex = DUPLEX_HALF;
+ cmd->base.duplex = DUPLEX_HALF;
} else {
- ethtool_cmd_speed_set(ecmd, SPEED_UNKNOWN);
- ecmd->duplex = DUPLEX_UNKNOWN;
+ cmd->base.speed = SPEED_UNKNOWN;
+ cmd->base.duplex = DUPLEX_UNKNOWN;
}
- ecmd->autoneg = AUTONEG_ENABLE;
+ cmd->base.autoneg = AUTONEG_ENABLE;
+
+ ethtool_convert_legacy_u32_to_link_mode(cmd->link_modes.supported,
+ supported);
+ ethtool_convert_legacy_u32_to_link_mode(cmd->link_modes.advertising,
+ advertising);
+
return 0;
}
-static int atl1e_set_settings(struct net_device *netdev,
- struct ethtool_cmd *ecmd)
+static int atl1e_set_link_ksettings(struct net_device *netdev,
+ const struct ethtool_link_ksettings *cmd)
{
struct atl1e_adapter *adapter = netdev_priv(netdev);
struct atl1e_hw *hw = &adapter->hw;
+ u32 advertising;
+
+ ethtool_convert_link_mode_to_legacy_u32(&advertising,
+ cmd->link_modes.advertising);
while (test_and_set_bit(__AT_RESETTING, &adapter->flags))
msleep(1);
- if (ecmd->autoneg == AUTONEG_ENABLE) {
+ if (cmd->base.autoneg == AUTONEG_ENABLE) {
u16 adv4, adv9;
- if ((ecmd->advertising&ADVERTISE_1000_FULL)) {
+ if (advertising & ADVERTISE_1000_FULL) {
if (hw->nic_type == athr_l1e) {
hw->autoneg_advertised =
- ecmd->advertising & AT_ADV_MASK;
+ advertising & AT_ADV_MASK;
} else {
clear_bit(__AT_RESETTING, &adapter->flags);
return -EINVAL;
}
- } else if (ecmd->advertising&ADVERTISE_1000_HALF) {
+ } else if (advertising & ADVERTISE_1000_HALF) {
clear_bit(__AT_RESETTING, &adapter->flags);
return -EINVAL;
} else {
hw->autoneg_advertised =
- ecmd->advertising & AT_ADV_MASK;
+ advertising & AT_ADV_MASK;
}
- ecmd->advertising = hw->autoneg_advertised |
+ advertising = hw->autoneg_advertised |
ADVERTISED_TP | ADVERTISED_Autoneg;
adv4 = hw->mii_autoneg_adv_reg & ~ADVERTISE_ALL;
@@ -367,8 +377,6 @@ static int atl1e_nway_reset(struct net_device *netdev)
}
static const struct ethtool_ops atl1e_ethtool_ops = {
- .get_settings = atl1e_get_settings,
- .set_settings = atl1e_set_settings,
.get_drvinfo = atl1e_get_drvinfo,
.get_regs_len = atl1e_get_regs_len,
.get_regs = atl1e_get_regs,
@@ -380,6 +388,8 @@ static int atl1e_nway_reset(struct net_device *netdev)
.get_eeprom_len = atl1e_get_eeprom_len,
.get_eeprom = atl1e_get_eeprom,
.set_eeprom = atl1e_set_eeprom,
+ .get_link_ksettings = atl1e_get_link_ksettings,
+ .set_link_ksettings = atl1e_set_link_ksettings,
};
void atl1e_set_ethtool_ops(struct net_device *netdev)
--
1.7.4.4
^ permalink raw reply related
* [PATCH] net/phy/vitesse: Configure RGMII skew on VSC8601, if needed
From: Alexandru Gagniuc @ 2016-11-12 23:32 UTC (permalink / raw)
To: f.fainelli; +Cc: gokhan, netdev, linux-kernel, Alexandru Gagniuc
With RGMII, we need a 1.5 to 2ns skew between clock and data lines. The
VSC8601 can handle this internally. While the VSC8601 can set more
fine-grained delays, the standard skew settings work out of the box.
The same heuristic is used to determine when this skew should be enabled
as in vsc824x_config_init().
Tested on custom board with AM3352 SOC and VSC801 PHY.
Signed-off-by: Alexandru Gagniuc <alex.g@adaptrum.com>
---
drivers/net/phy/vitesse.c | 31 ++++++++++++++++++++++++++++++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/vitesse.c b/drivers/net/phy/vitesse.c
index 2e37eb3..7923831 100644
--- a/drivers/net/phy/vitesse.c
+++ b/drivers/net/phy/vitesse.c
@@ -62,6 +62,10 @@
/* Vitesse Extended Page Access Register */
#define MII_VSC82X4_EXT_PAGE_ACCESS 0x1f
+/* Vitesse VSC8601 Extended PHY Control Register 1 */
+#define MII_VSC8601_EPHY_CTL 0x17
+#define MII_VSC8601_EPHY_CTL_RGMII_SKEW (1 << 8)
+
#define PHY_ID_VSC8234 0x000fc620
#define PHY_ID_VSC8244 0x000fc6c0
#define PHY_ID_VSC8514 0x00070670
@@ -111,6 +115,31 @@ static int vsc824x_config_init(struct phy_device *phydev)
return err;
}
+static int vsc8601_add_skew(struct phy_device *phydev)
+{
+ int ret;
+
+ ret = phy_read(phydev, MII_VSC8601_EPHY_CTL);
+ if (ret < 0)
+ return ret;
+
+ ret |= MII_VSC8601_EPHY_CTL_RGMII_SKEW;
+ return phy_write(phydev, MII_VSC8601_EPHY_CTL, ret);
+}
+
+static int vsc8601_config_init(struct phy_device *phydev)
+{
+ int ret = 0;
+
+ if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID)
+ ret = vsc8601_add_skew(phydev);
+
+ if (ret < 0)
+ return ret;
+
+ return genphy_config_init(phydev);
+}
+
static int vsc824x_ack_interrupt(struct phy_device *phydev)
{
int err = 0;
@@ -275,7 +304,7 @@ static struct phy_driver vsc82xx_driver[] = {
.phy_id_mask = 0x000ffff0,
.features = PHY_GBIT_FEATURES,
.flags = PHY_HAS_INTERRUPT,
- .config_init = &genphy_config_init,
+ .config_init = &vsc8601_config_init,
.config_aneg = &genphy_config_aneg,
.read_status = &genphy_read_status,
.ack_interrupt = &vsc824x_ack_interrupt,
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net-next v13 7/8] openvswitch: add Ethernet push and pop actions
From: Pravin Shelar @ 2016-11-12 23:57 UTC (permalink / raw)
To: Jiri Benc; +Cc: ovs dev, Linux Kernel Network Developers, Simon Horman
In-Reply-To: <fefa3d36d50639e176e831fefbc53d38ab2f04f6.1478791347.git.jbenc-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On Thu, Nov 10, 2016 at 7:28 AM, Jiri Benc <jbenc-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> It's not allowed to push Ethernet header in front of another Ethernet
> header.
>
> It's not allowed to pop Ethernet header if there's a vlan tag. This
> preserves the invariant that L3 packet never has a vlan tag.
>
> Based on previous versions by Lorand Jakab and Simon Horman.
>
> Signed-off-by: Lorand Jakab <lojakab-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>
> Signed-off-by: Simon Horman <simon.horman-wFxRvT7yatFl57MIdRCFDg@public.gmane.org>
> Signed-off-by: Jiri Benc <jbenc-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Acked-by: Pravin B Shelar <pshelar-LZ6Gd1LRuIk@public.gmane.org>
^ permalink raw reply
* Re: [PATCH net-next v13 5/8] openvswitch: add processing of L3 packets
From: Pravin Shelar @ 2016-11-12 23:58 UTC (permalink / raw)
To: Jiri Benc
Cc: Linux Kernel Network Developers, ovs dev, Lorand Jakab,
Simon Horman
In-Reply-To: <05254a13fdb29c1c3eaa1840ba2d127d98f8c418.1478791347.git.jbenc@redhat.com>
On Thu, Nov 10, 2016 at 7:28 AM, Jiri Benc <jbenc@redhat.com> wrote:
> Support receiving, extracting flow key and sending of L3 packets (packets
> without an Ethernet header).
>
> Note that even after this patch, non-Ethernet interfaces are still not
> allowed to be added to bridges. Similarly, netlink interface for sending and
> receiving L3 packets to/from user space is not in place yet.
>
> Based on previous versions by Lorand Jakab and Simon Horman.
>
> Signed-off-by: Lorand Jakab <lojakab@cisco.com>
> Signed-off-by: Simon Horman <simon.horman@netronome.com>
> Signed-off-by: Jiri Benc <jbenc@redhat.com>
> ---
> v13:
> - fix incorrect setting of packet to NULL in ovs_packet_cmd_execute
> - dropping packet for interfaces with wrong type
> ---
Thanks for working on this.
Acked-by: Pravin B Shelar <pshelar@ovn.org>
^ permalink raw reply
* Debugging Ethernet issues
From: Mason @ 2016-11-13 0:01 UTC (permalink / raw)
To: netdev
Cc: Florian Fainelli, Mans Rullgard, Sergei Shtylyov, Tom Lendacky,
Zach Brown, Andrew Lunn, Shaohui Xie, Tim Beale, Brian Hill,
Vince Bridgers, Balakumaran Kannan, David S. Miller,
Sebastian Frias, Kirill Kapranov
Hello everyone,
In a past thread ("Ethernet not working on a different SoC with
same eth HW") I was struggling getting Ethernet to work at all on
a new board using a recent 4.7 kernel.
After much hair-pulling, it turned out that *some* of the breakage
was caused by a local patch which should have been guarded by a
preprocessor macro.
But even after reverting that patch, Ethernet does not work well
on this board with kernel 4.7 whereas if I use an ancient 3.4 kernel,
then Ethernet works much better.
Differences:
When connected to a 100 Mbps switch
3.4 negotiates a LAN DHCP setup instantly
4.7 times out
When connected to a Gigabit switch
3.4 negotiates a LAN DHCP setup instantly
4.7 requires over 5 seconds to do so
(In case it matters, my board is using an Atheros 8035 PHY.)
I am aware that there have been hundreds of patches to the phy
and net frameworks in the 3.4 to 4.7 time-frame. I'm wondering
if there are important events I can log, to see what is going
wrong in the 4.7 case?
Are there kernel debugging options I might turn on, to better
understand what is going wrong?
I would be extremely grateful for any insight on this subject.
Regards.
^ permalink raw reply
* Re: Source address fib invalidation on IPv6
From: Jason A. Donenfeld @ 2016-11-13 0:43 UTC (permalink / raw)
To: David Ahern
Cc: Netdev, WireGuard mailing list, LKML, YOSHIFUJI Hideaki,
Hannes Frederic Sowa
In-Reply-To: <CAHmME9owJNvMfF9jHGW7i_jPMaxwPhxQE5W6cxjw14nL0HK0eQ@mail.gmail.com>
On Sat, Nov 12, 2016 at 8:08 PM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>> Gotcha. I don't see any checks that the saddr is valid similar to what IPv4 does.
>>
>> I think the right place to add a check is in ip6_dst_lookup_tail():
>> if (!ipv6_addr_any(&fl6->saddr)) {
>> // saddr is valid for L3 domain
>> }
>
> Right. It should probably do the check here, and return
> ERR_PTR(-EINVAL), the same as the v4 version, so that ret codes can be
> checked consistently.
>
> Thanks for looking into this. If you're backed up and would like me to
> submit a patch, just let me know, and I'll give it my best shot.
In perusing through the v6 FIB code, I don't even see an analog of
__ip_dev_find... Hm?
^ permalink raw reply
* Re: Source address fib invalidation on IPv6
From: Hannes Frederic Sowa @ 2016-11-13 0:51 UTC (permalink / raw)
To: Jason A. Donenfeld, David Ahern
Cc: Netdev, LKML, WireGuard mailing list, YOSHIFUJI Hideaki
In-Reply-To: <CAHmME9pMzcwjveOoa08-fVCnZTkaoMz8y9DEc7f6b-4PeWu4xQ@mail.gmail.com>
On Sun, Nov 13, 2016, at 01:43, Jason A. Donenfeld wrote:
> On Sat, Nov 12, 2016 at 8:08 PM, Jason A. Donenfeld <Jason@zx2c4.com>
> wrote:
> >> Gotcha. I don't see any checks that the saddr is valid similar to what IPv4 does.
> >>
> >> I think the right place to add a check is in ip6_dst_lookup_tail():
> >> if (!ipv6_addr_any(&fl6->saddr)) {
> >> // saddr is valid for L3 domain
> >> }
> >
> > Right. It should probably do the check here, and return
> > ERR_PTR(-EINVAL), the same as the v4 version, so that ret codes can be
> > checked consistently.
> >
> > Thanks for looking into this. If you're backed up and would like me to
> > submit a patch, just let me know, and I'll give it my best shot.
>
> In perusing through the v6 FIB code, I don't even see an analog of
> __ip_dev_find... Hm?
You probably need some combination of ipv6_chk_addr and/or
ipv6_check_addr_and_flags (where dev can also be NULL). Be careful if a
IFA_HOST or IFA_LINK address switches from one interface to another.
Bye,
Hannes
^ permalink raw reply
* Re: Source address fib invalidation on IPv6
From: Jason A. Donenfeld @ 2016-11-13 0:51 UTC (permalink / raw)
To: David Ahern
Cc: Netdev, Hannes Frederic Sowa, LKML, WireGuard mailing list,
YOSHIFUJI Hideaki
In-Reply-To: <CAHmME9pMzcwjveOoa08-fVCnZTkaoMz8y9DEc7f6b-4PeWu4xQ@mail.gmail.com>
On Sun, Nov 13, 2016 at 1:43 AM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> In perusing through the v6 FIB code, I don't even see an analog of
> __ip_dev_find... Hm?
Of all places, the iscsi code actually has a nice side-by-side
comparison. So far as I can see, the other protocols just omit this
check in the v6 case, which I believe to be errant behavior. For
example, grep for ip_dev_find in the sctp v4 code. The equivalent v6
code is missing the dev check. Ugly! Here's the block I found in
cxgbit_cm.c:
static struct net_device *cxgbit_ipv4_netdev(__be32 saddr)
{
struct net_device *ndev;
ndev = __ip_dev_find(&init_net, saddr, false);
if (!ndev)
return NULL;
return cxgbit_get_real_dev(ndev);
}
static struct net_device *cxgbit_ipv6_netdev(struct in6_addr *addr6)
{
struct net_device *ndev = NULL;
bool found = false;
if (IS_ENABLED(CONFIG_IPV6)) {
for_each_netdev_rcu(&init_net, ndev)
if (ipv6_chk_addr(&init_net, addr6, ndev, 1)) {
found = true;
break;
}
}
if (!found)
return NULL;
return cxgbit_get_real_dev(ndev);
}
It seems like __ip6_dev_find could be made out of that inner loop.
Then existing uses like that iscsi code can be replaced with that
helper function, and the existing ip6 route tail function can be
augmented in the manner you recommended. Seem like a decent
implementation strategy?
I might submit some patches, unless you beat me to it.
Jason
^ permalink raw reply
* Re: Source address fib invalidation on IPv6
From: Jason A. Donenfeld @ 2016-11-13 1:00 UTC (permalink / raw)
To: Hannes Frederic Sowa
Cc: David Ahern, YOSHIFUJI Hideaki, LKML, WireGuard mailing list,
Netdev
In-Reply-To: <1478998272.2299343.785875225.19237693@webmail.messagingengine.com>
Hi Hannes,
On Sun, Nov 13, 2016 at 1:51 AM, Hannes Frederic Sowa
<hannes@stressinduktion.org> wrote:
> You probably need some combination of ipv6_chk_addr and/or
> ipv6_check_addr_and_flags (where dev can also be NULL). Be careful if a
> IFA_HOST or IFA_LINK address switches from one interface to another.
I can confirm this trick works beautifully:
https://git.zx2c4.com/WireGuard/commit/?id=eb65810fc6350c50b42abedd1291b12337d3dc3d
I'll see if I can fold this into the routing function so that it
behaves the same as v4, unless David gets there first.
Regards,
Jason
^ permalink raw reply
* Re: [PATCH] r8169: Module parameter for opt-in of ASPM
From: David Miller @ 2016-11-13 2:02 UTC (permalink / raw)
To: kastbernd; +Cc: nic_swsd, netdev, linux-kernel
In-Reply-To: <20161103233306.GA9368@ASUS-Bernd.fritz.box>
From: Kast Bernd <kastbernd@gmx.de>
Date: Fri, 4 Nov 2016 00:33:06 +0100
> This patch adds a module parameter in order to activate ASPM. By that
> the CPU can enter deep sleep modes (PC6) and power consumption can be
> reduced (for example from 13W to 8W on my notebook with a Haswell CPU).
> Basically, it reapplies d64ec841517a25f6d468bde9f67e5b4cffdc67c7, which
> was reverted due to delayed link status detection and increased boot
> times on some systems. These bugs are avoided by two actions:
> 1) ASPM is turned off by default to avoid any problems with the
> default configuration.
> 2) Flags for ASPM and clock request are set after ephy_init,
> which wasn't respected on the previous patch. Thus ASPM with
> this patch could work even with previously failing systems.
This feels like grasping at straws.
If you feel you've corrected a flaw in the previous ASPM
support, then let's reinstate it unconditionally without
some module parameter.
We'll never find out if you actually did fix ASPM support
sufficiently if it's off by default.
Only experts like you will ever enable the option. It's
usage will be minimal, and therefore the benefits will not
be sufficient to justify these changes in the first place.
^ permalink raw reply
* Re: [PATCH] net: ethernet: ti: davinci_cpdma: free memory while channel destroy
From: David Miller @ 2016-11-13 2:07 UTC (permalink / raw)
To: ivan.khoronzhuk
Cc: mugunthanvnm, grygorii.strashko, netdev, linux-omap, linux-kernel
In-Reply-To: <1478610965-25288-1-git-send-email-ivan.khoronzhuk@linaro.org>
From: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
Date: Tue, 8 Nov 2016 15:16:05 +0200
> While create/destroy channel operation memory is not freed. It was
> supposed that memory is freed while driver remove. But a channel
> can be created and destroyed many times while changing number of
> channels with ethtool.
>
> Based on net-next/master
>
> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
Applied.
^ permalink raw reply
* Re: Debugging Ethernet issues
From: Andrew Lunn @ 2016-11-13 3:09 UTC (permalink / raw)
To: Mason
Cc: netdev, Florian Fainelli, Mans Rullgard, Sergei Shtylyov,
Tom Lendacky, Zach Brown, Shaohui Xie, Tim Beale, Brian Hill,
Vince Bridgers, Balakumaran Kannan, David S. Miller,
Sebastian Frias, Kirill Kapranov
In-Reply-To: <5827AD4A.7010908@free.fr>
> When connected to a Gigabit switch
> 3.4 negotiates a LAN DHCP setup instantly
> 4.7 requires over 5 seconds to do so
When you run tcpdump on the DHCP server, are you noticing the first
request is missing?
What can happen is the dhclient gets started immediately and sends out
its first request before auto-negotiation has finished. So this first packet
gets lost. The retransmit after a few seconds is then successful.
Andrew
^ permalink raw reply
* Re: [PATCH 0/2] bnx2: Hard reset bnx2 chip at probe stage
From: Baoquan He @ 2016-11-13 4:10 UTC (permalink / raw)
To: Michael Chan
Cc: Netdev, open list, Dept-GELinuxNICDev, rasesh.mody, harish.patil,
frank, jsr, pmenzel, jroedel, dyoung
In-Reply-To: <CACKFLimGyhzPY=0ehHGG7e0w58i7XfuTmAcsrjMwzc3weGNCjA@mail.gmail.com>
Hi Michael,
On 11/11/16 at 09:37am, Michael Chan wrote:
> On Fri, Nov 11, 2016 at 6:02 AM, Baoquan He <bhe@redhat.com> wrote:
> > On 11/11/16 at 09:46pm, Baoquan He wrote:
> >> Hi bnx2 experts,
> >>
> >> In commit 3e1be7a ("bnx2: Reset device during driver initialization"),
> >> firmware requesting code was moved from open stage to probe stage.
> >> The reason is in kdump kernel hardware iommu need device be reset in
> >> driver probe stage, otherwise those in-flight DMA from 1st kernel
> >> will continue going and look up into the newly created io-page tables.
> >> So we need reset device to stop in-flight DMA as early as possibe.
> >>
> >> But with commit 3e1be7a merged, people reported their bnx2 driver init
> >> failed because of failed firmware loading. After discussion, it's found
> >> that they built bnx2 driver into kernel, and that makes probe function
> >> bnx2_init_one be called in do_initcalls(). But at this time the initramfs
> >> has not been uncompressed yet and mounted, kernel can't detect firmware.
> >>
> >> So there's only one way to cover both. Try to hard reset the bnx2 device
> >> at probe stage, without involving firmware issues. I tried to add function
> >> bnx2_hard_reset_chip() to do this and it's only called in kdump kernel.
> >> The thing is I am not quite familiar with bnx2 chip spec, just abstract
> >> code from bnx2_reset_chip, the testing result is good.
> >
> > Here I changed to send BNX2_MISC_COMMAND_HD_RESET in BNX2_CHIP_5709
> > case.
> >
>
> From my old 5709 Documentation:
>
> Bit 6 HD_RESET: Writing this bit as 1 will cause the chip to do a
> hard reset like bit 5 except the sticky bits in the PCI function are
> not reset.
>
> Bit 5 POR_RESET: Writing this bit as 1 will cause the chip to do an
> internal reset exactly like a power-up reset. There is no protection
> for this request and it may cause any current PCI cycle to lock up.
> This reset is intended for use under manufacturing conditions only.
>
> So it sounds like doing HD_RESET can potentially cause a PCI bus lock up.
>
> Why not just disable DMA gracefully as done at the beginning of
> bnx2_reset_chip()?
Thanks for your suggestion.
If what I undertand is correct, you meant waiting for the current PCI
transaction to complete, right? I tried and it also works. I like this
idea, will repost v2. Please help check if it meets your thoughts.
Thanks
Baoquan
^ permalink raw reply
* [PATCH v2 2/2] bnx2: Wait for in-flight DMA to complete at probe stage
From: Baoquan He @ 2016-11-13 4:15 UTC (permalink / raw)
To: netdev, Michael Chan
Cc: linux-kernel, Dept-GELinuxNICDev, rasesh.mody, harish.patil,
frank, jsr, pmenzel, jroedel, dyoung
In-Reply-To: <1478871995-29652-3-git-send-email-bhe@redhat.com>
In-flight DMA from 1st kernel could continue going in kdump kernel.
New io-page table has been created before bnx2 does reset at open stage.
We have to wait for the in-flight DMA to complete to avoid it look up
into the newly created io-page table at probe stage.
Suggested-by: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: Baoquan He <bhe@redhat.com>
---
v1->v2:
Michael suggested to wait for the in-flight DMA to complete at probe
stage. So give up the old method of trying to reset chip at probe
stage, take the new way accordingly.
drivers/net/ethernet/broadcom/bnx2.c | 38 ++++++++++++++++++++++++++++++------
1 file changed, 32 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2.c b/drivers/net/ethernet/broadcom/bnx2.c
index c557972..1f7034d 100644
--- a/drivers/net/ethernet/broadcom/bnx2.c
+++ b/drivers/net/ethernet/broadcom/bnx2.c
@@ -49,6 +49,7 @@
#include <linux/firmware.h>
#include <linux/log2.h>
#include <linux/aer.h>
+#include <linux/crash_dump.h>
#if IS_ENABLED(CONFIG_CNIC)
#define BCM_CNIC 1
@@ -4764,15 +4765,16 @@ bnx2_setup_msix_tbl(struct bnx2 *bp)
BNX2_WR(bp, BNX2_PCI_GRC_WINDOW3_ADDR, BNX2_MSIX_PBA_ADDR);
}
-static int
-bnx2_reset_chip(struct bnx2 *bp, u32 reset_code)
+static void
+bnx2_wait_dma_complete(struct bnx2 *bp)
{
u32 val;
- int i, rc = 0;
- u8 old_port;
+ int i;
- /* Wait for the current PCI transaction to complete before
- * issuing a reset. */
+ /*
+ * Wait for the current PCI transaction to complete before
+ * issuing a reset.
+ */
if ((BNX2_CHIP(bp) == BNX2_CHIP_5706) ||
(BNX2_CHIP(bp) == BNX2_CHIP_5708)) {
BNX2_WR(bp, BNX2_MISC_ENABLE_CLR_BITS,
@@ -4796,6 +4798,21 @@ bnx2_reset_chip(struct bnx2 *bp, u32 reset_code)
}
}
+ return;
+}
+
+
+static int
+bnx2_reset_chip(struct bnx2 *bp, u32 reset_code)
+{
+ u32 val;
+ int i, rc = 0;
+ u8 old_port;
+
+ /* Wait for the current PCI transaction to complete before
+ * issuing a reset. */
+ bnx2_wait_dma_complete(bp);
+
/* Wait for the firmware to tell us it is ok to issue a reset. */
bnx2_fw_sync(bp, BNX2_DRV_MSG_DATA_WAIT0 | reset_code, 1, 1);
@@ -8580,6 +8597,15 @@ bnx2_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
pci_set_drvdata(pdev, dev);
+ /*
+ * In-flight DMA from 1st kernel could continue going in kdump kernel.
+ * New io-page table has been created before bnx2 does reset at open stage.
+ * We have to wait for the in-flight DMA to complete to avoid it look up
+ * into the newly created io-page table.
+ */
+ if (is_kdump_kernel())
+ bnx2_wait_dma_complete(bp);
+
memcpy(dev->dev_addr, bp->mac_addr, ETH_ALEN);
dev->hw_features = NETIF_F_IP_CSUM | NETIF_F_SG |
--
2.5.5
^ permalink raw reply related
* Re: [PATCH net-next] bpf, mlx4: fix prog refcount in mlx4_en_try_alloc_resources error path
From: David Miller @ 2016-11-13 4:34 UTC (permalink / raw)
To: daniel; +Cc: alexei.starovoitov, bblanco, tariqt, zhiyisun, netdev
In-Reply-To: <9d5b1ed1b70a8a4db545c308bcb5b28280564798.1478724690.git.daniel@iogearbox.net>
From: Daniel Borkmann <daniel@iogearbox.net>
Date: Wed, 9 Nov 2016 22:02:34 +0100
> Commit 67f8b1dcb9ee ("net/mlx4_en: Refactor the XDP forwarding rings
> scheme") added a bug in that the prog's reference count is not dropped
> in the error path when mlx4_en_try_alloc_resources() is failing from
> mlx4_xdp_set().
>
> We previously took bpf_prog_add(prog, priv->rx_ring_num - 1), that we
> need to release again. Earlier in the call path, dev_change_xdp_fd()
> itself holds a reference to the prog as well (hence the '- 1' in the
> bpf_prog_add()), so a simple atomic_sub() is safe to use here. When
> an error is propagated, then bpf_prog_put() is called eventually from
> dev_change_xdp_fd()
>
> Fixes: 67f8b1dcb9ee ("net/mlx4_en: Refactor the XDP forwarding rings scheme")
> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Applied, thanks Daniel.
^ permalink raw reply
* Re: [PATCHv2 net] igmp: do not remove igmp souce list info when set link down
From: David Miller @ 2016-11-13 4:29 UTC (permalink / raw)
To: liuhangbin; +Cc: netdev, hannes, daniel
In-Reply-To: <1478661400-10152-1-git-send-email-liuhangbin@gmail.com>
From: Hangbin Liu <liuhangbin@gmail.com>
Date: Wed, 9 Nov 2016 11:16:40 +0800
> In commit 24cf3af(igmp: call ip_mc_clear_src...), we forgot to remove
> igmpv3_clear_delrec() in ip_mc_down(), which also called ip_mc_clear_src().
> This make us clear all IGMPv3 source filter info after NETDEV_DOWN.
> Move igmpv3_clear_delrec() to ip_mc_destroy_dev() and then no need
> ip_mc_clear_src() in ip_mc_destroy_dev().
>
> On the other hand, we should restore back instead of free all source filter
> info in igmpv3_del_delrec(). Or we will not able to restore IGMPv3 source
> filter info after NETDEV_UP and NETDEV_POST_TYPE_CHANGE.
>
> Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
Commits must be referenced with 12 characters of significance in the
SHA1-ID and appear in an appropriately formed "Fixes: " tag right
before the signoffs.
As-per Documentation/SubmittingPatches.
It also doesn't look so good how you lack a space between the SHA1-ID
and the commit message header text reference.
^ 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