Re: [Patch net] act_police: fix a crash during removal

[Cong Wang]

On Fri, Jun 3, 2016 at 4:28 PM, David Miller  wrote:
> From: Cong Wang 
> Date: Wed,  1 Jun 2016 16:15:20 -0700
>
>> The police action is using its own code to initialize tcf hash
>> info, which makes us to forgot to initialize a->hinfo correctly.
>> Fix this by calling the helper function tcf_hash_create() directly.
>>
>> This patch fixed the following crash:
>  ...
>> Fixes: ddf97ccdd7cb ("net_sched: add network namespace support for tc 
>> actions")
>> Cc: Jamal Hadi Salim 
>> Signed-off-by: Cong Wang 
>
> This adds a new warning, please resubmit with this fixed.
>
> net/sched/act_police.c: In function ‘tcf_act_police_locate’:
> net/sched/act_police.c:247:3: warning: ‘police’ may be used uninitialized in 
> this function [-Wmaybe-uninitialized]

Oh, sure, my compiler didn't catch this.

I will send v2 tomorrow.

Re: [net-next PATCH 3/3] net sched actions: aggregate dumping of actions timeinfo

[Cong Wang]

On Sun, Jun 5, 2016 at 7:26 AM, Jamal Hadi Salim  wrote:
> diff --git a/include/net/act_api.h b/include/net/act_api.h
> index 8389c00..5453f52 100644
> --- a/include/net/act_api.h
> +++ b/include/net/act_api.h
> @@ -80,6 +80,14 @@ static inline void tcf_lastuse_update(struct tcf_t *tm)
> tm->firstuse = now;
>  }
>
> +static inline void tcf_tm_dump(struct tcf_t *dtm, struct tcf_t *stm)

Nit: const struct tcf_t *stm. ;)

The rest looks good.

Thanks.

Re: [PATCH net-next 1/3] arm64: bpf: implement bpf_tail_call() helper

[Z Lim]

Hi Daniel,

On Sun, Jun 5, 2016 at 12:53 AM, Daniel Borkmann <dan...@iogearbox.net> wrote:
> On 06/05/2016 01:46 AM, kbuild test robot wrote:
>>
>> Hi,
>>
>> [auto build test ERROR on net-next/master]
>>
>> url:
>> https://github.com/0day-ci/linux/commits/Zi-Shen-Lim/arm64-bpf-implement-bpf_tail_call-helper/20160605-060435
>> config: arm64-defconfig (attached as .config)
>> compiler: aarch64-linux-gnu-gcc (Debian 5.3.1-8) 5.3.1 20160205
>> 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=arm64
>>
>> All errors (new ones prefixed by >>):
>>
>> In file included from arch/arm64/net/bpf_jit_comp.c:21:0:
>> include/linux/bpf.h: In function 'bpf_prog_get':
>>>>
>>>> include/linux/bpf.h:235:9: error: implicit declaration of function
>>>> 'ERR_PTR' [-Werror=implicit-function-declaration]
>>
>>   return ERR_PTR(-EOPNOTSUPP);
>>  ^
>> include/linux/bpf.h:235:9: warning: return makes pointer from integer
>> without a cast [-Wint-conversion]
>> In file included from include/linux/rwsem.h:17:0,
>>  from include/linux/mm_types.h:10,
>>  from include/linux/sched.h:27,
>>  from arch/arm64/include/asm/compat.h:25,
>>  from arch/arm64/include/asm/stat.h:23,
>>  from include/linux/stat.h:5,
>>  from include/linux/compat.h:12,
>>  from include/linux/filter.h:10,
>>  from arch/arm64/net/bpf_jit_comp.c:22:
>> include/linux/err.h: At top level:
>>>>
>>>> include/linux/err.h:23:35: error: conflicting types for 'ERR_PTR'
>>
>>  static inline void * __must_check ERR_PTR(long error)
>>^
>> In file included from arch/arm64/net/bpf_jit_comp.c:21:0:
>> include/linux/bpf.h:235:9: note: previous implicit declaration of
>> 'ERR_PTR' was here
>>   return ERR_PTR(-EOPNOTSUPP);
>>  ^
>> cc1: some warnings being treated as errors
>
>
> Looks like including linux/bpf.h at the very beginning causes issues when
> bpf
> syscall is disabled. We should probably just include linux/err.h from bpf.h.

How about the attached patch? Fixes compilation error on build
!CONFIG_BPF_SYSCALL.

Also, should this patch be sent to net or net-next (along with this series)?

Thanks,
z
From 0633e3e528e11b09691fbf533ba7fdaf4c52f772 Mon Sep 17 00:00:00 2001
From: Zi Shen Lim <zlim@gmail.com>
Date: Sun, 5 Jun 2016 21:43:14 -0700
Subject: [PATCH] bpf: fix missing header inclusion

Commit 0fc174dea545 ("ebpf: make internal bpf API independent of
CONFIG_BPF_SYSCALL ifdefs") introduced usage of ERR_PTR() in
bpf_prog_get(), however did not include linux/err.h.

Without this patch, when compiling arm64 BPF without CONFIG_BPF_SYSCALL:
...
In file included from arch/arm64/net/bpf_jit_comp.c:21:0:
include/linux/bpf.h: In function 'bpf_prog_get':
include/linux/bpf.h:235:9: error: implicit declaration of function 'ERR_PTR' [-Werror=implicit-function-declaration]
  return ERR_PTR(-EOPNOTSUPP);
 ^
include/linux/bpf.h:235:9: warning: return makes pointer from integer without a cast [-Wint-conversion]
In file included from include/linux/rwsem.h:17:0,
 from include/linux/mm_types.h:10,
 from include/linux/sched.h:27,
 from arch/arm64/include/asm/compat.h:25,
 from arch/arm64/include/asm/stat.h:23,
 from include/linux/stat.h:5,
 from include/linux/compat.h:12,
 from include/linux/filter.h:10,
 from arch/arm64/net/bpf_jit_comp.c:22:
include/linux/err.h: At top level:
include/linux/err.h:23:35: error: conflicting types for 'ERR_PTR'
 static inline void * __must_check ERR_PTR(long error)
   ^
In file included from arch/arm64/net/bpf_jit_comp.c:21:0:
include/linux/bpf.h:235:9: note: previous implicit declaration of 'ERR_PTR' was here
  return ERR_PTR(-EOPNOTSUPP);
 ^
...

Fixes: 0fc174dea545 ("ebpf: make internal bpf API independent of CONFIG_BPF_SYSCALL ifdefs")
Suggested-by: Daniel Borkmann <dan...@iogearbox.net>
Signed-off-by: Zi Shen Lim <zlim@gmail.com>
---
 include/linux/bpf.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index 8ee27b8..1bcae82 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct bpf_map;
 
-- 
1.9.1

RE: [PATCH] net: fec: fix spelling mistake "coalesed" -> "coalesced"

[Fugang Duan]

From: Colin King  Sent: Sunday, June 05, 2016 3:01 AM
> To: Fugang Duan ; netdev@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> Subject: [PATCH] net: fec: fix spelling mistake "coalesed" -> "coalesced"
> 
> From: Colin Ian King 
> 
> trivial fix to spelling mistake in pr_err message
> 
> Signed-off-by: Colin Ian King 
> ---
>  drivers/net/ethernet/freescale/fec_main.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/ethernet/freescale/fec_main.c
> b/drivers/net/ethernet/freescale/fec_main.c
> index 3c0255e..96bd210 100644
> --- a/drivers/net/ethernet/freescale/fec_main.c
> +++ b/drivers/net/ethernet/freescale/fec_main.c
> @@ -2427,13 +2427,13 @@ fec_enet_set_coalesce(struct net_device *ndev,
> struct ethtool_coalesce *ec)
> 
>   cycle = fec_enet_us_to_itr_clock(ndev, fep->rx_time_itr);
>   if (cycle > 0x) {
> - pr_err("Rx coalesed usec exceeed hardware limiation");
> + pr_err("Rx coalesced usec exceeed hardware limiation");

coalesed -> coalesced, Exceeed -> exceed,  limitation-> limitation

So:
pr_err("Rx coalesced usec exceed hardware limitation \n");

>   return -EINVAL;
>   }
> 
>   cycle = fec_enet_us_to_itr_clock(ndev, fep->tx_time_itr);
>   if (cycle > 0x) {
> - pr_err("Rx coalesed usec exceeed hardware limiation");
> + pr_err("Rx coalesced usec exceeed hardware limiation");

pr_err("Rx coalesced usec exceed hardware limitation \n");

Of course, pls add "\n" terminate char for all pr_err() in . 
fec_enet_set_coalesce() function.
Thanks.

>   return -EINVAL;
>   }
> 
> --
> 2.8.1

Re: rhashtable - rhashtable_insert_fast failed

[Herbert Xu]

On Sat, Jun 04, 2016 at 09:35:27AM +0200, Phil Sutter wrote:
> [Cc'ing other interested parties, therefore full-quoting.]
> 
> Hi Helge,
> 
> On Fri, Jun 03, 2016 at 10:22:26PM +0200, Helge Deller wrote:
> > Hi Phil,
> > 
> > I'm testing 4.7.0-rc1-64bit on a parisc/hppa machine and get
> > those message with CONFIG_TEST_RHASHTABLE=y.
> > 
> > Is this expected/normal ?
> 
> No, this shouldn't happen. Can you possibly bisect the issue?

This reminds me that I do still have to tackle the multi-page
kmalloc issue.  This may or may not be the problem here.  Enabling
warnings at the kmalloc call should be an easy way to check.

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH v3 RESEND 0/7] Add MDIO bus multiplexer support for iProc SoCs

[David Miller]

From: Andrew Lunn 
Date: Fri, 3 Jun 2016 18:32:47 +0200

>> Reason for resend:
>> -Rebased on v4.7-rc1
> 
> How do you see this getting merged? Via netdev? If so, you should be
> based on net-next/master, not v4.7-rc1.

Indeed, please respin.

Also, in your Subject lines, always have a space after the ":"
characters.

Re: [PATCH net-next 2/9] net: dsa: Add support for parsing the old binding

[Andrew Lunn]

> How much support do we want to have for the old binding for in tree
> platforms? Is the plan to migrate them all to the new binding?

I think there are three cases to consider.

1) There are some old boards using setup.c files which have a platform
   device, platform data, etc. I've never used DSA in this way, and it
   could be all the recent additions have broken this. We might want
   to test this, and if it is in fact broken, and has been for a
   while, it indicates nobody uses those boards any more. We might
   suggest removing them. Even if they do work, i doubt anybody is
   interested in converting them to device tree. So we might have to
   keep the platform data support around.

2) In tree devices using the DT binding. We can update them all to the
   new binding. The kirkwood boards don't have a u-boot which is DT
   capable. Some of the armada boards do have a DT capable uboot, but
   all these boards have been added by the community, so i suspect
   they are not flashed never to be changed again.

3) Out of tree devices using the DT binding. As far as i can see,
   there is no in three board actually using the Broadcom SF2 driver
   and its odd binding. However from talking to you, i know there are
   devices out in the wild using this binding, and their DT blob is
   fixed, never to be changed again.

It actually seems odd to me that we have a nice new binding and an
implement which is reasonably clean, and we want to add code to
support a legacy binding for an out of tree board.

I need to think on this for a while. However, i don't see the old code
and binding going away anytime soon. It will take a few cycles to
determine if the old platform device/platform data still works, and to
remove the old boards if not. We can update the in tree devices to the
new binding, but we should keep the old binding a while to aid the
transition.

I'm tempted to say you should keep using the old code to support your
out of tree devices. You should define a new binding for SF2 which
conforms to the device tree binding document which just got accepted,
and add it to SF 2 alongside the legacy binding. And it would be great
if you could go the last step and actually add a boards device tree
file using it.

I'm hesitant to add legacy binding support for SF2 to the new DSA2
code. We should try to keep it free of cruft, and set a good example
for others to follow when they bring along there new drivers.

Andrew

Re: [PATCH net-next v2 0/5] hv_netvsc: cleanup after untangling the pointer mess

[David Miller]

From: Vitaly Kuznetsov 
Date: Fri,  3 Jun 2016 17:50:57 +0200

> Changes since v1:
> - resend when net-next is open [David Miller]
> - rebased to current net-next.
> 
> After we made traveling through our internal structures explicit it became
> obvious that some functions take arguments they don't need just to do
> redundant pointer travel and get to what they really need while their
> callers already have the required information.
> 
> This is just a cleanup series with no functional changes intended. It
> doesn't pretend to be complete, additional cleanup of other functions may
> follow.

Series applied, thanks.

Re: [PATCH net] bnx2x: allow adding VLANs while interface is down

[David Miller]

From: Michal Schmidt 
Date: Fri,  3 Jun 2016 15:32:18 +0200

> Since implementing VLAN filtering in commit 05cc5a39ddb74
> ("bnx2x: add vlan filtering offload") bnx2x refuses to add a VLAN while
> the interface is down:
> 
>   # ip link add link enp3s0f0 enp3s0f0_10 type vlan id 10
>   RTNETLINK answers: Bad address
> 
> and in dmesg (with bnx2x.debug=0x20):
>   bnx2x: [bnx2x_vlan_rx_add_vid:12941(enp3s0f0)]Ignoring VLAN
>   configuration the interface is down
> 
> Other drivers have no problem with this.
> Fix this peculiar behavior in the following way:
>  - Accept requests to add/kill VID regardless of the device state.
>Maintain the requested list of VIDs in the bp->vlan_reg list.
>  - If the device is up, try to configure the VID list into the hardware.
>If we run out of VLAN credits or encounter a failure configuring an
>entry, fall back to accepting all VLANs.
>If we successfully configure all entries from the list, turn the
>fallback off.
>  - Use the same code for reconfiguring VLANs during NIC load.
> 
> Signed-off-by: Michal Schmidt 

Applied, thanks.

Re: [PATCHv2 net-next] sctp: sctp should change socket state when shutdown is received

[David Miller]

From: Xin Long 
Date: Fri,  3 Jun 2016 22:42:45 +0800

> Now sctp doesn't change socket state upon shutdown reception. It changes
> just the assoc state, even though it's a TCP-style socket.
> 
> For some cases, if we really need to check sk->sk_state, it's necessary to
> fix this issue, at least when we use ss or netstat to dump, we can get a
> more exact information.
> 
> As an improvement, we will change sk->sk_state when we change asoc->state
> to SHUTDOWN_RECEIVED, and also do it in sctp_shutdown to keep consistent with
> sctp_close.
> 
> Signed-off-by: Xin Long 

It looks like some changes are still needed for this.

Re: [PATCH 1/1] net: ethernet: Add TSE PCS support to dwmac-socfpga

[David Miller]

From: 
Date: Fri, 3 Jun 2016 02:07:15 -0700

> From: Tien Hock Loh 
> 
> This adds support for TSE PCS that uses SGMII adapter when the phy-mode of
> the dwmac is set to sgmii
> 
> Signed-off-by: Tien Hock Loh 

Please at least make an effort to use consistent coding style.

You rework this function to do this:

> - if (!splitter_base)
> - return;
> + if (splitter_base) {

And then you add something like this:

> + if ((tse_pcs_base) && (sgmii_adapter_base)) {
> + tse_pcs_fix_mac_speed(>pcs, phy_dev, speed);
> + }

Excessive parenthesis in the if() condition, and single statement
basic blocks do not get curly braces.

Re: [PATCH net-next] net: disable fragment reassembly if high_thresh is zero

[David Miller]

From: Michal Kubecek 
Date: Fri, 27 May 2016 17:53:52 +0200

> Before commit 6d7b857d541e ("net: use lib/percpu_counter API for
> fragmentation mem accounting"), setting the reassembly high threshold
> to 0 prevented fragment reassembly as first fragment would be always
> evicted before second could be added to the queue. While inefficient,
> some users apparently relied on this method.
> 
> Since the commit mentioned above, a percpu counter is used for
> reassembly memory accounting and high batch size avoids taking slow path
> in most common scenarios. As a result, a whole full sized packet can be
> reassembled without the percpu counter's main counter changing its value
> so that even with high_thresh set to 0, fragmented packets can be still
> reassembled and processed.
> 
> Add explicit check preventing reassembly if high threshold is zero.
> 
> Signed-off-by: Michal Kubecek 

Applied, thanks.

Re: [PATCH net-next 7/9] net: dsa: Initialize CPU port ethtool ops per tree

[Andrew Lunn]

On Sun, Jun 05, 2016 at 03:29:01PM -0700, Florian Fainelli wrote:
> Le 04/06/2016 13:38, Andrew Lunn a écrit :
> >> index e8386157de30..938262010524 100644
> >> --- a/net/dsa/dsa2.c
> >> +++ b/net/dsa/dsa2.c
> >> @@ -346,7 +346,7 @@ static int dsa_ds_apply(struct dsa_switch_tree *dst, 
> >> struct dsa_switch *ds)
> >>continue;
> >>}
> >>  
> >> -  return 0;
> >> +  return dsa_cpu_port_ethtool_setup(dst, ds);
> > 
> > Hi Florian
> > 
> > This is wrong. Remember, multiple CPU ports. You need to apply this to
> > each CPU port.
> 
> We do not quite support that properly though, we still do not create a
> "cpu" network device, and there is only a single master netdev per
> dsa_switch at the moment, making the secondary CPU port interfaces
> impossible to overlay their backing "master" netdev with their companion
> switch port statistics at the moment.

Hi Florian.

Using that argument, you should probably call
dsa_cpu_port_ethtool_setup() in dsa_dst_apply, since that is what
manipulates the master interface to make it handle DSA frames.

Andrew

RE: [PATCH v2 1/2] ARM: imx6: disable deeper idle states when FEC is active w/o HW workaround

[Fugang Duan]

From: Lucas Stach  Sent: Saturday, June 04, 2016 12:31 
AM
> To: Shawn Guo ; Fugang Duan 
> Cc: devicet...@vger.kernel.org; patchwork-...@pengutronix.de;
> ker...@pengutronix.de; linux-arm-ker...@lists.infradead.org;
> netdev@vger.kernel.org
> Subject: [PATCH v2 1/2] ARM: imx6: disable deeper idle states when FEC is
> active w/o HW workaround
> 
> The i.MX6 Q/DL has an erratum (ERR006687) that prevents the FEC from waking
> the CPUs when they are in wait(unclocked) state. As the hardware workaround
> isn't applicable to all boards, disable the deeper idle state when the 
> workaround
> isn't present and the FEC is in use.
> 
> This allows to safely run a kernel with CPUidle enabled on all i.MX6 boards.
> 
> Signed-off-by: Lucas Stach 
> Acked-by: David S. Miller  (for network changes)
> ---
> v2: Spell out "workaround" to avoid confusion.
> ---
>  Documentation/devicetree/bindings/net/fsl-fec.txt |  3 +++
>  arch/arm/mach-imx/cpuidle-imx6q.c | 16 +++
>  drivers/net/ethernet/freescale/fec.h  |  2 ++
>  drivers/net/ethernet/freescale/fec_main.c | 12 +++
>  include/soc/imx/cpuidle.h | 25 
> +++
>  5 files changed, 58 insertions(+)
>  create mode 100644 include/soc/imx/cpuidle.h
> 
> diff --git a/Documentation/devicetree/bindings/net/fsl-fec.txt
> b/Documentation/devicetree/bindings/net/fsl-fec.txt
> index b037a9d78d93..a1e3693cca16 100644
> --- a/Documentation/devicetree/bindings/net/fsl-fec.txt
> +++ b/Documentation/devicetree/bindings/net/fsl-fec.txt
> @@ -27,6 +27,9 @@ Optional properties:
>number to 1.
>  - fsl,magic-packet : If present, indicates that the hardware supports waking
>up via magic packet.
> +- fsl,err006687-workaround-present: If present indicates that the
> +system has
> +  the hardware workaround for ERR006687 applied and does not need a
> +software
> +  workaround.
> 
>  Optional subnodes:
>  - mdio : specifies the mdio bus in the FEC, used as a container for phy 
> nodes diff

Hi, Lucas,

FEC irq cannot wake up CPUs when system is in wait mode. But we can use GPIO_6 
for FEC interrupt that GPIO irq wake up CPUs.
No need to disable wait mode as your such patches.

You just config the gpio irq like below patches:
bc20a5d6da71 (ARM: dts: imx6qdl-sabreauto: use GPIO_6 for FEC interrupt.)
6261c4c8f13e (ARM: dts: imx6qdl-sabrelite: use GPIO_6 for FEC interrupt.)


> --git a/arch/arm/mach-imx/cpuidle-imx6q.c b/arch/arm/mach-imx/cpuidle-
> imx6q.c
> index 353bb8774112..c3cc8ca8d2ff 100644
> --- a/arch/arm/mach-imx/cpuidle-imx6q.c
> +++ b/arch/arm/mach-imx/cpuidle-imx6q.c
> @@ -62,6 +62,22 @@ static struct cpuidle_driver imx6q_cpuidle_driver = {
>   .safe_state_index = 0,
>  };
> 
> +/*
> + * i.MX6 Q/DL has an erratum (ERR006687) that prevents the FEC from
> +waking the
> + * CPUs when they are in wait(unclocked) state. As the hardware
> +workaround isn't
> + * applicable to all boards, disable the deeper idle state when the
> +workaround
> + * isn't present and the FEC is in use.
> + */
> +void imx6q_cpuidle_fec_irqs_used(void)
> +{
> + imx6q_cpuidle_driver.states[1].disabled = true; }
> +
> +void imx6q_cpuidle_fec_irqs_unused(void)
> +{
> + imx6q_cpuidle_driver.states[1].disabled = false; }
> +
>  int __init imx6q_cpuidle_init(void)
>  {
>   /* Set INT_MEM_CLK_LPM bit to get a reliable WAIT mode support */
> diff --git a/drivers/net/ethernet/freescale/fec.h
> b/drivers/net/ethernet/freescale/fec.h
> index f58f9ea51639..dc71a88e9c55 100644
> --- a/drivers/net/ethernet/freescale/fec.h
> +++ b/drivers/net/ethernet/freescale/fec.h
> @@ -442,6 +442,8 @@ struct bufdesc_ex {
>  #define FEC_QUIRK_SINGLE_MDIO(1 << 11)
>  /* Controller supports RACC register */
>  #define FEC_QUIRK_HAS_RACC   (1 << 12)
> +/* Interrupt doesn't wake CPU from deep idle */
> +#define FEC_QUIRK_ERR006687  (1 << 13)
> 
>  struct bufdesc_prop {
>   int qid;
> diff --git a/drivers/net/ethernet/freescale/fec_main.c
> b/drivers/net/ethernet/freescale/fec_main.c
> index ca2594fd..8c2110b61684 100644
> --- a/drivers/net/ethernet/freescale/fec_main.c
> +++ b/drivers/net/ethernet/freescale/fec_main.c
> @@ -60,6 +60,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
> 
>  #include 
> 
> @@ -2820,6 +2821,9 @@ fec_enet_open(struct net_device *ndev)
>   if (ret)
>   goto err_enet_mii_probe;
> 
> + if (fep->quirks & FEC_QUIRK_ERR006687)
> + imx6q_cpuidle_fec_irqs_used();
> +
>   napi_enable(>napi);
>   phy_start(ndev->phydev);
>   netif_tx_start_all_queues(ndev);
> @@ -2855,6 +2859,9 @@ fec_enet_close(struct net_device *ndev)
> 
>   phy_disconnect(ndev->phydev);
> 
> + if (fep->quirks & FEC_QUIRK_ERR006687)
> + imx6q_cpuidle_fec_irqs_unused();
> +
>   fec_enet_clk_enable(ndev, false);
>   

RE: ath9k gpio request

[Pan, Miaoqing]

Got it, thanks.  There is no difference of the changes for AR9462 which is the 
chip Sudip tested.

Thanks,
Miaoqing

-Original Message-
From: Kalle Valo [mailto:kv...@codeaurora.org] 
Sent: Saturday, June 04, 2016 10:38 PM
To: Pan, Miaoqing 
Cc: Sudip Mukherjee ; Stephen Rothwell 
; ath9k-devel ; 
linux-n...@vger.kernel.org; linux-ker...@vger.kernel.org; 
linux-wirel...@vger.kernel.org; ath9k-de...@lists.ath9k.org; 
netdev@vger.kernel.org; Miaoqing Pan 
Subject: Re: ath9k gpio request

(Fixing top posting)

"Pan, Miaoqing"  writes:

>>> --- a/drivers/net/wireless/ath/ath9k/reg.h
>>> +++ b/drivers/net/wireless/ath/ath9k/reg.h
>>> @@ -1122,8 +1122,8 @@ enum {
>>>   #define AR9300_NUM_GPIO  16
>>>   #define AR9330_NUM_GPIO 16
>>>   #define AR9340_NUM_GPIO 23
>>> -#define AR9462_NUM_GPIO 10
>>> -#define AR9485_NUM_GPIO 12
>>> +#define AR9462_NUM_GPIO 14
>>> +#define AR9485_NUM_GPIO 11
>>>   #define AR9531_NUM_GPIO 18
>>>   #define AR9550_NUM_GPIO 24
>>>   #define AR9561_NUM_GPIO 23
>>> @@ -1139,8 +1139,8 @@ enum {
>>>   #define AR9300_GPIO_MASK0xF4FF
>>>   #define AR9330_GPIO_MASK0xF4FF
>>>   #define AR9340_GPIO_MASK0x000F
>>> -#define AR9462_GPIO_MASK0x03FF
>>> -#define AR9485_GPIO_MASK0x0FFF
>>> +#define AR9462_GPIO_MASK0x3FFF
>>> +#define AR9485_GPIO_MASK0x07FF
>>>   #define AR9531_GPIO_MASK0x000F
>>>   #define AR9550_GPIO_MASK0x000F
>>>   #define AR9561_GPIO_MASK0x000F
>>
>> solves the problem.
>>
>> Tested-by: Sudip Mukherjee 
>
> Done, https://patchwork.kernel.org/patch/9151847/

But the patch 9151847 is different from what Sudip tested above? Why?

And if you modify something _after_ the reporter has tested the patch clearly 
document what you changed and why. I do not want find hidden changes like this, 
even more so when the patch is going to a 4.7-rc release.

Sudip, could you also test patch 9151847, please? You can download the patch 
from the patchwork link above.

--
Kalle Valo

Re: [PATCH RFC v7 3/5] skb_array: array based FIFO for skbs

[Jason Wang]

On 2016年06月03日 21:04, Michael S. Tsirkin wrote:

On Fri, Jun 03, 2016 at 02:58:39PM +0200, Jesper Dangaard Brouer wrote:

>
>On Thu, 2 Jun 2016 19:08:26 +0300 "Michael S. Tsirkin"  wrote:
>

> >A simple array based FIFO of pointers.  Intended for net stack so uses
> >skbs for type safety. Implemented as a set of wrappers around ptr_array.

> ^
>It is called "ptr_ring" not "ptr_array".

Thanks!
Jason, could you please tweak this when you repost?



Sure, looks like Jesper has pointed out some other issues, want me to 
fix them too? Or you want to post new version yourself?


Thanks

Re: [linux-sunxi] [PATCH 1/5] ethernet: add sun8i-emac driver

[Chen-Yu Tsai]

On Mon, Jun 6, 2016 at 6:32 AM, André Przywara  wrote:
> On 03/06/16 10:56, LABBE Corentin wrote:
>
> Hi,
>
> first: thanks for posting this and the time and work that you spent on
> it. With the respective DT nodes this works for me on the Pine64 and
> turns this board eventually into something useful.
>
> Some comments below:
>
>> This patch add support for sun8i-emac ethernet MAC hardware.
>> It could be found in Allwinner H3/A83T/A64 SoCs.
>>
>> It supports 10/100/1000 Mbit/s speed with half/full duplex.
>> It can use an internal PHY (MII 10/100) or an external PHY
>> via RGMII/RMII.
>>
>> Signed-off-by: LABBE Corentin 
>> ---
>>  drivers/net/ethernet/allwinner/Kconfig  |   13 +
>>  drivers/net/ethernet/allwinner/Makefile |1 +
>>  drivers/net/ethernet/allwinner/sun8i-emac.c | 1943 
>> +++
>>  3 files changed, 1957 insertions(+)
>>  create mode 100644 drivers/net/ethernet/allwinner/sun8i-emac.c
>>
>> diff --git a/drivers/net/ethernet/allwinner/Kconfig 
>> b/drivers/net/ethernet/allwinner/Kconfig
>> index 47da7e7..226499d 100644
>> --- a/drivers/net/ethernet/allwinner/Kconfig
>> +++ b/drivers/net/ethernet/allwinner/Kconfig
>> @@ -33,4 +33,17 @@ config SUN4I_EMAC
>>To compile this driver as a module, choose M here.  The module
>>will be called sun4i-emac.
>>
>> +config SUN8I_EMAC
>> +tristate "Allwinner sun8i EMAC support"
>
> nit: w/s error
>
>> + depends on ARCH_SUNXI || COMPILE_TEST
>> + depends on OF
>> + select MII
>> + select PHYLIB
>> +---help---
>> +   This driver support the sun8i EMAC ethernet driver present on
>> +   H3/A83T/A64 Allwinner SoCs.
>> +
>> +  To compile this driver as a module, choose M here.  The module
>> +  will be called sun8i-emac.
>> +
>>  endif # NET_VENDOR_ALLWINNER
>> diff --git a/drivers/net/ethernet/allwinner/Makefile 
>> b/drivers/net/ethernet/allwinner/Makefile
>> index 03129f7..8bd1693c 100644
>> --- a/drivers/net/ethernet/allwinner/Makefile
>> +++ b/drivers/net/ethernet/allwinner/Makefile
>> @@ -3,3 +3,4 @@
>>  #
>>
>>  obj-$(CONFIG_SUN4I_EMAC) += sun4i-emac.o
>> +obj-$(CONFIG_SUN8I_EMAC) += sun8i-emac.o
>> diff --git a/drivers/net/ethernet/allwinner/sun8i-emac.c 
>> b/drivers/net/ethernet/allwinner/sun8i-emac.c
>> new file mode 100644
>> index 000..179aa61
>> --- /dev/null
>> +++ b/drivers/net/ethernet/allwinner/sun8i-emac.c
>> @@ -0,0 +1,1943 @@
>> +/*
>> + * sun8i-emac driver
>> + *
>> + * Copyright (C) 2015-2016 Corentin LABBE 
>> + *
>> + * This is the driver for Allwinner Ethernet MAC found in H3/A83T/A64 SoC
>> + *
>> + * TODO:
>> + * - NAPI
>> + * - MAC filtering
>> + * - Jumbo frame
>> + * - features rx-all (NETIF_F_RXALL_BIT)
>> + */
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#define SUN8I_EMAC_BASIC_CTL0 0x00
>> +#define SUN8I_EMAC_BASIC_CTL1 0x04
>> +
>> +#define SUN8I_EMAC_MDIO_CMD 0x48
>> +#define SUN8I_EMAC_MDIO_DATA 0x4C
>
> Can you align all these register offsets with tabs, so that the actual
> offset values are below each other?
> Also ordering them by address seems useful to me.
>
>> +
>> +#define SUN8I_EMAC_RX_CTL0 0x24
>> +#define SUN8I_EMAC_RX_CTL1 0x28
>> +
>> +#define SUN8I_EMAC_TX_CTL0 0x10
>> +#define SUN8I_EMAC_TX_CTL1 0x14
>> +
>> +#define SUN8I_EMAC_TX_FLOW_CTL 0x1C
>> +
>> +#define SUN8I_EMAC_RX_FRM_FLT 0x38
>> +
>> +#define SUN8I_EMAC_INT_STA 0x08
>> +#define SUN8I_EMAC_INT_EN 0x0C
>> +#define SUN8I_EMAC_RGMII_STA 0xD0
>
>
>> +
>> +#define SUN8I_EMAC_TX_DMA_STA 0xB0
>> +#define SUN8I_EMAC_TX_CUR_DESC 0xB4
>> +#define SUN8I_EMAC_TX_CUR_BUF 0xB8
>> +#define SUN8I_EMAC_RX_DMA_STA 0xC0
>> +
>> +#define MDIO_CMD_MII_BUSYBIT(0)
>> +#define MDIO_CMD_MII_WRITE   BIT(1)
>> +#define MDIO_CMD_MII_PHY_REG_ADDR_MASK   GENMASK(8, 4)
>> +#define MDIO_CMD_MII_PHY_REG_ADDR_SHIFT  4
>> +#define MDIO_CMD_MII_PHY_ADDR_MASK   GENMASK(16, 12)
>> +#define MDIO_CMD_MII_PHY_ADDR_SHIFT  12
>> +
>> +#define SUN8I_EMAC_MACADDR_HI0x50
>> +#define SUN8I_EMAC_MACADDR_LO0x54
>> +
>> +#define SUN8I_EMAC_RX_DESC_LIST 0x34
>> +#define SUN8I_EMAC_TX_DESC_LIST 0x20
>> +
>> +#define SUN8I_EMAC_TX_DO_CRC (BIT(27) | BIT(28))
>> +#define SUN8I_EMAC_RX_DO_CRC BIT(27)
>> +#define SUN8I_EMAC_RX_STRIP_FCS BIT(28)
>> +
>> +#define SUN8I_COULD_BE_USED_BY_DMA BIT(31)
>> +
>> +#define FLOW_RX 1
>> +#define FLOW_TX 2
>> +
>> +/* describe how data from skb are DMA mapped */
>> +#define MAP_SINGLE 1
>> +#define MAP_PAGE 2
>> +
>> +enum emac_variant {
>> + A83T_EMAC,
>> + H3_EMAC,
>> + A64_EMAC,
>> +};
>> +
>> +struct ethtool_str {
>> + char name[ETH_GSTRING_LEN];
>> +};
>> +
>> +static const struct 

Re: [PATCH v2 net] fq_codel: fix NET_XMIT_CN behavior

[Cong Wang]

On Sun, Jun 5, 2016 at 1:55 PM, Eric Dumazet  wrote:
> On Sun, 2016-06-05 at 13:54 -0700, Eric Dumazet wrote:
>
>> BTW, we might need a similar fix in sch_fq.c
>
> I meant sch_sfq.c
>

Potentially all of the following:

net/sched/sch_choke.c:  return NET_XMIT_CN;
net/sched/sch_fifo.c:   return NET_XMIT_CN;
net/sched/sch_generic.c:return NET_XMIT_CN;
net/sched/sch_gred.c:   return NET_XMIT_CN;
net/sched/sch_hhf.c:return NET_XMIT_CN;
net/sched/sch_red.c:return NET_XMIT_CN;
net/sched/sch_sfb.c:return NET_XMIT_CN;
net/sched/sch_sfq.c:return NET_XMIT_CN;

Re: [PATCH net-next 2/9] net: dsa: Add support for parsing the old binding

[Florian Fainelli]

Le 04/06/2016 13:00, Andrew Lunn a écrit :
>> -static int dsa_cpu_parse(struct device_node *port, u32 index,
>> - struct dsa_switch_tree *dst,
>> - struct dsa_switch *ds)
>> +static int _dsa_cpu_parse(struct dsa_switch_tree *dst,
>> +   struct dsa_switch *ds,
>> +   struct net_device *ethernet_dev,
>> +   u32 index)
>>  {
>> -struct net_device *ethernet_dev;
>> -struct device_node *ethernet;
>> -
>> -ethernet = of_parse_phandle(port, "ethernet", 0);
>> -if (!ethernet)
>> -return -EINVAL;
>> -
>> -ethernet_dev = of_find_net_device_by_node(ethernet);
>> -if (!ethernet_dev)
>> -return -EPROBE_DEFER;
>> -
> 
> Hi Florian
> 
> You have just removed all the actual DT parsing. So i would give this
> a different name, and avoid the _ prefix.
> 
>> +static int _dsa_register_switch_legacy(struct dsa_switch *ds, struct 
>> device_node *np)
>> +{
> 
> We might want to call this _dsa_register_switch_legacy_sf2, since the
> code only supports what is needed for your rather odd sf2 binding.

The SF2 binding just encapsulates the normal legacy DSA binding in its
simplified, one switch only configuration, that makes things much
easier, but not way off.

> It does not appear to work for the generic DSA binding.

It would if we also added support for parsing and filing in a routing
table, so yes, that is currently missing.

How about offering dsa_of_parse() (or another name) as a helper function
which fills up a dsa_switch / dsa_switch_tree structure to the best it
can, and then let a driver dealing with the old binding call into the
bottom parts of dsa_register_switch()? That could allow us to remove
some of the duplicated code from net/dsa/dsa.c by doing so

The other approach could be to have custom DT parsing in bcm_sf2.c and
also call the bottom parts of dsa_register_switch() once it has properly
initialized ds/dst.

How much support do we want to have for the old binding for in tree
platforms? Is the plan to migrate them all to the new binding?

-- 
Florian

Re: [PATCH net-next 4/9] net: dsa: Initialize ds->enabled_port_mask and ds->phys_mii_mask

[Florian Fainelli]

Le 04/06/2016 13:29, Andrew Lunn a écrit :
>> @@ -517,6 +541,15 @@ static int dsa_parse_ports_dn(struct device_node 
>> *ports, struct dsa_switch *ds)
>>  return -EINVAL;
>>  
>>  ds->ports[reg].dn = port;
>> +
>> +if (dsa_port_is_cpu(port))
>> +ds->dst->cpu_port = reg;
>> +else
>> +/* Initialize enabled_port_mask now for drv->setup()
>> + * to have access to a correct value, just like what
>> + * net/dsa/dsa.c::dsa_switch_setup_one does.
>> + */
>> +ds->enabled_port_mask |= 1 << reg;
> 
> Hi Florian
> 
> You need to be careful here. There can be multiple CPU ports, in
> different switches. We want dst->cpu_port to be deterministic,
> independent of the order switches are registered. Which is why i set
> it as part of dsa_cpu_parse(), which only happens when all the
> switches have registered, and we are parsing their device tree nodes
> in order. So we guarantee dst->cpu_port is the first CPU node.

Ah OK, I completely missed that part and just wanted to avoid walking
the ports children nodes more than twice.

We might be able to get away with just initializing
ds->enabled_port_mask here actually.

> 
> You now set dst->cpu_port via dsa_parse_ports_dn(), so it is now non
> deterministic, it depends on the probe order of the switches.
> 
> In the long run, i want to deprecate and then remove dst->cpu_port,
> but i'm not that far yet.
> 
> Please rethink this part of the patch, keeping in mind you have
> multiple switches, with multiple CPU and DSA ports, all connected in
> some crazy fashion.
-- 
Florian

Re: [linux-sunxi] [PATCH 1/5] ethernet: add sun8i-emac driver

[André Przywara]

On 03/06/16 10:56, LABBE Corentin wrote:

Hi,

first: thanks for posting this and the time and work that you spent on
it. With the respective DT nodes this works for me on the Pine64 and
turns this board eventually into something useful.

Some comments below:

> This patch add support for sun8i-emac ethernet MAC hardware.
> It could be found in Allwinner H3/A83T/A64 SoCs.
> 
> It supports 10/100/1000 Mbit/s speed with half/full duplex.
> It can use an internal PHY (MII 10/100) or an external PHY
> via RGMII/RMII.
> 
> Signed-off-by: LABBE Corentin 
> ---
>  drivers/net/ethernet/allwinner/Kconfig  |   13 +
>  drivers/net/ethernet/allwinner/Makefile |1 +
>  drivers/net/ethernet/allwinner/sun8i-emac.c | 1943 
> +++
>  3 files changed, 1957 insertions(+)
>  create mode 100644 drivers/net/ethernet/allwinner/sun8i-emac.c
> 
> diff --git a/drivers/net/ethernet/allwinner/Kconfig 
> b/drivers/net/ethernet/allwinner/Kconfig
> index 47da7e7..226499d 100644
> --- a/drivers/net/ethernet/allwinner/Kconfig
> +++ b/drivers/net/ethernet/allwinner/Kconfig
> @@ -33,4 +33,17 @@ config SUN4I_EMAC
>To compile this driver as a module, choose M here.  The module
>will be called sun4i-emac.
>  
> +config SUN8I_EMAC
> +tristate "Allwinner sun8i EMAC support"

nit: w/s error

> + depends on ARCH_SUNXI || COMPILE_TEST
> + depends on OF
> + select MII
> + select PHYLIB
> +---help---
> +   This driver support the sun8i EMAC ethernet driver present on
> +   H3/A83T/A64 Allwinner SoCs.
> +
> +  To compile this driver as a module, choose M here.  The module
> +  will be called sun8i-emac.
> +
>  endif # NET_VENDOR_ALLWINNER
> diff --git a/drivers/net/ethernet/allwinner/Makefile 
> b/drivers/net/ethernet/allwinner/Makefile
> index 03129f7..8bd1693c 100644
> --- a/drivers/net/ethernet/allwinner/Makefile
> +++ b/drivers/net/ethernet/allwinner/Makefile
> @@ -3,3 +3,4 @@
>  #
>  
>  obj-$(CONFIG_SUN4I_EMAC) += sun4i-emac.o
> +obj-$(CONFIG_SUN8I_EMAC) += sun8i-emac.o
> diff --git a/drivers/net/ethernet/allwinner/sun8i-emac.c 
> b/drivers/net/ethernet/allwinner/sun8i-emac.c
> new file mode 100644
> index 000..179aa61
> --- /dev/null
> +++ b/drivers/net/ethernet/allwinner/sun8i-emac.c
> @@ -0,0 +1,1943 @@
> +/*
> + * sun8i-emac driver
> + *
> + * Copyright (C) 2015-2016 Corentin LABBE 
> + *
> + * This is the driver for Allwinner Ethernet MAC found in H3/A83T/A64 SoC
> + *
> + * TODO:
> + * - NAPI
> + * - MAC filtering
> + * - Jumbo frame
> + * - features rx-all (NETIF_F_RXALL_BIT)
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define SUN8I_EMAC_BASIC_CTL0 0x00
> +#define SUN8I_EMAC_BASIC_CTL1 0x04
> +
> +#define SUN8I_EMAC_MDIO_CMD 0x48
> +#define SUN8I_EMAC_MDIO_DATA 0x4C

Can you align all these register offsets with tabs, so that the actual
offset values are below each other?
Also ordering them by address seems useful to me.

> +
> +#define SUN8I_EMAC_RX_CTL0 0x24
> +#define SUN8I_EMAC_RX_CTL1 0x28
> +
> +#define SUN8I_EMAC_TX_CTL0 0x10
> +#define SUN8I_EMAC_TX_CTL1 0x14
> +
> +#define SUN8I_EMAC_TX_FLOW_CTL 0x1C
> +
> +#define SUN8I_EMAC_RX_FRM_FLT 0x38
> +
> +#define SUN8I_EMAC_INT_STA 0x08
> +#define SUN8I_EMAC_INT_EN 0x0C
> +#define SUN8I_EMAC_RGMII_STA 0xD0


> +
> +#define SUN8I_EMAC_TX_DMA_STA 0xB0
> +#define SUN8I_EMAC_TX_CUR_DESC 0xB4
> +#define SUN8I_EMAC_TX_CUR_BUF 0xB8
> +#define SUN8I_EMAC_RX_DMA_STA 0xC0
> +
> +#define MDIO_CMD_MII_BUSYBIT(0)
> +#define MDIO_CMD_MII_WRITE   BIT(1)
> +#define MDIO_CMD_MII_PHY_REG_ADDR_MASK   GENMASK(8, 4)
> +#define MDIO_CMD_MII_PHY_REG_ADDR_SHIFT  4
> +#define MDIO_CMD_MII_PHY_ADDR_MASK   GENMASK(16, 12)
> +#define MDIO_CMD_MII_PHY_ADDR_SHIFT  12
> +
> +#define SUN8I_EMAC_MACADDR_HI0x50
> +#define SUN8I_EMAC_MACADDR_LO0x54
> +
> +#define SUN8I_EMAC_RX_DESC_LIST 0x34
> +#define SUN8I_EMAC_TX_DESC_LIST 0x20
> +
> +#define SUN8I_EMAC_TX_DO_CRC (BIT(27) | BIT(28))
> +#define SUN8I_EMAC_RX_DO_CRC BIT(27)
> +#define SUN8I_EMAC_RX_STRIP_FCS BIT(28)
> +
> +#define SUN8I_COULD_BE_USED_BY_DMA BIT(31)
> +
> +#define FLOW_RX 1
> +#define FLOW_TX 2
> +
> +/* describe how data from skb are DMA mapped */
> +#define MAP_SINGLE 1
> +#define MAP_PAGE 2
> +
> +enum emac_variant {
> + A83T_EMAC,
> + H3_EMAC,
> + A64_EMAC,
> +};
> +
> +struct ethtool_str {
> + char name[ETH_GSTRING_LEN];
> +};
> +
> +static const struct ethtool_str estats_str[] = {
> + /* errors */
> + { "rx_payload_error" },
> + { "rx_CRC_error" },
> + { "rx_phy_error" },
> + { "rx_length_error" },
> + { "rx_col_error" },
> + { "rx_header_error" },
> + { "rx_overflow_error" },
> 

Re: [PATCH net-next 8/9] net: dsa: bcm_sf2: Make it a real platform device driver

[Florian Fainelli]

Le 04/06/2016 13:55, Andrew Lunn a écrit :
>> -static struct dsa_switch_driver bcm_sf2_switch_driver = {
>> +static struct dsa_switch_driver bcm_sf2_switch_ops = {
>>  .tag_protocol   = DSA_TAG_PROTO_BRCM,
>>  .probe  = bcm_sf2_sw_drv_probe,
>>  .setup  = bcm_sf2_sw_setup,
> 
> Does this also allow you to kill bcm_sf2_sw_drv_probe?
> 
> dsa2 will never call it, and now you have your old binding parsed by
> the legacy code in dsa2, you might not need it at all.

Good point, yes, that can go away now, thanks!
-- 
Florian

Re: [PATCH net-next 7/9] net: dsa: Initialize CPU port ethtool ops per tree

[Florian Fainelli]

Le 04/06/2016 13:38, Andrew Lunn a écrit :
>> index e8386157de30..938262010524 100644
>> --- a/net/dsa/dsa2.c
>> +++ b/net/dsa/dsa2.c
>> @@ -346,7 +346,7 @@ static int dsa_ds_apply(struct dsa_switch_tree *dst, 
>> struct dsa_switch *ds)
>>  continue;
>>  }
>>  
>> -return 0;
>> +return dsa_cpu_port_ethtool_setup(dst, ds);
> 
> Hi Florian
> 
> This is wrong. Remember, multiple CPU ports. You need to apply this to
> each CPU port.

We do not quite support that properly though, we still do not create a
"cpu" network device, and there is only a single master netdev per
dsa_switch at the moment, making the secondary CPU port interfaces
impossible to overlay their backing "master" netdev with their companion
switch port statistics at the moment.

This fixes a real bug where we end-up clobbering
dsa_cpu_port_ethtool_ops as soon as there are multiple trees being
registered, and this can now happen.
-- 
Florian

Re: [PATCH 07/23] netfilter: x_tables: check standard target size too

[Florian Westphal]

Andreas Schwab  wrote:
> > From: Florian Westphal 
> >
> > We have targets and standard targets -- the latter carries a verdict.
> >
> > The ip/ip6tables validation functions will access t->verdict for the
> > standard targets to fetch the jump offset or verdict for chainloop
> > detection, but this happens before the targets get checked/validated.
> >
> > Thus we also need to check for verdict presence here, else t->verdict
> > can point right after a blob.
> >
> > Spotted with UBSAN while testing malformed blobs.
> 
> This breaks iptables on PPC32.

Yes, we got bug report for arm32, I'm sorry about this -- only 32bit
platform I tested was i686 and that only needs 4byte alignment for u64.

This fix should help:

https://git.kernel.org/cgit/linux/kernel/git/pablo/nf.git/commit/?id=7b7eba0f3515fca3296b8881d583f7c1042f5226

[PATCH 0/2] NET: PHY: Add PHY LED control binding.

[Hauke Mehrtens]

This is now spitted out of the patch series that adds support the 
Ethernet PHY. The second patch depends on the Ethernet PHY code which I 
send before. How should this get merged, or should I split this in a 
different way?

Hauke Mehrtens (2):
  NET: PHY: Add PHY LED control binding.
  NET: PHY: Intel XWAY: add LED configuration support

 .../devicetree/bindings/phy/intel-xway.txt |  77 +++
 Documentation/devicetree/bindings/phy/phy-leds.txt |  52 +++
 drivers/net/phy/intel-xway.c   | 152 +
 include/dt-bindings/phy/phy-leds.h |  27 
 4 files changed, 308 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/intel-xway.txt
 create mode 100644 Documentation/devicetree/bindings/phy/phy-leds.txt
 create mode 100644 include/dt-bindings/phy/phy-leds.h

-- 
2.8.1

[PATCH 2/2] NET: PHY: Intel XWAY: add LED configuration support

[Hauke Mehrtens]

This makes it possible to configure the behavior of the LEDs connected
to a PHY. The LEDs are controlled by the chip, this makes it possible
to configure the behavior when the hardware should activate and
deactivate the LEDs.

Signed-off-by: Hauke Mehrtens 
---
 .../devicetree/bindings/phy/intel-xway.txt |  77 +++
 drivers/net/phy/intel-xway.c   | 152 +
 2 files changed, 229 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/intel-xway.txt

diff --git a/Documentation/devicetree/bindings/phy/intel-xway.txt 
b/Documentation/devicetree/bindings/phy/intel-xway.txt
new file mode 100644
index 000..02891c4
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/intel-xway.txt
@@ -0,0 +1,77 @@
+Intel XWAY Ethernet PHY binding
+--
+
+This supports the Intel XWAY (former Lantiq) 11G and 22E PHYs. These
+PHYs are also named PEF 7061, PEF 7071 and PEF 7072.
+
+Required properties:
+ - compatible: should be "ethernet-phy-ieee802.3-c22"
+ - reg:MDIO address of this PHY
+
+
+LEDs:
+The PEF 7071 PHY supports 3 LEDs, the PEF 7072 PHY supports 4 LEDs. Use
+one subnode for each LED. By default the LEDs 0, 1 and 2 are switched
+to be constant on when a 10MBit/s, 100MBit/s or 1000MBit/s link is
+detected and they blink when TX or RX traffic is detected. All 3 LEDs
+are doing the same as most known devices only have one LED.
+
+To change the behavior create a subnode with the following attributes:
+
+Required properties:
+ - compatible: should be: "phy,led"
+ - reg:led number
+
+optional properties:
+ - led-const-on:   Conditions when being constant on
+   Possible options are one of these:
+   LED_LINK10, LED_LINK100 and LED_LINK1000, or
+   some of these 3 values connected with OR.
+   PHY_LED_PDOWN, PHY_LED_EEE, PHY_LED_ANEG,
+   PHY_LED_ABIST, PHY_LED_CDIAG, PHY_LED_COPPER,
+   PHY_LED_FIBER.
+ - led-pulse:  Conditions when led is pulsed
+   The following values can be connected with OR:
+   PHY_LED_TXACT, PHY_LED_RXACT, PHY_LED_COL
+ - led-blink-slow: Conditions when led should blink with 2Hz:
+   Possible options are one of these:
+   LED_LINK10, LED_LINK100 and LED_LINK1000, or
+   some of these 3 values connected with OR.
+   PHY_LED_PDOWN, PHY_LED_EEE, PHY_LED_ANEG,
+   PHY_LED_ABIST, PHY_LED_CDIAG.
+ - led-blink-fast: Conditions when led should blink with 16Hz:
+   Possible options are one of these:
+   LED_LINK10, LED_LINK100 and LED_LINK1000, or
+   some of these 3 values connected with OR.
+   PHY_LED_PDOWN, PHY_LED_EEE, PHY_LED_ANEG,
+   PHY_LED_ABIST, PHY_LED_CDIAG.
+
+When multiple properties are set they are applied with the following priority:
+ 1. led-pulse
+ 2. led-blink-fast
+ 3. led-blink-slow
+ 4. led-const-on
+ 5. off
+
+
+Example:
+
+#include 
+phy@0 {
+   compatible = "intel,phy11g", "ethernet-phy-ieee802.3-c22";
+   reg = <0x0>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   led@0 {
+   compatible = "phy,led";
+   reg = <0>;
+   led-const-on = <(PHY_LED_LINK10 | PHY_LED_LINK100 | 
PHY_LED_LINK1000)>;
+   led-pulse = <(PHY_LED_TXACT | PHY_LED_RXACT)>;
+   };
+   led@2 {
+   compatible = "phy,led";
+   reg = <2>;
+   led-blink-slow = ;
+   led-blink-fast = ;
+   };
+};
diff --git a/drivers/net/phy/intel-xway.c b/drivers/net/phy/intel-xway.c
index c300ab5..6469ded 100644
--- a/drivers/net/phy/intel-xway.c
+++ b/drivers/net/phy/intel-xway.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define XWAY_MDIO_IMASK0x19/* interrupt mask */
 #define XWAY_MDIO_ISTAT0x1A/* interrupt status */
@@ -152,11 +153,158 @@
 #define PHY_ID_PHY11G_VR9  0xD565A409
 #define PHY_ID_PHY22F_VR9  0xD565A419
 
+static void xway_gphy_config_led(struct phy_device *phydev,
+struct device_node *led_np)
+{
+   const __be32 *addr, *blink_fast_p, *const_on_p, *pulse_p, *blink_slow_p;
+   u32 num, blink_fast, const_on, pulse, blink_slow;
+   u32 ledxl;
+   u32 ledxh;
+
+   addr = of_get_property(led_np, "reg", NULL);
+   if (!addr)
+   return;
+   num = be32_to_cpu(*addr);
+
+   if (num < 0 || num > 3)
+   return;
+
+   ledxh = XWAY_MMD_LEDxH_BLINKF_NONE | XWAY_MMD_LEDxH_CON_LINK10XX;
+   blink_fast_p = of_get_property(led_np, "led-blink-fast", NULL);
+   if (blink_fast_p) 

[PATCH 1/2] NET: PHY: Add PHY LED control binding.

[Hauke Mehrtens]

This binding makes it possible to control the LEDs of an Ethernet PHY.
These settings allow it to abstract the hardware configuration which
tells the hardware when to switch the LED constant on or blink for
example. This will be used by the Intel XWAY PHY driver.  I also
checked datasheets for some other Ethernet PHYs and it should be
possible to also control their LED behavior with these settings, but
they all did not allow a so fine control over the LED behavior.

Signed-off-by: Hauke Mehrtens 
---
 Documentation/devicetree/bindings/phy/phy-leds.txt | 52 ++
 include/dt-bindings/phy/phy-leds.h | 27 +++
 2 files changed, 79 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/phy-leds.txt
 create mode 100644 include/dt-bindings/phy/phy-leds.h

diff --git a/Documentation/devicetree/bindings/phy/phy-leds.txt 
b/Documentation/devicetree/bindings/phy/phy-leds.txt
new file mode 100644
index 000..1a35e3d
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-leds.txt
@@ -0,0 +1,52 @@
+LED configuration for Ethernet phys
+
+All these properties are optional, not all properties are supported by
+all PHYs. When more then one property name is define for one LED the
+order they get applied is device depended.
+Property names:
+   led-const-on: conditions the LED should be constant on
+   led-pulse: condition the LED should be pulsed on
+   led-blink-slow: condition the LED should slowly blink
+   led-blink-fast: condition the LED should fast blink
+
+These property values define the states a LED is triggered by the
+hardware. Not all PHYs support all states. It is possible to connect
+these property values with OR to trigger the LED in multiple stats like
+10MBit/s and 100MBit/s. The possible combinations are device specific.
+property values:
+   PHY_LED_OFF:LED is off
+   PHY_LED_LINK10: link is 10MBit/s
+   PHY_LED_LINK100:link is 100MBit/s
+   PHY_LED_LINK1000:   link is 1000MBit/s
+   PHY_LED_PDOWN:  link is powered down
+   PHY_LED_EEE:link is in EEE mode
+   PHY_LED_ANEG:   auto negotiation is running
+   PHY_LED_ABIST:  analog self testing is running
+   PHY_LED_CDIAG:  cable diagnostics is running
+   PHY_LED_COPPER: copper interface detected
+   PHY_LED_FIBER:  fiber interface detected
+   PHY_LED_TXACT:  Transmit activity
+   PHY_LED_RXACT:  Receive activity
+   PHY_LED_COL:Collision
+
+Example:
+
+#include 
+phy@0 {
+   compatible = "ethernet-phy-ieee802.3-c22";
+   reg = <0x0>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   led@0 {
+   compatible = "phy,led";
+   reg = <0>;
+   led-const-on = <(PHY_LED_LINK10 | PHY_LED_LINK100 | 
PHY_LED_LINK1000)>;
+   led-pulse = <(PHY_LED_TXACT | PHY_LED_RXACT)>;
+   };
+   led@2 {
+   compatible = "phy,led";
+   reg = <2>;
+   led-blink-slow = ;
+   led-blink-fast = ;
+   };
+};
diff --git a/include/dt-bindings/phy/phy-leds.h 
b/include/dt-bindings/phy/phy-leds.h
new file mode 100644
index 000..801fdaf
--- /dev/null
+++ b/include/dt-bindings/phy/phy-leds.h
@@ -0,0 +1,27 @@
+/*
+ * Copyright (C) 2016 Hauke Mehrtens 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ */
+
+#ifndef _DT_BINDINGS_PHY_LEDS
+#define _DT_BINDINGS_PHY_LEDS
+
+#define PHY_LED_OFF(1 << 0)  /* is off */
+#define PHY_LED_LINK10 (1 << 1)  /* link is 10MBit/s */
+#define PHY_LED_LINK100(1 << 2)  /* link is 100MBit/s */
+#define PHY_LED_LINK1000   (1 << 3)  /* link is 1000MBit/s */
+#define PHY_LED_PDOWN  (1 << 4)  /* link is powered down */
+#define PHY_LED_EEE(1 << 5)  /* link is in EEE mode */
+#define PHY_LED_ANEG   (1 << 6)  /* auto negotiation is running */
+#define PHY_LED_ABIST  (1 << 7)  /* analog self testing is running */
+#define PHY_LED_CDIAG  (1 << 8)  /* cable diagnostics is running */
+#define PHY_LED_COPPER (1 << 9)  /* copper interface detected */
+#define PHY_LED_FIBER  (1 << 10) /* fiber interface detected */
+#define PHY_LED_TXACT  (1 << 11) /* Transmit activity */
+#define PHY_LED_RXACT  (1 << 12) /* Receive activity */
+#define PHY_LED_COL(1 << 13) /* Collision */
+
+#endif /* _DT_BINDINGS_PHY_LEDS */
-- 
2.8.1

[PATCH] NET: PHY: adds driver for Intel XWAY PHY

[Hauke Mehrtens]

This adds support for the Intel (former Lantiq) XWAY 11G and 22E PHYs.
These PHYs are also named PEF 7061, PEF 7071, PEF 7072.

Signed-off-by: John Crispin 
Signed-off-by: Hauke Mehrtens 
---

changes since last RFC:
 * activated interrupts for all versions, if it causes problems it 
   should be deactivated in the device tree file
 * renamed xRX200 to xRX integrated, this is also found in other SoCs.

 drivers/net/phy/Kconfig  |   8 +
 drivers/net/phy/Makefile |   1 +
 drivers/net/phy/intel-xway.c | 376 +++
 3 files changed, 385 insertions(+)
 create mode 100644 drivers/net/phy/intel-xway.c

diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 6dad9a9..37d40c1 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -271,6 +271,14 @@ config MDIO_BCM_IPROC
  This module provides a driver for the MDIO busses found in the
  Broadcom iProc SoC's.
 
+config INTEL_XWAY_PHY
+   tristate "Driver for Intel XWAY PHYs"
+   ---help---
+ Supports the Intel XWAY (former Lantiq) 11G and 22E PHYs.
+ These PHYs are marked as standalone chips under the names
+ PEF 7061, PEF 7071 and PEF 7072 or integrated into the Intel
+ SoCs xRX200, xRX300, xRX330, xRX350 and xRX550.
+
 endif # PHYLIB
 
 config MICREL_KS8995MA
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index fcdbb92..c26b651 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -44,3 +44,4 @@ obj-$(CONFIG_MDIO_MOXART) += mdio-moxart.o
 obj-$(CONFIG_MDIO_BCM_UNIMAC)  += mdio-bcm-unimac.o
 obj-$(CONFIG_MICROCHIP_PHY)+= microchip.o
 obj-$(CONFIG_MDIO_BCM_IPROC)   += mdio-bcm-iproc.o
+obj-$(CONFIG_INTEL_XWAY_PHY)   += intel-xway.o
diff --git a/drivers/net/phy/intel-xway.c b/drivers/net/phy/intel-xway.c
new file mode 100644
index 000..c300ab5
--- /dev/null
+++ b/drivers/net/phy/intel-xway.c
@@ -0,0 +1,376 @@
+/*
+ * Copyright (C) 2012 Daniel Schwierzeck 
+ * Copyright (C) 2016 Hauke Mehrtens 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#define XWAY_MDIO_IMASK0x19/* interrupt mask */
+#define XWAY_MDIO_ISTAT0x1A/* interrupt status */
+
+#define XWAY_MDIO_INIT_WOL BIT(15) /* Wake-On-LAN */
+#define XWAY_MDIO_INIT_MSREBIT(14)
+#define XWAY_MDIO_INIT_NPRXBIT(13)
+#define XWAY_MDIO_INIT_NPTXBIT(12)
+#define XWAY_MDIO_INIT_ANE BIT(11) /* Auto-Neg error */
+#define XWAY_MDIO_INIT_ANC BIT(10) /* Auto-Neg complete */
+#define XWAY_MDIO_INIT_ADSCBIT(5)  /* Link auto-downspeed detect */
+#define XWAY_MDIO_INIT_MPIPC   BIT(4)
+#define XWAY_MDIO_INIT_MDIXC   BIT(3)
+#define XWAY_MDIO_INIT_DXMCBIT(2)  /* Duplex mode change */
+#define XWAY_MDIO_INIT_LSPCBIT(1)  /* Link speed change */
+#define XWAY_MDIO_INIT_LSTCBIT(0)  /* Link state change */
+#define XWAY_MDIO_INIT_MASK(XWAY_MDIO_INIT_LSTC | \
+XWAY_MDIO_INIT_ADSC)
+
+#define ADVERTISED_MPD BIT(10) /* Multi-port device */
+
+/* LED Configuration */
+#define XWAY_MMD_LEDCH 0x01E0
+/* Inverse of SCAN Function */
+#define  XWAY_MMD_LEDCH_NACS_NONE  0x
+#define  XWAY_MMD_LEDCH_NACS_LINK  0x0001
+#define  XWAY_MMD_LEDCH_NACS_PDOWN 0x0002
+#define  XWAY_MMD_LEDCH_NACS_EEE   0x0003
+#define  XWAY_MMD_LEDCH_NACS_ANEG  0x0004
+#define  XWAY_MMD_LEDCH_NACS_ABIST 0x0005
+#define  XWAY_MMD_LEDCH_NACS_CDIAG 0x0006
+#define  XWAY_MMD_LEDCH_NACS_TEST  0x0007
+/* Slow Blink Frequency */
+#define  XWAY_MMD_LEDCH_SBF_F02HZ  0x
+#define  XWAY_MMD_LEDCH_SBF_F04HZ  0x0010
+#define  XWAY_MMD_LEDCH_SBF_F08HZ  0x0020
+#define  XWAY_MMD_LEDCH_SBF_F16HZ  0x0030
+/* Fast Blink Frequency */
+#define  XWAY_MMD_LEDCH_FBF_F02HZ  0x
+#define  XWAY_MMD_LEDCH_FBF_F04HZ  0x0040
+#define  XWAY_MMD_LEDCH_FBF_F08HZ  0x0080
+#define  XWAY_MMD_LEDCH_FBF_F16HZ  0x00C0
+/* LED Configuration */
+#define XWAY_MMD_LEDCL 0x01E1
+/* Complex Blinking Configuration */
+#define  XWAY_MMD_LEDCH_CBLINK_NONE0x
+#define  XWAY_MMD_LEDCH_CBLINK_LINK0x0001
+#define  XWAY_MMD_LEDCH_CBLINK_PDOWN   0x0002
+#define  XWAY_MMD_LEDCH_CBLINK_EEE 

Re: [PATCH 07/23] netfilter: x_tables: check standard target size too

[Andreas Schwab]

Pablo Neira Ayuso  writes:

> From: Florian Westphal 
>
> We have targets and standard targets -- the latter carries a verdict.
>
> The ip/ip6tables validation functions will access t->verdict for the
> standard targets to fetch the jump offset or verdict for chainloop
> detection, but this happens before the targets get checked/validated.
>
> Thus we also need to check for verdict presence here, else t->verdict
> can point right after a blob.
>
> Spotted with UBSAN while testing malformed blobs.

This breaks iptables on PPC32.

# iptables -nL
iptables v1.4.21: can't initialize iptables table `filter': Table does not 
exist (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
# modprobe iptable-filter
FATAL: Error inserting iptable_filter 
(/lib/modules/4.7.0-rc1/kernel/net/ipv4/netfilter/iptable_filter.ko): Invalid 
argument

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [PATCH v2 net] fq_codel: fix NET_XMIT_CN behavior

[Eric Dumazet]

On Sun, 2016-06-05 at 13:54 -0700, Eric Dumazet wrote:

> BTW, we might need a similar fix in sch_fq.c

I meant sch_sfq.c

Re: [PATCH v2 net] fq_codel: fix NET_XMIT_CN behavior

[Eric Dumazet]

On Sun, 2016-06-05 at 13:30 -0700, Cong Wang wrote:
> On Sat, Jun 4, 2016 at 12:55 PM, Eric Dumazet  wrote:
> > From: Eric Dumazet 
> >
> > My prior attempt to fix the backlogs of parents failed.
> >
> > If we return NET_XMIT_CN, our parents wont increase their backlog,
> > so our qdisc_tree_reduce_backlog() should take this into account.
> >
> 
> Acked-by: Cong Wang 

BTW, we might need a similar fix in sch_fq.c

Re: [PATCH v2 net] fq_codel: fix NET_XMIT_CN behavior

[Cong Wang]

On Sat, Jun 4, 2016 at 12:55 PM, Eric Dumazet  wrote:
> From: Eric Dumazet 
>
> My prior attempt to fix the backlogs of parents failed.
>
> If we return NET_XMIT_CN, our parents wont increase their backlog,
> so our qdisc_tree_reduce_backlog() should take this into account.
>

Acked-by: Cong Wang 

[PATCH] staging: r8188eu: Fix scheduling while atomic splat

[Larry Finger]

Commit fadbe0cd5292851608e2e01b91d9295fa287b9fe ("staging: rtl8188eu:
Remove rtw_zmalloc(), wrapper for kzalloc()") changed all allocation
calls to be GFP_KERNEL even though the original wrapper was testing
to determine if the caller was in atomic mode. Most of the mistakes
were corrected with commit 33dc85c3c667209c930b2dac5ccbc2a365e06b7a
("staging: r8188eu: Fix scheduling while atomic error introduced in
commit fadbe0cd"); however, two kzalloc calls were missed as the
call only happens when the driver is shutting down.

Fixes: fadbe0cd5292851608e2e01b91d9295fa287b9fe ("staging: rtl8188eu: Remove 
rtw_zmalloc(), wrapper for kzalloc()")
Signed-off-by: Larry Finger 
Cc: navin patidar 
---
 drivers/staging/rtl8188eu/core/rtw_cmd.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_cmd.c 
b/drivers/staging/rtl8188eu/core/rtw_cmd.c
index 7748523..32d3a9c 100644
--- a/drivers/staging/rtl8188eu/core/rtw_cmd.c
+++ b/drivers/staging/rtl8188eu/core/rtw_cmd.c
@@ -670,13 +670,13 @@ u8 rtw_addbareq_cmd(struct adapter *padapter, u8 tid, u8 
*addr)
u8  res = _SUCCESS;
 
 
-   ph2c = kzalloc(sizeof(struct cmd_obj), GFP_KERNEL);
+   ph2c = kzalloc(sizeof(struct cmd_obj), GFP_ATOMIC);
if (!ph2c) {
res = _FAIL;
goto exit;
}
 
-   paddbareq_parm = kzalloc(sizeof(struct addBaReq_parm), GFP_KERNEL);
+   paddbareq_parm = kzalloc(sizeof(struct addBaReq_parm), GFP_ATOMIC);
if (!paddbareq_parm) {
kfree(ph2c);
res = _FAIL;
-- 
2.1.4

Re: [PATCH 1/1] ixgbe: replace rtnl_lock with rcu_read_lock

[Alexander Duyck]

On Sun, Jun 5, 2016 at 2:14 AM,   wrote:
> From: Zhu Yanjun 
>
>
> Signed-off-by: Zhu Yanjun 
> ---
>  drivers/net/ethernet/intel/ixgbe/ixgbe_main.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c 
> b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> index 088c47c..cb19cbc 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> @@ -6840,7 +6840,7 @@ static void ixgbe_watchdog_link_is_up(struct 
> ixgbe_adapter *adapter)
> netif_tx_wake_all_queues(adapter->netdev);
>
> /* enable any upper devices */
> -   rtnl_lock();
> +   rcu_read_lock();
> netdev_for_each_all_upper_dev_rcu(adapter->netdev, upper, iter) {
> if (netif_is_macvlan(upper)) {
> struct macvlan_dev *vlan = netdev_priv(upper);
> @@ -6849,7 +6849,7 @@ static void ixgbe_watchdog_link_is_up(struct 
> ixgbe_adapter *adapter)
> netif_tx_wake_all_queues(upper);
> }
> }
> -   rtnl_unlock();
> +   rcu_read_unlock();
>
> /* update the default user priority for VFs */
> ixgbe_update_default_up(adapter);

The rtnl_lock is being used to prevent any changes to the upper
devices while the interface is going through and updating the Tx queue
configuration on them.  Without that lock you introduce possible bugs
since you could have queues freed or added while this loop is in the
middle of trying to update the state of it.

As a general rule you use rcu_read_lock when you are only reading an
RCU protected structure, you use rtnl_lock when you have to protect
the system from any other changes while you are updating network
configuration.  In this case netif_tx_wake_all_queues changes the
state of the upper device.  The use of rtnl_lock here is intentional
and it is best to just leave it as is unless you have some actual bug
you are seeing.

- Alex

RE: [RFC net-next 1/1] ethtool: Add support for set eeprom metadata.

[Yuval Mintz]

> > > > > Currently ethtool implementation does not have a way to pass the
> > > > > metadata for eeprom related operations. Some adapters have a
> > > > > complicated non-volatile memory implementation that requires
> > > > > additional information – there are drivers [bnx2x and bnxt] that
> > > > > use the ‘magic’ field in the {G,S}EEPROM  for that purpose,
> > > > > although that’s not
> > > its intended usage.
> > > > >
> > > > > This patch adds a provision to pass the eeprom metadata for
> > > > > %ETHTOOL_SEEPROM/%ETHTOOL_GEEPROM implementations. User
> > > provided
> > > > > metadata will be cached by the driver and assigns a magic value
> > > > > which the application need to use for the subsequent {G,S}EEPROM
> > > command.
> > > >
> > > > Hi Dave,
> > > >
> > > > This got no comments at all.
> > > > What do you want us to with it next? Should we re-send it as a patch?
> > >
> > > Here's a comment: I really dislike this.
> > :-)
> >
> > > - It doesn't specify any semantics for the 'metadata'.  The comment
> > > hints that they are driver-specific identifiers for different NVRAM 
> > > partitions.
> > Not exactly, but close [in our use case there are 2 'methods' of
> > accessing the flash - either according to addresses or logical 'files'].
> >
> > > - It doesn't provide a way for userland to enumerate the valid metadata
> values.
> > I agree; I can't think of any good way of enumerating device-specific 
> > values.
> >
> > > - It's not clear whether the driver is supposed to maintain just one
> > > metadata:magic mapping, or more than that.
> > Theoretically, I guess it could maintain multiple, but that wasn't the 
> > intention.
> > One should do.
> >
> > > Is the ethtool API really the right interface for access to flash?
> > > The sfc driver exposes a large number of flash partitions using MTD
> > > instead.  These can be enumerated (through /proc/mtd or sysfs) and
> > > they can be read and written through block devices.
> >
> > I think the better question then is 'what's the purpose of this ethtool API 
> > at
> all'?
> 
> I think it's a bit of an accident - MTD was designed for flash in embedded
> systems, and it used to have a static limit on the number of partitions.  The
> ethtool API was then rather better suited to plug-in cards that would have a
> single small EEPROM.
> 
> > I agree we can go and do everything via MTD; The reason we've tried
> > using this API was mainly... because it was there. And thus we thought
> > this is the RIGHT method for providing users the way of reading their flash.
> [...]
> 
> I think that MTD makes more sense for flash partitions, especially when there
> are several of them.  I already did the work of removing the static limit on 
> the
> number of partitions, and convincing distributions to enable the MTD core
> drivers.  (That said, you will still find some users who need to change their
> custom kernel
> configurations.)

Notice we don't really have multiple partitions. We have a single partition
pseudo file-system, but problem is device has no direct access to the 
controller;
Every access has to go via the management firmware. 
And in order to work with it we need some additional metadata.
I think MTD would eventually look just as 'magical'.

Re: [PATCH net-next] net, cls: allow for deleting all filters for given parent

[Daniel Borkmann]

On 06/05/2016 02:53 PM, Sergei Shtylyov wrote:

On 6/4/2016 7:24 PM, Daniel Borkmann wrote:

[...]


Need a comment here, something like /* FALL THRU */.


Hmm, not really, I think it's obvious enough.


+default:
 return -ENOENT;
-prio = TC_H_MAKE(0x8000U, 0U);
+}
 }

 /* Find head of filter chain. */

[...]

MBR, Sergei

Re: ath9k gpio request

[Sudip Mukherjee]

On Saturday 04 June 2016 08:07 PM, Kalle Valo wrote:

(Fixing top posting)

"Pan, Miaoqing"  writes:


--- a/drivers/net/wireless/ath/ath9k/reg.h
+++ b/drivers/net/wireless/ath/ath9k/reg.h
@@ -1122,8 +1122,8 @@ enum {
   #define AR9300_NUM_GPIO  16
   #define AR9330_NUM_GPIO 16
   #define AR9340_NUM_GPIO 23
-#define AR9462_NUM_GPIO 10
-#define AR9485_NUM_GPIO 12
+#define AR9462_NUM_GPIO 14
+#define AR9485_NUM_GPIO 11
   #define AR9531_NUM_GPIO 18
   #define AR9550_NUM_GPIO 24
   #define AR9561_NUM_GPIO 23
@@ -1139,8 +1139,8 @@ enum {
   #define AR9300_GPIO_MASK0xF4FF
   #define AR9330_GPIO_MASK0xF4FF
   #define AR9340_GPIO_MASK0x000F
-#define AR9462_GPIO_MASK0x03FF
-#define AR9485_GPIO_MASK0x0FFF
+#define AR9462_GPIO_MASK0x3FFF
+#define AR9485_GPIO_MASK0x07FF
   #define AR9531_GPIO_MASK0x000F
   #define AR9550_GPIO_MASK0x000F
   #define AR9561_GPIO_MASK0x000F


solves the problem.

Tested-by: Sudip Mukherjee 


Done, https://patchwork.kernel.org/patch/9151847/


But the patch 9151847 is different from what Sudip tested above? Why?

And if you modify something _after_ the reporter has tested the patch
clearly document what you changed and why. I do not want find hidden
changes like this, even more so when the patch is going to a 4.7-rc
release.

Sudip, could you also test patch 9151847, please? You can download the
patch from the patchwork link above.


This is also ok. Please add my
Tested-by: Sudip Mukherjee 

and maybe a Reported-by tag is also appropriate in this case.


Regards
Sudip

Re: [RFC net-next 1/1] ethtool: Add support for set eeprom metadata.

[Ben Hutchings]

On Sun, 2016-06-05 at 13:29 +, Yuval Mintz wrote:
> > 
> > > > Currently ethtool implementation does not have a way to pass the
> > > > metadata for eeprom related operations. Some adapters have a
> > > > complicated non-volatile memory implementation that requires
> > > > additional information – there are drivers [bnx2x and bnxt] that use
> > > > the ‘magic’ field in the {G,S}EEPROM  for that purpose, although that’s 
> > > > not
> > its intended usage.
> > > > 
> > > > This patch adds a provision to pass the eeprom metadata for
> > > > %ETHTOOL_SEEPROM/%ETHTOOL_GEEPROM implementations. User
> > provided
> > > > metadata will be cached by the driver and assigns a magic value
> > > > which the application need to use for the subsequent {G,S}EEPROM
> > command.
> > > 
> > > Hi Dave,
> > > 
> > > This got no comments at all.
> > > What do you want us to with it next? Should we re-send it as a patch?
> > 
> > Here's a comment: I really dislike this.
> :-)
> 
> > - It doesn't specify any semantics for the 'metadata'.  The comment hints 
> > that
> > they are driver-specific identifiers for different NVRAM partitions.
> Not exactly, but close [in our use case there are 2 'methods' of accessing the
> flash - either according to addresses or logical 'files'].
> 
> > - It doesn't provide a way for userland to enumerate the valid metadata 
> > values.
> I agree; I can't think of any good way of enumerating device-specific values.
> 
> > - It's not clear whether the driver is supposed to maintain just one
> > metadata:magic mapping, or more than that.
> Theoretically, I guess it could maintain multiple, but that wasn't the 
> intention.
> One should do.
> 
> > Is the ethtool API really the right interface for access to flash?  The sfc 
> > driver
> > exposes a large number of flash partitions using MTD instead.  These can be
> > enumerated (through /proc/mtd or sysfs) and they can be read and written
> > through block devices.
> 
> I think the better question then is 'what's the purpose of this ethtool API 
> at all'?

I think it's a bit of an accident - MTD was designed for flash in
embedded systems, and it used to have a static limit on the number of
partitions.  The ethtool API was then rather better suited to plug-in
cards that would have a single small EEPROM.

> I agree we can go and do everything via MTD; The reason we've tried using this
> API was mainly... because it was there. And thus we thought this is the RIGHT
> method for providing users the way of reading their flash.
[...]

I think that MTD makes more sense for flash partitions, especially when
there are several of them.  I already did the work of removing 
the static limit on the number of partitions, and convincing
distributions to enable the MTD core drivers.  (That said, you will
still find some users who need to change their custom kernel
configurations.)

Ben.

-- 
Ben Hutchings
Everything should be made as simple as possible, but not simpler.
   - Albert
Einstein



signature.asc
Description: This is a digitally signed message part

Good Day

[China Textiles Ltd]

It is my pleasure to announce to you the vacancy of a collection 
representative post for China Textiles Ltd in your country,if you are 
interested you will be given 5% for every collection made on our 
clients, for more details

Respond.
Sincerely,
Dave Desmond.

[PATCH V2] staging: r8188eu: Fix crash caused by commit 99aded71b52c

[Larry Finger]

Commit 99aded71b52cfdfa22721c42e42efdd13a02f0a6 ("Staging: drivers: rtl8188eu:
use sizeof(*ptr) instead of sizeof(struct)") introduces an error in that the
sizeof(struct hal_data_8188e) is 18712, while the sizeof(*adapt->HalData) is
only 1! As a result, the system panics.

Fixes: 99aded71b52cfdfa22721c42e42efdd13a02f0a6 ("Staging: drivers: rtl8188eu: 
use sizeof(*ptr) instead of sizeof(struct)")
Signed-off-by: Larry Finger 
Cc: Jacky Boen 
---
V2 - Remove extra blank line inserted by mistake.
---
 drivers/staging/rtl8188eu/hal/usb_halinit.c | 2 +-
 1 file changed, 1 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8188eu/hal/usb_halinit.c 
b/drivers/staging/rtl8188eu/hal/usb_halinit.c
index 87ea3b8..363f3a3 100644
--- a/drivers/staging/rtl8188eu/hal/usb_halinit.c
+++ b/drivers/staging/rtl8188eu/hal/usb_halinit.c
@@ -2072,7 +2072,7 @@ void rtl8188eu_set_hal_ops(struct adapter *adapt)
 {
struct hal_ops  *halfunc = >HalFunc;
 
-   adapt->HalData = kzalloc(sizeof(*adapt->HalData), GFP_KERNEL);
+   adapt->HalData = kzalloc(sizeof(struct hal_data_8188e), GFP_KERNEL);
if (!adapt->HalData)
DBG_88E("cant not alloc memory for HAL DATA\n");
 
-- 
2.1.4

[PATCH] staging: r8188eu: Remove some false positives from kmemleak

[Larry Finger]

When this driver preallocates some SKBs, kmemleak is unable to find that
allocated memory when it scans. When the driver is unloaded, that memory
is released; therefore, the report is a false positive.

Signed-off-by: Larry Finger 
---
 drivers/staging/rtl8188eu/hal/rtl8188eu_recv.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/staging/rtl8188eu/hal/rtl8188eu_recv.c 
b/drivers/staging/rtl8188eu/hal/rtl8188eu_recv.c
index 255d6f2..093a998 100644
--- a/drivers/staging/rtl8188eu/hal/rtl8188eu_recv.c
+++ b/drivers/staging/rtl8188eu/hal/rtl8188eu_recv.c
@@ -13,6 +13,7 @@
  *
  
**/
 #define _RTL8188EU_RECV_C_
+#include 
 #include 
 #include 
 #include 
@@ -72,6 +73,7 @@ int   rtl8188eu_init_recv_priv(struct adapter *padapter)
MAX_RECVBUF_SZ + RECVBUFF_ALIGN_SZ,
GFP_KERNEL);
if (pskb) {
+   kmemleak_not_leak(pskb);
pskb->dev = padapter->pnetdev;
tmpaddr = (size_t)pskb->data;
alignm = tmpaddr & (RECVBUFF_ALIGN_SZ-1);
-- 
2.1.4

Re: [PATCH][RT] netpoll: Always take poll_lock when doing polling

[Alison Chaiken]

Steven Rostedt suggests in reference to "[PATCH][RT] netpoll: Always
take poll_lock when doing polling"
>> [ Alison, can you try this patch ]

Sebastian follows up:
>Alison, did you try it?

Sorry for not responding sooner.   I was hoping to come to a complete
understanding of the system before replying . . .

I did try that patch, but it hasn't made much difference.   Let me
back up and restate the problem I'm trying to solve, which is that a
DRA7X OMAP5 SOC system running a patched 4.1.18-ti-rt kernel has a
main event loop in user space that misses latency deadlines under the
test condition where I ping-flood it from another box.   While in
production, the system would not be expected to support high rates of
network traffic, but the instability with the ping-flood makes me
wonder if there aren't underlying configuration problems.

We've applied Sebastian's commit "softirq: split timer softirqs out of
ksoftirqd," which improved event loop stability substantially when we
left ksoftirqd running at userspace default but elevated ktimersoftd.
 That made me think that focusing on the softirqs was pertinent.

Subsequently, I've tried "[PATCH][RT] netpoll: Always take poll_lock
when doing polling" (which seems like a good idea in any event).
After reading the "net: threadable napi poll loop discussion"
(https://lkml.org/lkml/2016/5/10/472), and
https://lkml.org/lkml/2016/2/27/152, I tried reverting

commit c10d73671ad30f54692f7f69f0e09e75d3a8926a
   Author: Eric Dumazet 
   Date:   Thu Jan 10 15:26:34 2013 -0800
   softirq: reduce latencies

but that didn't help.   When the userspace application (running at -3
priority) starts having problems, I see that the hard IRQ associated
with the ethernet device uses about 35% of one core, which seems
awfully high if the NAPI has triggered a switch to polling.  I vaguely
recall David Miller saying in the "threadable napi poll loop"
discussion that accounting was broken for net IRQs, so perhaps that
number is misleading.   mpstat shows that the NET_RX softirqs run on
the same core where we've pinned the ethernet IRQ, so you might hope
that userspace might be able to run happily on the other one.

What I see in ftrace while watching scheduler and IRQ events is that
the userspace application is yielding to ethernet or CAN IRQs, which
also raise NET_RX.In the following,  ping-flood is running, and
irq/343 is the ethernet one:

 userspace_application-4767  [000] dn.h1..  4196.422318:
irq_handler_entry: irq=347 name=can1
 userspace_application-4767  [000] dn.h1..  4196.422319:
irq_handler_exit: irq=347 ret=handled
 userspace_application-4767  [000] dn.h2..  4196.422321: sched_waking:
comm=irq/347-can1 pid=2053 prio=28 target_cpu=000
 irq/343-4848400-874   [001] 112  4196.422323: softirq_entry:
vec=3 [action=NET_RX]
 userspace_application-4767  [000] dn.h3..  4196.422325: sched_wakeup:
comm=irq/347-can1 pid=2053 prio=28 target_cpu=000
 irq/343-4848400-874   [001] 112  4196.422328: napi_poll: napi
poll on napi struct edd5f560 for device eth0
 irq/343-4848400-874   [001] 112  4196.422329: softirq_exit: vec=3
[action=NET_RX]
 userspace_application-4767  [000] dn..3..  4196.422332:
sched_stat_runtime: comm=userspace_application pid=4767 runtime=22448
[ns] vruntime=338486919642 [ns]
 userspace_application-4767  [000] d...3..  4196.422336: sched_switch:
prev_comm=userspace_application prev_pid=4767 prev_prio=120
prev_state=R ==> next_comm=irq/347-can1 next_pid=2053 next_prio=28
 irq/343-4848400-874   [001] d...3..  4196.422339: sched_switch:
prev_comm=irq/343-4848400 prev_pid=874 prev_prio=47 prev_state=S ==>
next_comm=irq/344-4848400 next_pid=875 next_prio=47

You can see why the application is having problems: it is constantly
interrupted by eth and CAN IRQs.   Given that CAN traffic is critical
for our application, perhaps we will simply have to reduce the eth
hard IRQ priority in order to make the system more robust? It
would be great to offload the network traffic-handling to the Cortex-M
processor on the DRA7, but I fear that the development schedule will
not allow for that option.

I still am not sure how to tell if the NAPI switch from
interrupt-driven to polling is properly taking place.  Any
suggestion on how best to monitor that behavior with overly loading
the system would be appreciated.

Thanks again for the patches,
Alison Chaiken
Peloton Technology

Re: [PATCH 09/12] net: mediatek: increase watchdog_timeo

[Andrew Lunn]

On Sun, Jun 05, 2016 at 08:33:02AM +0200, John Crispin wrote:
> During stress testing, after reducing the threshold value, we have seen
> TX timeouts that were caused by the watchdog_timeo value being too low.
> Increase the value to 5 * HZ which is a value commonly used by many other
> drivers.

I've never studied what watchdog_timeo actually means. Does it mean a
transmit has not completed in that amount of time? Would this imply
you have 5 seconds worth of packets in your transmit queue? Do you
know what the driver is doing during this 5 seconds?

Thanks
Andrew

[net-next PATCH 1/1] net sched: indentation and other OCD stylistic fixes

[Jamal Hadi Salim]

From: Jamal Hadi Salim 

Signed-off-by: Jamal Hadi Salim 
---
 include/net/act_api.h  | 14 --
 include/net/tc_act/tc_defact.h |  4 ++--
 include/uapi/linux/pkt_cls.h   |  6 +++---
 net/sched/act_api.c| 19 +++
 net/sched/act_bpf.c|  3 ++-
 net/sched/act_gact.c   |  3 ++-
 net/sched/act_ipt.c|  6 --
 net/sched/act_vlan.c   |  3 ++-
 net/sched/cls_api.c| 11 +++
 9 files changed, 41 insertions(+), 28 deletions(-)

diff --git a/include/net/act_api.h b/include/net/act_api.h
index 5453f52..b39f5aa 100644
--- a/include/net/act_api.h
+++ b/include/net/act_api.h
@@ -2,8 +2,8 @@
 #define __NET_ACT_API_H
 
 /*
- * Public police action API for classifiers/qdiscs
- */
+ * Public action API for classifiers/qdiscs
+*/
 
 #include 
 #include 
@@ -107,7 +107,8 @@ struct tc_action_ops {
charkind[IFNAMSIZ];
__u32   type; /* TBD to match kind */
struct module   *owner;
-   int (*act)(struct sk_buff *, const struct tc_action *, struct 
tcf_result *);
+   int (*act)(struct sk_buff *, const struct tc_action *,
+  struct tcf_result *);
int (*dump)(struct sk_buff *, struct tc_action *, int, int);
void(*cleanup)(struct tc_action *, int bind);
int (*lookup)(struct net *, struct tc_action *, u32);
@@ -125,8 +126,8 @@ struct tc_action_net {
 };
 
 static inline
-int tc_action_net_init(struct tc_action_net *tn, const struct tc_action_ops 
*ops,
-  unsigned int mask)
+int tc_action_net_init(struct tc_action_net *tn,
+  const struct tc_action_ops *ops, unsigned int mask)
 {
int err = 0;
 
@@ -169,7 +170,8 @@ static inline int tcf_hash_release(struct tc_action *a, 
bool bind)
 }
 
 int tcf_register_action(struct tc_action_ops *a, struct pernet_operations 
*ops);
-int tcf_unregister_action(struct tc_action_ops *a, struct pernet_operations 
*ops);
+int tcf_unregister_action(struct tc_action_ops *a,
+ struct pernet_operations *ops);
 int tcf_action_destroy(struct list_head *actions, int bind);
 int tcf_action_exec(struct sk_buff *skb, const struct list_head *actions,
struct tcf_result *res);
diff --git a/include/net/tc_act/tc_defact.h b/include/net/tc_act/tc_defact.h
index 9763dcb..ab9b5d6 100644
--- a/include/net/tc_act/tc_defact.h
+++ b/include/net/tc_act/tc_defact.h
@@ -5,8 +5,8 @@
 
 struct tcf_defact {
struct tcf_common   common;
-   u32 tcfd_datalen;
-   void*tcfd_defdata;
+   u32 tcfd_datalen;
+   void*tcfd_defdata;
 };
 #define to_defact(a) \
container_of(a->priv, struct tcf_defact, common)
diff --git a/include/uapi/linux/pkt_cls.h b/include/uapi/linux/pkt_cls.h
index 9ba1410..5702e93 100644
--- a/include/uapi/linux/pkt_cls.h
+++ b/include/uapi/linux/pkt_cls.h
@@ -115,8 +115,8 @@ struct tc_police {
__u32   mtu;
struct tc_ratespec  rate;
struct tc_ratespec  peakrate;
-   int refcnt;
-   int bindcnt;
+   int refcnt;
+   int bindcnt;
__u32   capab;
 };
 
@@ -128,7 +128,7 @@ struct tcf_t {
 };
 
 struct tc_cnt {
-   int   refcnt; 
+   int   refcnt;
int   bindcnt;
 };
 
diff --git a/net/sched/act_api.c b/net/sched/act_api.c
index 5ebf6d6..719bc2e 100644
--- a/net/sched/act_api.c
+++ b/net/sched/act_api.c
@@ -504,8 +504,8 @@ nla_put_failure:
 }
 EXPORT_SYMBOL(tcf_action_dump_1);
 
-int
-tcf_action_dump(struct sk_buff *skb, struct list_head *actions, int bind, int 
ref)
+int tcf_action_dump(struct sk_buff *skb, struct list_head *actions,
+   int bind, int ref)
 {
struct tc_action *a;
int err = -EINVAL;
@@ -688,9 +688,9 @@ errout:
return -1;
 }
 
-static int
-tca_get_fill(struct sk_buff *skb, struct list_head *actions, u32 portid, u32 
seq,
-u16 flags, int event, int bind, int ref)
+static int tca_get_fill(struct sk_buff *skb, struct list_head *actions,
+   u32 portid, u32 seq, u16 flags, int event, int bind,
+   int ref)
 {
struct tcamsg *t;
struct nlmsghdr *nlh;
@@ -731,7 +731,8 @@ act_get_notify(struct net *net, u32 portid, struct nlmsghdr 
*n,
skb = alloc_skb(NLMSG_GOODSIZE, GFP_KERNEL);
if (!skb)
return -ENOBUFS;
-   if (tca_get_fill(skb, actions, portid, n->nlmsg_seq, 0, event, 0, 0) <= 
0) {
+   if (tca_get_fill(skb, actions, portid, n->nlmsg_seq, 0, event,
+0, 0) <= 0) {
kfree_skb(skb);
return -EINVAL;
}
@@ -839,7 +840,8 @@ static int 

[net-next PATCH 0/3] net sched action timestamp improvements

[Jamal Hadi Salim]

From: Jamal Hadi Salim 

Various aggregations of duplicated code, fixes and introduction of firstused
timestamp

Jamal Hadi Salim (3):
  net sched: actions use tcf_lastuse_update for consistency
  net sched actions: introduce timestamp for firsttime use
  net sched actions: aggregate dumping of actions timeinfo

 include/net/act_api.h| 10 ++
 include/uapi/linux/pkt_cls.h |  1 +
 net/sched/act_api.c  |  1 +
 net/sched/act_bpf.c  |  5 +
 net/sched/act_connmark.c |  6 ++
 net/sched/act_csum.c |  7 +++
 net/sched/act_gact.c |  4 +---
 net/sched/act_ife.c  | 10 --
 net/sched/act_ipt.c  |  8 
 net/sched/act_mirred.c   |  6 ++
 net/sched/act_nat.c  |  7 +++
 net/sched/act_pedit.c|  8 
 net/sched/act_police.c   |  2 ++
 net/sched/act_simple.c   |  7 +++
 net/sched/act_skbedit.c  |  7 +++
 net/sched/act_vlan.c |  6 ++
 16 files changed, 46 insertions(+), 49 deletions(-)

-- 
1.9.1

[net-next PATCH 1/3] net sched: actions use tcf_lastuse_update for consistency

[Jamal Hadi Salim]

From: Jamal Hadi Salim 

Signed-off-by: Jamal Hadi Salim 
---
 net/sched/act_connmark.c | 2 +-
 net/sched/act_csum.c | 2 +-
 net/sched/act_ife.c  | 6 +++---
 net/sched/act_ipt.c  | 2 +-
 net/sched/act_mirred.c   | 1 -
 net/sched/act_nat.c  | 2 +-
 net/sched/act_pedit.c| 2 +-
 net/sched/act_simple.c   | 2 +-
 net/sched/act_skbedit.c  | 2 +-
 net/sched/act_vlan.c | 2 +-
 10 files changed, 11 insertions(+), 12 deletions(-)

diff --git a/net/sched/act_connmark.c b/net/sched/act_connmark.c
index 2ba700c..e0e6c68 100644
--- a/net/sched/act_connmark.c
+++ b/net/sched/act_connmark.c
@@ -44,7 +44,7 @@ static int tcf_connmark(struct sk_buff *skb, const struct 
tc_action *a,
int proto;
 
spin_lock(>tcf_lock);
-   ca->tcf_tm.lastuse = jiffies;
+   tcf_lastuse_update(>tcf_tm);
bstats_update(>tcf_bstats, skb);
 
if (skb->protocol == htons(ETH_P_IP)) {
diff --git a/net/sched/act_csum.c b/net/sched/act_csum.c
index 28e934e..065f716 100644
--- a/net/sched/act_csum.c
+++ b/net/sched/act_csum.c
@@ -501,7 +501,7 @@ static int tcf_csum(struct sk_buff *skb,
u32 update_flags;
 
spin_lock(>tcf_lock);
-   p->tcf_tm.lastuse = jiffies;
+   tcf_lastuse_update(>tcf_tm);
bstats_update(>tcf_bstats, skb);
action = p->tcf_action;
update_flags = p->update_flags;
diff --git a/net/sched/act_ife.c b/net/sched/act_ife.c
index 658046d..6491576 100644
--- a/net/sched/act_ife.c
+++ b/net/sched/act_ife.c
@@ -623,7 +623,7 @@ static int tcf_ife_decode(struct sk_buff *skb, const struct 
tc_action *a,
 
spin_lock(>tcf_lock);
bstats_update(>tcf_bstats, skb);
-   ife->tcf_tm.lastuse = jiffies;
+   tcf_lastuse_update(>tcf_tm);
spin_unlock(>tcf_lock);
 
ifehdrln = ntohs(ifehdrln);
@@ -711,7 +711,7 @@ static int tcf_ife_encode(struct sk_buff *skb, const struct 
tc_action *a,
 
spin_lock(>tcf_lock);
bstats_update(>tcf_bstats, skb);
-   ife->tcf_tm.lastuse = jiffies;
+   tcf_lastuse_update(>tcf_tm);
 
if (!metalen) { /* no metadata to send */
/* abuse overlimits to count when we allow packet
@@ -802,7 +802,7 @@ static int tcf_ife_act(struct sk_buff *skb, const struct 
tc_action *a,
pr_info_ratelimited("unknown failure(policy neither de/encode\n");
spin_lock(>tcf_lock);
bstats_update(>tcf_bstats, skb);
-   ife->tcf_tm.lastuse = jiffies;
+   tcf_lastuse_update(>tcf_tm);
ife->tcf_qstats.drops++;
spin_unlock(>tcf_lock);
 
diff --git a/net/sched/act_ipt.c b/net/sched/act_ipt.c
index 9f002ad..30e9087 100644
--- a/net/sched/act_ipt.c
+++ b/net/sched/act_ipt.c
@@ -212,7 +212,7 @@ static int tcf_ipt(struct sk_buff *skb, const struct 
tc_action *a,
 
spin_lock(>tcf_lock);
 
-   ipt->tcf_tm.lastuse = jiffies;
+   tcf_lastuse_update(>tcf_tm);
bstats_update(>tcf_bstats, skb);
 
/* yes, we have to worry about both in and out dev
diff --git a/net/sched/act_mirred.c b/net/sched/act_mirred.c
index 128942b..d3ac73e 100644
--- a/net/sched/act_mirred.c
+++ b/net/sched/act_mirred.c
@@ -157,7 +157,6 @@ static int tcf_mirred(struct sk_buff *skb, const struct 
tc_action *a,
u32 at;
 
tcf_lastuse_update(>tcf_tm);
-
bstats_cpu_update(this_cpu_ptr(m->common.cpu_bstats), skb);
 
rcu_read_lock();
diff --git a/net/sched/act_nat.c b/net/sched/act_nat.c
index c0a879f..9135aa8 100644
--- a/net/sched/act_nat.c
+++ b/net/sched/act_nat.c
@@ -103,7 +103,7 @@ static int tcf_nat(struct sk_buff *skb, const struct 
tc_action *a,
 
spin_lock(>tcf_lock);
 
-   p->tcf_tm.lastuse = jiffies;
+   tcf_lastuse_update(>tcf_tm);
old_addr = p->old_addr;
new_addr = p->new_addr;
mask = p->mask;
diff --git a/net/sched/act_pedit.c b/net/sched/act_pedit.c
index c6e18f2..67a1726 100644
--- a/net/sched/act_pedit.c
+++ b/net/sched/act_pedit.c
@@ -121,7 +121,7 @@ static int tcf_pedit(struct sk_buff *skb, const struct 
tc_action *a,
 
spin_lock(>tcf_lock);
 
-   p->tcf_tm.lastuse = jiffies;
+   tcf_lastuse_update(>tcf_tm);
 
if (p->tcfp_nkeys > 0) {
struct tc_pedit_key *tkey = p->tcfp_keys;
diff --git a/net/sched/act_simple.c b/net/sched/act_simple.c
index e42f8da..f95d1c5 100644
--- a/net/sched/act_simple.c
+++ b/net/sched/act_simple.c
@@ -35,7 +35,7 @@ static int tcf_simp(struct sk_buff *skb, const struct 
tc_action *a,
struct tcf_defact *d = a->priv;
 
spin_lock(>tcf_lock);
-   d->tcf_tm.lastuse = jiffies;
+   tcf_lastuse_update(>tcf_tm);
bstats_update(>tcf_bstats, skb);
 
/* print policy string followed by _ then packet count
diff --git a/net/sched/act_skbedit.c b/net/sched/act_skbedit.c
index e928802..82105c8 100644
--- a/net/sched/act_skbedit.c
+++ b/net/sched/act_skbedit.c
@@ -37,7 +37,7 @@ static int tcf_skbedit(struct sk_buff *skb, const 

[net-next PATCH 3/3] net sched actions: aggregate dumping of actions timeinfo

[Jamal Hadi Salim]

From: Jamal Hadi Salim 

Signed-off-by: Jamal Hadi Salim 
---
 include/net/act_api.h| 8 
 net/sched/act_bpf.c  | 6 +-
 net/sched/act_connmark.c | 5 +
 net/sched/act_csum.c | 6 ++
 net/sched/act_gact.c | 5 +
 net/sched/act_ife.c  | 4 +---
 net/sched/act_ipt.c  | 7 +++
 net/sched/act_mirred.c   | 6 ++
 net/sched/act_nat.c  | 6 ++
 net/sched/act_pedit.c| 7 +++
 net/sched/act_simple.c   | 6 ++
 net/sched/act_skbedit.c  | 6 ++
 net/sched/act_vlan.c | 5 +
 13 files changed, 29 insertions(+), 48 deletions(-)

diff --git a/include/net/act_api.h b/include/net/act_api.h
index 8389c00..5453f52 100644
--- a/include/net/act_api.h
+++ b/include/net/act_api.h
@@ -80,6 +80,14 @@ static inline void tcf_lastuse_update(struct tcf_t *tm)
tm->firstuse = now;
 }
 
+static inline void tcf_tm_dump(struct tcf_t *dtm, struct tcf_t *stm)
+{
+   dtm->install = jiffies_to_clock_t(jiffies - stm->install);
+   dtm->lastuse = jiffies_to_clock_t(jiffies - stm->lastuse);
+   dtm->firstuse = jiffies_to_clock_t(jiffies - stm->firstuse);
+   dtm->expires = jiffies_to_clock_t(stm->expires);
+}
+
 struct tc_action {
void*priv;
const struct tc_action_ops  *ops;
diff --git a/net/sched/act_bpf.c b/net/sched/act_bpf.c
index e4b877f..ae0e7cb 100644
--- a/net/sched/act_bpf.c
+++ b/net/sched/act_bpf.c
@@ -154,11 +154,7 @@ static int tcf_bpf_dump(struct sk_buff *skb, struct 
tc_action *act,
if (ret)
goto nla_put_failure;
 
-   tm.install = jiffies_to_clock_t(jiffies - prog->tcf_tm.install);
-   tm.lastuse = jiffies_to_clock_t(jiffies - prog->tcf_tm.lastuse);
-   tm.firstuse = jiffies_to_clock_t(jiffies - prog->tcf_tm.firstuse);
-   tm.expires = jiffies_to_clock_t(prog->tcf_tm.expires);
-
+   tcf_tm_dump(, >tcf_tm);
if (nla_put_64bit(skb, TCA_ACT_BPF_TM, sizeof(tm), ,
  TCA_ACT_BPF_PAD))
goto nla_put_failure;
diff --git a/net/sched/act_connmark.c b/net/sched/act_connmark.c
index e3f64f2..35a5270 100644
--- a/net/sched/act_connmark.c
+++ b/net/sched/act_connmark.c
@@ -160,10 +160,7 @@ static inline int tcf_connmark_dump(struct sk_buff *skb, 
struct tc_action *a,
if (nla_put(skb, TCA_CONNMARK_PARMS, sizeof(opt), ))
goto nla_put_failure;
 
-   t.install = jiffies_to_clock_t(jiffies - ci->tcf_tm.install);
-   t.lastuse = jiffies_to_clock_t(jiffies - ci->tcf_tm.lastuse);
-   t.expires = jiffies_to_clock_t(ci->tcf_tm.expires);
-   t.firstuse = jiffies_to_clock_t(jiffies - ci->tcf_tm.firstuse);
+   tcf_tm_dump(, >tcf_tm);
if (nla_put_64bit(skb, TCA_CONNMARK_TM, sizeof(t), ,
  TCA_CONNMARK_PAD))
goto nla_put_failure;
diff --git a/net/sched/act_csum.c b/net/sched/act_csum.c
index 7725eafb..dcd9aba 100644
--- a/net/sched/act_csum.c
+++ b/net/sched/act_csum.c
@@ -546,10 +546,8 @@ static int tcf_csum_dump(struct sk_buff *skb,
 
if (nla_put(skb, TCA_CSUM_PARMS, sizeof(opt), ))
goto nla_put_failure;
-   t.install = jiffies_to_clock_t(jiffies - p->tcf_tm.install);
-   t.lastuse = jiffies_to_clock_t(jiffies - p->tcf_tm.lastuse);
-   t.firstuse = jiffies_to_clock_t(jiffies - p->tcf_tm.firstuse);
-   t.expires = jiffies_to_clock_t(p->tcf_tm.expires);
+
+   tcf_tm_dump(, >tcf_tm);
if (nla_put_64bit(skb, TCA_CSUM_TM, sizeof(t), , TCA_CSUM_PAD))
goto nla_put_failure;
 
diff --git a/net/sched/act_gact.c b/net/sched/act_gact.c
index c9d59f3..4c6e008 100644
--- a/net/sched/act_gact.c
+++ b/net/sched/act_gact.c
@@ -188,10 +188,7 @@ static int tcf_gact_dump(struct sk_buff *skb, struct 
tc_action *a, int bind, int
goto nla_put_failure;
}
 #endif
-   t.install = jiffies_to_clock_t(jiffies - gact->tcf_tm.install);
-   t.lastuse = jiffies_to_clock_t(jiffies - gact->tcf_tm.lastuse);
-   t.firstuse = jiffies_to_clock_t(jiffies - gact->tcf_tm.firstuse);
-   t.expires = jiffies_to_clock_t(gact->tcf_tm.expires);
+   tcf_tm_dump(, >tcf_tm);
if (nla_put_64bit(skb, TCA_GACT_TM, sizeof(t), , TCA_GACT_PAD))
goto nla_put_failure;
return skb->len;
diff --git a/net/sched/act_ife.c b/net/sched/act_ife.c
index 6491576..02f5a8b 100644
--- a/net/sched/act_ife.c
+++ b/net/sched/act_ife.c
@@ -553,9 +553,7 @@ static int tcf_ife_dump(struct sk_buff *skb, struct 
tc_action *a, int bind,
if (nla_put(skb, TCA_IFE_PARMS, sizeof(opt), ))
goto nla_put_failure;
 
-   t.install = jiffies_to_clock_t(jiffies - ife->tcf_tm.install);
-   t.lastuse = jiffies_to_clock_t(jiffies - ife->tcf_tm.lastuse);
-   t.expires = jiffies_to_clock_t(ife->tcf_tm.expires);
+   tcf_tm_dump(, >tcf_tm);
if (nla_put_64bit(skb, TCA_IFE_TM, sizeof(t), , TCA_IFE_PAD))

[net-next PATCH 2/3] net sched actions: introduce timestamp for firsttime use

[Jamal Hadi Salim]

From: Jamal Hadi Salim 

Useful to know when the action was first used for accounting
(and debugging)

Signed-off-by: Jamal Hadi Salim 
---
 include/net/act_api.h| 2 ++
 include/uapi/linux/pkt_cls.h | 1 +
 net/sched/act_api.c  | 1 +
 net/sched/act_bpf.c  | 1 +
 net/sched/act_connmark.c | 1 +
 net/sched/act_csum.c | 1 +
 net/sched/act_gact.c | 1 +
 net/sched/act_ipt.c  | 1 +
 net/sched/act_mirred.c   | 1 +
 net/sched/act_nat.c  | 1 +
 net/sched/act_pedit.c| 1 +
 net/sched/act_police.c   | 2 ++
 net/sched/act_simple.c   | 1 +
 net/sched/act_skbedit.c  | 1 +
 net/sched/act_vlan.c | 1 +
 15 files changed, 17 insertions(+)

diff --git a/include/net/act_api.h b/include/net/act_api.h
index 9a9a8ed..8389c00 100644
--- a/include/net/act_api.h
+++ b/include/net/act_api.h
@@ -76,6 +76,8 @@ static inline void tcf_lastuse_update(struct tcf_t *tm)
 
if (tm->lastuse != now)
tm->lastuse = now;
+   if (unlikely(!tm->firstuse))
+   tm->firstuse = now;
 }
 
 struct tc_action {
diff --git a/include/uapi/linux/pkt_cls.h b/include/uapi/linux/pkt_cls.h
index f4297c8..9ba1410 100644
--- a/include/uapi/linux/pkt_cls.h
+++ b/include/uapi/linux/pkt_cls.h
@@ -124,6 +124,7 @@ struct tcf_t {
__u64   install;
__u64   lastuse;
__u64   expires;
+   __u64   firstuse;
 };
 
 struct tc_cnt {
diff --git a/net/sched/act_api.c b/net/sched/act_api.c
index 336774a..5ebf6d6 100644
--- a/net/sched/act_api.c
+++ b/net/sched/act_api.c
@@ -283,6 +283,7 @@ err2:
p->tcfc_index = index ? index : tcf_hash_new_index(tn);
p->tcfc_tm.install = jiffies;
p->tcfc_tm.lastuse = jiffies;
+   p->tcfc_tm.firstuse = 0;
if (est) {
err = gen_new_estimator(>tcfc_bstats, p->cpu_bstats,
>tcfc_rate_est,
diff --git a/net/sched/act_bpf.c b/net/sched/act_bpf.c
index c7123e0..e4b877f 100644
--- a/net/sched/act_bpf.c
+++ b/net/sched/act_bpf.c
@@ -156,6 +156,7 @@ static int tcf_bpf_dump(struct sk_buff *skb, struct 
tc_action *act,
 
tm.install = jiffies_to_clock_t(jiffies - prog->tcf_tm.install);
tm.lastuse = jiffies_to_clock_t(jiffies - prog->tcf_tm.lastuse);
+   tm.firstuse = jiffies_to_clock_t(jiffies - prog->tcf_tm.firstuse);
tm.expires = jiffies_to_clock_t(prog->tcf_tm.expires);
 
if (nla_put_64bit(skb, TCA_ACT_BPF_TM, sizeof(tm), ,
diff --git a/net/sched/act_connmark.c b/net/sched/act_connmark.c
index e0e6c68..e3f64f2 100644
--- a/net/sched/act_connmark.c
+++ b/net/sched/act_connmark.c
@@ -163,6 +163,7 @@ static inline int tcf_connmark_dump(struct sk_buff *skb, 
struct tc_action *a,
t.install = jiffies_to_clock_t(jiffies - ci->tcf_tm.install);
t.lastuse = jiffies_to_clock_t(jiffies - ci->tcf_tm.lastuse);
t.expires = jiffies_to_clock_t(ci->tcf_tm.expires);
+   t.firstuse = jiffies_to_clock_t(jiffies - ci->tcf_tm.firstuse);
if (nla_put_64bit(skb, TCA_CONNMARK_TM, sizeof(t), ,
  TCA_CONNMARK_PAD))
goto nla_put_failure;
diff --git a/net/sched/act_csum.c b/net/sched/act_csum.c
index 065f716..7725eafb 100644
--- a/net/sched/act_csum.c
+++ b/net/sched/act_csum.c
@@ -548,6 +548,7 @@ static int tcf_csum_dump(struct sk_buff *skb,
goto nla_put_failure;
t.install = jiffies_to_clock_t(jiffies - p->tcf_tm.install);
t.lastuse = jiffies_to_clock_t(jiffies - p->tcf_tm.lastuse);
+   t.firstuse = jiffies_to_clock_t(jiffies - p->tcf_tm.firstuse);
t.expires = jiffies_to_clock_t(p->tcf_tm.expires);
if (nla_put_64bit(skb, TCA_CSUM_TM, sizeof(t), , TCA_CSUM_PAD))
goto nla_put_failure;
diff --git a/net/sched/act_gact.c b/net/sched/act_gact.c
index ec5cc84..c9d59f3 100644
--- a/net/sched/act_gact.c
+++ b/net/sched/act_gact.c
@@ -190,6 +190,7 @@ static int tcf_gact_dump(struct sk_buff *skb, struct 
tc_action *a, int bind, int
 #endif
t.install = jiffies_to_clock_t(jiffies - gact->tcf_tm.install);
t.lastuse = jiffies_to_clock_t(jiffies - gact->tcf_tm.lastuse);
+   t.firstuse = jiffies_to_clock_t(jiffies - gact->tcf_tm.firstuse);
t.expires = jiffies_to_clock_t(gact->tcf_tm.expires);
if (nla_put_64bit(skb, TCA_GACT_TM, sizeof(t), , TCA_GACT_PAD))
goto nla_put_failure;
diff --git a/net/sched/act_ipt.c b/net/sched/act_ipt.c
index 30e9087..47525ee 100644
--- a/net/sched/act_ipt.c
+++ b/net/sched/act_ipt.c
@@ -279,6 +279,7 @@ static int tcf_ipt_dump(struct sk_buff *skb, struct 
tc_action *a, int bind, int
goto nla_put_failure;
tm.install = jiffies_to_clock_t(jiffies - ipt->tcf_tm.install);
tm.lastuse = jiffies_to_clock_t(jiffies - ipt->tcf_tm.lastuse);
+   tm.firstuse = jiffies_to_clock_t(jiffies - ipt->tcf_tm.firstuse);
tm.expires = 

[PATCH net-next] net/sched: cls_flower: Introduce support in SKIP SW flag

[Amir Vadai]

From: Amir Vadai 

In order to make a filter processed only by hardware, skip_sw flag
should be supplied. This is an addition to the already existing skip_hw
flag (filter will be processed by software only). If no flag is
specified, filter will be processed by both software and hardware.

If only hardware offloaded filters exist, fl_classify() will return
without doing anything.

A following userspace patch will be sent once kernel patch is accepted.

Example:

tc filter add dev enp0s9 protocol ip prio 20 parent : \
flower \
ip_proto 6 \
indev enp0s9 \
skip_sw \
action skbedit mark 0x1234

Signed-off-by: Amir Vadai 
---
 net/sched/cls_flower.c | 31 ++-
 1 file changed, 22 insertions(+), 9 deletions(-)

diff --git a/net/sched/cls_flower.c b/net/sched/cls_flower.c
index 730aaca..d737492 100644
--- a/net/sched/cls_flower.c
+++ b/net/sched/cls_flower.c
@@ -66,6 +66,7 @@ struct cls_fl_filter {
struct fl_flow_key key;
struct list_head list;
u32 handle;
+   u32 flags;
struct rcu_head rcu;
 };
 
@@ -123,6 +124,9 @@ static int fl_classify(struct sk_buff *skb, const struct 
tcf_proto *tp,
struct fl_flow_key skb_key;
struct fl_flow_key skb_mkey;
 
+   if (!atomic_read(>ht.nelems))
+   return -1;
+
fl_clear_masked_range(_key, >mask);
skb_key.indev_ifindex = skb->skb_iif;
/* skb_flow_dissect() does not set n_proto in case an unknown protocol,
@@ -136,7 +140,7 @@ static int fl_classify(struct sk_buff *skb, const struct 
tcf_proto *tp,
f = rhashtable_lookup_fast(>ht,
   fl_key_get_start(_mkey, >mask),
   head->ht_params);
-   if (f) {
+   if (f && !(f->flags & TCA_CLS_FLAGS_SKIP_SW)) {
*res = f->res;
return tcf_exts_exec(skb, >exts, res);
}
@@ -524,7 +528,6 @@ static int fl_change(struct net *net, struct sk_buff 
*in_skb,
struct cls_fl_filter *fnew;
struct nlattr *tb[TCA_FLOWER_MAX + 1];
struct fl_flow_mask mask = {};
-   u32 flags = 0;
int err;
 
if (!tca[TCA_OPTIONS])
@@ -552,8 +555,14 @@ static int fl_change(struct net *net, struct sk_buff 
*in_skb,
}
fnew->handle = handle;
 
-   if (tb[TCA_FLOWER_FLAGS])
-   flags = nla_get_u32(tb[TCA_FLOWER_FLAGS]);
+   if (tb[TCA_FLOWER_FLAGS]) {
+   fnew->flags = nla_get_u32(tb[TCA_FLOWER_FLAGS]);
+
+   if (!tc_flags_valid(fnew->flags)) {
+   err = -EINVAL;
+   goto errout;
+   }
+   }
 
err = fl_set_parms(net, tp, fnew, , base, tb, tca[TCA_RATE], ovr);
if (err)
@@ -563,10 +572,12 @@ static int fl_change(struct net *net, struct sk_buff 
*in_skb,
if (err)
goto errout;
 
-   err = rhashtable_insert_fast(>ht, >ht_node,
-head->ht_params);
-   if (err)
-   goto errout;
+   if (!(fnew->flags & TCA_CLS_FLAGS_SKIP_SW)) {
+   err = rhashtable_insert_fast(>ht, >ht_node,
+head->ht_params);
+   if (err)
+   goto errout;
+   }
 
fl_hw_replace_filter(tp,
 >dissector,
@@ -574,7 +585,7 @@ static int fl_change(struct net *net, struct sk_buff 
*in_skb,
 >key,
 >exts,
 (unsigned long)fnew,
-flags);
+fnew->flags);
 
if (fold) {
rhashtable_remove_fast(>ht, >ht_node,
@@ -734,6 +745,8 @@ static int fl_dump(struct net *net, struct tcf_proto *tp, 
unsigned long fh,
  sizeof(key->tp.dst
goto nla_put_failure;
 
+   nla_put_u32(skb, TCA_FLOWER_FLAGS, f->flags);
+
if (tcf_exts_dump(skb, >exts))
goto nla_put_failure;
 
-- 
2.8.3

Re: [PATCH v2] ethernet:arc: Fix racing of TX ring buffer

[Shuyu Wei]

On Mon, May 30, 2016 at 11:41:22PM +0200, Lino Sanfilippo wrote:
> 
> Did you see the same issues with the patch before (the one that, as you wrote,
> survived a whole night of stress testing)?
> 
> Lino

Hi Lino,
Sorry for my late reply. I retested the previous patch, it did have
the same issue. However it seems that the possibility of stuck is lower
(just my instinct, no evidence).

RE: [RFC net-next 1/1] ethtool: Add support for set eeprom metadata.

[Yuval Mintz]

> > > Currently ethtool implementation does not have a way to pass the
> > > metadata for eeprom related operations. Some adapters have a
> > > complicated non-volatile memory implementation that requires
> > > additional information – there are drivers [bnx2x and bnxt] that use
> > > the ‘magic’ field in the {G,S}EEPROM  for that purpose, although that’s 
> > > not
> its intended usage.
> > >
> > > This patch adds a provision to pass the eeprom metadata for
> > > %ETHTOOL_SEEPROM/%ETHTOOL_GEEPROM implementations. User
> provided
> > > metadata will be cached by the driver and assigns a magic value
> > > which the application need to use for the subsequent {G,S}EEPROM
> command.
> >
> > Hi Dave,
> >
> > This got no comments at all.
> > What do you want us to with it next? Should we re-send it as a patch?
> 
> Here's a comment: I really dislike this.
:-)

> - It doesn't specify any semantics for the 'metadata'.  The comment hints that
> they are driver-specific identifiers for different NVRAM partitions.
Not exactly, but close [in our use case there are 2 'methods' of accessing the
flash - either according to addresses or logical 'files'].

> - It doesn't provide a way for userland to enumerate the valid metadata 
> values.
I agree; I can't think of any good way of enumerating device-specific values.

> - It's not clear whether the driver is supposed to maintain just one
> metadata:magic mapping, or more than that.
Theoretically, I guess it could maintain multiple, but that wasn't the 
intention.
One should do.

> Is the ethtool API really the right interface for access to flash?  The sfc 
> driver
> exposes a large number of flash partitions using MTD instead.  These can be
> enumerated (through /proc/mtd or sysfs) and they can be read and written
> through block devices.

I think the better question then is 'what's the purpose of this ethtool API at 
all'?
I agree we can go and do everything via MTD; The reason we've tried using this
API was mainly... because it was there. And thus we thought this is the RIGHT
method for providing users the way of reading their flash.

I don't think that 'how complicated it is to read from the device's flash' 
should
be the determining factor on whether to use this API or not [nor should 'have
we managed to go under the rader' as is the case for bnx2x & bnxt]. 

I think it's a bit odd that our network drivers are offering a dedicated API
for reading flash when we have perfectly reasonable infrastructure [MTD] that
allows exposing them as their own devices.
But I think we need to either decide that this API is deprecated, or else find
some way to extend it to support slightly more complicated use cases.

[Not claiming this RFC is the best possible avenue; But I think we first need
to make a decision whether it's even worth the effort of trying to revise parts
of it]

Thanks,
Yuval

Re: [PATCH v2] soreuseport: add compat case for setsockopt SO_ATTACH_REUSEPORT_CBPF

[Willem de Bruijn]

> Acked-by: Daniel Borkmann 
>
> [ Cc Willem: I believe we also need something similar for PACKET_FANOUT_DATA
>   when PACKET_FANOUT_CBPF is requested since we have the same issue with the
>   pointer in struct sock_fprog there, too. ]

Indeed. I'll send a patch in a few days (am traveling). Thanks for the
heads-up, Daniel.

(apologies if you also received an html version of this reply)

[iproute2 resend PATCH 1/1] man: tc-ife.8: man page for ife action

[Jamal Hadi Salim]

From: Lucas Bates 

Signed-off-by: Lucas Bates 
Signed-off-by: Jamal Hadi Salim 
Acked-by: Phil Sutter 
---
 man/man8/tc-ife.8 | 117 ++
 1 file changed, 117 insertions(+)
 create mode 100644 man/man8/tc-ife.8

diff --git a/man/man8/tc-ife.8 b/man/man8/tc-ife.8
new file mode 100644
index 000..7b3601e
--- /dev/null
+++ b/man/man8/tc-ife.8
@@ -0,0 +1,117 @@
+.TH "IFE action in tc" 8 "22 Apr 2016" "iproute2" "Linux"
+
+.SH NAME
+IFE - encapsulate/decapsulate metadata
+.SH SYNOPSIS
+.in +8
+.ti -8
+.BR tc " ... " action ife"
+.I DIRECTION ACTION
+.RB "[ " dst
+.IR DMAC " ] "
+.RB "[ " src
+.IR SMAC " ] "
+.RB "[ " type
+.IR TYPE " ] "
+.R "[ "
+.IR CONTROL " ] "
+.RB "[ " index
+.IR INDEX " ] "
+
+.ti -8
+.IR DIRECTION " := { "
+.BR decode " | " encode " }"
+
+.ti -8
+.IR ACTION " := { "
+.BR allow " | " use " }"
+
+.ti -8
+.IR CONTROL " := { "
+.BR reclassify " | " use " | " pipe " | " drop " | " continue " | " ok " }"
+.SH DESCRIPTION
+The
+.B ife
+action allows for a sending side to encapsulate arbitrary metadata, which is
+then decapsulated by the receiving end. The sender runs in encoding mode and
+the receiver in decode mode. Both sender and receiver must specify the same
+ethertype. In the future, a registered ethertype may be available as a default.
+.SH OPTIONS
+.TP
+.B decode
+For the receiving side; decode the metadata if the packet matches.
+.TP
+.B encode
+For the sending side. Encode the specified metadata if the packet matches.
+.TP
+.B allow
+Encode direction only. Allows encoding specified metadata.
+.TP
+.B use
+Encode direction only. Enforce static encoding of specified metadata.
+.TP
+.BI dmac " DMAC"
+.TQ
+.BI smac " SMAC"
+Optional six byte destination or source MAC address to encode.
+.TP
+.BI type " TYPE"
+Optional 16-bit ethertype to encode.
+.TP
+.BI CONTROL
+Action to take following an encode/decode.
+.TP
+.BI index " INDEX"
+Assign a unique ID to this action instead of letting the kernel choose one
+automatically.
+.I INDEX
+is a 32bit unsigned integer greater than zero.
+.SH EXAMPLES
+
+On the receiving side, match packets with ethertype 0xdead and restart
+classification so that it will match ICMP on the next rule, at prio 3:
+.RS
+.EX
+# tc qdisc add dev eth0 handle : ingress
+# tc filter add dev eth0 parent : prio 2 protocol 0xdead \\
+   u32 match u32 0 0 flowid 1:1 \\
+   action ife decode reclassify
+# tc filter add dev eth0 parent : priod 3 protocol ip \\
+   u32 match ip protocol 0xff flowid 1:1 \\
+   action continue
+.EE
+.RE
+
+Match with skb mark of 17:
+
+.RS
+.EX
+# tc filter add dev eth0 parent : prio 4 protocol ip \\
+   handle 0x11 fw flowid 1:1 \\
+   action ok
+.EE
+.RE
+
+Configure the sending side to encode for the filters above. Use a destination
+IP address of 192.168.122.237/24, then tag with skb mark of decimal 17. Encode
+the packaet with ethertype 0xdead, add skb->mark to whitelist of metadatum to
+send, and rewrite the destination MAC address to 02:15:15:15:15:15.
+
+.RS
+.EX
+# tc qdisc add dev eth0 root handle 1: prio
+# tc filter add dev eth0 parent 1: protocol ip prio 10 u32 \\
+   match ip dst 192.168.122.237/24 \\
+   match ip protocol 1 0xff \\
+   flowid 1:2 \\
+   action skbedit mark 17 \\
+   action ife encode \\
+   type 0xDEAD \\
+   allow mark \\
+   dst 02:15:15:15:15:15
+.EE
+.RE
+
+.SH SEE ALSO
+.BR tc (8),
+.BR tc-u32 (8)
-- 
1.9.1

Re: [PATCH v2 net] fq_codel: fix NET_XMIT_CN behavior

[Jamal Hadi Salim]

On 16-06-04 03:55 PM, Eric Dumazet wrote:

From: Eric Dumazet 

My prior attempt to fix the backlogs of parents failed.

If we return NET_XMIT_CN, our parents wont increase their backlog,
so our qdisc_tree_reduce_backlog() should take this into account.

v2: Florian Westphal pointed out that we could drop the packet,
so we need to save qdisc_pkt_len(skb) in a temp variable before
calling fq_codel_drop()

Fixes: 9d18562a2278 ("fq_codel: add batch ability to fq_codel_drop()")
Fixes: 2f5fb43f ("net_sched: update hierarchical backlog too")
Reported-by: Stas Nichiporovich 
Signed-off-by: Eric Dumazet 
Cc: WANG Cong 
Cc: Jamal Hadi Salim 


Acked-by: Jamal Hadi Salim 

cheers,
jamal

Re: [PATCH net-next] net, cls: allow for deleting all filters for given parent

[Sergei Shtylyov]

Hello.

On 6/4/2016 7:24 PM, Daniel Borkmann wrote:


Add a possibility where the user can just specify the parent and
all filters under that parent are then being purged. Currently,
for example for scripting, one needs to specify pref/prio to have
a well-defined number for 'tc filter del' command for addressing
the previously created instance or additionally filter handle in
case of priorities being the same. Improve usage by allowing the
option for tc to specify the parent and removing the whole chain
for that given parent.

Example usage after patch, no tc changes required:

  # tc qdisc replace dev foo clsact
  # tc filter add dev foo egress bpf da obj ./bpf.o
  # tc filter add dev foo egress bpf da obj ./bpf.o
  # tc filter show dev foo egress
  filter protocol all pref 49151 bpf
  filter protocol all pref 49151 bpf handle 0x1 bpf.o:[classifier] direct-action
  filter protocol all pref 49152 bpf
  filter protocol all pref 49152 bpf handle 0x1 bpf.o:[classifier] direct-action
  # tc filter del dev foo egress
  # tc filter show dev foo egress
  #

Previously, RTM_DELTFILTER requests with invalid prio of 0 were
rejected, so only netlink requests with RTM_NEWTFILTER and NLM_F_CREATE
flag were allowed where the kernel would auto-generate a pref/prio.
We can piggyback on that and use prio of 0 as a wildcard for
requests of RTM_DELTFILTER.

Signed-off-by: Daniel Borkmann 
---
 net/sched/cls_api.c | 24 
 1 file changed, 20 insertions(+), 4 deletions(-)

diff --git a/net/sched/cls_api.c b/net/sched/cls_api.c
index a75864d..caa1dd4 100644
--- a/net/sched/cls_api.c
+++ b/net/sched/cls_api.c
@@ -156,11 +156,22 @@ replay:
cl = 0;

if (prio == 0) {
-   /* If no priority is given, user wants we allocated it. */
-   if (n->nlmsg_type != RTM_NEWTFILTER ||
-   !(n->nlmsg_flags & NLM_F_CREATE))
+   switch (n->nlmsg_type) {
+   case RTM_DELTFILTER:
+   if (protocol || t->tcm_handle)
+   return -ENOENT;
+   break;
+   case RTM_NEWTFILTER:
+   /* If no priority is provided by the user,
+* we allocate one.
+*/
+   if (n->nlmsg_flags & NLM_F_CREATE) {
+   prio = TC_H_MAKE(0x8000U, 0U);
+   break;
+   }


   Need a comment here, something like /* FALL THRU */.


+   default:
return -ENOENT;
-   prio = TC_H_MAKE(0x8000U, 0U);
+   }
}

/* Find head of filter chain. */

[...]

MBR, Sergei

Re: [RFC net-next 1/1] ethtool: Add support for set eeprom metadata.

[Ben Hutchings]

On Sun, 2016-06-05 at 10:16 +, Yuval Mintz wrote:
> > 
> > Currently ethtool implementation does not have a way to pass the metadata 
> > for
> > eeprom related operations. Some adapters have a complicated non-volatile
> > memory implementation that requires additional information – there are 
> > drivers
> > [bnx2x and bnxt] that use the ‘magic’ field in the {G,S}EEPROM  for that 
> > purpose,
> > although that’s not its intended usage.
> > 
> > This patch adds a provision to pass the eeprom metadata for
> > %ETHTOOL_SEEPROM/%ETHTOOL_GEEPROM implementations. User provided
> > metadata will be cached by the driver and assigns a magic value which the
> > application need to use for the subsequent {G,S}EEPROM command.
> 
> Hi Dave,
> 
> This got no comments at all.
> What do you want us to with it next? Should we re-send it as a patch?

Here's a comment: I really dislike this.

- It doesn't specify any semantics for the 'metadata'.  The comment
hints that they are driver-specific identifiers for different NVRAM
partitions.

- It doesn't provide a way for userland to enumerate the valid metadata
values.

- It's not clear whether the driver is supposed to maintain just one
metadata:magic mapping, or more than that.

Is the ethtool API really the right interface for access to flash?  The
sfc driver exposes a large number of flash partitions using MTD
instead.  These can be enumerated (through /proc/mtd or sysfs) and they
can be read and written through block devices.

Ben.

-- 
Ben Hutchings
Everything should be made as simple as possible, but not simpler.
   - Albert
Einstein


signature.asc
Description: This is a digitally signed message part

Re: [PATCH net-next] net, cls: allow for deleting all filters for given parent

[Jamal Hadi Salim]

On 16-06-04 12:24 PM, Daniel Borkmann wrote:

Add a possibility where the user can just specify the parent and
all filters under that parent are then being purged. Currently,
for example for scripting, one needs to specify pref/prio to have
a well-defined number for 'tc filter del' command for addressing
the previously created instance or additionally filter handle in
case of priorities being the same. Improve usage by allowing the
option for tc to specify the parent and removing the whole chain
for that given parent.

Example usage after patch, no tc changes required:

   # tc qdisc replace dev foo clsact
   # tc filter add dev foo egress bpf da obj ./bpf.o
   # tc filter add dev foo egress bpf da obj ./bpf.o
   # tc filter show dev foo egress
   filter protocol all pref 49151 bpf
   filter protocol all pref 49151 bpf handle 0x1 bpf.o:[classifier] 
direct-action
   filter protocol all pref 49152 bpf
   filter protocol all pref 49152 bpf handle 0x1 bpf.o:[classifier] 
direct-action
   # tc filter del dev foo egress
   # tc filter show dev foo egress
   #

Previously, RTM_DELTFILTER requests with invalid prio of 0 were
rejected, so only netlink requests with RTM_NEWTFILTER and NLM_F_CREATE
flag were allowed where the kernel would auto-generate a pref/prio.
We can piggyback on that and use prio of 0 as a wildcard for
requests of RTM_DELTFILTER.

Signed-off-by: Daniel Borkmann 



Looks good to me.
Acked-by: Jamal Hadi Salim 

cheers,
jamal

RE: [PATCH net] bnx2x: allow adding VLANs while interface is down

[Yuval Mintz]

> > Since implementing VLAN filtering in commit 05cc5a39ddb74
> > ("bnx2x: add vlan filtering offload") bnx2x refuses to add a VLAN
> > while the interface is down.
> 
> Hi Michal - thanks; I'll review this one on Sunday.

I'm a bit worried about the fact we're hiding actual issues -
E.g., if for some [unexpected] reason a vlan configuration ramrod would
fail, the only effect it will have is that we'll try [and probably fail] to
change HW into any-vlan mode; We won't propagate the error back to
caller.

Having written that, since we can't really avoid this in some scenarios
 [I.e., if we accept the command while down and configure it later while
up we can't do anything with an error if it occurs], I guess that's the pros
out-weight the cons here.

Thanks.

Acked-by: Yuval Mintz 

Re: [PATCH 1/1] ixgbe: replace rtnl_lock with rcu_read_lock

[Eric Dumazet]

On Sun, 2016-06-05 at 17:14 +0800, zyjzyj2...@gmail.com wrote:
> From: Zhu Yanjun 
> 
> 
> Signed-off-by: Zhu Yanjun 
> ---

You do not explain if this is a bug fix (targeting net tree) or simply
an optimization in the slow path (targeting net-next tree) ?

A changelog, even small, would be nice, even if the patch looks valid.

[PATCH 3.10 128/143] VSOCK: do not disconnect socket when peer has shutdown SEND only

[Willy Tarreau]

From: Ian Campbell 

commit dedc58e067d8c379a15a8a183c5db318201295bb upstream.

The peer may be expecting a reply having sent a request and then done a
shutdown(SHUT_WR), so tearing down the whole socket at this point seems
wrong and breaks for me with a client which does a SHUT_WR.

Looking at other socket family's stream_recvmsg callbacks doing a shutdown
here does not seem to be the norm and removing it does not seem to have
had any adverse effects that I can see.

I'm using Stefan's RFC virtio transport patches, I'm unsure of the impact
on the vmci transport.

Signed-off-by: Ian Campbell 
Cc: "David S. Miller" 
Cc: Stefan Hajnoczi 
Cc: Claudio Imbrenda 
Cc: Andy King 
Cc: Dmitry Torokhov 
Cc: Jorgen Hansen 
Cc: Adit Ranadive 
Cc: netdev@vger.kernel.org
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Willy Tarreau 
---
 net/vmw_vsock/af_vsock.c | 21 +
 1 file changed, 1 insertion(+), 20 deletions(-)

diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
index 9b88693..66a9bf5 100644
--- a/net/vmw_vsock/af_vsock.c
+++ b/net/vmw_vsock/af_vsock.c
@@ -1804,27 +1804,8 @@ vsock_stream_recvmsg(struct kiocb *kiocb,
else if (sk->sk_shutdown & RCV_SHUTDOWN)
err = 0;
 
-   if (copied > 0) {
-   /* We only do these additional bookkeeping/notification steps
-* if we actually copied something out of the queue pair
-* instead of just peeking ahead.
-*/
-
-   if (!(flags & MSG_PEEK)) {
-   /* If the other side has shutdown for sending and there
-* is nothing more to read, then modify the socket
-* state.
-*/
-   if (vsk->peer_shutdown & SEND_SHUTDOWN) {
-   if (vsock_stream_has_data(vsk) <= 0) {
-   sk->sk_state = SS_UNCONNECTED;
-   sock_set_flag(sk, SOCK_DONE);
-   sk->sk_state_change(sk);
-   }
-   }
-   }
+   if (copied > 0)
err = copied;
-   }
 
 out_wait:
finish_wait(sk_sleep(sk), );
-- 
2.8.0.rc2.1.gbe9624a

Re: [PATCH] net: wireless: marvell: libertas: Remove create_workqueue

[Tejun Heo]

On Sat, Jun 04, 2016 at 07:29:01PM +0530, Bhaktipriya Shridhar wrote:
> alloc_workqueue replaces deprecated create_workqueue().
> 
> In if_sdio.c, the workqueue card->workqueue has workitem
> >packet_worker, which is mapped to if_sdio_host_to_card_worker.
> The workitem is involved in sending packets to firmware.
> Forward progress under memory pressure is a requirement here.
> 
> In if_spi.c, the workqueue card->workqueue has workitem
> >packet_worker, which is mapped to if_spi_host_to_card_worker.
> The workitem is involved in sending command packets from the host.
> Forward progress under memory pressure is a requirement here.
> 
> Dedicated workqueues have been used in both cases since the workitems
> on the workqueues are involved in normal device operation with
> WQ_MEM_RECLAIM set to gurantee forward progress under memory pressure.
> Since there are only a fixed number of work items, explicit concurrency
> limit is unnecessary.
> 
> flush_workqueue is unnecessary since destroy_workqueue() itself calls
> drain_workqueue() which flushes repeatedly till the workqueue
> becomes empty. Hence the calls to flush_workqueue() before
> destroy_workqueue() have been dropped.
> 
> Signed-off-by: Bhaktipriya Shridhar 

Acked-by: Tejun Heo 

Thanks.

-- 
tejun

Re: [PATCH] net: ethernet: cavium: liquidio: response_manager: Remove create_workqueue

[Tejun Heo]

On Sat, Jun 04, 2016 at 08:21:40PM +0530, Bhaktipriya Shridhar wrote:
> alloc_workqueue replaces deprecated create_workqueue().
> 
> A dedicated workqueue has been used since the workitem viz
> (>wk.work which maps to oct_poll_req_completion) is involved
> in normal device operation. WQ_MEM_RECLAIM has been set to guarantee
> forward progress under memory pressure, which is a requirement here.
> Since there are only a fixed number of work items, explicit concurrency
> limit is unnecessary.
> 
> flush_workqueue is unnecessary since destroy_workqueue() itself calls
> drain_workqueue() which flushes repeatedly till the workqueue
> becomes empty. Hence the call to flush_workqueue() has been dropped.
> 
> Signed-off-by: Bhaktipriya Shridhar 

As with the previous patch, the subject tag doesn't need to contain
the full hierarchy but other than that,

 Acked-by: Tejun Heo 

Thanks.

-- 
tejun

Re: [PATCH] net: ethernet: cavium: liquidio: request_manager: Remove create_workqueue

[Tejun Heo]

On Sat, Jun 04, 2016 at 08:54:00PM +0530, Bhaktipriya Shridhar wrote:
> diff --git a/drivers/net/ethernet/cavium/liquidio/request_manager.c 
> b/drivers/net/ethernet/cavium/liquidio/request_manager.c
> index a2a2465..9313915 100644
> --- a/drivers/net/ethernet/cavium/liquidio/request_manager.c
> +++ b/drivers/net/ethernet/cavium/liquidio/request_manager.c
> @@ -144,7 +144,9 @@ int octeon_init_instr_queue(struct octeon_device *oct,
> 
>   oct->fn_list.setup_iq_regs(oct, iq_no);
> 
> - oct->check_db_wq[iq_no].wq = create_workqueue("check_iq_db");
> + oct->check_db_wq[iq_no].wq = alloc_workqueue("check_iq_db",
> +  WQ_MEM_RECLAIM,
> +  0);

Why the new line between WQ_MEM_RECLAIM and 0?

Except for the subj tag and the above nit,

 Acked-by: Tejun Heo 

Thanks.

-- 
tejun

RE: [RFC net-next 1/1] ethtool: Add support for set eeprom metadata.

[Yuval Mintz]

> Currently ethtool implementation does not have a way to pass the metadata for
> eeprom related operations. Some adapters have a complicated non-volatile
> memory implementation that requires additional information – there are drivers
> [bnx2x and bnxt] that use the ‘magic’ field in the {G,S}EEPROM  for that 
> purpose,
> although that’s not its intended usage.
> 
> This patch adds a provision to pass the eeprom metadata for
> %ETHTOOL_SEEPROM/%ETHTOOL_GEEPROM implementations. User provided
> metadata will be cached by the driver and assigns a magic value which the
> application need to use for the subsequent {G,S}EEPROM command.

Hi Dave,

This got no comments at all.
What do you want us to with it next? Should we re-send it as a patch?

Thanks,
Yuval

[PATCH net-next 6/6] qed: PF to reply to unknown messages

[Yuval Mintz]

If a future VF would send the PF an unknown message, the PF today would
not send a reply. This would have 2 bad effects:
  a. VF would have to timeout on the request.
  b. If VF were to send an additional message to PF, firmware would mark
 it as malicious.

Instead, if there's some valid reply-address on the message - let the PF
answer and tell the VF it doesn't know the message.

Signed-off-by: Yuval Mintz 
---
 drivers/net/ethernet/qlogic/qed/qed_sriov.c | 33 +++--
 1 file changed, 22 insertions(+), 11 deletions(-)

diff --git a/drivers/net/ethernet/qlogic/qed/qed_sriov.c 
b/drivers/net/ethernet/qlogic/qed/qed_sriov.c
index 50b535a..0a5b1f5 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_sriov.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_sriov.c
@@ -2857,7 +2857,6 @@ static void qed_iov_process_mbx_req(struct qed_hwfn 
*p_hwfn,
 {
struct qed_iov_vf_mbx *mbx;
struct qed_vf_info *p_vf;
-   int i;
 
p_vf = qed_iov_get_vf_info(p_hwfn, (u16) vfid, true);
if (!p_vf)
@@ -2866,9 +2865,8 @@ static void qed_iov_process_mbx_req(struct qed_hwfn 
*p_hwfn,
mbx = _vf->vf_mbx;
 
/* qed_iov_process_mbx_request */
-   DP_VERBOSE(p_hwfn,
-  QED_MSG_IOV,
-  "qed_iov_process_mbx_req vfid %d\n", p_vf->abs_vf_id);
+   DP_VERBOSE(p_hwfn, QED_MSG_IOV,
+  "VF[%02x]: Processing mailbox message\n", p_vf->abs_vf_id);
 
mbx->first_tlv = mbx->req_virt->first_tlv;
 
@@ -2922,15 +2920,28 @@ static void qed_iov_process_mbx_req(struct qed_hwfn 
*p_hwfn,
 * support them. Or this may be because someone wrote a crappy
 * VF driver and is sending garbage over the channel.
 */
-   DP_ERR(p_hwfn,
-  "unknown TLV. type %d length %d. first 20 bytes of 
mailbox buffer:\n",
-  mbx->first_tlv.tl.type, mbx->first_tlv.tl.length);
-
-   for (i = 0; i < 20; i++) {
+   DP_NOTICE(p_hwfn,
+ "VF[%02x]: unknown TLV. type %04x length %04x padding 
%08x reply address %llu\n",
+ p_vf->abs_vf_id,
+ mbx->first_tlv.tl.type,
+ mbx->first_tlv.tl.length,
+ mbx->first_tlv.padding, mbx->first_tlv.reply_address);
+
+   /* Try replying in case reply address matches the acquisition's
+* posted address.
+*/
+   if (p_vf->acquire.first_tlv.reply_address &&
+   (mbx->first_tlv.reply_address ==
+p_vf->acquire.first_tlv.reply_address)) {
+   qed_iov_prepare_resp(p_hwfn, p_ptt, p_vf,
+mbx->first_tlv.tl.type,
+sizeof(struct pfvf_def_resp_tlv),
+PFVF_STATUS_NOT_SUPPORTED);
+   } else {
DP_VERBOSE(p_hwfn,
   QED_MSG_IOV,
-  "%x ",
-  mbx->req_virt->tlv_buf_size.tlv_buffer[i]);
+  "VF[%02x]: Can't respond to TLV - no valid 
reply address\n",
+  p_vf->abs_vf_id);
}
}
 }
-- 
1.9.3

[PATCH net-next 5/6] qed: PF enforce MAC limitation of VFs

[Yuval Mintz]

The only limitation relating to MACs the PF enforce today on its VFs
is in case it has a forced-unicast MAC address for them, in which case
they can't configure other unicast addresses.
Specifically, the PF isn't enforcing the number of MAC addresse a VF can
configure regardless of the nubmer of such filters agreed upon by PF and
VF during the acquisition process.

PF's shadow-config is now extended to also contain information about its
VFs' unicast addresses configuration, allowing such enforcement.

Signed-off-by: Yuval Mintz 
---
 drivers/net/ethernet/qlogic/qed/qed_sriov.c | 83 ++---
 drivers/net/ethernet/qlogic/qed/qed_sriov.h |  2 +
 2 files changed, 79 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/qlogic/qed/qed_sriov.c 
b/drivers/net/ethernet/qlogic/qed/qed_sriov.c
index 0094f86..50b535a 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_sriov.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_sriov.c
@@ -2309,15 +2309,12 @@ out:
qed_iov_send_response(p_hwfn, p_ptt, vf, length, status);
 }
 
-static int qed_iov_vf_update_unicast_shadow(struct qed_hwfn *p_hwfn,
-   struct qed_vf_info *p_vf,
-   struct qed_filter_ucast *p_params)
+static int qed_iov_vf_update_vlan_shadow(struct qed_hwfn *p_hwfn,
+struct qed_vf_info *p_vf,
+struct qed_filter_ucast *p_params)
 {
int i;
 
-   if (p_params->type == QED_FILTER_MAC)
-   return 0;
-
/* First remove entries and then add new ones */
if (p_params->opcode == QED_FILTER_REMOVE) {
for (i = 0; i < QED_ETH_VF_NUM_VLAN_FILTERS + 1; i++)
@@ -2370,6 +2367,80 @@ static int qed_iov_vf_update_unicast_shadow(struct 
qed_hwfn *p_hwfn,
return 0;
 }
 
+static int qed_iov_vf_update_mac_shadow(struct qed_hwfn *p_hwfn,
+   struct qed_vf_info *p_vf,
+   struct qed_filter_ucast *p_params)
+{
+   int i;
+
+   /* If we're in forced-mode, we don't allow any change */
+   if (p_vf->bulletin.p_virt->valid_bitmap & (1 << MAC_ADDR_FORCED))
+   return 0;
+
+   /* First remove entries and then add new ones */
+   if (p_params->opcode == QED_FILTER_REMOVE) {
+   for (i = 0; i < QED_ETH_VF_NUM_MAC_FILTERS; i++) {
+   if (ether_addr_equal(p_vf->shadow_config.macs[i],
+p_params->mac)) {
+   memset(p_vf->shadow_config.macs[i], 0,
+  ETH_ALEN);
+   break;
+   }
+   }
+
+   if (i == QED_ETH_VF_NUM_MAC_FILTERS) {
+   DP_VERBOSE(p_hwfn, QED_MSG_IOV,
+  "MAC isn't configured\n");
+   return -EINVAL;
+   }
+   } else if (p_params->opcode == QED_FILTER_REPLACE ||
+  p_params->opcode == QED_FILTER_FLUSH) {
+   for (i = 0; i < QED_ETH_VF_NUM_MAC_FILTERS; i++)
+   memset(p_vf->shadow_config.macs[i], 0, ETH_ALEN);
+   }
+
+   /* List the new MAC address */
+   if (p_params->opcode != QED_FILTER_ADD &&
+   p_params->opcode != QED_FILTER_REPLACE)
+   return 0;
+
+   for (i = 0; i < QED_ETH_VF_NUM_MAC_FILTERS; i++) {
+   if (is_zero_ether_addr(p_vf->shadow_config.macs[i])) {
+   ether_addr_copy(p_vf->shadow_config.macs[i],
+   p_params->mac);
+   DP_VERBOSE(p_hwfn, QED_MSG_IOV,
+  "Added MAC at %d entry in shadow\n", i);
+   break;
+   }
+   }
+
+   if (i == QED_ETH_VF_NUM_MAC_FILTERS) {
+   DP_VERBOSE(p_hwfn, QED_MSG_IOV, "No available place for MAC\n");
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
+static int
+qed_iov_vf_update_unicast_shadow(struct qed_hwfn *p_hwfn,
+struct qed_vf_info *p_vf,
+struct qed_filter_ucast *p_params)
+{
+   int rc = 0;
+
+   if (p_params->type == QED_FILTER_MAC) {
+   rc = qed_iov_vf_update_mac_shadow(p_hwfn, p_vf, p_params);
+   if (rc)
+   return rc;
+   }
+
+   if (p_params->type == QED_FILTER_VLAN)
+   rc = qed_iov_vf_update_vlan_shadow(p_hwfn, p_vf, p_params);
+
+   return rc;
+}
+
 int qed_iov_chk_ucast(struct qed_hwfn *hwfn,
  int vfid, struct qed_filter_ucast *params)
 {
diff --git a/drivers/net/ethernet/qlogic/qed/qed_sriov.h 
b/drivers/net/ethernet/qlogic/qed/qed_sriov.h
index ea24795..96a7273 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_sriov.h
+++ 

[PATCH net-next 3/6] qed: Make PF more robust against malicious VF

[Yuval Mintz]

There are several requests the VF can make toward the PF which the driver
would pass to firmware without checking the validity first - specifically,
opening queues and updating vports. Such configurations might cause the
firmware to assert.

This adds validation of the legality of said configurations on the PF side
before passing it onward via ramrod to firmware.

Signed-off-by: Yuval Mintz 
---
 drivers/net/ethernet/qlogic/qed/qed_sriov.c | 72 +++--
 1 file changed, 68 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/qlogic/qed/qed_sriov.c 
b/drivers/net/ethernet/qlogic/qed/qed_sriov.c
index dbb4553..a1e40bb 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_sriov.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_sriov.c
@@ -146,6 +146,45 @@ static struct qed_vf_info *qed_iov_get_vf_info(struct 
qed_hwfn *p_hwfn,
return vf;
 }
 
+static bool qed_iov_validate_rxq(struct qed_hwfn *p_hwfn,
+struct qed_vf_info *p_vf, u16 rx_qid)
+{
+   if (rx_qid >= p_vf->num_rxqs)
+   DP_VERBOSE(p_hwfn,
+  QED_MSG_IOV,
+  "VF[0x%02x] - can't touch Rx queue[%04x]; Only 
0x%04x are allocated\n",
+  p_vf->abs_vf_id, rx_qid, p_vf->num_rxqs);
+   return rx_qid < p_vf->num_rxqs;
+}
+
+static bool qed_iov_validate_txq(struct qed_hwfn *p_hwfn,
+struct qed_vf_info *p_vf, u16 tx_qid)
+{
+   if (tx_qid >= p_vf->num_txqs)
+   DP_VERBOSE(p_hwfn,
+  QED_MSG_IOV,
+  "VF[0x%02x] - can't touch Tx queue[%04x]; Only 
0x%04x are allocated\n",
+  p_vf->abs_vf_id, tx_qid, p_vf->num_txqs);
+   return tx_qid < p_vf->num_txqs;
+}
+
+static bool qed_iov_validate_sb(struct qed_hwfn *p_hwfn,
+   struct qed_vf_info *p_vf, u16 sb_idx)
+{
+   int i;
+
+   for (i = 0; i < p_vf->num_sbs; i++)
+   if (p_vf->igu_sbs[i] == sb_idx)
+   return true;
+
+   DP_VERBOSE(p_hwfn,
+  QED_MSG_IOV,
+  "VF[0%02x] - tried using sb_idx %04x which doesn't exist as 
one of its 0x%02x SBs\n",
+  p_vf->abs_vf_id, sb_idx, p_vf->num_sbs);
+
+   return false;
+}
+
 int qed_iov_post_vf_bulletin(struct qed_hwfn *p_hwfn,
 int vfid, struct qed_ptt *p_ptt)
 {
@@ -1687,12 +1726,17 @@ static void qed_iov_vf_mbx_start_rxq(struct qed_hwfn 
*p_hwfn,
 {
struct qed_queue_start_common_params params;
struct qed_iov_vf_mbx *mbx = >vf_mbx;
-   u8 status = PFVF_STATUS_SUCCESS;
+   u8 status = PFVF_STATUS_NO_RESOURCE;
struct vfpf_start_rxq_tlv *req;
int rc;
 
memset(, 0, sizeof(params));
req = >req_virt->start_rxq;
+
+   if (!qed_iov_validate_rxq(p_hwfn, vf, req->rx_qid) ||
+   !qed_iov_validate_sb(p_hwfn, vf, req->hw_sb))
+   goto out;
+
params.queue_id =  vf->vf_queues[req->rx_qid].fw_rx_qid;
params.vf_qid = req->rx_qid;
params.vport_id = vf->vport_id;
@@ -1710,10 +1754,12 @@ static void qed_iov_vf_mbx_start_rxq(struct qed_hwfn 
*p_hwfn,
if (rc) {
status = PFVF_STATUS_FAILURE;
} else {
+   status = PFVF_STATUS_SUCCESS;
vf->vf_queues[req->rx_qid].rxq_active = true;
vf->num_active_rxqs++;
}
 
+out:
qed_iov_vf_mbx_start_rxq_resp(p_hwfn, p_ptt, vf, status);
 }
 
@@ -1724,8 +1770,8 @@ static void qed_iov_vf_mbx_start_txq(struct qed_hwfn 
*p_hwfn,
u16 length = sizeof(struct pfvf_def_resp_tlv);
struct qed_queue_start_common_params params;
struct qed_iov_vf_mbx *mbx = >vf_mbx;
+   u8 status = PFVF_STATUS_NO_RESOURCE;
union qed_qm_pq_params pq_params;
-   u8 status = PFVF_STATUS_SUCCESS;
struct vfpf_start_txq_tlv *req;
int rc;
 
@@ -1736,6 +1782,11 @@ static void qed_iov_vf_mbx_start_txq(struct qed_hwfn 
*p_hwfn,
 
memset(, 0, sizeof(params));
req = >req_virt->start_txq;
+
+   if (!qed_iov_validate_txq(p_hwfn, vf, req->tx_qid) ||
+   !qed_iov_validate_sb(p_hwfn, vf, req->hw_sb))
+   goto out;
+
params.queue_id =  vf->vf_queues[req->tx_qid].fw_tx_qid;
params.vport_id = vf->vport_id;
params.sb = req->hw_sb;
@@ -1749,11 +1800,14 @@ static void qed_iov_vf_mbx_start_txq(struct qed_hwfn 
*p_hwfn,
 req->pbl_addr,
 req->pbl_size, _params);
 
-   if (rc)
+   if (rc) {
status = PFVF_STATUS_FAILURE;
-   else
+   } else {
+   status = PFVF_STATUS_SUCCESS;
vf->vf_queues[req->tx_qid].txq_active = true;
+   }
 
+out:
qed_iov_prepare_resp(p_hwfn, p_ptt, vf, CHANNEL_TLV_START_TXQ,
   

[PATCH net-next 4/6] qed: Move doorbell calculation from VF to PF

[Yuval Mintz]

Today, the VF is aware of its queues context-ids, and calculates the
doorbell address when opening its queues on its own.
The configuration of doorbells in HW can sometime in the future be changed
by the PF [hw has several configurable features that might affect doorbell
addresses, e.g., dpm support], this would break compatibility with older
VFs as their calculated doorbell addresses would be incorrect for such a
configuration.

In order to avoid such a backward compatibility failure, let the PF make
the calculation of the doorbell offset based on the context-id, and pass
that to the VF.

Signed-off-by: Yuval Mintz 
---
 drivers/net/ethernet/qlogic/qed/qed_sriov.c | 29 ++---
 drivers/net/ethernet/qlogic/qed/qed_vf.c| 20 
 2 files changed, 38 insertions(+), 11 deletions(-)

diff --git a/drivers/net/ethernet/qlogic/qed/qed_sriov.c 
b/drivers/net/ethernet/qlogic/qed/qed_sriov.c
index a1e40bb..0094f86 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_sriov.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_sriov.c
@@ -1763,11 +1763,35 @@ out:
qed_iov_vf_mbx_start_rxq_resp(p_hwfn, p_ptt, vf, status);
 }
 
+static void qed_iov_vf_mbx_start_txq_resp(struct qed_hwfn *p_hwfn,
+ struct qed_ptt *p_ptt,
+ struct qed_vf_info *p_vf, u8 status)
+{
+   struct qed_iov_vf_mbx *mbx = _vf->vf_mbx;
+   struct pfvf_start_queue_resp_tlv *p_tlv;
+
+   mbx->offset = (u8 *)mbx->reply_virt;
+
+   p_tlv = qed_add_tlv(p_hwfn, >offset, CHANNEL_TLV_START_TXQ,
+   sizeof(*p_tlv));
+   qed_add_tlv(p_hwfn, >offset, CHANNEL_TLV_LIST_END,
+   sizeof(struct channel_list_end_tlv));
+
+   /* Update the TLV with the response */
+   if (status == PFVF_STATUS_SUCCESS) {
+   u16 qid = mbx->req_virt->start_txq.tx_qid;
+
+   p_tlv->offset = qed_db_addr(p_vf->vf_queues[qid].fw_cid,
+   DQ_DEMS_LEGACY);
+   }
+
+   qed_iov_send_response(p_hwfn, p_ptt, p_vf, sizeof(*p_tlv), status);
+}
+
 static void qed_iov_vf_mbx_start_txq(struct qed_hwfn *p_hwfn,
 struct qed_ptt *p_ptt,
 struct qed_vf_info *vf)
 {
-   u16 length = sizeof(struct pfvf_def_resp_tlv);
struct qed_queue_start_common_params params;
struct qed_iov_vf_mbx *mbx = >vf_mbx;
u8 status = PFVF_STATUS_NO_RESOURCE;
@@ -1808,8 +1832,7 @@ static void qed_iov_vf_mbx_start_txq(struct qed_hwfn 
*p_hwfn,
}
 
 out:
-   qed_iov_prepare_resp(p_hwfn, p_ptt, vf, CHANNEL_TLV_START_TXQ,
-length, status);
+   qed_iov_vf_mbx_start_txq_resp(p_hwfn, p_ptt, vf, status);
 }
 
 static int qed_iov_vf_stop_rxqs(struct qed_hwfn *p_hwfn,
diff --git a/drivers/net/ethernet/qlogic/qed/qed_vf.c 
b/drivers/net/ethernet/qlogic/qed/qed_vf.c
index 46751ce..9819230 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_vf.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_vf.c
@@ -440,8 +440,8 @@ int qed_vf_pf_txq_start(struct qed_hwfn *p_hwfn,
u16 pbl_size, void __iomem **pp_doorbell)
 {
struct qed_vf_iov *p_iov = p_hwfn->vf_iov_info;
+   struct pfvf_start_queue_resp_tlv *resp;
struct vfpf_start_txq_tlv *req;
-   struct pfvf_def_resp_tlv *resp;
int rc;
 
/* clear mailbox and prep first tlv */
@@ -459,20 +459,24 @@ int qed_vf_pf_txq_start(struct qed_hwfn *p_hwfn,
qed_add_tlv(p_hwfn, _iov->offset,
CHANNEL_TLV_LIST_END, sizeof(struct channel_list_end_tlv));
 
-   resp = _iov->pf2vf_reply->default_resp;
+   resp = _iov->pf2vf_reply->queue_start;
rc = qed_send_msg2pf(p_hwfn, >hdr.status, sizeof(*resp));
if (rc)
-   return rc;
+   goto exit;
 
-   if (resp->hdr.status != PFVF_STATUS_SUCCESS)
-   return -EINVAL;
+   if (resp->hdr.status != PFVF_STATUS_SUCCESS) {
+   rc = -EINVAL;
+   goto exit;
+   }
 
if (pp_doorbell) {
-   u8 cid = p_iov->acquire_resp.resc.cid[tx_queue_id];
+   *pp_doorbell = (u8 __iomem *)p_hwfn->doorbells + resp->offset;
 
-   *pp_doorbell = (u8 __iomem *)p_hwfn->doorbells +
-qed_db_addr(cid, DQ_DEMS_LEGACY);
+   DP_VERBOSE(p_hwfn, QED_MSG_IOV,
+  "Txq[0x%02x]: doorbell at %p [offset 0x%08x]\n",
+  tx_queue_id, *pp_doorbell, resp->offset);
}
+exit:
 
return rc;
 }
-- 
1.9.3

[PATCH net-next 2/6] qed: PF-VF resource negotiation

[Yuval Mintz]

One of the goals of the vf's first message to the PF [acquire]
is to learn about the number of resources available to it [macs, vlans,
etc.]. This is done via negotiation - the VF requires a set of resources,
which the PF either approves or disaproves and sends a smaller set of
resources as alternative. In this later case, the VF is then expected to
either abort the probe or re-send the acquire message with less
required resources.

While this infrastructure exists since the initial submision of qed
SRIOV support, it's in fact completely inoperational - PF isn't really
looking into the resources the VF has asked for and is never going to
reply to the VF that it lacks resources.

This patch addresses this flow, fixing it and allowing the PF and VF
to actually agree on a set of resources.

Signed-off-by: Yuval Mintz 
---
 drivers/net/ethernet/qlogic/qed/qed_sriov.c | 144 ++--
 drivers/net/ethernet/qlogic/qed/qed_sriov.h |   4 +-
 drivers/net/ethernet/qlogic/qed/qed_vf.c|  56 +++
 3 files changed, 135 insertions(+), 69 deletions(-)

diff --git a/drivers/net/ethernet/qlogic/qed/qed_sriov.c 
b/drivers/net/ethernet/qlogic/qed/qed_sriov.c
index 9857624..dbb4553 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_sriov.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_sriov.c
@@ -322,6 +322,9 @@ static void qed_iov_setup_vfdb(struct qed_hwfn *p_hwfn)
vf->opaque_fid = (p_hwfn->hw_info.opaque_fid & 0xff) |
 (vf->abs_vf_id << 8);
vf->vport_id = idx + 1;
+
+   vf->num_mac_filters = QED_ETH_VF_NUM_MAC_FILTERS;
+   vf->num_vlan_filters = QED_ETH_VF_NUM_VLAN_FILTERS;
}
 }
 
@@ -1123,8 +1126,6 @@ static void qed_iov_vf_cleanup(struct qed_hwfn *p_hwfn,
 
p_vf->vf_bulletin = 0;
p_vf->vport_instance = 0;
-   p_vf->num_mac_filters = 0;
-   p_vf->num_vlan_filters = 0;
p_vf->configured_features = 0;
 
/* If VF previously requested less resources, go back to default */
@@ -1141,6 +1142,91 @@ static void qed_iov_vf_cleanup(struct qed_hwfn *p_hwfn,
qed_iov_clean_vf(p_hwfn, p_vf->relative_vf_id);
 }
 
+static u8 qed_iov_vf_mbx_acquire_resc(struct qed_hwfn *p_hwfn,
+ struct qed_ptt *p_ptt,
+ struct qed_vf_info *p_vf,
+ struct vf_pf_resc_request *p_req,
+ struct pf_vf_resc *p_resp)
+{
+   int i;
+
+   /* Queue related information */
+   p_resp->num_rxqs = p_vf->num_rxqs;
+   p_resp->num_txqs = p_vf->num_txqs;
+   p_resp->num_sbs = p_vf->num_sbs;
+
+   for (i = 0; i < p_resp->num_sbs; i++) {
+   p_resp->hw_sbs[i].hw_sb_id = p_vf->igu_sbs[i];
+   p_resp->hw_sbs[i].sb_qid = 0;
+   }
+
+   /* These fields are filled for backward compatibility.
+* Unused by modern vfs.
+*/
+   for (i = 0; i < p_resp->num_rxqs; i++) {
+   qed_fw_l2_queue(p_hwfn, p_vf->vf_queues[i].fw_rx_qid,
+   (u16 *)_resp->hw_qid[i]);
+   p_resp->cid[i] = p_vf->vf_queues[i].fw_cid;
+   }
+
+   /* Filter related information */
+   p_resp->num_mac_filters = min_t(u8, p_vf->num_mac_filters,
+   p_req->num_mac_filters);
+   p_resp->num_vlan_filters = min_t(u8, p_vf->num_vlan_filters,
+p_req->num_vlan_filters);
+
+   /* This isn't really needed/enforced, but some legacy VFs might depend
+* on the correct filling of this field.
+*/
+   p_resp->num_mc_filters = QED_MAX_MC_ADDRS;
+
+   /* Validate sufficient resources for VF */
+   if (p_resp->num_rxqs < p_req->num_rxqs ||
+   p_resp->num_txqs < p_req->num_txqs ||
+   p_resp->num_sbs < p_req->num_sbs ||
+   p_resp->num_mac_filters < p_req->num_mac_filters ||
+   p_resp->num_vlan_filters < p_req->num_vlan_filters ||
+   p_resp->num_mc_filters < p_req->num_mc_filters) {
+   DP_VERBOSE(p_hwfn,
+  QED_MSG_IOV,
+  "VF[%d] - Insufficient resources: rxq [%02x/%02x] 
txq [%02x/%02x] sbs [%02x/%02x] mac [%02x/%02x] vlan [%02x/%02x] mc 
[%02x/%02x]\n",
+  p_vf->abs_vf_id,
+  p_req->num_rxqs,
+  p_resp->num_rxqs,
+  p_req->num_rxqs,
+  p_resp->num_txqs,
+  p_req->num_sbs,
+  p_resp->num_sbs,
+  p_req->num_mac_filters,
+  p_resp->num_mac_filters,
+  p_req->num_vlan_filters,
+  p_resp->num_vlan_filters,
+  p_req->num_mc_filters, p_resp->num_mc_filters);
+   return 

[PATCH net-next 0/6] qed: IOV series - relax firmware requirements

[Yuval Mintz]

In order for VFs to work, current implementation demands that the VF's
requried storm firmware would be exactly the version that was loaded by
the PF, which is a very harsh requirement.
This patch series is intended to relax this -
the recently submitted firmware is intended to be forward/backward
compatible in its fastpath [slowpath is configured by PF on behalf of VF],
and so VFs would only be required of having the same major faspath HSI in
order to work.

Most of the other patches in this series extend current forward
compatibilty of driver to reduce chance of breaking PF/VF compatibility
in the future. A few are unrelated IOV changes.

Dave,

Please consider applying these to 'net-next'.

Thanks,
Yuval

Yuval Mintz (6):
  qed: Relax VF firmware requirements
  qed: PF-VF resource negotiation
  qed: Make PF more robust against malicious VF
  qed: Move doorbell calculation from VF to PF
  qed: PF enforce MAC limitation of VFs
  qed: PF to reply to unknown messages

 drivers/net/ethernet/qlogic/qed/qed_sriov.c | 488 +---
 drivers/net/ethernet/qlogic/qed/qed_sriov.h |   9 +-
 drivers/net/ethernet/qlogic/qed/qed_vf.c|  95 --
 drivers/net/ethernet/qlogic/qed/qed_vf.h|  13 +-
 4 files changed, 456 insertions(+), 149 deletions(-)

-- 
1.9.3

[PATCH net-next 1/6] qed: Relax VF firmware requirements

[Yuval Mintz]

Current driver require an exact match between VF and PF storm firmware;
Any difference would fail the VF acquire message, causing the VF probe
to be aborted.

While there's still dependencies between the two, the recent FW submission
has relaxed the match requirement - instead of an exact match, there's now
a 'fastpath' HSI major/minor scheme, where VFs and PFs that match in their
major number can co-exist even if their minor is different.

In order to accomadate this change some changes in the vf-start init flow
had to be made, as the VF start ramrod now has to be sent only after PF
learns which fastpath HSI its VF is requiring.

Signed-off-by: Yuval Mintz 
---
 drivers/net/ethernet/qlogic/qed/qed_sriov.c | 131 ++--
 drivers/net/ethernet/qlogic/qed/qed_sriov.h |   3 +
 drivers/net/ethernet/qlogic/qed/qed_vf.c|  19 
 drivers/net/ethernet/qlogic/qed/qed_vf.h|  13 ++-
 4 files changed, 116 insertions(+), 50 deletions(-)

diff --git a/drivers/net/ethernet/qlogic/qed/qed_sriov.c 
b/drivers/net/ethernet/qlogic/qed/qed_sriov.c
index eb75b82..9857624 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_sriov.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_sriov.c
@@ -21,18 +21,18 @@
 #include "qed_vf.h"
 
 /* IOV ramrods */
-static int qed_sp_vf_start(struct qed_hwfn *p_hwfn,
-  u32 concrete_vfid, u16 opaque_vfid)
+static int qed_sp_vf_start(struct qed_hwfn *p_hwfn, struct qed_vf_info *p_vf)
 {
struct vf_start_ramrod_data *p_ramrod = NULL;
struct qed_spq_entry *p_ent = NULL;
struct qed_sp_init_data init_data;
int rc = -EINVAL;
+   u8 fp_minor;
 
/* Get SPQ entry */
memset(_data, 0, sizeof(init_data));
init_data.cid = qed_spq_get_cid(p_hwfn);
-   init_data.opaque_fid = opaque_vfid;
+   init_data.opaque_fid = p_vf->opaque_fid;
init_data.comp_mode = QED_SPQ_MODE_EBLOCK;
 
rc = qed_sp_init_request(p_hwfn, _ent,
@@ -43,12 +43,39 @@ static int qed_sp_vf_start(struct qed_hwfn *p_hwfn,
 
p_ramrod = _ent->ramrod.vf_start;
 
-   p_ramrod->vf_id = GET_FIELD(concrete_vfid, PXP_CONCRETE_FID_VFID);
-   p_ramrod->opaque_fid = cpu_to_le16(opaque_vfid);
+   p_ramrod->vf_id = GET_FIELD(p_vf->concrete_fid, PXP_CONCRETE_FID_VFID);
+   p_ramrod->opaque_fid = cpu_to_le16(p_vf->opaque_fid);
+
+   switch (p_hwfn->hw_info.personality) {
+   case QED_PCI_ETH:
+   p_ramrod->personality = PERSONALITY_ETH;
+   break;
+   case QED_PCI_ETH_ROCE:
+   p_ramrod->personality = PERSONALITY_RDMA_AND_ETH;
+   break;
+   default:
+   DP_NOTICE(p_hwfn, "Unknown VF personality %d\n",
+ p_hwfn->hw_info.personality);
+   return -EINVAL;
+   }
+
+   fp_minor = p_vf->acquire.vfdev_info.eth_fp_hsi_minor;
+   if (fp_minor > ETH_HSI_VER_MINOR) {
+   DP_VERBOSE(p_hwfn,
+  QED_MSG_IOV,
+  "VF [%d] - Requested fp hsi %02x.%02x which is 
slightly newer than PF's %02x.%02x; Configuring PFs version\n",
+  p_vf->abs_vf_id,
+  ETH_HSI_VER_MAJOR,
+  fp_minor, ETH_HSI_VER_MAJOR, ETH_HSI_VER_MINOR);
+   fp_minor = ETH_HSI_VER_MINOR;
+   }
 
-   p_ramrod->personality = PERSONALITY_ETH;
p_ramrod->hsi_fp_ver.major_ver_arr[ETH_VER_KEY] = ETH_HSI_VER_MAJOR;
-   p_ramrod->hsi_fp_ver.minor_ver_arr[ETH_VER_KEY] = ETH_HSI_VER_MINOR;
+   p_ramrod->hsi_fp_ver.minor_ver_arr[ETH_VER_KEY] = fp_minor;
+
+   DP_VERBOSE(p_hwfn, QED_MSG_IOV,
+  "VF[%d] - Starting using HSI %02x.%02x\n",
+  p_vf->abs_vf_id, ETH_HSI_VER_MAJOR, fp_minor);
 
return qed_spq_post(p_hwfn, p_ent, NULL);
 }
@@ -600,17 +627,6 @@ static int qed_iov_enable_vf_access(struct qed_hwfn 
*p_hwfn,
/* unpretend */
qed_fid_pretend(p_hwfn, p_ptt, (u16) p_hwfn->hw_info.concrete_fid);
 
-   if (vf->state != VF_STOPPED) {
-   DP_NOTICE(p_hwfn, "VF[%02x] is already started\n",
- vf->abs_vf_id);
-   return -EINVAL;
-   }
-
-   /* Start VF */
-   rc = qed_sp_vf_start(p_hwfn, vf->concrete_fid, vf->opaque_fid);
-   if (rc)
-   DP_NOTICE(p_hwfn, "Failed to start VF[%02x]\n", vf->abs_vf_id);
-
vf->state = VF_FREE;
 
return rc;
@@ -854,7 +870,6 @@ static int qed_iov_release_hw_for_vf(struct qed_hwfn 
*p_hwfn,
struct qed_mcp_link_params params;
struct qed_mcp_link_state link;
struct qed_vf_info *vf = NULL;
-   int rc = 0;
 
vf = qed_iov_get_vf_info(p_hwfn, rel_vf_id, true);
if (!vf) {
@@ -876,18 +891,8 @@ static int qed_iov_release_hw_for_vf(struct qed_hwfn 
*p_hwfn,
memcpy(, qed_mcp_get_link_capabilities(p_hwfn), sizeof(caps));
qed_iov_set_link(p_hwfn, 

[PATCH 1/1] ixgbe: replace rtnl_lock with rcu_read_lock

[zyjzyj2000]

From: Zhu Yanjun 


Signed-off-by: Zhu Yanjun 
---
 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c 
b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 088c47c..cb19cbc 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -6840,7 +6840,7 @@ static void ixgbe_watchdog_link_is_up(struct 
ixgbe_adapter *adapter)
netif_tx_wake_all_queues(adapter->netdev);
 
/* enable any upper devices */
-   rtnl_lock();
+   rcu_read_lock();
netdev_for_each_all_upper_dev_rcu(adapter->netdev, upper, iter) {
if (netif_is_macvlan(upper)) {
struct macvlan_dev *vlan = netdev_priv(upper);
@@ -6849,7 +6849,7 @@ static void ixgbe_watchdog_link_is_up(struct 
ixgbe_adapter *adapter)
netif_tx_wake_all_queues(upper);
}
}
-   rtnl_unlock();
+   rcu_read_unlock();
 
/* update the default user priority for VFs */
ixgbe_update_default_up(adapter);
-- 
1.7.9.5

ixgbe: replace rtnl_lock with rcu_read_lock

[zyjzyj2000]

Hi,all

 I am using the ixgbe nic. I found that the rtnl_lock is being 
 used to enable upper device, such as macvlan. I am curious
 why rcu_read_lock is not used here.

 I replaced rtnl_lock with rcu_read_lock here. Then I made tests and
 it can work well.

 So can the rtnl_lock be replaced with rcu_read_lock?
 Anyone can explain it in details?

 Any reply is appreciated.
 Zhu Yanjun

Re: [PATCH net-next 1/3] arm64: bpf: implement bpf_tail_call() helper

[Daniel Borkmann]

On 06/05/2016 01:46 AM, kbuild test robot wrote:

Hi,

[auto build test ERROR on net-next/master]

url:
https://github.com/0day-ci/linux/commits/Zi-Shen-Lim/arm64-bpf-implement-bpf_tail_call-helper/20160605-060435
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 5.3.1-8) 5.3.1 20160205
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=arm64

All errors (new ones prefixed by >>):

In file included from arch/arm64/net/bpf_jit_comp.c:21:0:
include/linux/bpf.h: In function 'bpf_prog_get':

include/linux/bpf.h:235:9: error: implicit declaration of function 'ERR_PTR' 
[-Werror=implicit-function-declaration]

  return ERR_PTR(-EOPNOTSUPP);
 ^
include/linux/bpf.h:235:9: warning: return makes pointer from integer 
without a cast [-Wint-conversion]
In file included from include/linux/rwsem.h:17:0,
 from include/linux/mm_types.h:10,
 from include/linux/sched.h:27,
 from arch/arm64/include/asm/compat.h:25,
 from arch/arm64/include/asm/stat.h:23,
 from include/linux/stat.h:5,
 from include/linux/compat.h:12,
 from include/linux/filter.h:10,
 from arch/arm64/net/bpf_jit_comp.c:22:
include/linux/err.h: At top level:

include/linux/err.h:23:35: error: conflicting types for 'ERR_PTR'

 static inline void * __must_check ERR_PTR(long error)
   ^
In file included from arch/arm64/net/bpf_jit_comp.c:21:0:
include/linux/bpf.h:235:9: note: previous implicit declaration of 'ERR_PTR' 
was here
  return ERR_PTR(-EOPNOTSUPP);
 ^
cc1: some warnings being treated as errors


Looks like including linux/bpf.h at the very beginning causes issues when bpf
syscall is disabled. We should probably just include linux/err.h from bpf.h.

Re: [PATCH net] bridge: Fix incorrect re-injection of STP packets

[Ido Schimmel]

Hi Florian,

Fri, Jun 03, 2016 at 12:39:45PM IDT, ido...@mellanox.com wrote:
>Commit 8626c56c8279 ("bridge: fix potential use-after-free when hook
>returns QUEUE or STOLEN verdict") fixed incorrect usage of NF_HOOK's
>return value by consuming packets in okfn via br_pass_frame_up().
>
>However, this function re-injects packets to the Rx path with skb->dev
>set to the bridge device, which breaks kernel's STP, as all STP packets
>appear to originate from the bridge device itself.
>
>Instead, if okfn was called for a packet, make bridge's rx_handler
>re-inject it to the Rx path by returning RX_HANDLER_PASS. This is
>consistent with previous behavior.
>
>Cc: Florian Westphal 
>Fixes: 8626c56c8279 ("bridge: fix potential use-after-free when hook returns 
>QUEUE or STOLEN verdict")
>Reviewed-by: Jiri Pirko 
>Signed-off-by: Ido Schimmel 

I read your commit more closely and also looked at nf_reinject() and I'm
not sure how the fix should be carried out.

After packet is processed by okfn it should return to the Rx path -
by making bridge's rx_handler return RX_HANDLER_PASS - so that it 
could be picked up by the packet handlers.

However, if verdict is NF_QUEUE and packet is later re-injected via
nf_reinject() then this can't happen, as rx_handler already returned
RX_HANDLER_CONSUMED for the packet.

So, my patch is wrong because it doesn't consume the packet in okfn, but
yours consumes it in a way which breaks current packet handlers.

Any suggestions regarding a fix? I have a feeling I'm missing something
obvious.

Thanks!

Re: [PATCH 01/12] net: mediatek: fix DQL support

[David Miller]

From: John Crispin 
Date: Sun,  5 Jun 2016 08:32:54 +0200

> @@ -625,7 +625,16 @@ static int mtk_tx_map(struct sk_buff *skb, struct 
> net_device *dev,
>   WRITE_ONCE(itxd->txd3, (TX_DMA_SWC | TX_DMA_PLEN0(skb_headlen(skb)) |
>   (!nr_frags * TX_DMA_LS0)));
>  
> - netdev_sent_queue(dev, skb->len);
> + /* we have a single DMA ring so BQL needs to be updated for all devices
> +  * sitting on this ring
> +  */
> + for (i = 0; i < MTK_MAC_COUNT; i++) {
> + if (!eth->netdev[i])
> + continue;
> +
> + netdev_sent_queue(eth->netdev[i], skb->len);
> + }
> +
>   skb_tx_timestamp(skb);

Sorry, this is very far from working.

You cannot asynchronously touch the DQL state of another netdevice.

You have to hold the TX lock of a queue while changing it's DQL state,
otherwise you'll corrupt the state.

This "loop over all possible devices on this DMA ring" is pretty
expensive for the problem you're trying to solve.

You'll have to find another way to fix this bug, which BTW I'm not too
clear about.  The commit message doesn't explain sufficiently what the
actual problem is.  "not deterministic" doesn't give enough details.

[PATCH] staging: r8188eu: Fix crash caused by commit 99aded71b52c

[Larry Finger]

Commit 99aded71b52cfdfa22721c42e42efdd13a02f0a6 ("Staging: drivers: rtl8188eu:
use sizeof(*ptr) instead of sizeof(struct)") introduces an error in that the
sizeof(struct hal_data_8188e) is 18712, while the sizeof(*adapt->HalData) is
only 1! As a result, the system panics.

Fixes: 99aded71b52cfdfa22721c42e42efdd13a02f0a6 ("Staging: drivers: rtl8188eu: 
use sizeof(*ptr) instead of sizeof(struct)")
Signed-off-by: Larry Finger 
Cc: Jacky Boen 
---
 drivers/staging/rtl8188eu/hal/usb_halinit.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8188eu/hal/usb_halinit.c 
b/drivers/staging/rtl8188eu/hal/usb_halinit.c
index 87ea3b8..363f3a3 100644
--- a/drivers/staging/rtl8188eu/hal/usb_halinit.c
+++ b/drivers/staging/rtl8188eu/hal/usb_halinit.c
@@ -2072,7 +2072,8 @@ void rtl8188eu_set_hal_ops(struct adapter *adapt)
 {
struct hal_ops  *halfunc = >HalFunc;
 
-   adapt->HalData = kzalloc(sizeof(*adapt->HalData), GFP_KERNEL);
+
+   adapt->HalData = kzalloc(sizeof(struct hal_data_8188e), GFP_KERNEL);
if (!adapt->HalData)
DBG_88E("cant not alloc memory for HAL DATA\n");
 
-- 
2.1.4

[PATCH 10/12] net: mediatek: fix off by one in the TX ring allocation

[John Crispin]

The TX ring setup has an off by one error causing it to not utilise all
descriptors. This has the side effect that we need to reset the next
pointer at runtime to make it work. Fix the off by one and remove the
code fixing the ring at runtime.

Signed-off-by: John Crispin 
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 24714ab..6daf48b 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -903,7 +903,6 @@ static int mtk_poll_tx(struct mtk_eth *eth, int budget, 
bool *tx_again)
}
mtk_tx_unmap(eth->dev, tx_buf);
 
-   ring->last_free->txd2 = next_cpu;
ring->last_free = desc;
atomic_inc(>free_count);
 
@@ -1011,7 +1010,7 @@ static int mtk_tx_alloc(struct mtk_eth *eth)
 
atomic_set(>free_count, MTK_DMA_SIZE - 2);
ring->next_free = >dma[0];
-   ring->last_free = >dma[MTK_DMA_SIZE - 2];
+   ring->last_free = >dma[MTK_DMA_SIZE - 1];
ring->thresh = MAX_SKB_FRAGS;
 
/* make sure that all changes to the dma ring are flushed before we
-- 
1.7.10.4

[PATCH 11/12] net: mediatek: only wake the queue if it is stopped

[John Crispin]

The current code unconditionally wakes up the queue at the end of each
tx_poll action. Change the code to only wake up the queues if any of
them have actually been stopped before.

Signed-off-by: John Crispin 
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c |   17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 6daf48b..40d3cfd 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -685,6 +685,20 @@ static inline int mtk_cal_txd_req(struct sk_buff *skb)
return nfrags;
 }
 
+static int mtk_queue_stopped(struct mtk_eth *eth)
+{
+   int i;
+
+   for (i = 0; i < MTK_MAC_COUNT; i++) {
+   if (!eth->netdev[i])
+   continue;
+   if (netif_queue_stopped(eth->netdev[i]))
+   return 1;
+   }
+
+   return 0;
+}
+
 static void mtk_wake_queue(struct mtk_eth *eth)
 {
int i;
@@ -929,7 +943,8 @@ static int mtk_poll_tx(struct mtk_eth *eth, int budget, 
bool *tx_again)
if (!total)
return 0;
 
-   if (atomic_read(>free_count) > ring->thresh)
+   if (mtk_queue_stopped(eth) &&
+   (atomic_read(>free_count) > ring->thresh))
mtk_wake_queue(eth);
 
return total;
-- 
1.7.10.4

[PATCH 12/12] net: mediatek: remove superfluous queue wake up call

[John Crispin]

The code checks if the queue should be stopped because we are below the
threshold of free descriptors only to check if it should be started again.
If we do end up in a state where we are at the threshold limit, it makes
more sense to just stop the queue and wait for the next IRQ to trigger the
TX housekeeping again. There is no rush in enqueuing the next packet, it
needs to wait for all the others in the queue to be dispatched first
anyway.

Signed-off-by: John Crispin 
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c |7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 40d3cfd..ebfca7d 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -764,12 +764,9 @@ static int mtk_start_xmit(struct sk_buff *skb, struct 
net_device *dev)
if (mtk_tx_map(skb, dev, tx_num, ring, gso) < 0)
goto drop;
 
-   if (unlikely(atomic_read(>free_count) <= ring->thresh)) {
+   if (unlikely(atomic_read(>free_count) <= ring->thresh))
mtk_stop_queue(eth);
-   if (unlikely(atomic_read(>free_count) >
-ring->thresh))
-   mtk_wake_queue(eth);
-   }
+
spin_unlock_irqrestore(>page_lock, flags);
 
return NETDEV_TX_OK;
-- 
1.7.10.4

Re: [PATCH] net: fec: fix spelling mistake "coalesed" -> "coalesced"

[Joe Perches]

On Sat, 2016-06-04 at 16:43 -0300, Augusto Mecking Caringi wrote:
> On Sat, Jun 4, 2016 at 4:01 PM, Colin King  wrote:
> > From: Colin Ian King 
> > trivial fix to spelling mistake in pr_err message
[]
> > diff --git a/drivers/net/ethernet/freescale/fec_main.c 
> > b/drivers/net/ethernet/freescale/fec_main.c
[]
> > @@ -2427,13 +2427,13 @@ fec_enet_set_coalesce(struct net_device *ndev, 
> > struct ethtool_coalesce *ec)
> > 
> > cycle = fec_enet_us_to_itr_clock(ndev, fep->rx_time_itr);
> > if (cycle > 0x) {
> > -   pr_err("Rx coalesed usec exceeed hardware limiation");
> > +   pr_err("Rx coalesced usec exceeed hardware limiation");
> > return -EINVAL;
> > }
> > 
> > cycle = fec_enet_us_to_itr_clock(ndev, fep->tx_time_itr);
> > if (cycle > 0x) {
> > -   pr_err("Rx coalesed usec exceeed hardware limiation");
> > +   pr_err("Rx coalesced usec exceeed hardware limiation");
> > return -EINVAL;
> > }
> > 
> s/limiation/limitation

Could also add \n terminations to the pr_err uses.

[PATCH 09/12] net: mediatek: increase watchdog_timeo

[John Crispin]

During stress testing, after reducing the threshold value, we have seen
TX timeouts that were caused by the watchdog_timeo value being too low.
Increase the value to 5 * HZ which is a value commonly used by many other
drivers.

Signed-off-by: John Crispin 
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 8b289e1..24714ab 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -1688,7 +1688,7 @@ static int mtk_add_mac(struct mtk_eth *eth, struct 
device_node *np)
mac->hw_stats->reg_offset = id * MTK_STAT_OFFSET;
 
SET_NETDEV_DEV(eth->netdev[id], eth->dev);
-   eth->netdev[id]->watchdog_timeo = HZ;
+   eth->netdev[id]->watchdog_timeo = 5 * HZ;
eth->netdev[id]->netdev_ops = _netdev_ops;
eth->netdev[id]->base_addr = (unsigned long)eth->base;
eth->netdev[id]->vlan_features = MTK_HW_FEATURES &
-- 
1.7.10.4

[PATCH 03/12] net: mediatek: fix missing free of scratch memory

[John Crispin]

Scratch memory gets allocated in mtk_init_fq_dma() but the corresponding
code to free it is missing inside mtk_dma_free() causing a memory leak.
With this patch applied, we can run ifconfig up/down several thousand
times without any problems.

Signed-off-by: John Crispin 
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c |   18 +-
 drivers/net/ethernet/mediatek/mtk_eth_soc.h |2 ++
 2 files changed, 15 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 6780886..8d79bbf 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -453,14 +453,14 @@ static inline void mtk_rx_get_desc(struct mtk_rx_dma *rxd,
 /* the qdma core needs scratch memory to be setup */
 static int mtk_init_fq_dma(struct mtk_eth *eth)
 {
-   dma_addr_t phy_ring_head, phy_ring_tail;
+   dma_addr_t phy_ring_tail;
int cnt = MTK_DMA_SIZE;
dma_addr_t dma_addr;
int i;
 
eth->scratch_ring = dma_alloc_coherent(eth->dev,
   cnt * sizeof(struct mtk_tx_dma),
-  _ring_head,
+  >phy_scratch_ring,
   GFP_ATOMIC | __GFP_ZERO);
if (unlikely(!eth->scratch_ring))
return -ENOMEM;
@@ -477,19 +477,19 @@ static int mtk_init_fq_dma(struct mtk_eth *eth)
return -ENOMEM;
 
memset(eth->scratch_ring, 0x0, sizeof(struct mtk_tx_dma) * cnt);
-   phy_ring_tail = phy_ring_head +
+   phy_ring_tail = eth->phy_scratch_ring +
(sizeof(struct mtk_tx_dma) * (cnt - 1));
 
for (i = 0; i < cnt; i++) {
eth->scratch_ring[i].txd1 =
(dma_addr + (i * MTK_QDMA_PAGE_SIZE));
if (i < cnt - 1)
-   eth->scratch_ring[i].txd2 = (phy_ring_head +
+   eth->scratch_ring[i].txd2 = (eth->phy_scratch_ring +
((i + 1) * sizeof(struct mtk_tx_dma)));
eth->scratch_ring[i].txd3 = TX_DMA_SDL(MTK_QDMA_PAGE_SIZE);
}
 
-   mtk_w32(eth, phy_ring_head, MTK_QDMA_FQ_HEAD);
+   mtk_w32(eth, eth->phy_scratch_ring, MTK_QDMA_FQ_HEAD);
mtk_w32(eth, phy_ring_tail, MTK_QDMA_FQ_TAIL);
mtk_w32(eth, (cnt << 16) | cnt, MTK_QDMA_FQ_CNT);
mtk_w32(eth, MTK_QDMA_PAGE_SIZE << 16, MTK_QDMA_FQ_BLEN);
@@ -1189,6 +1189,14 @@ static void mtk_dma_free(struct mtk_eth *eth)
for (i = 0; i < MTK_MAC_COUNT; i++)
if (eth->netdev[i])
netdev_reset_queue(eth->netdev[i]);
+   if (eth->scratch_ring) {
+   dma_free_coherent(eth->dev,
+ MTK_DMA_SIZE * sizeof(struct mtk_tx_dma),
+ eth->scratch_ring,
+ eth->phy_scratch_ring);
+   eth->scratch_ring = NULL;
+   eth->phy_scratch_ring = 0;
+   }
mtk_tx_clean(eth);
mtk_rx_clean(eth);
kfree(eth->scratch_head);
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.h 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
index eed626d..57f7e8a 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
@@ -357,6 +357,7 @@ struct mtk_rx_ring {
  * @rx_ring:   Pointer to the memore holding info about the RX ring
  * @rx_napi:   The NAPI struct
  * @scratch_ring:  Newer SoCs need memory for a second HW managed TX ring
+ * @phy_scratch_ring:  physical address of scratch_ring
  * @scratch_head:  The scratch memory that scratch_ring points to.
  * @clk_ethif: The ethif clock
  * @clk_esw:   The switch clock
@@ -384,6 +385,7 @@ struct mtk_eth {
struct mtk_rx_ring  rx_ring;
struct napi_struct  rx_napi;
struct mtk_tx_dma   *scratch_ring;
+   dma_addr_t  phy_scratch_ring;
void*scratch_head;
struct clk  *clk_ethif;
struct clk  *clk_esw;
-- 
1.7.10.4

[PATCH 08/12] net: mediatek: fix threshold value

[John Crispin]

The logic to calculate the threshold value for stopping the TX queue is
bad. Currently it will always use 1/2 of the rings size, which is way too
much. Set the threshold to MAX_SKB_FRAGS. This makes sure that the queue
is stopped when there is not enough room to accept an additional segment. 

Signed-off-by: John Crispin 
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 93af4e3..8b289e1 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -1012,8 +1012,7 @@ static int mtk_tx_alloc(struct mtk_eth *eth)
atomic_set(>free_count, MTK_DMA_SIZE - 2);
ring->next_free = >dma[0];
ring->last_free = >dma[MTK_DMA_SIZE - 2];
-   ring->thresh = max((unsigned long)MTK_DMA_SIZE >> 2,
- MAX_SKB_FRAGS);
+   ring->thresh = MAX_SKB_FRAGS;
 
/* make sure that all changes to the dma ring are flushed before we
 * continue
-- 
1.7.10.4

[PATCH 05/12] net: mediatek: dropped rx packets are not being counted properly

[John Crispin]

There are two places inside mtk_poll_rx where rx_dropped is not being
incremented properly. Fix this by adding the missing code to increment
the counter.

Signed-off-by: John Crispin 
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 4f22ee9..0610262 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -810,6 +810,7 @@ static int mtk_poll_rx(struct napi_struct *napi, int budget,
  DMA_FROM_DEVICE);
if (unlikely(dma_mapping_error(>dev, dma_addr))) {
skb_free_frag(new_data);
+   netdev->stats.rx_dropped++;
goto release_desc;
}
 
@@ -817,6 +818,7 @@ static int mtk_poll_rx(struct napi_struct *napi, int budget,
skb = build_skb(data, ring->frag_size);
if (unlikely(!skb)) {
put_page(virt_to_head_page(new_data));
+   netdev->stats.rx_dropped++;
goto release_desc;
}
skb_reserve(skb, NET_SKB_PAD + NET_IP_ALIGN);
-- 
1.7.10.4

[PATCH 07/12] net: mediatek: disable all interrupts during probe

[John Crispin]

The current code only disables those IRQs that we will later use. To
ensure that we have a predefined state, we really want to disable all IRQs.
Change the code to disable all IRQs to achieve this.

Signed-off-by: John Crispin 
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index bfac376..93af4e3 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -1375,7 +1375,7 @@ static int __init mtk_hw_init(struct mtk_eth *eth)
 
/* disable delay and normal interrupt */
mtk_w32(eth, 0, MTK_QDMA_DELAY_INT);
-   mtk_irq_disable(eth, MTK_TX_DONE_INT | MTK_RX_DONE_INT);
+   mtk_irq_disable(eth, ~0);
mtk_w32(eth, RST_GL_PSE, MTK_RST_GL);
mtk_w32(eth, 0, MTK_RST_GL);
 
-- 
1.7.10.4

[PATCH 06/12] net: mediatek: add next data pointer coherency protection

[John Crispin]

The QDMA engine can fail to update the register pointing to the next TX
descriptor if this bit does not get set in the QDMA configuration register.
Not setting this bit can result in invalid values inside the TX rings
registers which will causes TX stalls.

Signed-off-by: John Crispin 
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c |2 +-
 drivers/net/ethernet/mediatek/mtk_eth_soc.h |1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 0610262..bfac376 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -1261,7 +1261,7 @@ static int mtk_start_dma(struct mtk_eth *eth)
mtk_w32(eth,
MTK_TX_WB_DDONE | MTK_RX_DMA_EN | MTK_TX_DMA_EN |
MTK_RX_2B_OFFSET | MTK_DMA_SIZE_16DWORDS |
-   MTK_RX_BT_32DWORDS,
+   MTK_RX_BT_32DWORDS | MTK_NDP_CO_PRO,
MTK_QDMA_GLO_CFG);
 
return 0;
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.h 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
index 57f7e8a..a5eb7c6 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
@@ -91,6 +91,7 @@
 #define MTK_QDMA_GLO_CFG   0x1A04
 #define MTK_RX_2B_OFFSET   BIT(31)
 #define MTK_RX_BT_32DWORDS (3 << 11)
+#define MTK_NDP_CO_PRO BIT(10)
 #define MTK_TX_WB_DDONEBIT(6)
 #define MTK_DMA_SIZE_16DWORDS  (2 << 4)
 #define MTK_RX_DMA_BUSYBIT(3)
-- 
1.7.10.4

[PATCH 00/12] net: mediatek: various small fixes

[John Crispin]

This series contains various small fixes that we stumbled across while
doing thorough testing and code level reviewing of the driver. The only
patch that sticks out is the first one, which addresses a DQL related
issue. The rest are just minor fixes.

John Crispin (12):
  net: mediatek: fix DQL support
  net: mediatek: add missing return code check
  net: mediatek: fix missing free of scratch memory
  net: mediatek: invalid buffer lookup in mtk_tx_map()
  net: mediatek: dropped rx packets are not being counted properly
  net: mediatek: add next data pointer coherency protection
  net: mediatek: disable all interrupts during probe
  net: mediatek: fix threshold value
  net: mediatek: increase watchdog_timeo
  net: mediatek: fix off by one in the TX ring allocation
  net: mediatek: only wake the queue if it is stopped
  net: mediatek: remove superfluous queue wake up call

 drivers/net/ethernet/mediatek/mtk_eth_soc.c |   94 ++-
 drivers/net/ethernet/mediatek/mtk_eth_soc.h |3 +
 2 files changed, 65 insertions(+), 32 deletions(-)

-- 
1.7.10.4

[PATCH 04/12] net: mediatek: invalid buffer lookup in mtk_tx_map()

[John Crispin]

The lookup of the tx_buffer in the error path inside mtk_tx_map() uses the
wrong descriptor pointer. This looks like a copy & paste error. Change the
code to use the correct pointer.

Signed-off-by: John Crispin 
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 8d79bbf..4f22ee9 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -655,7 +655,7 @@ static int mtk_tx_map(struct sk_buff *skb, struct 
net_device *dev,
 
 err_dma:
do {
-   tx_buf = mtk_desc_to_tx_buf(ring, txd);
+   tx_buf = mtk_desc_to_tx_buf(ring, itxd);
 
/* unmap dma */
mtk_tx_unmap(>dev, tx_buf);
-- 
1.7.10.4

[PATCH 02/12] net: mediatek: add missing return code check

[John Crispin]

The code fails to check if the scratch memory was properly allocated. Add
this check and return with an error if the allocation failed.

Signed-off-by: John Crispin 
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 45f8dbf..6780886 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -467,6 +467,9 @@ static int mtk_init_fq_dma(struct mtk_eth *eth)
 
eth->scratch_head = kcalloc(cnt, MTK_QDMA_PAGE_SIZE,
GFP_KERNEL);
+   if (unlikely(!eth->scratch_head))
+   return -ENOMEM;
+
dma_addr = dma_map_single(eth->dev,
  eth->scratch_head, cnt * MTK_QDMA_PAGE_SIZE,
  DMA_FROM_DEVICE);
-- 
1.7.10.4

[PATCH 01/12] net: mediatek: fix DQL support

[John Crispin]

The MTK ethernet core has 2 MACs both sitting on the same DMA ring. For
DQL to be deterministic it needs to track the amount of data in the DMA
ring and not the amount of data enqueued on each device. The current code
is incorrect, fix it by making it each device track its own traffic aswell
as the traffic of the other device.

Signed-off-by: John Crispin 
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c |   33 ---
 1 file changed, 20 insertions(+), 13 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index c984462..45f8dbf 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -625,7 +625,16 @@ static int mtk_tx_map(struct sk_buff *skb, struct 
net_device *dev,
WRITE_ONCE(itxd->txd3, (TX_DMA_SWC | TX_DMA_PLEN0(skb_headlen(skb)) |
(!nr_frags * TX_DMA_LS0)));
 
-   netdev_sent_queue(dev, skb->len);
+   /* we have a single DMA ring so BQL needs to be updated for all devices
+* sitting on this ring
+*/
+   for (i = 0; i < MTK_MAC_COUNT; i++) {
+   if (!eth->netdev[i])
+   continue;
+
+   netdev_sent_queue(eth->netdev[i], skb->len);
+   }
+
skb_tx_timestamp(skb);
 
ring->next_free = mtk_qdma_phys_to_virt(ring, txd->txd2);
@@ -853,21 +862,18 @@ static int mtk_poll_tx(struct mtk_eth *eth, int budget, 
bool *tx_again)
struct mtk_tx_dma *desc;
struct sk_buff *skb;
struct mtk_tx_buf *tx_buf;
-   int total = 0, done[MTK_MAX_DEVS];
-   unsigned int bytes[MTK_MAX_DEVS];
+   int total = 0, done = 0;
+   unsigned int bytes = 0;
u32 cpu, dma;
static int condition;
int i;
 
-   memset(done, 0, sizeof(done));
-   memset(bytes, 0, sizeof(bytes));
-
cpu = mtk_r32(eth, MTK_QTX_CRX_PTR);
dma = mtk_r32(eth, MTK_QTX_DRX_PTR);
 
desc = mtk_qdma_phys_to_virt(ring, cpu);
 
-   while ((cpu != dma) && budget) {
+   while ((cpu != dma) && done < budget) {
u32 next_cpu = desc->txd2;
int mac;
 
@@ -887,9 +893,8 @@ static int mtk_poll_tx(struct mtk_eth *eth, int budget, 
bool *tx_again)
}
 
if (skb != (struct sk_buff *)MTK_DMA_DUMMY_DESC) {
-   bytes[mac] += skb->len;
-   done[mac]++;
-   budget--;
+   bytes += skb->len;
+   done++;
}
mtk_tx_unmap(eth->dev, tx_buf);
 
@@ -902,11 +907,13 @@ static int mtk_poll_tx(struct mtk_eth *eth, int budget, 
bool *tx_again)
 
mtk_w32(eth, cpu, MTK_QTX_CRX_PTR);
 
+   /* we have a single DMA ring so BQL needs to be updated for all devices
+* sitting on this ring
+*/
for (i = 0; i < MTK_MAC_COUNT; i++) {
-   if (!eth->netdev[i] || !done[i])
+   if (!eth->netdev[i])
continue;
-   netdev_completed_queue(eth->netdev[i], done[i], bytes[i]);
-   total += done[i];
+   netdev_completed_queue(eth->netdev[i], done, bytes);
}
 
/* read hw index again make sure no new tx packet */
-- 
1.7.10.4