* Re: Strange routing with VRF and 5.2.7+
From: David Ahern @ 2019-09-22 19:23 UTC (permalink / raw)
To: Ben Greear, netdev
In-Reply-To: <7d1de949-5cf0-cb74-6ca3-52315c34a340@candelatech.com>
On 9/20/19 9:57 AM, Ben Greear wrote:
> On 9/10/19 6:08 PM, Ben Greear wrote:
>> On 9/10/19 3:17 PM, Ben Greear wrote:
>>> Today we were testing creating 200 virtual station vdevs on ath9k,
>>> and using
>>> VRF for the routing.
>>
>> Looks like the same issue happens w/out VRF, but there I have oodles
>> of routing
>> rules, so it is an area ripe for failure.
>>
>> Will upgrade to 5.2.14+ and retest, and try 4.20 as well....
>
> Turns out, this was ipsec (strongswan) inserting a rule that pointed to
> a table
> that we then used for a vrf w/out realizing the rule was added.
>
> Stopping strongswan and/or reconfiguring how routing tables are assigned
> resolved the issue.
>
Hi Ben:
Since you are the pioneer with vrf and ipsec, can you add an ipsec
section with some notes to Documentation/networking/vrf.txt?
^ permalink raw reply
* [PATCH AUTOSEL 5.2 171/185] libertas: Add missing sentinel at end of if_usb.c fw_table
From: Sasha Levin @ 2019-09-22 18:49 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Kevin Easton, syzbot+98156c174c5a2cad9f8f, Kalle Valo,
Sasha Levin, libertas-dev, linux-wireless, netdev
In-Reply-To: <20190922184924.32534-1-sashal@kernel.org>
From: Kevin Easton <kevin@guarana.org>
[ Upstream commit 764f3f1ecffc434096e0a2b02f1a6cc964a89df6 ]
This sentinel tells the firmware loading process when to stop.
Reported-and-tested-by: syzbot+98156c174c5a2cad9f8f@syzkaller.appspotmail.com
Signed-off-by: Kevin Easton <kevin@guarana.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/marvell/libertas/if_usb.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/marvell/libertas/if_usb.c b/drivers/net/wireless/marvell/libertas/if_usb.c
index f1622f0ff8c9e..fe3142d85d1e4 100644
--- a/drivers/net/wireless/marvell/libertas/if_usb.c
+++ b/drivers/net/wireless/marvell/libertas/if_usb.c
@@ -50,7 +50,8 @@ static const struct lbs_fw_table fw_table[] = {
{ MODEL_8388, "libertas/usb8388_v5.bin", NULL },
{ MODEL_8388, "libertas/usb8388.bin", NULL },
{ MODEL_8388, "usb8388.bin", NULL },
- { MODEL_8682, "libertas/usb8682.bin", NULL }
+ { MODEL_8682, "libertas/usb8682.bin", NULL },
+ { 0, NULL, NULL }
};
static const struct usb_device_id if_usb_table[] = {
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.2 172/185] e1000e: add workaround for possible stalled packet
From: Sasha Levin @ 2019-09-22 18:49 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Kai-Heng Feng, Aaron Brown, Jeff Kirsher, Sasha Levin, netdev
In-Reply-To: <20190922184924.32534-1-sashal@kernel.org>
From: Kai-Heng Feng <kai.heng.feng@canonical.com>
[ Upstream commit e5e9a2ecfe780975820e157b922edee715710b66 ]
This works around a possible stalled packet issue, which may occur due to
clock recovery from the PCH being too slow, when the LAN is transitioning
from K1 at 1G link speed.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204057
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/intel/e1000e/ich8lan.c | 10 ++++++++++
drivers/net/ethernet/intel/e1000e/ich8lan.h | 2 +-
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/e1000e/ich8lan.c b/drivers/net/ethernet/intel/e1000e/ich8lan.c
index cdae0efde8e64..7998a73b6a0fa 100644
--- a/drivers/net/ethernet/intel/e1000e/ich8lan.c
+++ b/drivers/net/ethernet/intel/e1000e/ich8lan.c
@@ -1429,6 +1429,16 @@ static s32 e1000_check_for_copper_link_ich8lan(struct e1000_hw *hw)
else
phy_reg |= 0xFA;
e1e_wphy_locked(hw, I217_PLL_CLOCK_GATE_REG, phy_reg);
+
+ if (speed == SPEED_1000) {
+ hw->phy.ops.read_reg_locked(hw, HV_PM_CTRL,
+ &phy_reg);
+
+ phy_reg |= HV_PM_CTRL_K1_CLK_REQ;
+
+ hw->phy.ops.write_reg_locked(hw, HV_PM_CTRL,
+ phy_reg);
+ }
}
hw->phy.ops.release(hw);
diff --git a/drivers/net/ethernet/intel/e1000e/ich8lan.h b/drivers/net/ethernet/intel/e1000e/ich8lan.h
index eb09c755fa172..1502895eb45dd 100644
--- a/drivers/net/ethernet/intel/e1000e/ich8lan.h
+++ b/drivers/net/ethernet/intel/e1000e/ich8lan.h
@@ -210,7 +210,7 @@
/* PHY Power Management Control */
#define HV_PM_CTRL PHY_REG(770, 17)
-#define HV_PM_CTRL_PLL_STOP_IN_K1_GIGA 0x100
+#define HV_PM_CTRL_K1_CLK_REQ 0x200
#define HV_PM_CTRL_K1_ENABLE 0x4000
#define I217_PLL_CLOCK_GATE_REG PHY_REG(772, 28)
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 121/128] libertas: Add missing sentinel at end of if_usb.c fw_table
From: Sasha Levin @ 2019-09-22 18:54 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Kevin Easton, syzbot+98156c174c5a2cad9f8f, Kalle Valo,
Sasha Levin, libertas-dev, linux-wireless, netdev
In-Reply-To: <20190922185418.2158-1-sashal@kernel.org>
From: Kevin Easton <kevin@guarana.org>
[ Upstream commit 764f3f1ecffc434096e0a2b02f1a6cc964a89df6 ]
This sentinel tells the firmware loading process when to stop.
Reported-and-tested-by: syzbot+98156c174c5a2cad9f8f@syzkaller.appspotmail.com
Signed-off-by: Kevin Easton <kevin@guarana.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/marvell/libertas/if_usb.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/marvell/libertas/if_usb.c b/drivers/net/wireless/marvell/libertas/if_usb.c
index 3dbfce972c56b..9e82ec12564bb 100644
--- a/drivers/net/wireless/marvell/libertas/if_usb.c
+++ b/drivers/net/wireless/marvell/libertas/if_usb.c
@@ -49,7 +49,8 @@ static const struct lbs_fw_table fw_table[] = {
{ MODEL_8388, "libertas/usb8388_v5.bin", NULL },
{ MODEL_8388, "libertas/usb8388.bin", NULL },
{ MODEL_8388, "usb8388.bin", NULL },
- { MODEL_8682, "libertas/usb8682.bin", NULL }
+ { MODEL_8682, "libertas/usb8682.bin", NULL },
+ { 0, NULL, NULL }
};
static const struct usb_device_id if_usb_table[] = {
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 122/128] e1000e: add workaround for possible stalled packet
From: Sasha Levin @ 2019-09-22 18:54 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Kai-Heng Feng, Aaron Brown, Jeff Kirsher, Sasha Levin, netdev
In-Reply-To: <20190922185418.2158-1-sashal@kernel.org>
From: Kai-Heng Feng <kai.heng.feng@canonical.com>
[ Upstream commit e5e9a2ecfe780975820e157b922edee715710b66 ]
This works around a possible stalled packet issue, which may occur due to
clock recovery from the PCH being too slow, when the LAN is transitioning
from K1 at 1G link speed.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204057
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/intel/e1000e/ich8lan.c | 10 ++++++++++
drivers/net/ethernet/intel/e1000e/ich8lan.h | 2 +-
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/e1000e/ich8lan.c b/drivers/net/ethernet/intel/e1000e/ich8lan.c
index cdae0efde8e64..7998a73b6a0fa 100644
--- a/drivers/net/ethernet/intel/e1000e/ich8lan.c
+++ b/drivers/net/ethernet/intel/e1000e/ich8lan.c
@@ -1429,6 +1429,16 @@ static s32 e1000_check_for_copper_link_ich8lan(struct e1000_hw *hw)
else
phy_reg |= 0xFA;
e1e_wphy_locked(hw, I217_PLL_CLOCK_GATE_REG, phy_reg);
+
+ if (speed == SPEED_1000) {
+ hw->phy.ops.read_reg_locked(hw, HV_PM_CTRL,
+ &phy_reg);
+
+ phy_reg |= HV_PM_CTRL_K1_CLK_REQ;
+
+ hw->phy.ops.write_reg_locked(hw, HV_PM_CTRL,
+ phy_reg);
+ }
}
hw->phy.ops.release(hw);
diff --git a/drivers/net/ethernet/intel/e1000e/ich8lan.h b/drivers/net/ethernet/intel/e1000e/ich8lan.h
index eb09c755fa172..1502895eb45dd 100644
--- a/drivers/net/ethernet/intel/e1000e/ich8lan.h
+++ b/drivers/net/ethernet/intel/e1000e/ich8lan.h
@@ -210,7 +210,7 @@
/* PHY Power Management Control */
#define HV_PM_CTRL PHY_REG(770, 17)
-#define HV_PM_CTRL_PLL_STOP_IN_K1_GIGA 0x100
+#define HV_PM_CTRL_K1_CLK_REQ 0x200
#define HV_PM_CTRL_K1_ENABLE 0x4000
#define I217_PLL_CLOCK_GATE_REG PHY_REG(772, 28)
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.14 84/89] e1000e: add workaround for possible stalled packet
From: Sasha Levin @ 2019-09-22 18:57 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Kai-Heng Feng, Aaron Brown, Jeff Kirsher, Sasha Levin, netdev
In-Reply-To: <20190922185717.3412-1-sashal@kernel.org>
From: Kai-Heng Feng <kai.heng.feng@canonical.com>
[ Upstream commit e5e9a2ecfe780975820e157b922edee715710b66 ]
This works around a possible stalled packet issue, which may occur due to
clock recovery from the PCH being too slow, when the LAN is transitioning
from K1 at 1G link speed.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204057
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/intel/e1000e/ich8lan.c | 10 ++++++++++
drivers/net/ethernet/intel/e1000e/ich8lan.h | 2 +-
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/e1000e/ich8lan.c b/drivers/net/ethernet/intel/e1000e/ich8lan.c
index 00eedf202e62d..1e990f9dd3794 100644
--- a/drivers/net/ethernet/intel/e1000e/ich8lan.c
+++ b/drivers/net/ethernet/intel/e1000e/ich8lan.c
@@ -1447,6 +1447,16 @@ static s32 e1000_check_for_copper_link_ich8lan(struct e1000_hw *hw)
else
phy_reg |= 0xFA;
e1e_wphy_locked(hw, I217_PLL_CLOCK_GATE_REG, phy_reg);
+
+ if (speed == SPEED_1000) {
+ hw->phy.ops.read_reg_locked(hw, HV_PM_CTRL,
+ &phy_reg);
+
+ phy_reg |= HV_PM_CTRL_K1_CLK_REQ;
+
+ hw->phy.ops.write_reg_locked(hw, HV_PM_CTRL,
+ phy_reg);
+ }
}
hw->phy.ops.release(hw);
diff --git a/drivers/net/ethernet/intel/e1000e/ich8lan.h b/drivers/net/ethernet/intel/e1000e/ich8lan.h
index 00a36df02a3fd..88df80c0894b1 100644
--- a/drivers/net/ethernet/intel/e1000e/ich8lan.h
+++ b/drivers/net/ethernet/intel/e1000e/ich8lan.h
@@ -228,7 +228,7 @@
/* PHY Power Management Control */
#define HV_PM_CTRL PHY_REG(770, 17)
-#define HV_PM_CTRL_PLL_STOP_IN_K1_GIGA 0x100
+#define HV_PM_CTRL_K1_CLK_REQ 0x200
#define HV_PM_CTRL_K1_ENABLE 0x4000
#define I217_PLL_CLOCK_GATE_REG PHY_REG(772, 28)
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.14 83/89] libertas: Add missing sentinel at end of if_usb.c fw_table
From: Sasha Levin @ 2019-09-22 18:57 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Kevin Easton, syzbot+98156c174c5a2cad9f8f, Kalle Valo,
Sasha Levin, libertas-dev, linux-wireless, netdev
In-Reply-To: <20190922185717.3412-1-sashal@kernel.org>
From: Kevin Easton <kevin@guarana.org>
[ Upstream commit 764f3f1ecffc434096e0a2b02f1a6cc964a89df6 ]
This sentinel tells the firmware loading process when to stop.
Reported-and-tested-by: syzbot+98156c174c5a2cad9f8f@syzkaller.appspotmail.com
Signed-off-by: Kevin Easton <kevin@guarana.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/marvell/libertas/if_usb.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/marvell/libertas/if_usb.c b/drivers/net/wireless/marvell/libertas/if_usb.c
index e4ae2b5a71c25..aad82ff568835 100644
--- a/drivers/net/wireless/marvell/libertas/if_usb.c
+++ b/drivers/net/wireless/marvell/libertas/if_usb.c
@@ -49,7 +49,8 @@ static const struct lbs_fw_table fw_table[] = {
{ MODEL_8388, "libertas/usb8388_v5.bin", NULL },
{ MODEL_8388, "libertas/usb8388.bin", NULL },
{ MODEL_8388, "usb8388.bin", NULL },
- { MODEL_8682, "libertas/usb8682.bin", NULL }
+ { MODEL_8682, "libertas/usb8682.bin", NULL },
+ { 0, NULL, NULL }
};
static const struct usb_device_id if_usb_table[] = {
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.9 26/60] net: lpc-enet: fix printk format strings
From: Sasha Levin @ 2019-09-22 18:58 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Arnd Bergmann, kbuild test robot, Sasha Levin, netdev
In-Reply-To: <20190922185934.4305-1-sashal@kernel.org>
From: Arnd Bergmann <arnd@arndb.de>
[ Upstream commit de6f97b2bace0e2eb6c3a86e124d1e652a587b56 ]
compile-testing this driver on other architectures showed
multiple warnings:
drivers/net/ethernet/nxp/lpc_eth.c: In function 'lpc_eth_drv_probe':
drivers/net/ethernet/nxp/lpc_eth.c:1337:19: warning: format '%d' expects argument of type 'int', but argument 4 has type 'resource_size_t {aka long long unsigned int}' [-Wformat=]
drivers/net/ethernet/nxp/lpc_eth.c:1342:19: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'dma_addr_t {aka long long unsigned int}' [-Wformat=]
Use format strings that work on all architectures.
Link: https://lore.kernel.org/r/20190809144043.476786-10-arnd@arndb.de
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/nxp/lpc_eth.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/nxp/lpc_eth.c b/drivers/net/ethernet/nxp/lpc_eth.c
index 8e13ec84c5381..9fcaf19106335 100644
--- a/drivers/net/ethernet/nxp/lpc_eth.c
+++ b/drivers/net/ethernet/nxp/lpc_eth.c
@@ -1374,13 +1374,14 @@ static int lpc_eth_drv_probe(struct platform_device *pdev)
pldat->dma_buff_base_p = dma_handle;
netdev_dbg(ndev, "IO address space :%pR\n", res);
- netdev_dbg(ndev, "IO address size :%d\n", resource_size(res));
+ netdev_dbg(ndev, "IO address size :%zd\n",
+ (size_t)resource_size(res));
netdev_dbg(ndev, "IO address (mapped) :0x%p\n",
pldat->net_base);
netdev_dbg(ndev, "IRQ number :%d\n", ndev->irq);
- netdev_dbg(ndev, "DMA buffer size :%d\n", pldat->dma_buff_size);
- netdev_dbg(ndev, "DMA buffer P address :0x%08x\n",
- pldat->dma_buff_base_p);
+ netdev_dbg(ndev, "DMA buffer size :%zd\n", pldat->dma_buff_size);
+ netdev_dbg(ndev, "DMA buffer P address :%pad\n",
+ &pldat->dma_buff_base_p);
netdev_dbg(ndev, "DMA buffer V address :0x%p\n",
pldat->dma_buff_base_v);
@@ -1427,8 +1428,8 @@ static int lpc_eth_drv_probe(struct platform_device *pdev)
if (ret)
goto err_out_unregister_netdev;
- netdev_info(ndev, "LPC mac at 0x%08x irq %d\n",
- res->start, ndev->irq);
+ netdev_info(ndev, "LPC mac at 0x%08lx irq %d\n",
+ (unsigned long)res->start, ndev->irq);
phydev = ndev->phydev;
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.9 55/60] libertas: Add missing sentinel at end of if_usb.c fw_table
From: Sasha Levin @ 2019-09-22 18:59 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Kevin Easton, syzbot+98156c174c5a2cad9f8f, Kalle Valo,
Sasha Levin, libertas-dev, linux-wireless, netdev
In-Reply-To: <20190922185934.4305-1-sashal@kernel.org>
From: Kevin Easton <kevin@guarana.org>
[ Upstream commit 764f3f1ecffc434096e0a2b02f1a6cc964a89df6 ]
This sentinel tells the firmware loading process when to stop.
Reported-and-tested-by: syzbot+98156c174c5a2cad9f8f@syzkaller.appspotmail.com
Signed-off-by: Kevin Easton <kevin@guarana.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/marvell/libertas/if_usb.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/marvell/libertas/if_usb.c b/drivers/net/wireless/marvell/libertas/if_usb.c
index a605d569f663a..9d147b11ee516 100644
--- a/drivers/net/wireless/marvell/libertas/if_usb.c
+++ b/drivers/net/wireless/marvell/libertas/if_usb.c
@@ -49,7 +49,8 @@ static const struct lbs_fw_table fw_table[] = {
{ MODEL_8388, "libertas/usb8388_v5.bin", NULL },
{ MODEL_8388, "libertas/usb8388.bin", NULL },
{ MODEL_8388, "usb8388.bin", NULL },
- { MODEL_8682, "libertas/usb8682.bin", NULL }
+ { MODEL_8682, "libertas/usb8682.bin", NULL },
+ { 0, NULL, NULL }
};
static struct usb_device_id if_usb_table[] = {
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.4 41/44] libertas: Add missing sentinel at end of if_usb.c fw_table
From: Sasha Levin @ 2019-09-22 19:00 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Kevin Easton, syzbot+98156c174c5a2cad9f8f, Kalle Valo,
Sasha Levin, linux-wireless, netdev
In-Reply-To: <20190922190103.4906-1-sashal@kernel.org>
From: Kevin Easton <kevin@guarana.org>
[ Upstream commit 764f3f1ecffc434096e0a2b02f1a6cc964a89df6 ]
This sentinel tells the firmware loading process when to stop.
Reported-and-tested-by: syzbot+98156c174c5a2cad9f8f@syzkaller.appspotmail.com
Signed-off-by: Kevin Easton <kevin@guarana.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/libertas/if_usb.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/libertas/if_usb.c b/drivers/net/wireless/libertas/if_usb.c
index dff08a2896a38..d271eaf1f9499 100644
--- a/drivers/net/wireless/libertas/if_usb.c
+++ b/drivers/net/wireless/libertas/if_usb.c
@@ -49,7 +49,8 @@ static const struct lbs_fw_table fw_table[] = {
{ MODEL_8388, "libertas/usb8388_v5.bin", NULL },
{ MODEL_8388, "libertas/usb8388.bin", NULL },
{ MODEL_8388, "usb8388.bin", NULL },
- { MODEL_8682, "libertas/usb8682.bin", NULL }
+ { MODEL_8682, "libertas/usb8682.bin", NULL },
+ { 0, NULL, NULL }
};
static struct usb_device_id if_usb_table[] = {
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.4 23/44] net: lpc-enet: fix printk format strings
From: Sasha Levin @ 2019-09-22 19:00 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Arnd Bergmann, kbuild test robot, Sasha Levin, netdev
In-Reply-To: <20190922190103.4906-1-sashal@kernel.org>
From: Arnd Bergmann <arnd@arndb.de>
[ Upstream commit de6f97b2bace0e2eb6c3a86e124d1e652a587b56 ]
compile-testing this driver on other architectures showed
multiple warnings:
drivers/net/ethernet/nxp/lpc_eth.c: In function 'lpc_eth_drv_probe':
drivers/net/ethernet/nxp/lpc_eth.c:1337:19: warning: format '%d' expects argument of type 'int', but argument 4 has type 'resource_size_t {aka long long unsigned int}' [-Wformat=]
drivers/net/ethernet/nxp/lpc_eth.c:1342:19: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'dma_addr_t {aka long long unsigned int}' [-Wformat=]
Use format strings that work on all architectures.
Link: https://lore.kernel.org/r/20190809144043.476786-10-arnd@arndb.de
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/nxp/lpc_eth.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/nxp/lpc_eth.c b/drivers/net/ethernet/nxp/lpc_eth.c
index 057665180f13f..ba14bad81a21f 100644
--- a/drivers/net/ethernet/nxp/lpc_eth.c
+++ b/drivers/net/ethernet/nxp/lpc_eth.c
@@ -1417,13 +1417,14 @@ static int lpc_eth_drv_probe(struct platform_device *pdev)
pldat->dma_buff_base_p = dma_handle;
netdev_dbg(ndev, "IO address space :%pR\n", res);
- netdev_dbg(ndev, "IO address size :%d\n", resource_size(res));
+ netdev_dbg(ndev, "IO address size :%zd\n",
+ (size_t)resource_size(res));
netdev_dbg(ndev, "IO address (mapped) :0x%p\n",
pldat->net_base);
netdev_dbg(ndev, "IRQ number :%d\n", ndev->irq);
- netdev_dbg(ndev, "DMA buffer size :%d\n", pldat->dma_buff_size);
- netdev_dbg(ndev, "DMA buffer P address :0x%08x\n",
- pldat->dma_buff_base_p);
+ netdev_dbg(ndev, "DMA buffer size :%zd\n", pldat->dma_buff_size);
+ netdev_dbg(ndev, "DMA buffer P address :%pad\n",
+ &pldat->dma_buff_base_p);
netdev_dbg(ndev, "DMA buffer V address :0x%p\n",
pldat->dma_buff_base_v);
@@ -1470,8 +1471,8 @@ static int lpc_eth_drv_probe(struct platform_device *pdev)
if (ret)
goto err_out_unregister_netdev;
- netdev_info(ndev, "LPC mac at 0x%08x irq %d\n",
- res->start, ndev->irq);
+ netdev_info(ndev, "LPC mac at 0x%08lx irq %d\n",
+ (unsigned long)res->start, ndev->irq);
phydev = pldat->phy_dev;
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.9 56/60] e1000e: add workaround for possible stalled packet
From: Sasha Levin @ 2019-09-22 18:59 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Kai-Heng Feng, Aaron Brown, Jeff Kirsher, Sasha Levin, netdev
In-Reply-To: <20190922185934.4305-1-sashal@kernel.org>
From: Kai-Heng Feng <kai.heng.feng@canonical.com>
[ Upstream commit e5e9a2ecfe780975820e157b922edee715710b66 ]
This works around a possible stalled packet issue, which may occur due to
clock recovery from the PCH being too slow, when the LAN is transitioning
from K1 at 1G link speed.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204057
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/intel/e1000e/ich8lan.c | 10 ++++++++++
drivers/net/ethernet/intel/e1000e/ich8lan.h | 2 +-
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/e1000e/ich8lan.c b/drivers/net/ethernet/intel/e1000e/ich8lan.c
index dc7d671b903c5..625008e8cb0df 100644
--- a/drivers/net/ethernet/intel/e1000e/ich8lan.c
+++ b/drivers/net/ethernet/intel/e1000e/ich8lan.c
@@ -1447,6 +1447,16 @@ static s32 e1000_check_for_copper_link_ich8lan(struct e1000_hw *hw)
else
phy_reg |= 0xFA;
e1e_wphy_locked(hw, I217_PLL_CLOCK_GATE_REG, phy_reg);
+
+ if (speed == SPEED_1000) {
+ hw->phy.ops.read_reg_locked(hw, HV_PM_CTRL,
+ &phy_reg);
+
+ phy_reg |= HV_PM_CTRL_K1_CLK_REQ;
+
+ hw->phy.ops.write_reg_locked(hw, HV_PM_CTRL,
+ phy_reg);
+ }
}
hw->phy.ops.release(hw);
diff --git a/drivers/net/ethernet/intel/e1000e/ich8lan.h b/drivers/net/ethernet/intel/e1000e/ich8lan.h
index 67163ca898ba2..6374c8fc76a8d 100644
--- a/drivers/net/ethernet/intel/e1000e/ich8lan.h
+++ b/drivers/net/ethernet/intel/e1000e/ich8lan.h
@@ -227,7 +227,7 @@
/* PHY Power Management Control */
#define HV_PM_CTRL PHY_REG(770, 17)
-#define HV_PM_CTRL_PLL_STOP_IN_K1_GIGA 0x100
+#define HV_PM_CTRL_K1_CLK_REQ 0x200
#define HV_PM_CTRL_K1_ENABLE 0x4000
#define I217_PLL_CLOCK_GATE_REG PHY_REG(772, 28)
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.14 43/89] net: lpc-enet: fix printk format strings
From: Sasha Levin @ 2019-09-22 18:56 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Arnd Bergmann, kbuild test robot, Sasha Levin, netdev
In-Reply-To: <20190922185717.3412-1-sashal@kernel.org>
From: Arnd Bergmann <arnd@arndb.de>
[ Upstream commit de6f97b2bace0e2eb6c3a86e124d1e652a587b56 ]
compile-testing this driver on other architectures showed
multiple warnings:
drivers/net/ethernet/nxp/lpc_eth.c: In function 'lpc_eth_drv_probe':
drivers/net/ethernet/nxp/lpc_eth.c:1337:19: warning: format '%d' expects argument of type 'int', but argument 4 has type 'resource_size_t {aka long long unsigned int}' [-Wformat=]
drivers/net/ethernet/nxp/lpc_eth.c:1342:19: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'dma_addr_t {aka long long unsigned int}' [-Wformat=]
Use format strings that work on all architectures.
Link: https://lore.kernel.org/r/20190809144043.476786-10-arnd@arndb.de
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/nxp/lpc_eth.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/nxp/lpc_eth.c b/drivers/net/ethernet/nxp/lpc_eth.c
index 08381ef8bdb48..41d30f55c946b 100644
--- a/drivers/net/ethernet/nxp/lpc_eth.c
+++ b/drivers/net/ethernet/nxp/lpc_eth.c
@@ -1371,13 +1371,14 @@ static int lpc_eth_drv_probe(struct platform_device *pdev)
pldat->dma_buff_base_p = dma_handle;
netdev_dbg(ndev, "IO address space :%pR\n", res);
- netdev_dbg(ndev, "IO address size :%d\n", resource_size(res));
+ netdev_dbg(ndev, "IO address size :%zd\n",
+ (size_t)resource_size(res));
netdev_dbg(ndev, "IO address (mapped) :0x%p\n",
pldat->net_base);
netdev_dbg(ndev, "IRQ number :%d\n", ndev->irq);
- netdev_dbg(ndev, "DMA buffer size :%d\n", pldat->dma_buff_size);
- netdev_dbg(ndev, "DMA buffer P address :0x%08x\n",
- pldat->dma_buff_base_p);
+ netdev_dbg(ndev, "DMA buffer size :%zd\n", pldat->dma_buff_size);
+ netdev_dbg(ndev, "DMA buffer P address :%pad\n",
+ &pldat->dma_buff_base_p);
netdev_dbg(ndev, "DMA buffer V address :0x%p\n",
pldat->dma_buff_base_v);
@@ -1424,8 +1425,8 @@ static int lpc_eth_drv_probe(struct platform_device *pdev)
if (ret)
goto err_out_unregister_netdev;
- netdev_info(ndev, "LPC mac at 0x%08x irq %d\n",
- res->start, ndev->irq);
+ netdev_info(ndev, "LPC mac at 0x%08lx irq %d\n",
+ (unsigned long)res->start, ndev->irq);
phydev = ndev->phydev;
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 057/128] net: lpc-enet: fix printk format strings
From: Sasha Levin @ 2019-09-22 18:53 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Arnd Bergmann, kbuild test robot, Sasha Levin, netdev
In-Reply-To: <20190922185418.2158-1-sashal@kernel.org>
From: Arnd Bergmann <arnd@arndb.de>
[ Upstream commit de6f97b2bace0e2eb6c3a86e124d1e652a587b56 ]
compile-testing this driver on other architectures showed
multiple warnings:
drivers/net/ethernet/nxp/lpc_eth.c: In function 'lpc_eth_drv_probe':
drivers/net/ethernet/nxp/lpc_eth.c:1337:19: warning: format '%d' expects argument of type 'int', but argument 4 has type 'resource_size_t {aka long long unsigned int}' [-Wformat=]
drivers/net/ethernet/nxp/lpc_eth.c:1342:19: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'dma_addr_t {aka long long unsigned int}' [-Wformat=]
Use format strings that work on all architectures.
Link: https://lore.kernel.org/r/20190809144043.476786-10-arnd@arndb.de
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/nxp/lpc_eth.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/nxp/lpc_eth.c b/drivers/net/ethernet/nxp/lpc_eth.c
index 08381ef8bdb48..41d30f55c946b 100644
--- a/drivers/net/ethernet/nxp/lpc_eth.c
+++ b/drivers/net/ethernet/nxp/lpc_eth.c
@@ -1371,13 +1371,14 @@ static int lpc_eth_drv_probe(struct platform_device *pdev)
pldat->dma_buff_base_p = dma_handle;
netdev_dbg(ndev, "IO address space :%pR\n", res);
- netdev_dbg(ndev, "IO address size :%d\n", resource_size(res));
+ netdev_dbg(ndev, "IO address size :%zd\n",
+ (size_t)resource_size(res));
netdev_dbg(ndev, "IO address (mapped) :0x%p\n",
pldat->net_base);
netdev_dbg(ndev, "IRQ number :%d\n", ndev->irq);
- netdev_dbg(ndev, "DMA buffer size :%d\n", pldat->dma_buff_size);
- netdev_dbg(ndev, "DMA buffer P address :0x%08x\n",
- pldat->dma_buff_base_p);
+ netdev_dbg(ndev, "DMA buffer size :%zd\n", pldat->dma_buff_size);
+ netdev_dbg(ndev, "DMA buffer P address :%pad\n",
+ &pldat->dma_buff_base_p);
netdev_dbg(ndev, "DMA buffer V address :0x%p\n",
pldat->dma_buff_base_v);
@@ -1424,8 +1425,8 @@ static int lpc_eth_drv_probe(struct platform_device *pdev)
if (ret)
goto err_out_unregister_netdev;
- netdev_info(ndev, "LPC mac at 0x%08x irq %d\n",
- res->start, ndev->irq);
+ netdev_info(ndev, "LPC mac at 0x%08lx irq %d\n",
+ (unsigned long)res->start, ndev->irq);
phydev = ndev->phydev;
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.2 180/185] zd1211rw: remove false assertion from zd_mac_clear()
From: Sasha Levin @ 2019-09-22 18:49 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Oliver Neukum, syzbot+74c65761783d66a9c97c, Kalle Valo,
Sasha Levin, linux-wireless, netdev
In-Reply-To: <20190922184924.32534-1-sashal@kernel.org>
From: Oliver Neukum <oneukum@suse.com>
[ Upstream commit 7a2eb7367fdea72e448d1a847aa857f6caf8ea2f ]
The function is called before the lock which is asserted was ever used.
Just remove it.
Reported-by: syzbot+74c65761783d66a9c97c@syzkaller.appspotmail.com
Signed-off-by: Oliver Neukum <oneukum@suse.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/zydas/zd1211rw/zd_mac.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/wireless/zydas/zd1211rw/zd_mac.c b/drivers/net/wireless/zydas/zd1211rw/zd_mac.c
index da7e63fca9f57..a9999d10ae81f 100644
--- a/drivers/net/wireless/zydas/zd1211rw/zd_mac.c
+++ b/drivers/net/wireless/zydas/zd1211rw/zd_mac.c
@@ -223,7 +223,6 @@ void zd_mac_clear(struct zd_mac *mac)
{
flush_workqueue(zd_workqueue);
zd_chip_clear(&mac->chip);
- lockdep_assert_held(&mac->lock);
ZD_MEMCLEAR(mac, sizeof(struct zd_mac));
}
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.3 190/203] e1000e: add workaround for possible stalled packet
From: Sasha Levin @ 2019-09-22 18:43 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Kai-Heng Feng, Aaron Brown, Jeff Kirsher, Sasha Levin, netdev
In-Reply-To: <20190922184350.30563-1-sashal@kernel.org>
From: Kai-Heng Feng <kai.heng.feng@canonical.com>
[ Upstream commit e5e9a2ecfe780975820e157b922edee715710b66 ]
This works around a possible stalled packet issue, which may occur due to
clock recovery from the PCH being too slow, when the LAN is transitioning
from K1 at 1G link speed.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204057
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/intel/e1000e/ich8lan.c | 10 ++++++++++
drivers/net/ethernet/intel/e1000e/ich8lan.h | 2 +-
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/e1000e/ich8lan.c b/drivers/net/ethernet/intel/e1000e/ich8lan.c
index 395b057014809..a1fab77b2096a 100644
--- a/drivers/net/ethernet/intel/e1000e/ich8lan.c
+++ b/drivers/net/ethernet/intel/e1000e/ich8lan.c
@@ -1429,6 +1429,16 @@ static s32 e1000_check_for_copper_link_ich8lan(struct e1000_hw *hw)
else
phy_reg |= 0xFA;
e1e_wphy_locked(hw, I217_PLL_CLOCK_GATE_REG, phy_reg);
+
+ if (speed == SPEED_1000) {
+ hw->phy.ops.read_reg_locked(hw, HV_PM_CTRL,
+ &phy_reg);
+
+ phy_reg |= HV_PM_CTRL_K1_CLK_REQ;
+
+ hw->phy.ops.write_reg_locked(hw, HV_PM_CTRL,
+ phy_reg);
+ }
}
hw->phy.ops.release(hw);
diff --git a/drivers/net/ethernet/intel/e1000e/ich8lan.h b/drivers/net/ethernet/intel/e1000e/ich8lan.h
index eb09c755fa172..1502895eb45dd 100644
--- a/drivers/net/ethernet/intel/e1000e/ich8lan.h
+++ b/drivers/net/ethernet/intel/e1000e/ich8lan.h
@@ -210,7 +210,7 @@
/* PHY Power Management Control */
#define HV_PM_CTRL PHY_REG(770, 17)
-#define HV_PM_CTRL_PLL_STOP_IN_K1_GIGA 0x100
+#define HV_PM_CTRL_K1_CLK_REQ 0x200
#define HV_PM_CTRL_K1_ENABLE 0x4000
#define I217_PLL_CLOCK_GATE_REG PHY_REG(772, 28)
--
2.20.1
^ permalink raw reply related
* Re: [PATCH net] ionic: Fix an error code in ionic_lif_alloc()
From: Shannon Nelson @ 2019-09-22 18:21 UTC (permalink / raw)
To: Dan Carpenter; +Cc: Pensando Drivers, David S. Miller, netdev, kernel-janitors
In-Reply-To: <20190921055926.GA18726@mwanda>
On 9/20/19 10:59 PM, Dan Carpenter wrote:
> We need to set the error code on this path. Otherwise it probably
> results in a NULL dereference down the line.
>
> Fixes: aa3198819bea ("ionic: Add RSS support")
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> ---
> drivers/net/ethernet/pensando/ionic/ionic_lif.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/net/ethernet/pensando/ionic/ionic_lif.c b/drivers/net/ethernet/pensando/ionic/ionic_lif.c
> index db7c82742828..72107a0627a9 100644
> --- a/drivers/net/ethernet/pensando/ionic/ionic_lif.c
> +++ b/drivers/net/ethernet/pensando/ionic/ionic_lif.c
> @@ -1704,6 +1704,7 @@ static struct ionic_lif *ionic_lif_alloc(struct ionic *ionic, unsigned int index
> GFP_KERNEL);
>
> if (!lif->rss_ind_tbl) {
> + err = -ENOMEM;
> dev_err(dev, "Failed to allocate rss indirection table, aborting\n");
> goto err_out_free_qcqs;
> }
Thanks, Dan.
Acked-by: Shannon Nelson <snelson@pensando.io>
^ permalink raw reply
* Re: [PATCH 0/4] Attempt to fix regression with AR8035 speed downgrade
From: Florian Fainelli @ 2019-09-22 18:02 UTC (permalink / raw)
To: Russell King - ARM Linux admin, Andrew Lunn
Cc: Heiner Kallweit, tinywrkb, David S. Miller, netdev
In-Reply-To: <20190922175246.GR25745@shell.armlinux.org.uk>
On 9/22/2019 10:52 AM, Russell King - ARM Linux admin wrote:
> On Sun, Sep 22, 2019 at 06:53:35PM +0200, Andrew Lunn wrote:
>> On Sun, Sep 22, 2019 at 11:59:32AM +0100, Russell King - ARM Linux admin wrote:
>>> Hi,
>>>
>>> tinywrkb, please can you test this series to ensure that it fixes
>>> your problem - the previous version has turned out to be a non-starter
>>> as it introduces more problems, thanks!
>>>
>>> The following series attempts to address an issue spotted by tinywrkb
>>> with the AR8035 on the Cubox-i2 in a situation where the PHY downgrades
>>> the negotiated link.
>>
>> Hi Russell
>>
>> This all looks sensible.
>>
>> One things we need to be careful of, is this is for net and so stable.
>
> Since the regression was introduced in 5.1, it should be backported
> to stable trees.
>
>> But only some of the patches have fixes-tags. I don't know if we
>> should add fixes tags to all the patches, just to give back porters a
>> hint that they are all needed? It won't compile without the patches,
>> so at least it fails safe.
>
> I only put Fixes: tags on patches that are actually fixing something.
> Quoting submitting-patches.rst:
>
> A Fixes: tag indicates that the patch fixes an issue in a previous
> commit.
>
> Since the preceding two patches are just preparing for the fix, and
> not actually fixing an issue in themselves, it seems wrong to add a
> Fixes: tag for them. However, mentioning it in the commit message
> for the patch that does fix the issue is probably worth it. Thanks.
>
This is not a criticism of your patch series, which is fine.
I believe Andrew's angle is that if you have fixes that rely on
non-functional changes, then the fixes cannot be back ported as a
standalone patch set towards specific stable trees. This means that
people who do care about such fixes may have to come up with a slightly
different fix for earlier kernels affected by those bugs, such fixes
would not rely on patch #2 and #3 in this series and open code
phy_resolve_aneg() and genphy_read_lpa() within the at803x.c PHY driver.
--
Florian
^ permalink raw reply
* Re: [PATCH] net: dsa: microchip: Always set regmap stride to 1
From: Florian Fainelli @ 2019-09-22 17:58 UTC (permalink / raw)
To: Marek Vasut, netdev
Cc: Andrew Lunn, David S . Miller, George McCollister, Tristram Ha,
Vivien Didelot, Woojung Huh
In-Reply-To: <20190921175309.2195-1-marex@denx.de>
On 9/21/2019 10:53 AM, Marek Vasut wrote:
> The regmap stride is set to 1 for regmap describing 8bit registers already.
> However, for 16/32/64bit registers, the stride is 2/4/8 respectively. This
> is not correct, as the switch protocol supports unaligned register reads
> and writes and the KSZ87xx even uses such unaligned register accesses to
> read e.g. MIB counter.
>
> This patch fixes MIB counter access on KSZ87xx.
Should that be having the following Fixes tag(s):
Fixes: 46558d601cb6 ("net: dsa: microchip: Initial SPI regmap support")
and where relevant:
Fixes: 255b59ad0db2 ("net: dsa: microchip: Factor out regmap config
generation into common header")
>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: Florian Fainelli <f.fainelli@gmail.com>
> Cc: George McCollister <george.mccollister@gmail.com>
> Cc: Tristram Ha <Tristram.Ha@microchip.com>
> Cc: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
> Cc: Woojung Huh <woojung.huh@microchip.com>
> ---
> drivers/net/dsa/microchip/ksz_common.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/dsa/microchip/ksz_common.h b/drivers/net/dsa/microchip/ksz_common.h
> index a24d8e61fbe7..dd60d0837fc6 100644
> --- a/drivers/net/dsa/microchip/ksz_common.h
> +++ b/drivers/net/dsa/microchip/ksz_common.h
> @@ -303,7 +303,7 @@ static inline void ksz_pwrite32(struct ksz_device *dev, int port, int offset,
> { \
> .name = #width, \
> .val_bits = (width), \
> - .reg_stride = (width) / 8, \
> + .reg_stride = 1, \
> .reg_bits = (regbits) + (regalign), \
> .pad_bits = (regpad), \
> .max_register = BIT(regbits) - 1, \
>
--
Florian
^ permalink raw reply
* Re: [PATCH 0/4] Attempt to fix regression with AR8035 speed downgrade
From: Russell King - ARM Linux admin @ 2019-09-22 17:52 UTC (permalink / raw)
To: Andrew Lunn
Cc: Florian Fainelli, Heiner Kallweit, tinywrkb, David S. Miller,
netdev
In-Reply-To: <20190922165335.GE27014@lunn.ch>
On Sun, Sep 22, 2019 at 06:53:35PM +0200, Andrew Lunn wrote:
> On Sun, Sep 22, 2019 at 11:59:32AM +0100, Russell King - ARM Linux admin wrote:
> > Hi,
> >
> > tinywrkb, please can you test this series to ensure that it fixes
> > your problem - the previous version has turned out to be a non-starter
> > as it introduces more problems, thanks!
> >
> > The following series attempts to address an issue spotted by tinywrkb
> > with the AR8035 on the Cubox-i2 in a situation where the PHY downgrades
> > the negotiated link.
>
> Hi Russell
>
> This all looks sensible.
>
> One things we need to be careful of, is this is for net and so stable.
Since the regression was introduced in 5.1, it should be backported
to stable trees.
> But only some of the patches have fixes-tags. I don't know if we
> should add fixes tags to all the patches, just to give back porters a
> hint that they are all needed? It won't compile without the patches,
> so at least it fails safe.
I only put Fixes: tags on patches that are actually fixing something.
Quoting submitting-patches.rst:
A Fixes: tag indicates that the patch fixes an issue in a previous
commit.
Since the preceding two patches are just preparing for the fix, and
not actually fixing an issue in themselves, it seems wrong to add a
Fixes: tag for them. However, mentioning it in the commit message
for the patch that does fix the issue is probably worth it. Thanks.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
^ permalink raw reply
* [RFC] VSOCK: add support for MSG_PEEK
From: Matias Ezequiel Vara Larsen @ 2019-09-22 17:48 UTC (permalink / raw)
To: stefanha
Cc: davem, kvm, virtualization, netdev, linux-kernel, matiasevara,
sgarzare
This patch adds support for MSG_PEEK. In such a case, packets are not
removed from the rx_queue and credit updates are not sent.
Signed-off-by: Matias Ezequiel Vara Larsen <matiasevara@gmail.com>
---
net/vmw_vsock/virtio_transport_common.c | 59 +++++++++++++++++++++++++++++++--
1 file changed, 56 insertions(+), 3 deletions(-)
diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c
index 94cc0fa..830e890 100644
--- a/net/vmw_vsock/virtio_transport_common.c
+++ b/net/vmw_vsock/virtio_transport_common.c
@@ -264,6 +264,59 @@ static int virtio_transport_send_credit_update(struct vsock_sock *vsk,
}
static ssize_t
+virtio_transport_stream_do_peek(struct vsock_sock *vsk,
+ struct msghdr *msg,
+ size_t len)
+{
+ struct virtio_vsock_sock *vvs = vsk->trans;
+ struct virtio_vsock_pkt *pkt;
+ size_t bytes, off = 0, total = 0;
+ int err = -EFAULT;
+
+ spin_lock_bh(&vvs->rx_lock);
+
+ if (list_empty(&vvs->rx_queue)) {
+ spin_unlock_bh(&vvs->rx_lock);
+ return 0;
+ }
+
+ pkt = list_first_entry(&vvs->rx_queue,
+ struct virtio_vsock_pkt, list);
+ do {
+ bytes = len - total;
+ if (bytes > pkt->len - off)
+ bytes = pkt->len - off;
+
+ /* sk_lock is held by caller so no one else can dequeue.
+ * Unlock rx_lock since memcpy_to_msg() may sleep.
+ */
+ spin_unlock_bh(&vvs->rx_lock);
+
+ err = memcpy_to_msg(msg, pkt->buf + off, bytes);
+ if (err)
+ goto out;
+
+ spin_lock_bh(&vvs->rx_lock);
+
+ total += bytes;
+ off += bytes;
+ if (off == pkt->len) {
+ pkt = list_next_entry(pkt, list);
+ off = 0;
+ }
+ } while ((total < len) && !list_is_first(&pkt->list, &vvs->rx_queue));
+
+ spin_unlock_bh(&vvs->rx_lock);
+
+ return total;
+
+out:
+ if (total)
+ err = total;
+ return err;
+}
+
+static ssize_t
virtio_transport_stream_do_dequeue(struct vsock_sock *vsk,
struct msghdr *msg,
size_t len)
@@ -330,9 +383,9 @@ virtio_transport_stream_dequeue(struct vsock_sock *vsk,
size_t len, int flags)
{
if (flags & MSG_PEEK)
- return -EOPNOTSUPP;
-
- return virtio_transport_stream_do_dequeue(vsk, msg, len);
+ return virtio_transport_stream_do_peek(vsk, msg, len);
+ else
+ return virtio_transport_stream_do_dequeue(vsk, msg, len);
}
EXPORT_SYMBOL_GPL(virtio_transport_stream_dequeue);
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net-next] tuntap: Fallback to automq on TUNSETSTEERINGEBPF prog negative return
From: Matt Cover @ 2019-09-22 17:43 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: davem, ast, daniel, kafai, songliubraving, yhs, Jason Wang,
Eric Dumazet, Stanislav Fomichev, Matthew Cover, mail, pabeni,
Nicolas Dichtel, wangli39, lifei.shirley, tglx, netdev,
linux-kernel, bpf
In-Reply-To: <20190922080326-mutt-send-email-mst@kernel.org>
On Sun, Sep 22, 2019 at 5:37 AM Michael S. Tsirkin <mst@redhat.com> wrote:
>
> On Fri, Sep 20, 2019 at 11:58:43AM -0700, Matthew Cover wrote:
> > Treat a negative return from a TUNSETSTEERINGEBPF bpf prog as a signal
> > to fallback to tun_automq_select_queue() for tx queue selection.
> >
> > Compilation of this exact patch was tested.
> >
> > For functional testing 3 additional printk()s were added.
> >
> > Functional testing results (on 2 txq tap device):
> >
> > [Fri Sep 20 18:33:27 2019] ========== tun no prog ==========
> > [Fri Sep 20 18:33:27 2019] tuntap: tun_ebpf_select_queue() returned '-1'
> > [Fri Sep 20 18:33:27 2019] tuntap: tun_automq_select_queue() ran
> > [Fri Sep 20 18:33:27 2019] ========== tun prog -1 ==========
> > [Fri Sep 20 18:33:27 2019] tuntap: bpf_prog_run_clear_cb() returned '-1'
> > [Fri Sep 20 18:33:27 2019] tuntap: tun_ebpf_select_queue() returned '-1'
> > [Fri Sep 20 18:33:27 2019] tuntap: tun_automq_select_queue() ran
> > [Fri Sep 20 18:33:27 2019] ========== tun prog 0 ==========
> > [Fri Sep 20 18:33:27 2019] tuntap: bpf_prog_run_clear_cb() returned '0'
> > [Fri Sep 20 18:33:27 2019] tuntap: tun_ebpf_select_queue() returned '0'
> > [Fri Sep 20 18:33:27 2019] ========== tun prog 1 ==========
> > [Fri Sep 20 18:33:27 2019] tuntap: bpf_prog_run_clear_cb() returned '1'
> > [Fri Sep 20 18:33:27 2019] tuntap: tun_ebpf_select_queue() returned '1'
> > [Fri Sep 20 18:33:27 2019] ========== tun prog 2 ==========
> > [Fri Sep 20 18:33:27 2019] tuntap: bpf_prog_run_clear_cb() returned '2'
> > [Fri Sep 20 18:33:27 2019] tuntap: tun_ebpf_select_queue() returned '0'
> >
> > Signed-off-by: Matthew Cover <matthew.cover@stackpath.com>
>
>
> Could you add a bit more motivation data here?
Thank you for these questions Michael.
I'll plan on adding the below information to the
commit message and submitting a v2 of this patch
when net-next reopens. In the meantime, it would
be very helpful to know if these answers address
some of your concerns.
> 1. why is this a good idea
This change allows TUNSETSTEERINGEBPF progs to
do any of the following.
1. implement queue selection for a subset of
traffic (e.g. special queue selection logic
for ipv4, but return negative and use the
default automq logic for ipv6)
2. determine there isn't sufficient information
to do proper queue selection; return
negative and use the default automq logic
for the unknown
3. implement a noop prog (e.g. do
bpf_trace_printk() then return negative and
use the default automq logic for everything)
> 2. how do we know existing userspace does not rely on existing behaviour
Prior to this change a negative return from a
TUNSETSTEERINGEBPF prog would have been cast
into a u16 and traversed netdev_cap_txqueue().
In most cases netdev_cap_txqueue() would have
found this value to exceed real_num_tx_queues
and queue_index would be updated to 0.
It is possible that a TUNSETSTEERINGEBPF prog
return a negative value which when cast into a
u16 results in a positive queue_index less than
real_num_tx_queues. For example, on x86_64, a
return value of -65535 results in a queue_index
of 1; which is a valid queue for any multiqueue
device.
It seems unlikely, however as stated above is
unfortunately possible, that existing
TUNSETSTEERINGEBPF programs would choose to
return a negative value rather than return the
positive value which holds the same meaning.
It seems more likely that future
TUNSETSTEERINGEBPF programs would leverage a
negative return and potentially be loaded into
a kernel with the old behavior.
> 3. why doesn't userspace need a way to figure out whether it runs on a kernel with and
> without this patch
There may be some value in exposing this fact
to the ebpf prog loader. What is the standard
practice here, a define?
>
>
> thanks,
> MST
>
> > ---
> > drivers/net/tun.c | 20 +++++++++++---------
> > 1 file changed, 11 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> > index aab0be4..173d159 100644
> > --- a/drivers/net/tun.c
> > +++ b/drivers/net/tun.c
> > @@ -583,35 +583,37 @@ static u16 tun_automq_select_queue(struct tun_struct *tun, struct sk_buff *skb)
> > return txq;
> > }
> >
> > -static u16 tun_ebpf_select_queue(struct tun_struct *tun, struct sk_buff *skb)
> > +static int tun_ebpf_select_queue(struct tun_struct *tun, struct sk_buff *skb)
> > {
> > struct tun_prog *prog;
> > u32 numqueues;
> > - u16 ret = 0;
> > + int ret = -1;
> >
> > numqueues = READ_ONCE(tun->numqueues);
> > if (!numqueues)
> > return 0;
> >
> > + rcu_read_lock();
> > prog = rcu_dereference(tun->steering_prog);
> > if (prog)
> > ret = bpf_prog_run_clear_cb(prog->prog, skb);
> > + rcu_read_unlock();
> >
> > - return ret % numqueues;
> > + if (ret >= 0)
> > + ret %= numqueues;
> > +
> > + return ret;
> > }
> >
> > static u16 tun_select_queue(struct net_device *dev, struct sk_buff *skb,
> > struct net_device *sb_dev)
> > {
> > struct tun_struct *tun = netdev_priv(dev);
> > - u16 ret;
> > + int ret;
> >
> > - rcu_read_lock();
> > - if (rcu_dereference(tun->steering_prog))
> > - ret = tun_ebpf_select_queue(tun, skb);
> > - else
> > + ret = tun_ebpf_select_queue(tun, skb);
> > + if (ret < 0)
> > ret = tun_automq_select_queue(tun, skb);
> > - rcu_read_unlock();
> >
> > return ret;
> > }
> > --
> > 1.8.3.1
^ permalink raw reply
* Re: [PATCH 0/4] Attempt to fix regression with AR8035 speed downgrade
From: Andrew Lunn @ 2019-09-22 16:53 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Florian Fainelli, Heiner Kallweit, tinywrkb, David S. Miller,
netdev
In-Reply-To: <20190922105932.GP25745@shell.armlinux.org.uk>
On Sun, Sep 22, 2019 at 11:59:32AM +0100, Russell King - ARM Linux admin wrote:
> Hi,
>
> tinywrkb, please can you test this series to ensure that it fixes
> your problem - the previous version has turned out to be a non-starter
> as it introduces more problems, thanks!
>
> The following series attempts to address an issue spotted by tinywrkb
> with the AR8035 on the Cubox-i2 in a situation where the PHY downgrades
> the negotiated link.
Hi Russell
This all looks sensible.
One things we need to be careful of, is this is for net and so stable.
But only some of the patches have fixes-tags. I don't know if we
should add fixes tags to all the patches, just to give back porters a
hint that they are all needed? It won't compile without the patches,
so at least it fails safe.
Andrew
^ permalink raw reply
* Re: [PATCH 4/4] net: phy: at803x: use operating parameters from PHY-specific status
From: Andrew Lunn @ 2019-09-22 16:45 UTC (permalink / raw)
To: Russell King
Cc: Florian Fainelli, Heiner Kallweit, tinywrkb, David S. Miller,
netdev
In-Reply-To: <E1iBzbN-00007N-U4@rmk-PC.armlinux.org.uk>
On Sun, Sep 22, 2019 at 12:00:25PM +0100, Russell King wrote:
> Read the PHY-specific status register for the current operating mode
> (speed and duplex) of the PHY. This register reflects the actual
> mode that the PHY has resolved depending on either the advertisements
> of autoneg is enabled, or the forced mode if autoneg is disabled.
>
> This ensures that phylib's software state always tracks the hardware
> state.
>
> It seems both AR8033 (which uses the AR8031 ID) and AR8035 support
> this status register. AR8030 is not known at the present time.
>
> Reported-by: tinywrkb <tinywrkb@gmail.com>
> Fixes: 5502b218e001 ("net: phy: use phy_resolve_aneg_linkmode in genphy_read_status")
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH 3/4] net: phy: extract pause mode
From: Andrew Lunn @ 2019-09-22 16:38 UTC (permalink / raw)
To: Russell King
Cc: Florian Fainelli, Heiner Kallweit, tinywrkb, David S. Miller,
netdev
In-Reply-To: <E1iBzbI-000072-R4@rmk-PC.armlinux.org.uk>
On Sun, Sep 22, 2019 at 12:00:20PM +0100, Russell King wrote:
> Extract the update of phylib's software pause mode state from
> genphy_read_status(), so that we can re-use this functionality with
> PHYs that have alternative ways to read the negotiation results.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ 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