Netdev List
 help / color / mirror / Atom feed
* Re: [PATCH 2/4] ravb: Add optional PHY reset during system resume
From: Florian Fainelli @ 2017-10-01 16:34 UTC (permalink / raw)
  To: Sergei Shtylyov, Geert Uytterhoeven
  Cc: Geert Uytterhoeven, David S . Miller, Simon Horman, Magnus Damm,
	Andrew Lunn, Niklas Söderlund, netdev@vger.kernel.org,
	Linux-Renesas, devicetree@vger.kernel.org
In-Reply-To: <47456e34-2c2f-ec19-fcda-e3132a8037b3@cogentembedded.com>



On 09/30/2017 01:23 PM, Sergei Shtylyov wrote:
> Hello!
> 
> On 09/28/2017 10:21 PM, Florian Fainelli wrote:
> 
>>>>> If the optional "reset-gpios" property is specified in DT, the generic
>>>>> MDIO bus code takes care of resetting the PHY during device probe.
>>>>> However, the PHY may still have to be reset explicitly after system
>>>>> resume.
>>>>>
>>>>> This allows to restore Ethernet operation after resume from s2ram on
>>>>> Salvator-XS, where the enable pin of the regulator providing PHY power
>>>>> is connected to PRESETn, and PSCI suspend powers down the SoC.
>>>>>
>>>>> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
>>>>> ---
>>>>>   drivers/net/ethernet/renesas/ravb_main.c | 9 +++++++++
>>>>>   1 file changed, 9 insertions(+)
>>>>>
>>>>> diff --git a/drivers/net/ethernet/renesas/ravb_main.c
>>>>> b/drivers/net/ethernet/renesas/ravb_main.c
>>>>> index fdf30bfa403bf416..96d1d48e302f8c9a 100644
>>>>> --- a/drivers/net/ethernet/renesas/ravb_main.c
>>>>> +++ b/drivers/net/ethernet/renesas/ravb_main.c
> [...]
>>>>> @@ -2302,6 +2304,13 @@ static int __maybe_unused ravb_resume(struct
>>>>> device *dev)
>>>>>         * reopen device if it was running before system suspended.
>>>>>         */
>>>>>
>>>>> +     /* PHY reset */
>>>>> +     if (bus->reset_gpiod) {
>>>>> +             gpiod_set_value_cansleep(bus->reset_gpiod, 1);
>>>>> +             udelay(bus->reset_delay_us);
>>>>> +             gpiod_set_value_cansleep(bus->reset_gpiod, 0);
>>>>> +     }
>>>>
>>>> This is a clever hack, but unfortunately this is also misusing the MDIO
>>>> bus reset line into a PHY reset line. As commented in patch 3, if this
>>>> reset line is tied to the PHY, then this should be a PHY property and
>>>
>>> OK.
>>>
>>>> you cannot (ab)use the MDIO bus GPIO reset logic anymore...
>>>
>>> And then I should add reset-gpios support to drivers/net/phy/micrel.c?
>>> Or is there already generic code to handle per-PHY reset? I couldn't
>>> find it.
>>
>> There is not such a thing unfortunately, but it would presumably be
> 
>    It's strange you don't remember about my (abandoned) patches to
> handle per=PHY reset GPIOs -- perhaps it's time to unearth them. Here
> they are:
> 
> http://patchwork.ozlabs.org/patch/616495/
> http://patchwork.ozlabs.org/patch/616501/
> 
>    I had v3 in the works before abandoning this series -- it doesn't
> apply now.

Should Geert pick-up where you left and address the feedback given in
v2, or do you plan to post a rebased v3?

> 
>> called within drivers/net/phy/mdio_bus.c during bus->reset() time
>> because you need the PHY reset to be deasserted before you can
>> successfully read/write from the PHY, and if you can't read/write from
>> the PHY, the MDIO bus layer cannot read the PHY ID, and therefore cannot
>> match a PHY device with its driver, so things don't work.
> 
>    I did this a bit differently...
> 
> [...]
> 
> MBR, Sergei

-- 
Florian

^ permalink raw reply

* [PATCH][next] mlxsw: spectrum: fix uninitialized value in err
From: Colin King @ 2017-10-01 16:27 UTC (permalink / raw)
  To: Jiri Pirko, Ido Schimmel, netdev; +Cc: kernel-janitors, linux-kernel

From: Colin Ian King <colin.king@canonical.com>

In the unlikely event that mfc->mfc_un.res.ttls[i] is 255 for all
values of i from 0 to MAXIVS-1, the err is not set at all and hence
has a garbage value on the error return at the end of the function,
so initialize it to 0.  Also, the error return check on err and goto
to err: inside the for loop makes it impossible for err to be zero
at the end of the for loop, so we can remove the redundant err check
at the end of the loop.

Detected by CoverityScan CID#1457207 ("Unitialized scalar value")

Fixes: c011ec1bbfd6 ("mlxsw: spectrum: Add the multicast routing offloading logic")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
 drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c
index 09120259a45d..4aaf6ca1be7c 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c
@@ -349,7 +349,7 @@ mlxsw_sp_mr_route4_create(struct mlxsw_sp_mr_table *mr_table,
 {
 	struct mlxsw_sp_mr_route_vif_entry *rve, *tmp;
 	struct mlxsw_sp_mr_route *mr_route;
-	int err;
+	int err = 0;
 	int i;
 
 	/* Allocate and init a new route and fill it with parameters */
@@ -376,8 +376,6 @@ mlxsw_sp_mr_route4_create(struct mlxsw_sp_mr_table *mr_table,
 		}
 	}
 	mlxsw_sp_mr_route_ivif_link(mr_route, &mr_table->vifs[mfc->mfc_parent]);
-	if (err)
-		goto err;
 
 	mr_route->route_action = mlxsw_sp_mr_route_action(mr_route);
 	return mr_route;
-- 
2.14.1

^ permalink raw reply related

* Re: tc-ipt v0.2: Extension does not know id 1504083504
From: Sergey K. @ 2017-10-01 14:25 UTC (permalink / raw)
  To: netdev, bugfood-ml

> Funny, I just ran into this too and subscribed here to report it. The
> error occurs during parsing of any options to the jump target; if the
> target has no options, there is no error.
>
> The problem seems to be an outdated version of struct xtables_target in
> include/xtables.h. The version in iptables has an additional member
> "udata" that makes the offsets in the struct different for anything
> following.
>
> A quick fix for this particular problem is to copy include/xtables.h from:
> git://git.netfilter.org/iptables
> ...into include/ in the iproute2 source, then recompile after a 'make
> clean'.
>
> As for a comprehensive fix, I don't know--presumably other headers in
> include/ may be out of date, but I don't want to just blindly send a
> patch unless someone who knows the ramifications says it's ok. This
> seems like it would need maintainer oversight. If there's something I
> can do, though, let me know.
>
>-Corey

Hi Corey.

I did it on your recommendation, replaced xtables.h file from my
version of iptables 1.6.0, and replaced the file netfilter.h.

Now it's works, but new construction doesn't:

# tc filter add dev eth0 parent ffff: u32 match u32 0 0 action xt -j
SET --map-set WORLD_QoS dst
xt: unrecognized option '--map-set'
failed to find target (null)

bad action parsing
parse_action: bad value (6:xt)!
Illegal "action"

my ipset chain:
# ipset -L WORLD_QoS
Name: WORLD_QoS
Type: hash:ip
Revision: 4
Header: family inet hashsize 1024 maxelem 65536 skbinfo
Size in memory: 96
References: 1
Members:

------------------------------------------------

If I will try to execute:

# tc filter add dev eth0 parent ffff: u32 match u32 0 0 action xt -j SET

tc-ipt v0.2: You must specify either `--add-set' or `--del-set' or `--map-set'

it looks like it possible to use this construction.

Is it possible?

^ permalink raw reply

* [PATCH net 4/4] ip_gre: erspan device should keep dst
From: Xin Long @ 2017-10-01 14:00 UTC (permalink / raw)
  To: network dev; +Cc: davem, Dmitry Kozlov, William Tu
In-Reply-To: <cover.1506866059.git.lucien.xin@gmail.com>

The patch 'ip_gre: ipgre_tap device should keep dst' fixed
the issue ipgre_tap dev mtu couldn't be updated in tx path.

The same fix is needed for erspan as well.

Fixes: 84e54fe0a5ea ("gre: introduce native tunnel support for ERSPAN")
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
 net/ipv4/ip_gre.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index fad0bb1..467e44d 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -1254,6 +1254,7 @@ static int erspan_tunnel_init(struct net_device *dev)
 	dev->features		|= GRE_FEATURES;
 	dev->hw_features	|= GRE_FEATURES;
 	dev->priv_flags		|= IFF_LIVE_ADDR_CHANGE;
+	netif_keep_dst(dev);
 
 	return ip_tunnel_init(dev);
 }
-- 
2.1.0

^ permalink raw reply related

* [PATCH net 3/4] ip_gre: set tunnel hlen properly in erspan_tunnel_init
From: Xin Long @ 2017-10-01 14:00 UTC (permalink / raw)
  To: network dev; +Cc: davem, Dmitry Kozlov, William Tu
In-Reply-To: <cover.1506866059.git.lucien.xin@gmail.com>

According to __gre_tunnel_init, tunnel->hlen should be set as the
headers' length between inner packet and outer iphdr.

It would be used especially to calculate a proper mtu when updating
mtu in tnl_update_pmtu. Now without setting it, a bigger mtu value
than expected would be updated, which hurts performance a lot.

This patch is to fix it by setting tunnel->hlen with:
   tunnel->tun_hlen + tunnel->encap_hlen + sizeof(struct erspanhdr)

Fixes: 84e54fe0a5ea ("gre: introduce native tunnel support for ERSPAN")
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
 net/ipv4/ip_gre.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index 2a4ef9d..fad0bb1 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -1245,7 +1245,9 @@ static int erspan_tunnel_init(struct net_device *dev)
 
 	tunnel->tun_hlen = 8;
 	tunnel->parms.iph.protocol = IPPROTO_GRE;
-	t_hlen = tunnel->hlen + sizeof(struct iphdr) + sizeof(struct erspanhdr);
+	tunnel->hlen = tunnel->tun_hlen + tunnel->encap_hlen +
+		       sizeof(struct erspanhdr);
+	t_hlen = tunnel->hlen + sizeof(struct iphdr);
 
 	dev->needed_headroom = LL_MAX_HEADER + t_hlen + 4;
 	dev->mtu = ETH_DATA_LEN - t_hlen - 4;
-- 
2.1.0

^ permalink raw reply related

* [PATCH net 2/4] ip_gre: check packet length and mtu correctly in erspan_xmit
From: Xin Long @ 2017-10-01 14:00 UTC (permalink / raw)
  To: network dev; +Cc: davem, Dmitry Kozlov, William Tu
In-Reply-To: <cover.1506866059.git.lucien.xin@gmail.com>

As a ARPHRD_ETHER device, skb->len in erspan_xmit is the length
of the whole ether packet. So before checking if a packet size
exceeds the mtu, skb->len should subtract dev->hard_header_len.

Otherwise, all packets with max size according to mtu would be
trimmed to be truncated packet.

Fixes: 84e54fe0a5ea ("gre: introduce native tunnel support for ERSPAN")
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
 net/ipv4/ip_gre.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index b25b1e5..2a4ef9d 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -731,7 +731,7 @@ static netdev_tx_t erspan_xmit(struct sk_buff *skb,
 	if (skb_cow_head(skb, dev->needed_headroom))
 		goto free_skb;
 
-	if (skb->len > dev->mtu) {
+	if (skb->len - dev->hard_header_len > dev->mtu) {
 		pskb_trim(skb, dev->mtu);
 		truncate = true;
 	}
-- 
2.1.0

^ permalink raw reply related

* [PATCH net 1/4] ip_gre: get key from session_id correctly in erspan_rcv
From: Xin Long @ 2017-10-01 14:00 UTC (permalink / raw)
  To: network dev; +Cc: davem, Dmitry Kozlov, William Tu
In-Reply-To: <cover.1506866059.git.lucien.xin@gmail.com>

erspan only uses the first 10 bits of session_id as the key to look
up the tunnel. But in erspan_rcv, it missed 'session_id & ID_MASK'
when getting the key from session_id.

If any other flag is also set in session_id in a packet, it would
fail to find the tunnel due to incorrect key in erspan_rcv.

This patch is to add 'session_id & ID_MASK' there and also remove
the unnecessary variable session_id.

Fixes: 84e54fe0a5ea ("gre: introduce native tunnel support for ERSPAN")
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
 net/ipv4/ip_gre.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index 8b837f6..b25b1e5 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -259,7 +259,6 @@ static int erspan_rcv(struct sk_buff *skb, struct tnl_ptk_info *tpi,
 	struct ip_tunnel *tunnel;
 	struct erspanhdr *ershdr;
 	const struct iphdr *iph;
-	__be32 session_id;
 	__be32 index;
 	int len;
 
@@ -275,8 +274,7 @@ static int erspan_rcv(struct sk_buff *skb, struct tnl_ptk_info *tpi,
 	/* The original GRE header does not have key field,
 	 * Use ERSPAN 10-bit session ID as key.
 	 */
-	session_id = cpu_to_be32(ntohs(ershdr->session_id));
-	tpi->key = session_id;
+	tpi->key = cpu_to_be32(ntohs(ershdr->session_id) & ID_MASK);
 	index = ershdr->md.index;
 	tunnel = ip_tunnel_lookup(itn, skb->dev->ifindex,
 				  tpi->flags | TUNNEL_KEY,
-- 
2.1.0

^ permalink raw reply related

* [PATCH net 0/4] ip_gre: a bunch of fixes for erspan
From: Xin Long @ 2017-10-01 14:00 UTC (permalink / raw)
  To: network dev; +Cc: davem, Dmitry Kozlov, William Tu

This patchset is to fix some issues that could cause 0 or low
performance, and even unexpected truncated packets on erspan.

Xin Long (4):
  ip_gre: get key from session_id correctly in erspan_rcv
  ip_gre: check packet length and mtu correctly in erspan_xmit
  ip_gre: set tunnel hlen properly in erspan_tunnel_init
  ip_gre: erspan device should keep dst

 net/ipv4/ip_gre.c | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

-- 
2.1.0

^ permalink raw reply

* [PATCH 6/6] bcm63xx_enet: remove unneeded include
From: Jonas Gorski @ 2017-10-01 11:02 UTC (permalink / raw)
  To: netdev, linux-arm-kernel, linux-kernel
  Cc: David S. Miller, Florian Fainelli, bcm-kernel-feedback-list
In-Reply-To: <20171001110220.27668-1-jonas.gorski@gmail.com>

We don't use anyhing from that file, so drop it.

Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
---
 drivers/net/ethernet/broadcom/bcm63xx_enet.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/ethernet/broadcom/bcm63xx_enet.h b/drivers/net/ethernet/broadcom/bcm63xx_enet.h
index 0a1b7b2e55bd..dd6ae3077433 100644
--- a/drivers/net/ethernet/broadcom/bcm63xx_enet.h
+++ b/drivers/net/ethernet/broadcom/bcm63xx_enet.h
@@ -8,7 +8,6 @@
 #include <linux/platform_device.h>
 
 #include <bcm63xx_regs.h>
-#include <bcm63xx_irq.h>
 #include <bcm63xx_io.h>
 #include <bcm63xx_iudma.h>
 
-- 
2.13.2

^ permalink raw reply related

* [PATCH 5/6] bcm63xx_enet: drop unneeded NULL phy_clk check
From: Jonas Gorski @ 2017-10-01 11:02 UTC (permalink / raw)
  To: netdev, linux-arm-kernel, linux-kernel
  Cc: David S. Miller, Florian Fainelli, bcm-kernel-feedback-list
In-Reply-To: <20171001110220.27668-1-jonas.gorski@gmail.com>

clk_disable and clk_unprepare are NULL-safe, so need to duplicate the
NULL check of the functions.

Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
---
 drivers/net/ethernet/broadcom/bcm63xx_enet.c | 7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/bcm63xx_enet.c b/drivers/net/ethernet/broadcom/bcm63xx_enet.c
index 059ef4f1d137..f6bc13fe8a99 100644
--- a/drivers/net/ethernet/broadcom/bcm63xx_enet.c
+++ b/drivers/net/ethernet/broadcom/bcm63xx_enet.c
@@ -1903,8 +1903,7 @@ static int bcm_enet_probe(struct platform_device *pdev)
 out_uninit_hw:
 	/* turn off mdc clock */
 	enet_writel(priv, 0, ENET_MIISC_REG);
-	if (priv->phy_clk)
-		clk_disable_unprepare(priv->phy_clk);
+	clk_disable_unprepare(priv->phy_clk);
 
 out_disable_clk_mac:
 	clk_disable_unprepare(priv->mac_clk);
@@ -1943,9 +1942,7 @@ static int bcm_enet_remove(struct platform_device *pdev)
 	}
 
 	/* disable hw block clocks */
-	if (priv->phy_clk)
-		clk_disable_unprepare(priv->phy_clk);
-
+	clk_disable_unprepare(priv->phy_clk);
 	clk_disable_unprepare(priv->mac_clk);
 
 	free_netdev(dev);
-- 
2.13.2

^ permalink raw reply related

* [PATCH 4/6] bcm63xx_enet: use managed functions for clock/ioremap
From: Jonas Gorski @ 2017-10-01 11:02 UTC (permalink / raw)
  To: netdev, linux-arm-kernel, linux-kernel
  Cc: David S. Miller, Florian Fainelli, bcm-kernel-feedback-list
In-Reply-To: <20171001110220.27668-1-jonas.gorski@gmail.com>

Use managed functions where possible to reduce the amount of resource
handling on error and remove paths.

Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
---
 drivers/net/ethernet/broadcom/bcm63xx_enet.c | 54 +++++++---------------------
 1 file changed, 12 insertions(+), 42 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/bcm63xx_enet.c b/drivers/net/ethernet/broadcom/bcm63xx_enet.c
index 8caf6abab3a6..059ef4f1d137 100644
--- a/drivers/net/ethernet/broadcom/bcm63xx_enet.c
+++ b/drivers/net/ethernet/broadcom/bcm63xx_enet.c
@@ -1767,14 +1767,14 @@ static int bcm_enet_probe(struct platform_device *pdev)
 		clk_name = "enet1";
 	}
 
-	priv->mac_clk = clk_get(&pdev->dev, clk_name);
+	priv->mac_clk = devm_clk_get(&pdev->dev, clk_name);
 	if (IS_ERR(priv->mac_clk)) {
 		ret = PTR_ERR(priv->mac_clk);
 		goto out;
 	}
 	ret = clk_prepare_enable(priv->mac_clk);
 	if (ret)
-		goto out_put_clk_mac;
+		goto out;
 
 	/* initialize default and fetch platform data */
 	priv->rx_ring_size = BCMENET_DEF_RX_DESC;
@@ -1802,7 +1802,7 @@ static int bcm_enet_probe(struct platform_device *pdev)
 
 	if (priv->mac_id == 0 && priv->has_phy && !priv->use_external_mii) {
 		/* using internal PHY, enable clock */
-		priv->phy_clk = clk_get(&pdev->dev, "ephy");
+		priv->phy_clk = devm_clk_get(&pdev->dev, "ephy");
 		if (IS_ERR(priv->phy_clk)) {
 			ret = PTR_ERR(priv->phy_clk);
 			priv->phy_clk = NULL;
@@ -1810,7 +1810,7 @@ static int bcm_enet_probe(struct platform_device *pdev)
 		}
 		ret = clk_prepare_enable(priv->phy_clk);
 		if (ret)
-			goto out_put_clk_phy;
+			goto out_disable_clk_mac;
 	}
 
 	/* do minimal hardware init to be able to probe mii bus */
@@ -1906,14 +1906,8 @@ static int bcm_enet_probe(struct platform_device *pdev)
 	if (priv->phy_clk)
 		clk_disable_unprepare(priv->phy_clk);
 
-out_put_clk_phy:
-	if (priv->phy_clk)
-		clk_put(priv->phy_clk);
-
 out_disable_clk_mac:
 	clk_disable_unprepare(priv->mac_clk);
-out_put_clk_mac:
-	clk_put(priv->mac_clk);
 out:
 	free_netdev(dev);
 	return ret;
@@ -1949,12 +1943,10 @@ static int bcm_enet_remove(struct platform_device *pdev)
 	}
 
 	/* disable hw block clocks */
-	if (priv->phy_clk) {
+	if (priv->phy_clk)
 		clk_disable_unprepare(priv->phy_clk);
-		clk_put(priv->phy_clk);
-	}
+
 	clk_disable_unprepare(priv->mac_clk);
-	clk_put(priv->mac_clk);
 
 	free_netdev(dev);
 	return 0;
@@ -2734,26 +2726,20 @@ static int bcm_enetsw_probe(struct platform_device *pdev)
 	if (ret)
 		goto out;
 
-	if (!request_mem_region(res_mem->start, resource_size(res_mem),
-				"bcm63xx_enetsw")) {
-		ret = -EBUSY;
+	priv->base = devm_ioremap_resource(&pdev->dev, res_mem);
+	if (IS_ERR(priv->base)) {
+		ret = PTR_ERR(priv->base);
 		goto out;
 	}
 
-	priv->base = ioremap(res_mem->start, resource_size(res_mem));
-	if (priv->base == NULL) {
-		ret = -ENOMEM;
-		goto out_release_mem;
-	}
-
-	priv->mac_clk = clk_get(&pdev->dev, "enetsw");
+	priv->mac_clk = devm_clk_get(&pdev->dev, "enetsw");
 	if (IS_ERR(priv->mac_clk)) {
 		ret = PTR_ERR(priv->mac_clk);
-		goto out_unmap;
+		goto out;
 	}
 	ret = clk_prepare_enable(priv->mac_clk);
 	if (ret)
-		goto out_put_clk;
+		goto out;
 
 	priv->rx_chan = 0;
 	priv->tx_chan = 1;
@@ -2785,15 +2771,6 @@ static int bcm_enetsw_probe(struct platform_device *pdev)
 
 out_disable_clk:
 	clk_disable_unprepare(priv->mac_clk);
-
-out_put_clk:
-	clk_put(priv->mac_clk);
-
-out_unmap:
-	iounmap(priv->base);
-
-out_release_mem:
-	release_mem_region(res_mem->start, resource_size(res_mem));
 out:
 	free_netdev(dev);
 	return ret;
@@ -2805,20 +2782,13 @@ static int bcm_enetsw_remove(struct platform_device *pdev)
 {
 	struct bcm_enet_priv *priv;
 	struct net_device *dev;
-	struct resource *res;
 
 	/* stop netdevice */
 	dev = platform_get_drvdata(pdev);
 	priv = netdev_priv(dev);
 	unregister_netdev(dev);
 
-	/* release device resources */
-	iounmap(priv->base);
-	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-	release_mem_region(res->start, resource_size(res));
-
 	clk_disable_unprepare(priv->mac_clk);
-	clk_put(priv->mac_clk);
 
 	free_netdev(dev);
 	return 0;
-- 
2.13.2

^ permalink raw reply related

* [PATCH 3/6] bcm63xx_enet: do not rely on probe order
From: Jonas Gorski @ 2017-10-01 11:02 UTC (permalink / raw)
  To: netdev, linux-arm-kernel, linux-kernel
  Cc: David S. Miller, Florian Fainelli, bcm-kernel-feedback-list
In-Reply-To: <20171001110220.27668-1-jonas.gorski@gmail.com>

Do not rely on the shared device being probed before the enet(sw)
devices. This makes it easier to eventually move out the shared
device as a dma controller driver (what it should be).

Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
---
 drivers/net/ethernet/broadcom/bcm63xx_enet.c | 9 ++-------
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/bcm63xx_enet.c b/drivers/net/ethernet/broadcom/bcm63xx_enet.c
index a1e1e12e187a..8caf6abab3a6 100644
--- a/drivers/net/ethernet/broadcom/bcm63xx_enet.c
+++ b/drivers/net/ethernet/broadcom/bcm63xx_enet.c
@@ -1722,10 +1722,8 @@ static int bcm_enet_probe(struct platform_device *pdev)
 	const char *clk_name;
 	int i, ret;
 
-	/* stop if shared driver failed, assume driver->probe will be
-	 * called in the same order we register devices (correct ?) */
 	if (!bcm_enet_shared_base[0])
-		return -ENODEV;
+		return -EPROBE_DEFER;
 
 	res_irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
 	res_irq_rx = platform_get_resource(pdev, IORESOURCE_IRQ, 1);
@@ -2696,11 +2694,8 @@ static int bcm_enetsw_probe(struct platform_device *pdev)
 	struct resource *res_mem;
 	int ret, irq_rx, irq_tx;
 
-	/* stop if shared driver failed, assume driver->probe will be
-	 * called in the same order we register devices (correct ?)
-	 */
 	if (!bcm_enet_shared_base[0])
-		return -ENODEV;
+		return -EPROBE_DEFER;
 
 	res_mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	irq_rx = platform_get_irq(pdev, 0);
-- 
2.13.2

^ permalink raw reply related

* [PATCH 2/6] bcm63xx_enet: do not write to random DMA channel on BCM6345
From: Jonas Gorski @ 2017-10-01 11:02 UTC (permalink / raw)
  To: netdev, linux-arm-kernel, linux-kernel
  Cc: David S. Miller, Florian Fainelli, bcm-kernel-feedback-list
In-Reply-To: <20171001110220.27668-1-jonas.gorski@gmail.com>

The DMA controller regs actually point to DMA channel 0, so the write to
ENETDMA_CFG_REG will actually modify a random DMA channel.

Since DMA controller registers do not exist on BCM6345, guard the write
with the usual check for dma_has_sram.

Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
---
 drivers/net/ethernet/broadcom/bcm63xx_enet.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/broadcom/bcm63xx_enet.c b/drivers/net/ethernet/broadcom/bcm63xx_enet.c
index a45ec97b5b1e..a1e1e12e187a 100644
--- a/drivers/net/ethernet/broadcom/bcm63xx_enet.c
+++ b/drivers/net/ethernet/broadcom/bcm63xx_enet.c
@@ -1062,7 +1062,8 @@ static int bcm_enet_open(struct net_device *dev)
 	val = enet_readl(priv, ENET_CTL_REG);
 	val |= ENET_CTL_ENABLE_MASK;
 	enet_writel(priv, val, ENET_CTL_REG);
-	enet_dma_writel(priv, ENETDMA_CFG_EN_MASK, ENETDMA_CFG_REG);
+	if (priv->dma_has_sram)
+		enet_dma_writel(priv, ENETDMA_CFG_EN_MASK, ENETDMA_CFG_REG);
 	enet_dmac_writel(priv, priv->dma_chan_en_mask,
 			 ENETDMAC_CHANCFG, priv->rx_chan);
 
-- 
2.13.2

^ permalink raw reply related

* [PATCH 1/6] bcm63xx_enet: correct clock usage
From: Jonas Gorski @ 2017-10-01 11:02 UTC (permalink / raw)
  To: netdev, linux-arm-kernel, linux-kernel
  Cc: David S. Miller, Florian Fainelli, bcm-kernel-feedback-list
In-Reply-To: <20171001110220.27668-1-jonas.gorski@gmail.com>

Check the return code of prepare_enable and change one last instance of
enable only to prepare_enable. Also properly disable and release the
clock in error paths and on remove for enetsw.

Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
---
 drivers/net/ethernet/broadcom/bcm63xx_enet.c | 31 +++++++++++++++++++++-------
 1 file changed, 23 insertions(+), 8 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/bcm63xx_enet.c b/drivers/net/ethernet/broadcom/bcm63xx_enet.c
index c6221f04a748..a45ec97b5b1e 100644
--- a/drivers/net/ethernet/broadcom/bcm63xx_enet.c
+++ b/drivers/net/ethernet/broadcom/bcm63xx_enet.c
@@ -1773,7 +1773,9 @@ static int bcm_enet_probe(struct platform_device *pdev)
 		ret = PTR_ERR(priv->mac_clk);
 		goto out;
 	}
-	clk_prepare_enable(priv->mac_clk);
+	ret = clk_prepare_enable(priv->mac_clk);
+	if (ret)
+		goto out_put_clk_mac;
 
 	/* initialize default and fetch platform data */
 	priv->rx_ring_size = BCMENET_DEF_RX_DESC;
@@ -1805,9 +1807,11 @@ static int bcm_enet_probe(struct platform_device *pdev)
 		if (IS_ERR(priv->phy_clk)) {
 			ret = PTR_ERR(priv->phy_clk);
 			priv->phy_clk = NULL;
-			goto out_put_clk_mac;
+			goto out_disable_clk_mac;
 		}
-		clk_prepare_enable(priv->phy_clk);
+		ret = clk_prepare_enable(priv->phy_clk);
+		if (ret)
+			goto out_put_clk_phy;
 	}
 
 	/* do minimal hardware init to be able to probe mii bus */
@@ -1900,13 +1904,16 @@ static int bcm_enet_probe(struct platform_device *pdev)
 out_uninit_hw:
 	/* turn off mdc clock */
 	enet_writel(priv, 0, ENET_MIISC_REG);
-	if (priv->phy_clk) {
+	if (priv->phy_clk)
 		clk_disable_unprepare(priv->phy_clk);
+
+out_put_clk_phy:
+	if (priv->phy_clk)
 		clk_put(priv->phy_clk);
-	}
 
-out_put_clk_mac:
+out_disable_clk_mac:
 	clk_disable_unprepare(priv->mac_clk);
+out_put_clk_mac:
 	clk_put(priv->mac_clk);
 out:
 	free_netdev(dev);
@@ -2748,7 +2755,9 @@ static int bcm_enetsw_probe(struct platform_device *pdev)
 		ret = PTR_ERR(priv->mac_clk);
 		goto out_unmap;
 	}
-	clk_enable(priv->mac_clk);
+	ret = clk_prepare_enable(priv->mac_clk);
+	if (ret)
+		goto out_put_clk;
 
 	priv->rx_chan = 0;
 	priv->tx_chan = 1;
@@ -2769,7 +2778,7 @@ static int bcm_enetsw_probe(struct platform_device *pdev)
 
 	ret = register_netdev(dev);
 	if (ret)
-		goto out_put_clk;
+		goto out_disable_clk;
 
 	netif_carrier_off(dev);
 	platform_set_drvdata(pdev, dev);
@@ -2778,6 +2787,9 @@ static int bcm_enetsw_probe(struct platform_device *pdev)
 
 	return 0;
 
+out_disable_clk:
+	clk_disable_unprepare(priv->mac_clk);
+
 out_put_clk:
 	clk_put(priv->mac_clk);
 
@@ -2809,6 +2821,9 @@ static int bcm_enetsw_remove(struct platform_device *pdev)
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	release_mem_region(res->start, resource_size(res));
 
+	clk_disable_unprepare(priv->mac_clk);
+	clk_put(priv->mac_clk);
+
 	free_netdev(dev);
 	return 0;
 }
-- 
2.13.2

^ permalink raw reply related

* [PATCH 0/6] bcm63xx_enet: small fixes and cleanups
From: Jonas Gorski @ 2017-10-01 11:02 UTC (permalink / raw)
  To: netdev, linux-arm-kernel, linux-kernel
  Cc: David S. Miller, Florian Fainelli, bcm-kernel-feedback-list

This patch set fixes a few theoretical issues and cleans up the code a
bit. It also adds a bit more managed function usage to simplify clock
and iomem usage.

Based on net-next.

Jonas Gorski (6):
  bcm63xx_enet: correct clock usage
  bcm63xx_enet: do not write to random DMA channel on BCM6345
  bcm63xx_enet: do not rely on probe order
  bcm63xx_enet: use managed functions for clock/ioremap
  bcm63xx_enet: drop unneeded NULL phy_clk check
  bcm63xx_enet: remove unneeded include

 drivers/net/ethernet/broadcom/bcm63xx_enet.c | 78 ++++++++++------------------
 drivers/net/ethernet/broadcom/bcm63xx_enet.h |  1 -
 2 files changed, 28 insertions(+), 51 deletions(-)

-- 
2.13.2

^ permalink raw reply

* Re: [PATCH net-next] net: ipv4: remove fib_info arg to fib_check_nh
From: Sergei Shtylyov @ 2017-10-01 10:44 UTC (permalink / raw)
  To: David Ahern, netdev
In-Reply-To: <1506570119-17088-1-git-send-email-dsahern@gmail.com>

Hello!

On 9/28/2017 6:41 AM, David Ahern wrote:

> fib_check_nh does not use the fib_info arg; remove t.

    s/t/it/. :-)

> Signed-off-by: David Ahern <dsahern@gmail.com>
[...]

MBR, Sergei

^ permalink raw reply

* Re: [patch net-next 3/7] ipv4: ipmr: Don't forward packets already forwarded by hardware
From: Yotam Gigi @ 2017-10-01  8:51 UTC (permalink / raw)
  To: Florian Fainelli, Jiri Pirko, netdev
  Cc: davem, idosch, mlxsw, nikolay, andrew, dsa, edumazet, willemb,
	johannes.berg, dcaratti, pabeni, daniel, fw, gfree.wind
In-Reply-To: <bb37f353-8f15-f570-a35e-ed76c56f1180@gmail.com>

On 09/28/2017 08:56 PM, Florian Fainelli wrote:
> On 09/28/2017 10:34 AM, Jiri Pirko wrote:
>> From: Yotam Gigi <yotamg@mellanox.com>
>>
>> Change the ipmr module to not forward packets if:
>>  - The packet is marked with the offload_mr_fwd_mark, and
>>  - Both input interface and output interface share the same parent ID.
>>
>> This way, a packet can go through partial multicast forwarding in the
>> hardware, where it will be forwarded only to the devices that share the
>> same parent ID (AKA, reside inside the same hardware). The kernel will
>> forward the packet to all other interfaces.
>>
>> To do this, add the ipmr_offload_forward helper, which per skb, ingress VIF
>> and egress VIF, returns whether the forwarding was offloaded to hardware.
>> The ipmr_queue_xmit frees the skb and does not forward it if the result is
>> a true value.
>>
>> All the forwarding path code compiles out when the CONFIG_NET_SWITCHDEV is
>> not set.
>>
>> Signed-off-by: Yotam Gigi <yotamg@mellanox.com>
>> Reviewed-by: Ido Schimmel <idosch@mellanox.com>
>> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
>> ---
>>  net/ipv4/ipmr.c | 37 ++++++++++++++++++++++++++++++++-----
>>  1 file changed, 32 insertions(+), 5 deletions(-)
>>
>> diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
>> index 4566c54..deba569 100644
>> --- a/net/ipv4/ipmr.c
>> +++ b/net/ipv4/ipmr.c
>> @@ -1857,10 +1857,33 @@ static inline int ipmr_forward_finish(struct net *net, struct sock *sk,
>>  	return dst_output(net, sk, skb);
>>  }
>>  
>> +#ifdef CONFIG_NET_SWITCHDEV
>> +static bool ipmr_forward_offloaded(struct sk_buff *skb, struct mr_table *mrt,
>> +				   int in_vifi, int out_vifi)
>> +{
>> +	struct vif_device *out_vif = &mrt->vif_table[out_vifi];
>> +	struct vif_device *in_vif = &mrt->vif_table[in_vifi];
> Nit: in_vifi and out_vifi may be better named as in_vif_idx and
> out_vif_idx, oh well you are just replicating the existing naming
> conventions used down below, never mind then.


Yes, unfortunately, the acronym "vifi" is pretty common in the file. I would
also prefer something like vif_index, but vifi would better match the current
convention in the code.

^ permalink raw reply

* Re: [PATCH RFC 3/5] Add KSZ8795 switch driver
From: Pavel Machek @ 2017-10-01  7:21 UTC (permalink / raw)
  To: Tristram.Ha
  Cc: andrew, muvarov, nathan.leigh.conrad, vivien.didelot, f.fainelli,
	netdev, linux-kernel, Woojung.Huh
In-Reply-To: <93AF473E2DA327428DE3D46B72B1E9FD4112CBC8@CHN-SV-EXMX02.mchp-main.com>

[-- Attachment #1: Type: text/plain, Size: 1251 bytes --]

On Fri 2017-09-29 18:45:19, Tristram.Ha@microchip.com wrote:
> > > > > > Similar code will be needed by other drivers, right?
> > > > >
> > > > > Although KSZ8795 and KSZ8895 may use the same code, the other
> > > > > chips will have different code.
> > > >
> > > > Ok, please make sure code is shared between these two.
> > >
> > > The exact function probably cannot be shared between KSZ8795
> > > and KSZ8895 drivers because although the register constants look
> > > the same but their exact locations are different in the 2 chips.
> > 
> > Put the code into header as static inline and include it from both
> > places?
> 
> Although KSZ8795 and KSZ8895 share the same code when simulating
> the PHY register access, even though the exact registers are not the
> same, this code needs a little modification for another chip.  It also looks
> too large to put in a header.

I believe putting it into a header is prefferable to having two (or
three) copies of the code. If it needs small changes, you can
introduce if () ..., gcc can probably optimize it out.

Thanks,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

^ permalink raw reply

* Re: [patch net-next 2/7] ipv4: ipmr: Add the parent ID field to VIF struct
From: Yotam Gigi @ 2017-10-01  6:33 UTC (permalink / raw)
  To: Nikolay Aleksandrov, Jiri Pirko, netdev
  Cc: davem, idosch, mlxsw, andrew, dsa, edumazet, willemb,
	johannes.berg, dcaratti, pabeni, daniel, f.fainelli, fw,
	gfree.wind
In-Reply-To: <29b9104c-6ada-0c9a-ce84-df104fa0afba@cumulusnetworks.com>

On 09/29/2017 12:50 PM, Nikolay Aleksandrov wrote:
> On 28/09/17 20:34, Jiri Pirko wrote:
>> From: Yotam Gigi <yotamg@mellanox.com>
>>
>> In order to allow the ipmr module to do partial multicast forwarding
>> according to the device parent ID, add the device parent ID field to the
>> VIF struct. This way, the forwarding path can use the parent ID field
>> without invoking switchdev calls, which requires the RTNL lock.
>>
>> When a new VIF is added, set the device parent ID field in it by invoking
>> the switchdev_port_attr_get call.
>>
>> Signed-off-by: Yotam Gigi <yotamg@mellanox.com>
>> Reviewed-by: Ido Schimmel <idosch@mellanox.com>
>> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
>> ---
>>  include/linux/mroute.h | 2 ++
>>  net/ipv4/ipmr.c        | 9 +++++++++
>>  2 files changed, 11 insertions(+)
>>
>> diff --git a/include/linux/mroute.h b/include/linux/mroute.h
>> index b072a84..a46577f 100644
>> --- a/include/linux/mroute.h
>> +++ b/include/linux/mroute.h
>> @@ -57,6 +57,8 @@ static inline bool ipmr_rule_default(const struct fib_rule *rule)
>>  
>>  struct vif_device {
>>  	struct net_device 	*dev;			/* Device we are using */
>> +	struct netdev_phys_item_id dev_parent_id;	/* Device parent ID    */
>> +	bool		dev_parent_id_valid;
>>  	unsigned long	bytes_in,bytes_out;
>>  	unsigned long	pkt_in,pkt_out;		/* Statistics 			*/
>>  	unsigned long	rate_limit;		/* Traffic shaping (NI) 	*/
>> diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
>> index 292a8e8..4566c54 100644
>> --- a/net/ipv4/ipmr.c
>> +++ b/net/ipv4/ipmr.c
>> @@ -67,6 +67,7 @@
>>  #include <net/fib_rules.h>
>>  #include <linux/netconf.h>
>>  #include <net/nexthop.h>
>> +#include <net/switchdev.h>
>>  
>>  struct ipmr_rule {
>>  	struct fib_rule		common;
>> @@ -868,6 +869,9 @@ static int vif_add(struct net *net, struct mr_table *mrt,
>>  		   struct vifctl *vifc, int mrtsock)
>>  {
>>  	int vifi = vifc->vifc_vifi;
>> +	struct switchdev_attr attr = {
>> +		.id = SWITCHDEV_ATTR_ID_PORT_PARENT_ID,
>> +	};
>>  	struct vif_device *v = &mrt->vif_table[vifi];
>>  	struct net_device *dev;
>>  	struct in_device *in_dev;
>> @@ -942,6 +946,11 @@ static int vif_add(struct net *net, struct mr_table *mrt,
>>  
>>  	/* Fill in the VIF structures */
>>  
>> +	attr.orig_dev = dev;
>> +	if (!switchdev_port_attr_get(dev, &attr)) {
>> +		v->dev_parent_id_valid = true;
>> +		memcpy(v->dev_parent_id.id, attr.u.ppid.id, attr.u.ppid.id_len);
>> +	}
>>  	v->rate_limit = vifc->vifc_rate_limit;
>>  	v->local = vifc->vifc_lcl_addr.s_addr;
>>  	v->remote = vifc->vifc_rmt_addr.s_addr;
>>
> One more thing - what happens on vif delete, then add with the same vif index of another
> device that doesn't have a parent id ? I think the vif will be stuck with its parent_id
> when it gets set.
>

Right. I will set the len to 0 if the device has no parent.

Thanks!

^ permalink raw reply

* Re: [patch net-next 2/7] ipv4: ipmr: Add the parent ID field to VIF struct
From: Yotam Gigi @ 2017-10-01  6:22 UTC (permalink / raw)
  To: Nikolay Aleksandrov, Jiri Pirko, netdev
  Cc: davem, idosch, mlxsw, andrew, dsa, edumazet, willemb,
	johannes.berg, dcaratti, pabeni, daniel, f.fainelli, fw,
	gfree.wind
In-Reply-To: <11d1be00-0bd4-3bcc-d63b-9419d5399602@cumulusnetworks.com>

On 09/29/2017 12:45 PM, Nikolay Aleksandrov wrote:
> On 29/09/17 12:29, Nikolay Aleksandrov wrote:
>> On 28/09/17 20:34, Jiri Pirko wrote:
>>> From: Yotam Gigi <yotamg@mellanox.com>
>>>
>>> In order to allow the ipmr module to do partial multicast forwarding
>>> according to the device parent ID, add the device parent ID field to the
>>> VIF struct. This way, the forwarding path can use the parent ID field
>>> without invoking switchdev calls, which requires the RTNL lock.
>>>
>>> When a new VIF is added, set the device parent ID field in it by invoking
>>> the switchdev_port_attr_get call.
>>>
>>> Signed-off-by: Yotam Gigi <yotamg@mellanox.com>
>>> Reviewed-by: Ido Schimmel <idosch@mellanox.com>
>>> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
>>> ---
>>>  include/linux/mroute.h | 2 ++
>>>  net/ipv4/ipmr.c        | 9 +++++++++
>>>  2 files changed, 11 insertions(+)
>>>
>>> diff --git a/include/linux/mroute.h b/include/linux/mroute.h
>>> index b072a84..a46577f 100644
>>> --- a/include/linux/mroute.h
>>> +++ b/include/linux/mroute.h
>>> @@ -57,6 +57,8 @@ static inline bool ipmr_rule_default(const struct fib_rule *rule)
>>>  
>>>  struct vif_device {
>>>  	struct net_device 	*dev;			/* Device we are using */
>>> +	struct netdev_phys_item_id dev_parent_id;	/* Device parent ID    */
>>> +	bool		dev_parent_id_valid;
>>>  	unsigned long	bytes_in,bytes_out;
>>>  	unsigned long	pkt_in,pkt_out;		/* Statistics 			*/
>>>  	unsigned long	rate_limit;		/* Traffic shaping (NI) 	*/
>>> diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
>>> index 292a8e8..4566c54 100644
>>> --- a/net/ipv4/ipmr.c
>>> +++ b/net/ipv4/ipmr.c
>>> @@ -67,6 +67,7 @@
>>>  #include <net/fib_rules.h>
>>>  #include <linux/netconf.h>
>>>  #include <net/nexthop.h>
>>> +#include <net/switchdev.h>
>>>  
>>>  struct ipmr_rule {
>>>  	struct fib_rule		common;
>>> @@ -868,6 +869,9 @@ static int vif_add(struct net *net, struct mr_table *mrt,
>>>  		   struct vifctl *vifc, int mrtsock)
>>>  {
>>>  	int vifi = vifc->vifc_vifi;
>>> +	struct switchdev_attr attr = {
>>> +		.id = SWITCHDEV_ATTR_ID_PORT_PARENT_ID,
>>> +	};
>>>  	struct vif_device *v = &mrt->vif_table[vifi];
>>>  	struct net_device *dev;
>>>  	struct in_device *in_dev;
>>> @@ -942,6 +946,11 @@ static int vif_add(struct net *net, struct mr_table *mrt,
>>>  
>>>  	/* Fill in the VIF structures */
>>>  
>>> +	attr.orig_dev = dev;
>>> +	if (!switchdev_port_attr_get(dev, &attr)) {
>>> +		v->dev_parent_id_valid = true;
>>> +		memcpy(v->dev_parent_id.id, attr.u.ppid.id, attr.u.ppid.id_len);
>> Hmm, shouldn't you set dev_parent_id.id_len too ? It would seem netdev_phys_item_id_same()
>> uses it in the comparison and without the len it would always look like they're the same
>> because memcmp will simply return 0 with count = 0.
> Also maybe we can use the non-zero id_len as a signal that it was set and drop the dev_parent_id_valid
> field altogether, it would seem there's no valid reason to have id_len == 0 and yet expect a valid
> parent_id.


Yes, I agree to both. I will remove the parent_id_valid field and use the len to
indicate whether it is valid.

Thanks for spotting the bug - since we have only been testing it with a pimreg
device, the problem was not found in our tests. Multi-ASIC setups are a bit
hard to find these days :)


>>> +	}
>>>  	v->rate_limit = vifc->vifc_rate_limit;
>>>  	v->local = vifc->vifc_lcl_addr.s_addr;
>>>  	v->remote = vifc->vifc_rmt_addr.s_addr;
>>>

^ permalink raw reply

* Re: [PATCH v5 2/2] ip_tunnel: add mpls over gre encapsulation
From: kbuild test robot @ 2017-10-01  5:27 UTC (permalink / raw)
  To: Amine Kherbouche
  Cc: kbuild-all, netdev, davem, xeb, roopa, amine.kherbouche, equinox
In-Reply-To: <f0e68e51351239614cea89ae612c09a1ed8f5928.1506616215.git.amine.kherbouche@6wind.com>

[-- Attachment #1: Type: text/plain, Size: 745 bytes --]

Hi Amine,

[auto build test ERROR on net/master]
[also build test ERROR on v4.14-rc2 next-20170929]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]

url:    https://github.com/0day-ci/linux/commits/Amine-Kherbouche/mpls-export-mpls_forward/20171001-074929
config: x86_64-rhel (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
        # save the attached .config to linux build tree
        make ARCH=x86_64 

All errors (new ones prefixed by >>):

>> ERROR: "mpls_forward" [net/ipv4/gre.ko] undefined!

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 40011 bytes --]

^ permalink raw reply

* Re: [PATCH net-next 0/3] support changing steering policies in tuntap
From: Michael S. Tsirkin @ 2017-10-01  3:28 UTC (permalink / raw)
  To: Willem de Bruijn; +Cc: Jason Wang, Network Development, LKML
In-Reply-To: <CAF=yD-KuDZK0-YUfYde=dk_6M6fgj_opuiK2VTfCKDM_=MqDcw@mail.gmail.com>

On Thu, Sep 28, 2017 at 12:09:05PM -0400, Willem de Bruijn wrote:
> Programming from the guest is
> indeed different. I don't fully understand that use case.

Generally programming host BPF from guest is a clear win - think DOS
protection. Guest runs logic to detect dos attacks, then passes the
program to host.  Afterwards, host does not need to enter guest if
there's a DOS attack. Saves a ton of cycles.

The difficulty is making it work well, e.g. how do we handle maps?

-- 
MST

^ permalink raw reply

* Re: [kbuild-all] [PATCH net-next] vhost_net: do not stall on zerocopy depletion
From: Fengguang Wu @ 2017-10-01  3:26 UTC (permalink / raw)
  To: Michael S. Tsirkin
  Cc: Willem de Bruijn, netdev, jasowang, Willem de Bruijn, den,
	virtualization, kbuild-all, davem
In-Reply-To: <20171001062018-mutt-send-email-mst@kernel.org>

On Sun, Oct 01, 2017 at 06:20:49AM +0300, Michael S. Tsirkin wrote:
>On Sun, Oct 01, 2017 at 08:09:30AM +0800, kbuild test robot wrote:
>> Hi Willem,
>>
>> [auto build test WARNING on net-next/master]
>>
>> url:    https://github.com/0day-ci/linux/commits/Willem-de-Bruijn/vhost_net-do-not-stall-on-zerocopy-depletion/20171001-054709
>> reproduce:
>>         # apt-get install sparse
>>         make ARCH=x86_64 allmodconfig
>>         make C=1 CF=-D__CHECK_ENDIAN__
>
>BTW __CHECK_ENDIAN__ is the default now, I think you can drop it from
>your scripts.

Good tip, thank you! However since we're testing old kernels, too,
we'll need to keep it for probably 1-3 more years.

Thanks,
Fengguang

>>
>> sparse warnings: (new ones prefixed by >>)
>>
>>
>> vim +440 drivers/vhost/net.c
>>
>>    433	
>>    434	static bool vhost_exceeds_maxpend(struct vhost_net *net)
>>    435	{
>>    436		struct vhost_net_virtqueue *nvq = &net->vqs[VHOST_NET_VQ_TX];
>>    437		struct vhost_virtqueue *vq = &nvq->vq;
>>    438	
>>    439		return (nvq->upend_idx + UIO_MAXIOV - nvq->done_idx) % UIO_MAXIOV >
>>  > 440		       min(VHOST_MAX_PEND, vq->num >> 2);
>>    441	}
>>    442	
>>
>> ---
>> 0-DAY kernel test infrastructure                Open Source Technology Center
>> https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
>_______________________________________________
>kbuild-all mailing list
>kbuild-all@lists.01.org
>https://lists.01.org/mailman/listinfo/kbuild-all

^ permalink raw reply

* [PATCH v2 iproute2] tc: fix ipv6 filter selector attribute for some prefix lengths
From: Yulia Kartseva @ 2017-10-01  3:18 UTC (permalink / raw)
  To: stephen; +Cc: netdev, yulia.kartseva, hex
In-Reply-To: <20170927092634.0870468d@shemminger-XPS-13-9360>

Wrong TCA_U32_SEL attribute packing if prefixLen AND 0x1f equals 0x1f.
These are  /31, /63, /95 and /127 prefix lengths.

Example:
ip6 dst face:b00f::/31
filter parent b: protocol ipv6 pref 2307 u32
filter parent b: protocol ipv6 pref 2307 u32 fh 800: ht divisor 1
filter parent b: protocol ipv6 pref 2307 u32 fh 800::800 order 2048
key ht 800 bkt 0
  match faceb00f/ffffffff at 24

v2: previous patch was made with a wrong repo

Signed-off-by: Yulia Kartseva <hex@fb.com>
---
 tc/f_u32.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/tc/f_u32.c b/tc/f_u32.c
index 5815be9..14b9588 100644
--- a/tc/f_u32.c
+++ b/tc/f_u32.c
@@ -385,8 +385,7 @@ static int parse_ip6_addr(int *argc_p, char ***argv_p,
 
 	plen = addr.bitlen;
 	for (i = 0; i < plen; i += 32) {
-		/* if (((i + 31) & ~0x1F) <= plen) { */
-		if (i + 31 <= plen) {
+		if (i + 31 < plen) {
 			res = pack_key(sel, addr.data[i / 32],
 				       0xFFFFFFFF, off + 4 * (i / 32), offmask);
 			if (res < 0)
-- 
2.9.5

^ permalink raw reply related

* Re: [PATCH net-next] vhost_net: do not stall on zerocopy depletion
From: Michael S. Tsirkin @ 2017-10-01  3:20 UTC (permalink / raw)
  To: kbuild test robot
  Cc: Willem de Bruijn, kbuild-all, netdev, davem, jasowang, den,
	virtualization, Willem de Bruijn
In-Reply-To: <201710010753.KeY9a5xF%fengguang.wu@intel.com>

On Sun, Oct 01, 2017 at 08:09:30AM +0800, kbuild test robot wrote:
> Hi Willem,
> 
> [auto build test WARNING on net-next/master]
> 
> url:    https://github.com/0day-ci/linux/commits/Willem-de-Bruijn/vhost_net-do-not-stall-on-zerocopy-depletion/20171001-054709
> reproduce:
>         # apt-get install sparse
>         make ARCH=x86_64 allmodconfig
>         make C=1 CF=-D__CHECK_ENDIAN__

BTW __CHECK_ENDIAN__ is the default now, I think you can drop it from
your scripts.

> 
> sparse warnings: (new ones prefixed by >>)
> 
> 
> vim +440 drivers/vhost/net.c
> 
>    433	
>    434	static bool vhost_exceeds_maxpend(struct vhost_net *net)
>    435	{
>    436		struct vhost_net_virtqueue *nvq = &net->vqs[VHOST_NET_VQ_TX];
>    437		struct vhost_virtqueue *vq = &nvq->vq;
>    438	
>    439		return (nvq->upend_idx + UIO_MAXIOV - nvq->done_idx) % UIO_MAXIOV >
>  > 440		       min(VHOST_MAX_PEND, vq->num >> 2);
>    441	}
>    442	
> 
> ---
> 0-DAY kernel test infrastructure                Open Source Technology Center
> https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox