[PATCH v2] net: stmmac: Fix wrong message in stmmac_probe_config_dt

[Heiner Kallweit]

Most likely a copy & paste error in referenced commit.
Restore the debug message to what it was before.

Fixes: f573c0b9c4e0 ("stmmac: move stmmac_clk, pclk, clk_ptp_ref and stmmac_rst 
to platform structure")
Signed-off-by: Heiner Kallweit 
---
v2:
- Don't remove the wrong comment but replace it with what
  was there before the referenced commit.
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 460f94f5..4963ccdb 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -371,7 +371,7 @@ stmmac_probe_config_dt(struct platform_device *pdev, const 
char **mac)
} else {
clk_prepare_enable(plat->clk_ptp_ref);
plat->clk_ptp_rate = clk_get_rate(plat->clk_ptp_ref);
-   dev_info(>dev, "No reset control found\n");
+   dev_dbg(>dev, "PTP rate %d\n", plat->clk_ptp_rate);
}
 
plat->stmmac_rst = devm_reset_control_get(>dev,
-- 
2.11.0

Re: [PATCH] net: stmmac: Remove wrong message in stmmac_probe_config_dt

[Heiner Kallweit]

Am 02.02.2017 um 03:20 schrieb Phil Reid:
> On 2/02/2017 05:05, Heiner Kallweit wrote:
>> I can only imagine that this message ended up there by a copy & paste
>> mistake. The same message appears correctly a few lines later, but
>> here it doesn't make sense.
>>
>> Signed-off-by: Heiner Kallweit 
>> ---
>>  drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 1 -
>>  1 file changed, 1 deletion(-)
>>
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c 
>> b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
>> index 460f94f5..5edf23dc 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
>> @@ -371,7 +371,6 @@ stmmac_probe_config_dt(struct platform_device *pdev, 
>> const char **mac)
>>  } else {
>>  clk_prepare_enable(plat->clk_ptp_ref);
>>  plat->clk_ptp_rate = clk_get_rate(plat->clk_ptp_ref);
>> -dev_info(>dev, "No reset control found\n");
>>  }
>>
>>  plat->stmmac_rst = devm_reset_control_get(>dev,
>>
> 
> It was originally:
> netdev_dbg(priv->dev, "PTP rate %d\n", priv->clk_ptp_rate);
> Before it got moved in:
> commit f573c0b9c4e02691cf87736bd0824fd37ec02e65
> stmmac: move stmmac_clk, pclk, clk_ptp_ref and stmmac_rst to platform 
> structure
> 
Thanks for the hint, I'll send a v2 to restore the original message.

[PATCH net-next] cxgb4: Fix uld_send() for ctrl pkts

[Ganesh Goudar]

From: Arjun V 

Without any uld being loaded, uld_txq_info[] will be NULL. uld_send()
is also used for sending control work requests(for eg: setting filter)
that dont require any ulds to be loaded. Hence move uld_txq_info[]
assignment after ctrl_xmit().

Also added a NULL check for uld_txq_info[].

Fixes: 94cdb8bb993a (cxgb4: Add support for dynamic allocation
   of resources for ULD).
Signed-off-by: Arjun V 
Signed-off-by: Casey Leedom 
Signed-off-by: Ganesh Goudar 
---
 drivers/net/ethernet/chelsio/cxgb4/sge.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/chelsio/cxgb4/sge.c 
b/drivers/net/ethernet/chelsio/cxgb4/sge.c
index 0fe04b4..09653ae 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/sge.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/sge.c
@@ -1774,15 +1774,20 @@ static inline int uld_send(struct adapter *adap, struct 
sk_buff *skb,
struct sge_uld_txq *txq;
unsigned int idx = skb_txq(skb);
 
-   txq_info = adap->sge.uld_txq_info[tx_uld_type];
-   txq = _info->uldtxq[idx];
-
if (unlikely(is_ctrl_pkt(skb))) {
/* Single ctrl queue is a requirement for LE workaround path */
if (adap->tids.nsftids)
idx = 0;
return ctrl_xmit(>sge.ctrlq[idx], skb);
}
+
+   txq_info = adap->sge.uld_txq_info[tx_uld_type];
+   if (unlikely(!txq_info)) {
+   WARN_ON(true);
+   return NET_XMIT_DROP;
+   }
+
+   txq = _info->uldtxq[idx];
return ofld_xmit(txq, skb);
 }
 
-- 
2.1.0

Re: [PATCH net-next v2 0/5] bridge: per vlan dst_metadata support

[Stephen Hemminger]

On Wed, 01 Feb 2017 21:58:25 -0800
Roopa Prabhu  wrote:

> On 2/1/17, 5:23 PM, Alexei Starovoitov wrote:
> > On Tue, Jan 31, 2017 at 10:59:50PM -0800, Roopa Prabhu wrote:
> >  
> 
> [snip]
> 
> >> Solution in this patch series:
> >> The Goal is to use a single vxlan device to carry all vnis similar
> >> to the vxlan collect metadata mode but additionally allowing the bridge
> >> and vxlan driver to carry all the forwarding information and also learn.
> >> This implementation uses the existing dst_metadata infrastructure to map
> >> vlan to a tunnel id.  
> > ovs and/or bpf can do the same already, but sounds like the main reason is
> > to keep it integrated with bridge fdb to leverage your offload of bridge
> > fdb into hw asic, right?  
> 
> correct. We already use the bridge driver for vlan filtering and offloading. 
> Having vlan to tunnel map
> elsewhere is not feasible. It is also more than the hw offload asic case, we 
> have routing protocols like bgp looking at bridge driver
> l2 forwarding database for ethernet vpns 
> (https://tools.ietf.org/html/draft-ietf-bess-evpn-overlay-07)
> and they need a single place to look at bridge fdb table, vxlan fdb table, 
> vlan and tunnel info. Also, Bgp might not be the only
> protocol needing this info...we support other controllers too. Hence this 
> info cannot be in a bpf or
> live outside the bridge driver.
> 
> We today have the vlan info, bridge fdb table, vxlan remote dst fdb table. 
> the missing peice is the vlan to vxlan-id mapping
> which this series provides (Well, to be correct, this series helps with 
> scaling this mapping.
> Today we use a vxlan netdev per vlan which does not scale well). And this is 
> a very common configuration in
> data center switches that provide vxlan bridging gateway function.
> [Google for 'vlan to vxlan mapping' should give a couple hits. I did not want 
> to paste a link
> to any specific vendor guide here...but found a generic blog --> 
> http://www.definethecloud.net/vxlan-deep-dive/]
> 
> > If so, I guess, the extra complexity can be justified.
> > The question is how do you program hw ? Is there really 1 to 1 mapping
> > in the asics too? Or is it more flexible ?  
> yes, it is 1-1 mapping in asics too (might be variations on different chips 
> but
> this kind of function is supported by most asics).
> 
> > I think most swith asics can do other tunnels too,
> > so can this vlan->vxlan 1 to 1 be generalized to cover different
> > types of tunnels that can be configured on the switch?  
> 
> 
> yes, it can be. Hence i have kept the tunnel info netlink attribute generic. 
> similar to how LWT provides
> various encaps at the L3 routing layer, this can provide such function at the 
> L2 bridge layer. But, to keep it relatively lite I use the
> already existing dst_metadata infra to bridge vlan to vxlan (Which is already 
> done in the case of vxlan collect metadata mode.
> I simply extend it to cover the bridge case).
> 
> thanks,

I wonder if this is a case for a new driver (with same subset of bridge API). 
You probably
don't want all the baggage of STP, netfilter, VLAN filtering, etc when doing 
VXLAN VNI bridging.

Re: [PATCH v2 3/4] phy: Add USB3 PHY support for Broadcom NSP SoC

[Rafał Miłecki]

[Resending with fixed/complete Cc-s]

On Tue, 17 Jan 2017 11:14:29 -0500, Yendapally Reddy Dhananjaya Reddy 
 wrote:> This patch adds support for Broadcom 
NSP USB3 PHY
>
> Signed-off-by: Yendapally Reddy Dhananjaya Reddy 


Seriously?! I really dislike what you did there.

NACK.

You are aware this block is common for both: Northstar and Northstar Plus and
we already have phy-bcm-ns-usb3.c! In fact Jon told me to rewrite my initial
driver to make is possible to reuse it on NSP and I did that!

This is old comment from Jon:

In 30 March 2016 at 23:31, Jon Mason  wrote:
> On Mon, Mar 28, 2016 at 9:46 PM, Florian Fainelli 
> wrote:
>>
>> CC: bcm-kernel-feedback-list, Jon
>
>
> This is a common IP block with NSP.  I believe with some minor changes it
> can support both.  Please allow me 1-2 days to look at these in more detail
> and see if I can get these patches working on NSP.

Please start using existing code instead of inventing everything from the
scratch internally at Broadcom. You did the same thing with (Q)SPI driver.


This driver duplicates phy-bcm-ns-usb3.c and should have not been accepted. I
strongly suggest *reverting* it and adjusting existing driver if needed.

Re: [PATCH net-next v2 0/5] bridge: per vlan dst_metadata support

[Roopa Prabhu]

On 2/1/17, 5:23 PM, Alexei Starovoitov wrote:
> On Tue, Jan 31, 2017 at 10:59:50PM -0800, Roopa Prabhu wrote:
>

[snip]

>> Solution in this patch series:
>> The Goal is to use a single vxlan device to carry all vnis similar
>> to the vxlan collect metadata mode but additionally allowing the bridge
>> and vxlan driver to carry all the forwarding information and also learn.
>> This implementation uses the existing dst_metadata infrastructure to map
>> vlan to a tunnel id.
> ovs and/or bpf can do the same already, but sounds like the main reason is
> to keep it integrated with bridge fdb to leverage your offload of bridge
> fdb into hw asic, right?

correct. We already use the bridge driver for vlan filtering and offloading. 
Having vlan to tunnel map
elsewhere is not feasible. It is also more than the hw offload asic case, we 
have routing protocols like bgp looking at bridge driver
l2 forwarding database for ethernet vpns 
(https://tools.ietf.org/html/draft-ietf-bess-evpn-overlay-07)
and they need a single place to look at bridge fdb table, vxlan fdb table, vlan 
and tunnel info. Also, Bgp might not be the only
protocol needing this info...we support other controllers too. Hence this info 
cannot be in a bpf or
live outside the bridge driver.

We today have the vlan info, bridge fdb table, vxlan remote dst fdb table. the 
missing peice is the vlan to vxlan-id mapping
which this series provides (Well, to be correct, this series helps with scaling 
this mapping.
Today we use a vxlan netdev per vlan which does not scale well). And this is a 
very common configuration in
data center switches that provide vxlan bridging gateway function.
[Google for 'vlan to vxlan mapping' should give a couple hits. I did not want 
to paste a link
to any specific vendor guide here...but found a generic blog --> 
http://www.definethecloud.net/vxlan-deep-dive/]

> If so, I guess, the extra complexity can be justified.
> The question is how do you program hw ? Is there really 1 to 1 mapping
> in the asics too? Or is it more flexible ?
yes, it is 1-1 mapping in asics too (might be variations on different chips but
this kind of function is supported by most asics).

> I think most swith asics can do other tunnels too,
> so can this vlan->vxlan 1 to 1 be generalized to cover different
> types of tunnels that can be configured on the switch?


yes, it can be. Hence i have kept the tunnel info netlink attribute generic. 
similar to how LWT provides
various encaps at the L3 routing layer, this can provide such function at the 
L2 bridge layer. But, to keep it relatively lite I use the
already existing dst_metadata infra to bridge vlan to vxlan (Which is already 
done in the case of vxlan collect metadata mode.
I simply extend it to cover the bridge case).

thanks,

Re: [PATCH net-next v2 0/5] bridge: per vlan dst_metadata support

[Roopa Prabhu]

On 2/1/17, 8:04 PM, Stephen Hemminger wrote:
> On Wed, 01 Feb 2017 20:02:35 -0800
> Roopa Prabhu  wrote:
>
>> On 2/1/17, 5:59 PM, David Ahern wrote:
>>> On 2/1/17 6:23 PM, Alexei Starovoitov wrote:  
 On Tue, Jan 31, 2017 at 10:59:50PM -0800, Roopa Prabhu wrote:  
> 
> This provides the required vxlan bridging function but poses a
> scalability problem with using a separate vxlan netdev for each vni.  
 if I remember correctly this issue was the main reason David Ahern
 put netdev on diet. Sounds like no more fun at netconf ;)
  
>>> oh, it still needs a diet ...  
>>  Even if the netdev went on diet, a netdev per vni for vxlan deployments is 
>> just too much overhead.
>>
>>
> But the intent was VNI == VLAN tag and there are cases where you need per VNI 
> rules.
what rules are these ?
> Having them all smashed into one netdev seems like a step in the wrong 
> direction.
only thing that a vxlan netdev per vni carries is a separate fdb table per vni 
with mac as the key. The natural progression from one fdb table per vni to a 
single fdb table for all vni's is to support a fdb table with   as 
the key. So, unclear why it is a step in the wrong direction. This is exactly 
how the vlan filtering bridge fdb table is built also ...with  as 
the key.

And, note that a single vxlan netdev is already deployed in COLLECT_METADATA 
mode. This series, just makes the fdb
available to the single vxlan netdev in COLLECT_METADATA mode. No change to the 
normal default mode of one vxlan netdev per vni.

Re: [PATCH 1/2] Documentation: devicetree: change the mediatek ethernet compatible string

[James Liao]

On Wed, 2017-01-25 at 09:20 +0100, John Crispin wrote:
> When the binding was defined, I was not aware that mt2701 was an earlier
> version of the SoC. For sake of consistency, the ethernet driver should
> use mt2701 inside the compat string as this is the earliest SoC with the
> ethernet core.
> 
> The ethernet driver is currently of no real use until we finish and
> upstream the DSA driver. There are no users of this binding yet. It should
> be safe to fix this now before it is too late and we need to provide
> backward compatibility for the mt7623-eth compat string.
> 
> Reported-by: Sean Wang 
> Signed-off-by: John Crispin 

Acked-by: James Liao 

> ---
>  Documentation/devicetree/bindings/net/mediatek-net.txt |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/net/mediatek-net.txt 
> b/Documentation/devicetree/bindings/net/mediatek-net.txt
> index c010faf..c7194e8 100644
> --- a/Documentation/devicetree/bindings/net/mediatek-net.txt
> +++ b/Documentation/devicetree/bindings/net/mediatek-net.txt
> @@ -7,7 +7,7 @@ have dual GMAC each represented by a child node..
>  * Ethernet controller node
>  
>  Required properties:
> -- compatible: Should be "mediatek,mt7623-eth"
> +- compatible: Should be "mediatek,mt2701-eth"
>  - reg: Address and length of the register set for the device
>  - interrupts: Should contain the three frame engines interrupts in numeric
>   order. These are fe_int0, fe_int1 and fe_int2.

Re: [PATCH 2/2] net-next: ethernet: mediatek: change the compatible string

[James Liao]

On Wed, 2017-01-25 at 09:20 +0100, John Crispin wrote:
> When the binding was defined, I was not aware that mt2701 was an earlier
> version of the SoC. For sake of consistency, the ethernet driver should
> use mt2701 inside the compat string as this is the earliest SoC with the
> ethernet core.
> 
> The ethernet driver is currently of no real use until we finish and
> upstream the DSA driver. There are no users of this binding yet. It should
> be safe to fix this now before it is too late and we need to provide
> backward compatibility for the mt7623-eth compat string.
> 
> Reported-by: Sean Wang 
> Signed-off-by: John Crispin 

Acked-by: James Liao 

> ---
>  drivers/net/ethernet/mediatek/mtk_eth_soc.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c 
> b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> index 25ae0c5..9e75768 100644
> --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> @@ -2515,7 +2515,7 @@ static int mtk_remove(struct platform_device *pdev)
>  }
>  
>  const struct of_device_id of_mtk_match[] = {
> - { .compatible = "mediatek,mt7623-eth" },
> + { .compatible = "mediatek,mt2701-eth" },
>   {},
>  };
>  MODULE_DEVICE_TABLE(of, of_mtk_match);

[PATCH net-next] net: add LINUX_MIB_PFMEMALLOCDROP counter

[Eric Dumazet]

From: Eric Dumazet 

Debugging issues caused by pfmemalloc is often tedious.

Add a new SNMP counter to more easily diagnose these problems.

Signed-off-by: Eric Dumazet 
Cc: Josef Bacik 
---
 include/uapi/linux/snmp.h |1 +
 net/core/filter.c |5 +++--
 net/ipv4/proc.c   |1 +
 3 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/include/uapi/linux/snmp.h b/include/uapi/linux/snmp.h
index 
e7a31f8306903f53bc5881ae4c271f85cad2e361..3b2bed7ca9a4d92c5671e614f2bc598668805f75
 100644
--- a/include/uapi/linux/snmp.h
+++ b/include/uapi/linux/snmp.h
@@ -240,6 +240,7 @@ enum
LINUX_MIB_SACKMERGED,
LINUX_MIB_SACKSHIFTFALLBACK,
LINUX_MIB_TCPBACKLOGDROP,
+   LINUX_MIB_PFMEMALLOCDROP,
LINUX_MIB_TCPMINTTLDROP, /* RFC 5082 */
LINUX_MIB_TCPDEFERACCEPTDROP,
LINUX_MIB_IPRPFILTER, /* IP Reverse Path Filter (rp_filter) */
diff --git a/net/core/filter.c b/net/core/filter.c
index 
1e00737e3bc370bc6c1afaf602439c81208ea3ac..0b753cbb2536763de53d266c9b9126d63942d7e5
 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -76,9 +76,10 @@ int sk_filter_trim_cap(struct sock *sk, struct sk_buff *skb, 
unsigned int cap)
 * allow SOCK_MEMALLOC sockets to use it as this socket is
 * helping free memory
 */
-   if (skb_pfmemalloc(skb) && !sock_flag(sk, SOCK_MEMALLOC))
+   if (skb_pfmemalloc(skb) && !sock_flag(sk, SOCK_MEMALLOC)) {
+   NET_INC_STATS(sock_net(sk), LINUX_MIB_PFMEMALLOCDROP);
return -ENOMEM;
-
+   }
err = BPF_CGROUP_RUN_PROG_INET_INGRESS(sk, skb);
if (err)
return err;
diff --git a/net/ipv4/proc.c b/net/ipv4/proc.c
index 
a9deeb90dd36e0a8f94596b4f563ad63925344cf..69cf49e8356d0184f774840c9dc96560f2ae2f2b
 100644
--- a/net/ipv4/proc.c
+++ b/net/ipv4/proc.c
@@ -262,6 +262,7 @@ static const struct snmp_mib snmp4_net_list[] = {
SNMP_MIB_ITEM("TCPSackMerged", LINUX_MIB_SACKMERGED),
SNMP_MIB_ITEM("TCPSackShiftFallback", LINUX_MIB_SACKSHIFTFALLBACK),
SNMP_MIB_ITEM("TCPBacklogDrop", LINUX_MIB_TCPBACKLOGDROP),
+   SNMP_MIB_ITEM("PFMemallocDrop", LINUX_MIB_PFMEMALLOCDROP),
SNMP_MIB_ITEM("TCPMinTTLDrop", LINUX_MIB_TCPMINTTLDROP),
SNMP_MIB_ITEM("TCPDeferAcceptDrop", LINUX_MIB_TCPDEFERACCEPTDROP),
SNMP_MIB_ITEM("IPReversePathFilter", LINUX_MIB_IPRPFILTER),

Re: [PATCH net-next v2 0/5] bridge: per vlan dst_metadata support

[Stephen Hemminger]

On Wed, 01 Feb 2017 20:02:35 -0800
Roopa Prabhu  wrote:

> On 2/1/17, 5:59 PM, David Ahern wrote:
> > On 2/1/17 6:23 PM, Alexei Starovoitov wrote:  
> >> On Tue, Jan 31, 2017 at 10:59:50PM -0800, Roopa Prabhu wrote:  
> >>> 
> >>> This provides the required vxlan bridging function but poses a
> >>> scalability problem with using a separate vxlan netdev for each vni.  
> >> if I remember correctly this issue was the main reason David Ahern
> >> put netdev on diet. Sounds like no more fun at netconf ;)
> >>  
> > oh, it still needs a diet ...  
>  Even if the netdev went on diet, a netdev per vni for vxlan deployments is 
> just too much overhead.
> 
> 

But the intent was VNI == VLAN tag and there are cases where you need per VNI 
rules.
Having them all smashed into one netdev seems like a step in the wrong 
direction.

Re: [PATCH net-next v2 0/5] bridge: per vlan dst_metadata support

[Roopa Prabhu]

On 2/1/17, 5:59 PM, David Ahern wrote:
> On 2/1/17 6:23 PM, Alexei Starovoitov wrote:
>> On Tue, Jan 31, 2017 at 10:59:50PM -0800, Roopa Prabhu wrote:
>>> 
>>> This provides the required vxlan bridging function but poses a
>>> scalability problem with using a separate vxlan netdev for each vni.
>> if I remember correctly this issue was the main reason David Ahern
>> put netdev on diet. Sounds like no more fun at netconf ;)
>>
> oh, it still needs a diet ...
 Even if the netdev went on diet, a netdev per vni for vxlan deployments is 
just too much overhead.

Re: [net-next ovs clone action 3/3] openvswitch: kernel datapath clone action

[Andy Zhou]

On Wed, Feb 1, 2017 at 6:30 PM, Pravin Shelar  wrote:
> On Tue, Jan 31, 2017 at 8:47 AM, Andy Zhou  wrote:
>> Add 'clone' kernel datapath support. In case the actions within clone
>> do not modify the current flow, the actions are executed without
>> making a copy of current key before execution. This analysis is
>> done once per flow installation.
>>
>> On the other hand, in case the actions within clone may modify
>> current flow key, a key has to be copied. In case the percpu
>> 'flow_keys' is available for the next 'exec_actions_level', the clone
>> actions will be executed without using the deferred fifo. Otherwise,
>> deferred fifo is used this clone action.
>>
>
> I think we can use sample action to clone packet and apply
> optimization to sample action. That will allow greater use of existing
> action without additional complexity.
>
O.K. I will rework the patch series to apply the optimizations to the sample
action.  Thanks for the review and comment.

Re: [PATCH net] net: phy: Fix lack of reference count on PHY driver

[Florian Fainelli]

On 02/01/2017 11:10 AM, Russell King - ARM Linux wrote:
> On Wed, Feb 01, 2017 at 01:59:38PM -0500, David Miller wrote:
>> From: Florian Fainelli 
>> Date: Wed, 1 Feb 2017 10:55:46 -0800
>>
>>> You are right, but there is still a fundamental problem IMHO in that you
>>> should not be able to rmmod a PHY driver as long as a network device is
>>> attached to the PHY, and if the PHY driver is attached from several
>>> different network devices, they should all have a way to prevent a PHY
>>> driver rmmod, each of them incrementing the driver refcount, which is
>>> what the patche from Maowan does here.
>>
>> It briefly occurred to me that we might want to be able to disconnect
>> PHYs to allow an unload using notifiers, the same way that when you
>> take a netdevice down we emit notifiers so that all of the references
>> to the netdevice can release themselves.
>>
>> I have no idea how well that would work, or whether it is valuable or
>> not.  But it is another way to handle this.
>>
>> But that is a longer-term thing even if we want to go that way, and
>> thus grabbing the proper refs is the right things to do for now.
> 
> It's something I'm effectively already doing as part of my phylink
> project for SFP support, since you can hot-unplug a copper SFP
> module, and the PHY on the copper SFP module will be gone.  phylink,
> however, sits between the network driver and phylib, which isn't
> ideal.

So, for the "net" tree what should we do? I don't really think that we
should be able to let the PHY state machine run without a PHY driver
bound to the device, at best nothing happens, at worse, we just crash
and burn without further chance of recovering.
-- 
Florian

Re: [PATCH net] net: phy: Fix lack of reference count on PHY driver

[Florian Fainelli]

On 02/01/2017 02:51 AM, Russell King - ARM Linux wrote:
> It looks to me as if that's the only case where this can happen, so maybe
> the above needs to be:
> 
> if (phydev->drv && phydev->drv->link_change_notify)
> phydev->drv->link_change_notify(phydev);
> 
> Also, I'd suggest making sure that the workqueue is flushed in
> phy_remove() after setting phydev->drv to NULL to ensure that the
> workqueue isn't running while the phy driver is being unbound, which
> should also make module removal safe(r).  I haven't fully analysed
> that though.

I suspect nobody has actually ever tested that, because it's pretty
badly broken at the moment... working on it.
-- 
Florian

Re: [PATCH net-next] loopback: clear pfmemalloc on outgoing skb's

[Eric Dumazet]

On Wed, 2017-02-01 at 15:38 -0800, Eric Dumazet wrote:

> I am not sure this is a proper fix.
> 
> Presumably if the socket was able to store packets in its write queue,
> fact that it sends it to loopback or an Ethernet link should not matter.
> 
> Only in RX path the pfmemalloc thing is really important.
> 
> So I would rather not set skb->pfmemalloc for skbs allocated for the
> write queue, and more exactly the fast clone.

Also note that any looped packet would have the problem : veth, macvlan,
ipvlan, ...

[PATCH net-next] net: ipv4: remove fib_lookup.h from devinet.c include list

[David Ahern]

nothing in devinet.c relies on fib_lookup.h; remove it from the includes

Signed-off-by: David Ahern 
---
 net/ipv4/devinet.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index 4cd2ee8857d2..5d367b7ff542 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -65,8 +65,6 @@
 #include 
 #include 
 
-#include "fib_lookup.h"
-
 static struct ipv4_devconf ipv4_devconf = {
.data = {
[IPV4_DEVCONF_ACCEPT_REDIRECTS - 1] = 1,
-- 
2.1.4

Re: [net-next ovs clone action 3/3] openvswitch: kernel datapath clone action

[Pravin Shelar]

On Tue, Jan 31, 2017 at 8:47 AM, Andy Zhou  wrote:
> Add 'clone' kernel datapath support. In case the actions within clone
> do not modify the current flow, the actions are executed without
> making a copy of current key before execution. This analysis is
> done once per flow installation.
>
> On the other hand, in case the actions within clone may modify
> current flow key, a key has to be copied. In case the percpu
> 'flow_keys' is available for the next 'exec_actions_level', the clone
> actions will be executed without using the deferred fifo. Otherwise,
> deferred fifo is used this clone action.
>

I think we can use sample action to clone packet and apply
optimization to sample action. That will allow greater use of existing
action without additional complexity.

Thanks,
Pravin.

Re: [PATCH] net: stmmac: Remove wrong message in stmmac_probe_config_dt

[Phil Reid]

On 2/02/2017 05:05, Heiner Kallweit wrote:

I can only imagine that this message ended up there by a copy & paste
mistake. The same message appears correctly a few lines later, but
here it doesn't make sense.

Signed-off-by: Heiner Kallweit 
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 460f94f5..5edf23dc 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -371,7 +371,6 @@ stmmac_probe_config_dt(struct platform_device *pdev, const 
char **mac)
} else {
clk_prepare_enable(plat->clk_ptp_ref);
plat->clk_ptp_rate = clk_get_rate(plat->clk_ptp_ref);
-   dev_info(>dev, "No reset control found\n");
}

plat->stmmac_rst = devm_reset_control_get(>dev,



It was originally:
netdev_dbg(priv->dev, "PTP rate %d\n", priv->clk_ptp_rate);
Before it got moved in:
commit f573c0b9c4e02691cf87736bd0824fd37ec02e65
stmmac: move stmmac_clk, pclk, clk_ptp_ref and stmmac_rst to platform structure

--
Regards
Phil Reid

Re: [PATCH net-next] net: phy: marvell: Add support for 88e1545 PHY

[Florian Fainelli]

On 02/01/2017 03:35 PM, Andrew Lunn wrote:
> The 88e1545 PHYs are discrete Marvell PHYs, found in a quad package on
> the zii-devel-b board. Add support for it to the Marvell PHY driver.
> 
> Signed-off-by: Andrew Lunn 

Reviewed-by: Florian Fainelli 
-- 
Florian

[PATCH net-next] net: remove useless pfmemalloc setting

[Eric Dumazet]

From: Eric Dumazet 

When __alloc_skb() allocates an skb from fast clone cache,
setting pfmemalloc on the clone is not needed.

Clone will be properly initialized later at skb_clone() time,
including pfmemalloc field, as it is included in the
headers_start/headers_end section which is fully copied.

Signed-off-by: Eric Dumazet 
---
 net/core/skbuff.c |1 -
 1 file changed, 1 deletion(-)

diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 
26c1344cc23e31d4248d23fc007bcab4b034c5c9..4f8f2a1a66b5a36705e8f9966f7abd751932dcc6
 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -271,7 +271,6 @@ struct sk_buff *__alloc_skb(unsigned int size, gfp_t 
gfp_mask,
atomic_set(>fclone_ref, 1);
 
fclones->skb2.fclone = SKB_FCLONE_CLONE;
-   fclones->skb2.pfmemalloc = pfmemalloc;
}
 out:
return skb;

Re: [PATCH net-next v2 0/5] bridge: per vlan dst_metadata support

[David Ahern]

On 2/1/17 6:23 PM, Alexei Starovoitov wrote:
> On Tue, Jan 31, 2017 at 10:59:50PM -0800, Roopa Prabhu wrote:
>> 
>> This provides the required vxlan bridging function but poses a
>> scalability problem with using a separate vxlan netdev for each vni.
> if I remember correctly this issue was the main reason David Ahern
> put netdev on diet. Sounds like no more fun at netconf ;)
> 

oh, it still needs a diet ...

Re: [PATCH] net: phy: dp83867: Port mirroring support in the DP83867 TI's PHY driver

[Andrew Lunn]

On Wed, Feb 01, 2017 at 11:13:23PM +0100, Lukasz Majewski wrote:
> Hi Andrew,
> 
> > > We would need a tri-state device tree properly:
> > > 
> > > 1. Not defined - do nothing
> > > 2. Defined as 0 -> explicitly disable port mirroring
> > > 3. Defined as 1 -> explicitly enable port mirriring
> > > 
> > > The "net-phy-lane-swap" only fulfills points 1 and 3 above.
> > > 
> > > In my use case I do need point 2.
> > 
> > Looking at the datasheet, PORT_MIRROR_EN defaults to 0. So it seems
> > reasonable to unconditionally set it to 0 when the PHY driver
> > loads. Any device which needs a value of 1 can set "net-phy-lane-swap"
> 
> Unconditionally setting this field to 0 (as we expect the reset default
> setting) seems to me like a good solution. 
> 
> However, I was not sure if such approach is acceptable by the community.

So the issue here is, are there boards with bootloaders which set this
"lane swap" bit, and rely on Linux not changing it, because the
hardware design has such a swap?

It seems the bootloader you are using does this. But in your case, it
does it wrongly. I'm guessing you have a vendor bootloader? And no
easy access to the sources? Otherwise you would of fixed the
bootloader. So can we assume there are vendor designed boards which
require the swap? Do they run a mainline kernel? Or only the vendor
kernel?

If we know of mainline boards which are going to break, we should not
do this.

If however we do decide to reset it to default value, i think it would
be good to implement net-phy-lane-swap as well, so giving people an
easier path towards mainline.

   Andrew

linux-next: manual merge of the net-next tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the net-next tree got a conflict in:

  net/sched/cls_matchall.c

between commit:

  fd62d9f5c575 ("net/sched: matchall: Fix configuration race")

from Linus' tree and commit:

  ec2507d2a306 ("net/sched: cls_matchall: Fix error path")

from the net-next tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc net/sched/cls_matchall.c
index b12bc2abea93,fcecf5aac666..
--- a/net/sched/cls_matchall.c
+++ b/net/sched/cls_matchall.c
@@@ -118,19 -141,24 +118,24 @@@ static int mall_set_parms(struct net *n
struct tcf_exts e;
int err;
  
-   tcf_exts_init(, TCA_MATCHALL_ACT, 0);
+   err = tcf_exts_init(, TCA_MATCHALL_ACT, 0);
+   if (err)
+   return err;
err = tcf_exts_validate(net, tp, tb, est, , ovr);
if (err < 0)
-   return err;
+   goto errout;
  
if (tb[TCA_MATCHALL_CLASSID]) {
 -  f->res.classid = nla_get_u32(tb[TCA_MATCHALL_CLASSID]);
 -  tcf_bind_filter(tp, >res, base);
 +  head->res.classid = nla_get_u32(tb[TCA_MATCHALL_CLASSID]);
 +  tcf_bind_filter(tp, >res, base);
}
  
 -  tcf_exts_change(tp, >exts, );
 +  tcf_exts_change(tp, >exts, );
  
return 0;
+ errout:
+   tcf_exts_destroy();
+   return err;
  }
  
  static int mall_change(struct net *net, struct sk_buff *in_skb,
@@@ -162,39 -194,43 +167,44 @@@
return -EINVAL;
}
  
 -  f = kzalloc(sizeof(*f), GFP_KERNEL);
 -  if (!f)
 +  new = kzalloc(sizeof(*new), GFP_KERNEL);
 +  if (!new)
return -ENOBUFS;
  
-   tcf_exts_init(>exts, TCA_MATCHALL_ACT, 0);
 -  err = tcf_exts_init(>exts, TCA_MATCHALL_ACT, 0);
++  err = tcf_exts_init(>exts, TCA_MATCHALL_ACT, 0);
+   if (err)
+   goto err_exts_init;
  
if (!handle)
handle = 1;
 -  f->handle = handle;
 -  f->flags = flags;
 +  new->handle = handle;
 +  new->flags = flags;
  
 -  err = mall_set_parms(net, tp, f, base, tb, tca[TCA_RATE], ovr);
 +  err = mall_set_parms(net, tp, new, base, tb, tca[TCA_RATE], ovr);
if (err)
-   goto errout;
+   goto err_set_parms;
  
if (tc_should_offload(dev, tp, flags)) {
 -  err = mall_replace_hw_filter(tp, f, (unsigned long) f);
 +  err = mall_replace_hw_filter(tp, new, (unsigned long) new);
if (err) {
if (tc_skip_sw(flags))
-   goto errout;
+   goto err_replace_hw_filter;
else
err = 0;
}
}
  
 -  *arg = (unsigned long) f;
 -  rcu_assign_pointer(head->filter, f);
 -
 +  *arg = (unsigned long) head;
 +  rcu_assign_pointer(tp->root, new);
 +  if (head)
 +  call_rcu(>rcu, mall_destroy_rcu);
return 0;
  
- errout:
+ err_replace_hw_filter:
+ err_set_parms:
 -  tcf_exts_destroy(>exts);
++  tcf_exts_destroy(>exts);
+ err_exts_init:
 -  kfree(f);
 +  kfree(new);
return err;
  }
  

Re: [PATCH net-next v2 0/5] bridge: per vlan dst_metadata support

[Alexei Starovoitov]

On Tue, Jan 31, 2017 at 10:59:50PM -0800, Roopa Prabhu wrote:
> 
> This provides the required vxlan bridging function but poses a
> scalability problem with using a separate vxlan netdev for each vni.

if I remember correctly this issue was the main reason David Ahern
put netdev on diet. Sounds like no more fun at netconf ;)

> Solution in this patch series:
> The Goal is to use a single vxlan device to carry all vnis similar
> to the vxlan collect metadata mode but additionally allowing the bridge
> and vxlan driver to carry all the forwarding information and also learn.
> This implementation uses the existing dst_metadata infrastructure to map
> vlan to a tunnel id.

ovs and/or bpf can do the same already, but sounds like the main reason is
to keep it integrated with bridge fdb to leverage your offload of bridge
fdb into hw asic, right?
If so, I guess, the extra complexity can be justified.
The question is how do you program hw ? Is there really 1 to 1 mapping
in the asics too? Or is it more flexible ?
I think most swith asics can do other tunnels too,
so can this vlan->vxlan 1 to 1 be generalized to cover different
types of tunnels that can be configured on the switch?

[PATCH iproute2] ss: print tcpi_rcv_mss

[Eric Dumazet]

From: Eric Dumazet 

tcpi_rcv_mss tcp info field was not yet reported by ss.

While adding GRO support to packetdrill, I found this was useful.

Signed-off-by: Eric Dumazet 
---
 misc/ss.c |4 
 1 file changed, 4 insertions(+)

diff --git a/misc/ss.c b/misc/ss.c
index 4454bd1..6e4f84a 100644
--- a/misc/ss.c
+++ b/misc/ss.c
@@ -707,6 +707,7 @@ struct tcpstat {
int snd_wscale;
int rcv_wscale;
int mss;
+   int rcv_mss;
unsigned intcwnd;
unsigned intlastsnd;
unsigned intlastrcv;
@@ -1872,6 +1873,8 @@ static void tcp_stats_print(struct tcpstat *s)
 
if (s->mss)
printf(" mss:%d", s->mss);
+   if (s->rcv_mss)
+   printf(" rcvmss:%d", s->rcv_mss);
if (s->cwnd)
printf(" cwnd:%u", s->cwnd);
if (s->ssthresh)
@@ -2189,6 +2192,7 @@ static void tcp_show_info(const struct nlmsghdr *nlh, 
struct inet_diag_msg *r,
s.rttvar = (double)info->tcpi_rttvar / 1000;
s.ato= (double)info->tcpi_ato / 1000;
s.mss= info->tcpi_snd_mss;
+   s.rcv_mss= info->tcpi_rcv_mss;
s.rcv_space  = info->tcpi_rcv_space;
s.rcv_rtt= (double)info->tcpi_rcv_rtt / 1000;
s.lastsnd= info->tcpi_last_data_sent;

Re: [PATCH 1/2] net: ethernet: bgmac: init sequence bug

[Zac Schroff]

How about BCMA_IOCTL_PRESERVE_ACROSS_INIT?

On Wed, Feb 1, 2017 at 6:06 PM, Rafał Miłecki  wrote:
> On 02/01/2017 11:39 PM, Jon Mason wrote:
>>
>> From: Zac Schroff 
>>
>> Fix a bug in the 'bgmac' driver init sequence that blind writes for init
>> sequence where it should preserve most bits other than the ones it is
>> deliberately manipulating.
>>
>> Signed-off-by: Zac Schroff 
>> Signed-off-by: Jon Mason 
>> Fixes: f6a95a24957 ("net: ethernet: bgmac: Add platform device support")
>> ---
>>  drivers/net/ethernet/broadcom/bgmac-platform.c | 10 +++---
>>  include/linux/bcma/bcma_regs.h |  1 +
>>  2 files changed, 8 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/broadcom/bgmac-platform.c
>> b/drivers/net/ethernet/broadcom/bgmac-platform.c
>> index 6f736c1..9bbe05c 100644
>> --- a/drivers/net/ethernet/broadcom/bgmac-platform.c
>> +++ b/drivers/net/ethernet/broadcom/bgmac-platform.c
>> @@ -61,15 +61,19 @@ static bool platform_bgmac_clk_enabled(struct bgmac
>> *bgmac)
>>
>>  static void platform_bgmac_clk_enable(struct bgmac *bgmac, u32 flags)
>>  {
>> -   bgmac_idm_write(bgmac, BCMA_IOCTL,
>> -   (BCMA_IOCTL_CLK | BCMA_IOCTL_FGC | flags));
>> +   u32 regval;
>> +
>> +   /* Some bits of BCMA_IOCTL set by HW/ATF & should not change */
>> +   regval = bgmac_idm_read(bgmac, BCMA_IOCTL) &
>> BCMA_IOCTL_DO_NOT_MODIFY;
>> +   regval |= ((flags & (~BCMA_IOCTL_DO_NOT_MODIFY)) |
>> BCMA_IOCTL_CLK);
>
>
> You don't need these braces around whole calculation.
> This should work the same:
> (flags & (~BCMA_IOCTL_DO_NOT_MODIFY)) | BCMA_IOCTL_CLK
>
>
>> +   bgmac_idm_write(bgmac, BCMA_IOCTL, regval | BCMA_IOCTL_FGC);
>> bgmac_idm_read(bgmac, BCMA_IOCTL);
>>
>> bgmac_idm_write(bgmac, BCMA_RESET_CTL, 0);
>> bgmac_idm_read(bgmac, BCMA_RESET_CTL);
>> udelay(1);
>>
>> -   bgmac_idm_write(bgmac, BCMA_IOCTL, (BCMA_IOCTL_CLK | flags));
>> +   bgmac_idm_write(bgmac, BCMA_IOCTL, regval);
>> bgmac_idm_read(bgmac, BCMA_IOCTL);
>> udelay(1);
>>  }
>> diff --git a/include/linux/bcma/bcma_regs.h
>> b/include/linux/bcma/bcma_regs.h
>> index 9986f82..41d7404 100644
>> --- a/include/linux/bcma/bcma_regs.h
>> +++ b/include/linux/bcma/bcma_regs.h
>> @@ -31,6 +31,7 @@
>>  #define  BCMA_IOCTL_CORE_BITS  0x3FFC
>>  #define  BCMA_IOCTL_PME_EN 0x4000
>>  #define  BCMA_IOCTL_BIST_EN0x8000
>> +#define  BCMA_IOCTL_DO_NOT_MODIFY  0x7F80
>
>
> This sounds like a pretty bad name.
>
> Take a look at brcmsmac and SICF_*:
> http://lxr.free-electrons.com/source/drivers/net/wireless/broadcom/brcm80211/brcmsmac/d11.h?v=4.9#L1737
>
> Or b43 and B43_BCMA_IOCTL_*:
> http://lxr.free-electrons.com/source/drivers/net/wireless/broadcom/b43/b43.h?v=4.9#L494
>
> Both drives modify bits you marked as DO_NOT_MODIFY and they are OK.

Re: [PATCH] xen-netfront: Delete rx_refill_timer in xennet_disconnect_backend()

[Eric Dumazet]

On Wed, 2017-02-01 at 18:29 -0500, Boris Ostrovsky wrote:

> 
> I could not convince myself that napi_synchronize() is sufficient here
> (mostly because I am not familiar with napi flow). At the same time I
> would rather not make changes in anticipation of possible disappearance
> of netif_carrier_ok() in the future so I'd like this patch to go in as is.
> 
> Unless there are other problems with the patch or if Eric (or others)
> feel strongly about usage of netif_carrier_ok() here.
> 

No strong feelings from me.
We probably have more serious issues to fix anyway.

Re: net: suspicious RCU usage in nf_hook

[Eric Dumazet]

On Wed, 2017-02-01 at 15:48 -0800, Eric Dumazet wrote:
> On Wed, Feb 1, 2017 at 3:29 PM, Cong Wang  wrote:
> 
> > Not sure if it is better. The difference is caught up in 
> > net_enable_timestamp(),
> > which is called setsockopt() path and sk_clone() path, so we could be
> > in netstamp_needed state for a long time too until user-space exercises
> > these paths.
> >
> > I am feeling we probably need to get rid of netstamp_needed_deferred,
> > and simply defer the whole static_key_slow_dec(), like the attached patch
> > (compile only).
> >
> > What do you think?
> 
> I think we need to keep the atomic.
> 
> If two cpus call net_disable_timestamp() roughly at the same time, the
> work will be scheduled once.

Updated patch (but not tested yet)

diff --git a/net/core/dev.c b/net/core/dev.c
index 
7f218e095361520d11c243d650e053321ea7274f..29101c98399f40b6b8e42c31a255d8f1fb6bd7a1
 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1695,24 +1695,19 @@ EXPORT_SYMBOL_GPL(net_dec_egress_queue);
 
 static struct static_key netstamp_needed __read_mostly;
 #ifdef HAVE_JUMP_LABEL
-/* We are not allowed to call static_key_slow_dec() from irq context
- * If net_disable_timestamp() is called from irq context, defer the
- * static_key_slow_dec() calls.
- */
 static atomic_t netstamp_needed_deferred;
-#endif
-
-void net_enable_timestamp(void)
+static void netstamp_clear(struct work_struct *work)
 {
-#ifdef HAVE_JUMP_LABEL
int deferred = atomic_xchg(_needed_deferred, 0);
 
-   if (deferred) {
-   while (--deferred)
-   static_key_slow_dec(_needed);
-   return;
-   }
+   while (deferred--)
+   static_key_slow_dec(_needed);
+}
+static DECLARE_WORK(netstamp_work, netstamp_clear);
 #endif
+
+void net_enable_timestamp(void)
+{
static_key_slow_inc(_needed);
 }
 EXPORT_SYMBOL(net_enable_timestamp);
@@ -1720,12 +1715,12 @@ EXPORT_SYMBOL(net_enable_timestamp);
 void net_disable_timestamp(void)
 {
 #ifdef HAVE_JUMP_LABEL
-   if (in_interrupt()) {
-   atomic_inc(_needed_deferred);
-   return;
-   }
-#endif
+   /* net_disable_timestamp() can be called from non process context */
+   atomic_inc(_needed_deferred);
+   schedule_work(_work);
+#else
static_key_slow_dec(_needed);
+#endif
 }
 EXPORT_SYMBOL(net_disable_timestamp);
 

Re: [PATCH net-next] loopback: clear pfmemalloc on outgoing skb's

[Eric Dumazet]

On Wed, 2017-02-01 at 15:38 -0800, Eric Dumazet wrote:
> On Wed, 2017-02-01 at 16:04 -0500, Josef Bacik wrote:
> > I was seeing random disconnects while testing NBD over loopback.  This 
> > turned
> > out to be because NBD sets pfmemalloc on it's socket, however the receiving 
> > side
> > is a user space application so does not have pfmemalloc set on its socket.  
> > This
> > means that sk_filter_trim_cap will simply drop this packet, under the 
> > assumption
> > that the other side will simply retransmit.  Well we do retransmit, and 
> > then the
> > packet is just dropped again for the same reason.  To keep this from 
> > happening
> > simply clear skb->pfmemalloc on transmit so that we don't drop the packet 
> > on the
> > receive side.
> > 
> > Signed-off-by: Josef Bacik 
> > ---
> >  drivers/net/loopback.c | 7 +++
> >  1 file changed, 7 insertions(+)
> > 
> > diff --git a/drivers/net/loopback.c b/drivers/net/loopback.c
> > index 1e05b7c..13c9126 100644
> > --- a/drivers/net/loopback.c
> > +++ b/drivers/net/loopback.c
> > @@ -81,6 +81,13 @@ static netdev_tx_t loopback_xmit(struct sk_buff *skb,
> >  */
> > skb_dst_force(skb);
> >  
> > +   /* If our transmitter was a pfmemalloc socket we need to clear
> > +* pfmemalloc here, otherwise the receiving socket may not be
> > +* pfmemalloc, and if this is a tcp packet then it'll get dropped and
> > +* all traffic will halt.
> > +*/
> > +   skb->pfmemalloc = false;
> > +
> 
> I am not sure this is a proper fix.
> 
> Presumably if the socket was able to store packets in its write queue,
> fact that it sends it to loopback or an Ethernet link should not matter.
> 
> Only in RX path the pfmemalloc thing is really important.
> 
> So I would rather not set skb->pfmemalloc for skbs allocated for the
> write queue, and more exactly the fast clone.
> 
> This would actually speed up the stack a bit.
> 
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index 
> 734c71468b013838516cfe8c744dcd0e797a6e2b..f91b81340dc5be80e0c26f9835d9192f35b75ad7
>  100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -271,7 +271,7 @@ struct sk_buff *__alloc_skb(unsigned int size, gfp_t 
> gfp_mask,
> atomic_set(>fclone_ref, 1);
>  
> fclones->skb2.fclone = SKB_FCLONE_CLONE;
> -   fclones->skb2.pfmemalloc = pfmemalloc;
> +   fclones->skb2.pfmemalloc = 0;


It turns out this part was not needed in current kernel, because
__copy_skb_header() will copy pfmemalloc, since it is included in the
headers_start/headers_end section of skb.

So this patch is not solving your issue.

Re: net: suspicious RCU usage in nf_hook

[Eric Dumazet]

On Wed, Feb 1, 2017 at 3:29 PM, Cong Wang  wrote:

> Not sure if it is better. The difference is caught up in 
> net_enable_timestamp(),
> which is called setsockopt() path and sk_clone() path, so we could be
> in netstamp_needed state for a long time too until user-space exercises
> these paths.
>
> I am feeling we probably need to get rid of netstamp_needed_deferred,
> and simply defer the whole static_key_slow_dec(), like the attached patch
> (compile only).
>
> What do you think?

I think we need to keep the atomic.

If two cpus call net_disable_timestamp() roughly at the same time, the
work will be scheduled once.

Re: [net-next 1/8] net/mlx5: Fixed static checker warnings

[Or Gerlitz]

On Wed, Feb 1, 2017 at 7:22 PM, David Miller  wrote:

[..]

> You're propagating values into a u32 field, which you are explicitly
> performing 32-bit endianness conversions upon.

> Just use "u32" for a local variable and get rid of all of these casts.

ok, will do that

[PATCHv2 net-next 0/2] MV88E6390 fixes

[Andrew Lunn]

Two patches, which have been posted before. Fix simple issues in the
mv88e6390 support. These don't need to go to stable, since the
mv88e6390 support in stable is insufficient to be usable.

To apply cleanly, these patches rely on "net: dsa: mv88e6xxx:
Workaround missing PHY".

v2: Added Reviewed-by.
Removed a redundant "the"

Andrew Lunn (2):
  net: dsa: mv88e6xxx: Fix ATU age timer for MV88E6390
  net: dsa: mv88e6xxx: Fix typ0 when configuring 2.5Gbps

 drivers/net/dsa/mv88e6xxx/chip.c | 12 ++--
 drivers/net/dsa/mv88e6xxx/port.c |  2 +-
 2 files changed, 7 insertions(+), 7 deletions(-)

-- 
2.11.0

[PATCHv2 net-next 1/2] net: dsa: mv88e6xxx: Fix ATU age timer for MV88E6390

[Andrew Lunn]

The MV88E6390 family uses a different ATU age timer coefficient.
Fix the info structures.

Signed-off-by: Andrew Lunn 
Reviewed-by: Vivien Didelot 
---
v2: Remove redundant "the".
Add Reviewed-by
---
 drivers/net/dsa/mv88e6xxx/chip.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 29190303ace0..22ce57256d34 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -4011,7 +4011,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.port_base_addr = 0x0,
.global1_addr = 0x1b,
.tag_protocol = DSA_TAG_PROTO_DSA,
-   .age_time_coeff = 15000,
+   .age_time_coeff = 3750,
.g1_irqs = 9,
.flags = MV88E6XXX_FLAGS_FAMILY_6390,
.ops = _ops,
@@ -4025,7 +4025,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.num_ports = 11,/* 10 + Z80 */
.port_base_addr = 0x0,
.global1_addr = 0x1b,
-   .age_time_coeff = 15000,
+   .age_time_coeff = 3750,
.g1_irqs = 9,
.tag_protocol = DSA_TAG_PROTO_DSA,
.flags = MV88E6XXX_FLAGS_FAMILY_6390,
@@ -4040,7 +4040,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.num_ports = 11,/* 10 + Z80 */
.port_base_addr = 0x0,
.global1_addr = 0x1b,
-   .age_time_coeff = 15000,
+   .age_time_coeff = 3750,
.g1_irqs = 9,
.tag_protocol = DSA_TAG_PROTO_DSA,
.flags = MV88E6XXX_FLAGS_FAMILY_6390,
@@ -4070,7 +4070,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.num_ports = 11,/* 10 + Z80 */
.port_base_addr = 0x0,
.global1_addr = 0x1b,
-   .age_time_coeff = 15000,
+   .age_time_coeff = 3750,
.g1_irqs = 9,
.tag_protocol = DSA_TAG_PROTO_DSA,
.flags = MV88E6XXX_FLAGS_FAMILY_6390,
@@ -4187,7 +4187,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.num_ports = 11,/* 10 + Z80 */
.port_base_addr = 0x0,
.global1_addr = 0x1b,
-   .age_time_coeff = 15000,
+   .age_time_coeff = 3750,
.g1_irqs = 9,
.tag_protocol = DSA_TAG_PROTO_DSA,
.flags = MV88E6XXX_FLAGS_FAMILY_6390,
@@ -4201,7 +4201,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.num_ports = 11,/* 10 + Z80 */
.port_base_addr = 0x0,
.global1_addr = 0x1b,
-   .age_time_coeff = 15000,
+   .age_time_coeff = 3750,
.g1_irqs = 9,
.tag_protocol = DSA_TAG_PROTO_DSA,
.flags = MV88E6XXX_FLAGS_FAMILY_6390,
-- 
2.11.0

[PATCHv2 net-next 2/2] net: dsa: mv88e6xxx: Fix typ0 when configuring 2.5Gbps

[Andrew Lunn]

In order to enable 2.5Gbps mode, we need the base speed of 10G, plus
the Alt bit setting. Fix a typ0 that used 1Gb base speed.

Signed-off-by: Andrew Lunn 
Reviewed-by: Vivien Didelot 
---
v2: Add Reviewed-by
---
 drivers/net/dsa/mv88e6xxx/port.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/dsa/mv88e6xxx/port.c b/drivers/net/dsa/mv88e6xxx/port.c
index 0db7fa0373ae..d380a93b092c 100644
--- a/drivers/net/dsa/mv88e6xxx/port.c
+++ b/drivers/net/dsa/mv88e6xxx/port.c
@@ -193,7 +193,7 @@ static int mv88e6xxx_port_set_speed(struct mv88e6xxx_chip 
*chip, int port,
ctrl = PORT_PCS_CTRL_SPEED_1000;
break;
case 2500:
-   ctrl = PORT_PCS_CTRL_SPEED_1000 | PORT_PCS_CTRL_ALTSPEED;
+   ctrl = PORT_PCS_CTRL_SPEED_1 | PORT_PCS_CTRL_ALTSPEED;
break;
case 1:
/* all bits set, fall through... */
-- 
2.11.0

Re: [PATCH net-next] loopback: clear pfmemalloc on outgoing skb's

[Eric Dumazet]

On Wed, 2017-02-01 at 16:04 -0500, Josef Bacik wrote:
> I was seeing random disconnects while testing NBD over loopback.  This turned
> out to be because NBD sets pfmemalloc on it's socket, however the receiving 
> side
> is a user space application so does not have pfmemalloc set on its socket.  
> This
> means that sk_filter_trim_cap will simply drop this packet, under the 
> assumption
> that the other side will simply retransmit.  Well we do retransmit, and then 
> the
> packet is just dropped again for the same reason.  To keep this from happening
> simply clear skb->pfmemalloc on transmit so that we don't drop the packet on 
> the
> receive side.
> 
> Signed-off-by: Josef Bacik 
> ---
>  drivers/net/loopback.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/net/loopback.c b/drivers/net/loopback.c
> index 1e05b7c..13c9126 100644
> --- a/drivers/net/loopback.c
> +++ b/drivers/net/loopback.c
> @@ -81,6 +81,13 @@ static netdev_tx_t loopback_xmit(struct sk_buff *skb,
>*/
>   skb_dst_force(skb);
>  
> + /* If our transmitter was a pfmemalloc socket we need to clear
> +  * pfmemalloc here, otherwise the receiving socket may not be
> +  * pfmemalloc, and if this is a tcp packet then it'll get dropped and
> +  * all traffic will halt.
> +  */
> + skb->pfmemalloc = false;
> +

I am not sure this is a proper fix.

Presumably if the socket was able to store packets in its write queue,
fact that it sends it to loopback or an Ethernet link should not matter.

Only in RX path the pfmemalloc thing is really important.

So I would rather not set skb->pfmemalloc for skbs allocated for the
write queue, and more exactly the fast clone.

This would actually speed up the stack a bit.

diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 
734c71468b013838516cfe8c744dcd0e797a6e2b..f91b81340dc5be80e0c26f9835d9192f35b75ad7
 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -271,7 +271,7 @@ struct sk_buff *__alloc_skb(unsigned int size, gfp_t 
gfp_mask,
atomic_set(>fclone_ref, 1);
 
fclones->skb2.fclone = SKB_FCLONE_CLONE;
-   fclones->skb2.pfmemalloc = pfmemalloc;
+   fclones->skb2.pfmemalloc = 0;
}
 out:
return skb;

[PATCH net-next] net: phy: marvell: Add support for 88e1545 PHY

[Andrew Lunn]

The 88e1545 PHYs are discrete Marvell PHYs, found in a quad package on
the zii-devel-b board. Add support for it to the Marvell PHY driver.

Signed-off-by: Andrew Lunn 
---

NOTE: To apply cleanly, the "Work around missing PHY product ID in mv88e6390"
patches need to be applied first.

drivers/net/phy/marvell.c   | 21 +
 include/linux/marvell_phy.h |  1 +
 2 files changed, 22 insertions(+)

diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index 1a0ac48cbc50..f9d0fa315a47 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -2123,6 +2123,26 @@ static struct phy_driver marvell_drivers[] = {
.get_stats = marvell_get_stats,
},
{
+   .phy_id = MARVELL_PHY_ID_88E1545,
+   .phy_id_mask = MARVELL_PHY_ID_MASK,
+   .name = "Marvell 88E1545",
+   .probe = m88e1510_probe,
+   .remove = _remove,
+   .features = PHY_GBIT_FEATURES,
+   .flags = PHY_HAS_INTERRUPT,
+   .config_init = _config_init,
+   .config_aneg = _config_aneg,
+   .read_status = _read_status,
+   .ack_interrupt = _ack_interrupt,
+   .config_intr = _config_intr,
+   .did_interrupt = _did_interrupt,
+   .resume = _resume,
+   .suspend = _suspend,
+   .get_sset_count = marvell_get_sset_count,
+   .get_strings = marvell_get_strings,
+   .get_stats = marvell_get_stats,
+   },
+   {
.phy_id = MARVELL_PHY_ID_88E3016,
.phy_id_mask = MARVELL_PHY_ID_MASK,
.name = "Marvell 88E3016",
@@ -2178,6 +2198,7 @@ static struct mdio_device_id __maybe_unused marvell_tbl[] 
= {
{ MARVELL_PHY_ID_88E1116R, MARVELL_PHY_ID_MASK },
{ MARVELL_PHY_ID_88E1510, MARVELL_PHY_ID_MASK },
{ MARVELL_PHY_ID_88E1540, MARVELL_PHY_ID_MASK },
+   { MARVELL_PHY_ID_88E1545, MARVELL_PHY_ID_MASK },
{ MARVELL_PHY_ID_88E3016, MARVELL_PHY_ID_MASK },
{ MARVELL_PHY_ID_88E6390, MARVELL_PHY_ID_MASK },
{ }
diff --git a/include/linux/marvell_phy.h b/include/linux/marvell_phy.h
index 3d616d7f65bf..4055cf8cc978 100644
--- a/include/linux/marvell_phy.h
+++ b/include/linux/marvell_phy.h
@@ -17,6 +17,7 @@
 #define MARVELL_PHY_ID_88E1116R0x01410e40
 #define MARVELL_PHY_ID_88E1510 0x01410dd0
 #define MARVELL_PHY_ID_88E1540 0x01410eb0
+#define MARVELL_PHY_ID_88E1545 0x01410ea0
 #define MARVELL_PHY_ID_88E3016 0x01410e60
 
 /* The MV88e6390 Ethernet switch contains embedded PHYs. These PHYs do
-- 
2.11.0

Re: net: suspicious RCU usage in nf_hook

[Cong Wang]

On Wed, Feb 1, 2017 at 1:16 PM, Eric Dumazet  wrote:
> On Wed, 2017-02-01 at 12:51 -0800, Cong Wang wrote:
>> On Tue, Jan 31, 2017 at 7:44 AM, Eric Dumazet  wrote:
>> > On Mon, 2017-01-30 at 22:19 -0800, Cong Wang wrote:
>> >
>> >>
>> >> The context is process context (TX path before hitting qdisc), and
>> >> BH is not disabled, so in_interrupt() doesn't catch it. Hmm, this
>> >> makes me thinking maybe we really need to disable BH in this
>> >> case for nf_hook()? But it is called in RX path too, and BH is
>> >> already disabled there.
>> >
>> > ipt_do_table() and similar netfilter entry points disable BH.
>> >
>> > Maybe it is done too late.
>>
>> I think we need a fix like the following one for minimum impact.
>>
>> diff --git a/net/core/dev.c b/net/core/dev.c
>> index 727b6fd..eee7d63 100644
>> --- a/net/core/dev.c
>> +++ b/net/core/dev.c
>> @@ -1720,12 +1720,10 @@ EXPORT_SYMBOL(net_enable_timestamp);
>>  void net_disable_timestamp(void)
>>  {
>>  #ifdef HAVE_JUMP_LABEL
>> -   if (in_interrupt()) {
>> -   atomic_inc(_needed_deferred);
>> -   return;
>> -   }
>> -#endif
>> +   atomic_inc(_needed_deferred);
>> +#else
>> static_key_slow_dec(_needed);
>> +#endif
>>  }
>>  EXPORT_SYMBOL(net_disable_timestamp);
>
> This would permanently leave the kernel in the netstamp_needed state.
>
> I would prefer the patch using a process context to perform the
> cleanup ? Note there is a race window, but probably not a big deal.

Not sure if it is better. The difference is caught up in net_enable_timestamp(),
which is called setsockopt() path and sk_clone() path, so we could be
in netstamp_needed state for a long time too until user-space exercises
these paths.

I am feeling we probably need to get rid of netstamp_needed_deferred,
and simply defer the whole static_key_slow_dec(), like the attached patch
(compile only).

What do you think?
diff --git a/net/core/dev.c b/net/core/dev.c
index 727b6fd..0ef1734 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1694,38 +1694,28 @@ EXPORT_SYMBOL_GPL(net_dec_egress_queue);
 #endif
 
 static struct static_key netstamp_needed __read_mostly;
-#ifdef HAVE_JUMP_LABEL
-/* We are not allowed to call static_key_slow_dec() from irq context
- * If net_disable_timestamp() is called from irq context, defer the
- * static_key_slow_dec() calls.
- */
-static atomic_t netstamp_needed_deferred;
-#endif
 
-void net_enable_timestamp(void)
+static void netstamp_clear(struct work_struct *work)
 {
-#ifdef HAVE_JUMP_LABEL
-   int deferred = atomic_xchg(_needed_deferred, 0);
+   static_key_slow_dec(_needed);
+}
 
-   if (deferred) {
-   while (--deferred)
-   static_key_slow_dec(_needed);
-   return;
-   }
-#endif
+static DECLARE_WORK(netstamp_work, netstamp_clear);
+
+void net_enable_timestamp(void)
+{
+   flush_work(_work);
static_key_slow_inc(_needed);
 }
 EXPORT_SYMBOL(net_enable_timestamp);
 
 void net_disable_timestamp(void)
 {
-#ifdef HAVE_JUMP_LABEL
-   if (in_interrupt()) {
-   atomic_inc(_needed_deferred);
-   return;
-   }
-#endif
-   static_key_slow_dec(_needed);
+   /* We are not allowed to call static_key_slow_dec() from irq context
+* If net_disable_timestamp() is called from irq context, defer the
+* static_key_slow_dec() calls.
+*/
+   schedule_work(_work);
 }
 EXPORT_SYMBOL(net_disable_timestamp);
 

Re: [PATCH] xen-netfront: Delete rx_refill_timer in xennet_disconnect_backend()

[Boris Ostrovsky]

On 01/31/2017 12:47 PM, Boris Ostrovsky wrote:
> On 01/30/2017 02:31 PM, Boris Ostrovsky wrote:
>> On 01/30/2017 02:06 PM, Eric Dumazet wrote:
>>> On Mon, 2017-01-30 at 13:23 -0500, Boris Ostrovsky wrote:
>>>
 We do netif_carrier_off() first thing in xennet_disconnect_backend() and
 the only place where the timer is rearmed is xennet_alloc_rx_buffers(),
 which is guarded by netif_carrier_ok() check.
>>> Oh well, testing netif_carrier_ok() in packet processing fast path looks
>>> unusual and a waste of cpu cycles. I've never seen that pattern before.
>>>
>>> If one day, we remove this netif_carrier_ok() test during a cleanup,
>>> then the race window will open again.
>> I don't know much about napi but I wonder whether I can indeed disable
>> it in xennet_disconnect_backend(). I don't see how anything can happen
>> after disconnect since it unmaps the rings. And then napi is re-enabled
>> during reconnection in xennet_create_queues(). In which case am not sure
>> there is any need for xennet_destroy_queues() as everything there could
>> be folded into xennet_disconnect_backend().
> While this does work, there was a reason why napi_disable() was not
> called in xennet_disconnect_backend() and it is explained in commit
> ce58725fec6e --- napi_disable() may sleep and that's why it is called in
> xennet_destroy_queues().
>
> OTOH, there is a napi_synchronize() call in xennet_destroy_queues().
> Will destroying the timer after it guarantee that all preceding RX have
> been completed? RX interrupt is disabled prior to napi_synchronize() so
> presumably nothing new can be received.


I could not convince myself that napi_synchronize() is sufficient here
(mostly because I am not familiar with napi flow). At the same time I
would rather not make changes in anticipation of possible disappearance
of netif_carrier_ok() in the future so I'd like this patch to go in as is.

Unless there are other problems with the patch or if Eric (or others)
feel strongly about usage of netif_carrier_ok() here.


-boris

[PATCH] wcn36xx: Implement cancel_hw_scan

[Bjorn Andersson]

In the even that the wcn36xx interface is brought down while a hw_scan
is active we must abort and wait for the ongoing scan to signal
completion to mac80211.

Reported-by: Mart Raudsepp 
Fixes: 886039036c20 ("wcn36xx: Implement firmware assisted scan")
Signed-off-by: Bjorn Andersson 
---
 drivers/net/wireless/ath/wcn36xx/main.c| 25 -
 drivers/net/wireless/ath/wcn36xx/wcn36xx.h |  1 +
 2 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/wcn36xx/main.c 
b/drivers/net/wireless/ath/wcn36xx/main.c
index a24edf33be93..bb7110f7fc86 100644
--- a/drivers/net/wireless/ath/wcn36xx/main.c
+++ b/drivers/net/wireless/ath/wcn36xx/main.c
@@ -574,6 +574,7 @@ static void wcn36xx_hw_scan_worker(struct work_struct *work)
struct cfg80211_scan_request *req = wcn->scan_req;
u8 channels[WCN36XX_HAL_PNO_MAX_NETW_CHANNELS_EX];
struct cfg80211_scan_info scan_info = {};
+   bool aborted = false;
int i;
 
wcn36xx_dbg(WCN36XX_DBG_MAC, "mac80211 scan %d channels worker\n", 
req->n_channels);
@@ -585,6 +586,13 @@ static void wcn36xx_hw_scan_worker(struct work_struct 
*work)
 
wcn36xx_smd_init_scan(wcn, HAL_SYS_MODE_SCAN);
for (i = 0; i < req->n_channels; i++) {
+   mutex_lock(>scan_lock);
+   aborted = wcn->scan_aborted;
+   mutex_unlock(>scan_lock);
+
+   if (aborted)
+   break;
+
wcn->scan_freq = req->channels[i]->center_freq;
wcn->scan_band = req->channels[i]->band;
 
@@ -596,7 +604,7 @@ static void wcn36xx_hw_scan_worker(struct work_struct *work)
}
wcn36xx_smd_finish_scan(wcn, HAL_SYS_MODE_SCAN);
 
-   scan_info.aborted = false;
+   scan_info.aborted = aborted;
ieee80211_scan_completed(wcn->hw, _info);
 
mutex_lock(>scan_lock);
@@ -615,6 +623,8 @@ static int wcn36xx_hw_scan(struct ieee80211_hw *hw,
mutex_unlock(>scan_lock);
return -EBUSY;
}
+
+   wcn->scan_aborted = false;
wcn->scan_req = _req->req;
mutex_unlock(>scan_lock);
 
@@ -623,6 +633,18 @@ static int wcn36xx_hw_scan(struct ieee80211_hw *hw,
return 0;
 }
 
+static void wcn36xx_cancel_hw_scan(struct ieee80211_hw *hw,
+  struct ieee80211_vif *vif)
+{
+   struct wcn36xx *wcn = hw->priv;
+
+   mutex_lock(>scan_lock);
+   wcn->scan_aborted = true;
+   mutex_unlock(>scan_lock);
+
+   cancel_work_sync(>scan_work);
+}
+
 static void wcn36xx_update_allowed_rates(struct ieee80211_sta *sta,
 enum nl80211_band band)
 {
@@ -1034,6 +1056,7 @@ static const struct ieee80211_ops wcn36xx_ops = {
.tx = wcn36xx_tx,
.set_key= wcn36xx_set_key,
.hw_scan= wcn36xx_hw_scan,
+   .cancel_hw_scan = wcn36xx_cancel_hw_scan,
.bss_info_changed   = wcn36xx_bss_info_changed,
.set_rts_threshold  = wcn36xx_set_rts_threshold,
.sta_add= wcn36xx_sta_add,
diff --git a/drivers/net/wireless/ath/wcn36xx/wcn36xx.h 
b/drivers/net/wireless/ath/wcn36xx/wcn36xx.h
index 571e9f76da7e..b52b4da9a967 100644
--- a/drivers/net/wireless/ath/wcn36xx/wcn36xx.h
+++ b/drivers/net/wireless/ath/wcn36xx/wcn36xx.h
@@ -220,6 +220,7 @@ struct wcn36xx {
int scan_freq;
int scan_band;
struct mutexscan_lock;
+   boolscan_aborted;
 
/* DXE channels */
struct wcn36xx_dxe_ch   dxe_tx_l_ch;/* TX low */
-- 
2.11.0

Re: [PATCH 1/2] net: ethernet: bgmac: init sequence bug

[Rafał Miłecki]

On 02/01/2017 11:39 PM, Jon Mason wrote:

From: Zac Schroff 

Fix a bug in the 'bgmac' driver init sequence that blind writes for init
sequence where it should preserve most bits other than the ones it is
deliberately manipulating.

Signed-off-by: Zac Schroff 
Signed-off-by: Jon Mason 
Fixes: f6a95a24957 ("net: ethernet: bgmac: Add platform device support")
---
 drivers/net/ethernet/broadcom/bgmac-platform.c | 10 +++---
 include/linux/bcma/bcma_regs.h |  1 +
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/bgmac-platform.c 
b/drivers/net/ethernet/broadcom/bgmac-platform.c
index 6f736c1..9bbe05c 100644
--- a/drivers/net/ethernet/broadcom/bgmac-platform.c
+++ b/drivers/net/ethernet/broadcom/bgmac-platform.c
@@ -61,15 +61,19 @@ static bool platform_bgmac_clk_enabled(struct bgmac *bgmac)

 static void platform_bgmac_clk_enable(struct bgmac *bgmac, u32 flags)
 {
-   bgmac_idm_write(bgmac, BCMA_IOCTL,
-   (BCMA_IOCTL_CLK | BCMA_IOCTL_FGC | flags));
+   u32 regval;
+
+   /* Some bits of BCMA_IOCTL set by HW/ATF & should not change */
+   regval = bgmac_idm_read(bgmac, BCMA_IOCTL) & BCMA_IOCTL_DO_NOT_MODIFY;
+   regval |= ((flags & (~BCMA_IOCTL_DO_NOT_MODIFY)) | BCMA_IOCTL_CLK);


You don't need these braces around whole calculation.
This should work the same:
(flags & (~BCMA_IOCTL_DO_NOT_MODIFY)) | BCMA_IOCTL_CLK



+   bgmac_idm_write(bgmac, BCMA_IOCTL, regval | BCMA_IOCTL_FGC);
bgmac_idm_read(bgmac, BCMA_IOCTL);

bgmac_idm_write(bgmac, BCMA_RESET_CTL, 0);
bgmac_idm_read(bgmac, BCMA_RESET_CTL);
udelay(1);

-   bgmac_idm_write(bgmac, BCMA_IOCTL, (BCMA_IOCTL_CLK | flags));
+   bgmac_idm_write(bgmac, BCMA_IOCTL, regval);
bgmac_idm_read(bgmac, BCMA_IOCTL);
udelay(1);
 }
diff --git a/include/linux/bcma/bcma_regs.h b/include/linux/bcma/bcma_regs.h
index 9986f82..41d7404 100644
--- a/include/linux/bcma/bcma_regs.h
+++ b/include/linux/bcma/bcma_regs.h
@@ -31,6 +31,7 @@
 #define  BCMA_IOCTL_CORE_BITS  0x3FFC
 #define  BCMA_IOCTL_PME_EN 0x4000
 #define  BCMA_IOCTL_BIST_EN0x8000
+#define  BCMA_IOCTL_DO_NOT_MODIFY  0x7F80


This sounds like a pretty bad name.

Take a look at brcmsmac and SICF_*:
http://lxr.free-electrons.com/source/drivers/net/wireless/broadcom/brcm80211/brcmsmac/d11.h?v=4.9#L1737

Or b43 and B43_BCMA_IOCTL_*:
http://lxr.free-electrons.com/source/drivers/net/wireless/broadcom/b43/b43.h?v=4.9#L494

Both drives modify bits you marked as DO_NOT_MODIFY and they are OK.

Re: [PATCHv3 net-next 5/7] net: add confirm_neigh method to dst_ops

[Julian Anastasov]

Hello,

On Wed, 1 Feb 2017, Steffen Klassert wrote:

> On Tue, Jan 31, 2017 at 11:57:05PM +0200, Julian Anastasov wrote:
> >  
> > +static void xfrm_confirm_neigh(const struct dst_entry *dst, const void 
> > *daddr)
> > +{
> > +   const struct dst_entry *path = dst->path;
> > +
> > +   if (path == dst) {
> 
> I think path can not be equal to dst here, otherwise we would
> have an infinite recursion.

Yep, I know that, this place remained unfinished.

> > +   dst->ops->confirm_neigh(dst, daddr);
> > +   } else {
> > +   /* daddr can be from different family and we need the
> > +* tunnel address. How to get it?
> > +*/
> 
> This is only called on a xfrm_dst, so you should have dst->xfrm set.
> You can get the daddr of this transform with:
> 
> xfrm_address_t *daddr = >id.daddr;

I hope so but see below...

> > +   path->ops->confirm_neigh(path, NULL);
> 
> I think here it is better to go through the whole chain
> of transformations with
> 
> child->ops->confirm_neigh(path, daddr);

It may sounds good. But only dst->path->ops->confirm_neigh
points to real IPv4/IPv6 function. And also, I guess, the
family can change while walking the chain, so we should be
careful while providing the original daddr (which comes from
sendmsg). I had the idea to walk all xforms to get the latest
tunnel address but this can be slow. Something like this?:

static void xfrm_confirm_neigh(const struct dst_entry *dst, const void 
*daddr)
{
const struct dst_entry *path = dst->path;

/* By default, daddr is from sendmsg() if we have no tunnels */
for (;dst != path; dst = dst->child) {
const struct xfrm_state *xfrm = dst->xfrm;

/* Use address from last tunnel */
if (xfrm->props.mode != XFRM_MODE_TRANSPORT)
daddr = >id.daddr;
}
path->ops->confirm_neigh(path, daddr);
}

This should work as long as path and last tunnel are
from same family. Also, after checking xfrm_dst_lookup() I'm not
sure using just >id.daddr is enough. Should we consider
more places for daddr value?

> >  int xfrm_policy_register_afinfo(struct xfrm_policy_afinfo *afinfo)
> >  {
> > int err = 0;
> > @@ -2882,6 +2896,8 @@ int xfrm_policy_register_afinfo(struct 
> > xfrm_policy_afinfo *afinfo)
> > dst_ops->link_failure = xfrm_link_failure;
> > if (likely(dst_ops->neigh_lookup == NULL))
> > dst_ops->neigh_lookup = xfrm_neigh_lookup;
> > +   if (likely(!dst_ops->confirm_neigh))
> > +   dst_ops->confirm_neigh = xfrm_confirm_neigh;
> 
> We also have address family depended dst_ops, look for
> xfrm4_dst_ops_template/xfrm6_dst_ops_template.

For now I installed common handler, just like
xfrm_neigh_lookup. BTW this function has problem from
commit f894cbf847c9, it looks like dst is wrongly provided,
first arg should be dst->path.

But as dst_ops contains the family, I think, we can know
what kind of daddr is provided initially (dst->ops->family).
So far, the above logic does not need to compare the families.
But as I don't know the code well, I'm not sure, my assumptions are:

- transports do not change the family
- tunnels may change the family
- last tunnel gets dst0->path route from its family

Regards

--
Julian Anastasov 

[PATCH 2/2] net: ethernet: bgmac: mac address change bug

[Jon Mason]

From: Hari Vyas 

ndo_set_mac_address() passes struct sockaddr * as 2nd parameter to
bgmac_set_mac_address() but code assumed u8 *.  This caused two bytes
chopping and the wrong mac address was configured.

Signed-off-by: Hari Vyas 
Signed-off-by: Jon Mason 
Fixes: 4e209001b86 ("bgmac: write mac address to hardware in 
ndo_set_mac_address")
---
 drivers/net/ethernet/broadcom/bgmac.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/broadcom/bgmac.c 
b/drivers/net/ethernet/broadcom/bgmac.c
index 0e066dc6..ea24072 100644
--- a/drivers/net/ethernet/broadcom/bgmac.c
+++ b/drivers/net/ethernet/broadcom/bgmac.c
@@ -1222,11 +1222,15 @@ static int bgmac_set_mac_address(struct net_device 
*net_dev, void *addr)
 {
struct bgmac *bgmac = netdev_priv(net_dev);
int ret;
+   struct sockaddr *sa = addr;
 
ret = eth_prepare_mac_addr_change(net_dev, addr);
if (ret < 0)
return ret;
-   bgmac_write_mac_address(bgmac, (u8 *)addr);
+
+   ether_addr_copy(bgmac->mac_addr, sa->sa_data);
+   bgmac_write_mac_address(bgmac, bgmac->mac_addr);
+
eth_commit_mac_addr_change(net_dev, addr);
return 0;
 }
-- 
2.7.4

[PATCH 0/2] net: ethernet: bgmac: bug fixes

[Jon Mason]

Bug fixes for bgmac driver

Hari Vyas (1):
  net: ethernet: bgmac: mac address change bug

Zac Schroff (1):
  net: ethernet: bgmac: init sequence bug

 drivers/net/ethernet/broadcom/bgmac-platform.c | 10 +++---
 drivers/net/ethernet/broadcom/bgmac.c  |  6 +-
 include/linux/bcma/bcma_regs.h |  1 +
 3 files changed, 13 insertions(+), 4 deletions(-)

-- 
2.7.4

[PATCH 1/2] net: ethernet: bgmac: init sequence bug

[Jon Mason]

From: Zac Schroff 

Fix a bug in the 'bgmac' driver init sequence that blind writes for init
sequence where it should preserve most bits other than the ones it is
deliberately manipulating.

Signed-off-by: Zac Schroff 
Signed-off-by: Jon Mason 
Fixes: f6a95a24957 ("net: ethernet: bgmac: Add platform device support")
---
 drivers/net/ethernet/broadcom/bgmac-platform.c | 10 +++---
 include/linux/bcma/bcma_regs.h |  1 +
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/bgmac-platform.c 
b/drivers/net/ethernet/broadcom/bgmac-platform.c
index 6f736c1..9bbe05c 100644
--- a/drivers/net/ethernet/broadcom/bgmac-platform.c
+++ b/drivers/net/ethernet/broadcom/bgmac-platform.c
@@ -61,15 +61,19 @@ static bool platform_bgmac_clk_enabled(struct bgmac *bgmac)
 
 static void platform_bgmac_clk_enable(struct bgmac *bgmac, u32 flags)
 {
-   bgmac_idm_write(bgmac, BCMA_IOCTL,
-   (BCMA_IOCTL_CLK | BCMA_IOCTL_FGC | flags));
+   u32 regval;
+
+   /* Some bits of BCMA_IOCTL set by HW/ATF & should not change */
+   regval = bgmac_idm_read(bgmac, BCMA_IOCTL) & BCMA_IOCTL_DO_NOT_MODIFY;
+   regval |= ((flags & (~BCMA_IOCTL_DO_NOT_MODIFY)) | BCMA_IOCTL_CLK);
+   bgmac_idm_write(bgmac, BCMA_IOCTL, regval | BCMA_IOCTL_FGC);
bgmac_idm_read(bgmac, BCMA_IOCTL);
 
bgmac_idm_write(bgmac, BCMA_RESET_CTL, 0);
bgmac_idm_read(bgmac, BCMA_RESET_CTL);
udelay(1);
 
-   bgmac_idm_write(bgmac, BCMA_IOCTL, (BCMA_IOCTL_CLK | flags));
+   bgmac_idm_write(bgmac, BCMA_IOCTL, regval);
bgmac_idm_read(bgmac, BCMA_IOCTL);
udelay(1);
 }
diff --git a/include/linux/bcma/bcma_regs.h b/include/linux/bcma/bcma_regs.h
index 9986f82..41d7404 100644
--- a/include/linux/bcma/bcma_regs.h
+++ b/include/linux/bcma/bcma_regs.h
@@ -31,6 +31,7 @@
 #define  BCMA_IOCTL_CORE_BITS  0x3FFC
 #define  BCMA_IOCTL_PME_EN 0x4000
 #define  BCMA_IOCTL_BIST_EN0x8000
+#define  BCMA_IOCTL_DO_NOT_MODIFY  0x7F80
 #define BCMA_IOST  0x0500 /* IO status */
 #define  BCMA_IOST_CORE_BITS   0x0FFF
 #define  BCMA_IOST_DMA64   0x1000
-- 
2.7.4

[PATCH v7 3/3] Bluetooth: btusb: Configure Marvell to use one of the pins for oob wakeup

[Rajat Jain]

The Marvell devices may have many gpio pins, and hence for wakeup
on these out-of-band pins, the chip needs to be told which pin is
to be used for wakeup, using an hci command.

Thus, we read the pin number etc from the device tree node and send
a command to the chip.

Signed-off-by: Rajat Jain 
Reviewed-by: Brian Norris 
Acked-by: Rob Herring 
---
v7: Same as v6
v6: same as v5
v5: same as v5
v4: same as v3
v3: * remove the Marvell specific id table and check
* Add reference to marvell-bt-8xxx.txt in btusb.txt
* Add "Reviewed-by" and "Acked-by"
v2: Fix the binding document to specify to use "wakeup" interrupt-name

 Documentation/devicetree/bindings/net/btusb.txt|  3 ++
 .../{marvell-bt-sd8xxx.txt => marvell-bt-8xxx.txt} | 46 +++
 drivers/bluetooth/btusb.c  | 51 ++
 3 files changed, 92 insertions(+), 8 deletions(-)
 rename Documentation/devicetree/bindings/net/{marvell-bt-sd8xxx.txt => 
marvell-bt-8xxx.txt} (50%)

diff --git a/Documentation/devicetree/bindings/net/btusb.txt 
b/Documentation/devicetree/bindings/net/btusb.txt
index 2c0355c85972..01fa2d4188d4 100644
--- a/Documentation/devicetree/bindings/net/btusb.txt
+++ b/Documentation/devicetree/bindings/net/btusb.txt
@@ -10,6 +10,9 @@ Required properties:
 
  "usb1286,204e" (Marvell 8997)
 
+Also, vendors that use btusb may have device additional properties, e.g:
+Documentation/devicetree/bindings/net/marvell-bt-8xxx.txt
+
 Optional properties:
 
   - interrupt-parent: phandle of the parent interrupt controller
diff --git a/Documentation/devicetree/bindings/net/marvell-bt-sd8xxx.txt 
b/Documentation/devicetree/bindings/net/marvell-bt-8xxx.txt
similarity index 50%
rename from Documentation/devicetree/bindings/net/marvell-bt-sd8xxx.txt
rename to Documentation/devicetree/bindings/net/marvell-bt-8xxx.txt
index 6a9a63cb0543..9be1059ff03f 100644
--- a/Documentation/devicetree/bindings/net/marvell-bt-sd8xxx.txt
+++ b/Documentation/devicetree/bindings/net/marvell-bt-8xxx.txt
@@ -1,16 +1,21 @@
-Marvell 8897/8997 (sd8897/sd8997) bluetooth SDIO devices
+Marvell 8897/8997 (sd8897/sd8997) bluetooth devices (SDIO or USB based)
 --
+The 8997 devices supports multiple interfaces. When used on SDIO interfaces,
+the btmrvl driver is used and when used on USB interface, the btusb driver is
+used.
 
 Required properties:
 
   - compatible : should be one of the following:
-   * "marvell,sd8897-bt"
-   * "marvell,sd8997-bt"
+   * "marvell,sd8897-bt" (for SDIO)
+   * "marvell,sd8997-bt" (for SDIO)
+   * "usb1286,204e"  (for USB)
 
 Optional properties:
 
   - marvell,cal-data: Calibration data downloaded to the device during
  initialization. This is an array of 28 values(u8).
+ This is only applicable to SDIO devices.
 
   - marvell,wakeup-pin: It represents wakeup pin number of the bluetooth chip.
firmware will use the pin to wakeup host system (u16).
@@ -18,10 +23,15 @@ Optional properties:
  platform. The value will be configured to firmware. This
  is needed to work chip's sleep feature as expected (u16).
   - interrupt-parent: phandle of the parent interrupt controller
-  - interrupts : interrupt pin number to the cpu. Driver will request an irq 
based
-on this interrupt number. During system suspend, the irq will 
be
-enabled so that the bluetooth chip can wakeup host platform 
under
-certain condition. During system resume, the irq will be 
disabled
+  - interrupt-names: Used only for USB based devices (See below)
+  - interrupts : specifies the interrupt pin number to the cpu. For SDIO, the
+driver will use the first interrupt specified in the interrupt
+array. For USB based devices, the driver will use the interrupt
+named "wakeup" from the interrupt-names and interrupt arrays.
+The driver will request an irq based on this interrupt number.
+During system suspend, the irq will be enabled so that the
+bluetooth chip can wakeup host platform under certain
+conditions. During system resume, the irq will be disabled
 to make sure unnecessary interrupt is not received.
 
 Example:
@@ -29,7 +39,9 @@ Example:
 IRQ pin 119 is used as system wakeup source interrupt.
 wakeup pin 13 and gap 100ms are configured so that firmware can wakeup host
 using this device side pin and wakeup latency.
-calibration data is also available in below example.
+
+Example for SDIO device follows (calibration data is also available in
+below example).
 
  {
status = "okay";
@@ -54,3 +66,21 @@ calibration data is also available in below example.
marvell,wakeup-gap-ms = /bits/ 16 <0x64>;
};
 };
+
+Example for 

[PATCH v7 2/3] Bluetooth: btusb: Add out-of-band wakeup support

[Rajat Jain]

Some onboard BT chips (e.g. Marvell 8997) contain a wakeup pin that
can be connected to a gpio on the CPU side, and can be used to wakeup
the host out-of-band. This can be useful in situations where the
in-band wakeup is not possible or not preferable (e.g. the in-band
wakeup may require the USB host controller to remain active, and
hence consuming more system power during system sleep).

The oob gpio interrupt to be used for wakeup on the CPU side, is
read from the device tree node, (using standard interrupt descriptors).
A devcie tree binding document is also added for the driver. The
compatible string is in compliance with
Documentation/devicetree/bindings/usb/usb-device.txt

Signed-off-by: Rajat Jain 
Reviewed-by: Brian Norris 
Acked-by: Rob Herring 
---
v7: Change the BTUSB_OOB_WAKE_DISABLED flag to BTUSB_OOB_WAKE_ENABLED
v6: Remove the newlines in error statements ("\n")
v5: Move the call to pm_wakeup_event() to the begining of irq handler.
v4: Move the set_bit(BTUSB_OOB_WAKE_DISABLED,..) call to the beginning of
btusb_config_oob_wake()
v3: Add Brian's "Reviewed-by"
v2: * Use interrupt-names ("wakeup") instead of assuming first interrupt.
* Leave it on device tree to specify IRQ flags (level /edge triggered)
* Mark the device as non wakeable on exit.

 Documentation/devicetree/bindings/net/btusb.txt | 40 
 drivers/bluetooth/btusb.c   | 85 +
 2 files changed, 125 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/btusb.txt

diff --git a/Documentation/devicetree/bindings/net/btusb.txt 
b/Documentation/devicetree/bindings/net/btusb.txt
new file mode 100644
index ..2c0355c85972
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/btusb.txt
@@ -0,0 +1,40 @@
+Generic Bluetooth controller over USB (btusb driver)
+---
+
+Required properties:
+
+  - compatible : should comply with the format "usbVID,PID" specified in
+Documentation/devicetree/bindings/usb/usb-device.txt
+At the time of writing, the only OF supported devices
+(more may be added later) are:
+
+ "usb1286,204e" (Marvell 8997)
+
+Optional properties:
+
+  - interrupt-parent: phandle of the parent interrupt controller
+  - interrupt-names: (see below)
+  - interrupts : The interrupt specified by the name "wakeup" is the interrupt
+that shall be used for out-of-band wake-on-bt. Driver will
+request this interrupt for wakeup. During system suspend, the
+irq will be enabled so that the bluetooth chip can wakeup host
+platform out of band. During system resume, the irq will be
+disabled to make sure unnecessary interrupt is not received.
+
+Example:
+
+Following example uses irq pin number 3 of gpio0 for out of band wake-on-bt:
+
+_host1_ehci {
+status = "okay";
+#address-cells = <1>;
+#size-cells = <0>;
+
+mvl_bt1: bt@1 {
+   compatible = "usb1286,204e";
+   reg = <1>;
+   interrupt-parent = <>;
+   interrupt-name = "wakeup";
+   interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
+};
+};
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index ce22cefceed1..fa2231a36b98 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -24,6 +24,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 
 #include 
@@ -369,6 +371,7 @@ static const struct usb_device_id blacklist_table[] = {
 #define BTUSB_BOOTING  9
 #define BTUSB_RESET_RESUME 10
 #define BTUSB_DIAG_RUNNING 11
+#define BTUSB_OOB_WAKE_ENABLED 12
 
 struct btusb_data {
struct hci_dev   *hdev;
@@ -416,6 +419,8 @@ struct btusb_data {
int (*recv_bulk)(struct btusb_data *data, void *buffer, int count);
 
int (*setup_on_usb)(struct hci_dev *hdev);
+
+   int oob_wake_irq;   /* irq for out-of-band wake-on-bt */
 };
 
 static inline void btusb_free_frags(struct btusb_data *data)
@@ -2728,6 +2733,66 @@ static int btusb_bcm_set_diag(struct hci_dev *hdev, bool 
enable)
 }
 #endif
 
+#ifdef CONFIG_PM
+static irqreturn_t btusb_oob_wake_handler(int irq, void *priv)
+{
+   struct btusb_data *data = priv;
+
+   pm_wakeup_event(>udev->dev, 0);
+
+   /* Disable only if not already disabled (keep it balanced) */
+   if (test_and_clear_bit(BTUSB_OOB_WAKE_ENABLED, >flags)) {
+   disable_irq_nosync(irq);
+   disable_irq_wake(irq);
+   }
+   return IRQ_HANDLED;
+}
+
+static const struct of_device_id btusb_match_table[] = {
+   { .compatible = "usb1286,204e" },
+   { }
+};
+MODULE_DEVICE_TABLE(of, btusb_match_table);
+
+/* Use an oob wakeup pin? */
+static int btusb_config_oob_wake(struct hci_dev *hdev)
+{
+   struct btusb_data *data = hci_get_drvdata(hdev);
+   struct device *dev = 

[PATCH v7 1/3] Bluetooth: btusb: Use an error label for error paths

[Rajat Jain]

Use a label to remove the repetetive cleanup, for error cases.

Signed-off-by: Rajat Jain 
Reviewed-by: Brian Norris 
---
v7: same as v6
v6: same as v5
v5: same as v4
v4: same as v3
v3: Added Brian's "Reviewed-by"
v2: same as v1

 drivers/bluetooth/btusb.c | 19 +--
 1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 2f633df9f4e6..ce22cefceed1 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -2991,18 +2991,15 @@ static int btusb_probe(struct usb_interface *intf,
err = usb_set_interface(data->udev, 0, 0);
if (err < 0) {
BT_ERR("failed to set interface 0, alt 0 %d", err);
-   hci_free_dev(hdev);
-   return err;
+   goto out_free_dev;
}
}
 
if (data->isoc) {
err = usb_driver_claim_interface(_driver,
 data->isoc, data);
-   if (err < 0) {
-   hci_free_dev(hdev);
-   return err;
-   }
+   if (err < 0)
+   goto out_free_dev;
}
 
 #ifdef CONFIG_BT_HCIBTUSB_BCM
@@ -3016,14 +3013,16 @@ static int btusb_probe(struct usb_interface *intf,
 #endif
 
err = hci_register_dev(hdev);
-   if (err < 0) {
-   hci_free_dev(hdev);
-   return err;
-   }
+   if (err < 0)
+   goto out_free_dev;
 
usb_set_intfdata(intf, data);
 
return 0;
+
+out_free_dev:
+   hci_free_dev(hdev);
+   return err;
 }
 
 static void btusb_disconnect(struct usb_interface *intf)
-- 
2.11.0.483.g087da7b7c-goog

Re: [PATCH] net: phy: dp83867: Port mirroring support in the DP83867 TI's PHY driver

[Lukasz Majewski]

Hi Andrew,

> > We would need a tri-state device tree properly:
> > 
> > 1. Not defined - do nothing
> > 2. Defined as 0 -> explicitly disable port mirroring
> > 3. Defined as 1 -> explicitly enable port mirriring
> > 
> > The "net-phy-lane-swap" only fulfills points 1 and 3 above.
> > 
> > In my use case I do need point 2.
> 
> Looking at the datasheet, PORT_MIRROR_EN defaults to 0. So it seems
> reasonable to unconditionally set it to 0 when the PHY driver
> loads. Any device which needs a value of 1 can set "net-phy-lane-swap"

Unconditionally setting this field to 0 (as we expect the reset default
setting) seems to me like a good solution. 

However, I was not sure if such approach is acceptable by the community.

> 
>Andrew




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de

Re: [PATCH v2 2/4] net: phy: Initialize mdio clock at probe function

[Florian Fainelli]

On 01/17/2017 08:14 AM, Yendapally Reddy Dhananjaya Reddy wrote:
> Initialize mdio clock divisor in probe function. The ext bus
> bit available in the same register will be used by mdio mux
> to enable external mdio.
> 
> Signed-off-by: Yendapally Reddy Dhananjaya Reddy 
> 

David, this patch should go through your tree (but we forgot to CC you),
patch in patchwork is here:

http://patchwork.ozlabs.org/patch/716281/

Thanks!

> ---
>  drivers/net/phy/mdio-bcm-iproc.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/net/phy/mdio-bcm-iproc.c 
> b/drivers/net/phy/mdio-bcm-iproc.c
> index c0b4e65..46fe1ae 100644
> --- a/drivers/net/phy/mdio-bcm-iproc.c
> +++ b/drivers/net/phy/mdio-bcm-iproc.c
> @@ -81,8 +81,6 @@ static int iproc_mdio_read(struct mii_bus *bus, int phy_id, 
> int reg)
>   if (rc)
>   return rc;
>  
> - iproc_mdio_config_clk(priv->base);
> -
>   /* Prepare the read operation */
>   cmd = (MII_DATA_TA_VAL << MII_DATA_TA_SHIFT) |
>   (reg << MII_DATA_RA_SHIFT) |
> @@ -112,8 +110,6 @@ static int iproc_mdio_write(struct mii_bus *bus, int 
> phy_id,
>   if (rc)
>   return rc;
>  
> - iproc_mdio_config_clk(priv->base);
> -
>   /* Prepare the write operation */
>   cmd = (MII_DATA_TA_VAL << MII_DATA_TA_SHIFT) |
>   (reg << MII_DATA_RA_SHIFT) |
> @@ -163,6 +159,8 @@ static int iproc_mdio_probe(struct platform_device *pdev)
>   bus->read = iproc_mdio_read;
>   bus->write = iproc_mdio_write;
>  
> + iproc_mdio_config_clk(priv->base);
> +
>   rc = of_mdiobus_register(bus, pdev->dev.of_node);
>   if (rc) {
>   dev_err(>dev, "MDIO bus registration failed\n");
> 


-- 
Florian

Re: net: suspicious RCU usage in nf_hook

[Eric Dumazet]

On Wed, 2017-02-01 at 13:16 -0800, Eric Dumazet wrote:

> This would permanently leave the kernel in the netstamp_needed state.
> 
> I would prefer the patch using a process context to perform the
> cleanup ? Note there is a race window, but probably not a big deal.
> 
>  net/core/dev.c |   30 ++
>  1 file changed, 10 insertions(+), 20 deletions(-)

Patch is not complete (for the HAVE_JUMP_LABEL=n case)

Would you like to author/submit it ?

Thanks.

Re: net: suspicious RCU usage in nf_hook

[Eric Dumazet]

On Wed, 2017-02-01 at 12:51 -0800, Cong Wang wrote:
> On Tue, Jan 31, 2017 at 7:44 AM, Eric Dumazet  wrote:
> > On Mon, 2017-01-30 at 22:19 -0800, Cong Wang wrote:
> >
> >>
> >> The context is process context (TX path before hitting qdisc), and
> >> BH is not disabled, so in_interrupt() doesn't catch it. Hmm, this
> >> makes me thinking maybe we really need to disable BH in this
> >> case for nf_hook()? But it is called in RX path too, and BH is
> >> already disabled there.
> >
> > ipt_do_table() and similar netfilter entry points disable BH.
> >
> > Maybe it is done too late.
> 
> I think we need a fix like the following one for minimum impact.
> 
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 727b6fd..eee7d63 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -1720,12 +1720,10 @@ EXPORT_SYMBOL(net_enable_timestamp);
>  void net_disable_timestamp(void)
>  {
>  #ifdef HAVE_JUMP_LABEL
> -   if (in_interrupt()) {
> -   atomic_inc(_needed_deferred);
> -   return;
> -   }
> -#endif
> +   atomic_inc(_needed_deferred);
> +#else
> static_key_slow_dec(_needed);
> +#endif
>  }
>  EXPORT_SYMBOL(net_disable_timestamp);

This would permanently leave the kernel in the netstamp_needed state.

I would prefer the patch using a process context to perform the
cleanup ? Note there is a race window, but probably not a big deal.

 net/core/dev.c |   30 ++
 1 file changed, 10 insertions(+), 20 deletions(-)

diff --git a/net/core/dev.c b/net/core/dev.c
index 
7f218e095361520d11c243d650e053321ea7274f..1cae681b6cfd1cf2c9bee7072eb8af9cf79cced8
 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1695,37 +1695,27 @@ EXPORT_SYMBOL_GPL(net_dec_egress_queue);
 
 static struct static_key netstamp_needed __read_mostly;
 #ifdef HAVE_JUMP_LABEL
-/* We are not allowed to call static_key_slow_dec() from irq context
- * If net_disable_timestamp() is called from irq context, defer the
- * static_key_slow_dec() calls.
- */
 static atomic_t netstamp_needed_deferred;
-#endif
-
-void net_enable_timestamp(void)
+static void netstamp_clear(struct work_struct *work)
 {
-#ifdef HAVE_JUMP_LABEL
int deferred = atomic_xchg(_needed_deferred, 0);
 
-   if (deferred) {
-   while (--deferred)
-   static_key_slow_dec(_needed);
-   return;
-   }
+   while (deferred--)
+   static_key_slow_dec(_needed);
+}
+static DECLARE_WORK(netstamp_work, netstamp_clear);
 #endif
+
+void net_enable_timestamp(void)
+{
static_key_slow_inc(_needed);
 }
 EXPORT_SYMBOL(net_enable_timestamp);
 
 void net_disable_timestamp(void)
 {
-#ifdef HAVE_JUMP_LABEL
-   if (in_interrupt()) {
-   atomic_inc(_needed_deferred);
-   return;
-   }
-#endif
-   static_key_slow_dec(_needed);
+   atomic_inc(_needed_deferred);
+   schedule_work(_work);
 }
 EXPORT_SYMBOL(net_disable_timestamp);
 

Re: [PATCH] net: phy: dp83867: Port mirroring support in the DP83867 TI's PHY driver

[Andrew Lunn]

> What a poorly chosen name though... in Ethernet world, port mirroring
> means the ability to capture traffic from a vector of ports and copying
> it verbatim (or sampled) towards a capture port, aka the mirror port...

Ack. We should avoid "port mirroring" in what ever patch we decide upon.

 Andrew

Re: [PATCH] net: phy: dp83867: Port mirroring support in the DP83867 TI's PHY driver

[Andrew Lunn]

> We would need a tri-state device tree properly:
> 
> 1. Not defined - do nothing
> 2. Defined as 0 -> explicitly disable port mirroring
> 3. Defined as 1 -> explicitly enable port mirriring
> 
> The "net-phy-lane-swap" only fulfills points 1 and 3 above.
> 
> In my use case I do need point 2.

Looking at the datasheet, PORT_MIRROR_EN defaults to 0. So it seems
reasonable to unconditionally set it to 0 when the PHY driver
loads. Any device which needs a value of 1 can set "net-phy-lane-swap"

   Andrew

Re: [PATCH] net: phy: dp83867: Port mirroring support in the DP83867 TI's PHY driver

[Florian Fainelli]

On 02/01/2017 01:05 PM, Lukasz Majewski wrote:
> Dear All,
> 
> Thanks for prompt reply.
> 
>> On 02/01/2017 09:16 AM, Andrew Lunn wrote:
>>> On Wed, Feb 01, 2017 at 03:43:35PM +0100, Lukasz Majewski wrote:
 This patch adds support for enabling or disabling the port
 mirroring feature of the DP83867 TI's PHY device.

 One use case is when bootstrap configuration enables this feature
 (because of e.g. LED wiring) so then one needs to disable it in
 software (u-boot/Linux).
>>>
>>> Hi Lukasz
>>>
>>> How does this differ from "enet-phy-lane-swap"?
>>
>> Same here, I am confused about what port mirroring could be meaning
>> here
> 
> The "net-phy-lane-swap" when defined indicates that the "lane swap"
> needs to be enabled. This is a simple bool variable. In my case it
> would mean: "please enable port mirroring -> write 1 to CFG4 register's
> PORT_MIRROR_EN field"
> 
> My use case is unfortunately different:
> 
> - Due to HW design - during the bootstrap PHY phase - the PHY enables
>   "port mirroring", which is incorrect. 
> 
> Then, in SW I do need to explicitly disable port mirroring (write 0 to
> PORT_MIRROR_EN field in CFG4 register). 

You did not really explain whether port mirroring meant the same thing
as swapping the PHY lanes or not, but based on your paragraph later on,
it does sound like this is the case.

What a poorly chosen name though... in Ethernet world, port mirroring
means the ability to capture traffic from a vector of ports and copying
it verbatim (or sampled) towards a capture port, aka the mirror port...

> 
> 
>> and if we can find a better way to describe what is being added.
>> Thanks!
> 
> We would need a tri-state device tree properly:
> 
> 1. Not defined - do nothing
> 2. Defined as 0 -> explicitly disable port mirroring
> 3. Defined as 1 -> explicitly enable port mirriring
> 
> The "net-phy-lane-swap" only fulfills points 1 and 3 above.
> 
> In my use case I do need point 2.

You can define another boolean property:

net-phy-lane-no-swap?

-- 
Florian

[PATCH] net: stmmac: Remove wrong message in stmmac_probe_config_dt

[Heiner Kallweit]

I can only imagine that this message ended up there by a copy & paste
mistake. The same message appears correctly a few lines later, but
here it doesn't make sense.

Signed-off-by: Heiner Kallweit 
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 460f94f5..5edf23dc 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -371,7 +371,6 @@ stmmac_probe_config_dt(struct platform_device *pdev, const 
char **mac)
} else {
clk_prepare_enable(plat->clk_ptp_ref);
plat->clk_ptp_rate = clk_get_rate(plat->clk_ptp_ref);
-   dev_info(>dev, "No reset control found\n");
}
 
plat->stmmac_rst = devm_reset_control_get(>dev,
-- 
2.11.0

Re: [PATCH] net: phy: dp83867: Port mirroring support in the DP83867 TI's PHY driver

[Lukasz Majewski]

Dear All,

Thanks for prompt reply.

> On 02/01/2017 09:16 AM, Andrew Lunn wrote:
> > On Wed, Feb 01, 2017 at 03:43:35PM +0100, Lukasz Majewski wrote:
> >> This patch adds support for enabling or disabling the port
> >> mirroring feature of the DP83867 TI's PHY device.
> >>
> >> One use case is when bootstrap configuration enables this feature
> >> (because of e.g. LED wiring) so then one needs to disable it in
> >> software (u-boot/Linux).
> > 
> > Hi Lukasz
> > 
> > How does this differ from "enet-phy-lane-swap"?
> 
> Same here, I am confused about what port mirroring could be meaning
> here

The "net-phy-lane-swap" when defined indicates that the "lane swap"
needs to be enabled. This is a simple bool variable. In my case it
would mean: "please enable port mirroring -> write 1 to CFG4 register's
PORT_MIRROR_EN field"

My use case is unfortunately different:

- Due to HW design - during the bootstrap PHY phase - the PHY enables
  "port mirroring", which is incorrect. 

Then, in SW I do need to explicitly disable port mirroring (write 0 to
PORT_MIRROR_EN field in CFG4 register). 


> and if we can find a better way to describe what is being added.
> Thanks!

We would need a tri-state device tree properly:

1. Not defined - do nothing
2. Defined as 0 -> explicitly disable port mirroring
3. Defined as 1 -> explicitly enable port mirriring

The "net-phy-lane-swap" only fulfills points 1 and 3 above.

In my use case I do need point 2.

Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de

[PATCH] net: stmmac: add separate warning for PTP not being supported by HW

[Heiner Kallweit]

Chips like Amlogic S905GXBB are supported by this driver but don't
have support for PTP. Add a separate warning for missing HW support
to differentiate it from other actual failures.

Signed-off-by: Heiner Kallweit 
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 26a2185f..bd83bf9e 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1726,8 +1726,10 @@ static int stmmac_hw_setup(struct net_device *dev, bool 
init_ptp)
 
if (init_ptp) {
ret = stmmac_init_ptp(priv);
-   if (ret)
-   netdev_warn(priv->dev, "fail to init PTP.\n");
+   if (ret == -EOPNOTSUPP)
+   netdev_warn(priv->dev, "PTP not supported by HW\n");
+   else if (ret)
+   netdev_warn(priv->dev, "PTP init failed\n");
}
 
 #ifdef CONFIG_DEBUG_FS
-- 
2.11.0

[PATCH net-next] loopback: clear pfmemalloc on outgoing skb's

[Josef Bacik]

I was seeing random disconnects while testing NBD over loopback.  This turned
out to be because NBD sets pfmemalloc on it's socket, however the receiving side
is a user space application so does not have pfmemalloc set on its socket.  This
means that sk_filter_trim_cap will simply drop this packet, under the assumption
that the other side will simply retransmit.  Well we do retransmit, and then the
packet is just dropped again for the same reason.  To keep this from happening
simply clear skb->pfmemalloc on transmit so that we don't drop the packet on the
receive side.

Signed-off-by: Josef Bacik 
---
 drivers/net/loopback.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/net/loopback.c b/drivers/net/loopback.c
index 1e05b7c..13c9126 100644
--- a/drivers/net/loopback.c
+++ b/drivers/net/loopback.c
@@ -81,6 +81,13 @@ static netdev_tx_t loopback_xmit(struct sk_buff *skb,
 */
skb_dst_force(skb);
 
+   /* If our transmitter was a pfmemalloc socket we need to clear
+* pfmemalloc here, otherwise the receiving socket may not be
+* pfmemalloc, and if this is a tcp packet then it'll get dropped and
+* all traffic will halt.
+*/
+   skb->pfmemalloc = false;
+
skb->protocol = eth_type_trans(skb, dev);
 
/* it's OK to use per_cpu_ptr() because BHs are off */
-- 
2.7.4

Re: [PATCH] stmmac: Discard masked flags in interrupt status register

[David Miller]

From: Alexey Brodkin 
Date: Wed, 1 Feb 2017 20:22:22 +

> May we have that one back-ported to stable branches starting from 4.8.x?
> 
> That issue started to appear due to a change from pr_debug() to pr_info() in 
> commit
> 70523e639bf8 ("drivers: net: stmmac: reworking the PCS code.").

Sure, queued up for -stable.

Thanks.

Re: net: suspicious RCU usage in nf_hook

[Cong Wang]

On Tue, Jan 31, 2017 at 7:44 AM, Eric Dumazet  wrote:
> On Mon, 2017-01-30 at 22:19 -0800, Cong Wang wrote:
>
>>
>> The context is process context (TX path before hitting qdisc), and
>> BH is not disabled, so in_interrupt() doesn't catch it. Hmm, this
>> makes me thinking maybe we really need to disable BH in this
>> case for nf_hook()? But it is called in RX path too, and BH is
>> already disabled there.
>
> ipt_do_table() and similar netfilter entry points disable BH.
>
> Maybe it is done too late.

I think we need a fix like the following one for minimum impact.

diff --git a/net/core/dev.c b/net/core/dev.c
index 727b6fd..eee7d63 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1720,12 +1720,10 @@ EXPORT_SYMBOL(net_enable_timestamp);
 void net_disable_timestamp(void)
 {
 #ifdef HAVE_JUMP_LABEL
-   if (in_interrupt()) {
-   atomic_inc(_needed_deferred);
-   return;
-   }
-#endif
+   atomic_inc(_needed_deferred);
+#else
static_key_slow_dec(_needed);
+#endif
 }
 EXPORT_SYMBOL(net_disable_timestamp);

RE: [PATCH] stmmac: Discard masked flags in interrupt status register

[Alexey Brodkin]

Hi David, all,

> -Original Message-
> From: David Miller [mailto:da...@davemloft.net]
> Sent: Monday, January 30, 2017 2:16 AM
> To: alexey.brod...@synopsys.com
> Cc: netdev@vger.kernel.org; linux-ker...@vger.kernel.org;
> peppe.cavall...@st.com; fabrice.gasn...@st.com; manab...@gmail.com;
> pr...@electromag.com.au; alexandre.tor...@gmail.com;
> vineet.gup...@synopsys.com
> Subject: Re: [PATCH] stmmac: Discard masked flags in interrupt status
> register
> 
> From: Alexey Brodkin 
> Date: Fri, 27 Jan 2017 15:24:43 +0300
> 
> > DW GMAC databook says the following about bits in "Register 15
> > (Interrupt Mask Register)":
> > --->8-
> > When set, this bit __disables_the_assertion_of_the_interrupt_signal__
> > because of the setting of XXX bit in Register 14 (Interrupt Status
> > Register).
> > --->8-
> >
> > In fact even if we mask one bit in the mask register it doesn't
> > prevent corresponding bit to appear in the status register, it only
> > disables interrupt generation for corresponding event.
> >
> > But currently we expect a bit different behavior: status bits to be in
> > sync with their masks, i.e. if mask for bit A is set in the mask
> > register then bit A won't appear in the interrupt status register.
> >
> > This was proven to be incorrect assumption, see discussion here [1].
> > That misunderstanding causes unexpected behaviour of the GMAC, for
> > example we were happy enough to just see bogus messages about link
> > state changes.
> >
> > So from now on we'll be only checking bits that really may trigger an
> > interrupt.
> >
> > [1] https://lkml.org/lkml/2016/11/3/413
> >
> > Signed-off-by: Alexey Brodkin 
> 
> This looks good, applied, thanks.

May we have that one back-ported to stable branches starting from 4.8.x?

That issue started to appear due to a change from pr_debug() to pr_info() in 
commit
70523e639bf8 ("drivers: net: stmmac: reworking the PCS code.").

-Alexey

[GIT] Networking

[David Miller]

1) Fix handling of interrupt status in stmmac driver.  Just because we have
   masked the event from generating interrupts, doesn't mean the bit won't
   still be set in the interrupt status register.  From Alexey Brodkin.

2) Fix DMA API debugging splats in gianfar driver, from Arseny Solokha.

3) Fix off-by-one error in __ip6_append_data(), from Vlad Yasevich.

4) cls_flow does not match on icmpv6 codes properly, from Simon Horman.

5) Initial MAC address can be set incorrectly in some scenerios, from
   Ivan Vecera.

6) Packet header pointer arithmetic fix in ip6_tnl_parse_tlv_end_lim(),
   from Dan Carpenter.

7) Fix divide by zero in __tcp_select_window(), from Eric Dumazet.

8) Fix crash in iwlwifi when unregistering thermal zone, from Jens
   Axboe.

9) Check for DMA mapping errors in starfire driver, from Alexey
   Khoroshilov.

Please pull, thanks a lot!

The following changes since commit 1b1bc42c1692e9b62756323c675a44cb1a1f9dbd:

  Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2017-01-27 
12:54:16 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git 

for you to fetch changes up to 06425c308b92eaf60767bc71d359f4cbc7a561f8:

  tcp: fix 0 divide in __tcp_select_window() (2017-02-01 12:55:42 -0500)


Alexey Brodkin (1):
  stmmac: Discard masked flags in interrupt status register

Alexey Khoroshilov (1):
  net: adaptec: starfire: add checks for dma mapping errors

Arseny Solokha (1):
  gianfar: synchronize DMA API usage by free_skb_rx_queue w/ gfar_new_page

Dan Carpenter (1):
  ipv6: pointer math error in ip6_tnl_parse_tlv_enc_lim()

David S. Miller (3):
  Merge tag 'wireless-drivers-for-davem-2017-01-29' of 
git://git.kernel.org/.../kvalo/wireless-drivers
  Merge tag 'mlx5-fixes-2017-01-27' of git://git.kernel.org/.../saeed/linux
  Merge tag 'linux-can-fixes-for-4.10-20170130' of 
git://git.kernel.org/.../mkl/linux-can

Dimitris Michailidis (2):
  ipv6: fix flow labels when the traffic class is non-0
  net: fix ndo_features_check/ndo_fix_features comment ordering

Eric Dumazet (2):
  can: Fix kernel panic at security_sock_rcv_skb
  tcp: fix 0 divide in __tcp_select_window()

Gal Pressman (2):
  net/mlx5e: Modify TIRs hash only when it's needed
  net/mlx5e: Fix update of hash function/key via ethtool

Hadar Hen Zion (1):
  net/mlx5e: Support TC encapsulation offloads with upper devices

Ivan Vecera (1):
  be2net: fix initial MAC setting

Jack Morgenstein (1):
  net/mlx4_core: Avoid command timeouts during VF driver device shutdown

Jens Axboe (1):
  iwlwifi: fix kernel crash when unregistering thermal zone

Johannes Berg (1):
  iwlwifi: mvm: avoid crash on restart w/o reserved queues

Jürg Billeter (1):
  iwlwifi: fix double hyphen in MODULE_FIRMWARE for 8000

Kalle Valo (2):
  Merge tag 'iwlwifi-for-kalle-2017-01-23' of 
git://git.kernel.org/.../iwlwifi/iwlwifi-fixes
  MAINTAINERS: ath9k-devel is closed

Moshe Shemesh (1):
  net/mlx5e: Check ets capability before ets query FW command

Oliver Hartkopp (1):
  can: bcm: fix hrtimer/tasklet termination in bcm op removal

Or Gerlitz (4):
  net/mlx5: Change ENOTSUPP to EOPNOTSUPP
  net/mlx5: Return EOPNOTSUPP when failing to get steering name-space
  net/mlx5: E-Switch, Err when retrieving steering name-space fails
  net/mlx5: E-Switch, Re-enable RoCE on mode change only after FDB destroy

Pavel Belous (1):
  net: ethtool: add support for 2500BaseT and 5000BaseT link modes

Rafal Ozieblo (1):
  net: macb: Fix 64 bit addressing support for GEM

Rafał Miłecki (1):
  Revert "bcma: init serial console directly from ChipCommon code"

Sean Nyekjaer (1):
  net: phy: micrel: KSZ8795 do not set SUPPORTED_[Asym_]Pause

Simon Horman (1):
  net/sched: cls_flower: Correct matching on ICMPv6 code

Vincent (1):
  net: thunderx: avoid dereferencing xcv when NULL

Vlad Yasevich (1):
  ipv6: Paritially checksum full MTU frames

Yotam Gigi (1):
  net/sched: matchall: Fix configuration race

 MAINTAINERS|   1 -
 drivers/bcma/bcma_private.h|   3 ++
 drivers/bcma/driver_chipcommon.c   |  11 ++
 drivers/bcma/driver_mips.c |   3 ++
 drivers/net/ethernet/adaptec/starfire.c|  45 
++--
 drivers/net/ethernet/cadence/macb.c| 188 
---
 drivers/net/ethernet/cadence/macb.h|  20 +--
 drivers/net/ethernet/cavium/thunder/thunder_xcv.c  |   3 +-
 drivers/net/ethernet/emulex/benet/be_main.c|  33 
+++---
 drivers/net/ethernet/freescale/gianfar.c  

Re: [PATCH] net: phy: broadcom: rehook BCM54612E specific init

[David Miller]

From: Rafał Miłecki 
Date: Tue, 31 Jan 2017 22:54:54 +0100

> From: Rafał Miłecki 
> 
> This extra BCM54612E code in PHY driver isn't really aneg specific. Even
> without it aneg works OK but the problem is no packets pass through PHY.
> 
> Moreover putting this code inside config_aneg callback didn't allow
> resuming PHY correctly. When driver called phy_stop and phy_start it was
> putting PHY machine into RESUMING state. After that machine was
> switching into AN and NOLINK without ever calling phy_start_aneg. This
> prevented this extra setup from being called and PHY didn't work.
> 
> This change has been verified to fix network on BCM47186B0 SoC device
> with BCM54612E.
> 
> Signed-off-by: Rafał Miłecki 

Applied to net-next, thanks.

[PATCH] net: stmmac: don't set tx delay in RGMII_ID and RGMII_TXID mode

[Heiner Kallweit]

As documented in Documentation/devicetree/bindings/net/ethernet.txt,
in RGMII_ID and RGMII_TXID mode the MAC should not add a tx delay.

Signed-off-by: Heiner Kallweit 
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
index 8840a360..9689 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
@@ -177,12 +177,19 @@ static int meson8b_init_prg_eth(struct meson8b_dwmac 
*dwmac)
 {
int ret;
unsigned long clk_rate;
-   u8 tx_dly_val;
+   u8 tx_dly_val = 0;
 
switch (dwmac->phy_mode) {
case PHY_INTERFACE_MODE_RGMII:
-   case PHY_INTERFACE_MODE_RGMII_ID:
case PHY_INTERFACE_MODE_RGMII_RXID:
+   /* TX clock delay in ns = "8ns / 4 * tx_dly_val" (where
+* 8ns are exactly one cycle of the 125MHz RGMII TX clock):
+* 0ns = 0x0, 2ns = 0x1, 4ns = 0x2, 6ns = 0x3
+*/
+   tx_dly_val = dwmac->tx_delay_ns >> 1;
+   /* fall through */
+
+   case PHY_INTERFACE_MODE_RGMII_ID:
case PHY_INTERFACE_MODE_RGMII_TXID:
/* Generate a 25MHz clock for the PHY */
clk_rate = 25 * 1000 * 1000;
@@ -195,11 +202,6 @@ static int meson8b_init_prg_eth(struct meson8b_dwmac 
*dwmac)
meson8b_dwmac_mask_bits(dwmac, PRG_ETH0,
PRG_ETH0_INVERTED_RMII_CLK, 0);
 
-   /* TX clock delay in ns = "8ns / 4 * tx_dly_val" (where
-* 8ns are exactly one cycle of the 125MHz RGMII TX clock):
-* 0ns = 0x0, 2ns = 0x1, 4ns = 0x2, 6ns = 0x3
-*/
-   tx_dly_val = dwmac->tx_delay_ns >> 1;
meson8b_dwmac_mask_bits(dwmac, PRG_ETH0, PRG_ETH0_TXDLY_MASK,
tx_dly_val << PRG_ETH0_TXDLY_SHIFT);
break;
-- 
2.11.0

Re: [PATCH net-next 0/5] bridge: per vlan dst_metadata support

[Roopa Prabhu]

On 2/1/17, 8:35 AM, Stephen Hemminger wrote:
> On Tue, 31 Jan 2017 12:43:19 -0800
> Roopa Prabhu  wrote:
>
>> On 1/31/17, 8:41 AM, Stephen Hemminger wrote:

[snip]

>> But, this is just discouraging people from using the bridge driver. sorry, 
>> but i think it is a bit too late for that now :) 
> It is time for a new driver (like team was for bonding). That does less in 
> the kernel,
> and has a cleaner API for extension. Then the actual bridge forwarding path 
> can be reduced
> down to something more manageable. 
sure. But, this patch series is an incremental extension to the already 
existing vlan filtering feature
in the bridge driver.

>> A few things:
>> - Like I have said before, bridge driver vlan filtering and forwarding 
>> database has been
>> ideal to offload to switch asics. We have many industry standard bridging
>> networking features deployed using the bridge driver...even the vxlan 
>> bridging gateway
>> I mention in the deployment section above (this patch series just helps with 
>> scaling those deployments).
>> When bridge driver has all it takes to be deployed on a data center switch 
>> today, I am not understanding
>> the argument on saving it from newer features. why not enable bridge for 
>> newer features when people are using it ?
>>
>> - vlan to tunnel-id (or vlan to vxlan id) mapping is not a hack. It is 
>> supported on every data center switch
>> that supports l2 gateway functions today (google will give a few hits).
>>
>> - dst_metadata propagation is also not a hack. It is a generic 
>> infrastructure provided by the kernel
>> that any subsystem can use...and is already in use in various parts in the 
>> kernel today.
>>
>> - We heavily use bridge driver forwarding database for our l2 deployments 
>> similar to the routing fib.
>> With routing protocols like bgp being used as control plane for l2 overlays
>>  https://tools.ietf.org/html/draft-ietf-bess-evpn-overlay-07, bgp 
>> implementations like quagga will also
>> now start looking at the bridge forwarding database.
>>
>> - this patchset enables a feature which is off by default, so i am not sure 
>> how it is adding additional
>> complexity to the bridge driver.
> The Openstack and Docker architectures have lots of small bridges. These are 
> really endpoint vswitches
> having something lighter would help them.

the feature in this series is disabled by default and is an extension to the 
existing vlan filtering code.
It is only enabled if CONFIG_BRIDGE_VLAN_FILTERING is enabled. If you did like 
me to add an additional
CONFIG_*, I can do so.

Openstack and Docker architectures don't have to enable vlan filtering,  it is 
disabled by default.
seems like we need a new bridge driver that is lighter for these 
architecturesbecause the current
one already supports vlan filtering and stp and igmp snooping for data center 
architectures.
shutting the bridge driver for any incremental features for the data center 
would need more reasons
 than this.
>
> I admit my bias. like Radia Perlman, it seems people keep reinventing L2 
> features to implement features
> that belong in L3. Coddling along old broken applications that run on L2.
>
>
l2 overlays are not uncommon in data center deployments ...and its not us who 
is re-inventing this.
As you know we would love to move the industry and data center architectures to 
pure l3...,
but it is not time for that yet.

thanks,
Roopa

Re: [PATCH net] net: phy: Fix lack of reference count on PHY driver

[Russell King - ARM Linux]

On Wed, Feb 01, 2017 at 01:59:38PM -0500, David Miller wrote:
> From: Florian Fainelli 
> Date: Wed, 1 Feb 2017 10:55:46 -0800
> 
> > You are right, but there is still a fundamental problem IMHO in that you
> > should not be able to rmmod a PHY driver as long as a network device is
> > attached to the PHY, and if the PHY driver is attached from several
> > different network devices, they should all have a way to prevent a PHY
> > driver rmmod, each of them incrementing the driver refcount, which is
> > what the patche from Maowan does here.
> 
> It briefly occurred to me that we might want to be able to disconnect
> PHYs to allow an unload using notifiers, the same way that when you
> take a netdevice down we emit notifiers so that all of the references
> to the netdevice can release themselves.
> 
> I have no idea how well that would work, or whether it is valuable or
> not.  But it is another way to handle this.
> 
> But that is a longer-term thing even if we want to go that way, and
> thus grabbing the proper refs is the right things to do for now.

It's something I'm effectively already doing as part of my phylink
project for SFP support, since you can hot-unplug a copper SFP
module, and the PHY on the copper SFP module will be gone.  phylink,
however, sits between the network driver and phylib, which isn't
ideal.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH net-next 0/2] net/sched: act_sample: Little fixes

[David Miller]

From: Yotam Gigi 
Date: Tue, 31 Jan 2017 11:33:52 +0200

> Little fixes in sample tc action.

Series applied, thanks.

Re: [PATCH 4.10-rc3 11/13] net: liquidio: fix build errors when linux/phy*.h is removed from net/dsa.h

[Felix Manlunas]

Russell King  wrote on Tue [2017-Jan-31 19:19:19 
+]:
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:30: error: expected 
> declaration specifiers or '...' before string constant
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:30: warning: data 
> definition has no type or storage class
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:30: error: type defaults 
> to 'int' in declaration of 'MODULE_AUTHOR'
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:30: error: function 
> declaration isn't a prototype
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:31: error: expected 
> declaration specifiers or '...' before string constant
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:31: warning: data 
> definition has no type or storage class
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:31: error: type defaults 
> to 'int' in declaration of 'MODULE_DESCRIPTION'
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:31: error: function 
> declaration isn't a prototype
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:32: error: expected 
> declaration specifiers or '...' before string constant
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:32: warning: data 
> definition has no type or storage class
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:32: error: type defaults 
> to 'int' in declaration of 'MODULE_LICENSE'
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:32: error: function 
> declaration isn't a prototype
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:33: error: expected 
> declaration specifiers or '...' before string constant
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:33: warning: data 
> definition has no type or storage class
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:33: error: type defaults 
> to 'int' in declaration of 'MODULE_VERSION'
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:33: error: function 
> declaration isn't a prototype
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:36: error: expected ')' 
> before 'int'
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:37: error: expected ')' 
> before string constant
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:325: warning: data 
> definition has no type or storage class
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:325: error: type defaults 
> to 'int' in declaration of 'MODULE_DEVICE_TABLE'
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:325: warning: parameter 
> names (without types) in function declaration
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:3250: warning: data 
> definition has no type or storage class
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:3250: error: type defaults 
> to 'int' in declaration of 'module_init'
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:3250: warning: parameter 
> names (without types) in function declaration
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:3251: warning: data 
> definition has no type or storage class
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:3251: error: type defaults 
> to 'int' in declaration of 'module_exit'
> drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:3251: warning: parameter 
> names (without types) in function declaration
> drivers/net/ethernet/cavium/liquidio/lio_main.c:36: error: expected 
> declaration specifiers or '...' before string constant
> drivers/net/ethernet/cavium/liquidio/lio_main.c:36: warning: data definition 
> has no type or storage class
> drivers/net/ethernet/cavium/liquidio/lio_main.c:36: error: type defaults to 
> 'int' in declaration of 'MODULE_AUTHOR'
> drivers/net/ethernet/cavium/liquidio/lio_main.c:36: error: function 
> declaration isn't a prototype
> drivers/net/ethernet/cavium/liquidio/lio_main.c:37: error: expected 
> declaration specifiers or '...' before string constant
> drivers/net/ethernet/cavium/liquidio/lio_main.c:37: warning: data definition 
> has no type or storage class
> drivers/net/ethernet/cavium/liquidio/lio_main.c:37: error: type defaults to 
> 'int' in declaration of 'MODULE_DESCRIPTION'
> drivers/net/ethernet/cavium/liquidio/lio_main.c:37: error: function 
> declaration isn't a prototype
> drivers/net/ethernet/cavium/liquidio/lio_main.c:38: error: expected 
> declaration specifiers or '...' before string constant
> drivers/net/ethernet/cavium/liquidio/lio_main.c:38: warning: data definition 
> has no type or storage class
> drivers/net/ethernet/cavium/liquidio/lio_main.c:38: error: type defaults to 
> 'int' in declaration of 'MODULE_LICENSE'
> drivers/net/ethernet/cavium/liquidio/lio_main.c:38: error: function 
> declaration isn't a prototype
> drivers/net/ethernet/cavium/liquidio/lio_main.c:39: error: expected 
> declaration specifiers or '...' before string constant
> drivers/net/ethernet/cavium/liquidio/lio_main.c:39: warning: data definition 
> has no type or storage class
> drivers/net/ethernet/cavium/liquidio/lio_main.c:39: error: type 

Re: [PATCH] net: phy: dp83867: Port mirroring support in the DP83867 TI's PHY driver

[Florian Fainelli]

On 02/01/2017 09:16 AM, Andrew Lunn wrote:
> On Wed, Feb 01, 2017 at 03:43:35PM +0100, Lukasz Majewski wrote:
>> This patch adds support for enabling or disabling the port mirroring
>> feature of the DP83867 TI's PHY device.
>>
>> One use case is when bootstrap configuration enables this feature (because
>> of e.g. LED wiring) so then one needs to disable it in software
>> (u-boot/Linux).
> 
> Hi Lukasz
> 
> How does this differ from "enet-phy-lane-swap"?

Same here, I am confused about what port mirroring could be meaning here
and if we can find a better way to describe what is being added. Thanks!
-- 
Florian

[PATCH net-next] unix: add ioctl to open a unix socket file with O_PATH

[Andrei Vagin]

This ioctl opens a file to which a socket is bound and
returns a file descriptor. The caller has to have CAP_NET_ADMIN
in the socket network namespace.

Currently it is impossible to get a path and a mount point
for a socket file. socket_diag reports address, device ID and inode
number for unix sockets. An address can contain a relative path or
a file may be moved somewhere. And these properties say nothing about
a mount namespace and a mount point of a socket file.

With the introduced ioctl, we can get a path by reading
/proc/self/fd/X and get mnt_id from /proc/self/fdinfo/X.

In CRIU we are going to use this ioctl to dump and restore unix socket.

Here is an example how it can be used:

$ strace -e socket,bind,ioctl ./test /tmp/test_sock
socket(AF_UNIX, SOCK_STREAM, 0) = 3
bind(3, {sa_family=AF_UNIX, sun_path="test_sock"}, 11) = 0
ioctl(3, SIOCUNIXFILE, 0)   = 4
^Z

$ ss -a | grep test_sock
u_str  LISTEN 0  1  test_sock 17798 * 0

$ ls -l /proc/760/fd/{3,4}
lrwx-- 1 root root 64 Feb  1 09:41 3 -> 'socket:[17798]'
l- 1 root root 64 Feb  1 09:41 4 -> /tmp/test_sock

$ cat /proc/760/fdinfo/4
pos:0
flags:  01200
mnt_id: 40

$ cat /proc/self/mountinfo | grep "^40\s"
40 19 0:37 / /tmp rw shared:23 - tmpfs tmpfs rw

Signed-off-by: Andrei Vagin 
---
 include/uapi/linux/un.h |  2 ++
 net/unix/af_unix.c  | 41 +
 2 files changed, 43 insertions(+)

diff --git a/include/uapi/linux/un.h b/include/uapi/linux/un.h
index 3ed3e46..4f0ab3a 100644
--- a/include/uapi/linux/un.h
+++ b/include/uapi/linux/un.h
@@ -10,4 +10,6 @@ struct sockaddr_un {
char sun_path[UNIX_PATH_MAX];   /* pathname */
 };
 
+#define SIOCUNIXFILE (SIOCPROTOPRIVATE + 0) /* open a socket file with O_PATH 
*/
+
 #endif /* _LINUX_UN_H */
diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index cef7987..e2d18b9 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -117,6 +117,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct hlist_head unix_socket_table[2 * UNIX_HASH_SIZE];
 EXPORT_SYMBOL_GPL(unix_socket_table);
@@ -2592,6 +2593,43 @@ long unix_outq_len(struct sock *sk)
 }
 EXPORT_SYMBOL_GPL(unix_outq_len);
 
+static int unix_open_file(struct sock *sk)
+{
+   struct path path;
+   struct file *f;
+   int fd;
+
+   if (!ns_capable(sock_net(sk)->user_ns, CAP_NET_ADMIN))
+   return -EPERM;
+
+   unix_state_lock(sk);
+   path = unix_sk(sk)->path;
+   if (!path.dentry) {
+   unix_state_unlock(sk);
+   return -ENOENT;
+   }
+
+   path_get();
+   unix_state_unlock(sk);
+
+   fd = get_unused_fd_flags(O_CLOEXEC);
+   if (fd < 0)
+   goto out;
+
+   f = dentry_open(, O_PATH, current_cred());
+   if (IS_ERR(f)) {
+   put_unused_fd(fd);
+   fd = PTR_ERR(f);
+   goto out;
+   }
+
+   fd_install(fd, f);
+out:
+   path_put();
+
+   return fd;
+}
+
 static int unix_ioctl(struct socket *sock, unsigned int cmd, unsigned long arg)
 {
struct sock *sk = sock->sk;
@@ -2610,6 +2648,9 @@ static int unix_ioctl(struct socket *sock, unsigned int 
cmd, unsigned long arg)
else
err = put_user(amount, (int __user *)arg);
break;
+   case SIOCUNIXFILE:
+   err = unix_open_file(sk);
+   break;
default:
err = -ENOIOCTLCMD;
break;
-- 
2.7.4

Re: [PATCH net] net: phy: Fix lack of reference count on PHY driver

[David Miller]

From: Florian Fainelli 
Date: Wed, 1 Feb 2017 10:55:46 -0800

> You are right, but there is still a fundamental problem IMHO in that you
> should not be able to rmmod a PHY driver as long as a network device is
> attached to the PHY, and if the PHY driver is attached from several
> different network devices, they should all have a way to prevent a PHY
> driver rmmod, each of them incrementing the driver refcount, which is
> what the patche from Maowan does here.

It briefly occurred to me that we might want to be able to disconnect
PHYs to allow an unload using notifiers, the same way that when you
take a netdevice down we emit notifiers so that all of the references
to the netdevice can release themselves.

I have no idea how well that would work, or whether it is valuable or
not.  But it is another way to handle this.

But that is a longer-term thing even if we want to go that way, and
thus grabbing the proper refs is the right things to do for now.

Re: [PATCH net] net: phy: Fix lack of reference count on PHY driver

[Florian Fainelli]

On 02/01/2017 02:51 AM, Russell King - ARM Linux wrote:
> On Wed, Feb 01, 2017 at 10:22:08AM +, Russell King - ARM Linux wrote:
>> On Tue, Jan 31, 2017 at 06:46:43PM -0800, Florian Fainelli wrote:
>>> From: Mao Wenan 
>>>
>>> There is currently no reference count being held on the PHY driver,
>>> which makes it possible to remove the PHY driver module while the PHY
>>> state machine is running and polling the PHY. This could cause crashes
>>> similar to this one to show up:
>>
>> Does this really solve the problem?  What if you use sysfs to unbind the
>> driver but without removing the module?
> 
> I think that's a problem, and the patch is just solving a symptom of
> it.

You are right, but there is still a fundamental problem IMHO in that you
should not be able to rmmod a PHY driver as long as a network device is
attached to the PHY, and if the PHY driver is attached from several
different network devices, they should all have a way to prevent a PHY
driver rmmod, each of them incrementing the driver refcount, which is
what the patche from Maowan does here.


> 
> If a phy driver is unbound from a device, phy_remove() will be called.
> This will set the state to PHY_DOWN (under the mutex) before calling
> the driver's remove function (if any), and finally setting phydev->drv
> to NULL.
> 
> If phy_state_machine() is called after that point, then:
> 
> void phy_state_machine(struct work_struct *work)
> {
> ...
> if (phydev->drv->link_change_notify)
> phydev->drv->link_change_notify(phydev);
> 
> which happens unconditionally, causes a NULL pointer dereference, which
> is probably the same NULL pointer dereference given in Mao Wenan's patch
> description.

Yep, that's exactly the location, but then after fixing that, we can
still crash in other locations, e.g: if we bring down an interface that
was attached to the PHY we would now crash in phy_suspend ->
phy_ethtool_get_wol

All of that can be fixed, and actually should be fixed, but it still
feels like we should have an easier way to prevent the driver removal IMHO.

> 
> It looks to me as if that's the only case where this can happen, so maybe
> the above needs to be:
> 
> if (phydev->drv && phydev->drv->link_change_notify)
> phydev->drv->link_change_notify(phydev);
> 
> Also, I'd suggest making sure that the workqueue is flushed in
> phy_remove() after setting phydev->drv to NULL to ensure that the
> workqueue isn't running while the phy driver is being unbound, which
> should also make module removal safe(r).  I haven't fully analysed
> that though.

That is reasonable to do as well, thanks!
-- 
Florian

Re: [PATCH] xen-netfront: Improve error handling during initialization

[Boris Ostrovsky]

On 02/01/2017 10:50 AM, Ross Lagerwall wrote:
> Improve error handling during initialization. This fixes a crash when
> running out of grant refs when creating many queues across many netdevs.
>
> * Delay timer creation so that if initializing a queue fails, the timer
> has not been setup yet.
> * If creating queues fails (i.e. there are no grant refs available),
> call xenbus_dev_fatal() to ensure that the xenbus device is set to the
> closed state.
> * If no queues are created, don't call xennet_disconnect_backend as
> netdev->real_num_tx_queues will not have been set correctly.
> * If setup_netfront() fails, ensure that all the queues created are
> cleaned up, not just those that have been set up.
> * If any queues were set up and an error occurs, call
> xennet_destroy_queues() to stop the timer and clean up the napi context.

We need to stop the timer in xennet_disconnect_backend(). I sent a patch
a couple of day ago

https://lists.xenproject.org/archives/html/xen-devel/2017-01/msg03269.html

but was about to resend it with del_timer_sync() moved after
napi_synchronize().



-boris

> * If any fatal error occurs, unregister and destroy the netdev to avoid
> leaving around a half setup network device.
>
> Signed-off-by: Ross Lagerwall 
> ---
>  drivers/net/xen-netfront.c | 39 ++-
>  1 file changed, 18 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> index 8315fe7..8ca85af 100644
> --- a/drivers/net/xen-netfront.c
> +++ b/drivers/net/xen-netfront.c
> @@ -1596,9 +1596,6 @@ static int xennet_init_queue(struct netfront_queue 
> *queue)
>   spin_lock_init(>tx_lock);
>   spin_lock_init(>rx_lock);
>  
> - setup_timer(>rx_refill_timer, rx_refill_timeout,
> - (unsigned long)queue);
> -
>   snprintf(queue->name, sizeof(queue->name), "%s-q%u",
>queue->info->netdev->name, queue->id);
>  
> @@ -1632,6 +1629,9 @@ static int xennet_init_queue(struct netfront_queue 
> *queue)
>   goto exit_free_tx;
>   }
>  
> + setup_timer(>rx_refill_timer, rx_refill_timeout,
> + (unsigned long)queue);
> +
>   return 0;
>  
>   exit_free_tx:
> @@ -1822,27 +1822,23 @@ static int talk_to_netback(struct xenbus_device *dev,
>   xennet_destroy_queues(info);
>  
>   err = xennet_create_queues(info, _queues);
> - if (err < 0)
> - goto destroy_ring;
> + if (err < 0) {
> + xenbus_dev_fatal(dev, err, "creating queues");
> + if (num_queues > 0) {
> + goto destroy_ring;
> + } else {
> + kfree(info->queues);
> + info->queues = NULL;
> + goto out;
> + }
> + }
>  
>   /* Create shared ring, alloc event channel -- for each queue */
>   for (i = 0; i < num_queues; ++i) {
>   queue = >queues[i];
>   err = setup_netfront(dev, queue, feature_split_evtchn);
> - if (err) {
> - /* setup_netfront() will tidy up the current
> -  * queue on error, but we need to clean up
> -  * those already allocated.
> -  */
> - if (i > 0) {
> - rtnl_lock();
> - netif_set_real_num_tx_queues(info->netdev, i);
> - rtnl_unlock();
> - goto destroy_ring;
> - } else {
> - goto out;
> - }
> - }
> + if (err)
> + goto destroy_ring;
>   }
>  
>  again:
> @@ -1932,9 +1928,10 @@ static int talk_to_netback(struct xenbus_device *dev,
>   xenbus_transaction_end(xbt, 1);
>   destroy_ring:
>   xennet_disconnect_backend(info);
> - kfree(info->queues);
> - info->queues = NULL;
> + xennet_destroy_queues(info);
>   out:
> + unregister_netdev(info->netdev);
> + xennet_free_netdev(info->netdev);
>   return err;
>  }
>  

Re: [PATCH 0/2] sh_eth: fixes for MagicPacket handling

[Niklas Söderlund]

On 2017-02-01 12:54:41 -0500, David Miller wrote:
> From: Niklas Söderlund 
> Date: Wed,  1 Feb 2017 15:41:53 +0100
> 
> > This series contain two fixes for MagicPacket handling. It's based on 
> > top of net-next and is tested on Koelsch.
> 
> Series applied, thanks.
> 
> I fixed the "register" --> "registered" thing in the commit message
> for patch #2 when I applied this.

Thanks for applying and thanks for fixing the typo.

> 
> Thanks again.

-- 
Regards,
Niklas Söderlund

Re: [PATCH v2 net-next] net: phy: Add LED mode driver for Microsemi

[Florian Fainelli]

On 02/01/2017 04:53 AM, Raju Lakkaraju wrote:
> From: Raju Lakkaraju 
> 
> LED Mode:
> Microsemi PHY support 2 LEDs (LED[0] and LED[1]) to display different
> status information that can be selected by setting LED mode.

Why is this LED selection done through Device Tree/initial configuration
instead of coming up with a proper LED device registered by the PHY
which allows you to select exactly how you want the modes to wind-up
looking like?

NB: you don't need a cover letter for single patches.

> 
> LED Mode parameter (vsc8531, led-0-mode) and (vsc8531, led-1-mode) get from
> Device Tree.
> 
> Tested on Beaglebone Black with VSC 8531 PHY.
> 
> Change set:
> v0:
> - Initial version of LED driver for Microsemi PHYs.
> v1:
> - Update all review comments given by Andrew.
> - Add new header file "mscc-phy-vsc8531.h" to define DT macros.
> - Add error/range check for DT LED mode input
> v2:
> - Fixed x86_64 build error.
> 
> Signed-off-by: Raju Lakkaraju 
> 
> 
> Raju Lakkaraju (1):
>   net: phy: Add LED mode driver for Microsemi PHYs.
> 
>  .../devicetree/bindings/net/mscc-phy-vsc8531.txt   | 10 +++
>  drivers/net/phy/mscc.c | 85 
> +-
>  include/dt-bindings/net/mscc-phy-vsc8531.h | 29 
>  3 files changed, 123 insertions(+), 1 deletion(-)
>  create mode 100644 include/dt-bindings/net/mscc-phy-vsc8531.h
> 


-- 
Florian

Re: [PATCH v2 net-next] net: phy: Add LED mode driver for Microsemi PHYs.

[Rob Herring]

On Wed, Feb 01, 2017 at 06:23:46PM +0530, Raju Lakkaraju wrote:
> From: Raju Lakkaraju 
> 
> LED Mode:
> Microsemi PHY support 2 LEDs (LED[0] and LED[1]) to display different
> status information that can be selected by setting LED mode.
> 
> LED Mode parameter (vsc8531, led-0-mode) and (vsc8531, led-1-mode) get
> from Device Tree.
> 
> Signed-off-by: Raju Lakkaraju 
> ---
>  .../devicetree/bindings/net/mscc-phy-vsc8531.txt   | 10 +++
>  drivers/net/phy/mscc.c | 85 
> +-
>  include/dt-bindings/net/mscc-phy-vsc8531.h | 29 
>  3 files changed, 123 insertions(+), 1 deletion(-)
>  create mode 100644 include/dt-bindings/net/mscc-phy-vsc8531.h
> 
> diff --git a/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt 
> b/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt
> index bdefefc6..bb7450c 100644
> --- a/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt
> +++ b/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt
> @@ -27,6 +27,14 @@ Optional properties:
> 'vddmac'.
> Default value is 0%.
> Ref: Table:1 - Edge rate change (below).
> +- vsc8531,led-0-mode : LED mode. Specify how the LED[0] should behave.

vsc8531 is not a vendor prefix. I see other properties did this, but 
please don't continue it.

> +   Allowed values are define in
> +   "include/dt-bindings/net/mscc-phy-vsc8531.h".
> +   Default value is 1.
> +- vsc8531,led-1-mode : LED mode. Specify how the LED[1] should behave.

Why not make this an array for LED0 and LED1?

> +   Allowed values are define in
> +   "include/dt-bindings/net/mscc-phy-vsc8531.h".
> +   Default value is 2.
>  
>  Table: 1 - Edge rate change
>  |
> @@ -60,4 +68,6 @@ Example:
>  compatible = "ethernet-phy-id0007.0570";
>  vsc8531,vddmac   = <3300>;
>  vsc8531,edge-slowdown= <7>;
> +vsc8531,led-0-mode   = ;
> +vsc8531,led-1-mode   = ;
>  };

Re: [PATCH net] tcp: fix 0 divide in __tcp_select_window()

[David Miller]

From: Eric Dumazet 
Date: Wed, 01 Feb 2017 08:33:53 -0800

> From: Eric Dumazet 
> 
> syszkaller fuzzer was able to trigger a divide by zero, when
> TCP window scaling is not enabled.
> 
> SO_RCVBUF can be used not only to increase sk_rcvbuf, also
> to decrease it below current receive buffers utilization.
> 
> If mss is negative or 0, just return a zero TCP window.
> 
> Signed-off-by: Eric Dumazet 
> Reported-by: Dmitry Vyukov  
> ---
> No Fixes: tag, this is a day-0 bug.

Applied and queued up for -stable, thanks Eric.

Re: [PATCH 0/2] sh_eth: fixes for MagicPacket handling

[David Miller]

From: Niklas Söderlund 
Date: Wed,  1 Feb 2017 15:41:53 +0100

> This series contain two fixes for MagicPacket handling. It's based on 
> top of net-next and is tested on Koelsch.

Series applied, thanks.

I fixed the "register" --> "registered" thing in the commit message
for patch #2 when I applied this.

Thanks again.

Re: pull-request: wireless-drivers-next 2017-02-01

[David Miller]

From: Kalle Valo 
Date: Wed, 01 Feb 2017 11:37:38 +0200

> here's a pull request to 4.11, more details in the signed tag below.
> 
> I forgot to mention in the tag that this includes one small change to
> include/linux/soc/qcom/smem_state.h which was acked by Andy Gross in
> commit 6c0b2e833f14. It was needed to fix a build problem with wcn36xx
> using the SMD interface.
> 
> Please let me know if you have any problems.

Pulled, thank you.

Re: [patch net-next] ethernet: aquantia: fix dma_mapping_error test

[David Miller]

From: Dan Carpenter 
Date: Wed, 1 Feb 2017 11:52:15 +0300

> dma_mapping_error() returns 1 if there is an error and 0 if not.
> 
> Fixes: 018423e90bee ("net: ethernet: aquantia: Add ring support code")
> Signed-off-by: Dan Carpenter 

Applied, thanks Dan.

Re: [patch net-next] sfc: a couple off by one bugs

[David Miller]

From: Dan Carpenter 
Date: Wed, 1 Feb 2017 11:50:40 +0300

> These checks are off by one.  These are just sanity checks and we don't
> ever pass invalid values for "encap_type" so it's harmless.
> 
> Fixes: 9b4108012517 ("sfc: insert catch-all filters for encapsulated traffic")
> Signed-off-by: Dan Carpenter 

Please respin against net-next and Colin's fix.

Thanks.

RE: sock_create_kern() and network namespace reference counts

[David Laight]

From: Cong Wang
> Sent: 01 February 2017 17:20
> On Tue, Jan 31, 2017 at 9:57 AM, David Laight  wrote:
> > From: Cong Wang
> >> Sent: 31 January 2017 17:38
> >> On Tue, Jan 31, 2017 at 7:41 AM, David Laight  
> >> wrote:
> >> > Commit 26abe1437 changed sock_create_kern() so that it stopped
> >> > holding a reference to the network namespace.
> >> > The rational seemed to be 'to allow to stop it' (presumably 'be 
> >> > deleted').
> >> > Prior to this change some kernel paths used sk_change_net() (etc) to
> >> > change the namespace after the socket was created.
> >> >
> >> > If the socket doesn't hold a reference to the namespace, what actually
> >> > happens when the namespace is deleted?
> >>
> >> Kernel socket should have the same lifetime with the net namespace,
> >> that is, created in net_init and released in net_exit. Think about it, if 
> >> it
> >> really held a refcnt to this netns, how could this netns be teared down?
> >
> > That rather depends on what they are being used for.
> > Consider something like an in kernel ftp client, it doesn't really care
> > about namespaces except in as much as the connections it creates must
> > be inside the correct namespace.
> > The namespace shouldn't be torn down while that connection exists any more
> > than it should be torn down while a user process has an open connection.
> > (Listening sockets are likely to be more of a problem.)
> 
> If you don't care about netns, why not just use init_net which is never
> torn down and make your kernel socket global so that each netns
> can access it too?

If I create the kernel socket in init_net the connections don't work.
In particular a connection to 127.0.0.1 to a process started in
a different namespace (which contains an external ethernet port).

So I care enough about them to have to create sockets in the right one.
I don't care about namespaces being created or deleted.

They do work if I save the net_ns from a 'random' open of the driver
(from a process that happens to be running in the right namespace).

However that just proves the kernel socket need to be in the right
namespace. It isn't a real solution and I can't hold a reference count
on the namespace at all (well I could call sock_create() and hold it
via a user socket).

As a matter of interest, a process can change namespace by doing:
set_ns(open("/var/run/netns/namespace",...),...)
How can it select init_ns ??

David

Re: [patch] ipv6: pointer math error in ip6_tnl_parse_tlv_enc_lim()

[David Miller]

From: Dan Carpenter 
Date: Wed, 1 Feb 2017 11:46:32 +0300

> Casting is a high precedence operation but "off" and "i" are in terms of
> bytes so we need to have some parenthesis here.
> 
> Fixes: fbfa743a9d2a ("ipv6: fix ip6_tnl_parse_tlv_enc_lim()")
> Signed-off-by: Dan Carpenter 

Applied, thanks Dan.

Re: [PATCH net-next] liquidio: fix for iq and droq cnts going negative

[David Miller]

From: Felix Manlunas 
Date: Tue, 31 Jan 2017 13:04:42 -0800

> From: Satanand Burla 
> 
> Flush the mmio writes before releasing spin locks.
> if the maintained counts get too high > 2M force
> writeback of the counts to clear them
> 
> Signed-off-by: Satanand Burla 
> Signed-off-by: Felix Manlunas 
> Signed-off-by: Raghu Vatsavayi 
> Signed-off-by: Derek Chickles 

Applied, thanks.

Re: [net-next 1/8] net/mlx5: Fixed static checker warnings

[David Miller]

From: Saeed Mahameed 
Date: Tue, 31 Jan 2017 22:58:36 +0200

> @@ -487,11 +487,11 @@ static int __parse_cls_flower(struct mlx5e_priv *priv,
>   MLX5_SET(fte_match_set_lyr_2_4, headers_c, cvlan_tag, 
> 1);
>   MLX5_SET(fte_match_set_lyr_2_4, headers_v, cvlan_tag, 
> 1);
>  
> - MLX5_SET(fte_match_set_lyr_2_4, headers_c, first_vid, 
> mask->vlan_id);
> - MLX5_SET(fte_match_set_lyr_2_4, headers_v, first_vid, 
> key->vlan_id);
> + MLX5_SET(fte_match_set_lyr_2_4, headers_c, first_vid, 
> (u16)mask->vlan_id);
> + MLX5_SET(fte_match_set_lyr_2_4, headers_v, first_vid, 
> (u16)key->vlan_id);
 ...
> @@ -67,10 +67,11 @@
>  
>  /* insert a value to a struct */
>  #define MLX5_SET(typ, p, fld, v) do { \
> + typeof(v) _v = v; \
>   BUILD_BUG_ON(__mlx5_st_sz_bits(typ) % 32); \
>   *((__be32 *)(p) + __mlx5_dw_off(typ, fld)) = \
>   cpu_to_be32((be32_to_cpu(*((__be32 *)(p) + __mlx5_dw_off(typ, fld))) & \
> -  (~__mlx5_dw_mask(typ, fld))) | (((v) & __mlx5_mask(typ, 
> fld)) \
> +  (~__mlx5_dw_mask(typ, fld))) | (((_v) & __mlx5_mask(typ, 
> fld)) \
><< __mlx5_dw_bit_off(typ, fld))); \
>  } while (0)

I have to agree with others that this is really crummy.

You're propagating values into a u32 field, which you are explicitly
performing 32-bit endianness conversions upon.

Just use "u32" for a local variable and get rid of all of these casts.

Re: sock_create_kern() and network namespace reference counts

[Cong Wang]

On Tue, Jan 31, 2017 at 9:57 AM, David Laight  wrote:
> From: Cong Wang
>> Sent: 31 January 2017 17:38
>> On Tue, Jan 31, 2017 at 7:41 AM, David Laight  
>> wrote:
>> > Commit 26abe1437 changed sock_create_kern() so that it stopped
>> > holding a reference to the network namespace.
>> > The rational seemed to be 'to allow to stop it' (presumably 'be deleted').
>> > Prior to this change some kernel paths used sk_change_net() (etc) to
>> > change the namespace after the socket was created.
>> >
>> > If the socket doesn't hold a reference to the namespace, what actually
>> > happens when the namespace is deleted?
>>
>> Kernel socket should have the same lifetime with the net namespace,
>> that is, created in net_init and released in net_exit. Think about it, if it
>> really held a refcnt to this netns, how could this netns be teared down?
>
> That rather depends on what they are being used for.
> Consider something like an in kernel ftp client, it doesn't really care
> about namespaces except in as much as the connections it creates must
> be inside the correct namespace.
> The namespace shouldn't be torn down while that connection exists any more
> than it should be torn down while a user process has an open connection.
> (Listening sockets are likely to be more of a problem.)

If you don't care about netns, why not just use init_net which is never
torn down and make your kernel socket global so that each netns
can access it too?

Re: [PATCH] net: phy: dp83867: Port mirroring support in the DP83867 TI's PHY driver

[Andrew Lunn]

On Wed, Feb 01, 2017 at 03:43:35PM +0100, Lukasz Majewski wrote:
> This patch adds support for enabling or disabling the port mirroring
> feature of the DP83867 TI's PHY device.
> 
> One use case is when bootstrap configuration enables this feature (because
> of e.g. LED wiring) so then one needs to disable it in software
> (u-boot/Linux).

Hi Lukasz

How does this differ from "enet-phy-lane-swap"?

Thanks
Andrew

Re: [PATCH net-next 0/2] net/sched: act_sample: Little fixes

[Cong Wang]

On Tue, Jan 31, 2017 at 1:33 AM, Yotam Gigi  wrote:
> Little fixes in sample tc action.
>
> Yotam Gigi (2):
>   net/sched: act_sample: Fix error path in init
>   net/sched: act_psample: Remove unnecessary ASSERT_RTNL
>

Acked-by: Cong Wang 

Thanks!

Re: [PATCH net-next] net: ipv6: add NLM_F_APPEND in notifications when applicable

[David Miller]

From: David Ahern 
Date: Tue, 31 Jan 2017 16:51:37 -0800

> IPv6 does not set the NLM_F_APPEND flag in notifications to signal that
> a NEWROUTE is an append versus a new route or a replaced one. Add the
> flag if the request has it.
> 
> Signed-off-by: David Ahern 
> ---
> sending this one outside of the multipath patch set since it has
> nothing to do with multipath.

Looks good Dave, applied, thank you.

Re: [PATCH] net: fix ndo_features_check/ndo_fix_features comment ordering

[David Miller]

From: Dimitris Michailidis 
Date: Tue, 31 Jan 2017 16:03:13 -0800

> Commit cdba756f5803a2 ("net: move ndo_features_check() close to
> ndo_start_xmit()") inadvertently moved the doc comment for
> .ndo_fix_features instead of .ndo_features_check. Fix the comment
> ordering.
> 
> Fixes: cdba756f5803a2 ("net: move ndo_features_check() close to 
> ndo_start_xmit()")
> Signed-off-by: Dimitris Michailidis 

Applied, thank you.

Re: [PATCH] net: ethernet: ti: cpsw: fix NULL pointer dereference in switch mode

[David Miller]

From: Grygorii Strashko 
Date: Tue, 31 Jan 2017 14:04:04 -0600

> In switch mode on struct cpsw_slave->ndev field will be initialized with
> proper value only for the one cpsw slave port, as result
> cpsw_get_usage_count() will generate "Unable to handle kernel NULL pointer
> dereference" exception when first ethernet interface is opening
> cpsw_ndo_open(). This issue causes boot regression on AM335x EVM and
> reproducible on am57xx-evm (switch mode).
> Fix it by adding additional check for !cpsw->slaves[i].ndev in
> cpsw_get_usage_count().
> 
> Cc: Ivan Khoronzhuk 
> fixes: 03fd01ad0eea ("net: ethernet: ti: cpsw: don't duplicate ndev_running")

Please capitalize "Fixes: " in the future.

> Signed-off-by: Grygorii Strashko 

Applied, thanks.

Re: [PATCH net-next] net: reduce skb_warn_bad_offload() noise

[David Miller]

From: Eric Dumazet 
Date: Tue, 31 Jan 2017 10:20:32 -0800

> From: Eric Dumazet 
> 
> Dmitry reported warnings occurring in __skb_gso_segment() [1]
> 
> All SKB_GSO_DODGY producers can allow user space to feed
> packets that trigger the current check.
> 
> We could prevent them from doing so, rejecting packets, but
> this might add regressions to existing programs.
> 
> It turns out our SKB_GSO_DODGY handlers properly set up checksum
> information that is needed anyway when packets needs to be segmented.
> 
> By checking again skb_needs_check() after skb_mac_gso_segment(),
> we should remove these pesky warnings, at a very minor cost.
> 
> With help from Willem de Bruijn
 ...
> Signed-off-by: Eric Dumazet 
> Reported-by: Dmitry Vyukov  
> Cc: Willem de Bruijn 

Applied, thanks Eric.

RE: [net-next 1/8] net/mlx5: Fixed static checker warnings

[David Laight]

From: Or Gerlitz
> Sent: 01 February 2017 16:40
> On Wed, Feb 1, 2017 at 1:17 PM, David Laight  wrote:
> > From: Saeed Mahameed
> >> Sent: 31 January 2017 20:59
> >> From: Or Gerlitz 
> >>
> >> For some reason, sparse doesn't like using an expression of type (!x)
> >> with a bitwise | and &.  In order to mitigate that, we use a local
> >> variable.
> >>
> >> Since getting a typeof(bitfield) is incorrect, we cast such cases.
> > ...
> >> + MLX5_SET(fte_match_set_lyr_2_4, headers_c, 
> >> first_prio, (u8)mask-
> >vlan_priority);
> >
> > Ugg nasty casts...
> > ...
> >>  #define MLX5_SET(typ, p, fld, v) do { \
> >> + typeof(v) _v = v; \
> > ..
> >
> > Why not just 'unsigned int _v = v;
> 
> Yeah, basically we could have allocate (use) the max size and assign.
> We preferred to allocate the specific instance size and use this, as using t
> he required size is cleaner.

Doesn't make a blind bit of difference.
The value is promoted to 'int' before being used in the expression.
You might as well do the promotion earlier.

David

Re: [PATCH net v2] net/sched: matchall: Fix configuration race

[David Miller]

From: Yotam Gigi 
Date: Tue, 31 Jan 2017 15:14:29 +0200

> In the current version, the matchall internal state is split into two
> structs: cls_matchall_head and cls_matchall_filter. This makes little
> sense, as matchall instance supports only one filter, and there is no
> situation where one exists and the other does not. In addition, that led
> to some races when filter was deleted while packet was processed.
> 
> Unify that two structs into one, thus simplifying the process of matchall
> creation and deletion. As a result, the new, delete and get callbacks have
> a dummy implementation where all the work is done in destroy and change
> callbacks, as was done in cls_cgroup.
> 
> Fixes: bf3994d2ed31 ("net/sched: introduce Match-all classifier")
> Reported-by: Daniel Borkmann 
> Signed-off-by: Yotam Gigi 
> Acked-by: Jiri Pirko 

Applied and queued up for -stable, thanks.

Re: [PATCH] rtnetlink: Handle IFLA_MASTER parameter when processing rtnl_newlink

[David Miller]

From: Theuns Verwoerd 
Date: Tue, 31 Jan 2017 12:23:46 +1300

> Allow a master interface to be specified as one of the parameters when
> creating a new interface via rtnl_newlink.  Previously this would
> require invoking interface creation, waiting for it to complete, and
> then separately binding that new interface to a master.
> 
> In particular, this is used when creating a macvlan child interface for
> VRRP in a VRF configuration, allowing the interface creator to specify
> directly what master interface should be inherited by the child,
> without having to deal with asynchronous complications and potential
> race conditions.
> 
> Signed-off-by: Theuns Verwoerd 

Applied to net-next, thanks.

[PATCH] [net-next] xgene_enet: remove bogus forward declarations

[Arnd Bergmann]

The device match tables for both the xgene_enet driver and its phy driver
have forward declarations that declare an array without a length, leading
to a clang warning when they are not followed by an actual defitinition:

drivers/net/ethernet/apm/xgene/../../../phy/mdio-xgene.h:135:34: warning: 
tentative array definition assumed to have one element
drivers/net/ethernet/apm/xgene/xgene_enet_main.c:33:36: warning: tentative 
array definition assumed to have one element

The declarations for the mdio driver are even in a header file, so they
cause duplicate definitions of the tables for each file that includes
them.

This removes all four forward declarations and moves the actual
definitions up a little, so they are in front of their first user. For
the OF match tables, this means having to remove the #ifdef around them,
and passing the actual structure into of_match_device(). This has no
effect on the generated object code though, as the of_match_device
function has an empty stub that does not evaluate its argument, and
the symbol gets dropped either way.

Fixes: 43b3cf6634a4 ("drivers: net: phy: xgene: Add MDIO driver")
Signed-off-by: Arnd Bergmann 
---
The bug is old, but relatively harmless, so not needed as a fixup for 4.10
---
 drivers/net/ethernet/apm/xgene/xgene_enet_main.c | 50 
 drivers/net/phy/mdio-xgene.c | 50 
 drivers/net/phy/mdio-xgene.h |  4 --
 3 files changed, 48 insertions(+), 56 deletions(-)

diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_main.c 
b/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
index ab43c52723df..d0d0d12b531f 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
@@ -1964,6 +1964,30 @@ static void xgene_enet_napi_add(struct xgene_enet_pdata 
*pdata)
}
 }
 
+#ifdef CONFIG_ACPI
+static const struct acpi_device_id xgene_enet_acpi_match[] = {
+   { "APMC0D05", XGENE_ENET1},
+   { "APMC0D30", XGENE_ENET1},
+   { "APMC0D31", XGENE_ENET1},
+   { "APMC0D3F", XGENE_ENET1},
+   { "APMC0D26", XGENE_ENET2},
+   { "APMC0D25", XGENE_ENET2},
+   { }
+};
+MODULE_DEVICE_TABLE(acpi, xgene_enet_acpi_match);
+#endif
+
+static const struct of_device_id xgene_enet_of_match[] = {
+   {.compatible = "apm,xgene-enet",.data = (void *)XGENE_ENET1},
+   {.compatible = "apm,xgene1-sgenet", .data = (void *)XGENE_ENET1},
+   {.compatible = "apm,xgene1-xgenet", .data = (void *)XGENE_ENET1},
+   {.compatible = "apm,xgene2-sgenet", .data = (void *)XGENE_ENET2},
+   {.compatible = "apm,xgene2-xgenet", .data = (void *)XGENE_ENET2},
+   {},
+};
+
+MODULE_DEVICE_TABLE(of, xgene_enet_of_match);
+
 static int xgene_enet_probe(struct platform_device *pdev)
 {
struct net_device *ndev;
@@ -2110,32 +2134,6 @@ static void xgene_enet_shutdown(struct platform_device 
*pdev)
xgene_enet_remove(pdev);
 }
 
-#ifdef CONFIG_ACPI
-static const struct acpi_device_id xgene_enet_acpi_match[] = {
-   { "APMC0D05", XGENE_ENET1},
-   { "APMC0D30", XGENE_ENET1},
-   { "APMC0D31", XGENE_ENET1},
-   { "APMC0D3F", XGENE_ENET1},
-   { "APMC0D26", XGENE_ENET2},
-   { "APMC0D25", XGENE_ENET2},
-   { }
-};
-MODULE_DEVICE_TABLE(acpi, xgene_enet_acpi_match);
-#endif
-
-#ifdef CONFIG_OF
-static const struct of_device_id xgene_enet_of_match[] = {
-   {.compatible = "apm,xgene-enet",.data = (void *)XGENE_ENET1},
-   {.compatible = "apm,xgene1-sgenet", .data = (void *)XGENE_ENET1},
-   {.compatible = "apm,xgene1-xgenet", .data = (void *)XGENE_ENET1},
-   {.compatible = "apm,xgene2-sgenet", .data = (void *)XGENE_ENET2},
-   {.compatible = "apm,xgene2-xgenet", .data = (void *)XGENE_ENET2},
-   {},
-};
-
-MODULE_DEVICE_TABLE(of, xgene_enet_of_match);
-#endif
-
 static struct platform_driver xgene_enet_driver = {
.driver = {
   .name = "xgene-enet",
diff --git a/drivers/net/phy/mdio-xgene.c b/drivers/net/phy/mdio-xgene.c
index 92af182951be..f095051beb54 100644
--- a/drivers/net/phy/mdio-xgene.c
+++ b/drivers/net/phy/mdio-xgene.c
@@ -311,6 +311,30 @@ static acpi_status acpi_register_phy(acpi_handle handle, 
u32 lvl,
 }
 #endif
 
+static const struct of_device_id xgene_mdio_of_match[] = {
+   {
+   .compatible = "apm,xgene-mdio-rgmii",
+   .data = (void *)XGENE_MDIO_RGMII
+   },
+   {
+   .compatible = "apm,xgene-mdio-xfi",
+   .data = (void *)XGENE_MDIO_XFI
+   },
+   {},
+};
+MODULE_DEVICE_TABLE(of, xgene_mdio_of_match);
+
+#ifdef CONFIG_ACPI
+static const struct acpi_device_id xgene_mdio_acpi_match[] = {
+   { "APMC0D65", XGENE_MDIO_RGMII },
+   { "APMC0D66", XGENE_MDIO_XFI },
+   { }
+};
+
+MODULE_DEVICE_TABLE(acpi, xgene_mdio_acpi_match);
+#endif
+
+
 static int xgene_mdio_probe(struct platform_device *pdev)
 {
struct device 

Re: [PATCH net] tcp: fix 0 divide in __tcp_select_window()

[Neal Cardwell]

On Wed, Feb 1, 2017 at 11:33 AM, Eric Dumazet  wrote:
>
> From: Eric Dumazet 
>
> syszkaller fuzzer was able to trigger a divide by zero, when
> TCP window scaling is not enabled.
>
> SO_RCVBUF can be used not only to increase sk_rcvbuf, also
> to decrease it below current receive buffers utilization.
>
> If mss is negative or 0, just return a zero TCP window.
>
> Signed-off-by: Eric Dumazet 
> Reported-by: Dmitry Vyukov  
> ---

Acked-by: Neal Cardwell 

Thanks, Eric!

neal

Re: [net-next 1/8] net/mlx5: Fixed static checker warnings

[Or Gerlitz]

On Wed, Feb 1, 2017 at 1:17 PM, David Laight  wrote:
> From: Saeed Mahameed
>> Sent: 31 January 2017 20:59
>> From: Or Gerlitz 
>>
>> For some reason, sparse doesn't like using an expression of type (!x)
>> with a bitwise | and &.  In order to mitigate that, we use a local
>> variable.
>>
>> Since getting a typeof(bitfield) is incorrect, we cast such cases.
> ...
>> + MLX5_SET(fte_match_set_lyr_2_4, headers_c, first_prio, 
>> (u8)mask->vlan_priority);
>
> Ugg nasty casts...
> ...
>>  #define MLX5_SET(typ, p, fld, v) do { \
>> + typeof(v) _v = v; \
> ..
>
> Why not just 'unsigned int _v = v;

Yeah, basically we could have allocate (use) the max size and assign.
We preferred to allocate the specific instance size and use this, as using t
he required size is cleaner.

Or.

Re: pull request (net-next): ipsec-next 2017-02-01

[David Miller]

From: Steffen Klassert 
Date: Wed, 1 Feb 2017 09:17:42 +0100

> 1) Some typo fixes, from Alexander Alemayhu.
> 
> 2) Don't acquire state lock in get_mtu functions.
>The only rece against a dead state does not matter.
>From Florian Westphal.
> 
> 3) Remove xfrm4_state_fini, it is unused for more than
>10 years. From Florian Westphal.
> 
> 4) Various rcu usage improvements. From Florian Westphal.
> 
> 5) Properly handle crypto arrors in ah4/ah6.
>From Gilad Ben-Yossef.
> 
> 6) Try to avoid skb linearization in esp4 and esp6.
> 
> 7) The esp trailer is now set up in different places,
>add a helper for this.
> 
> 8) With the upcomming usage of gro_cells in IPsec,
>a gro merged skb can have a secpath. Drop it
>before freeing or reusing the skb.
> 
> 9) Add a xfrm dummy network device for napi. With
>this we can use gro_cells from within xfrm,
>it allows IPsec GRO without impact on the generic
>networking code.
> 
> Please pull or let me know if there are problems.

Looks great, pulled, thanks a lot!