* Re: [PATCH net-next] net: ethernet: ti: cpsw-phy-sel: check bus_find_device() ret value
From: Andy Shevchenko @ 2018-05-15 23:07 UTC (permalink / raw)
To: Grygorii Strashko
Cc: David S. Miller, netdev, Sekhar Nori, Linux Kernel Mailing List,
Linux OMAP Mailing List
In-Reply-To: <20180515230149.6547-1-grygorii.strashko@ti.com>
On Wed, May 16, 2018 at 2:01 AM, Grygorii Strashko
<grygorii.strashko@ti.com> wrote:
> This fixes klockworks warnings: Pointer 'dev' returned from call to
> function 'bus_find_device' at line 179 may be NULL and will be dereferenced
> at line 181.
> + dev_err(dev, "unable to find platform device for %s\n",
> + of_node_full_name(node));
Sorry, isn't %pOF works for this?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH net-next] net: ethernet: ti: cpsw-phy-sel: check bus_find_device() ret value
From: Grygorii Strashko @ 2018-05-15 23:01 UTC (permalink / raw)
To: David S. Miller, netdev
Cc: Sekhar Nori, linux-kernel, linux-omap, Grygorii Strashko
This fixes klockworks warnings: Pointer 'dev' returned from call to
function 'bus_find_device' at line 179 may be NULL and will be dereferenced
at line 181.
cpsw-phy-sel.c:179: 'dev' is assigned the return value from function 'bus_find_device'.
bus.c:342: 'bus_find_device' explicitly returns a NULL value.
cpsw-phy-sel.c:181: 'dev' is dereferenced by passing argument 1 to function 'dev_get_drvdata'.
device.h:1024: 'dev' is passed to function 'dev_get_drvdata'.
device.h:1026: 'dev' is explicitly dereferenced.
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
[nsekhar@ti.com: add an error message, fix return path]
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
---
it present for a very long time, so not critical.
drivers/net/ethernet/ti/cpsw-phy-sel.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/ti/cpsw-phy-sel.c b/drivers/net/ethernet/ti/cpsw-phy-sel.c
index 1801364..005fd53 100644
--- a/drivers/net/ethernet/ti/cpsw-phy-sel.c
+++ b/drivers/net/ethernet/ti/cpsw-phy-sel.c
@@ -177,12 +177,19 @@ void cpsw_phy_sel(struct device *dev, phy_interface_t phy_mode, int slave)
}
dev = bus_find_device(&platform_bus_type, NULL, node, match);
- of_node_put(node);
+ if (!dev) {
+ dev_err(dev, "unable to find platform device for %s\n",
+ of_node_full_name(node));
+ goto out;
+ }
+
priv = dev_get_drvdata(dev);
priv->cpsw_phy_sel(priv, phy_mode, slave);
put_device(dev);
+out:
+ of_node_put(node);
}
EXPORT_SYMBOL_GPL(cpsw_phy_sel);
--
2.10.5
^ permalink raw reply related
* [PATCH net v2 3/3] net: dsa: bcm_sf2: Fix IPv6 rule half deletion
From: Florian Fainelli @ 2018-05-15 23:01 UTC (permalink / raw)
To: netdev
Cc: Florian Fainelli, Andrew Lunn, Vivien Didelot, open list, opendmb,
davem
In-Reply-To: <20180515230125.25886-1-f.fainelli@gmail.com>
It was possible to delete only one half of an IPv6, which would leave
the second half still programmed and possibly in use. Instead of
checking for the unused bitmap, we need to check the unique bitmap, and
refuse any deletion that does not match that criteria. We also need to
move that check from bcm_sf2_cfp_rule_del_one() into its caller:
bcm_sf2_cfp_rule_del() otherwise we would not be able to delete second
halves anymore that would not pass the first test.
Fixes: ba0696c22e7c ("net: dsa: bcm_sf2: Add support for IPv6 CFP rules")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/dsa/bcm_sf2_cfp.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/net/dsa/bcm_sf2_cfp.c b/drivers/net/dsa/bcm_sf2_cfp.c
index 6fd0f8a12cc2..b89acaee12d4 100644
--- a/drivers/net/dsa/bcm_sf2_cfp.c
+++ b/drivers/net/dsa/bcm_sf2_cfp.c
@@ -790,10 +790,6 @@ static int bcm_sf2_cfp_rule_del_one(struct bcm_sf2_priv *priv, int port,
int ret;
u32 reg;
- /* Refuse deletion of unused rules, and the default reserved rule */
- if (!test_bit(loc, priv->cfp.used) || loc == 0)
- return -EINVAL;
-
/* Indicate which rule we want to read */
bcm_sf2_cfp_rule_addr_set(priv, loc);
@@ -831,6 +827,13 @@ static int bcm_sf2_cfp_rule_del(struct bcm_sf2_priv *priv, int port,
u32 next_loc = 0;
int ret;
+ /* Refuse deleting unused rules, and those that are not unique since
+ * that could leave IPv6 rules with one of the chained rule in the
+ * table.
+ */
+ if (!test_bit(loc, priv->cfp.unique) || loc == 0)
+ return -EINVAL;
+
ret = bcm_sf2_cfp_rule_del_one(priv, port, loc, &next_loc);
if (ret)
return ret;
--
2.14.1
^ permalink raw reply related
* [PATCH net v2 2/3] net: dsa: bcm_sf2: Fix IPv6 rules and chain ID
From: Florian Fainelli @ 2018-05-15 23:01 UTC (permalink / raw)
To: netdev
Cc: Florian Fainelli, Andrew Lunn, Vivien Didelot, open list, opendmb,
davem
In-Reply-To: <20180515230125.25886-1-f.fainelli@gmail.com>
We had several issues that would make the programming of IPv6 rules both
inconsistent and error prone:
- the chain ID that we would be asking the hardware to put in the
packet's Broadcom tag would be off by one, it would return one of the
two indexes, but not the one user-space specified
- when an user specified a particular location to insert a CFP rule at,
we would not be returning the same index, which would be confusing if
nothing else
- finally, like IPv4, it would be possible to overflow the last entry by
re-programming it
Fix this by swapping the usage of rule_index[0] and rule_index[1] where
relevant in order to return a consistent and correct user-space
experience.
Fixes: ba0696c22e7c ("net: dsa: bcm_sf2: Add support for IPv6 CFP rules")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/dsa/bcm_sf2_cfp.c | 20 +++++++++++---------
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/net/dsa/bcm_sf2_cfp.c b/drivers/net/dsa/bcm_sf2_cfp.c
index 9e04786e3139..6fd0f8a12cc2 100644
--- a/drivers/net/dsa/bcm_sf2_cfp.c
+++ b/drivers/net/dsa/bcm_sf2_cfp.c
@@ -565,19 +565,21 @@ static int bcm_sf2_cfp_ipv6_rule_set(struct bcm_sf2_priv *priv, int port,
* first half because the HW search is by incrementing addresses.
*/
if (fs->location == RX_CLS_LOC_ANY)
- rule_index[0] = find_first_zero_bit(priv->cfp.used,
- bcm_sf2_cfp_rule_size(priv));
+ rule_index[1] = find_first_zero_bit(priv->cfp.used,
+ priv->num_cfp_rules);
else
- rule_index[0] = fs->location;
+ rule_index[1] = fs->location;
+ if (rule_index[1] > bcm_sf2_cfp_rule_size(priv))
+ return -ENOSPC;
/* Flag it as used (cleared on error path) such that we can immediately
* obtain a second one to chain from.
*/
- set_bit(rule_index[0], priv->cfp.used);
+ set_bit(rule_index[1], priv->cfp.used);
- rule_index[1] = find_first_zero_bit(priv->cfp.used,
- bcm_sf2_cfp_rule_size(priv));
- if (rule_index[1] > bcm_sf2_cfp_rule_size(priv)) {
+ rule_index[0] = find_first_zero_bit(priv->cfp.used,
+ priv->num_cfp_rules);
+ if (rule_index[0] > bcm_sf2_cfp_rule_size(priv)) {
ret = -ENOSPC;
goto out_err;
}
@@ -715,14 +717,14 @@ static int bcm_sf2_cfp_ipv6_rule_set(struct bcm_sf2_priv *priv, int port,
/* Flag the second half rule as being used now, return it as the
* location, and flag it as unique while dumping rules
*/
- set_bit(rule_index[1], priv->cfp.used);
+ set_bit(rule_index[0], priv->cfp.used);
set_bit(rule_index[1], priv->cfp.unique);
fs->location = rule_index[1];
return ret;
out_err:
- clear_bit(rule_index[0], priv->cfp.used);
+ clear_bit(rule_index[1], priv->cfp.used);
return ret;
}
--
2.14.1
^ permalink raw reply related
* [PATCH net v2 1/3] net: dsa: bcm_sf2: Fix RX_CLS_LOC_ANY overwrite for last rule
From: Florian Fainelli @ 2018-05-15 23:01 UTC (permalink / raw)
To: netdev
Cc: Florian Fainelli, Andrew Lunn, Vivien Didelot, open list, opendmb,
davem
In-Reply-To: <20180515230125.25886-1-f.fainelli@gmail.com>
When we let the kernel pick up a rule location with RX_CLS_LOC_ANY, we
would be able to overwrite the last rules because of a number of issues.
The IPv4 code path would not be checking that rule_index is within
bounds, and it would also only be allowed to pick up rules from range
0..126 instead of the full 0..127 range. This would lead us to allow
overwriting the last rule when we let the kernel pick-up the location.
Fixes: 3306145866b6 ("net: dsa: bcm_sf2: Move IPv4 CFP processing to specific functions")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/dsa/bcm_sf2_cfp.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/dsa/bcm_sf2_cfp.c b/drivers/net/dsa/bcm_sf2_cfp.c
index 23b45da784cb..9e04786e3139 100644
--- a/drivers/net/dsa/bcm_sf2_cfp.c
+++ b/drivers/net/dsa/bcm_sf2_cfp.c
@@ -354,10 +354,13 @@ static int bcm_sf2_cfp_ipv4_rule_set(struct bcm_sf2_priv *priv, int port,
/* Locate the first rule available */
if (fs->location == RX_CLS_LOC_ANY)
rule_index = find_first_zero_bit(priv->cfp.used,
- bcm_sf2_cfp_rule_size(priv));
+ priv->num_cfp_rules);
else
rule_index = fs->location;
+ if (rule_index > bcm_sf2_cfp_rule_size(priv))
+ return -ENOSPC;
+
layout = &udf_tcpip4_layout;
/* We only use one UDF slice for now */
slice_num = bcm_sf2_get_slice_number(layout, 0);
--
2.14.1
^ permalink raw reply related
* [PATCH net v2 0/3] net: dsa: bcm_sf2: CFP fixes
From: Florian Fainelli @ 2018-05-15 23:01 UTC (permalink / raw)
To: netdev
Cc: Florian Fainelli, Andrew Lunn, Vivien Didelot, open list, opendmb,
davem
Hi David,
This patch series fixes a number of usability issues with the SF2 Compact Field
Processor code:
- we would not be properly bound checking the location when we let the kernel
automatically place rules with RX_CLS_LOC_ANY
- when using IPv6 rules and user space specifies a location identifier we
would be off by one in what the chain ID (within the Broadcom tag) indicates
- it would be possible to delete one of the two slices of an IPv6 while leaving
the other one programming leading to various problems
Florian Fainelli (3):
net: dsa: bcm_sf2: Fix RX_CLS_LOC_ANY overwrite for last rule
net: dsa: bcm_sf2: Fix IPv6 rules and chain ID
net: dsa: bcm_sf2: Fix IPv6 rule half deletion
drivers/net/dsa/bcm_sf2_cfp.c | 36 ++++++++++++++++++++++--------------
1 file changed, 22 insertions(+), 14 deletions(-)
--
2.14.1
^ permalink raw reply
* Re: [PATCH net-next 2/2] drivers: net: Remove device_node checks with of_mdiobus_register()
From: Florian Fainelli @ 2018-05-15 22:59 UTC (permalink / raw)
To: Grygorii Strashko, netdev
Cc: Andrew Lunn, Vivien Didelot, David S. Miller, Nicolas Ferre,
Fugang Duan, Sergei Shtylyov, Giuseppe Cavallaro,
Alexandre Torgue, Jose Abreu, Woojung Huh,
Microchip Linux Driver Support, Rob Herring, Frank Rowand,
Antoine Tenart, Tobias Jordan, Russell King, Geert Uytterhoeven,
Thomas
In-Reply-To: <1112dc66-5300-89f8-8382-ceb7a024e933@ti.com>
On 05/15/2018 03:57 PM, Grygorii Strashko wrote:
>
>
> On 05/15/2018 04:59 PM, Florian Fainelli wrote:
>> A number of drivers have the following pattern:
>>
>> if (np)
>> of_mdiobus_register()
>> else
>> mdiobus_register()
>>
>> which the implementation of of_mdiobus_register() now takes care of.
>> Remove that pattern in drivers that strictly adhere to it.
>>
>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>> ---
>> drivers/net/dsa/bcm_sf2.c | 8 ++------
>> drivers/net/dsa/mv88e6xxx/chip.c | 5 +----
>> drivers/net/ethernet/cadence/macb_main.c | 12 +++---------
>> drivers/net/ethernet/freescale/fec_main.c | 8 ++------
>> drivers/net/ethernet/marvell/mvmdio.c | 5 +----
>> drivers/net/ethernet/renesas/sh_eth.c | 11 +++--------
>> drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c | 5 +----
>> drivers/net/ethernet/ti/davinci_mdio.c | 6 ++----
>> drivers/net/phy/mdio-gpio.c | 6 +-----
>> drivers/net/phy/mdio-mscc-miim.c | 6 +-----
>> drivers/net/usb/lan78xx.c | 7 ++-----
>> 11 files changed, 19 insertions(+), 60 deletions(-)
>>
>
> ...
>
>> goto bus_register_fail;
>> diff --git a/drivers/net/ethernet/ti/davinci_mdio.c
>> b/drivers/net/ethernet/ti/davinci_mdio.c
>> index 98a1c97fb95e..e720244e7f71 100644
>> --- a/drivers/net/ethernet/ti/davinci_mdio.c
>> +++ b/drivers/net/ethernet/ti/davinci_mdio.c
>> @@ -431,10 +431,8 @@ static int davinci_mdio_probe(struct
>> platform_device *pdev)
>> */
>> if (dev->of_node && of_get_child_count(dev->of_node)) {
>
> It causes build error due to "{" above.
Humpf, shame on me for not enabling that driver, thanks for catching this!
>
>> data->skip_scan = true;
>> - ret = of_mdiobus_register(data->bus, dev->of_node);
>> - } else {
>> - ret = mdiobus_register(data->bus);
>> - }
>> +
>> + ret = of_mdiobus_register(data->bus, dev->of_node);
>> if (ret)
>> goto bail_out;
>> diff --git a/drivers/net/phy/mdio-gpio.c b/drivers/net/phy/mdio-gpio.c
>> index b501221819e1..4e4c8daf44c3 100644
>> --- a/drivers/net/phy/mdio-gpio.c
>> +++ b/drivers/net/phy/mdio-gpio.c
>> @@ -179,11 +179,7 @@ static int mdio_gpio_probe(struct platform_device
>> *pdev)
>
> [...]
>
--
Florian
^ permalink raw reply
* Re: [PATCH net-next 2/2] drivers: net: Remove device_node checks with of_mdiobus_register()
From: Grygorii Strashko @ 2018-05-15 22:57 UTC (permalink / raw)
To: Florian Fainelli, netdev
Cc: Andrew Lunn, Vivien Didelot, David S. Miller, Nicolas Ferre,
Fugang Duan, Sergei Shtylyov, Giuseppe Cavallaro,
Alexandre Torgue, Jose Abreu, Woojung Huh,
Microchip Linux Driver Support, Rob Herring, Frank Rowand,
Antoine Tenart, Tobias Jordan, Russell King, Geert Uytterhoeven,
Thomas
In-Reply-To: <20180515215930.12115-3-f.fainelli@gmail.com>
On 05/15/2018 04:59 PM, Florian Fainelli wrote:
> A number of drivers have the following pattern:
>
> if (np)
> of_mdiobus_register()
> else
> mdiobus_register()
>
> which the implementation of of_mdiobus_register() now takes care of.
> Remove that pattern in drivers that strictly adhere to it.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> drivers/net/dsa/bcm_sf2.c | 8 ++------
> drivers/net/dsa/mv88e6xxx/chip.c | 5 +----
> drivers/net/ethernet/cadence/macb_main.c | 12 +++---------
> drivers/net/ethernet/freescale/fec_main.c | 8 ++------
> drivers/net/ethernet/marvell/mvmdio.c | 5 +----
> drivers/net/ethernet/renesas/sh_eth.c | 11 +++--------
> drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c | 5 +----
> drivers/net/ethernet/ti/davinci_mdio.c | 6 ++----
> drivers/net/phy/mdio-gpio.c | 6 +-----
> drivers/net/phy/mdio-mscc-miim.c | 6 +-----
> drivers/net/usb/lan78xx.c | 7 ++-----
> 11 files changed, 19 insertions(+), 60 deletions(-)
>
...
> goto bus_register_fail;
> diff --git a/drivers/net/ethernet/ti/davinci_mdio.c b/drivers/net/ethernet/ti/davinci_mdio.c
> index 98a1c97fb95e..e720244e7f71 100644
> --- a/drivers/net/ethernet/ti/davinci_mdio.c
> +++ b/drivers/net/ethernet/ti/davinci_mdio.c
> @@ -431,10 +431,8 @@ static int davinci_mdio_probe(struct platform_device *pdev)
> */
> if (dev->of_node && of_get_child_count(dev->of_node)) {
It causes build error due to "{" above.
> data->skip_scan = true;
> - ret = of_mdiobus_register(data->bus, dev->of_node);
> - } else {
> - ret = mdiobus_register(data->bus);
> - }
> +
> + ret = of_mdiobus_register(data->bus, dev->of_node);
> if (ret)
> goto bail_out;
>
> diff --git a/drivers/net/phy/mdio-gpio.c b/drivers/net/phy/mdio-gpio.c
> index b501221819e1..4e4c8daf44c3 100644
> --- a/drivers/net/phy/mdio-gpio.c
> +++ b/drivers/net/phy/mdio-gpio.c
> @@ -179,11 +179,7 @@ static int mdio_gpio_probe(struct platform_device *pdev)
[...]
--
regards,
-grygorii
^ permalink raw reply
* Re: [PATCH v2] {net, IB}/mlx5: Use 'kvfree()' for memory allocated by 'kvzalloc()'
From: Jason Gunthorpe @ 2018-05-15 22:21 UTC (permalink / raw)
To: Christophe JAILLET
Cc: saeedm, matanb, leon, dledford, davem, netdev, linux-rdma,
linux-kernel, kernel-janitors
In-Reply-To: <20180513070041.24246-1-christophe.jaillet@wanadoo.fr>
On Sun, May 13, 2018 at 09:00:41AM +0200, Christophe JAILLET wrote:
> When 'kvzalloc()' is used to allocate memory, 'kvfree()' must be used to
> free it.
>
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> ---
> v1 -> v2: More places to update have been added to the patch
> ---
> drivers/infiniband/hw/mlx5/cq.c | 2 +-
> drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c | 2 +-
> drivers/net/ethernet/mellanox/mlx5/core/vport.c | 6 +++---
> 3 files changed, 5 insertions(+), 5 deletions(-)
I agree with Eric on the need for fixes lines in v3..
> diff --git a/drivers/infiniband/hw/mlx5/cq.c b/drivers/infiniband/hw/mlx5/cq.c
> index 77d257ec899b..6d52ea03574e 100644
> --- a/drivers/infiniband/hw/mlx5/cq.c
> +++ b/drivers/infiniband/hw/mlx5/cq.c
> @@ -849,7 +849,7 @@ static int create_cq_user(struct mlx5_ib_dev *dev, struct ib_udata *udata,
> return 0;
>
> err_cqb:
> - kfree(*cqb);
> + kvfree(*cqb);
For the infiniband part:
Acked-by: Jason Gunthorpe <jgg@mellanox.com>
Since this is mostly ethernet, can it go through netdev? thanks
Jason
^ permalink raw reply
* Re: [PATCH 00/14] Modify action API for implementing lockless actions
From: Lucas Bates @ 2018-05-15 22:07 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Vlad Buslov, Linux Kernel Network Developers, David Miller,
Cong Wang, Jiri Pirko, pablo, kadlec, fw, ast, Daniel Borkmann,
edumazet, kliteyn
In-Reply-To: <CAMDBHY+QRKnQnmCx7hj_9wXmdvb1Qarnj5xJ3EaZssABoxG1bg@mail.gmail.com>
On Tue, May 15, 2018 at 6:03 PM, Lucas Bates <lucasb@mojatatu.com> wrote:
> On Tue, May 15, 2018 at 5:49 PM, Jamal Hadi Salim <jhs@mojatatu.com> wrote:
>>> Test 7d50: Add skbmod action to set destination mac
>>> exit: 255 0
>>> dst MAC address <11:22:33:44:55:66>
>>> RTNETLINK answers: No such file or directory
>>> We have an error talking to the kernel
>>>
>>
>> You may actually have broken something with your patches in this case.
>>
>> Lucas - does this test pass on latest net-next?
>
> Yes, 7d50 has been passing on our builds for at least the last month.
Also, Vlad, you can look at the JSON to see the test case data, or run
tdc.py -s | less and search for the ID to see the commands being run.
I'm here if you need help using tdc.
^ permalink raw reply
* Re: [PATCH 00/14] Modify action API for implementing lockless actions
From: Lucas Bates @ 2018-05-15 22:03 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Vlad Buslov, Linux Kernel Network Developers, David Miller,
Cong Wang, Jiri Pirko, pablo, kadlec, fw, ast, Daniel Borkmann,
edumazet, kliteyn
In-Reply-To: <2ee4066e-643a-f901-8926-7001f8699163@mojatatu.com>
On Tue, May 15, 2018 at 5:49 PM, Jamal Hadi Salim <jhs@mojatatu.com> wrote:
>> Test 7d50: Add skbmod action to set destination mac
>> exit: 255 0
>> dst MAC address <11:22:33:44:55:66>
>> RTNETLINK answers: No such file or directory
>> We have an error talking to the kernel
>>
>
> You may actually have broken something with your patches in this case.
>
> Lucas - does this test pass on latest net-next?
Yes, 7d50 has been passing on our builds for at least the last month.
- Lucas
^ permalink raw reply
* [PATCH net-next 2/2] drivers: net: Remove device_node checks with of_mdiobus_register()
From: Florian Fainelli @ 2018-05-15 21:59 UTC (permalink / raw)
To: netdev
Cc: Florian Fainelli, Andrew Lunn, Vivien Didelot, David S. Miller,
Nicolas Ferre, Fugang Duan, Sergei Shtylyov, Giuseppe Cavallaro,
Alexandre Torgue, Jose Abreu, Grygorii Strashko, Woojung Huh,
Microchip Linux Driver Support, Rob Herring, Frank Rowand,
Antoine Tenart, Tobias Jordan, Russell King <r
In-Reply-To: <20180515215930.12115-1-f.fainelli@gmail.com>
A number of drivers have the following pattern:
if (np)
of_mdiobus_register()
else
mdiobus_register()
which the implementation of of_mdiobus_register() now takes care of.
Remove that pattern in drivers that strictly adhere to it.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/dsa/bcm_sf2.c | 8 ++------
drivers/net/dsa/mv88e6xxx/chip.c | 5 +----
drivers/net/ethernet/cadence/macb_main.c | 12 +++---------
drivers/net/ethernet/freescale/fec_main.c | 8 ++------
drivers/net/ethernet/marvell/mvmdio.c | 5 +----
drivers/net/ethernet/renesas/sh_eth.c | 11 +++--------
drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c | 5 +----
drivers/net/ethernet/ti/davinci_mdio.c | 6 ++----
drivers/net/phy/mdio-gpio.c | 6 +-----
drivers/net/phy/mdio-mscc-miim.c | 6 +-----
drivers/net/usb/lan78xx.c | 7 ++-----
11 files changed, 19 insertions(+), 60 deletions(-)
diff --git a/drivers/net/dsa/bcm_sf2.c b/drivers/net/dsa/bcm_sf2.c
index ac621f44237a..02e8982519ce 100644
--- a/drivers/net/dsa/bcm_sf2.c
+++ b/drivers/net/dsa/bcm_sf2.c
@@ -450,12 +450,8 @@ static int bcm_sf2_mdio_register(struct dsa_switch *ds)
priv->slave_mii_bus->parent = ds->dev->parent;
priv->slave_mii_bus->phy_mask = ~priv->indir_phy_mask;
- if (dn)
- err = of_mdiobus_register(priv->slave_mii_bus, dn);
- else
- err = mdiobus_register(priv->slave_mii_bus);
-
- if (err)
+ err = of_mdiobus_register(priv->slave_mii_bus, dn);
+ if (err && dn)
of_node_put(dn);
return err;
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index b23c11d9f4b2..2bb3f03ee1cb 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -2454,10 +2454,7 @@ static int mv88e6xxx_mdio_register(struct mv88e6xxx_chip *chip,
return err;
}
- if (np)
- err = of_mdiobus_register(bus, np);
- else
- err = mdiobus_register(bus);
+ err = of_mdiobus_register(bus, np);
if (err) {
dev_err(chip->dev, "Cannot register MDIO bus (%d)\n", err);
mv88e6xxx_g2_irq_mdio_free(chip, bus);
diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
index b4c9268100bb..3e93df5d4e3b 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -591,16 +591,10 @@ static int macb_mii_init(struct macb *bp)
dev_set_drvdata(&bp->dev->dev, bp->mii_bus);
np = bp->pdev->dev.of_node;
+ if (pdata)
+ bp->mii_bus->phy_mask = pdata->phy_mask;
- if (np) {
- err = of_mdiobus_register(bp->mii_bus, np);
- } else {
- if (pdata)
- bp->mii_bus->phy_mask = pdata->phy_mask;
-
- err = mdiobus_register(bp->mii_bus);
- }
-
+ err = of_mdiobus_register(bp->mii_bus, np);
if (err)
goto err_out_free_mdiobus;
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index d4604bc8eb5b..f3e43db0d6cb 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -2052,13 +2052,9 @@ static int fec_enet_mii_init(struct platform_device *pdev)
fep->mii_bus->parent = &pdev->dev;
node = of_get_child_by_name(pdev->dev.of_node, "mdio");
- if (node) {
- err = of_mdiobus_register(fep->mii_bus, node);
+ err = of_mdiobus_register(fep->mii_bus, node);
+ if (node)
of_node_put(node);
- } else {
- err = mdiobus_register(fep->mii_bus);
- }
-
if (err)
goto err_out_free_mdiobus;
diff --git a/drivers/net/ethernet/marvell/mvmdio.c b/drivers/net/ethernet/marvell/mvmdio.c
index 0495487f7b42..c5dac6bd2be4 100644
--- a/drivers/net/ethernet/marvell/mvmdio.c
+++ b/drivers/net/ethernet/marvell/mvmdio.c
@@ -348,10 +348,7 @@ static int orion_mdio_probe(struct platform_device *pdev)
goto out_mdio;
}
- if (pdev->dev.of_node)
- ret = of_mdiobus_register(bus, pdev->dev.of_node);
- else
- ret = mdiobus_register(bus);
+ ret = of_mdiobus_register(bus, pdev->dev.of_node);
if (ret < 0) {
dev_err(&pdev->dev, "Cannot register MDIO bus (%d)\n", ret);
goto out_mdio;
diff --git a/drivers/net/ethernet/renesas/sh_eth.c b/drivers/net/ethernet/renesas/sh_eth.c
index 5970d9e5ddf1..8dd41e08a6c6 100644
--- a/drivers/net/ethernet/renesas/sh_eth.c
+++ b/drivers/net/ethernet/renesas/sh_eth.c
@@ -3025,15 +3025,10 @@ static int sh_mdio_init(struct sh_eth_private *mdp,
pdev->name, pdev->id);
/* register MDIO bus */
- if (dev->of_node) {
- ret = of_mdiobus_register(mdp->mii_bus, dev->of_node);
- } else {
- if (pd->phy_irq > 0)
- mdp->mii_bus->irq[pd->phy] = pd->phy_irq;
-
- ret = mdiobus_register(mdp->mii_bus);
- }
+ if (pd->phy_irq > 0)
+ mdp->mii_bus->irq[pd->phy] = pd->phy_irq;
+ ret = of_mdiobus_register(mdp->mii_bus, dev->of_node);
if (ret)
goto out_free_bus;
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
index f5f37bfa1d58..5df1a608e566 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
@@ -233,10 +233,7 @@ int stmmac_mdio_register(struct net_device *ndev)
new_bus->phy_mask = mdio_bus_data->phy_mask;
new_bus->parent = priv->device;
- if (mdio_node)
- err = of_mdiobus_register(new_bus, mdio_node);
- else
- err = mdiobus_register(new_bus);
+ err = of_mdiobus_register(new_bus, mdio_node);
if (err != 0) {
dev_err(dev, "Cannot register the MDIO bus\n");
goto bus_register_fail;
diff --git a/drivers/net/ethernet/ti/davinci_mdio.c b/drivers/net/ethernet/ti/davinci_mdio.c
index 98a1c97fb95e..e720244e7f71 100644
--- a/drivers/net/ethernet/ti/davinci_mdio.c
+++ b/drivers/net/ethernet/ti/davinci_mdio.c
@@ -431,10 +431,8 @@ static int davinci_mdio_probe(struct platform_device *pdev)
*/
if (dev->of_node && of_get_child_count(dev->of_node)) {
data->skip_scan = true;
- ret = of_mdiobus_register(data->bus, dev->of_node);
- } else {
- ret = mdiobus_register(data->bus);
- }
+
+ ret = of_mdiobus_register(data->bus, dev->of_node);
if (ret)
goto bail_out;
diff --git a/drivers/net/phy/mdio-gpio.c b/drivers/net/phy/mdio-gpio.c
index b501221819e1..4e4c8daf44c3 100644
--- a/drivers/net/phy/mdio-gpio.c
+++ b/drivers/net/phy/mdio-gpio.c
@@ -179,11 +179,7 @@ static int mdio_gpio_probe(struct platform_device *pdev)
if (!new_bus)
return -ENODEV;
- if (pdev->dev.of_node)
- ret = of_mdiobus_register(new_bus, pdev->dev.of_node);
- else
- ret = mdiobus_register(new_bus);
-
+ ret = of_mdiobus_register(new_bus, pdev->dev.of_node);
if (ret)
mdio_gpio_bus_deinit(&pdev->dev);
diff --git a/drivers/net/phy/mdio-mscc-miim.c b/drivers/net/phy/mdio-mscc-miim.c
index 8c689ccfdbca..badbc99bedd3 100644
--- a/drivers/net/phy/mdio-mscc-miim.c
+++ b/drivers/net/phy/mdio-mscc-miim.c
@@ -151,11 +151,7 @@ static int mscc_miim_probe(struct platform_device *pdev)
}
}
- if (pdev->dev.of_node)
- ret = of_mdiobus_register(bus, pdev->dev.of_node);
- else
- ret = mdiobus_register(bus);
-
+ ret = of_mdiobus_register(bus, pdev->dev.of_node);
if (ret < 0) {
dev_err(&pdev->dev, "Cannot register MDIO bus (%d)\n", ret);
return ret;
diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c
index 91761436709a..8dff87ec6d99 100644
--- a/drivers/net/usb/lan78xx.c
+++ b/drivers/net/usb/lan78xx.c
@@ -1843,12 +1843,9 @@ static int lan78xx_mdio_init(struct lan78xx_net *dev)
}
node = of_get_child_by_name(dev->udev->dev.of_node, "mdio");
- if (node) {
- ret = of_mdiobus_register(dev->mdiobus, node);
+ ret = of_mdiobus_register(dev->mdiobus, node);
+ if (node)
of_node_put(node);
- } else {
- ret = mdiobus_register(dev->mdiobus);
- }
if (ret) {
netdev_err(dev->net, "can't register MDIO bus\n");
goto exit1;
--
2.14.1
^ permalink raw reply related
* [PATCH net-next 1/2] of: mdio: Fall back to mdiobus_register() with np is NULL
From: Florian Fainelli @ 2018-05-15 21:59 UTC (permalink / raw)
To: netdev
Cc: Florian Fainelli, Andrew Lunn, Vivien Didelot, David S. Miller,
Nicolas Ferre, Fugang Duan, Sergei Shtylyov, Giuseppe Cavallaro,
Alexandre Torgue, Jose Abreu, Grygorii Strashko, Woojung Huh,
Microchip Linux Driver Support, Rob Herring, Frank Rowand,
Antoine Tenart, Tobias Jordan, Russell King <r
In-Reply-To: <20180515215930.12115-1-f.fainelli@gmail.com>
When the Device Tree node specified is NULL, fall back to
mdiobus_register(). We have a number of drivers having a similar pattern
which is:
if (np)
of_mdiobus_register()
else
mdiobus_register()
so incorporate that behavior within the core of_mdiobus_register()
function. This is also consistent with the stub version that we defined
when CONFIG_OF=n.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/of/of_mdio.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
index 8c0c92712fc9..2341dbf675bf 100644
--- a/drivers/of/of_mdio.c
+++ b/drivers/of/of_mdio.c
@@ -204,6 +204,12 @@ int of_mdiobus_register(struct mii_bus *mdio, struct device_node *np)
bool scanphys = false;
int addr, rc;
+ /* If the Device Tree node does not exist, fall back to traditional
+ * registration
+ */
+ if (!np)
+ return mdiobus_register(mdio);
+
/* Do not continue if the node is disabled */
if (!of_device_is_available(np))
return -ENODEV;
--
2.14.1
^ permalink raw reply related
* [PATCH net-next 0/2] of: mdio: Fall back to mdiobus_register() with np is NULL
From: Florian Fainelli @ 2018-05-15 21:59 UTC (permalink / raw)
To: netdev
Cc: Florian Fainelli, Andrew Lunn, Vivien Didelot, David S. Miller,
Nicolas Ferre, Fugang Duan, Sergei Shtylyov, Giuseppe Cavallaro,
Alexandre Torgue, Jose Abreu, Grygorii Strashko, Woojung Huh,
Microchip Linux Driver Support, Rob Herring, Frank Rowand,
Antoine Tenart, Tobias Jordan, Russell King <r
Hi all,
This patch series updates of_mdiobus_register() such that when the device_node
argument is NULL, it calls mdiobus_register() directly. This is consistent with
the behavior of of_mdiobus_register() when CONFIG_OF=n.
I only converted the most obvious drivers, there are others that have a much
less obvious behavior and specifically attempt to deal with CONFIG_ACPI.
Florian Fainelli (2):
of: mdio: Fall back to mdiobus_register() with np is NULL
drivers: net: Remove device_node checks with of_mdiobus_register()
drivers/net/dsa/bcm_sf2.c | 8 ++------
drivers/net/dsa/mv88e6xxx/chip.c | 5 +----
drivers/net/ethernet/cadence/macb_main.c | 12 +++---------
drivers/net/ethernet/freescale/fec_main.c | 8 ++------
drivers/net/ethernet/marvell/mvmdio.c | 5 +----
drivers/net/ethernet/renesas/sh_eth.c | 11 +++--------
drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c | 5 +----
drivers/net/ethernet/ti/davinci_mdio.c | 6 ++----
drivers/net/phy/mdio-gpio.c | 6 +-----
drivers/net/phy/mdio-mscc-miim.c | 6 +-----
drivers/net/usb/lan78xx.c | 7 ++-----
drivers/of/of_mdio.c | 6 ++++++
12 files changed, 25 insertions(+), 60 deletions(-)
--
2.14.1
^ permalink raw reply
* [PATCH iproute2] Allow to configure /var/run/netns directory
From: Pavel Maltsev @ 2018-05-15 21:49 UTC (permalink / raw)
To: netdev, lorenzo, stephen, pavelm; +Cc: lorenzo, stephen, Pavel Maltsev
Currently NETNS_RUN_DIR is hardcoded and refers to /var/run/netns.
However, some systems (e.g. Android) doesn't have /var
which results in error attempts to create network namespaces on these
systems. This change makes NETNS_RUN_DIR configurable at build time
by allowing to pass environment variable to configre script.
For example: NETNS_RUN_DIR=/mnt/vendor/netns ./configure && make
Tested: verified that iproute2 with configuration mentioned above
creates namespaces in /mnt/vendor/netns
Signed-off-by: Pavel Maltsev <pavelm@google.com>
---
configure | 3 +++
include/namespace.h | 3 +++
2 files changed, 6 insertions(+)
diff --git a/configure b/configure
index 5ef5cd4c..a6a222da 100755
--- a/configure
+++ b/configure
@@ -213,6 +213,9 @@ EOF
echo "IP_CONFIG_SETNS:=y" >>$CONFIG
echo "yes"
echo "CFLAGS += -DHAVE_SETNS" >>$CONFIG
+ if [ -n "$NETNS_RUN_DIR" ]; then
+ echo "CFLAGS += -DNETNS_RUN_DIR=\\\"$NETNS_RUN_DIR\\\"" >>$CONFIG
+ fi
else
echo "no"
fi
diff --git a/include/namespace.h b/include/namespace.h
index aed7ce08..b8fb14df 100644
--- a/include/namespace.h
+++ b/include/namespace.h
@@ -8,7 +8,10 @@
#include <sys/syscall.h>
#include <errno.h>
+#ifndef NETNS_RUN_DIR
#define NETNS_RUN_DIR "/var/run/netns"
+#endif /* NETNS_RUN_DIR */
+
#define NETNS_ETC_DIR "/etc/netns"
#ifndef CLONE_NEWNET
--
2.17.0.441.gb46fe60e1d-goog
^ permalink raw reply related
* Re: [PATCH 00/14] Modify action API for implementing lockless actions
From: Jamal Hadi Salim @ 2018-05-15 21:49 UTC (permalink / raw)
To: Vlad Buslov
Cc: netdev, davem, xiyou.wangcong, jiri, pablo, kadlec, fw, ast,
daniel, edumazet, kliteyn
In-Reply-To: <vbfh8n81uoc.fsf@reg-r-vrt-018-180.mtr.labs.mlnx>
On 15/05/18 05:21 PM, Vlad Buslov wrote:
>
> On Tue 15 May 2018 at 18:25, Jamal Hadi Salim <jhs@mojatatu.com> wrote:
>> On 14/05/18 04:46 PM, Vlad Buslov wrote:
>>>
>>> On Mon 14 May 2018 at 18:03, Jamal Hadi Salim <jhs@mojatatu.com> wrote:
>>>> On 14/05/18 10:27 AM, Vlad Buslov wrote:
>>
>>
>>> Hello Jamal,
>>>
>>> I'm trying to run tdc, but keep getting following error even on clean
>>> branch without my patches:
>>
>> Vlad, not sure if you saw my email:
>> Apply Roman's patch and try again
>>
>> https://marc.info/?l=linux-netdev&m=152639369112020&w=2
>>
>> cheers,
>> jamal
>
> With patch applied I get following error:
>
> Test 7d50: Add skbmod action to set destination mac
> exit: 255 0
> dst MAC address <11:22:33:44:55:66>
> RTNETLINK answers: No such file or directory
> We have an error talking to the kernel
>
You may actually have broken something with your patches in this case.
Lucas - does this test pass on latest net-next?
cheers,
jamal
PS:- any reason for the big Cc? I have trimmed it down.
^ permalink raw reply
* Re: i40e - Is i40e_force_link_state doing the right thing ?
From: Chaitanya Lala @ 2018-05-15 21:47 UTC (permalink / raw)
To: Stachura, Mariusz
Cc: netdev@vger.kernel.org, Williams, Mitch A, Bowers, AndrewX,
Kirsher, Jeffrey T
In-Reply-To: <1F86EBA5C8668B468CEE1C33B96E862B36905DA1@IRSMSX104.ger.corp.intel.com>
Hi Mariusz, ...
On Tue, May 15, 2018 at 2:24 PM, Stachura, Mariusz
<mariusz.stachura@intel.com> wrote:
> On Tue, May 15, 2018 at 1:15 PM, Chaitanya Lala <chaitanya.lala@gmail.com> wrote:
>> Hi,
>>
>> I am trying to bring up a Intel XL710 4x10G Intel card using the
>> latest mainline top-of-tree.
>> The problem is that "ifconfig up" and "ifconfig down" do not take
>> effect at the link state level.
>> I tracked the problem down to i40e_force_link_state() when it is
>> called from i40e_down().
>> It calls i40e_force_link_state with "is_up" == false. In-turn it
>> calls, i40e_aq_set_link_restart_an(hw, true, NULL).
>>
>> Should the second argument of i40e_aq_set_link_restart_an be "is_up"
>> vs the current "true"
>> i.e. i40e_aq_set_link_restart_an(hw, is_up, NULL). ? When I make this
>> change, the link state syncs-up with the interface administrative
>> state.
>>
>> Is this a bug ?
>>
>> Thanks,
>> Chaitanya
>
> Hello Chaitanya,
>
> i40e_down() calls i40e_force_link_state with "is_up" == false only if interface's private flag "link-down-on-close" is set. By default the link is left up for manageability and VF traffic, user can use this flag to power down the interface on the link level. Does that work for you?
> The command is:
> "ethtool --set-priv-flags IFNAME link-down-on-close on" and then
This flag is _on_ in my setup and hencet i40e_force_link_state is
being called with is_up == false in my setup. The problem is that
irrespective of
value of "is_up" flag, i40e_force_link_state invokes
i40e_aq_set_link_restart_an with second argument (enable_link) as
"true". So i40e_aq_set_link_restart_an
is always trying to enable link even if is_up was false. Is that
correct behavior ?
I have pasted code with my annotations below marked with "//XXX".
/**
* i40e_force_link_state - Force the link status
* @pf: board private structure
* @is_up: whether the link state should be forced up or down
**/
static i40e_status i40e_force_link_state(struct i40e_pf *pf, bool
is_up) // XXX is_up was _false_ in my test case because I have
link-down-on-close "on"
{
struct i40e_aq_get_phy_abilities_resp abilities;
struct i40e_aq_set_phy_config config = {0};
struct i40e_hw *hw = &pf->hw;
i40e_status err;
u64 mask;
/* Get the current phy config */
err = i40e_aq_get_phy_capabilities(hw, false, false, &abilities,
NULL);
if (err) {
dev_err(&pf->pdev->dev,
"failed to get phy cap., ret = %s last_status = %s\n",
i40e_stat_str(hw, err),
i40e_aq_str(hw, hw->aq.asq_last_status));
return err;
}
/* If link needs to go up, but was not forced to go down,
* no need for a flap
*/
if (is_up && abilities.phy_type != 0)
return I40E_SUCCESS;
/* To force link we need to set bits for all supported PHY types,
* but there are now more than 32, so we need to split the bitmap
* across two fields.
*/
mask = I40E_PHY_TYPES_BITMASK;
config.phy_type = is_up ? cpu_to_le32((u32)(mask & 0xffffffff)) : 0;
config.phy_type_ext = is_up ? (u8)((mask >> 32) & 0xff) : 0;
/* Copy the old settings, except of phy_type */
config.abilities = abilities.abilities;
config.link_speed = abilities.link_speed;
config.eee_capability = abilities.eee_capability;
config.eeer = abilities.eeer_val;
config.low_power_ctrl = abilities.d3_lpan;
err = i40e_aq_set_phy_config(hw, &config, NULL);
if (err) {
dev_err(&pf->pdev->dev,
"set phy config ret = %s last_status = %s\n",
i40e_stat_str(&pf->hw, err),
i40e_aq_str(&pf->hw, pf->hw.aq.asq_last_status));
return err;
}
/* Update the link info */
err = i40e_update_link_info(hw);
if (err) {
/* Wait a little bit (on 40G cards it sometimes takes a really
* long time for link to come back from the atomic reset)
* and try once more
*/
msleep(1000);
i40e_update_link_info(hw);
}
i40e_aq_set_link_restart_an(hw, true, NULL); // XXX Second argument is
unconditionally true. Should it not be is_up instead of true ?
return I40E_SUCCESS;
}
Thanks,
Chaitanya
> "ifconfig IFNAME down"
>
> Best regards!
> Mariusz
> --------------------------------------------------------------------
>
> Intel Technology Poland sp. z o.o.
> ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 | Kapital zakladowy 200.000 PLN.
>
> Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i moze zawierac informacje poufne. W razie przypadkowego otrzymania tej wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; jakiekolwiek
> przegladanie lub rozpowszechnianie jest zabronione.
> This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by
> others is strictly prohibited.
^ permalink raw reply
* RE: i40e - Is i40e_force_link_state doing the right thing ?
From: Stachura, Mariusz @ 2018-05-15 21:24 UTC (permalink / raw)
To: Chaitanya Lala, netdev@vger.kernel.org, Williams, Mitch A,
Bowers, AndrewX, Kirsher, Jeffrey T
In-Reply-To: <CABOGejK8bnwU0iqO5-GRO8FX6tCaMYtS+UORPrug3E7LqeWg1Q@mail.gmail.com>
On Tue, May 15, 2018 at 1:15 PM, Chaitanya Lala <chaitanya.lala@gmail.com> wrote:
> Hi,
>
> I am trying to bring up a Intel XL710 4x10G Intel card using the
> latest mainline top-of-tree.
> The problem is that "ifconfig up" and "ifconfig down" do not take
> effect at the link state level.
> I tracked the problem down to i40e_force_link_state() when it is
> called from i40e_down().
> It calls i40e_force_link_state with "is_up" == false. In-turn it
> calls, i40e_aq_set_link_restart_an(hw, true, NULL).
>
> Should the second argument of i40e_aq_set_link_restart_an be "is_up"
> vs the current "true"
> i.e. i40e_aq_set_link_restart_an(hw, is_up, NULL). ? When I make this
> change, the link state syncs-up with the interface administrative
> state.
>
> Is this a bug ?
>
> Thanks,
> Chaitanya
Hello Chaitanya,
i40e_down() calls i40e_force_link_state with "is_up" == false only if interface's private flag "link-down-on-close" is set. By default the link is left up for manageability and VF traffic, user can use this flag to power down the interface on the link level. Does that work for you?
The command is:
"ethtool --set-priv-flags IFNAME link-down-on-close on" and then
"ifconfig IFNAME down"
Best regards!
Mariusz
--------------------------------------------------------------------
Intel Technology Poland sp. z o.o.
ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 | Kapital zakladowy 200.000 PLN.
Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i moze zawierac informacje poufne. W razie przypadkowego otrzymania tej wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; jakiekolwiek
przegladanie lub rozpowszechnianie jest zabronione.
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by
others is strictly prohibited.
^ permalink raw reply
* Re: [PATCH 00/14] Modify action API for implementing lockless actions
From: Vlad Buslov @ 2018-05-15 21:21 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: netdev, davem, xiyou.wangcong, jiri, pablo, kadlec, fw, ast,
daniel, edumazet, keescook, linux-kernel, netfilter-devel,
coreteam, kliteyn
In-Reply-To: <97ccb118-a3dc-6eb0-b127-9c04adf9e2fd@mojatatu.com>
On Tue 15 May 2018 at 18:25, Jamal Hadi Salim <jhs@mojatatu.com> wrote:
> On 14/05/18 04:46 PM, Vlad Buslov wrote:
>>
>> On Mon 14 May 2018 at 18:03, Jamal Hadi Salim <jhs@mojatatu.com> wrote:
>>> On 14/05/18 10:27 AM, Vlad Buslov wrote:
>
>
>> Hello Jamal,
>>
>> I'm trying to run tdc, but keep getting following error even on clean
>> branch without my patches:
>
> Vlad, not sure if you saw my email:
> Apply Roman's patch and try again
>
> https://marc.info/?l=linux-netdev&m=152639369112020&w=2
>
> cheers,
> jamal
With patch applied I get following error:
Test 7d50: Add skbmod action to set destination mac
exit: 255 0
dst MAC address <11:22:33:44:55:66>
RTNETLINK answers: No such file or directory
We have an error talking to the kernel
-----> teardown stage *** Could not execute: "$TC actions flush action skbmod"
-----> teardown stage *** Error message: "RTNETLINK answers: Invalid argument
We have an error flushing
"
-----> teardown stage *** Aborting test run.
<_io.BufferedReader name=3> *** stdout ***
<_io.BufferedReader name=5> *** stderr ***
"-----> teardown stage" did not complete successfully
Exception <class '__main__.PluginMgrTestFail'> ('teardown', 'dst MAC address <11:22:33:44:55:66>\nRTNETLINK answers: No such file or directory\nWe have an error talking to the kernel\n', '"-----> teardown stage" did not complete successful
ly') (caught in test_runner, running test 87 7d50 Add skbmod action to set destination mac stage teardown)
---------------
traceback
File "./tdc.py", line 293, in test_runner
tap += run_one_test(pm, args, index, tidx)
File "./tdc.py", line 229, in run_one_test
prepare_env(args, pm, 'teardown', '-----> teardown stage', tidx['teardown'], procout)
File "./tdc.py", line 177, in prepare_env
'"{}" did not complete successfully'.format(prefix))
---------------
accumulated output for this test:
dst MAC address <11:22:33:44:55:66>
RTNETLINK answers: No such file or directory
We have an error talking to the kernel
---------------
Regards,
Vlad
^ permalink raw reply
* Re: [PATCH bpf-next v6 2/4] bpf: sockmap, add hash map support
From: Y Song @ 2018-05-15 21:09 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: John Fastabend, Alexei Starovoitov, netdev, David Miller
In-Reply-To: <cc2e3011-0309-842c-4dbc-d3e82d5fc2d0@iogearbox.net>
On Tue, May 15, 2018 at 12:01 PM, Daniel Borkmann <daniel@iogearbox.net> wrote:
> On 05/14/2018 07:00 PM, John Fastabend wrote:
>> Sockmap is currently backed by an array and enforces keys to be
>> four bytes. This works well for many use cases and was originally
>> modeled after devmap which also uses four bytes keys. However,
>> this has become limiting in larger use cases where a hash would
>> be more appropriate. For example users may want to use the 5-tuple
>> of the socket as the lookup key.
>>
>> To support this add hash support.
>>
>> Signed-off-by: John Fastabend <john.fastabend@gmail.com>
>> Acked-by: David S. Miller <davem@davemloft.net>
>> ---
>> include/linux/bpf.h | 8 +
>> include/linux/bpf_types.h | 1 +
>> include/uapi/linux/bpf.h | 52 ++++-
>> kernel/bpf/core.c | 1 +
>> kernel/bpf/sockmap.c | 494 ++++++++++++++++++++++++++++++++++++++++++++--
>> kernel/bpf/verifier.c | 14 +-
>> net/core/filter.c | 58 ++++++
>> 7 files changed, 610 insertions(+), 18 deletions(-)
>>
>> diff --git a/include/linux/bpf.h b/include/linux/bpf.h
>> index a38e474..ed0122b 100644
>> --- a/include/linux/bpf.h
>> +++ b/include/linux/bpf.h
>> @@ -668,6 +668,7 @@ static inline void bpf_map_offload_map_free(struct bpf_map *map)
>>
>> #if defined(CONFIG_STREAM_PARSER) && defined(CONFIG_BPF_SYSCALL) && defined(CONFIG_INET)
>> struct sock *__sock_map_lookup_elem(struct bpf_map *map, u32 key);
>> +struct sock *__sock_hash_lookup_elem(struct bpf_map *map, void *key);
>> int sock_map_prog(struct bpf_map *map, struct bpf_prog *prog, u32 type);
>> #else
>> static inline struct sock *__sock_map_lookup_elem(struct bpf_map *map, u32 key)
>> @@ -675,6 +676,12 @@ static inline struct sock *__sock_map_lookup_elem(struct bpf_map *map, u32 key)
>> return NULL;
>> }
>>
>> +static inline struct sock *__sock_hash_lookup_elem(struct bpf_map *map,
>> + void *key)
>> +{
>> + return NULL;
>> +}
>> +
>> static inline int sock_map_prog(struct bpf_map *map,
>> struct bpf_prog *prog,
>> u32 type)
>> @@ -724,6 +731,7 @@ static inline void __xsk_map_flush(struct bpf_map *map)
>> extern const struct bpf_func_proto bpf_get_stackid_proto;
>> extern const struct bpf_func_proto bpf_get_stack_proto;
>> extern const struct bpf_func_proto bpf_sock_map_update_proto;
>> +extern const struct bpf_func_proto bpf_sock_hash_update_proto;
>>
>> /* Shared helpers among cBPF and eBPF. */
>> void bpf_user_rnd_init_once(void);
>> diff --git a/include/linux/bpf_types.h b/include/linux/bpf_types.h
>> index d7df1b32..b67f879 100644
>> --- a/include/linux/bpf_types.h
>> +++ b/include/linux/bpf_types.h
>> @@ -47,6 +47,7 @@
>> BPF_MAP_TYPE(BPF_MAP_TYPE_DEVMAP, dev_map_ops)
>> #if defined(CONFIG_STREAM_PARSER) && defined(CONFIG_INET)
>> BPF_MAP_TYPE(BPF_MAP_TYPE_SOCKMAP, sock_map_ops)
>> +BPF_MAP_TYPE(BPF_MAP_TYPE_SOCKHASH, sock_hash_ops)
>> #endif
>> BPF_MAP_TYPE(BPF_MAP_TYPE_CPUMAP, cpu_map_ops)
>> #if defined(CONFIG_XDP_SOCKETS)
>> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
>> index 02e4112..1205d86 100644
>> --- a/include/uapi/linux/bpf.h
>> +++ b/include/uapi/linux/bpf.h
>> @@ -118,6 +118,7 @@ enum bpf_map_type {
>> BPF_MAP_TYPE_SOCKMAP,
>> BPF_MAP_TYPE_CPUMAP,
>> BPF_MAP_TYPE_XSKMAP,
>> + BPF_MAP_TYPE_SOCKHASH,
>> };
>>
>> enum bpf_prog_type {
>> @@ -1855,6 +1856,52 @@ struct bpf_stack_build_id {
>> * Egress device index on success, 0 if packet needs to continue
>> * up the stack for further processing or a negative error in case
>> * of failure.
>> + * int bpf_sock_hash_update(struct bpf_sock_ops_kern *skops, struct bpf_map *map, void *key, u64 flags)
>
> When you rebase please fix this up properly next time and add a newline in between
> the helpers. I fixed this up while applying.
I guess the tools/include/uapi/linux/bpf.h may also need fixup to be
in sync with main bpf.h.
^ permalink raw reply
* Re: Poor TCP performance with XPS enabled after scrubbing skb
From: Eric Dumazet @ 2018-05-15 21:08 UTC (permalink / raw)
To: Flavio Leitner, netdev; +Cc: Paolo Abeni
In-Reply-To: <20180515193128.GA11901@plex.lan>
On 05/15/2018 12:31 PM, Flavio Leitner wrote:
> Hi,
>
> There is a significant throughput issue (~50% drop) for a single TCP
> stream when the skb is scrubbed and XPS is enabled.
>
> If I turn CONFIG_XPS off, then the issue never happens and the test
> reaches line rate. The same happens if I echo 0 to tx-*/xps_cpus.
>
> It looks like that when the skb is scrubbed, there is no more reference
> to the struct sock,
And this is really the problem here, since it breaks back pressure (and TCP Small queues)
I am not sure why skb_orphan() is used in this scrubbing really.
^ permalink raw reply
* Re: [PATCH net-next v3 0/7] Microsemi Ocelot Ethernet switch support
From: David Miller @ 2018-05-15 20:45 UTC (permalink / raw)
To: alexandre.belloni
Cc: Allan.Nielsen, razvan.stefanescu, po.liu, thomas.petazzoni,
andrew, f.fainelli, netdev, linux-kernel, linux-mips, jhogan
In-Reply-To: <20180514200500.2953-1-alexandre.belloni@bootlin.com>
From: Alexandre Belloni <alexandre.belloni@bootlin.com>
Date: Mon, 14 May 2018 22:04:53 +0200
> The ocelot dts changes are here for reference and should probably go
> through the MIPS tree once the bindings are accepted.
Ok, series applied to net-next minus patches #5 and #6.
Thank you.
^ permalink raw reply
* Re: [PATCH v2 iproute2-next 1/3] rdma: update rdma_netlink.h to get new driver attributes
From: Doug Ledford @ 2018-05-15 20:39 UTC (permalink / raw)
To: Steve Wise, 'David Ahern', leon; +Cc: stephen, netdev, linux-rdma
In-Reply-To: <004901d3ec8b$4b9ac5c0$e2d05140$@opengridcomputing.com>
[-- Attachment #1: Type: text/plain, Size: 2390 bytes --]
On Tue, 2018-05-15 at 15:28 -0500, Steve Wise wrote:
> > -----Original Message-----
> > From: linux-rdma-owner@vger.kernel.org <linux-rdma-
> > owner@vger.kernel.org> On Behalf Of Doug Ledford
> > Sent: Tuesday, May 15, 2018 2:53 PM
> > To: David Ahern <dsahern@gmail.com>; Steve Wise
> > <swise@opengridcomputing.com>; leon@kernel.org
> > Cc: stephen@networkplumber.org; netdev@vger.kernel.org; linux-
> > rdma@vger.kernel.org
> > Subject: Re: [PATCH v2 iproute2-next 1/3] rdma: update rdma_netlink.h to
> > get new driver attributes
> >
> > On Tue, 2018-05-15 at 13:37 -0600, David Ahern wrote:
> > > On 5/14/18 9:42 AM, Steve Wise wrote:
> > > > diff --git a/rdma/include/uapi/rdma/rdma_netlink.h
> >
> > b/rdma/include/uapi/rdma/rdma_netlink.h
> > > > index 60416ed..40be0d8 100644
> > > > --- a/rdma/include/uapi/rdma/rdma_netlink.h
> > > > +++ b/rdma/include/uapi/rdma/rdma_netlink.h
> > > >
> > > > @@ -387,6 +399,20 @@ enum rdma_nldev_attr {
> > > > RDMA_NLDEV_ATTR_RES_PD_ENTRY, /* nested table */
> > > > RDMA_NLDEV_ATTR_RES_LOCAL_DMA_LKEY, /* u32 */
> > > > RDMA_NLDEV_ATTR_RES_UNSAFE_GLOBAL_RKEY, /* u32 */
> > > > + /*
> > > > + * driver-specific attributes.
> > > > + */
> > > > + RDMA_NLDEV_ATTR_DRIVER, /* nested table */
> > > > + RDMA_NLDEV_ATTR_DRIVER_ENTRY, /* nested table */
> > > > + RDMA_NLDEV_ATTR_DRIVER_STRING, /* string */
> > > > + /*
> > > > + * u8 values from enum rdma_nldev_print_type
> > > > + */
> > > > + RDMA_NLDEV_ATTR_DRIVER_PRINT_TYPE, /* u8 */
> > > > + RDMA_NLDEV_ATTR_DRIVER_S32, /* s32 */
> > > > + RDMA_NLDEV_ATTR_DRIVER_U32, /* u32 */
> > > > + RDMA_NLDEV_ATTR_DRIVER_S64, /* s64 */
> > > > + RDMA_NLDEV_ATTR_DRIVER_U64, /* u64 */
> > >
> > > and again here.
> >
> > This chunk, however, is a problem. We'll need to fix that in the kernel
> > and in this patch too.
>
> I'll fix this series once I fix the kernel side. Doug, should I send a patch that basically moves the DRIVER attributes to the bottom?
>
> Sorry about missing this!
I missed it too. I knew about the first hunk, but thought this one was
at the end. Anyway, I've already pushed the fix to my wip/dl-for-next
branch, so you can get it there now.
--
Doug Ledford <dledford@redhat.com>
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: i40e - Is i40e_force_link_state doing the right thing ?
From: Alexander Duyck @ 2018-05-15 20:31 UTC (permalink / raw)
To: Chaitanya Lala, intel-wired-lan
Cc: Netdev, mariusz.stachura, Mitch Williams, Bowers, AndrewX,
Jeff Kirsher
In-Reply-To: <CABOGejK8bnwU0iqO5-GRO8FX6tCaMYtS+UORPrug3E7LqeWg1Q@mail.gmail.com>
On Tue, May 15, 2018 at 1:15 PM, Chaitanya Lala
<chaitanya.lala@gmail.com> wrote:
> Hi,
>
> I am trying to bring up a Intel XL710 4x10G Intel card using the
> latest mainline top-of-tree.
> The problem is that "ifconfig up" and "ifconfig down" do not take
> effect at the link state level.
> I tracked the problem down to i40e_force_link_state() when it is
> called from i40e_down().
> It calls i40e_force_link_state with "is_up" == false. In-turn it
> calls, i40e_aq_set_link_restart_an(hw, true, NULL).
>
> Should the second argument of i40e_aq_set_link_restart_an be "is_up"
> vs the current "true"
> i.e. i40e_aq_set_link_restart_an(hw, is_up, NULL). ? When I make this
> change, the link state syncs-up with
> the interface administrative state.
>
> Is this a bug ?
>
> Thanks,
> Chaitanya
If you are calling i40e_down the assumption is you are bringing the
interface down, so as not to pass traffic. That is why the "is_up" is
set to false.
Could you provide the dmesg results for when you load the driver and
execute the "ifconfig up" and "ifconfig down" commands? That would
help us to understand what might be going on.
Thanks.
- Alex
^ permalink raw reply
* RE: [PATCH v2 iproute2-next 1/3] rdma: update rdma_netlink.h to get new driver attributes
From: Steve Wise @ 2018-05-15 20:29 UTC (permalink / raw)
To: 'David Ahern', 'Doug Ledford', leon
Cc: stephen, netdev, linux-rdma
In-Reply-To: <fd64ce39-a284-b09f-85b0-8cd7ba0d1207@gmail.com>
> -----Original Message-----
> From: David Ahern <dsahern@gmail.com>
> Sent: Tuesday, May 15, 2018 3:02 PM
> To: Doug Ledford <dledford@redhat.com>; Steve Wise
> <swise@opengridcomputing.com>; leon@kernel.org
> Cc: stephen@networkplumber.org; netdev@vger.kernel.org; linux-
> rdma@vger.kernel.org
> Subject: Re: [PATCH v2 iproute2-next 1/3] rdma: update rdma_netlink.h to
> get new driver attributes
>
> On 5/15/18 2:00 PM, Doug Ledford wrote:
> > I just sent an incremental fix to the list under separate cover. You
> > can squash that fix into Steve's patch and it should resolve the issue.
> > Or Steve can respin the set. Either way.
>
> Once the patch has been committed to the upstream repo, spin a new set
> with the correct header update.
Will do!
Steve.
^ 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