Re: [for-next 07/10] IB/mlx5: Use blue flame register allocator in mlx5_ib

2017-01-07 Thread Leon Romanovsky
On Fri, Jan 06, 2017 at 11:11:31AM -0500, David Miller wrote:
> From: Leon Romanovsky 
> Date: Fri, 6 Jan 2017 08:06:09 +0200
>
> > On Thu, Jan 05, 2017 at 03:07:31PM -0500, David Miller wrote:
> >> From: Eli Cohen 
> >> Date: Thu, 5 Jan 2017 14:03:18 -0600
> >>
> >> > If necessary I can make sure it builds on 32 bits as well.
> >>
> >> Please do.
> >
> > Dave,
> >
> > I'm failing to understand the benefits of building mlx5 on 32 bits, and
> > see only disadvantages:
> >  * It is actual dead code without test coverage.
> >  * It misleads reviewers/customers by seeing code for 32 bits.
> >  * It adds compilation time for 32 bits platforms and "punishes" them
> >for not relevant for them driver.
> >
> > Why do you call removing all that as a "regression"?
>
> We have this thing called "CONFIG_COMPILE_TEST", it has tons of value,
> perhaps you've seen it before?

Thanks David,
I see your point.

> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


signature.asc
Description: PGP signature


[PATCH net 1/2] net: dsa: bcm_sf2: Do not clobber b53_switch_ops

2017-01-07 Thread Florian Fainelli
We make the bcm_sf2 driver override ds->ops which points to
b53_switch_ops since b53_switch_alloc() did the assignent. This is all
well and good until a second b53 switch comes in, and ends up using the
bcm_sf2 operations. Make a proper local copy, substitute the ds->ops
pointer and then override the operations.

Fixes: f458995b9ad8 ("net: dsa: bcm_sf2: Utilize core B53 driver when possible")
Signed-off-by: Florian Fainelli 
---
 drivers/net/dsa/bcm_sf2.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/net/dsa/bcm_sf2.c b/drivers/net/dsa/bcm_sf2.c
index 9ec33b51a0ed..2f9f910c0e40 100644
--- a/drivers/net/dsa/bcm_sf2.c
+++ b/drivers/net/dsa/bcm_sf2.c
@@ -982,6 +982,7 @@ static int bcm_sf2_sw_probe(struct platform_device *pdev)
const char *reg_names[BCM_SF2_REGS_NUM] = BCM_SF2_REGS_NAME;
struct device_node *dn = pdev->dev.of_node;
struct b53_platform_data *pdata;
+   struct dsa_switch_ops *ops;
struct bcm_sf2_priv *priv;
struct b53_device *dev;
struct dsa_switch *ds;
@@ -995,6 +996,10 @@ static int bcm_sf2_sw_probe(struct platform_device *pdev)
if (!priv)
return -ENOMEM;
 
+   ops = devm_kzalloc(>dev, sizeof(*ops), GFP_KERNEL);
+   if (!ops)
+   return -ENOMEM;
+
dev = b53_switch_alloc(>dev, _sf2_io_ops, priv);
if (!dev)
return -ENOMEM;
@@ -1014,6 +1019,8 @@ static int bcm_sf2_sw_probe(struct platform_device *pdev)
ds = dev->ds;
 
/* Override the parts that are non-standard wrt. normal b53 devices */
+   memcpy(ops, ds->ops, sizeof(*ops));
+   ds->ops = ops;
ds->ops->get_tag_protocol = bcm_sf2_sw_get_tag_protocol;
ds->ops->setup = bcm_sf2_sw_setup;
ds->ops->get_phy_flags = bcm_sf2_sw_get_phy_flags;
-- 
2.9.3



[PATCH net 0/2] net: dsa: bcm_sf2: Couple fixes

2017-01-07 Thread Florian Fainelli
Hi David,

Here are a couple of fixes for bcm_sf2, please queue these up for -stable
as well, thank you very much!

Florian Fainelli (2):
  net: dsa: bcm_sf2: Do not clobber b53_switch_ops
  net: dsa: bcm_sf2: Utilize nested MDIO read/write

 drivers/net/dsa/bcm_sf2.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

-- 
2.9.3



[PATCH net 2/2] net: dsa: bcm_sf2: Utilize nested MDIO read/write

2017-01-07 Thread Florian Fainelli
We are implementing a MDIO bus which is behind another one, so use the
nested version of the accessors to get lockdep annotations correct.

Fixes: 461cd1b03e32 ("net: dsa: bcm_sf2: Register our slave MDIO bus")
Signed-off-by: Florian Fainelli 
---
 drivers/net/dsa/bcm_sf2.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/dsa/bcm_sf2.c b/drivers/net/dsa/bcm_sf2.c
index 2f9f910c0e40..2ce7ae97ac91 100644
--- a/drivers/net/dsa/bcm_sf2.c
+++ b/drivers/net/dsa/bcm_sf2.c
@@ -393,7 +393,7 @@ static int bcm_sf2_sw_mdio_read(struct mii_bus *bus, int 
addr, int regnum)
if (addr == BRCM_PSEUDO_PHY_ADDR && priv->indir_phy_mask & BIT(addr))
return bcm_sf2_sw_indir_rw(priv, 1, addr, regnum, 0);
else
-   return mdiobus_read(priv->master_mii_bus, addr, regnum);
+   return mdiobus_read_nested(priv->master_mii_bus, addr, regnum);
 }
 
 static int bcm_sf2_sw_mdio_write(struct mii_bus *bus, int addr, int regnum,
@@ -407,7 +407,7 @@ static int bcm_sf2_sw_mdio_write(struct mii_bus *bus, int 
addr, int regnum,
if (addr == BRCM_PSEUDO_PHY_ADDR && priv->indir_phy_mask & BIT(addr))
bcm_sf2_sw_indir_rw(priv, 0, addr, regnum, val);
else
-   mdiobus_write(priv->master_mii_bus, addr, regnum, val);
+   mdiobus_write_nested(priv->master_mii_bus, addr, regnum, val);
 
return 0;
 }
-- 
2.9.3



Re: [PATCH net-next] net: ipv6: put autoconf routes into per-interface tables

2017-01-07 Thread David Ahern
On 1/6/17 8:30 AM, Lorenzo Colitti wrote:
> This patch adds a per-interface sysctl to have the kernel put
> autoconf routes into different tables. This allows each interface
> to have its own routing table if desired.  Choosing the default
> interface, or using different interfaces at the same time on a
> per-socket or per-packet basis) can be done using policy routing
> mechanisms that use as SO_BINDTODEVICE / IPV6_PKTINFO, mark-based
> routing, or UID-based routing to select specific routing tables.

Why not use the VRF capability then? create a VRF and assign the interface to 
it. End result is the same -- separate tables and the need to use a 
bind-to-device API to hit those routes.


[PATCH net-next] net: ipv4: remove disable of bottom half in inet_rtm_getroute

2017-01-07 Thread David Ahern
Nothing about the route lookup requires bottom half to be disabled.
Remove the local_bh_disable ... local_bh_enable around ip_route_input.
This appears to be a vestige of days gone by as it has been there
since the beginning of git time.

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

diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index f51823dc998b..7144288371cf 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -2631,9 +2631,7 @@ static int inet_rtm_getroute(struct sk_buff *in_skb, 
struct nlmsghdr *nlh)
skb->protocol   = htons(ETH_P_IP);
skb->dev= dev;
skb->mark   = mark;
-   local_bh_disable();
err = ip_route_input(skb, dst, src, rtm->rtm_tos, dev);
-   local_bh_enable();
 
rt = skb_rtable(skb);
if (err == 0 && rt->dst.error)
-- 
2.1.4



Re: [PATCH net-next] net: dsa: move HWMON support to its own file

2017-01-07 Thread David Miller
From: Vivien Didelot 
Date: Fri,  6 Jan 2017 16:42:00 -0500

> Isolate the HWMON support in DSA in its own file. Currently only the
> legacy DSA code is concerned.
> 
> Signed-off-by: Vivien Didelot 

Applied.


Re: [PATCH net] tg3: Fix race condition in tg3_get_stats64().

2017-01-07 Thread David Miller
From: Michael Chan 
Date: Fri,  6 Jan 2017 16:18:53 -0500

> The driver's ndo_get_stats64() method is not always called under RTNL.
> So it can race with driver close or ethtool reconfigurations.  Fix the
> race condition by taking tp->lock spinlock in tg3_free_consistent()
> when freeing the tp->hw_stats memory block.  tg3_get_stats64() is
> already taking tp->lock.
> 
> Reported-by: Wang Yufen 
> Signed-off-by: Michael Chan 

Applied, thanks Michael.


Re: [PATCH net] be2net: fix unicast list filling

2017-01-07 Thread David Miller
From: Ivan Vecera 
Date: Fri,  6 Jan 2017 21:59:30 +0100

> The adapter->pmac_id[0] item is used for primary MAC address but
> this is not true for adapter->uc_list[0] as is assumed in
> be_set_uc_list(). There are N UC addresses copied first from net_device
> to adapter->uc_list[1..N] and then N UC addresses from
> adapter->uc_list[0..N-1] are sent to HW. So the last UC address is never
> stored into HW and address 00:00:00:00;00:00 (from uc_list[0]) is used
> instead.
> 
> Cc: Sathya Perla 
> Cc: Ajit Khaparde 
> Cc: Sriharsha Basavapatna 
> Cc: Somnath Kotur 
> Fixes: b717241 be2net: replace polling with sleeping in the FW completion path
> Signed-off-by: Ivan Vecera 

Applied, thanks.


Re: [net-next v1 0/8] netcp: enhancements and minor fixes

2017-01-07 Thread David Miller
From: Murali Karicheri 
Date: Fri, 6 Jan 2017 15:37:38 -0500

> This series is for net-next. This propagates enhancements and minor
> bug fixes from internal version of the driver to keep the upstream
> in sync. Please review and apply if this looks good.
> 
> Tested on all of K2HK/E/L boards with nfs rootfs.
> Test logs below
> K2HK-EVM: http://pastebin.ubuntu.com/23754106/
> k2L-EVM: http://pastebin.ubuntu.com/23754143/
> K2E-EVM: http://pastebin.ubuntu.com/23754159/
> 
> History:
>   v1 - dropped 1/10 amd 2/10 of v0 based on comments from Rob as
>it needs more work before submission
>   v0 - Initial version

Series applied, thanks.


Re: [PATCH net] net: Fix inconsistent rtnl_lock usage on dev_get_stats().

2017-01-07 Thread David Miller
From: Eric Dumazet 
Date: Fri, 06 Jan 2017 12:13:23 -0800

> Well, there are cases where RTNL is quite contended, but supervisions
> like to get /proc/net/devices or various sysfs attributes
> (netstat_show() can be called very very often
> for /sys/class/net/*/statistics/*) in a reasonable amount of time.
> 
> I fear that such a change will add drifts, when devices are constantly
> added/removed.

It stands to reason that RTNETLINK could use pure RCU locking for
device and stat dumps, and frankly that would make their usage and
overhead superior to poking files over and over.


Re: [PATCH v2 0/7] net: ethernet: ti: cpsw: support placing CPDMA descriptors into DDR

2017-01-07 Thread David Miller
From: Grygorii Strashko 
Date: Fri, 6 Jan 2017 14:07:28 -0600

> This series intended to add support for placing CPDMA descriptors into DDR by
> introducing new module parameter "descs_pool_size" to specify size of 
> descriptor's
> pool. The "descs_pool_size" defines total number of CPDMA
> CPPI descriptors to be used for both ingress/egress packets
> processing. If not specified - the default value 256 will be used
> which will allow to place descriptor's pool into the internal CPPI
> RAM.
> 
> In addition, added ability to re-split CPDMA pool of descriptors between RX 
> and TX
> path via ethtool '-G' command wich will allow to configure and fix number
> of descriptors used by RX and TX path, which, then, will be split between
> RX/TX channels proportionally depending on number of RX/TX channels and
> its weight. 
> 
> This allows significantly to reduce UDP packets drop rate
> for bandwidth >301 Mbits/sec (am57x).  
> 
> Before enabling this feature, the am437x SoC has to be fixed as it's proved
> that it's not working when CPDMA descriptors placed in DDR.
> So, the patch 1 fixes this issue.

Series applied to net-next, thanks.


Re: [PATCH v2 net-next 3/4] secure_seq: use SipHash in place of MD5

2017-01-07 Thread David Miller
From: Eric Biggers 
Date: Sat, 7 Jan 2017 14:09:11 -0800

> Well, except those instructions aren't actually used in these
> places.  Although x86_64 SHA1-NI accelerated SHA-1 is available in
> the Linux crypto API, it seems that in kernel code it remains
> impractical to use these instructions on small amounts of data
> because they use XMM registers, which means the overhead of
> kernel_fpu_begin()/kernel_fpu_end() must be incurred.  Furthermore,
> kernel_fpu_begin() is not allowed in all contexts so there has to be
> a fallback.
> 
> Out of curiosity, is this actually a solvable problem, e.g. by
> making the code using the XMM registers responsible for saving and
> restoring the ones clobbered, or by optimizing
> kernel_fpu_begin()/kernel_fpu_end()?  Or does it in fact remain
> impractical for such instructions to be used for applications like
> this one?

On x86 making the FPU save more tractible in situations like this is
really hard and will make the code significantly more complex.

It's simpler and cheaper on sparc64, and unlike on x86 there aren't
any fundament restrictions on where FPU stuff can be used.  This is
because we don't have "save all the FPU state" instructions and have
to do it all by hand anyways.

However I will note that just like x86, sparc64 doesn't override the
md5_transform() in lib/md5.c like it should.


Re: [PATCH v5] net: stmmac: fix maxmtu assignment to be within valid range

2017-01-07 Thread Andy Shevchenko
On Sat, Jan 7, 2017 at 11:32 AM, Kweh, Hock Leong
 wrote:
> From: "Kweh, Hock Leong" 
>
> There is no checking valid value of maxmtu when getting it from
> device tree. This resolution added the checking condition to
> ensure the assignment is made within a valid range.

FWIW:
Reviewed-by: Andy Shevchenko 

>
> Signed-off-by: Kweh, Hock Leong 
> ---
> changelog v5:
> * revert back that plat->maxmtu > ndev->max_mtu is a valid case
>   when ndev->max_mtu assignment is entering to the else statement
> * add comment to enchance clarification
>
> changelog v4:
> * add print warning message when maxmtu > max_mtu as well
> * add maxmtu = JUMBO_LEN into each *_default_data() at stmmac_pci.c
>
> changelog v3:
> * print the warning message only if maxmtu < min_mtu
> * add maxmtu = JUMBO_LEN at stmmac_pci.c to follow stmmac_platform.c
>
> changelog v2:
> * correction of "devicetree" to "device tree" reported by Andy
> * print warning message while maxmtu is not in valid range
>
>  drivers/net/ethernet/stmicro/stmmac/stmmac_main.c |   10 +-
>  drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c  |6 ++
>  2 files changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
> b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index 92ac006..8e56dc4 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -3345,8 +3345,16 @@ int stmmac_dvr_probe(struct device *device,
> ndev->max_mtu = JUMBO_LEN;
> else
> ndev->max_mtu = SKB_MAX_HEAD(NET_SKB_PAD + NET_IP_ALIGN);
> -   if (priv->plat->maxmtu < ndev->max_mtu)
> +   /* Will not overwrite ndev->max_mtu if plat->maxmtu > ndev->max_mtu
> +* as well as plat->maxmtu < ndev->min_mtu which is a invalid range.
> +*/
> +   if ((priv->plat->maxmtu < ndev->max_mtu) &&
> +   (priv->plat->maxmtu >= ndev->min_mtu))
> ndev->max_mtu = priv->plat->maxmtu;
> +   else if (priv->plat->maxmtu < ndev->min_mtu)
> +   netdev_warn(priv->dev,
> +   "%s: warning: maxmtu having invalid value (%d)\n",
> +   __func__, priv->plat->maxmtu);
>
> if (flow_ctrl)
> priv->flow_ctrl = FLOW_AUTO;/* RX/TX pause on */
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c 
> b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
> index a283177..3da4737 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
> @@ -89,6 +89,9 @@ static void stmmac_default_data(struct plat_stmmacenet_data 
> *plat)
>
> /* Set default value for unicast filter entries */
> plat->unicast_filter_entries = 1;
> +
> +   /* Set the maxmtu to a default of JUMBO_LEN */
> +   plat->maxmtu = JUMBO_LEN;
>  }
>
>  static int quark_default_data(struct plat_stmmacenet_data *plat,
> @@ -126,6 +129,9 @@ static int quark_default_data(struct plat_stmmacenet_data 
> *plat,
> /* Set default value for unicast filter entries */
> plat->unicast_filter_entries = 1;
>
> +   /* Set the maxmtu to a default of JUMBO_LEN */
> +   plat->maxmtu = JUMBO_LEN;
> +
> return 0;
>  }
>
> --
> 1.7.9.5
>



-- 
With Best Regards,
Andy Shevchenko


[PATCH net] ipv6: fix typos

2017-01-07 Thread Alexander Alemayhu
o s/approriate/appropriate
o s/discouvery/discovery

Signed-off-by: Alexander Alemayhu 
---
 net/ipv6/route.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 8417c41d8ec8..ce5aaf448c54 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -1464,7 +1464,7 @@ static struct rt6_info *__ip6_route_redirect(struct net 
*net,
struct fib6_node *fn;
 
/* Get the "current" route for this destination and
-* check if the redirect has come from approriate router.
+* check if the redirect has come from appropriate router.
 *
 * RFC 4861 specifies that redirects should only be
 * accepted if they come from the nexthop to the target.
@@ -2768,7 +2768,7 @@ static int rt6_mtu_change_route(struct rt6_info *rt, void 
*p_arg)
   old MTU is the lowest MTU in the path, update the route PMTU
   to reflect the increase. In this case if the other nodes' MTU
   also have the lowest MTU, TOO BIG MESSAGE will be lead to
-  PMTU discouvery.
+  PMTU discovery.
 */
if (rt->dst.dev == arg->dev &&
dst_metric_raw(>dst, RTAX_MTU) &&
-- 
2.11.0



Re: [RFC PATCH] intel: Use upper_32_bits and lower_32_bits

2017-01-07 Thread Julia Lawall
On Sat, 7 Jan 2017, Joe Perches wrote:

> Shifting and masking various types can be made a bit
> simpler to read by using the available kernel macros.

It looks much nicer to me, especially in the lower case, where there are
multiple ways to express the same thing.

julia


>
> Signed-off-by: Joe Perches 
> ---
>
> This RFC patch is meant as an example, not necessarily
> to apply, though it does compile to equivalent code.
>
> It does seem a bit simpler for a human to read.
>
> Perhaps this could be automated via a coccinelle script,
> but this was done with grep & sed and some typing.
>
> Treewide, there are many hundred instances of this style code
> that could be converted.
>
> Dunno if it's really worth it though.
>
> Another usage that could be converted is DMA_BIT_MASK(32)
> where it is equivalent to upper_32_bits and lower_32_bits.
>
>  drivers/net/ethernet/intel/e1000/e1000_ethtool.c   |  8 
>  drivers/net/ethernet/intel/e1000/e1000_main.c  |  8 
>  drivers/net/ethernet/intel/e1000e/ethtool.c|  8 
>  drivers/net/ethernet/intel/fm10k/fm10k_common.c|  4 ++--
>  drivers/net/ethernet/intel/fm10k/fm10k_pf.c|  2 +-
>  drivers/net/ethernet/intel/i40e/i40e_common.c  |  4 ++--
>  drivers/net/ethernet/intel/i40e/i40e_ethtool.c |  8 
>  drivers/net/ethernet/intel/i40e/i40e_main.c|  4 ++--
>  drivers/net/ethernet/intel/i40e/i40e_ptp.c | 12 ++--
>  drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c |  9 +
>  drivers/net/ethernet/intel/i40evf/i40evf_main.c|  4 ++--
>  drivers/net/ethernet/intel/igb/igb_main.c  | 10 --
>  drivers/net/ethernet/intel/igb/igb_ptp.c   |  4 ++--
>  drivers/net/ethernet/intel/ixgb/ixgb_main.c| 12 ++--
>  drivers/net/ethernet/intel/ixgbe/ixgbe_common.h|  4 ++--
>  drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c   | 12 ++--
>  drivers/net/ethernet/intel/ixgbe/ixgbe_main.c  | 16 
>  drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c   | 12 ++--
>  drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c  |  4 ++--
>  19 files changed, 72 insertions(+), 73 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/e1000/e1000_ethtool.c 
> b/drivers/net/ethernet/intel/e1000/e1000_ethtool.c
> index 975eeb885ca2..11ad95f34f4f 100644
> --- a/drivers/net/ethernet/intel/e1000/e1000_ethtool.c
> +++ b/drivers/net/ethernet/intel/e1000/e1000_ethtool.c
> @@ -1021,8 +1021,8 @@ static int e1000_setup_desc_rings(struct e1000_adapter 
> *adapter)
>   }
>   txdr->next_to_use = txdr->next_to_clean = 0;
>
> - ew32(TDBAL, ((u64)txdr->dma & 0x));
> - ew32(TDBAH, ((u64)txdr->dma >> 32));
> + ew32(TDBAL, lower_32_bits(txdr->dma));
> + ew32(TDBAH, upper_32_bits(txdr->dma));
>   ew32(TDLEN, txdr->count * sizeof(struct e1000_tx_desc));
>   ew32(TDH, 0);
>   ew32(TDT, 0);
> @@ -1081,8 +1081,8 @@ static int e1000_setup_desc_rings(struct e1000_adapter 
> *adapter)
>
>   rctl = er32(RCTL);
>   ew32(RCTL, rctl & ~E1000_RCTL_EN);
> - ew32(RDBAL, ((u64)rxdr->dma & 0x));
> - ew32(RDBAH, ((u64)rxdr->dma >> 32));
> + ew32(RDBAL, lower_32_bits(rxdr->dma));
> + ew32(RDBAH, upper_32_bits(rxdr->dma));
>   ew32(RDLEN, rxdr->size);
>   ew32(RDH, 0);
>   ew32(RDT, 0);
> diff --git a/drivers/net/ethernet/intel/e1000/e1000_main.c 
> b/drivers/net/ethernet/intel/e1000/e1000_main.c
> index 93fc6c67306b..d222f731f280 100644
> --- a/drivers/net/ethernet/intel/e1000/e1000_main.c
> +++ b/drivers/net/ethernet/intel/e1000/e1000_main.c
> @@ -1614,8 +1614,8 @@ static void e1000_configure_tx(struct e1000_adapter 
> *adapter)
>   tdlen = adapter->tx_ring[0].count *
>   sizeof(struct e1000_tx_desc);
>   ew32(TDLEN, tdlen);
> - ew32(TDBAH, (tdba >> 32));
> - ew32(TDBAL, (tdba & 0xULL));
> + ew32(TDBAH, upper_32_bits(tdba));
> + ew32(TDBAL, lower_32_bits(tdba));
>   ew32(TDT, 0);
>   ew32(TDH, 0);
>   adapter->tx_ring[0].tdh = ((hw->mac_type >= e1000_82543) ?
> @@ -1896,8 +1896,8 @@ static void e1000_configure_rx(struct e1000_adapter 
> *adapter)
>   default:
>   rdba = adapter->rx_ring[0].dma;
>   ew32(RDLEN, rdlen);
> - ew32(RDBAH, (rdba >> 32));
> - ew32(RDBAL, (rdba & 0xULL));
> + ew32(RDBAH, upper_32_bits(rdba));
> + ew32(RDBAL, lower_32_bits(rdba));
>   ew32(RDT, 0);
>   ew32(RDH, 0);
>   adapter->rx_ring[0].rdh = ((hw->mac_type >= e1000_82543) ?
> diff --git a/drivers/net/ethernet/intel/e1000e/ethtool.c 
> b/drivers/net/ethernet/intel/e1000e/ethtool.c
> index 7aff68a4a4df..35304b380eaa 100644
> --- a/drivers/net/ethernet/intel/e1000e/ethtool.c
> +++ b/drivers/net/ethernet/intel/e1000e/ethtool.c

[PATCH] net: intel: e100: use new api ethtool_{get|set}_link_ksettings

2017-01-07 Thread Philippe Reynes
The ethtool api {get|set}_settings is deprecated.
We move this driver to new api {get|set}_link_ksettings.

Signed-off-by: Philippe Reynes 
---
 drivers/net/ethernet/intel/e100.c |   14 --
 1 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/intel/e100.c 
b/drivers/net/ethernet/intel/e100.c
index 25c6dfd..04e9392 100644
--- a/drivers/net/ethernet/intel/e100.c
+++ b/drivers/net/ethernet/intel/e100.c
@@ -2426,19 +2426,21 @@ static int e100_loopback_test(struct nic *nic, enum 
loopback loopback_mode)
 #define E100_82552_LED_ON   0x000F /* LEDTX and LED_RX both on */
 #define E100_82552_LED_OFF  0x000A /* LEDTX and LED_RX both off */
 
-static int e100_get_settings(struct net_device *netdev, struct ethtool_cmd 
*cmd)
+static int e100_get_link_ksettings(struct net_device *netdev,
+  struct ethtool_link_ksettings *cmd)
 {
struct nic *nic = netdev_priv(netdev);
-   return mii_ethtool_gset(>mii, cmd);
+   return mii_ethtool_get_link_ksettings(>mii, cmd);
 }
 
-static int e100_set_settings(struct net_device *netdev, struct ethtool_cmd 
*cmd)
+static int e100_set_link_ksettings(struct net_device *netdev,
+  const struct ethtool_link_ksettings *cmd)
 {
struct nic *nic = netdev_priv(netdev);
int err;
 
mdio_write(netdev, nic->mii.phy_id, MII_BMCR, BMCR_RESET);
-   err = mii_ethtool_sset(>mii, cmd);
+   err = mii_ethtool_set_link_ksettings(>mii, cmd);
e100_exec_cb(nic, NULL, e100_configure);
 
return err;
@@ -2741,8 +2743,6 @@ static void e100_get_strings(struct net_device *netdev, 
u32 stringset, u8 *data)
 }
 
 static const struct ethtool_ops e100_ethtool_ops = {
-   .get_settings   = e100_get_settings,
-   .set_settings   = e100_set_settings,
.get_drvinfo= e100_get_drvinfo,
.get_regs_len   = e100_get_regs_len,
.get_regs   = e100_get_regs,
@@ -2763,6 +2763,8 @@ static void e100_get_strings(struct net_device *netdev, 
u32 stringset, u8 *data)
.get_ethtool_stats  = e100_get_ethtool_stats,
.get_sset_count = e100_get_sset_count,
.get_ts_info= ethtool_op_get_ts_info,
+   .get_link_ksettings = e100_get_link_ksettings,
+   .set_link_ksettings = e100_set_link_ksettings,
 };
 
 static int e100_do_ioctl(struct net_device *netdev, struct ifreq *ifr, int cmd)
-- 
1.7.4.4



Re: [PATCH v2 net-next 3/4] secure_seq: use SipHash in place of MD5

2017-01-07 Thread Eric Biggers
Hi David,

On Sat, Jan 07, 2017 at 04:37:36PM -0500, David Miller wrote:
> From: "Jason A. Donenfeld" 
> Date: Sat,  7 Jan 2017 15:40:56 +0100
> 
> > This gives a clear speed and security improvement. Siphash is both
> > faster and is more solid crypto than the aging MD5.
[snip]
> 
> This and the next patch are a real shame, performance wise, on cpus
> that have single-instruction SHA1 and MD5 implementations.  Sparc64
> has both, and I believe x86_64 can do SHA1 these days.
> 
> It took so long to get those instructions into real silicon, and then
> have software implemented to make use of them as well.
> 
> Who knows when we'll see SipHash widely deployed in any instruction
> set, if at all, right?  And by that time we'll possibly find out that
> "Oh shit, this SipHash thing has flaws!" and we'll need
> DIPPY_DO_DA_HASH and thus be forced back to a software implementation
> again.
> 
> I understand the reasons why these patches are being proposed, I just
> thought I'd mention the issue of cpus that implement secure hash
> algorithm instructions.

Well, except those instructions aren't actually used in these places.  Although
x86_64 SHA1-NI accelerated SHA-1 is available in the Linux crypto API, it seems
that in kernel code it remains impractical to use these instructions on small
amounts of data because they use XMM registers, which means the overhead of
kernel_fpu_begin()/kernel_fpu_end() must be incurred.  Furthermore,
kernel_fpu_begin() is not allowed in all contexts so there has to be a fallback.

Out of curiosity, is this actually a solvable problem, e.g. by making the code
using the XMM registers responsible for saving and restoring the ones clobbered,
or by optimizing kernel_fpu_begin()/kernel_fpu_end()?  Or does it in fact remain
impractical for such instructions to be used for applications like this one?

Eric


[PATCH net-next 3/6] net-tc: extract skip classify bit from tc_verd

2017-01-07 Thread Willem de Bruijn
From: Willem de Bruijn 

Packets sent by the IFB device skip subsequent tc classification.
A single bit governs this state. Move it out of tc_verd in
anticipation of removing that __u16 completely.

The new bitfield tc_skip_classify temporarily uses one bit of a
hole, until tc_verd is removed completely in a follow-up patch.

Remove the bit hole comment. It could be 2, 3, 4 or 5 bits long.
With that many options, little value in documenting it.

Introduce a helper function to deduplicate the logic in the two
sites that check this bit.

The field tc_skip_classify is set only in IFB on skbs cloned in
act_mirred, so original packet sources do not have to clear the
bit when reusing packets (notably, pktgen and octeon).

Signed-off-by: Willem de Bruijn 
---
 drivers/net/ifb.c|  2 +-
 include/linux/skbuff.h   |  5 -
 include/net/sch_generic.h| 11 +++
 include/uapi/linux/pkt_cls.h |  6 --
 net/core/dev.c   | 10 +++---
 net/sched/act_api.c  | 11 ---
 6 files changed, 23 insertions(+), 22 deletions(-)

diff --git a/drivers/net/ifb.c b/drivers/net/ifb.c
index 66c0eeafcb5d..4299ac163376 100644
--- a/drivers/net/ifb.c
+++ b/drivers/net/ifb.c
@@ -81,7 +81,7 @@ static void ifb_ri_tasklet(unsigned long _txp)
u32 from = G_TC_FROM(skb->tc_verd);
 
skb->tc_verd = 0;
-   skb->tc_verd = SET_TC_NCLS(skb->tc_verd);
+   skb->tc_skip_classify = 1;
 
u64_stats_update_begin(>tsync);
txp->tx_packets++;
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index b53c0cfd417e..570f60ec6cb4 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -589,6 +589,7 @@ static inline bool skb_mstamp_after(const struct skb_mstamp 
*t1,
  * @pkt_type: Packet class
  * @fclone: skbuff clone status
  * @ipvs_property: skbuff is owned by ipvs
+ * @tc_skip_classify: do not classify packet. set by IFB device
  * @peeked: this packet has been seen already, so stats have been
  * done for it, don't do them again
  * @nf_trace: netfilter packet trace flag
@@ -749,7 +750,9 @@ struct sk_buff {
 #ifdef CONFIG_NET_SWITCHDEV
__u8offload_fwd_mark:1;
 #endif
-   /* 2, 4 or 5 bit hole */
+#ifdef CONFIG_NET_CLS_ACT
+   __u8tc_skip_classify:1;
+#endif
 
 #ifdef CONFIG_NET_SCHED
__u16   tc_index;   /* traffic control index */
diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h
index 498f81b229a4..857356f2d74b 100644
--- a/include/net/sch_generic.h
+++ b/include/net/sch_generic.h
@@ -418,6 +418,17 @@ static inline bool skb_at_tc_ingress(const struct sk_buff 
*skb)
 #endif
 }
 
+static inline bool skb_skip_tc_classify(struct sk_buff *skb)
+{
+#ifdef CONFIG_NET_CLS_ACT
+   if (skb->tc_skip_classify) {
+   skb->tc_skip_classify = 0;
+   return true;
+   }
+#endif
+   return false;
+}
+
 /* Reset all TX qdiscs greater then index of a device.  */
 static inline void qdisc_reset_all_tx_gt(struct net_device *dev, unsigned int 
i)
 {
diff --git a/include/uapi/linux/pkt_cls.h b/include/uapi/linux/pkt_cls.h
index bba23dbb3ab6..1eed5d7509bc 100644
--- a/include/uapi/linux/pkt_cls.h
+++ b/include/uapi/linux/pkt_cls.h
@@ -22,8 +22,6 @@ bit 6,7: Where this packet was last seen
 1: on the Ingress
 2: on the Egress
 
-bit 8: when set --> Request not to classify on ingress. 
-
  *
  * */
 
@@ -36,10 +34,6 @@ bit 8: when set --> Request not to classify on ingress.
 #define AT_INGRESS 0x1
 #define AT_EGRESS  0x2
 
-#define TC_NCLS  _TC_MAKEMASK1(8)
-#define SET_TC_NCLS(v)   ( TC_NCLS | (v & ~TC_NCLS))
-#define CLR_TC_NCLS(v)   ( v & ~TC_NCLS)
-
 #define S_TC_AT  _TC_MAKE32(12)
 #define M_TC_AT  _TC_MAKEMASK(2,S_TC_AT)
 #define G_TC_AT(x)   _TC_GETVALUE(x,S_TC_AT,M_TC_AT)
diff --git a/net/core/dev.c b/net/core/dev.c
index 56818f7eab2b..e39e35d2e082 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4093,12 +4093,8 @@ static int __netif_receive_skb_core(struct sk_buff *skb, 
bool pfmemalloc)
goto out;
}
 
-#ifdef CONFIG_NET_CLS_ACT
-   if (skb->tc_verd & TC_NCLS) {
-   skb->tc_verd = CLR_TC_NCLS(skb->tc_verd);
-   goto ncls;
-   }
-#endif
+   if (skb_skip_tc_classify(skb))
+   goto skip_classify;
 
if (pfmemalloc)
goto skip_taps;
@@ -4128,8 +4124,8 @@ static int __netif_receive_skb_core(struct sk_buff *skb, 
bool pfmemalloc)
 #endif
 #ifdef CONFIG_NET_CLS_ACT
skb->tc_verd = 0;
-ncls:
 #endif
+skip_classify:
if (pfmemalloc && !skb_pfmemalloc_protocol(skb))
goto drop;
 
diff --git a/net/sched/act_api.c b/net/sched/act_api.c
index 2095c83ce773..f04715a57300 100644
--- a/net/sched/act_api.c
+++ b/net/sched/act_api.c
@@ -426,11 +426,9 @@ 

[PATCH net-next 4/6] net-tc: convert tc_verd to integer bitfields

2017-01-07 Thread Willem de Bruijn
From: Willem de Bruijn 

Extract the remaining two fields from tc_verd and remove the __u16
completely. TC_AT and TC_FROM are converted to equivalent two-bit
integer fields tc_at and tc_from. Where possible, use existing
helper skb_at_tc_ingress when reading tc_at. Introduce helper
skb_reset_tc to clear fields.

Not documenting tc_from and tc_at, because they will be replaced
with single bit fields in follow-on patches.

Signed-off-by: Willem de Bruijn 
---
 drivers/net/ifb.c|  7 +++
 drivers/staging/octeon/ethernet-tx.c |  5 ++---
 include/linux/skbuff.h   |  6 ++
 include/net/sch_generic.h| 10 +-
 include/uapi/linux/pkt_cls.h | 31 ---
 net/core/dev.c   | 10 --
 net/core/pktgen.c|  4 +---
 net/core/skbuff.c|  3 ---
 net/sched/act_ife.c  |  7 +++
 net/sched/act_mirred.c   |  9 -
 net/sched/sch_netem.c|  2 +-
 11 files changed, 29 insertions(+), 65 deletions(-)

diff --git a/drivers/net/ifb.c b/drivers/net/ifb.c
index 4299ac163376..90ad8791bc99 100644
--- a/drivers/net/ifb.c
+++ b/drivers/net/ifb.c
@@ -78,9 +78,9 @@ static void ifb_ri_tasklet(unsigned long _txp)
}
 
while ((skb = __skb_dequeue(>tq)) != NULL) {
-   u32 from = G_TC_FROM(skb->tc_verd);
+   u32 from = skb->tc_from;
 
-   skb->tc_verd = 0;
+   skb_reset_tc(skb);
skb->tc_skip_classify = 1;
 
u64_stats_update_begin(>tsync);
@@ -241,7 +241,6 @@ static void ifb_setup(struct net_device *dev)
 static netdev_tx_t ifb_xmit(struct sk_buff *skb, struct net_device *dev)
 {
struct ifb_dev_private *dp = netdev_priv(dev);
-   u32 from = G_TC_FROM(skb->tc_verd);
struct ifb_q_private *txp = dp->tx_private + skb_get_queue_mapping(skb);
 
u64_stats_update_begin(>rsync);
@@ -249,7 +248,7 @@ static netdev_tx_t ifb_xmit(struct sk_buff *skb, struct 
net_device *dev)
txp->rx_bytes += skb->len;
u64_stats_update_end(>rsync);
 
-   if (!(from & (AT_INGRESS|AT_EGRESS)) || !skb->skb_iif) {
+   if (skb->tc_from == AT_STACK || !skb->skb_iif) {
dev_kfree_skb(skb);
dev->stats.rx_dropped++;
return NETDEV_TX_OK;
diff --git a/drivers/staging/octeon/ethernet-tx.c 
b/drivers/staging/octeon/ethernet-tx.c
index 6b4c20872323..0b8053205091 100644
--- a/drivers/staging/octeon/ethernet-tx.c
+++ b/drivers/staging/octeon/ethernet-tx.c
@@ -23,6 +23,7 @@
 #endif /* CONFIG_XFRM */
 
 #include 
+#include 
 
 #include 
 
@@ -369,9 +370,7 @@ int cvm_oct_xmit(struct sk_buff *skb, struct net_device 
*dev)
 
 #ifdef CONFIG_NET_SCHED
skb->tc_index = 0;
-#ifdef CONFIG_NET_CLS_ACT
-   skb->tc_verd = 0;
-#endif /* CONFIG_NET_CLS_ACT */
+   skb_reset_tc(skb);
 #endif /* CONFIG_NET_SCHED */
 #endif /* REUSE_SKBUFFS_WITHOUT_FREE */
 
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 570f60ec6cb4..f738d09947b2 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -599,7 +599,6 @@ static inline bool skb_mstamp_after(const struct skb_mstamp 
*t1,
  * @nf_bridge: Saved data about a bridged frame - see br_netfilter.c
  * @skb_iif: ifindex of device we arrived on
  * @tc_index: Traffic control index
- * @tc_verd: traffic control verdict
  * @hash: the packet hash
  * @queue_mapping: Queue mapping for multiqueue devices
  * @xmit_more: More SKBs are pending for this queue
@@ -752,13 +751,12 @@ struct sk_buff {
 #endif
 #ifdef CONFIG_NET_CLS_ACT
__u8tc_skip_classify:1;
+   __u8tc_at:2;
+   __u8tc_from:2;
 #endif
 
 #ifdef CONFIG_NET_SCHED
__u16   tc_index;   /* traffic control index */
-#ifdef CONFIG_NET_CLS_ACT
-   __u16   tc_verd;/* traffic control verdict */
-#endif
 #endif
 
union {
diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h
index 857356f2d74b..f80dba516964 100644
--- a/include/net/sch_generic.h
+++ b/include/net/sch_generic.h
@@ -409,10 +409,18 @@ bool tcf_destroy(struct tcf_proto *tp, bool force);
 void tcf_destroy_chain(struct tcf_proto __rcu **fl);
 int skb_do_redirect(struct sk_buff *);
 
+static inline void skb_reset_tc(struct sk_buff *skb)
+{
+#ifdef CONFIG_NET_CLS_ACT
+   skb->tc_at = 0;
+   skb->tc_from = 0;
+#endif
+}
+
 static inline bool skb_at_tc_ingress(const struct sk_buff *skb)
 {
 #ifdef CONFIG_NET_CLS_ACT
-   return G_TC_AT(skb->tc_verd) & AT_INGRESS;
+   return skb->tc_at & AT_INGRESS;
 #else
return false;
 #endif
diff --git a/include/uapi/linux/pkt_cls.h b/include/uapi/linux/pkt_cls.h
index 1eed5d7509bc..cee753a7a40c 100644
--- a/include/uapi/linux/pkt_cls.h
+++ 

[PATCH net-next 5/6] net-tc: convert tc_at to tc_at_ingress

2017-01-07 Thread Willem de Bruijn
From: Willem de Bruijn 

Field tc_at is used only within tc actions to distinguish ingress from
egress processing. A single bit is sufficient for this purpose.

Signed-off-by: Willem de Bruijn 
---
 include/linux/skbuff.h|  3 ++-
 include/net/sch_generic.h |  3 +--
 net/core/dev.c|  8 +++-
 net/sched/act_mirred.c| 12 ++--
 4 files changed, 12 insertions(+), 14 deletions(-)

diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index f738d09947b2..fab3f87e9bd1 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -590,6 +590,7 @@ static inline bool skb_mstamp_after(const struct skb_mstamp 
*t1,
  * @fclone: skbuff clone status
  * @ipvs_property: skbuff is owned by ipvs
  * @tc_skip_classify: do not classify packet. set by IFB device
+ * @tc_at_ingress: used within tc_classify to distinguish in/egress
  * @peeked: this packet has been seen already, so stats have been
  * done for it, don't do them again
  * @nf_trace: netfilter packet trace flag
@@ -751,7 +752,7 @@ struct sk_buff {
 #endif
 #ifdef CONFIG_NET_CLS_ACT
__u8tc_skip_classify:1;
-   __u8tc_at:2;
+   __u8tc_at_ingress:1;
__u8tc_from:2;
 #endif
 
diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h
index f80dba516964..4bd6d5387209 100644
--- a/include/net/sch_generic.h
+++ b/include/net/sch_generic.h
@@ -412,7 +412,6 @@ int skb_do_redirect(struct sk_buff *);
 static inline void skb_reset_tc(struct sk_buff *skb)
 {
 #ifdef CONFIG_NET_CLS_ACT
-   skb->tc_at = 0;
skb->tc_from = 0;
 #endif
 }
@@ -420,7 +419,7 @@ static inline void skb_reset_tc(struct sk_buff *skb)
 static inline bool skb_at_tc_ingress(const struct sk_buff *skb)
 {
 #ifdef CONFIG_NET_CLS_ACT
-   return skb->tc_at & AT_INGRESS;
+   return skb->tc_at_ingress;
 #else
return false;
 #endif
diff --git a/net/core/dev.c b/net/core/dev.c
index 8b5d6d033473..c143f1391117 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3153,9 +3153,7 @@ sch_handle_egress(struct sk_buff *skb, int *ret, struct 
net_device *dev)
if (!cl)
return skb;
 
-   /* skb->tc_at and qdisc_skb_cb(skb)->pkt_len were already set
-* earlier by the caller.
-*/
+   /* qdisc_skb_cb(skb)->pkt_len was already set by the caller. */
qdisc_bstats_cpu_update(cl->q, skb);
 
switch (tc_classify(skb, cl, _res, false)) {
@@ -3320,7 +3318,7 @@ static int __dev_queue_xmit(struct sk_buff *skb, void 
*accel_priv)
 
qdisc_pkt_len_init(skb);
 #ifdef CONFIG_NET_CLS_ACT
-   skb->tc_at = AT_EGRESS;
+   skb->tc_at_ingress = 0;
 # ifdef CONFIG_NET_EGRESS
if (static_key_false(_needed)) {
skb = sch_handle_egress(skb, , dev);
@@ -3920,7 +3918,7 @@ sch_handle_ingress(struct sk_buff *skb, struct 
packet_type **pt_prev, int *ret,
}
 
qdisc_skb_cb(skb)->pkt_len = skb->len;
-   skb->tc_at = AT_INGRESS;
+   skb->tc_at_ingress = 1;
qdisc_bstats_cpu_update(cl->q, skb);
 
switch (tc_classify(skb, cl, _res, false)) {
diff --git a/net/sched/act_mirred.c b/net/sched/act_mirred.c
index 8543279bba49..e832c62fd705 100644
--- a/net/sched/act_mirred.c
+++ b/net/sched/act_mirred.c
@@ -39,15 +39,15 @@ static bool tcf_mirred_is_act_redirect(int action)
return action == TCA_EGRESS_REDIR || action == TCA_INGRESS_REDIR;
 }
 
-static u32 tcf_mirred_act_direction(int action)
+static bool tcf_mirred_act_wants_ingress(int action)
 {
switch (action) {
case TCA_EGRESS_REDIR:
case TCA_EGRESS_MIRROR:
-   return AT_EGRESS;
+   return false;
case TCA_INGRESS_REDIR:
case TCA_INGRESS_MIRROR:
-   return AT_INGRESS;
+   return true;
default:
BUG();
}
@@ -198,7 +198,7 @@ static int tcf_mirred(struct sk_buff *skb, const struct 
tc_action *a,
 * and devices expect a mac header on xmit, then mac push/pull is
 * needed.
 */
-   if (skb->tc_at != tcf_mirred_act_direction(m_eaction) &&
+   if (skb_at_tc_ingress(skb) != tcf_mirred_act_wants_ingress(m_eaction) &&
m_mac_header_xmit) {
if (!skb_at_tc_ingress(skb)) {
/* caught at egress, act ingress: pull mac */
@@ -212,11 +212,11 @@ static int tcf_mirred(struct sk_buff *skb, const struct 
tc_action *a,
 
/* mirror is always swallowed */
if (tcf_mirred_is_act_redirect(m_eaction))
-   skb2->tc_from = skb2->tc_at;
+   skb2->tc_from = skb_at_tc_ingress(skb) ? AT_INGRESS : AT_EGRESS;
 
skb2->skb_iif = skb->dev->ifindex;
skb2->dev = dev;
-   if (tcf_mirred_act_direction(m_eaction) & AT_EGRESS)
+   if (!tcf_mirred_act_wants_ingress(m_eaction))
err = 

[PATCH net-next 6/6] net-tc: convert tc_from to tc_from_ingress and tc_redirected

2017-01-07 Thread Willem de Bruijn
From: Willem de Bruijn 

The tc_from field fulfills two roles. It encodes whether a packet was
redirected by an act_mirred device and, if so, whether act_mirred was
called on ingress or egress. Split it into separate fields.

The information is needed by the special IFB loop, where packets are
taken out of the normal path by act_mirred, forwarded to IFB, then
reinjected at their original location (ingress or egress) by IFB.

The IFB device cannot use skb->tc_at_ingress, because that may have
been overwritten as the packet travels from act_mirred to ifb_xmit,
when it passes through tc_classify on the IFB egress path. Cache this
value in skb->tc_from_ingress.

That field is valid only if a packet arriving at ifb_xmit came from
act_mirred. Other packets can be crafted to reach ifb_xmit. These
must be dropped. Set tc_redirected on redirection and drop all packets
that do not have this bit set.

Both fields are set only on cloned skbs in tc actions, so original
packet sources do not have to clear the bit when reusing packets
(notably, pktgen and octeon).

Signed-off-by: Willem de Bruijn 
---
 drivers/net/ifb.c| 13 +
 include/linux/skbuff.h   |  5 -
 include/net/sch_generic.h|  2 +-
 include/uapi/linux/pkt_cls.h |  6 --
 net/sched/act_mirred.c   |  6 --
 net/sched/sch_netem.c|  2 +-
 6 files changed, 15 insertions(+), 19 deletions(-)

diff --git a/drivers/net/ifb.c b/drivers/net/ifb.c
index 90ad8791bc99..193af7483bb0 100644
--- a/drivers/net/ifb.c
+++ b/drivers/net/ifb.c
@@ -78,9 +78,7 @@ static void ifb_ri_tasklet(unsigned long _txp)
}
 
while ((skb = __skb_dequeue(>tq)) != NULL) {
-   u32 from = skb->tc_from;
-
-   skb_reset_tc(skb);
+   skb->tc_redirected = 0;
skb->tc_skip_classify = 1;
 
u64_stats_update_begin(>tsync);
@@ -101,13 +99,12 @@ static void ifb_ri_tasklet(unsigned long _txp)
rcu_read_unlock();
skb->skb_iif = txp->dev->ifindex;
 
-   if (from & AT_EGRESS) {
+   if (!skb->tc_from_ingress) {
dev_queue_xmit(skb);
-   } else if (from & AT_INGRESS) {
+   } else {
skb_pull(skb, skb->mac_len);
netif_receive_skb(skb);
-   } else
-   BUG();
+   }
}
 
if (__netif_tx_trylock(txq)) {
@@ -248,7 +245,7 @@ static netdev_tx_t ifb_xmit(struct sk_buff *skb, struct 
net_device *dev)
txp->rx_bytes += skb->len;
u64_stats_update_end(>rsync);
 
-   if (skb->tc_from == AT_STACK || !skb->skb_iif) {
+   if (!skb->tc_redirected || !skb->skb_iif) {
dev_kfree_skb(skb);
dev->stats.rx_dropped++;
return NETDEV_TX_OK;
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index fab3f87e9bd1..3149a88de548 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -591,6 +591,8 @@ static inline bool skb_mstamp_after(const struct skb_mstamp 
*t1,
  * @ipvs_property: skbuff is owned by ipvs
  * @tc_skip_classify: do not classify packet. set by IFB device
  * @tc_at_ingress: used within tc_classify to distinguish in/egress
+ * @tc_redirected: packet was redirected by a tc action
+ * @tc_from_ingress: if tc_redirected, tc_at_ingress at time of redirect
  * @peeked: this packet has been seen already, so stats have been
  * done for it, don't do them again
  * @nf_trace: netfilter packet trace flag
@@ -753,7 +755,8 @@ struct sk_buff {
 #ifdef CONFIG_NET_CLS_ACT
__u8tc_skip_classify:1;
__u8tc_at_ingress:1;
-   __u8tc_from:2;
+   __u8tc_redirected:1;
+   __u8tc_from_ingress:1;
 #endif
 
 #ifdef CONFIG_NET_SCHED
diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h
index 4bd6d5387209..e2f426f6d62f 100644
--- a/include/net/sch_generic.h
+++ b/include/net/sch_generic.h
@@ -412,7 +412,7 @@ int skb_do_redirect(struct sk_buff *);
 static inline void skb_reset_tc(struct sk_buff *skb)
 {
 #ifdef CONFIG_NET_CLS_ACT
-   skb->tc_from = 0;
+   skb->tc_redirected = 0;
 #endif
 }
 
diff --git a/include/uapi/linux/pkt_cls.h b/include/uapi/linux/pkt_cls.h
index cee753a7a40c..a081efbd61a2 100644
--- a/include/uapi/linux/pkt_cls.h
+++ b/include/uapi/linux/pkt_cls.h
@@ -4,12 +4,6 @@
 #include 
 #include 
 
-#ifdef __KERNEL__
-#define AT_STACK   0x0
-#define AT_INGRESS 0x1
-#define AT_EGRESS  0x2
-#endif
-
 /* Action attributes */
 enum {
TCA_ACT_UNSPEC,
diff --git a/net/sched/act_mirred.c b/net/sched/act_mirred.c
index e832c62fd705..84682f02b611 100644
--- a/net/sched/act_mirred.c
+++ b/net/sched/act_mirred.c
@@ -211,8 +211,10 @@ static int tcf_mirred(struct sk_buff *skb, const 

[PATCH net-next 0/6] convert tc_verd to integer bitfields

2017-01-07 Thread Willem de Bruijn
From: Willem de Bruijn 

The skb tc_verd field takes up two bytes but uses far fewer bits.
Convert the remaining use cases to bitfields that fit in existing
holes (depending on config options) and potentially save the two
bytes in struct sk_buff.

This patchset is based on an earlier set by Florian Westphal and its
discussion (http://www.spinics.net/lists/netdev/msg329181.html).

Patches 1 and 2 are low hanging fruit: removing the last traces of
  data that are no longer stored in tc_verd.

Patches 3 and 4 convert tc_verd to individual bitfields (5 bits).

Patch 5 reduces TC_AT to a single bitfield,
  as AT_STACK is not valid here (unlike in the case of TC_FROM).

Patch 6 changes TC_FROM to two bitfields with clearly defined purpose.

It may be possible to reduce storage further after this initial round.
If tc_skip_classify is set only by IFB, testing skb_iif may suffice.
The L2 header pushing/popping logic can perhaps be shared with
AF_PACKET, which currently not pkt_type for the same purpose.

Changes:
  RFC -> v1
- (patch 3): remove no longer needed label in tfc_action_exec
- (patch 5): set tc_at_ingress at the same points as existing
 SET_TC_AT calls

Tested ingress mirred + netem + ifb:

  ip link set dev ifb0 up
  tc qdisc add dev eth0 ingress
  tc filter add dev eth0 parent : \
u32 match ip dport 8000 0x \
action mirred egress redirect dev ifb0
  tc qdisc add dev ifb0 root netem delay 1000ms
  nc -u -l 8000 &
  ssh $otherhost nc -u $host 8000

Tested egress mirred:

  ip link add veth1 type veth peer name veth2
  ip link set dev veth1 up
  ip link set dev veth2 up
  tcpdump -n -i veth2 udp and dst port 8000 &

  tc qdisc add dev eth0 root handle 1: prio
  tc filter add dev eth0 parent 1:0 \
u32 match ip dport 8000 0x \
action mirred egress redirect dev veth1
  tc qdisc add dev veth1 root netem delay 1000ms
  nc -u $otherhost 8000

Tested ingress mirred:

  ip link add veth1 type veth peer name veth2
  ip link add veth3 type veth peer name veth4

  ip netns add ns0
  ip netns add ns1

  for i in 1 2 3 4; do \
NS=ns$((${i}%2)); \
ip link set dev veth${i} netns ${NS}; \
ip netns exec ${NS} \
  ip addr add dev veth${i} 192.168.1.${i}/24; \
ip netns exec ${NS} \
  ip link set dev veth${i} up; \
  done

  ip netns exec ns0 tc qdisc add dev veth2 ingress
  ip netns exec ns0 \
tc filter add dev veth2 parent : \
  u32 match ip dport 8000 0x \
  action mirred ingress redirect dev veth4

  ip netns exec ns0 \
tcpdump -n -i veth4 udp and dst port 8000 &
  ip netns exec ns1 \
nc -u 192.168.1.2 8000


Willem de Bruijn (6):
  net-tc: remove unused tc_verd fields
  net-tc: make MAX_RECLASSIFY_LOOP local
  net-tc: extract skip classify bit from tc_verd
  net-tc: convert tc_verd to integer bitfields
  net-tc: convert tc_at to tc_at_ingress
  net-tc: convert tc_from to tc_from_ingress and tc_redirected

 drivers/net/ifb.c| 16 ---
 drivers/staging/octeon/ethernet-tx.c |  5 ++--
 include/linux/skbuff.h   | 15 ++
 include/net/sch_generic.h| 20 -
 include/uapi/linux/pkt_cls.h | 55 
 net/core/dev.c   | 22 +--
 net/core/pktgen.c|  4 +--
 net/core/skbuff.c|  3 --
 net/sched/act_api.c  | 11 +++-
 net/sched/act_ife.c  |  7 ++---
 net/sched/act_mirred.c   | 21 +++---
 net/sched/sch_api.c  |  3 +-
 net/sched/sch_netem.c|  2 +-
 13 files changed, 66 insertions(+), 118 deletions(-)

-- 
2.11.0.390.gc69c2f50cf-goog



[PATCH net-next 1/6] net-tc: remove unused tc_verd fields

2017-01-07 Thread Willem de Bruijn
From: Willem de Bruijn 

Remove the last reference to tc_verd's munge and redirect ttl bits.
These fields are no longer used.

Signed-off-by: Willem de Bruijn 
---
 include/uapi/linux/pkt_cls.h | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/include/uapi/linux/pkt_cls.h b/include/uapi/linux/pkt_cls.h
index cb4bcdc58543..c769f71972f5 100644
--- a/include/uapi/linux/pkt_cls.h
+++ b/include/uapi/linux/pkt_cls.h
@@ -17,10 +17,6 @@
 
 /* verdict bit breakdown 
  *
-bit 0: when set -> this packet has been munged already
-
-bit 1: when set -> It is ok to munge this packet
-
 bit 2,3,4,5: Reclassify counter - sort of reverse TTL - if exceeded
 assume loop
 
@@ -31,8 +27,6 @@ bit 6,7: Where this packet was last seen
 
 bit 8: when set --> Request not to classify on ingress. 
 
-bits 9,10,11: redirect counter -  redirect TTL. Loop avoidance
-
  *
  * */
 
@@ -56,7 +50,6 @@ bits 9,10,11: redirect counter -  redirect TTL. Loop avoidance
 #define SET_TC_AT(v,n)   ((V_TC_AT(n)) | (v & ~M_TC_AT))
 
 #define MAX_REC_LOOP 4
-#define MAX_RED_LOOP 4
 #endif
 
 /* Action attributes */
-- 
2.11.0.390.gc69c2f50cf-goog



[PATCH net-next 2/6] net-tc: make MAX_RECLASSIFY_LOOP local

2017-01-07 Thread Willem de Bruijn
From: Willem de Bruijn 

This field is no longer kept in tc_verd. Remove it from the global
definition of that struct.

Signed-off-by: Willem de Bruijn 
---
 include/uapi/linux/pkt_cls.h | 5 -
 net/sched/sch_api.c  | 3 ++-
 2 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/include/uapi/linux/pkt_cls.h b/include/uapi/linux/pkt_cls.h
index c769f71972f5..bba23dbb3ab6 100644
--- a/include/uapi/linux/pkt_cls.h
+++ b/include/uapi/linux/pkt_cls.h
@@ -17,9 +17,6 @@
 
 /* verdict bit breakdown 
  *
-bit 2,3,4,5: Reclassify counter - sort of reverse TTL - if exceeded
-assume loop
-
 bit 6,7: Where this packet was last seen 
 0: Above the transmit example at the socket level
 1: on the Ingress
@@ -48,8 +45,6 @@ bit 8: when set --> Request not to classify on ingress.
 #define G_TC_AT(x)   _TC_GETVALUE(x,S_TC_AT,M_TC_AT)
 #define V_TC_AT(x)   _TC_MAKEVALUE(x,S_TC_AT)
 #define SET_TC_AT(v,n)   ((V_TC_AT(n)) | (v & ~M_TC_AT))
-
-#define MAX_REC_LOOP 4
 #endif
 
 /* Action attributes */
diff --git a/net/sched/sch_api.c b/net/sched/sch_api.c
index d7b93429f0cc..ef53ede11590 100644
--- a/net/sched/sch_api.c
+++ b/net/sched/sch_api.c
@@ -1861,6 +1861,7 @@ int tc_classify(struct sk_buff *skb, const struct 
tcf_proto *tp,
 {
__be16 protocol = tc_skb_protocol(skb);
 #ifdef CONFIG_NET_CLS_ACT
+   const int max_reclassify_loop = 4;
const struct tcf_proto *old_tp = tp;
int limit = 0;
 
@@ -1885,7 +1886,7 @@ int tc_classify(struct sk_buff *skb, const struct 
tcf_proto *tp,
return TC_ACT_UNSPEC; /* signal: continue lookup */
 #ifdef CONFIG_NET_CLS_ACT
 reset:
-   if (unlikely(limit++ >= MAX_REC_LOOP)) {
+   if (unlikely(limit++ >= max_reclassify_loop)) {
net_notice_ratelimited("%s: reclassify loop, rule prio %u, 
protocol %02x\n",
   tp->q->ops->id, tp->prio & 0x,
   ntohs(tp->protocol));
-- 
2.11.0.390.gc69c2f50cf-goog



[PATCH] net: ibm: ibmvnic: use new api ethtool_{get|set}_link_ksettings

2017-01-07 Thread Philippe Reynes
The ethtool api {get|set}_settings is deprecated.
We move this driver to new api {get|set}_link_ksettings.

Signed-off-by: Philippe Reynes 
---
 drivers/net/ethernet/ibm/ibmvnic.c |   31 ++-
 1 files changed, 18 insertions(+), 13 deletions(-)

diff --git a/drivers/net/ethernet/ibm/ibmvnic.c 
b/drivers/net/ethernet/ibm/ibmvnic.c
index c125966..3c2526b 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -1025,21 +1025,26 @@ static void ibmvnic_netpoll_controller(struct 
net_device *dev)
 
 /* ethtool functions */
 
-static int ibmvnic_get_settings(struct net_device *netdev,
-   struct ethtool_cmd *cmd)
+static int ibmvnic_get_link_ksettings(struct net_device *netdev,
+ struct ethtool_link_ksettings *cmd)
 {
-   cmd->supported = (SUPPORTED_1000baseT_Full | SUPPORTED_Autoneg |
+   u32 supported, advertising;
+
+   supported = (SUPPORTED_1000baseT_Full | SUPPORTED_Autoneg |
  SUPPORTED_FIBRE);
-   cmd->advertising = (ADVERTISED_1000baseT_Full | ADVERTISED_Autoneg |
+   advertising = (ADVERTISED_1000baseT_Full | ADVERTISED_Autoneg |
ADVERTISED_FIBRE);
-   ethtool_cmd_speed_set(cmd, SPEED_1000);
-   cmd->duplex = DUPLEX_FULL;
-   cmd->port = PORT_FIBRE;
-   cmd->phy_address = 0;
-   cmd->transceiver = XCVR_INTERNAL;
-   cmd->autoneg = AUTONEG_ENABLE;
-   cmd->maxtxpkt = 0;
-   cmd->maxrxpkt = 1;
+   cmd->base.speed = SPEED_1000;
+   cmd->base.duplex = DUPLEX_FULL;
+   cmd->base.port = PORT_FIBRE;
+   cmd->base.phy_address = 0;
+   cmd->base.autoneg = AUTONEG_ENABLE;
+
+   ethtool_convert_legacy_u32_to_link_mode(cmd->link_modes.supported,
+   supported);
+   ethtool_convert_legacy_u32_to_link_mode(cmd->link_modes.advertising,
+   advertising);
+
return 0;
 }
 
@@ -1132,7 +1137,6 @@ static void ibmvnic_get_ethtool_stats(struct net_device 
*dev,
 }
 
 static const struct ethtool_ops ibmvnic_ethtool_ops = {
-   .get_settings   = ibmvnic_get_settings,
.get_drvinfo= ibmvnic_get_drvinfo,
.get_msglevel   = ibmvnic_get_msglevel,
.set_msglevel   = ibmvnic_set_msglevel,
@@ -1141,6 +1145,7 @@ static void ibmvnic_get_ethtool_stats(struct net_device 
*dev,
.get_strings= ibmvnic_get_strings,
.get_sset_count = ibmvnic_get_sset_count,
.get_ethtool_stats  = ibmvnic_get_ethtool_stats,
+   .get_link_ksettings = ibmvnic_get_link_ksettings,
 };
 
 /* Routines for managing CRQs/sCRQs  */
-- 
1.7.4.4



Re: [PATCH v2 net-next 3/4] secure_seq: use SipHash in place of MD5

2017-01-07 Thread David Miller
From: "Jason A. Donenfeld" 
Date: Sat,  7 Jan 2017 15:40:56 +0100

> This gives a clear speed and security improvement. Siphash is both
> faster and is more solid crypto than the aging MD5.
> 
> Rather than manually filling MD5 buffers, for IPv6, we simply create
> a layout by a simple anonymous struct, for which gcc generates
> rather efficient code. For IPv4, we pass the values directly to the
> short input convenience functions.
> 
> 64-bit x86_64:
> [1.683628] secure_tcpv6_sequence_number_md5# cycles: 99563527
> [1.717350] secure_tcp_sequence_number_md5# cycles: 92890502
> [1.741968] secure_tcpv6_sequence_number_siphash# cycles: 67825362
> [1.762048] secure_tcp_sequence_number_siphash# cycles: 67485526
> 
> 32-bit x86:
> [1.600012] secure_tcpv6_sequence_number_md5# cycles: 103227892
> [1.634219] secure_tcp_sequence_number_md5# cycles: 94732544
> [1.669102] secure_tcpv6_sequence_number_siphash# cycles: 96299384
> [1.700165] secure_tcp_sequence_number_siphash# cycles: 86015473
> 
> Signed-off-by: Jason A. Donenfeld 

This and the next patch are a real shame, performance wise, on cpus
that have single-instruction SHA1 and MD5 implementations.  Sparc64
has both, and I believe x86_64 can do SHA1 these days.

It took so long to get those instructions into real silicon, and then
have software implemented to make use of them as well.

Who knows when we'll see SipHash widely deployed in any instruction
set, if at all, right?  And by that time we'll possibly find out that
"Oh shit, this SipHash thing has flaws!" and we'll need
DIPPY_DO_DA_HASH and thus be forced back to a software implementation
again.

I understand the reasons why these patches are being proposed, I just
thought I'd mention the issue of cpus that implement secure hash
algorithm instructions.


[PATCH] net: ibm: ibmveth: use new api ethtool_{get|set}_link_ksettings

2017-01-07 Thread Philippe Reynes
The ethtool api {get|set}_settings is deprecated.
We move this driver to new api {get|set}_link_ksettings.

Signed-off-by: Philippe Reynes 
---
 drivers/net/ethernet/ibm/ibmveth.c |   30 ++
 1 files changed, 18 insertions(+), 12 deletions(-)

diff --git a/drivers/net/ethernet/ibm/ibmveth.c 
b/drivers/net/ethernet/ibm/ibmveth.c
index a831f94..c6ba75c 100644
--- a/drivers/net/ethernet/ibm/ibmveth.c
+++ b/drivers/net/ethernet/ibm/ibmveth.c
@@ -729,20 +729,26 @@ static int ibmveth_close(struct net_device *netdev)
return 0;
 }
 
-static int netdev_get_settings(struct net_device *dev, struct ethtool_cmd *cmd)
+static int netdev_get_link_ksettings(struct net_device *dev,
+struct ethtool_link_ksettings *cmd)
 {
-   cmd->supported = (SUPPORTED_1000baseT_Full | SUPPORTED_Autoneg |
+   u32 supported, advertising;
+
+   supported = (SUPPORTED_1000baseT_Full | SUPPORTED_Autoneg |
SUPPORTED_FIBRE);
-   cmd->advertising = (ADVERTISED_1000baseT_Full | ADVERTISED_Autoneg |
+   advertising = (ADVERTISED_1000baseT_Full | ADVERTISED_Autoneg |
ADVERTISED_FIBRE);
-   ethtool_cmd_speed_set(cmd, SPEED_1000);
-   cmd->duplex = DUPLEX_FULL;
-   cmd->port = PORT_FIBRE;
-   cmd->phy_address = 0;
-   cmd->transceiver = XCVR_INTERNAL;
-   cmd->autoneg = AUTONEG_ENABLE;
-   cmd->maxtxpkt = 0;
-   cmd->maxrxpkt = 1;
+   cmd->base.speed = SPEED_1000;
+   cmd->base.duplex = DUPLEX_FULL;
+   cmd->base.port = PORT_FIBRE;
+   cmd->base.phy_address = 0;
+   cmd->base.autoneg = AUTONEG_ENABLE;
+
+   ethtool_convert_legacy_u32_to_link_mode(cmd->link_modes.supported,
+   supported);
+   ethtool_convert_legacy_u32_to_link_mode(cmd->link_modes.advertising,
+   advertising);
+
return 0;
 }
 
@@ -978,11 +984,11 @@ static void ibmveth_get_ethtool_stats(struct net_device 
*dev,
 
 static const struct ethtool_ops netdev_ethtool_ops = {
.get_drvinfo= netdev_get_drvinfo,
-   .get_settings   = netdev_get_settings,
.get_link   = ethtool_op_get_link,
.get_strings= ibmveth_get_strings,
.get_sset_count = ibmveth_get_sset_count,
.get_ethtool_stats  = ibmveth_get_ethtool_stats,
+   .get_link_ksettings = netdev_get_link_ksettings,
 };
 
 static int ibmveth_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
-- 
1.7.4.4



[PATCH] net: ibm: emac: use new api ethtool_{get|set}_link_ksettings

2017-01-07 Thread Philippe Reynes
The ethtool api {get|set}_settings is deprecated.
We move this driver to new api {get|set}_link_ksettings.

Signed-off-by: Philippe Reynes 
---
 drivers/net/ethernet/ibm/emac/core.c |   70 +++--
 1 files changed, 40 insertions(+), 30 deletions(-)

diff --git a/drivers/net/ethernet/ibm/emac/core.c 
b/drivers/net/ethernet/ibm/emac/core.c
index 5909615..6ead233 100644
--- a/drivers/net/ethernet/ibm/emac/core.c
+++ b/drivers/net/ethernet/ibm/emac/core.c
@@ -1991,69 +1991,79 @@ static irqreturn_t emac_irq(int irq, void *dev_instance)
 };
 
 /* Ethtool support */
-static int emac_ethtool_get_settings(struct net_device *ndev,
-struct ethtool_cmd *cmd)
+static int emac_ethtool_get_link_ksettings(struct net_device *ndev,
+  struct ethtool_link_ksettings *cmd)
 {
struct emac_instance *dev = netdev_priv(ndev);
+   u32 supported, advertising;
 
-   cmd->supported = dev->phy.features;
-   cmd->port = PORT_MII;
-   cmd->phy_address = dev->phy.address;
-   cmd->transceiver =
-   dev->phy.address >= 0 ? XCVR_EXTERNAL : XCVR_INTERNAL;
+   supported = dev->phy.features;
+   cmd->base.port = PORT_MII;
+   cmd->base.phy_address = dev->phy.address;
 
mutex_lock(>link_lock);
-   cmd->advertising = dev->phy.advertising;
-   cmd->autoneg = dev->phy.autoneg;
-   cmd->speed = dev->phy.speed;
-   cmd->duplex = dev->phy.duplex;
+   advertising = dev->phy.advertising;
+   cmd->base.autoneg = dev->phy.autoneg;
+   cmd->base.speed = dev->phy.speed;
+   cmd->base.duplex = dev->phy.duplex;
mutex_unlock(>link_lock);
 
+   ethtool_convert_legacy_u32_to_link_mode(cmd->link_modes.supported,
+   supported);
+   ethtool_convert_legacy_u32_to_link_mode(cmd->link_modes.advertising,
+   advertising);
+
return 0;
 }
 
-static int emac_ethtool_set_settings(struct net_device *ndev,
-struct ethtool_cmd *cmd)
+static int
+emac_ethtool_set_link_ksettings(struct net_device *ndev,
+   const struct ethtool_link_ksettings *cmd)
 {
struct emac_instance *dev = netdev_priv(ndev);
u32 f = dev->phy.features;
+   u32 advertising;
+
+   ethtool_convert_link_mode_to_legacy_u32(,
+   cmd->link_modes.advertising);
 
DBG(dev, "set_settings(%d, %d, %d, 0x%08x)" NL,
-   cmd->autoneg, cmd->speed, cmd->duplex, cmd->advertising);
+   cmd->base.autoneg, cmd->base.speed, cmd->base.duplex, advertising);
 
/* Basic sanity checks */
if (dev->phy.address < 0)
return -EOPNOTSUPP;
-   if (cmd->autoneg != AUTONEG_ENABLE && cmd->autoneg != AUTONEG_DISABLE)
+   if (cmd->base.autoneg != AUTONEG_ENABLE &&
+   cmd->base.autoneg != AUTONEG_DISABLE)
return -EINVAL;
-   if (cmd->autoneg == AUTONEG_ENABLE && cmd->advertising == 0)
+   if (cmd->base.autoneg == AUTONEG_ENABLE && advertising == 0)
return -EINVAL;
-   if (cmd->duplex != DUPLEX_HALF && cmd->duplex != DUPLEX_FULL)
+   if (cmd->base.duplex != DUPLEX_HALF && cmd->base.duplex != DUPLEX_FULL)
return -EINVAL;
 
-   if (cmd->autoneg == AUTONEG_DISABLE) {
-   switch (cmd->speed) {
+   if (cmd->base.autoneg == AUTONEG_DISABLE) {
+   switch (cmd->base.speed) {
case SPEED_10:
-   if (cmd->duplex == DUPLEX_HALF &&
+   if (cmd->base.duplex == DUPLEX_HALF &&
!(f & SUPPORTED_10baseT_Half))
return -EINVAL;
-   if (cmd->duplex == DUPLEX_FULL &&
+   if (cmd->base.duplex == DUPLEX_FULL &&
!(f & SUPPORTED_10baseT_Full))
return -EINVAL;
break;
case SPEED_100:
-   if (cmd->duplex == DUPLEX_HALF &&
+   if (cmd->base.duplex == DUPLEX_HALF &&
!(f & SUPPORTED_100baseT_Half))
return -EINVAL;
-   if (cmd->duplex == DUPLEX_FULL &&
+   if (cmd->base.duplex == DUPLEX_FULL &&
!(f & SUPPORTED_100baseT_Full))
return -EINVAL;
break;
case SPEED_1000:
-   if (cmd->duplex == DUPLEX_HALF &&
+   if (cmd->base.duplex == DUPLEX_HALF &&
!(f & SUPPORTED_1000baseT_Half))
return -EINVAL;
-   if (cmd->duplex == DUPLEX_FULL &&
+   if 

Re: [PATCH net-next 1/2] net: dsa: make "label" property optional for dsa2

2017-01-07 Thread Uwe Kleine-König
Hello,

On 01/06/2017 11:00 PM, Vivien Didelot wrote:
> In the new DTS bindings for DSA (dsa2), the "ethernet" and "link"
> phandles are respectively mandatory and exclusive to CPU port and DSA
> link device tree nodes.
> 
> Simplify dsa2.c a bit by checking the presence of such phandle instead
> of checking the redundant "label" property.
> 
> Then the Linux philosophy for Ethernet switch ports is to expose them to
> userspace as standard NICs by default. Thus use the standard enumerated
> "eth%d" device name if no "label" property is provided for a user port.
> This allows to save DTS files from subjective net device names.
> 
> If one wants to rename an interface, udev rules can be used as usual.
> The sysfs phys_port_id and phys_switch_id also provide physical data.
> 
> Of course the current behavior is unchanged, and the optional "label"
> property for user ports has precedence over the enumerated name.
> 
> Signed-off-by: Vivien Didelot 
Acked-by: Uwe Kleine-König 

Thanks
Uwe



signature.asc
Description: OpenPGP digital signature


Re: [PATCH net-next 1/2] net: dsa: make "label" property optional for dsa2

2017-01-07 Thread Uwe Kleine-König
Hello,

On 01/06/2017 11:47 PM, Florian Fainelli wrote:
> On 01/06/2017 02:20 PM, Andrew Lunn wrote:
>>> If one wants to rename an interface, udev rules can be used as usual.
>>
>> Hi Vivien
>>
>> Do you have some examples?
>>
>> A quick look at udevadm info suggests we can use
>>
>> ATTR{phys_port_id} and ATTR{phys_switch_id}
>>
>> Humm, it would be nice to know why the second switch has a
>> phys_switch_id of 0100.
> 
> Well, that's a combination of being on a little endian system and using
> %*phN as a printk formatter, and the type being 32-bit long (int). I
> agree this does not feel natural, but since this is sysfs (so ABI in a
> way), it's going to be though to change now.

for most subsystems I know the internally used (and more or less
automatically determined) numbers are not to be considered stable.
For example the GPIO made it possible to let userspace work with GPIOs
without knowing (or having to determine) the gpio numbers.

I don't know if/how this applies here.

Best regards
Uwe




signature.asc
Description: OpenPGP digital signature


Re: [PATCHv2 net-next 11/16] net: mvpp2: handle misc PPv2.1/PPv2.2 differences

2017-01-07 Thread Russell King - ARM Linux
On Sat, Jan 07, 2017 at 09:38:34AM +, Russell King - ARM Linux wrote:
> On Wed, Dec 28, 2016 at 05:46:27PM +0100, Thomas Petazzoni wrote:
> > @@ -6511,7 +6515,9 @@ static int mvpp2_port_probe(struct platform_device 
> > *pdev,
> > dev_err(>dev, "failed to init port %d\n", id);
> > goto err_free_stats;
> > }
> > -   mvpp2_port_power_up(port);
> > +
> > +   if (priv->hw_version == MVPP21)
> > +   mvpp21_port_power_up(port);
> 
> This has the side effect that nothing clears the port reset bit in the
> GMAC, which means there's no hope of the interface working - with the
> reset bit set, the port is well and truely held in "link down" state.
> 
> In any case, the GMAC part is much the same as mvneta, and I think
> that code should be shared rather than writing new versions of it.
> There are some subtle differences between neta, pp2.1 and pp2.2, but
> it's entirely doable (I have an implementation here as I wasn't going
> to duplicate this code for my phylink conversion.)

In addition to comphy configuration and the above, I also need the
following to have working SGMII.  The change of MACMODE is needed
because uboot has configured the port for 10Gbase-R mode (it has a
10G PHY on it, but the PHY switches to SGMII in <10G modes.)  The
GMAC control register 4 is needed to properly configure for SGMII
mode.  I also included RGMII mode as well in there, as I expect you'd
need it to have GMAC properly configured for RGMII.

With this in place (and the other bits mentioned above), I can ping
the clearfog switch on the other end of eth0's cable:

# ping6 -I eth0 fe80::250:43ff:fe02:302
PING fe80::250:43ff:fe02:302(fe80::250:43ff:fe02:302) from fe80::200:ff:fe00:1 
eth0: 56 data bytes
64 bytes from fe80::250:43ff:fe02:302: icmp_seq=1 ttl=64 time=0.297 ms

diff --git a/drivers/net/ethernet/marvell/mvpp2.c 
b/drivers/net/ethernet/marvell/mvpp2.c
index bc97eebf7eee..4b6ec6213e9c 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -345,7 +345,17 @@
 #define  MVPP2_GMAC_TX_FIFO_MIN_TH_ALL_MASK0x1fc0
 #define  MVPP2_GMAC_TX_FIFO_MIN_TH_MASK(v) (((v) << 6) & \
MVPP2_GMAC_TX_FIFO_MIN_TH_ALL_MASK)
+#define MVPP22_GMAC_CTRL_4_REG 0x90
+#define  MVPP22_CTRL4_EXT_PIN_GMII_SEL BIT(0)
+#define  MVPP22_CTRL4_DP_CLK_SEL   BIT(5)
+#define  MVPP22_CTRL4_SYNC_BYPASS  BIT(6)
+#define  MVPP22_CTRL4_QSGMII_BYPASS_ACTIVE BIT(7)
+
+#define MVPP22_XLG_CTRL3_REG   0x11c
+#define  MVPP22_XLG_CTRL3_MACMODESELECT_MASK   (7 << 13)
+#define  MVPP22_XLG_CTRL3_MACMODESELECT_GMAC   (0 << 13)
 
+/* offsets from iface_base */
 #define MVPP22_SMI_MISC_CFG_REG0x2a204
 #define  MVPP22_SMI_POLLING_EN BIT(10)
 
@@ -4171,6 +4181,23 @@ static void mvpp2_port_mii_set(struct mvpp2_port *port)
 {
u32 val;
 
+   if (port->priv->hw_version == MVPP22) {
+   val = readl(port->base + MVPP22_XLG_CTRL3_REG);
+   val &= ~MVPP22_XLG_CTRL3_MACMODESELECT_MASK;
+   val |= MVPP22_XLG_CTRL3_MACMODESELECT_GMAC;
+   writel(val, port->base + MVPP22_XLG_CTRL3_REG);
+
+   val = readl(port->base + MVPP22_GMAC_CTRL_4_REG);
+   if (port->phy_interface == PHY_INTERFACE_MODE_RGMII)
+   val |= MVPP22_CTRL4_EXT_PIN_GMII_SEL;
+   else
+   val &= ~MVPP22_CTRL4_EXT_PIN_GMII_SEL;
+   val &= ~MVPP22_CTRL4_DP_CLK_SEL;
+   val |= MVPP22_CTRL4_SYNC_BYPASS;
+   val |= MVPP22_CTRL4_QSGMII_BYPASS_ACTIVE;
+   writel(val, port->base + MVPP22_GMAC_CTRL_4_REG);
+   }
+
val = readl(port->base + MVPP2_GMAC_CTRL_2_REG);
 
switch (port->phy_interface) {


-- 
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: More info about lockless qdisc patch

2017-01-07 Thread John Fastabend
On 16-12-30 04:48 AM, Xingjun Liu wrote:
> Hi John,
> 
> I note you have a patch request last august about "support lockless qdisc”,
> 
> see: https://www.mail-archive.com/netdev@vger.kernel.org/msg124489.html

I have another set of patches that fixes a few bugs from the above.

> 
> We take an interest in it. Do you have any info/plan on this patch?
> 

The current state of the patches (the latest I have on my private tree) is
currently
I an issue with re-starting the driver when multiple cores do a dequeue but the
driver overruns the hardware descriptor ring so we push back into the qdisc. 
When
this happens the patches push the skb onto the gso_skb per cpu list.

Now the problem is how do we wake the correct gso_skb per cpu list up? The 
driver
will restart the qdisc at some future point but not necessarily from the same
cpu that
the per cpu enqueue happened on. So I tried to fix this by removing the driver
restart
logic and having the qdisc layer poll the driver. This sort of/kind of works
except its not
a very satisfying solution. Tom noted at one point with BQL the above case
should not
happen very much but it is still possible unfortunately under certain
conditions. And the
corner cases get ugly.

I've been kicking around another idea lately. To get rid of the gso_skb entirely
which
would certainly clean up the code and get rid of one of the uglier pieces of
qdisc struct
in my opinion. To make this work I want to add a tx_prep() ndo call the qdisc
could call
into the driver with to reserve "slots" in the driver. Once we have some # of
slots reserved
we can dequeue from the qdisc ring and send to driver "knowing" that the driver 
has
agreed to consume the packets. The trick here is sk_buffs do not map 1:1 with
descriptors
in the hardware always so a bit of driver magic needs to occur to get
calculations correct.

I'll try to rebase the current set of patches I have on net-next and post it
just so its
available. I can probably get to the above in a month or so. Maybe have 
something by
March.

Thanks,
John

> Thanks
> Xingjun
> 



Re: [PATCH v2 net-next 0/4] Introduce The SipHash PRF

2017-01-07 Thread Eric Biggers
On Sat, Jan 07, 2017 at 03:40:53PM +0100, Jason A. Donenfeld wrote:
> This patch series introduces SipHash into the kernel. SipHash is a
> cryptographically secure PRF, which serves a variety of functions, and is
> introduced in patch #1. The following patch #2 introduces HalfSipHash,
> an optimization suitable for hash tables only. Finally, the last two patches
> in this series show two usages of the introduced siphash function family.
> It is expected that after this initial introductin, other usages will follow.
...
> The use of SipHash is not limited to the networking subsystem -- indeed I
> would like to use it in other places too in the kernel. But after discussing
> with a few on this list and at Linus' suggestion, the initial import of these
> functions is coming through the networking tree. After these are merged, it
> will then be easier to expand use elsewhere.
> 
> Changes v1->v2:
>   - len in the macro is now (len).
>   - siphash_key_t is now a struct, so that passing by reference is more
> obvious and clear. This required changing all the call sites.
>   - Rather than calling le32_to_cpu(data[0]), where data is a u64, we now
> do the safer thing and call le32_to_cpup((const __le32 *)data).
>   - The alignment in the tests is now more explicit.
>   - Sparse no longer complains, after fixing up a few endian casts.
>   - White space fixups.
>   - Word wrapping fixes.
>   - The valid suggestions from checkpatch.

Hi Jason, thanks for doing this!  Yes, I had gotten a little lost in the earlier
discussions about the 'random' driver and other potential users of SipHash.  I
agree with the approach to just introduce the two uses in net/ to start with,
and introduce more users later.  The changes from v1 to v2 look good too.

Now that the HalfSipHash patch is Cc'ed to me too I do have one other small
suggestion which is that this:

#if BITS_PER_LONG == 64
typedef siphash_key_t hsiphash_key_t;
#define HSIPHASH_ALIGNMENT SIPHASH_ALIGNMENT
#else
typedef struct {
u32 key[2];
} hsiphash_key_t;
#define HSIPHASH_ALIGNMENT __alignof__(u32)
#endif

could cause confusion if someone accidentally uses 'siphash_key_t' instead of
'hsiphash_key_t', as their code would compile fine on a 64-bit platform but
would fail to compile on a 32-bit platform.  I think there should just always be
a hsiphash_key_t struct defined, and it can use unsigned long (no need for an
#ifdef):

#define HSIPHASH_ALIGNMENT __alignof__(unsigned long)
typedef struct {
unsigned long key[2];
} hsiphash_key_t;

There's also a small error in Documentation/siphash.txt: hsiphash() is shown as
taking siphash_key_t instead of hsiphash_key_t.

The uses in net look good too.  Something to watch out for is accidentally
defining the structs in a way that leaves internal padding bytes, which could
theoretically take on any value and cause the same input to produce different
hashes.  But AFAICS, in the proposed patch all the structs are laid out
properly, so that won't happen.

'net_secret' could also be marked as __read_mostly, like the keys in
syncookies.c, I suppose; it may not matter much.

Thanks!

Eric


[RFC PATCH] intel: Use upper_32_bits and lower_32_bits

2017-01-07 Thread Joe Perches
Shifting and masking various types can be made a bit
simpler to read by using the available kernel macros.

Signed-off-by: Joe Perches 
---

This RFC patch is meant as an example, not necessarily
to apply, though it does compile to equivalent code.

It does seem a bit simpler for a human to read.

Perhaps this could be automated via a coccinelle script,
but this was done with grep & sed and some typing.

Treewide, there are many hundred instances of this style code
that could be converted.

Dunno if it's really worth it though.

Another usage that could be converted is DMA_BIT_MASK(32)
where it is equivalent to upper_32_bits and lower_32_bits.

 drivers/net/ethernet/intel/e1000/e1000_ethtool.c   |  8 
 drivers/net/ethernet/intel/e1000/e1000_main.c  |  8 
 drivers/net/ethernet/intel/e1000e/ethtool.c|  8 
 drivers/net/ethernet/intel/fm10k/fm10k_common.c|  4 ++--
 drivers/net/ethernet/intel/fm10k/fm10k_pf.c|  2 +-
 drivers/net/ethernet/intel/i40e/i40e_common.c  |  4 ++--
 drivers/net/ethernet/intel/i40e/i40e_ethtool.c |  8 
 drivers/net/ethernet/intel/i40e/i40e_main.c|  4 ++--
 drivers/net/ethernet/intel/i40e/i40e_ptp.c | 12 ++--
 drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c |  9 +
 drivers/net/ethernet/intel/i40evf/i40evf_main.c|  4 ++--
 drivers/net/ethernet/intel/igb/igb_main.c  | 10 --
 drivers/net/ethernet/intel/igb/igb_ptp.c   |  4 ++--
 drivers/net/ethernet/intel/ixgb/ixgb_main.c| 12 ++--
 drivers/net/ethernet/intel/ixgbe/ixgbe_common.h|  4 ++--
 drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c   | 12 ++--
 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c  | 16 
 drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c   | 12 ++--
 drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c  |  4 ++--
 19 files changed, 72 insertions(+), 73 deletions(-)

diff --git a/drivers/net/ethernet/intel/e1000/e1000_ethtool.c 
b/drivers/net/ethernet/intel/e1000/e1000_ethtool.c
index 975eeb885ca2..11ad95f34f4f 100644
--- a/drivers/net/ethernet/intel/e1000/e1000_ethtool.c
+++ b/drivers/net/ethernet/intel/e1000/e1000_ethtool.c
@@ -1021,8 +1021,8 @@ static int e1000_setup_desc_rings(struct e1000_adapter 
*adapter)
}
txdr->next_to_use = txdr->next_to_clean = 0;
 
-   ew32(TDBAL, ((u64)txdr->dma & 0x));
-   ew32(TDBAH, ((u64)txdr->dma >> 32));
+   ew32(TDBAL, lower_32_bits(txdr->dma));
+   ew32(TDBAH, upper_32_bits(txdr->dma));
ew32(TDLEN, txdr->count * sizeof(struct e1000_tx_desc));
ew32(TDH, 0);
ew32(TDT, 0);
@@ -1081,8 +1081,8 @@ static int e1000_setup_desc_rings(struct e1000_adapter 
*adapter)
 
rctl = er32(RCTL);
ew32(RCTL, rctl & ~E1000_RCTL_EN);
-   ew32(RDBAL, ((u64)rxdr->dma & 0x));
-   ew32(RDBAH, ((u64)rxdr->dma >> 32));
+   ew32(RDBAL, lower_32_bits(rxdr->dma));
+   ew32(RDBAH, upper_32_bits(rxdr->dma));
ew32(RDLEN, rxdr->size);
ew32(RDH, 0);
ew32(RDT, 0);
diff --git a/drivers/net/ethernet/intel/e1000/e1000_main.c 
b/drivers/net/ethernet/intel/e1000/e1000_main.c
index 93fc6c67306b..d222f731f280 100644
--- a/drivers/net/ethernet/intel/e1000/e1000_main.c
+++ b/drivers/net/ethernet/intel/e1000/e1000_main.c
@@ -1614,8 +1614,8 @@ static void e1000_configure_tx(struct e1000_adapter 
*adapter)
tdlen = adapter->tx_ring[0].count *
sizeof(struct e1000_tx_desc);
ew32(TDLEN, tdlen);
-   ew32(TDBAH, (tdba >> 32));
-   ew32(TDBAL, (tdba & 0xULL));
+   ew32(TDBAH, upper_32_bits(tdba));
+   ew32(TDBAL, lower_32_bits(tdba));
ew32(TDT, 0);
ew32(TDH, 0);
adapter->tx_ring[0].tdh = ((hw->mac_type >= e1000_82543) ?
@@ -1896,8 +1896,8 @@ static void e1000_configure_rx(struct e1000_adapter 
*adapter)
default:
rdba = adapter->rx_ring[0].dma;
ew32(RDLEN, rdlen);
-   ew32(RDBAH, (rdba >> 32));
-   ew32(RDBAL, (rdba & 0xULL));
+   ew32(RDBAH, upper_32_bits(rdba));
+   ew32(RDBAL, lower_32_bits(rdba));
ew32(RDT, 0);
ew32(RDH, 0);
adapter->rx_ring[0].rdh = ((hw->mac_type >= e1000_82543) ?
diff --git a/drivers/net/ethernet/intel/e1000e/ethtool.c 
b/drivers/net/ethernet/intel/e1000e/ethtool.c
index 7aff68a4a4df..35304b380eaa 100644
--- a/drivers/net/ethernet/intel/e1000e/ethtool.c
+++ b/drivers/net/ethernet/intel/e1000e/ethtool.c
@@ -1203,8 +1203,8 @@ static int e1000_setup_desc_rings(struct e1000_adapter 
*adapter)
tx_ring->next_to_use = 0;
tx_ring->next_to_clean = 0;
 
-   ew32(TDBAL(0), ((u64)tx_ring->dma & 0x));
-   ew32(TDBAH(0), ((u64)tx_ring->dma >> 32));
+   

Re: [PATCH net-next] mdio: Demote print from info to debug in mdio_device_register

2017-01-07 Thread Andrew Lunn
On Fri, Jan 06, 2017 at 10:27:59PM -0800, Florian Fainelli wrote:
> While it is useful to know which MDIO device is being registered, demote
> the dev_info() to a dev_dbg().
> 
> Signed-off-by: Florian Fainelli 

Reviewed-by: Andrew Lunn 

Andrew


[PATCH] net: ibm: ehea: use new api ethtool_{get|set}_link_ksettings

2017-01-07 Thread Philippe Reynes
The ethtool api {get|set}_settings is deprecated.
We move this driver to new api {get|set}_link_ksettings.

Signed-off-by: Philippe Reynes 
---
 drivers/net/ethernet/ibm/ehea/ehea_ethtool.c |   51 +++---
 1 files changed, 30 insertions(+), 21 deletions(-)

diff --git a/drivers/net/ethernet/ibm/ehea/ehea_ethtool.c 
b/drivers/net/ethernet/ibm/ehea/ehea_ethtool.c
index 85a3866..4f58d33 100644
--- a/drivers/net/ethernet/ibm/ehea/ehea_ethtool.c
+++ b/drivers/net/ethernet/ibm/ehea/ehea_ethtool.c
@@ -31,9 +31,11 @@
 #include "ehea.h"
 #include "ehea_phyp.h"
 
-static int ehea_get_settings(struct net_device *dev, struct ethtool_cmd *cmd)
+static int ehea_get_link_ksettings(struct net_device *dev,
+  struct ethtool_link_ksettings *cmd)
 {
struct ehea_port *port = netdev_priv(dev);
+   u32 supported, advertising;
u32 speed;
int ret;
 
@@ -60,68 +62,75 @@ static int ehea_get_settings(struct net_device *dev, struct 
ethtool_cmd *cmd)
speed = -1;
break; /* BUG */
}
-   cmd->duplex = port->full_duplex == 1 ?
+   cmd->base.duplex = port->full_duplex == 1 ?
 DUPLEX_FULL : DUPLEX_HALF;
} else {
speed = SPEED_UNKNOWN;
-   cmd->duplex = DUPLEX_UNKNOWN;
+   cmd->base.duplex = DUPLEX_UNKNOWN;
}
-   ethtool_cmd_speed_set(cmd, speed);
+   cmd->base.speed = speed;
 
-   if (cmd->speed == SPEED_1) {
-   cmd->supported = (SUPPORTED_1baseT_Full | SUPPORTED_FIBRE);
-   cmd->advertising = (ADVERTISED_1baseT_Full | 
ADVERTISED_FIBRE);
-   cmd->port = PORT_FIBRE;
+   if (cmd->base.speed == SPEED_1) {
+   supported = (SUPPORTED_1baseT_Full | SUPPORTED_FIBRE);
+   advertising = (ADVERTISED_1baseT_Full | ADVERTISED_FIBRE);
+   cmd->base.port = PORT_FIBRE;
} else {
-   cmd->supported = (SUPPORTED_1000baseT_Full | 
SUPPORTED_100baseT_Full
+   supported = (SUPPORTED_1000baseT_Full | SUPPORTED_100baseT_Full
   | SUPPORTED_100baseT_Half | 
SUPPORTED_10baseT_Full
   | SUPPORTED_10baseT_Half | SUPPORTED_Autoneg
   | SUPPORTED_TP);
-   cmd->advertising = (ADVERTISED_1000baseT_Full | 
ADVERTISED_Autoneg
+   advertising = (ADVERTISED_1000baseT_Full | ADVERTISED_Autoneg
 | ADVERTISED_TP);
-   cmd->port = PORT_TP;
+   cmd->base.port = PORT_TP;
}
 
-   cmd->autoneg = port->autoneg == 1 ? AUTONEG_ENABLE : AUTONEG_DISABLE;
+   cmd->base.autoneg = port->autoneg == 1 ?
+   AUTONEG_ENABLE : AUTONEG_DISABLE;
+
+   ethtool_convert_legacy_u32_to_link_mode(cmd->link_modes.supported,
+   supported);
+   ethtool_convert_legacy_u32_to_link_mode(cmd->link_modes.advertising,
+   advertising);
 
return 0;
 }
 
-static int ehea_set_settings(struct net_device *dev, struct ethtool_cmd *cmd)
+static int ehea_set_link_ksettings(struct net_device *dev,
+  const struct ethtool_link_ksettings *cmd)
 {
struct ehea_port *port = netdev_priv(dev);
int ret = 0;
u32 sp;
 
-   if (cmd->autoneg == AUTONEG_ENABLE) {
+   if (cmd->base.autoneg == AUTONEG_ENABLE) {
sp = EHEA_SPEED_AUTONEG;
goto doit;
}
 
-   switch (cmd->speed) {
+   switch (cmd->base.speed) {
case SPEED_10:
-   if (cmd->duplex == DUPLEX_FULL)
+   if (cmd->base.duplex == DUPLEX_FULL)
sp = H_SPEED_10M_F;
else
sp = H_SPEED_10M_H;
break;
 
case SPEED_100:
-   if (cmd->duplex == DUPLEX_FULL)
+   if (cmd->base.duplex == DUPLEX_FULL)
sp = H_SPEED_100M_F;
else
sp = H_SPEED_100M_H;
break;
 
case SPEED_1000:
-   if (cmd->duplex == DUPLEX_FULL)
+   if (cmd->base.duplex == DUPLEX_FULL)
sp = H_SPEED_1G_F;
else
ret = -EINVAL;
break;
 
case SPEED_1:
-   if (cmd->duplex == DUPLEX_FULL)
+   if (cmd->base.duplex == DUPLEX_FULL)
sp = H_SPEED_10G_F;
else
ret = -EINVAL;
@@ -264,7 +273,6 @@ static void ehea_get_ethtool_stats(struct net_device *dev,
 }
 
 static const struct ethtool_ops ehea_ethtool_ops = {
-   .get_settings = ehea_get_settings,
.get_drvinfo = 

bad interaction between privacy extensions, prefix lifetimes and protocols that maintain long-term connections.

2017-01-07 Thread peter green

I just switched my main machine to a new one. After doing so I noticed my 
connections to IRC were dropping about once per hour.

The old machine had been running a mixed mess of Debian versions while the new 
machine is running Debian stretch. A critical difference between the old and 
new machines is that the old machine had privacy extensions disabled while the 
new machine had them enabled.

Disabling privacy extensions solved the issue but obviously reveals the MAC 
address of my new machine to the world which is undesirable.

My ISP (a major provider in the UK) router sets a relatively short valid_lft of 
about 1 hour. Presumably so any changes to the ISP-allocated address will be 
picked up quickly by clients.

For the main MAC-based address the valid_lft is always short but it is updated 
by new RAs so the address remains valid.

However privacy addresses inherit their valid_lft from the main MAC-based 
address and unlike the main address it is not updated causing the addresses to 
time out. I believe that the timeout of these privacy addresses is what is 
causing my repeated disconnections from IRC.




Re: [PATCH net-next] bridge: multicast to unicast

2017-01-07 Thread Linus Lüssing
On Fri, Jan 06, 2017 at 01:47:52PM +0100, Johannes Berg wrote:
> How does this compare and/or relate to the multicast-to-unicast feature
> we were going to add to the wifi stack, particularly mac80211? Do we
> perhaps not need that feature at all, if bridging will have it?
> 
> I suppose that the feature there could apply also to locally generated
> traffic when the AP interface isn't in a bridge, but I think I could
> live with requiring the AP to be put into a bridge to achieve a similar
> configuration?
> 
> Additionally, on an unrelated note, this seems to apply generically to
> all kinds of frames, losing information by replacing the address.
> Shouldn't it have similar limitations as the wifi stack feature has
> then, like only applying to ARP, IPv4, IPv6 and not general protocols?

(should all three be answered with Michael's and my reply to
Michael's mail, I think)

> 
> Also, it should probably come with the same caveat as we documented for
> the wifi feature:
> 
> Note that this may break certain expectations of the receiver,
> such as the ability to drop unicast IP packets received within
> multicast L2 frames, or the ability to not send ICMP destination
> unreachable messages for packets received in L2 multicast (which
> is required, but the receiver can't tell the difference if this
> new option is enabled.)

Actually, I do not quite understand that remark in the mac80211
multicast-to-unicast patch. IP should not care about the ethernet
header?


Re: [PATCH net-next] bridge: multicast to unicast

2017-01-07 Thread Linus Lüssing
On Fri, Jan 06, 2017 at 07:13:56PM -0800, Stephen Hemminger wrote:
> On Mon,  2 Jan 2017 20:32:14 +0100
> Linus Lüssing  wrote:
> 
> > This feature is intended for interface types which have a more reliable
> > and/or efficient way to deliver unicast packets than broadcast ones
> > (e.g. wifi).
> 
> 
> Why is this not done in MAC80211 rather than  bridge?

Because mac80211 does not have the IGMP/MLD snooping code as
the bridge has?

Reimplementing the snooping in mac80211 does not make sense
because of duplicating code. Moving the snooping code from the
bridge to mac80211 does not make sense either, because we want
multicast snooping, software based, (virtually) wired switches,
too.

The "best way" (TM) would probably be to migrate the IGMP/MLD
snooping from the bridge code to the net device code on the long
run to make such a database usable for any kind of device, without
needing this bridge hack.

But such a migration would also need a way more invasive patchset.

While Felix's idea might look a little "ugly" due it's hacky
nature, I think it is also quite beautiful thanks to it's
simplicity.


Re:

2017-01-07 Thread Information


Do you need loan? we offer all kinds of loan from minimum amount of $5,000 to 
maximum of $2,000,000 if you are interested contact us via: 
internationalloa...@gmail.comwith the information below:

Full Name:
Country:
Loan Amount:
Loan Duration:
Mobile phone number:
Sex:

Thanks,
Dr Scott.


Re: [PATCH net-next] bridge: multicast to unicast

2017-01-07 Thread Linus Lüssing
On Sat, Jan 07, 2017 at 11:32:57AM +0100, M. Braun wrote:
> Am 06.01.2017 um 14:54 schrieb Johannes Berg:
> > 
> >> The bridge layer can use IGMP snooping to ensure that the multicast
> >> stream is only transmitted to clients that are actually a member of
> >> the group. Can the mac80211 feature do the same?
> > 
> > No, it'll convert the packet for all clients that are behind that
> > netdev. But that's an argument for dropping the mac80211 feature, which
> > hasn't been merged upstream yet, no?
> 
> But there is multicast/broadcast traffic like e.g. ARP and some IP
> multicast groups that are not covered by IGMP snooping. The mac80211
> patch converts this to unicast as well, which the bridge cannot do.
> 
> That way, these features both complement and overlap each other.

Right, I'd agree with that.

I didn't write it explicitly in the commit message, but yes, the
like anything concerning bridge multicast snooping, bridge
multicast-to-unicast can only affect packets as noted in
RFC4541 ("Considerations for Internet Group Management Protocol (IGMP)
and Multicast Listener Discovery (MLD) Snooping Switches"), too.

So it is only working for IPv4 multicast, excluding link-local
(224.0.0.0/24), and IPv6 multicast, excluding all-host-multicast
(ff02::1).

And does not concern ARP in any way.


The nice complementary effect is, that the bridge can first sieve
out those IP packets thanks to IGMP/MLD snooping knowledge and for
anything else, like ARP, 224.0.0.x or ff02::1, the mac80211
multicast-to-unicast could do its job.


For APs with a small number of STAs (like your private home AP),
you might want to enable both bridge multicast-to-unicast and
mac80211 multicast-to-unicast for this complementary effect. While
on public APs with 30 to 50 STAs with varying distances and bitrates,
you might only one to enable the bridge one, because sending an ARP
packet 50x might actually reduce performance and airtime
significantly.


[PATCH v2 net-next 1/4] siphash: add cryptographically secure PRF

2017-01-07 Thread Jason A. Donenfeld
SipHash is a 64-bit keyed hash function that is actually a
cryptographically secure PRF, like HMAC. Except SipHash is super fast,
and is meant to be used as a hashtable keyed lookup function, or as a
general PRF for short input use cases, such as sequence numbers or RNG
chaining.

For the first usage:

There are a variety of attacks known as "hashtable poisoning" in which an
attacker forms some data such that the hash of that data will be the
same, and then preceeds to fill up all entries of a hashbucket. This is
a realistic and well-known denial-of-service vector. Currently
hashtables use jhash, which is fast but not secure, and some kind of
rotating key scheme (or none at all, which isn't good). SipHash is meant
as a replacement for jhash in these cases.

There are a modicum of places in the kernel that are vulnerable to
hashtable poisoning attacks, either via userspace vectors or network
vectors, and there's not a reliable mechanism inside the kernel at the
moment to fix it. The first step toward fixing these issues is actually
getting a secure primitive into the kernel for developers to use. Then
we can, bit by bit, port things over to it as deemed appropriate.

While SipHash is extremely fast for a cryptographically secure function,
it is likely a bit slower than the insecure jhash, and so replacements
will be evaluated on a case-by-case basis based on whether or not the
difference in speed is negligible and whether or not the current jhash usage
poses a real security risk.

For the second usage:

A few places in the kernel are using MD5 or SHA1 for creating secure
sequence numbers, syn cookies, port numbers, or fast random numbers.
SipHash is a faster and more fitting, and more secure replacement for MD5
in those situations. Replacing MD5 and SHA1 with SipHash for these uses is
obvious and straight-forward, and so is submitted along with this patch
series. There shouldn't be much of a debate over its efficacy.

Dozens of languages are already using this internally for their hash
tables and PRFs. Some of the BSDs already use this in their kernels.
SipHash is a widely known high-speed solution to a widely known set of
problems, and it's time we catch-up.

Signed-off-by: Jason A. Donenfeld 
Reviewed-by: Jean-Philippe Aumasson 
Cc: Linus Torvalds 
Cc: Eric Biggers 
Cc: David Laight 
Cc: Eric Dumazet 
---
 Documentation/siphash.txt |  79 
 MAINTAINERS   |   7 ++
 include/linux/siphash.h   |  85 +
 lib/Kconfig.debug |   6 +-
 lib/Makefile  |   5 +-
 lib/siphash.c | 232 ++
 lib/test_siphash.c| 131 ++
 7 files changed, 540 insertions(+), 5 deletions(-)
 create mode 100644 Documentation/siphash.txt
 create mode 100644 include/linux/siphash.h
 create mode 100644 lib/siphash.c
 create mode 100644 lib/test_siphash.c

diff --git a/Documentation/siphash.txt b/Documentation/siphash.txt
new file mode 100644
index ..e540ab14eb8f
--- /dev/null
+++ b/Documentation/siphash.txt
@@ -0,0 +1,79 @@
+ SipHash - a short input PRF
+---
+Written by Jason A. Donenfeld 
+
+SipHash is a cryptographically secure PRF -- a keyed hash function -- that
+performs very well for short inputs, hence the name. It was designed by
+cryptographers Daniel J. Bernstein and Jean-Philippe Aumasson. It is intended
+as a replacement for some uses of: `jhash`, `md5_transform`, `sha_transform`,
+and so forth.
+
+SipHash takes a secret key filled with randomly generated numbers and either
+an input buffer or several input integers. It spits out an integer that is
+indistinguishable from random. You may then use that integer as part of secure
+sequence numbers, secure cookies, or mask it off for use in a hash table.
+
+1. Generating a key
+
+Keys should always be generated from a cryptographically secure source of
+random numbers, either using get_random_bytes or get_random_once:
+
+siphash_key_t key;
+get_random_bytes(, sizeof(key));
+
+If you're not deriving your key from here, you're doing it wrong.
+
+2. Using the functions
+
+There are two variants of the function, one that takes a list of integers, and
+one that takes a buffer:
+
+u64 siphash(const void *data, size_t len, const siphash_key_t *key);
+
+And:
+
+u64 siphash_1u64(u64, const siphash_key_t *key);
+u64 siphash_2u64(u64, u64, const siphash_key_t *key);
+u64 siphash_3u64(u64, u64, u64, const siphash_key_t *key);
+u64 siphash_4u64(u64, u64, u64, u64, const siphash_key_t *key);
+u64 siphash_1u32(u32, const siphash_key_t *key);
+u64 siphash_2u32(u32, u32, const siphash_key_t *key);
+u64 siphash_3u32(u32, u32, u32, const siphash_key_t *key);
+u64 siphash_4u32(u32, u32, u32, u32, const siphash_key_t *key);
+
+If you 

[PATCH v2 net-next 4/4] syncookies: use SipHash in place of SHA1

2017-01-07 Thread Jason A. Donenfeld
SHA1 is slower and less secure than SipHash, and so replacing syncookie
generation with SipHash makes natural sense. Some BSDs have been doing
this for several years in fact.

The speedup should be similar -- and even more impressive -- to the
speedup from the sequence number fix in this series.

Signed-off-by: Jason A. Donenfeld 
Cc: Eric Dumazet 
Cc: David Miller 
---
 net/ipv4/syncookies.c | 21 +
 net/ipv6/syncookies.c | 41 +++--
 2 files changed, 24 insertions(+), 38 deletions(-)

diff --git a/net/ipv4/syncookies.c b/net/ipv4/syncookies.c
index 3e88467d70ee..496b97e17aaf 100644
--- a/net/ipv4/syncookies.c
+++ b/net/ipv4/syncookies.c
@@ -13,13 +13,13 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
 #include 
 
-static u32 syncookie_secret[2][16-4+SHA_DIGEST_WORDS] __read_mostly;
+static siphash_key_t syncookie_secret[2] __read_mostly;
 
 #define COOKIEBITS 24  /* Upper bits store count */
 #define COOKIEMASK (((__u32)1 << COOKIEBITS) - 1)
@@ -48,24 +48,13 @@ static u32 syncookie_secret[2][16-4+SHA_DIGEST_WORDS] 
__read_mostly;
 #define TSBITS 6
 #define TSMASK (((__u32)1 << TSBITS) - 1)
 
-static DEFINE_PER_CPU(__u32 [16 + 5 + SHA_WORKSPACE_WORDS], 
ipv4_cookie_scratch);
-
 static u32 cookie_hash(__be32 saddr, __be32 daddr, __be16 sport, __be16 dport,
   u32 count, int c)
 {
-   __u32 *tmp;
-
net_get_random_once(syncookie_secret, sizeof(syncookie_secret));
-
-   tmp  = this_cpu_ptr(ipv4_cookie_scratch);
-   memcpy(tmp + 4, syncookie_secret[c], sizeof(syncookie_secret[c]));
-   tmp[0] = (__force u32)saddr;
-   tmp[1] = (__force u32)daddr;
-   tmp[2] = ((__force u32)sport << 16) + (__force u32)dport;
-   tmp[3] = count;
-   sha_transform(tmp + 16, (__u8 *)tmp, tmp + 16 + 5);
-
-   return tmp[17];
+   return siphash_4u32((__force u32)saddr, (__force u32)daddr,
+   (__force u32)sport << 16 | (__force u32)dport,
+   count, _secret[c]);
 }
 
 
diff --git a/net/ipv6/syncookies.c b/net/ipv6/syncookies.c
index a4d49760bf43..895ff650db43 100644
--- a/net/ipv6/syncookies.c
+++ b/net/ipv6/syncookies.c
@@ -16,7 +16,7 @@
 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
@@ -24,7 +24,7 @@
 #define COOKIEBITS 24  /* Upper bits store count */
 #define COOKIEMASK (((__u32)1 << COOKIEBITS) - 1)
 
-static u32 syncookie6_secret[2][16-4+SHA_DIGEST_WORDS] __read_mostly;
+static siphash_key_t syncookie6_secret[2] __read_mostly;
 
 /* RFC 2460, Section 8.3:
  * [ipv6 tcp] MSS must be computed as the maximum packet size minus 60 [..]
@@ -41,30 +41,27 @@ static __u16 const msstab[] = {
9000 - 60,
 };
 
-static DEFINE_PER_CPU(__u32 [16 + 5 + SHA_WORKSPACE_WORDS], 
ipv6_cookie_scratch);
-
-static u32 cookie_hash(const struct in6_addr *saddr, const struct in6_addr 
*daddr,
+static u32 cookie_hash(const struct in6_addr *saddr,
+  const struct in6_addr *daddr,
   __be16 sport, __be16 dport, u32 count, int c)
 {
-   __u32 *tmp;
+   const struct {
+   struct in6_addr saddr;
+   struct in6_addr daddr;
+   u32 count;
+   __be16 sport;
+   __be16 dport;
+   } __aligned(SIPHASH_ALIGNMENT) combined = {
+   .saddr = *saddr,
+   .daddr = *daddr,
+   .count = count,
+   .sport = sport,
+   .dport = dport
+   };
 
net_get_random_once(syncookie6_secret, sizeof(syncookie6_secret));
-
-   tmp  = this_cpu_ptr(ipv6_cookie_scratch);
-
-   /*
-* we have 320 bits of information to hash, copy in the remaining
-* 192 bits required for sha_transform, from the syncookie6_secret
-* and overwrite the digest with the secret
-*/
-   memcpy(tmp + 10, syncookie6_secret[c], 44);
-   memcpy(tmp, saddr, 16);
-   memcpy(tmp + 4, daddr, 16);
-   tmp[8] = ((__force u32)sport << 16) + (__force u32)dport;
-   tmp[9] = count;
-   sha_transform(tmp + 16, (__u8 *)tmp, tmp + 16 + 5);
-
-   return tmp[17];
+   return siphash(, offsetofend(typeof(combined), dport),
+  _secret[c]);
 }
 
 static __u32 secure_tcp_syn_cookie(const struct in6_addr *saddr,
-- 
2.11.0



[PATCH v2 net-next 3/4] secure_seq: use SipHash in place of MD5

2017-01-07 Thread Jason A. Donenfeld
This gives a clear speed and security improvement. Siphash is both
faster and is more solid crypto than the aging MD5.

Rather than manually filling MD5 buffers, for IPv6, we simply create
a layout by a simple anonymous struct, for which gcc generates
rather efficient code. For IPv4, we pass the values directly to the
short input convenience functions.

64-bit x86_64:
[1.683628] secure_tcpv6_sequence_number_md5# cycles: 99563527
[1.717350] secure_tcp_sequence_number_md5# cycles: 92890502
[1.741968] secure_tcpv6_sequence_number_siphash# cycles: 67825362
[1.762048] secure_tcp_sequence_number_siphash# cycles: 67485526

32-bit x86:
[1.600012] secure_tcpv6_sequence_number_md5# cycles: 103227892
[1.634219] secure_tcp_sequence_number_md5# cycles: 94732544
[1.669102] secure_tcpv6_sequence_number_siphash# cycles: 96299384
[1.700165] secure_tcp_sequence_number_siphash# cycles: 86015473

Signed-off-by: Jason A. Donenfeld 
Cc: Andi Kleen 
Cc: David Miller 
Cc: David Laight 
Cc: Tom Herbert 
Cc: Hannes Frederic Sowa 
Cc: Eric Dumazet 
---
 net/core/secure_seq.c | 145 ++
 1 file changed, 63 insertions(+), 82 deletions(-)

diff --git a/net/core/secure_seq.c b/net/core/secure_seq.c
index 88a8e429fc3e..119e3ebe2f30 100644
--- a/net/core/secure_seq.c
+++ b/net/core/secure_seq.c
@@ -1,3 +1,7 @@
+/*
+ * Copyright (C) 2016 Jason A. Donenfeld . All Rights 
Reserved.
+ */
+
 #include 
 #include 
 #include 
@@ -8,18 +12,18 @@
 #include 
 #include 
 #include 
-
+#include 
 #include 
 
 #if IS_ENABLED(CONFIG_IPV6) || IS_ENABLED(CONFIG_INET)
+#include 
 #include 
-#define NET_SECRET_SIZE (MD5_MESSAGE_BYTES / 4)
 
-static u32 net_secret[NET_SECRET_SIZE] cacheline_aligned;
+static siphash_key_t net_secret;
 
 static __always_inline void net_secret_init(void)
 {
-   net_get_random_once(net_secret, sizeof(net_secret));
+   net_get_random_once(_secret, sizeof(net_secret));
 }
 #endif
 
@@ -44,80 +48,70 @@ static u32 seq_scale(u32 seq)
 u32 secure_tcpv6_sequence_number(const __be32 *saddr, const __be32 *daddr,
 __be16 sport, __be16 dport, u32 *tsoff)
 {
-   u32 secret[MD5_MESSAGE_BYTES / 4];
-   u32 hash[MD5_DIGEST_WORDS];
-   u32 i;
-
+   const struct {
+   struct in6_addr saddr;
+   struct in6_addr daddr;
+   __be16 sport;
+   __be16 dport;
+   } __aligned(SIPHASH_ALIGNMENT) combined = {
+   .saddr = *(struct in6_addr *)saddr,
+   .daddr = *(struct in6_addr *)daddr,
+   .sport = sport,
+   .dport = dport
+   };
+   u64 hash;
net_secret_init();
-   memcpy(hash, saddr, 16);
-   for (i = 0; i < 4; i++)
-   secret[i] = net_secret[i] + (__force u32)daddr[i];
-   secret[4] = net_secret[4] +
-   (((__force u16)sport << 16) + (__force u16)dport);
-   for (i = 5; i < MD5_MESSAGE_BYTES / 4; i++)
-   secret[i] = net_secret[i];
-
-   md5_transform(hash, secret);
-
-   *tsoff = sysctl_tcp_timestamps == 1 ? hash[1] : 0;
-   return seq_scale(hash[0]);
+   hash = siphash(, offsetofend(typeof(combined), dport),
+  _secret);
+   *tsoff = sysctl_tcp_timestamps == 1 ? (hash >> 32) : 0;
+   return seq_scale(hash);
 }
 EXPORT_SYMBOL(secure_tcpv6_sequence_number);
 
 u32 secure_ipv6_port_ephemeral(const __be32 *saddr, const __be32 *daddr,
   __be16 dport)
 {
-   u32 secret[MD5_MESSAGE_BYTES / 4];
-   u32 hash[MD5_DIGEST_WORDS];
-   u32 i;
-
+   const struct {
+   struct in6_addr saddr;
+   struct in6_addr daddr;
+   __be16 dport;
+   } __aligned(SIPHASH_ALIGNMENT) combined = {
+   .saddr = *(struct in6_addr *)saddr,
+   .daddr = *(struct in6_addr *)daddr,
+   .dport = dport
+   };
net_secret_init();
-   memcpy(hash, saddr, 16);
-   for (i = 0; i < 4; i++)
-   secret[i] = net_secret[i] + (__force u32) daddr[i];
-   secret[4] = net_secret[4] + (__force u32)dport;
-   for (i = 5; i < MD5_MESSAGE_BYTES / 4; i++)
-   secret[i] = net_secret[i];
-
-   md5_transform(hash, secret);
-
-   return hash[0];
+   return siphash(, offsetofend(typeof(combined), dport),
+  _secret);
 }
 EXPORT_SYMBOL(secure_ipv6_port_ephemeral);
 #endif
 
 #ifdef CONFIG_INET
 
+/* secure_tcp_sequence_number(a, b, 0, d) == secure_ipv4_port_ephemeral(a, b, 
d),
+ * but fortunately, `sport' cannot be 0 in any circumstances. If this changes,
+ * it would be easy enough to have the former function use siphash_4u32, 
passing
+ * the arguments as separate u32.
+ */
+
 u32 

[PATCH v2 net-next 2/4] siphash: implement HalfSipHash1-3 for hash tables

2017-01-07 Thread Jason A. Donenfeld
HalfSipHash, or hsiphash, is a shortened version of SipHash, which
generates 32-bit outputs using a weaker 64-bit key. It has *much* lower
security margins, and shouldn't be used for anything too sensitive, but
it could be used as a hashtable key function replacement, if the output
is never exposed, and if the security requirement is not too high.

The goal is to make this something that performance-critical jhash users
would be willing to use.

On 64-bit machines, HalfSipHash1-3 is slower than SipHash1-3, so we alias
SipHash1-3 to HalfSipHash1-3 on those systems.

64-bit x86_64:
[0.509409] test_siphash: SipHash2-4 cycles: 4049181
[0.510650] test_siphash: SipHash1-3 cycles: 2512884
[0.512205] test_siphash: HalfSipHash1-3 cycles: 3429920
[0.512904] test_siphash:JenkinsHash cycles:  978267
So, we map hsiphash() -> SipHash1-3

32-bit x86:
[0.509868] test_siphash: SipHash2-4 cycles: 14812892
[0.513601] test_siphash: SipHash1-3 cycles:  9510710
[0.515263] test_siphash: HalfSipHash1-3 cycles:  3856157
[0.515952] test_siphash:JenkinsHash cycles:  1148567
So, we map hsiphash() -> HalfSipHash1-3

hsiphash() is roughly 3 times slower than jhash(), but comes with a
considerable security improvement.

Signed-off-by: Jason A. Donenfeld 
Reviewed-by: Jean-Philippe Aumasson 
---
 Documentation/siphash.txt |  75 +++
 include/linux/siphash.h   |  62 -
 lib/siphash.c | 321 +-
 lib/test_siphash.c|  98 +-
 4 files changed, 551 insertions(+), 5 deletions(-)

diff --git a/Documentation/siphash.txt b/Documentation/siphash.txt
index e540ab14eb8f..4a229a1f53e5 100644
--- a/Documentation/siphash.txt
+++ b/Documentation/siphash.txt
@@ -77,3 +77,78 @@ Linux implements the "2-4" variant of SipHash.
 
 Read the SipHash paper if you're interested in learning more:
 https://131002.net/siphash/siphash.pdf
+
+
+~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~
+
+HalfSipHash - SipHash's insecure younger cousin
+---
+Written by Jason A. Donenfeld 
+
+On the off-chance that SipHash is not fast enough for your needs, you might be
+able to justify using HalfSipHash, a terrifying but potentially useful
+possibility. HalfSipHash cuts SipHash's rounds down from "2-4" to "1-3" and,
+even scarier, uses an easily brute-forcable 64-bit key (with a 32-bit output)
+instead of SipHash's 128-bit key. However, this may appeal to some
+high-performance `jhash` users.
+
+Danger!
+
+Do not ever use HalfSipHash except for as a hashtable key function, and only
+then when you can be absolutely certain that the outputs will never be
+transmitted out of the kernel. This is only remotely useful over `jhash` as a
+means of mitigating hashtable flooding denial of service attacks.
+
+1. Generating a key
+
+Keys should always be generated from a cryptographically secure source of
+random numbers, either using get_random_bytes or get_random_once:
+
+hsiphash_key_t key;
+get_random_bytes(, sizeof(key));
+
+If you're not deriving your key from here, you're doing it wrong.
+
+2. Using the functions
+
+There are two variants of the function, one that takes a list of integers, and
+one that takes a buffer:
+
+u32 hsiphash(const void *data, size_t len, const siphash_key_t *key);
+
+And:
+
+u32 hsiphash_1u32(u32, const hsiphash_key_t *key);
+u32 hsiphash_2u32(u32, u32, const hsiphash_key_t *key);
+u32 hsiphash_3u32(u32, u32, u32, const hsiphash_key_t *key);
+u32 hsiphash_4u32(u32, u32, u32, u32, const hsiphash_key_t *key);
+
+If you pass the generic hsiphash function something of a constant length, it
+will constant fold at compile-time and automatically choose one of the
+optimized functions.
+
+3. Hashtable key function usage:
+
+struct some_hashtable {
+   DECLARE_HASHTABLE(hashtable, 8);
+   hsiphash_key_t key;
+};
+
+void init_hashtable(struct some_hashtable *table)
+{
+   get_random_bytes(>key, sizeof(table->key));
+}
+
+static inline hlist_head *some_hashtable_bucket(struct some_hashtable *table, 
struct interesting_input *input)
+{
+   return >hashtable[hsiphash(input, sizeof(*input), >key) & 
(HASH_SIZE(table->hashtable) - 1)];
+}
+
+You may then iterate like usual over the returned hash bucket.
+
+4. Performance
+
+HalfSipHash is roughly 3 times slower than JenkinsHash. For many replacements,
+this will not be a problem, as the hashtable lookup isn't the bottleneck. And
+in general, this is probably a good sacrifice to make for the security and DoS
+resistance of HalfSipHash.
diff --git a/include/linux/siphash.h b/include/linux/siphash.h
index feeb29cd113e..59dccdaff4f5 100644
--- a/include/linux/siphash.h
+++ b/include/linux/siphash.h
@@ -5,7 +5,9 @@
  * SipHash: a fast short-input PRF
  * https://131002.net/siphash/
  *
- * This implementation is specifically for 

Re: [PATCHv2 net-next 11/16] net: mvpp2: handle misc PPv2.1/PPv2.2 differences

2017-01-07 Thread Russell King - ARM Linux
On Sat, Jan 07, 2017 at 01:12:35PM +0100, Marcin Wojtas wrote:
> In fact there is common SMI bus, but each port has its own register
> set to control it (it's true at least for Neta and PP2). There is also
> an option to use HW polling - every 1s hardware checks PHY over SMI
> and updates MAC registers of each port independently. I was able to
> use those successfully in other implementations.
> 
> However we are supposed to use libphy in Linux and I'm afraid we have
> to use single instance that controls single SMI bus - I think current
> implementation is a compromise between HW and libphy demands.

One of the "DT rules" is that DT only describes the hardware in an
implementation independent way.  It should not describe a particular
implementation's view of the hardware.

"libphy demands" sounds very much like an implementation dictating
the DT description, which sounds to me very wrong and against the
goals and purposes of DT.

Anyway, I don't think it's too bad - a possible solution here would
be to have the existing MDIO driver as a library, which can be
instantiated by the Neta and PP2 drivers.  This could be done in
DT (taking dove as an example) as:

eth: ethernet-ctrl@72000 {
compatible = "marvell,orion-eth";
reg = <0x72000 0x4000>;
ranges = <0 0x72000 0 0x4000>;
...
mdio: mdio@4 {
compatible = "marvell,orion-mdio";
reg = <4>;
...
... phys ...
};
};

I don't think that would require that big a change - and it could be
done in a way that compatibility with the existing DT descriptions is
maintained very cheaply.

Now, I'm not suggesting that mdio@4 should be created by a platform
device via marking ethernet-ctrl@72000 with "simple-bus", but it's
something that should be created by the ethernet driver if present.
The compatible string is there so we can identify that this is a
mdio node, and which type of mdio it is (the Armada 8k has this type
and a separate clause-45 xmdio implementation, and we need to
distinguish those.)

What that means is that we no longer have to worry about clocks and
overlapping register regions and the like, and can deal with the
ethernet driver wanting to access the SMI registers as well.

We would need the ethernet driver to be capable of instantiation even
with no ports enabled, so cases where the MDIO interface is used with
other ethernet controllers continues to be supportable (eg, the
Armada 8040 case where the slave CP110 ethernet controller is used
with PHYs connected to the master CP110 ethernet controller's MDIO
buses - which afaik aren't shared between the two CP110 dies.)

However, I'd like to see libphy become more flexible and support
hardware polled mode of operation, since libphy provides a nice
library of functions for accessing various phy features (like setting
the advertisment, EEE modes, flow control, etc.)  Even with hardware
polling, we should still describe the PHY in DT, because PHY is part
of the hardware description, and we need to know where it is in order
to program these phy features.

-- 
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 1/4] siphash: add cryptographically secure PRF

2017-01-07 Thread Jason A. Donenfeld
Hi Eric,

Thanks for the review. I wish we had gotten to this much earlier
before the merge, when there were quite a few revisions and
refinements, but better late than never, and I'm quite pleased to have
your feedback for making this patchset perfect. Comments are inline
below.

On Sat, Jan 7, 2017 at 5:04 AM, Eric Biggers  wrote:
> I was confused by all the functions passing siphash_key_t "by value" until I 
> saw
> that it's actually typedefed to u64[2].  Have you considered making it a 
> struct
> instead, something like this?
>
> typedef struct {
> u64 v[2];
> } siphash_key_t;

That's a good idea. I'll make this change.

>
>> +static inline u64 ___siphash_aligned(const __le64 *data, size_t len, const 
>> siphash_key_t key)
>> +{
>> + if (__builtin_constant_p(len) && len == 4)
>> + return siphash_1u32(le32_to_cpu(data[0]), key);
>
> Small bug here: data[0] is not valid if len is 4.  This can be fixed by 
> casting
> to a le32 pointer:
>
> return siphash_1u32(le32_to_cpup((const __le32 *)data), key);

Since data[0] is then passed to a function that takes a u32, gcc
actually does the right thing here and doesn't generate an out of
bounds read. But of course this isn't good behavior to rely on. I'll
fix this up. Thanks for catching it.

>
>> +static int __init siphash_test_init(void)
>> +{
>> + u8 in[64] __aligned(SIPHASH_ALIGNMENT);
>> + u8 in_unaligned[65];
>
> It seems that in_unaligned+1 is meant to be misaligned, but that's not
> guaranteed because in_unaligned has no alignment restriction, so it could
> theoretically be misaligned in a way that makes in_unaligned+1 aligned.  So it
> should be 'in_unaligned[65] __aligned(SIPHASH_ALIGNMENT)'.

Thanks, will do.

>
> There are also a lot of checkpatch warnings produced by this patch.  It looks
> like many of them can be ignored, but there may be some that should be
> addressed.

Will have a look and address for v2.

Thanks again for your review!

Regards,
Jason


Re: [next PATCH 04/11] ixgbe: Update code to better handle incrementing page count

2017-01-07 Thread kbuild test robot
Hi Alexander,

[auto build test ERROR on jkirsher-next-queue/dev-queue]
[also build test ERROR on v4.10-rc2 next-20170106]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Alexander-Duyck/ixgbe-Add-support-for-writable-pages-and-build_skb/20170107-193738
base:   https://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue.git 
dev-queue
config: alpha-allyesconfig (attached as .config)
compiler: alpha-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=alpha 

All errors (new ones prefixed by >>):

   In file included from drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:60:0:
   drivers/net/ethernet/intel/ixgbe/ixgbe_main.c: In function 
'ixgbe_can_reuse_rx_page':
   drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:1960:46: error: 'rx_ring' 
undeclared (first use in this function)
 unsigned int last_offset = ixgbe_rx_pg_size(rx_ring) -
 ^
   drivers/net/ethernet/intel/ixgbe/ixgbe.h:371:65: note: in definition of 
macro 'ixgbe_rx_pg_size'
#define ixgbe_rx_pg_size(_ring) (PAGE_SIZE << ixgbe_rx_pg_order(_ring))
^
   drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:1960:46: note: each undeclared 
identifier is reported only once for each function it appears in
 unsigned int last_offset = ixgbe_rx_pg_size(rx_ring) -
 ^
   drivers/net/ethernet/intel/ixgbe/ixgbe.h:371:65: note: in definition of 
macro 'ixgbe_rx_pg_size'
#define ixgbe_rx_pg_size(_ring) (PAGE_SIZE << ixgbe_rx_pg_order(_ring))
^
   drivers/net/ethernet/intel/ixgbe/ixgbe_main.c: In function 
'ixgbe_fetch_rx_buffer':
>> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:2124:3: error: implicit 
>> declaration of function '__page_frag_cache_drain' 
>> [-Werror=implicit-function-declaration]
  __page_frag_cache_drain(page,
  ^~~
   cc1: some warnings being treated as errors

vim +/__page_frag_cache_drain +2124 
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c

  1954  
  1955  static bool ixgbe_can_reuse_rx_page(struct ixgbe_rx_buffer *rx_buffer,
  1956  struct page *page,
  1957  const unsigned int truesize)
  1958  {
  1959  #if (PAGE_SIZE >= 8192)
> 1960  unsigned int last_offset = ixgbe_rx_pg_size(rx_ring) -
  1961 ixgbe_rx_bufsz(rx_ring);
  1962  #endif
  1963  unsigned int pagecnt_bias = rx_buffer->pagecnt_bias--;
  1964  
  1965  /* avoid re-using remote pages */
  1966  if (unlikely(ixgbe_page_is_reserved(page)))
  1967  return false;
  1968  
  1969  #if (PAGE_SIZE < 8192)
  1970  /* if we are only owner of page we can reuse it */
  1971  if (unlikely(page_count(page) != pagecnt_bias))
  1972  return false;
  1973  
  1974  /* flip page offset to other buffer */
  1975  rx_buffer->page_offset ^= truesize;
  1976  #else
  1977  /* move offset up to the next cache line */
  1978  rx_buffer->page_offset += truesize;
  1979  
  1980  if (rx_buffer->page_offset > last_offset)
  1981  return false;
  1982  #endif
  1983  
  1984  /* If we have drained the page fragment pool we need to update
  1985   * the pagecnt_bias and page count so that we fully restock the
  1986   * number of references the driver holds.
  1987   */
  1988  if (unlikely(pagecnt_bias == 1)) {
  1989  page_ref_add(page, USHRT_MAX);
  1990  rx_buffer->pagecnt_bias = USHRT_MAX;
  1991  }
  1992  
  1993  return true;
  1994  }
  1995  
  1996  /**
  1997   * ixgbe_add_rx_frag - Add contents of Rx buffer to sk_buff
  1998   * @rx_ring: rx descriptor ring to transact packets on
  1999   * @rx_buffer: buffer containing page to add
  2000   * @rx_desc: descriptor containing length of buffer written by hardware
  2001   * @skb: sk_buff to place the data into
  2002   *
  2003   * This function will add the data contained in rx_buffer->page to the 
skb.
  2004   * This is done either through a direct copy if the data in the buffer 
is
  2005   * less than the skb header size, otherwise it will just attach the 
page as
  2006   * a frag to the skb.
  2007   *
  2008   * The function will then update the page offset if necessary and return
  2009   * true if the buffer can be reused by the 

Re: [PATCHv1 6/7] TAP: tap as an independent module

2017-01-07 Thread kbuild test robot
Hi Sainath,

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

url:
https://github.com/0day-ci/linux/commits/Sainath-Grandhi/Refactor-macvtap-to-re-use-tap-functionality-by-other-virtual-intefaces/20170107-165707
config: x86_64-allyesdebian (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/built-in.o: In function `macvtap_dellink':
>> macvtap.c:(.text+0x7d3255): undefined reference to `tap_del_queues'
   drivers/built-in.o: In function `macvtap_exit':
>> macvtap.c:(.text+0x7d32e2): undefined reference to `tap_destroy_cdev'
   drivers/built-in.o: In function `macvtap_init':
>> macvtap.c:(.text+0x7d3308): undefined reference to `tap_create_cdev'
   drivers/built-in.o: In function `macvtap_newlink':
>> macvtap.c:(.text+0x7d33df): undefined reference to `tap_handle_frame'
   drivers/built-in.o: In function `macvtap_device_event':
>> macvtap.c:(.text+0x7d34b5): undefined reference to `tap_get_minor'
>> macvtap.c:(.text+0x7d34fe): undefined reference to `tap_free_minor'
   macvtap.c:(.text+0x7d3586): undefined reference to `tap_free_minor'
>> macvtap.c:(.text+0x7d3594): undefined reference to `tap_queue_resize'
   drivers/built-in.o: In function `vhost_net_ioctl':
   net.c:(.text+0x11835a3): undefined reference to `tap_get_socket'

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


.config.gz
Description: application/gzip


Re: [PATCHv2 net-next 11/16] net: mvpp2: handle misc PPv2.1/PPv2.2 differences

2017-01-07 Thread Marcin Wojtas
Hi Russel,

2017-01-07 12:03 GMT+01:00 Russell King - ARM Linux :
> On Wed, Dec 28, 2016 at 05:46:27PM +0100, Thomas Petazzoni wrote:
>> +#define MVPP22_SMI_MISC_CFG_REG  0x2a204
>> +#define  MVPP22_SMI_POLLING_EN   BIT(10)
>> +
> ...
>> + if (priv->hw_version == MVPP21) {
>> + val = readl(priv->lms_base + MVPP2_PHY_AN_CFG0_REG);
>> + val |= MVPP2_PHY_AN_STOP_SMI0_MASK;
>> + writel(val, priv->lms_base + MVPP2_PHY_AN_CFG0_REG);
>> + } else {
>> + val = readl(priv->iface_base + MVPP22_SMI_MISC_CFG_REG);
>> + val &= ~MVPP22_SMI_POLLING_EN;
>> + writel(val, priv->iface_base + MVPP22_SMI_MISC_CFG_REG);
>> + }
>
> The MVPP22_SMI_MISC_CFG_REG register is within the MDIO driver's
> register set, although the mvmdio driver does not access this register.
> Shouldn't this be taken care of by the mvmdio driver?
>
> Also, a point that I've noticed while reviewing this is the mvmdio
> driver also accesses these registers:
>
> #define MVMDIO_ERR_INT_CAUSE   0x007C
> #define MVMDIO_ERR_INT_MASK0x0080
>
> in addition to the un-named register at offset 0.  The driver writes
> to these registers unconditionally when unbinding:
>
> writel(0, dev->regs + MVMDIO_ERR_INT_MASK);
>
> However, the various bindings for the driver have:
>
> arch/arm/boot/dts/armada-370-xp.dtsi:  compatible = "marvell,orion-mdio";
> arch/arm/boot/dts/armada-370-xp.dtsi-  reg = <0x72004 0x4>;
> arch/arm/boot/dts/armada-375.dtsi: compatible = "marvell,orion-mdio";
> arch/arm/boot/dts/armada-375.dtsi- reg = <0xc0054 0x4>;
> arch/arm/boot/dts/dove.dtsi:   compatible = "marvell,orion-mdio";
> arch/arm/boot/dts/dove.dtsi-   #address-cells = <1>;
> arch/arm/boot/dts/dove.dtsi-   #size-cells = <0>;
> arch/arm/boot/dts/dove.dtsi-   reg = <0x72004 0x84>;
> arch/arm/boot/dts/orion5x.dtsi:compatible = "marvell,orion-mdio";
> arch/arm/boot/dts/orion5x.dtsi-#address-cells = <1>;
> arch/arm/boot/dts/orion5x.dtsi-#size-cells = <0>;
> arch/arm/boot/dts/orion5x.dtsi-reg = <0x72004 0x84>;
> arch/arm/boot/dts/kirkwood.dtsi:   compatible = "marvell,orion-mdio";
> arch/arm/boot/dts/kirkwood.dtsi-   #address-cells = <1>;
> arch/arm/boot/dts/kirkwood.dtsi-   #size-cells = <0>;
> arch/arm/boot/dts/kirkwood.dtsi-   reg = <0x72004 0x84>;
> arch/arm/boot/dts/armada-38x.dtsi: compatible = "marvell,orion-mdio";
> arch/arm/boot/dts/armada-38x.dtsi- reg = <0x72004 0x4>;
>
> So, for many of these, we're accessing registers outside of the given
> binding, which sounds incorrect.  I guess that write should be
> conditional upon an interrupt being present.
>
> The binding document says:
>
> - reg: address and length of the SMI register
>
> which is clearly wrong for those cases where the interrupt is used.
>
> I also notice that the binding for CP110 uses a register size of 0x10
> (even in your tree) - but I guess this should be 4.
>
> I'm starting to wonder whether the orion-mdio driver really is a
> separate chunk of hardware that warrants a separate description in
> DT from the ethernet controller - it appears in all cases to be
> embedded with an ethernet controller, sharing its register space
> and at least some of the ethernet controllers clocks.  That says
> to me that it isn't an independent functional unit of hardware.
>

In fact there is common SMI bus, but each port has its own register
set to control it (it's true at least for Neta and PP2). There is also
an option to use HW polling - every 1s hardware checks PHY over SMI
and updates MAC registers of each port independently. I was able to
use those successfully in other implementations.

However we are supposed to use libphy in Linux and I'm afraid we have
to use single instance that controls single SMI bus - I think current
implementation is a compromise between HW and libphy demands.

Best regards,
Marcin


Re: [PATCHv1 2/7] TAP: Renaming tap related APIs, data structures, macros

2017-01-07 Thread kbuild test robot
Hi Sainath,

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

url:
https://github.com/0day-ci/linux/commits/Sainath-Grandhi/Refactor-macvtap-to-re-use-tap-functionality-by-other-virtual-intefaces/20170107-165707
config: x86_64-acpi-redef (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/built-in.o: In function `vhost_net_ioctl':
>> net.c:(.text+0x68e0b1): undefined reference to `tap_get_socket'

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


.config.gz
Description: application/gzip


[PATCH RFC 3/4] dt-bindings: correct marvell orion MDIO binding document

2017-01-07 Thread Russell King
Correct the Marvell Orion MDIO binding document to properly reflect the
cases where an interrupt is present.  Augment the examples to show this.

Signed-off-by: Russell King 
---
 .../devicetree/bindings/net/marvell-orion-mdio.txt  | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/marvell-orion-mdio.txt 
b/Documentation/devicetree/bindings/net/marvell-orion-mdio.txt
index 9417e54c26c0..ca733ff68ab9 100644
--- a/Documentation/devicetree/bindings/net/marvell-orion-mdio.txt
+++ b/Documentation/devicetree/bindings/net/marvell-orion-mdio.txt
@@ -7,7 +7,10 @@ interface.
 
 Required properties:
 - compatible: "marvell,orion-mdio"
-- reg: address and length of the SMI register
+- reg: address and length of the MDIO registers.  When an interrupt is
+  not present, the length is the size of the SMI register (4 bytes)
+  otherwise it must be 0x84 bytes to cover the interrupt control
+  registers.
 
 Optional properties:
 - interrupts: interrupt line number for the SMI error/done interrupt
@@ -17,7 +20,7 @@ The child nodes of the MDIO driver are the individual PHY 
devices
 connected to this MDIO bus. They must have a "reg" property given the
 PHY address on the MDIO bus.
 
-Example at the SoC level:
+Example at the SoC level without an interrupt property:
 
 mdio {
#address-cells = <1>;
@@ -26,6 +29,16 @@ mdio {
reg = <0xd0072004 0x4>;
 };
 
+Example with an interrupt property:
+
+mdio {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "marvell,orion-mdio";
+   reg = <0xd0072004 0x84>;
+   interrupts = <30>;
+};
+
 And at the board level:
 
 mdio {
-- 
2.7.4



[PATCH RFC 4/4] net: mvmdio: disable interrupt if resource size is too small

2017-01-07 Thread Russell King
Disable the MDIO interrupt, falling back to polled mode, if the resource
size does not allow us to access the interrupt registers.  All current
DT bindings use a size of 0x84, which allows access, but verifying it is
good practice.

Signed-off-by: Russell King 
---
 drivers/net/ethernet/marvell/mvmdio.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/net/ethernet/marvell/mvmdio.c 
b/drivers/net/ethernet/marvell/mvmdio.c
index 6ea5caddca62..614dfde657fe 100644
--- a/drivers/net/ethernet/marvell/mvmdio.c
+++ b/drivers/net/ethernet/marvell/mvmdio.c
@@ -221,6 +221,12 @@ static int orion_mdio_probe(struct platform_device *pdev)
clk_prepare_enable(dev->clk);
 
dev->err_interrupt = platform_get_irq(pdev, 0);
+   if (dev->err_interrupt > 0 &&
+   resource_size(r) < MVMDIO_ERR_INT_MASK + 4) {
+   dev_err(>dev,
+   "disabling interrupt, resource size is too small\n");
+   dev->err_interrupt = 0;
+   }
if (dev->err_interrupt > 0) {
ret = devm_request_irq(>dev, dev->err_interrupt,
orion_mdio_err_irq,
-- 
2.7.4



[PATCH RFC 2/4] net: mvmdio: fix interrupt disable in remove path

2017-01-07 Thread Russell King
The pre-existing write to disable interrupts on the remove path happens
whether we have an interrupt or not.  While this may seem to be a good
idea, this driver is re-used in many different implementations, some
where the binding only specifies four bytes of register space.  This
access causes us to access registers outside of the binding.

Make it conditional on the interrupt being present, which is the same
condition used when enabling the interrupt in the first place.

Signed-off-by: Russell King 
---
 drivers/net/ethernet/marvell/mvmdio.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/marvell/mvmdio.c 
b/drivers/net/ethernet/marvell/mvmdio.c
index 7aea0beca56e..6ea5caddca62 100644
--- a/drivers/net/ethernet/marvell/mvmdio.c
+++ b/drivers/net/ethernet/marvell/mvmdio.c
@@ -263,7 +263,8 @@ static int orion_mdio_remove(struct platform_device *pdev)
struct mii_bus *bus = platform_get_drvdata(pdev);
struct orion_mdio_dev *dev = bus->priv;
 
-   writel(0, dev->regs + MVMDIO_ERR_INT_MASK);
+   if (dev->err_interrupt > 0)
+   writel(0, dev->regs + MVMDIO_ERR_INT_MASK);
mdiobus_unregister(bus);
if (!IS_ERR(dev->clk))
clk_disable_unprepare(dev->clk);
-- 
2.7.4



[PATCH RFC 1/4] net: mvmdio: disable interrupts in driver failure path

2017-01-07 Thread Russell King
When the mvmdio driver has an interrupt, it enables the "done" interrupt
after requesting its interrupt handler.  However, probe failure results
in the interrupt being left enabled.  Disable it on the failure path.

Signed-off-by: Russell King 
---
 drivers/net/ethernet/marvell/mvmdio.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/ethernet/marvell/mvmdio.c 
b/drivers/net/ethernet/marvell/mvmdio.c
index a0d1b084ecec..7aea0beca56e 100644
--- a/drivers/net/ethernet/marvell/mvmdio.c
+++ b/drivers/net/ethernet/marvell/mvmdio.c
@@ -251,6 +251,8 @@ static int orion_mdio_probe(struct platform_device *pdev)
return 0;
 
 out_mdio:
+   if (dev->err_interrupt > 0)
+   writel(0, dev->regs + MVMDIO_ERR_INT_MASK);
if (!IS_ERR(dev->clk))
clk_disable_unprepare(dev->clk);
return ret;
-- 
2.7.4



[PATCH RFC 0/4] Fix orion-mdio resource/interrupt issues indentified while reviewing mvpp2

2017-01-07 Thread Russell King - ARM Linux
This patch series fixes some issues identified while reviewing the
mvpp2 driver changes recently posted by Thomas.  I've left the clock
issue, and the question over whether this should be separate out of
this series, concentrating on the resource size / interrupt issue.

This series updates the binding to reflect reality, and ensures that
the driver will not try to access registers outside its binding.  It
also ensures that it doesn't leave the interrupt enabled in hardware
on probe failure.

 .../devicetree/bindings/net/marvell-orion-mdio.txt  | 17 +++--
 drivers/net/ethernet/marvell/mvmdio.c   | 11 ++-
 2 files changed, 25 insertions(+), 3 deletions(-)

-- 
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: [PATCHv2 net-next 11/16] net: mvpp2: handle misc PPv2.1/PPv2.2 differences

2017-01-07 Thread Russell King - ARM Linux
On Wed, Dec 28, 2016 at 05:46:27PM +0100, Thomas Petazzoni wrote:
> +#define MVPP22_SMI_MISC_CFG_REG  0x2a204
> +#define  MVPP22_SMI_POLLING_EN   BIT(10)
> +
...
> + if (priv->hw_version == MVPP21) {
> + val = readl(priv->lms_base + MVPP2_PHY_AN_CFG0_REG);
> + val |= MVPP2_PHY_AN_STOP_SMI0_MASK;
> + writel(val, priv->lms_base + MVPP2_PHY_AN_CFG0_REG);
> + } else {
> + val = readl(priv->iface_base + MVPP22_SMI_MISC_CFG_REG);
> + val &= ~MVPP22_SMI_POLLING_EN;
> + writel(val, priv->iface_base + MVPP22_SMI_MISC_CFG_REG);
> + }

The MVPP22_SMI_MISC_CFG_REG register is within the MDIO driver's
register set, although the mvmdio driver does not access this register.
Shouldn't this be taken care of by the mvmdio driver?

Also, a point that I've noticed while reviewing this is the mvmdio
driver also accesses these registers:

#define MVMDIO_ERR_INT_CAUSE   0x007C
#define MVMDIO_ERR_INT_MASK0x0080

in addition to the un-named register at offset 0.  The driver writes
to these registers unconditionally when unbinding:

writel(0, dev->regs + MVMDIO_ERR_INT_MASK);

However, the various bindings for the driver have:

arch/arm/boot/dts/armada-370-xp.dtsi:  compatible = "marvell,orion-mdio";
arch/arm/boot/dts/armada-370-xp.dtsi-  reg = <0x72004 0x4>;
arch/arm/boot/dts/armada-375.dtsi: compatible = "marvell,orion-mdio";
arch/arm/boot/dts/armada-375.dtsi- reg = <0xc0054 0x4>;
arch/arm/boot/dts/dove.dtsi:   compatible = "marvell,orion-mdio";
arch/arm/boot/dts/dove.dtsi-   #address-cells = <1>;
arch/arm/boot/dts/dove.dtsi-   #size-cells = <0>;
arch/arm/boot/dts/dove.dtsi-   reg = <0x72004 0x84>;
arch/arm/boot/dts/orion5x.dtsi:compatible = "marvell,orion-mdio";
arch/arm/boot/dts/orion5x.dtsi-#address-cells = <1>;
arch/arm/boot/dts/orion5x.dtsi-#size-cells = <0>;
arch/arm/boot/dts/orion5x.dtsi-reg = <0x72004 0x84>;
arch/arm/boot/dts/kirkwood.dtsi:   compatible = "marvell,orion-mdio";
arch/arm/boot/dts/kirkwood.dtsi-   #address-cells = <1>;
arch/arm/boot/dts/kirkwood.dtsi-   #size-cells = <0>;
arch/arm/boot/dts/kirkwood.dtsi-   reg = <0x72004 0x84>;
arch/arm/boot/dts/armada-38x.dtsi: compatible = "marvell,orion-mdio";
arch/arm/boot/dts/armada-38x.dtsi- reg = <0x72004 0x4>;

So, for many of these, we're accessing registers outside of the given
binding, which sounds incorrect.  I guess that write should be
conditional upon an interrupt being present.

The binding document says:

- reg: address and length of the SMI register

which is clearly wrong for those cases where the interrupt is used.

I also notice that the binding for CP110 uses a register size of 0x10
(even in your tree) - but I guess this should be 4.

I'm starting to wonder whether the orion-mdio driver really is a
separate chunk of hardware that warrants a separate description in
DT from the ethernet controller - it appears in all cases to be
embedded with an ethernet controller, sharing its register space
and at least some of the ethernet controllers clocks.  That says
to me that it isn't an independent functional unit of hardware.

-- 
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: [PATCHv1 6/7] TAP: tap as an independent module

2017-01-07 Thread kbuild test robot
Hi Sainath,

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

url:
https://github.com/0day-ci/linux/commits/Sainath-Grandhi/Refactor-macvtap-to-re-use-tap-functionality-by-other-virtual-intefaces/20170107-165707
config: s390-default_defconfig (attached as .config)
compiler: s390x-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=s390 

All errors (new ones prefixed by >>):

   ERROR: "tap_get_socket" [drivers/vhost/vhost_net.ko] undefined!
>> ERROR: "tap_create_cdev" [drivers/net/macvtap.ko] undefined!
>> ERROR: "tap_queue_resize" [drivers/net/macvtap.ko] undefined!
>> ERROR: "tap_get_minor" [drivers/net/macvtap.ko] undefined!
>> ERROR: "tap_destroy_cdev" [drivers/net/macvtap.ko] undefined!
>> ERROR: "tap_handle_frame" [drivers/net/macvtap.ko] undefined!
>> ERROR: "tap_free_minor" [drivers/net/macvtap.ko] undefined!
>> ERROR: "tap_del_queues" [drivers/net/macvtap.ko] undefined!

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


.config.gz
Description: application/gzip


Re: [PATCH net-next] bridge: multicast to unicast

2017-01-07 Thread M. Braun
Am 06.01.2017 um 14:54 schrieb Johannes Berg:
> 
>> The bridge layer can use IGMP snooping to ensure that the multicast
>> stream is only transmitted to clients that are actually a member of
>> the group. Can the mac80211 feature do the same?
> 
> No, it'll convert the packet for all clients that are behind that
> netdev. But that's an argument for dropping the mac80211 feature, which
> hasn't been merged upstream yet, no?

But there is multicast/broadcast traffic like e.g. ARP and some IP
multicast groups that are not covered by IGMP snooping. The mac80211
patch converts this to unicast as well, which the bridge cannot do.

That way, these features both complement and overlap each other.

Regards,
Michael



Re: [PATCHv1 2/7] TAP: Renaming tap related APIs, data structures, macros

2017-01-07 Thread kbuild test robot
Hi Sainath,

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

url:
https://github.com/0day-ci/linux/commits/Sainath-Grandhi/Refactor-macvtap-to-re-use-tap-functionality-by-other-virtual-intefaces/20170107-165707
config: powerpc-defconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=powerpc 

All errors (new ones prefixed by >>):

>> ERROR: ".tap_get_socket" [drivers/vhost/vhost_net.ko] undefined!

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


.config.gz
Description: application/gzip


Re: [net-next PATCH] net: reduce cycles spend on ICMP replies that gets rate limited

2017-01-07 Thread Jesper Dangaard Brouer
On Fri, 06 Jan 2017 22:10:42 -0500 (EST)
David Miller  wrote:

> BTW Eric, you asked about kmalloc() allocation, you were CC:'d in the
> patch which did this :-)
> 
> commit 9a99d4a50cb8ce516adf0f2436138d4c8e6e4535
> Author: Cong Wang 
> Date:   Sun Jun 2 15:00:52 2013 +
> 
> icmp: avoid allocating large struct on stack
> 
> struct icmp_bxm is a large struct, reduce stack usage
> by allocating it on heap.
> 
> Cc: Eric Dumazet 
> Cc: Joe Perches 
> Cc: David S. Miller 
> Signed-off-by: Cong Wang 
> Signed-off-by: David S. Miller 

Did a quick revert, and tested again.  It is not the major bottleneck,
but we do save something.  The major bottleneck is still the call to
__ip_route_output_key_hash (invoked by icmp_route_lookup).

Single flow improvement from 1719182 pps to 1783368 pps.
 - 64186 pps
 - (1/1783368-1/1719182)*10^9 = -20.93 nanosec
   * 4GHz approx = 20.93*4 = 83.72 cycles

The optimal SLUB fast-path on this machine is 54 cycles(tsc) 13.557 ns,
thus the saving is actually higher than expected.  But low compared to
avoiding the icmp_route_lookup.

-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  LinkedIn: http://www.linkedin.com/in/brouer


Re: [PATCH v2 12/12] net: ethernet: aquantia: Receive side scaling

2017-01-07 Thread kbuild test robot
Hi David,

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

url:
https://github.com/0day-ci/linux/commits/Alexander-Loktionov/net-ethernet-aquantia-Add-AQtion-2-5-5-GB-NIC-driver/20170107-100651
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

   include/linux/compiler.h:253:8: sparse: attribute 'no_sanitize_address': 
unknown attribute
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked 
>> inline, but without a definition
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked 
>> inline, but without a definition
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked 
>> inline, but without a definition
--
   include/linux/compiler.h:253:8: sparse: attribute 'no_sanitize_address': 
unknown attribute
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked 
>> inline, but without a definition
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked 
>> inline, but without a definition
--
   include/linux/compiler.h:253:8: sparse: attribute 'no_sanitize_address': 
unknown attribute
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked 
>> inline, but without a definition
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked 
>> inline, but without a definition
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked 
>> inline, but without a definition
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked 
>> inline, but without a definition
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked 
>> inline, but without a definition
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked 
>> inline, but without a definition
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked 
>> inline, but without a definition
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked 
>> inline, but without a definition
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked 
>> inline, but without a definition
--
   include/linux/compiler.h:253:8: sparse: attribute 'no_sanitize_address': 
unknown attribute
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked 
>> inline, but without a definition
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked 
>> inline, but without a definition
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked 
>> inline, but without a definition
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked 
>> inline, but without a definition
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked 
>> inline, but without a definition
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked 
>> inline, but without a definition
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked 
>> inline, but without a definition
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked 
>> inline, but without a definition
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked 
>> inline, but without a definition
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked 
>> inline, but without a definition
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked 
>> inline, but without a definition
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked 
>> inline, but without a definition
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked 
>> inline, but without a definition
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked 
>> inline, but without a definition
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked 
>> inline, but without a definition
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked 
>> inline, but without a definition
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked 
>> inline, but without a definition
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked 
>> inline, but without a d

[PATCH] fix itnull.cocci warnings

2017-01-07 Thread Julia Lawall
The first argument to list_for_each_entry cannot be NULL.

Generated by: scripts/coccinelle/iterators/itnull.cocci

CC: Harsh Jain <ha...@chelsio.com>
Signed-off-by: Julia Lawall <julia.law...@lip6.fr>
Signed-off-by: Fengguang Wu <fengguang...@intel.com>
---

This code comes from the following git tree:

url:
https://github.com/0day-ci/linux/commits/Harsh-Jain/crypto-chcr-Bug-fixes/20170107-093356
base:
https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git
master
In-Reply-To:
<8e0086b56d8fb61637d179c32a09a1bca03c4186.1483599449.git.ha...@chelsio.com>

 chcr_core.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/crypto/chelsio/chcr_core.c
+++ b/drivers/crypto/chelsio/chcr_core.c
@@ -61,7 +61,7 @@ int assign_chcr_device(struct chcr_dev *
 */
mutex_lock(_mutex); /* TODO ? */
list_for_each_entry(u_ctx, _ctx_list, entry)
-   if (u_ctx && u_ctx->dev) {
+   if (u_ctx->dev) {
*dev = u_ctx->dev;
ret = 0;
break;


[PATCHv2 net-next 4/5] sctp: add support for generating stream reconf response chunk

2017-01-07 Thread Xin Long
This patch is to define Re-configuration Response Parameter described
in rfc6525 section 4.4. As optional fields are only for SSN/TSN Reset
Request Parameter, it uses another function to make that.

Signed-off-by: Xin Long 
---
 include/linux/sctp.h | 24 
 include/net/sctp/sm.h|  7 +
 net/sctp/sm_make_chunk.c | 74 
 3 files changed, 105 insertions(+)

diff --git a/include/linux/sctp.h b/include/linux/sctp.h
index cc4c74d..c4fcc7d 100644
--- a/include/linux/sctp.h
+++ b/include/linux/sctp.h
@@ -747,4 +747,28 @@ struct sctp_strreset_tsnreq {
__u32 request_seq;
 } __packed;
 
+enum {
+   SCTP_STRRESET_NOTHING_TO_DO = 0x00,
+   SCTP_STRRESET_PERFORMED = 0x01,
+   SCTP_STRRESET_DENIED= 0x02,
+   SCTP_STRRESET_ERR_WRONG_SSN = 0x03,
+   SCTP_STRRESET_ERR_IN_PROGRESS   = 0x04,
+   SCTP_STRRESET_ERR_BAD_SEQNO = 0x05,
+   SCTP_STRRESET_IN_PROGRESS   = 0x06,
+};
+
+struct sctp_strreset_resp {
+   sctp_paramhdr_t param_hdr;
+   __u32 response_seq;
+   __u32 result;
+} __packed;
+
+struct sctp_strreset_resptsn {
+   sctp_paramhdr_t param_hdr;
+   __u32 response_seq;
+   __u32 result;
+   __u32 senders_next_tsn;
+   __u32 receivers_next_tsn;
+} __packed;
+
 #endif /* __LINUX_SCTP_H__ */
diff --git a/include/net/sctp/sm.h b/include/net/sctp/sm.h
index c658700..013d69f 100644
--- a/include/net/sctp/sm.h
+++ b/include/net/sctp/sm.h
@@ -265,6 +265,13 @@ struct sctp_chunk *sctp_make_strreset_req(
bool out, bool in);
 struct sctp_chunk *sctp_make_strreset_tsnreq(
const struct sctp_association *asoc);
+struct sctp_chunk *sctp_make_strreset_resp(
+   const struct sctp_association *asoc,
+   __u32 result, __u32 sn);
+struct sctp_chunk *sctp_make_strreset_tsnresp(
+   struct sctp_association *asoc,
+   __u32 result, __u32 sn,
+   __u32 sender_tsn, __u32 receiver_tsn);
 void sctp_chunk_assign_tsn(struct sctp_chunk *);
 void sctp_chunk_assign_ssn(struct sctp_chunk *);
 
diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c
index f1d8f07..34edb30 100644
--- a/net/sctp/sm_make_chunk.c
+++ b/net/sctp/sm_make_chunk.c
@@ -3676,3 +3676,77 @@ struct sctp_chunk *sctp_make_strreset_tsnreq(
 
return retval;
 }
+
+/* RE-CONFIG 4.4 (RESP)
+ *   0   1   2   3
+ *   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ *  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ *  | Parameter Type = 16   |  Parameter Length |
+ *  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ *  | Re-configuration Response Sequence Number |
+ *  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ *  |Result |
+ *  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ */
+struct sctp_chunk *sctp_make_strreset_resp(
+   const struct sctp_association *asoc,
+   __u32 result, __u32 sn)
+{
+   struct sctp_strreset_resp resp;
+   __u16 length = sizeof(resp);
+   struct sctp_chunk *retval;
+
+   retval = sctp_make_reconf(asoc, length);
+   if (!retval)
+   return NULL;
+
+   resp.param_hdr.type = SCTP_PARAM_RESET_RESPONSE;
+   resp.param_hdr.length = htons(length);
+   resp.response_seq = htonl(sn);
+   resp.result = htonl(result);
+
+   sctp_addto_chunk(retval, sizeof(resp), );
+
+   return retval;
+}
+
+/* RE-CONFIG 4.4 OPTIONAL (TSNRESP)
+ *   0   1   2   3
+ *   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ *  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ *  | Parameter Type = 16   |  Parameter Length |
+ *  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ *  | Re-configuration Response Sequence Number |
+ *  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ *  |Result |
+ *  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ *  |   Sender's Next TSN (optional)|
+ *  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ *  |  Receiver's Next TSN (optional)   |
+ *  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ */
+struct sctp_chunk *sctp_make_strreset_tsnresp(
+   struct sctp_association *asoc,
+   __u32 result, __u32 sn,

[PATCHv2 net-next 3/5] sctp: add support for generating stream reconf ssn/tsn reset request chunk

2017-01-07 Thread Xin Long
This patch is to define SSN/TSN Reset Request Parameter described
in rfc6525 section 4.3.

Signed-off-by: Xin Long 
---
 include/linux/sctp.h |  5 +
 include/net/sctp/sm.h|  2 ++
 net/sctp/sm_make_chunk.c | 29 +
 3 files changed, 36 insertions(+)

diff --git a/include/linux/sctp.h b/include/linux/sctp.h
index d5da19c..cc4c74d 100644
--- a/include/linux/sctp.h
+++ b/include/linux/sctp.h
@@ -742,4 +742,9 @@ struct sctp_strreset_inreq {
__u16 list_of_streams[0];
 } __packed;
 
+struct sctp_strreset_tsnreq {
+   sctp_paramhdr_t param_hdr;
+   __u32 request_seq;
+} __packed;
+
 #endif /* __LINUX_SCTP_H__ */
diff --git a/include/net/sctp/sm.h b/include/net/sctp/sm.h
index 3462cb0..c658700 100644
--- a/include/net/sctp/sm.h
+++ b/include/net/sctp/sm.h
@@ -263,6 +263,8 @@ struct sctp_chunk *sctp_make_strreset_req(
const struct sctp_association *asoc,
__u16 stream_num, __u16 *stream_list,
bool out, bool in);
+struct sctp_chunk *sctp_make_strreset_tsnreq(
+   const struct sctp_association *asoc);
 void sctp_chunk_assign_tsn(struct sctp_chunk *);
 void sctp_chunk_assign_ssn(struct sctp_chunk *);
 
diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c
index 172385c..f1d8f07 100644
--- a/net/sctp/sm_make_chunk.c
+++ b/net/sctp/sm_make_chunk.c
@@ -3647,3 +3647,32 @@ struct sctp_chunk *sctp_make_strreset_req(
 
return retval;
 }
+
+/* RE-CONFIG 4.3 (SSN/TSN RESET ALL)
+ *   0   1   2   3
+ *   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ *  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ *  | Parameter Type = 15   |  Parameter Length = 8 |
+ *  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ *  | Re-configuration Request Sequence Number  |
+ *  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ */
+struct sctp_chunk *sctp_make_strreset_tsnreq(
+   const struct sctp_association *asoc)
+{
+   struct sctp_strreset_tsnreq tsnreq;
+   __u16 length = sizeof(tsnreq);
+   struct sctp_chunk *retval;
+
+   retval = sctp_make_reconf(asoc, length);
+   if (!retval)
+   return NULL;
+
+   tsnreq.param_hdr.type = SCTP_PARAM_RESET_TSN_REQUEST;
+   tsnreq.param_hdr.length = htons(length);
+   tsnreq.request_seq = htonl(asoc->strreset_outseq);
+
+   sctp_addto_chunk(retval, sizeof(tsnreq), );
+
+   return retval;
+}
-- 
2.1.0



[PATCHv2 net-next 5/5] sctp: add support for generating stream reconf add streams request chunk

2017-01-07 Thread Xin Long
This patch is to define Add Incoming/Outgoing Streams Request
Parameter described in rfc6525 section 4.5 and 4.6. They can
be in one same chunk trunk as rfc6525 section 3.1-7 describes,
so make them in one function.

Signed-off-by: Xin Long 
---
 include/linux/sctp.h |  7 +++
 include/net/sctp/sm.h|  3 +++
 net/sctp/sm_make_chunk.c | 46 ++
 3 files changed, 56 insertions(+)

diff --git a/include/linux/sctp.h b/include/linux/sctp.h
index c4fcc7d..3a9f234 100644
--- a/include/linux/sctp.h
+++ b/include/linux/sctp.h
@@ -771,4 +771,11 @@ struct sctp_strreset_resptsn {
__u32 receivers_next_tsn;
 } __packed;
 
+struct sctp_strreset_addstrm {
+   sctp_paramhdr_t param_hdr;
+   __u32 request_seq;
+   __u16 number_of_streams;
+   __u16 reserved;
+} __packed;
+
 #endif /* __LINUX_SCTP_H__ */
diff --git a/include/net/sctp/sm.h b/include/net/sctp/sm.h
index 013d69f..35986d0 100644
--- a/include/net/sctp/sm.h
+++ b/include/net/sctp/sm.h
@@ -272,6 +272,9 @@ struct sctp_chunk *sctp_make_strreset_tsnresp(
struct sctp_association *asoc,
__u32 result, __u32 sn,
__u32 sender_tsn, __u32 receiver_tsn);
+struct sctp_chunk *sctp_make_strreset_addstrm(
+   const struct sctp_association *asoc,
+   __u16 out, __u16 in);
 void sctp_chunk_assign_tsn(struct sctp_chunk *);
 void sctp_chunk_assign_ssn(struct sctp_chunk *);
 
diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c
index 34edb30..e6a5530 100644
--- a/net/sctp/sm_make_chunk.c
+++ b/net/sctp/sm_make_chunk.c
@@ -3750,3 +3750,49 @@ struct sctp_chunk *sctp_make_strreset_tsnresp(
 
return retval;
 }
+
+/* RE-CONFIG 4.5/4.6 (ADD STREAM)
+ *   0   1   2   3
+ *   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ *  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ *  | Parameter Type = 17   |  Parameter Length = 12|
+ *  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ *  |  Re-configuration Request Sequence Number |
+ *  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ *  |  Number of new streams| Reserved  |
+ *  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ */
+struct sctp_chunk *sctp_make_strreset_addstrm(
+   const struct sctp_association *asoc,
+   __u16 out, __u16 in)
+{
+   struct sctp_strreset_addstrm addstrm;
+   __u16 length = sizeof(addstrm);
+   struct sctp_chunk *retval;
+
+   retval = sctp_make_reconf(asoc, (!!out + !!in) * length);
+   if (!retval)
+   return NULL;
+
+   if (out) {
+   addstrm.param_hdr.type = SCTP_PARAM_RESET_ADD_OUT_STREAMS;
+   addstrm.param_hdr.length = htons(length);
+   addstrm.number_of_streams = htons(out);
+   addstrm.request_seq = htonl(asoc->strreset_outseq);
+   addstrm.reserved = 0;
+
+   sctp_addto_chunk(retval, length, );
+   }
+
+   if (in) {
+   addstrm.param_hdr.type = SCTP_PARAM_RESET_ADD_IN_STREAMS;
+   addstrm.param_hdr.length = htons(length);
+   addstrm.number_of_streams = htons(in);
+   addstrm.request_seq = htonl(asoc->strreset_outseq + !!out);
+   addstrm.reserved = 0;
+
+   sctp_addto_chunk(retval, length, );
+   }
+
+   return retval;
+}
-- 
2.1.0



[PATCHv2 net-next 2/5] sctp: add support for generating stream reconf ssn reset request chunk

2017-01-07 Thread Xin Long
This patch is to add asoc strreset_outseq and strreset_inseq for
saving the reconf request sequence, initialize them when create
assoc and process init, and also to define Incoming and Outgoing
SSN Reset Request Parameter described in rfc6525 section 4.1 and
4.2, As they can be in one same chunk as section rfc6525 3.1-3
describes, it makes them in one function.

Signed-off-by: Xin Long 
---
 include/linux/sctp.h   | 26 ++
 include/net/sctp/sm.h  |  5 ++-
 include/net/sctp/structs.h |  3 ++
 net/sctp/associola.c   |  1 +
 net/sctp/sm_make_chunk.c   | 88 ++
 5 files changed, 122 insertions(+), 1 deletion(-)

diff --git a/include/linux/sctp.h b/include/linux/sctp.h
index cdc3b05..d5da19c 100644
--- a/include/linux/sctp.h
+++ b/include/linux/sctp.h
@@ -200,6 +200,13 @@ typedef enum {
SCTP_PARAM_SUCCESS_REPORT   = cpu_to_be16(0xc005),
SCTP_PARAM_ADAPTATION_LAYER_IND = cpu_to_be16(0xc006),
 
+   /* RE-CONFIG. Section 4 */
+   SCTP_PARAM_RESET_OUT_REQUEST= cpu_to_be16(0x000d),
+   SCTP_PARAM_RESET_IN_REQUEST = cpu_to_be16(0x000e),
+   SCTP_PARAM_RESET_TSN_REQUEST= cpu_to_be16(0x000f),
+   SCTP_PARAM_RESET_RESPONSE   = cpu_to_be16(0x0010),
+   SCTP_PARAM_RESET_ADD_OUT_STREAMS= cpu_to_be16(0x0011),
+   SCTP_PARAM_RESET_ADD_IN_STREAMS = cpu_to_be16(0x0012),
 } sctp_param_t; /* enum */
 
 
@@ -716,4 +723,23 @@ struct sctp_reconf_chunk {
__u8 params[0];
 } __packed;
 
+struct sctp_strreset_req {
+   sctp_paramhdr_t param_hdr;
+   __u32 request_seq;
+} __packed;
+
+struct sctp_strreset_outreq {
+   sctp_paramhdr_t param_hdr;
+   __u32 request_seq;
+   __u32 response_seq;
+   __u32 send_reset_at_tsn;
+   __u16 list_of_streams[0];
+} __packed;
+
+struct sctp_strreset_inreq {
+   sctp_paramhdr_t param_hdr;
+   __u32 request_seq;
+   __u16 list_of_streams[0];
+} __packed;
+
 #endif /* __LINUX_SCTP_H__ */
diff --git a/include/net/sctp/sm.h b/include/net/sctp/sm.h
index ca6c971..3462cb0 100644
--- a/include/net/sctp/sm.h
+++ b/include/net/sctp/sm.h
@@ -259,7 +259,10 @@ struct sctp_chunk *sctp_make_fwdtsn(const struct 
sctp_association *asoc,
__u32 new_cum_tsn, size_t nstreams,
struct sctp_fwdtsn_skip *skiplist);
 struct sctp_chunk *sctp_make_auth(const struct sctp_association *asoc);
-
+struct sctp_chunk *sctp_make_strreset_req(
+   const struct sctp_association *asoc,
+   __u16 stream_num, __u16 *stream_list,
+   bool out, bool in);
 void sctp_chunk_assign_tsn(struct sctp_chunk *);
 void sctp_chunk_assign_ssn(struct sctp_chunk *);
 
diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
index 4741ec2..3dc983e 100644
--- a/include/net/sctp/structs.h
+++ b/include/net/sctp/structs.h
@@ -1865,6 +1865,9 @@ struct sctp_association {
 temp:1,/* Is it a temporary association? */
 prsctp_enable:1;
 
+   __u32 strreset_outseq; /* Update after receiving response */
+   __u32 strreset_inseq; /* Update after receiving request */
+
struct sctp_priv_assoc_stats stats;
 
int sent_cnt_removable;
diff --git a/net/sctp/associola.c b/net/sctp/associola.c
index 36294f7..42ece6f 100644
--- a/net/sctp/associola.c
+++ b/net/sctp/associola.c
@@ -207,6 +207,7 @@ static struct sctp_association 
*sctp_association_init(struct sctp_association *a
 * association to the same value as the initial TSN.
 */
asoc->addip_serial = asoc->c.initial_tsn;
+   asoc->strreset_outseq = asoc->c.initial_tsn;
 
INIT_LIST_HEAD(>addip_chunk_list);
INIT_LIST_HEAD(>asconf_ack_list);
diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c
index fd58097..172385c 100644
--- a/net/sctp/sm_make_chunk.c
+++ b/net/sctp/sm_make_chunk.c
@@ -1844,6 +1844,7 @@ struct sctp_association *sctp_unpack_cookie(
retval->next_tsn = retval->c.initial_tsn;
retval->ctsn_ack_point = retval->next_tsn - 1;
retval->addip_serial = retval->c.initial_tsn;
+   retval->strreset_outseq = retval->c.initial_tsn;
retval->adv_peer_ack_point = retval->ctsn_ack_point;
retval->peer.prsctp_capable = retval->c.prsctp_capable;
retval->peer.adaptation_ind = retval->c.adaptation_ind;
@@ -2387,6 +2388,8 @@ int sctp_process_init(struct sctp_association *asoc, 
struct sctp_chunk *chunk,
asoc->peer.i.initial_tsn =
ntohl(peer_init->init_hdr.initial_tsn);
 
+   asoc->strreset_inseq = asoc->peer.i.initial_tsn;
+
/* Apply the upper bounds for output streams based on peer's
 * number of inbound streams.
 */
@@ -3559,3 +3562,88 @@ static struct sctp_chunk *sctp_make_reconf(
 
return retval;
 }

[PATCHv2 net-next 0/5] sctp: add support for generating stream reconf chunks

2017-01-07 Thread Xin Long
This patchset is to add some functions to generate stream reconf chunks,
described in RFC6525 Section 3 and Section 4.

v1->v2:
  - put these into a smaller group.
  - rename some temporary variables in the codes.
  - rename the titles of the commits and improve some changelogs.

Xin Long (5):
  sctp: add a common helper function to generate stream reconf chunk
  sctp: add support for generating stream reconf ssn reset request chunk
  sctp: add support for generating stream reconf ssn/tsn reset request
chunk
  sctp: add support for generating stream reconf response chunk
  sctp: add support for generating stream reconf add streams request
chunk

 include/linux/sctp.h   |  68 
 include/net/sctp/sm.h  |  17 ++-
 include/net/sctp/structs.h |   3 +
 net/sctp/associola.c   |   1 +
 net/sctp/sm_make_chunk.c   | 270 +
 5 files changed, 358 insertions(+), 1 deletion(-)

-- 
2.1.0



[PATCHv2 net-next 1/5] sctp: add a common helper function to generate stream reconf chunk

2017-01-07 Thread Xin Long
This patch is to define a common api used to alloc memory and initialize
reconf chunk header that described in rfc6525 section 3.1.

All reconf chunks will be generated by calling this helper function.

Signed-off-by: Xin Long 
---
 include/linux/sctp.h |  6 ++
 net/sctp/sm_make_chunk.c | 33 +
 2 files changed, 39 insertions(+)

diff --git a/include/linux/sctp.h b/include/linux/sctp.h
index fcb4c36..cdc3b05 100644
--- a/include/linux/sctp.h
+++ b/include/linux/sctp.h
@@ -108,6 +108,7 @@ typedef enum {
/* Use hex, as defined in ADDIP sec. 3.1 */
SCTP_CID_ASCONF = 0xC1,
SCTP_CID_ASCONF_ACK = 0x80,
+   SCTP_CID_RECONF = 0x82,
 } sctp_cid_t; /* enum */
 
 
@@ -710,4 +711,9 @@ struct sctp_infox {
struct sctp_association *asoc;
 };
 
+struct sctp_reconf_chunk {
+   sctp_chunkhdr_t chunk_hdr;
+   __u8 params[0];
+} __packed;
+
 #endif /* __LINUX_SCTP_H__ */
diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c
index a15d824..fd58097 100644
--- a/net/sctp/sm_make_chunk.c
+++ b/net/sctp/sm_make_chunk.c
@@ -3526,3 +3526,36 @@ struct sctp_chunk *sctp_make_fwdtsn(const struct 
sctp_association *asoc,
 
return retval;
 }
+
+/* RE-CONFIG 3.1 (RE-CONFIG chunk)
+ *   0   1   2   3
+ *   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ *  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ *  | Type = 130|  Chunk Flags  |  Chunk Length |
+ *  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ *  \   \
+ *  /  Re-configuration Parameter   /
+ *  \   \
+ *  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ *  \   \
+ *  / Re-configuration Parameter (optional) /
+ *  \   \
+ *  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ */
+static struct sctp_chunk *sctp_make_reconf(
+   const struct sctp_association *asoc,
+   int length)
+{
+   struct sctp_reconf_chunk *reconf;
+   struct sctp_chunk *retval;
+
+   retval = sctp_make_control(asoc, SCTP_CID_RECONF, 0, length,
+  GFP_ATOMIC);
+   if (!retval)
+   return NULL;
+
+   reconf = (struct sctp_reconf_chunk *)retval->chunk_hdr;
+   retval->param_hdr.v = reconf->params;
+
+   return retval;
+}
-- 
2.1.0



Re: [PATCHv2 net-next 11/16] net: mvpp2: handle misc PPv2.1/PPv2.2 differences

2017-01-07 Thread Russell King - ARM Linux
On Wed, Dec 28, 2016 at 05:46:27PM +0100, Thomas Petazzoni wrote:
> @@ -6511,7 +6515,9 @@ static int mvpp2_port_probe(struct platform_device 
> *pdev,
>   dev_err(>dev, "failed to init port %d\n", id);
>   goto err_free_stats;
>   }
> - mvpp2_port_power_up(port);
> +
> + if (priv->hw_version == MVPP21)
> + mvpp21_port_power_up(port);

This has the side effect that nothing clears the port reset bit in the
GMAC, which means there's no hope of the interface working - with the
reset bit set, the port is well and truely held in "link down" state.

In any case, the GMAC part is much the same as mvneta, and I think
that code should be shared rather than writing new versions of it.
There are some subtle differences between neta, pp2.1 and pp2.2, but
it's entirely doable (I have an implementation here as I wasn't going
to duplicate this code for my phylink conversion.)

-- 
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: [PATCHv2 net-next 01/16] dt-bindings: net: update Marvell PPv2 binding for PPv2.2 support

2017-01-07 Thread Russell King - ARM Linux
On Wed, Dec 28, 2016 at 05:46:17PM +0100, Thomas Petazzoni wrote:
> @@ -31,7 +43,7 @@ Optional properties (port):
>then fixed link is assumed, and the 'fixed-link' property is
>mandatory.

Not directly related to this patch, but this context is wrong.  The
PP2 driver _requires_ a PHY.  It doesn't support fixed-link in its
current form.  I think the DT binding describes an expectation of
a future driver.

The side effect is that if trying to use a fixed-link on any port,
the ethernet driver fails to probe.

-- 
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: [PATCHv2 net-next 15/16] net: mvpp2: add support for an additional clock needed for PPv2.2

2017-01-07 Thread Russell King - ARM Linux
On Wed, Dec 28, 2016 at 05:46:31PM +0100, Thomas Petazzoni wrote:
> The PPv2.2 variant of the network controller needs an additional
> clock, the "MG clock" in order for the IP block to operate
> properly. This commit adds support for this additional clock to the
> driver, reworking as needed the error handling path.

There's more clocks that are required.

Firstly, what I'm finding is that the MDIO block in the CP110 does not
work at all (locks the system up if accessed) if these clocks are not
enabled:

cpm_syscon0 1 9, cpm_syscon0 1 6, cpm_syscon0 1 5

The XMDIO block requires the same clocks to be functional.  Since the
MDIO and XMDIO blocks are actually part of the ethernet controller,
it's not that surprising.

We can't rely on the ethernet controller having been probed, because
the 8k has two sets of MDIO buses - one set per CP110.  It's entirely
possible that people will put all their PHYs for both CP110 instances
on one set of MDIO buses (eg, the master).  Indeed, this is exactly
what SolidRun have done, and hence how I found the problem.

So, it looks to me like DT doesn't actually describe the hardware here -
especially when looking at the reg properties, they overlap with each
other.

> Signed-off-by: Thomas Petazzoni 
> ---
>  drivers/net/ethernet/marvell/mvpp2.c | 25 +
>  1 file changed, 21 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/net/ethernet/marvell/mvpp2.c 
> b/drivers/net/ethernet/marvell/mvpp2.c
> index 20e9429..194de00 100644
> --- a/drivers/net/ethernet/marvell/mvpp2.c
> +++ b/drivers/net/ethernet/marvell/mvpp2.c
> @@ -702,6 +702,7 @@ struct mvpp2 {
>   /* Common clocks */
>   struct clk *pp_clk;
>   struct clk *gop_clk;
> + struct clk *mg_clk;
>  
>   /* List of pointers to port structures */
>   struct mvpp2_port **port_list;
> @@ -6899,6 +6900,18 @@ static int mvpp2_probe(struct platform_device *pdev)
>   if (err < 0)
>   goto err_pp_clk;
>  
> + if (priv->hw_version == MVPP22) {
> + priv->mg_clk = devm_clk_get(>dev, "mg_clk");
> + if (IS_ERR(priv->mg_clk)) {
> + err = PTR_ERR(priv->mg_clk);
> + goto err_gop_clk;
> + }
> +
> + err = clk_prepare_enable(priv->mg_clk);
> + if (err < 0)
> + goto err_gop_clk;
> + }
> +
>   /* Get system's tclk rate */
>   priv->tclk = clk_get_rate(priv->pp_clk);
>  
> @@ -6906,14 +6919,14 @@ static int mvpp2_probe(struct platform_device *pdev)
>   err = mvpp2_init(pdev, priv);
>   if (err < 0) {
>   dev_err(>dev, "failed to initialize controller\n");
> - goto err_gop_clk;
> + goto err_mg_clk;
>   }
>  
>   port_count = of_get_available_child_count(dn);
>   if (port_count == 0) {
>   dev_err(>dev, "no ports enabled\n");
>   err = -ENODEV;
> - goto err_gop_clk;
> + goto err_mg_clk;
>   }
>  
>   priv->port_list = devm_kcalloc(>dev, port_count,
> @@ -6921,19 +6934,22 @@ static int mvpp2_probe(struct platform_device *pdev)
> GFP_KERNEL);
>   if (!priv->port_list) {
>   err = -ENOMEM;
> - goto err_gop_clk;
> + goto err_mg_clk;
>   }
>  
>   /* Initialize ports */
>   for_each_available_child_of_node(dn, port_node) {
>   err = mvpp2_port_probe(pdev, port_node, priv);
>   if (err < 0)
> - goto err_gop_clk;
> + goto err_mg_clk;
>   }
>  
>   platform_set_drvdata(pdev, priv);
>   return 0;
>  
> +err_mg_clk:
> + if (priv->hw_version == MVPP22)
> + clk_disable_unprepare(priv->mg_clk);
>  err_gop_clk:
>   clk_disable_unprepare(priv->gop_clk);
>  err_pp_clk:
> @@ -6969,6 +6985,7 @@ static int mvpp2_remove(struct platform_device *pdev)
> aggr_txq->descs_phys);
>   }
>  
> + clk_disable_unprepare(priv->mg_clk);
>   clk_disable_unprepare(priv->pp_clk);
>   clk_disable_unprepare(priv->gop_clk);
>  
> -- 
> 2.7.4
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
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: [net-next PATCH] net: reduce cycles spend on ICMP replies that gets rate limited

2017-01-07 Thread Jesper Dangaard Brouer
On Fri, 06 Jan 2017 14:08:06 -0800
Eric Dumazet  wrote:

> On Fri, 2017-01-06 at 11:40 -0800, Eric Dumazet wrote:
> > On Fri, 2017-01-06 at 18:39 +0100, Jesper Dangaard Brouer wrote:
> > 
> >   
> > > @@ -648,13 +668,17 @@ void icmp_send(struct sk_buff *skb_in, int type, 
> > > int code, __be32 info)
> > >   }
> > >   }
> > >  
> > > - icmp_param = kmalloc(sizeof(*icmp_param), GFP_ATOMIC);
> > > - if (!icmp_param)
> > > - return;
> > > -
> > >   sk = icmp_xmit_lock(net);
> > >   if (!sk)
> > > - goto out_free;
> > > + goto out;
> > > +
> > > + /* Check global sysctl_icmp_msgs_per_sec ratelimit */
> > > + if (!icmpv4_global_allow(net, type, code))
> > > + goto out_unlock;
> > > +
> > > + icmp_param = kmalloc(sizeof(*icmp_param), GFP_ATOMIC);
> > > + if (!icmp_param)
> > > + goto out_unlock;  
> >   
> 
> You could call icmp_xmit_lock() _after_ checking global limit perhaps. 
> 
> That would remove one atomic op.

The reason I don't do this is, because icmp_xmit_lock() disables BH and
icmp_global_allow() have a comment that it need to run with BH-disabled.
Thus, I'm depending on the BH-disable from icmp_xmit_lock().

I would have to move out the BH-disable part of icmp_xmit_lock, to do
this. Would that be acceptable?

-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  LinkedIn: http://www.linkedin.com/in/brouer


Re: [PATCH] treewide: fix semicolon.cocci warnings

2017-01-07 Thread Michal Hocko
On Sat 07-01-17 11:26:42, Wu Fengguang wrote:
> net/netfilter/x_tables.c:716:59-60: Unneeded semicolon
> 
> 
>  Remove unneeded semicolon.
> 
> Generated by: scripts/coccinelle/misc/semicolon.cocci
> 
> Signed-off-by: Fengguang Wu 

Thanks, I will fold this into the original patch.

> ---
> 
>  x_tables.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> --- a/net/netfilter/x_tables.c
> +++ b/net/netfilter/x_tables.c
> @@ -713,7 +713,7 @@ EXPORT_SYMBOL(xt_check_entry_offsets);
>  unsigned int *xt_alloc_entry_offsets(unsigned int size)
>  {
>   if (size < (SIZE_MAX / sizeof(unsigned int)))
> - return kvmalloc(size * sizeof(unsigned int), GFP_KERNEL);;
> + return kvmalloc(size * sizeof(unsigned int), GFP_KERNEL);
>  
>   return NULL;
>  

-- 
Michal Hocko
SUSE Labs


Re: [PATCH v2 01/12] net: ethernet: aquantia: Make and configuration files.

2017-01-07 Thread kbuild test robot
Hi David,

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

url:
https://github.com/0day-ci/linux/commits/Alexander-Loktionov/net-ethernet-aquantia-Add-AQtion-2-5-5-GB-NIC-driver/20170107-100651
config: powerpc-allyesconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=powerpc 

Note: the 
linux-review/Alexander-Loktionov/net-ethernet-aquantia-Add-AQtion-2-5-5-GB-NIC-driver/20170107-100651
 HEAD 3bdfdbb2c526cec3941e8e4136feb26e06a8df90 builds fine.
  It only hurts bisectibility.

All errors (new ones prefixed by >>):

>> make[5]: *** No rule to make target 
>> 'drivers/net/ethernet/aquantia/aq_main.o', needed by 
>> 'drivers/net/ethernet/aquantia/atlantic.o'.
>> make[5]: *** No rule to make target 
>> 'drivers/net/ethernet/aquantia/aq_nic.o', needed by 
>> 'drivers/net/ethernet/aquantia/atlantic.o'.
>> make[5]: *** No rule to make target 
>> 'drivers/net/ethernet/aquantia/aq_pci_func.o', needed by 
>> 'drivers/net/ethernet/aquantia/atlantic.o'.
>> make[5]: *** No rule to make target 
>> 'drivers/net/ethernet/aquantia/aq_vec.o', needed by 
>> 'drivers/net/ethernet/aquantia/atlantic.o'.
   make[5]: *** No rule to make target 
'drivers/net/ethernet/aquantia/aq_ring.o', needed by 
'drivers/net/ethernet/aquantia/atlantic.o'.
>> make[5]: *** No rule to make target 
>> 'drivers/net/ethernet/aquantia/aq_hw_utils.o', needed by 
>> 'drivers/net/ethernet/aquantia/atlantic.o'.
>> make[5]: *** No rule to make target 
>> 'drivers/net/ethernet/aquantia/aq_ethtool.o', needed by 
>> 'drivers/net/ethernet/aquantia/atlantic.o'.
>> make[5]: *** No rule to make target 
>> 'drivers/net/ethernet/aquantia/hw_atl/hw_atl_a0.o', needed by 
>> 'drivers/net/ethernet/aquantia/atlantic.o'.
>> make[5]: *** No rule to make target 
>> 'drivers/net/ethernet/aquantia/hw_atl/hw_atl_b0.o', needed by 
>> 'drivers/net/ethernet/aquantia/atlantic.o'.
>> make[5]: *** No rule to make target 
>> 'drivers/net/ethernet/aquantia/hw_atl/hw_atl_utils.o', needed by 
>> 'drivers/net/ethernet/aquantia/atlantic.o'.
>> make[5]: *** No rule to make target 
>> 'drivers/net/ethernet/aquantia/hw_atl/hw_atl_llh.o', needed by 
>> 'drivers/net/ethernet/aquantia/atlantic.o'.
   make[5]: Target '__build' not remade because of errors.

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


.config.gz
Description: application/gzip


[PATCH] net: change init_inodecache() return void

2017-01-07 Thread yuan linyu
From: yuan linyu 

sock_init() call it but not check it's return value,
so change it to void return and add an internal BUG_ON() check.

Signed-off-by: yuan linyu 
---
 net/socket.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/net/socket.c b/net/socket.c
index c65bb92..3ef02e9 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -287,7 +287,7 @@ static void init_once(void *foo)
inode_init_once(>vfs_inode);
 }
 
-static int init_inodecache(void)
+static void init_inodecache(void)
 {
sock_inode_cachep = kmem_cache_create("sock_inode_cache",
  sizeof(struct socket_alloc),
@@ -296,9 +296,7 @@ static int init_inodecache(void)
   SLAB_RECLAIM_ACCOUNT |
   SLAB_MEM_SPREAD | SLAB_ACCOUNT),
  init_once);
-   if (sock_inode_cachep == NULL)
-   return -ENOMEM;
-   return 0;
+   BUG_ON(sock_inode_cachep == NULL);
 }
 
 static const struct super_operations sockfs_ops = {
-- 
2.7.4




Re: [net-next PATCH v2 5/6] i40e: Add TX and RX support in switchdev mode.

2017-01-07 Thread Jiri Pirko
Fri, Jan 06, 2017 at 08:08:58PM CET, kubak...@wp.pl wrote:
>On Fri, 6 Jan 2017 18:30:35 +0100, Jiri Pirko wrote:
>> >> > +   skb_dst_drop(skb);
>> >> > +   dst_hold(>vfpr_dst->dst);
>> >> > +   skb_dst_set(skb, >vfpr_dst->dst);
>> >> > +   skb->dev = vsi->netdev;  
>> >> This dst dance seems a bit odd to me. Why don't you just call
>> >> i40e_xmit_frame_ring with an extra arg holding the needed metadata?  
>> >
>> >We don't have TX/RX queues associated with VFPR netdevs, so we need to set
>> >the dev to PF netdev and requeue the skb.  
>> 
>> Still, you eventually call a function within same .c file. Using dst
>> does not look right to me.
>
>Do you mean you don't like reusing the dst_metadata to store the
>representative id?  The missing patch provided the reasoning behind
>this design [1].  It's mostly about being able to comfortably use the
>queuing infrastructure.  Trying to push data from multiple netdevs into
>single ring at driver layer is even less pretty.
>
>[1] http://patchwork.ozlabs.org/patch/710563/

Okay, makes sense. Thanks.



Re: [PATCH v2 06/12] net: ethernet: aquantia: Atlantic A0 and B0 specific functions.

2017-01-07 Thread kbuild test robot
Hi David,

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

url:
https://github.com/0day-ci/linux/commits/Alexander-Loktionov/net-ethernet-aquantia-Add-AQtion-2-5-5-GB-NIC-driver/20170107-100651
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 6.2.0
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=ia64 

Note: the 
linux-review/Alexander-Loktionov/net-ethernet-aquantia-Add-AQtion-2-5-5-GB-NIC-driver/20170107-100651
 HEAD 3bdfdbb2c526cec3941e8e4136feb26e06a8df90 builds fine.
  It only hurts bisectibility.

All errors (new ones prefixed by >>):

>> drivers/net/ethernet/aquantia/hw_atl/hw_atl_a0.c:12:22: fatal error: 
>> ../aq_hw.h: No such file or directory
#include "../aq_hw.h"
 ^
   compilation terminated.
--
>> drivers/net/ethernet/aquantia/hw_atl/hw_atl_b0.c:12:22: fatal error: 
>> ../aq_hw.h: No such file or directory
#include "../aq_hw.h"
 ^
   compilation terminated.

vim +12 drivers/net/ethernet/aquantia/hw_atl/hw_atl_a0.c

 6   * under the terms and conditions of the GNU General Public License,
 7   * version 2, as published by the Free Software Foundation.
 8   */
 9  
10  /* File hw_atl_a0.c: Definition of Atlantic hardware specific 
functions. */
11  
  > 12  #include "../aq_hw.h"
13  #include "../aq_hw_utils.h"
14  #include "../aq_ring.h"
15  #include "hw_atl_a0.h"

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


.config.gz
Description: application/gzip


Re: [PATCH v2 05/12] net: ethernet: aquantia: Support for NIC-specific code

2017-01-07 Thread kbuild test robot
Hi David,

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

url:
https://github.com/0day-ci/linux/commits/Alexander-Loktionov/net-ethernet-aquantia-Add-AQtion-2-5-5-GB-NIC-driver/20170107-100651
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 6.2.0
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=ia64 

Note: the 
linux-review/Alexander-Loktionov/net-ethernet-aquantia-Add-AQtion-2-5-5-GB-NIC-driver/20170107-100651
 HEAD 3bdfdbb2c526cec3941e8e4136feb26e06a8df90 builds fine.
  It only hurts bisectibility.

All errors (new ones prefixed by >>):

   In file included from drivers/net/ethernet/aquantia/aq_common.h:18:0,
from drivers/net/ethernet/aquantia/aq_main.h:15,
from drivers/net/ethernet/aquantia/aq_main.c:12:
>> drivers/net/ethernet/aquantia/aq_nic.h:16:20: fatal error: aq_rss.h: No such 
>> file or directory
#include "aq_rss.h"
   ^
   compilation terminated.

vim +16 drivers/net/ethernet/aquantia/aq_nic.h

10  /* File aq_nic.h: Declaration of common code for NIC. */
11  
12  #ifndef AQ_NIC_H
13  #define AQ_NIC_H
14  
15  #include "aq_common.h"
  > 16  #include "aq_rss.h"
17  
18  struct aq_ring_s;
19  struct aq_pci_func_s;

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


.config.gz
Description: application/gzip