Re: [PATCH net] net: bcmgenet: device stats are unsigned long

2016-04-16 Thread David Miller
From: Eric Dumazet 
Date: Fri, 15 Apr 2016 10:47:52 -0700

> From: Eric Dumazet 
> 
> On 64bit kernels, device stats are 64bit wide, not 32bit.
> 
> Fixes: 1c1008c793fa4 ("net: bcmgenet: add main driver file")
> Signed-off-by: Eric Dumazet 
> Cc: Florian Fainelli 

Applied, thanks Eric.


Re: [PATCH net-next 0/2] Minor IFF_NO_QUEUE conversion follow-up

2016-04-16 Thread David Miller
From: Phil Sutter 
Date: Fri, 15 Apr 2016 19:14:18 +0200

> The following series converts two further drivers away from setting
> 'tx_queue_len = 0' to adding IFF_NO_QUEUE to priv_flags instead.
> 
> The first one, rtl8188eu in staging didn't exist back when all drivers
> were converted. The second one, openvswitch seems to have slipped through
> my grep'ing back then, no idea why.

Series applied, thanks Phil.


Re: [PATCH net-next v2 0/6] FUJITSU Extended Socket driver version 1.1

2016-04-16 Thread David Miller
From: Taku Izumi 
Date: Fri, 15 Apr 2016 11:20:00 +0900

> This patchsets update FUJITSU Extended Socket network driver into version 1.1.
> This mainly includes some improvements and minor bugfix.
> 
> v1->v2:
>   - Remove ioctl and debugfs facility according to David comment

Series applied.


Re: [PATCH net-next v3 1/2] rtnetlink: add new RTM_GETSTATS message to query stats

2016-04-16 Thread roopa
On 4/16/16, 12:49 AM, Thomas Graf wrote:
> On 04/15/16 at 08:28pm, Roopa Prabhu wrote:
>> +static u16 rtnl_stats_calcit(struct sk_buff *skb, struct nlmsghdr *nlh)
>> +{
>> +struct net *net = sock_net(skb->sk);
>> +struct net_device *dev;
>> +u16 min_ifinfo_dump_size = 0;
>> +struct if_stats_msg *ifsm;
>> +u32 filter_mask;
>> +
>> +ifsm = nlmsg_data(nlh);
>> +filter_mask = ifsm->filter_mask;
>> +
>> +/* traverse the list of net devices and compute the minimum
>> + * buffer size based upon the filter mask.
>> + */
>> +list_for_each_entry(dev, >dev_base_head, dev_list) {
>> +min_ifinfo_dump_size = max_t(u16, min_ifinfo_dump_size,
>> + if_nlmsg_stats_size(dev,
>> + filter_mask));
>> +}
> Iterating over all net_devices in the namespace is quite an expensive
> operation and it would now be done twice.
>
> I understand that this code is taken over from rtnl_calcit() but there
> the cost is at least only paid if ext_filter_mask is actually set and
> the user opts into additional statistics.
>
> I wonder if we can reduce the cost for the stats interface as its
> purpose is to be minimal cost. I suggest we only add the loop once we
> have an extension which actually depends on it. We can then try and
> figure out to not require it.
ok, ack. Its not absolutely necessary right now with the one link filter stats
I am adding support for. We can bring it back later when we see a first instance
 which makes it necessary.

In which case, I am going to trim down the series to absolute minimal.
just rtnl link stats64. I want to drop the ipv6 patch anyways.
With it I will also drop the general af stats handling. Will get it back when 
we get to the first
proper af stats implementation (hopefully mpls).

With this, the calcit for RTM_GETSTATS will be NULL, until we add the 
implementation for the other
stats attributes.


Re: [net-next PATCH] stmmac: socfpga: remove extra call to socfpga_dwmac_setup

2016-04-16 Thread David Miller
From: 
Date: Thu, 14 Apr 2016 20:42:29 -0500

> From: Dinh Nguyen 
> 
> In the socfpga_dwmac_probe function, we have a call to socfpga_dwmac_setup,
> which is already called from socfpga_dwmac_init later in the probe function.
> Remove this extra call to socfpga_dwmac_setup.
> 
> Also we should not be calling socfpga_dwmac_setup() directly without wrapping
> it around the proper reset assert/deasserts. That is because the
> socfpga_dwmac_setup() is setting up PHY modes in the system manager, and it
> is requires the EMAC's to be in reset during the PHY setup.
> 
> Reported-by: Matthew Gerlach 
> Signed-off-by: Dinh Nguyen 

Applied, thank you.


Re: [PATCH] bpf: avoid warning for wrong pointer cast

2016-04-16 Thread Alexei Starovoitov
On Sat, Apr 16, 2016 at 10:29:33PM +0200, Arnd Bergmann wrote:
> Two new functions in bpf contain a cast from a 'u64' to a
> pointer. This works on 64-bit architectures but causes a warning
> on all 32-bit architectures:
> 
> kernel/trace/bpf_trace.c: In function 'bpf_perf_event_output_tp':
> kernel/trace/bpf_trace.c:350:13: error: cast to pointer from integer of 
> different size [-Werror=int-to-pointer-cast]
>   u64 ctx = *(long *)r1;
> 
> This changes the cast to first convert the u64 argument into a uintptr_t,
> which is guaranteed to be the same size as a pointer.
> 
> Signed-off-by: Arnd Bergmann 
> Fixes: 9940d67c93b5 ("bpf: support bpf_get_stackid() and 
> bpf_perf_event_output() in tracepoint programs")

Thanks.
Acked-by: Alexei Starovoitov 

I guess I started to rely on 0-day build-bot too much.
This patch has been in my tree for 2+ weeks and then in net-next and
I didn't receive a single email from build-bot about this warning,
though I do receive them for my other work-in-progress stuff. Odd.
Fengguang, any idea why build-bot sometimes silent?



Re: [Odd commit author id merge via netdev]

2016-04-16 Thread santosh shilimkar

On 4/1/2016 3:15 PM, santosh shilimkar wrote:

On 4/1/2016 1:01 PM, Johannes Berg wrote:

On Fri, 2016-04-01 at 10:51 -0700, santosh shilimkar wrote:

Hi Dave,

I noticed something odd while checking the recent
commits of mine in kernel.org tree made it via netdev.

Don't know if its patchwork tool doing this.
Usual author line in my git objects:
Author: Santosh Shilimkar 

But the commits going via your tree seems to be like below..
Author: email-id 

Few more examples of the commits end of the email. Can this
be fixed for future commits ? The git objects you pulled from
my tree directly have right author format where as ones which
are picked from patchworks seems to be odd.



Patchwork does store this info somehow and re-use it, quite possibly
from the very first patch you ever sent. I think this bug was *just*
fixed in patchwork, but it'll probably be a while until that fix lands.

However, you can go and create a patchwork account with the real name,
associate it with all the email addresses you use and then I think
it'll pick it up. Not entirely sure though, you'll have to test it.


Thought of letting you know that creating username didn't
seems to help. I did create a patchwork account and associated
the email ids I use for commits after last email exchange.

Now it got tested with Dave's 'net' tree commits indirectly.
The patchwork commit format still seems to be
"Author: email-id " irrespective of patchwork user
name for me.

Regards,
Santosh







Re: [net][PATCH v2 0/2] RDS: couple of fixes for 4.6

2016-04-16 Thread santosh shilimkar

On 4/16/2016 3:53 PM, David Miller wrote:

From: Santosh Shilimkar 
Date: Thu, 14 Apr 2016 10:43:25 -0700


   git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git 
for_4.6/net/rds-fixes


I have no idea how you set this up, but there is no WAY this can be
pulled from by me.


Thought I did based it against 'net' after your last comment.
Just checked again and the 'net' remote added by me points
to wrong url(net-next).


When I try to pull it into 'net' I get 2690 objects.  That means you
didn't base it upon the 'net' tree which you must do.  You can't base
it upon Linus's tree, because if you do I'll get a ton of changes that
are absolutely not appropriate to be pulled into my 'net' tree.

Are you always doing this?  Working against Linus's tree instead of
mine?


No, its not Linus's tree. Its yours but not the right one.
Sorry for the trouble. Won't happen again.

Thanks for picking up the matches from patchworks.

Regards,
Santosh


Re: [PATCH v3] prism54: isl_38xx: Replace 'struct timeval'

2016-04-16 Thread Arnd Bergmann
On Wednesday 13 April 2016 10:38:26 Johannes Berg wrote:
> > The patch was build-tested / debugged by removing the
> > "if VERBOSE > SHOW_ERROR_MESSAGES" guards.
> 
> Stands to reason that we should just remove the (more or less) dead
> code, since I don't think anyone really ever touches this driver any
> more or will ever again ...

Do you mean removing all DEBUG() statements from the driver, or
removing the entire driver?

Arnd


Re: [PATCH] dsa: mv88e6xxx: Kill the REG_READ and REG_WRITE macros

2016-04-16 Thread David Miller
From: Andrew Lunn 
Date: Thu, 14 Apr 2016 23:47:12 +0200

> These macros hide a ds variable and a return statement on error, which
> can lead to locking issues. Kill them off.
> 
> Signed-off-by: Andrew Lunn 

Applied, thanks Andrew.


Re: [net-next PATCH] netdev_features: Add NETIF_F_TSO_MANGLEID to NETIF_F_ALL_TSO

2016-04-16 Thread David Miller
From: Alexander Duyck 
Date: Thu, 14 Apr 2016 17:04:34 -0400

> I realized that when I added NETIF_F_TSO_MANGLEID as a TSO type I forgot to
> add it to NETIF_F_ALL_TSO.  This patch corrects that so the flag will be
> included correctly.
> 
> The result should be minor as it was only used by a few drivers and in a
> few specific cases such as when NETIF_F_SG was not supported on a device so
> the TSO flags were cleared.
> 
> Signed-off-by: Alexander Duyck 

Applied.


Re: [net-next PATCH 0/5] Add support for offloads with IPv6 GRE tunnels

2016-04-16 Thread David Miller
From: Alexander Duyck 
Date: Thu, 14 Apr 2016 15:33:30 -0400

> This patch series enables the use of segmentation and checksum
> offloads with IPv6 based GRE tunnels.

Series applied, nice work Alex.


Re: [PATCH net 0/3] net: dsa: mv88e6xxx: fix hardware cross-chip bridging

2016-04-16 Thread David Miller
From: Vivien Didelot 
Date: Thu, 14 Apr 2016 14:42:06 -0400

> In order to accelerate cross-chip switching of frames with the hardware,
> the DSA Tag ports, used to interconnect switch devices, must learn SA
> and DA addresses, and share the same FDB with the user ports.
> 
> The two first patches restore address learning on DSA links. This fixes
> hardware cross-chip bridging in a VLAN filtering enabled system, which
> implements a bridge group as a 802.1Q VLAN and thus share an isolated
> address database between DSA and user ports.
> 
> The third patch changes the distinct default databases used for each
> port, to the same address database. This fixes the hardware cross-chip
> bridging in a VLAN filtering disabled system, where a bridge group gets
> implemented only as a port-based VLAN.

Series applied, thanks.


Re: [net][PATCH v2 2/2] RDS: Fix the atomicity for congestion map update

2016-04-16 Thread David Miller
From: Santosh Shilimkar 
Date: Thu, 14 Apr 2016 10:43:27 -0700

> Two different threads with different rds sockets may be in
> rds_recv_rcvbuf_delta() via receive path. If their ports
> both map to the same word in the congestion map, then
> using non-atomic ops to update it could cause the map to
> be incorrect. Lets use atomics to avoid such an issue.
> 
> Full credit to Wengang  for
> finding the issue, analysing it and also pointing out
> to offending code with spin lock based fix.
> 
> Reviewed-by: Leon Romanovsky 
> Signed-off-by: Wengang Wang 
> Signed-off-by: Santosh Shilimkar 

Applied.


Re: [net][PATCH v2 1/2] RDS: fix endianness for dp_ack_seq

2016-04-16 Thread David Miller
From: Santosh Shilimkar 
Date: Thu, 14 Apr 2016 10:43:26 -0700

> From: Qing Huang 
> 
> dp->dp_ack_seq is used in big endian format. We need to do the
> big endianness conversion when we assign a value in host format
> to it.
> 
> Signed-off-by: Qing Huang 
> Signed-off-by: Santosh Shilimkar 

Applied.


Re: [net][PATCH v2 0/2] RDS: couple of fixes for 4.6

2016-04-16 Thread David Miller
From: Santosh Shilimkar 
Date: Thu, 14 Apr 2016 10:43:25 -0700

>   git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git 
> for_4.6/net/rds-fixes

I have no idea how you set this up, but there is no WAY this can be
pulled from by me.

When I try to pull it into 'net' I get 2690 objects.  That means you
didn't base it upon the 'net' tree which you must do.  You can't base
it upon Linus's tree, because if you do I'll get a ton of changes that
are absolutely not appropriate to be pulled into my 'net' tree.

Are you always doing this?  Working against Linus's tree instead of
mine?


Re: [PATCH] ipv6: allow bypassing cross-intf routing limits

2016-04-16 Thread David Miller
From: Michal Kazior 
Date: Thu, 14 Apr 2016 14:46:28 +0200

> There are some use-cases to allow link-local
> routing for bridging purposes.
> 
> One of these is allowing transparent 802.11
> bridging. Due to 802.11 framing limitations many
> Access Points make it impossible to create bridges
> on Client endpoints because they can't maintain
> Destination/Source/Transmitter/Receiver address
> distinction with only 3 addresses in frame header.
> 
> The default behavior, i.e. link-local traffic
> being non-routable, remains. The user has to
> explicitly enable the bypass when defining a given
> route.
> 
> Signed-off-by: Michal Kazior 

Sorry, whilst I realize your problem, I'm not going to add what is
explicitly a violation of the way link-local addresses are meant to
work and the very much intentional restrictions the RFCs place upon
them (they MUST not be routed).

I also didn't see any real discussions in response to your original
proposals, not from even one person I know is knowledgable about ipv6
and the implications your change would have, and that is extremely
troubling.

I tried to let your patches sit for several days in order to let that
kind of discussion happen, but it didn't.

So, you'll need to find another way to achieve your goals.


[PATCH net-next v3 3/8] net: dsa: mv88e6xxx: read switch ID in probe

2016-04-16 Thread Vivien Didelot
Read the switch ID only once, at probe time, to avoid multiple read
accesses and MII bus checking.

Signed-off-by: Vivien Didelot 
---
 drivers/net/dsa/mv88e6xxx.c | 54 +
 1 file changed, 30 insertions(+), 24 deletions(-)

diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
index b63e985..af5ae70 100644
--- a/drivers/net/dsa/mv88e6xxx.c
+++ b/drivers/net/dsa/mv88e6xxx.c
@@ -2667,8 +2667,6 @@ int mv88e6xxx_setup_common(struct dsa_switch *ds)
ps->ds = ds;
mutex_init(>smi_mutex);
 
-   ps->id = REG_READ(REG_PORT(0), PORT_SWITCH_ID) & 0xfff0;
-
INIT_WORK(>bridge_work, mv88e6xxx_bridge_work);
 
return 0;
@@ -3068,21 +3066,14 @@ int mv88e6xxx_get_temp_alarm(struct dsa_switch *ds, 
bool *alarm)
 }
 #endif /* CONFIG_NET_DSA_HWMON */
 
-static char *mv88e6xxx_lookup_name(struct mii_bus *bus, int sw_addr,
+static char *mv88e6xxx_lookup_name(unsigned int id,
   const struct mv88e6xxx_switch_id *table,
   unsigned int num)
 {
-   int i, ret;
-
-   if (!bus)
-   return NULL;
-
-   ret = __mv88e6xxx_reg_read(bus, sw_addr, REG_PORT(0), PORT_SWITCH_ID);
-   if (ret < 0)
-   return NULL;
+   int i;
 
for (i = 0; i < num; ++i)
-   if (table[i].id == (ret & 0xfff0))
+   if (table[i].id == (id & 0xfff0))
return table[i].name;
 
return NULL;
@@ -3094,23 +3085,38 @@ char *mv88e6xxx_drv_probe(struct device *dsa_dev, 
struct device *host_dev,
  unsigned int num)
 {
struct mv88e6xxx_priv_state *ps;
-   struct mii_bus *bus = dsa_host_dev_to_mii_bus(host_dev);
+   struct mii_bus *bus;
+   int id, prod_num, rev;
char *name;
 
+   bus = dsa_host_dev_to_mii_bus(host_dev);
if (!bus)
return NULL;
 
-   name = mv88e6xxx_lookup_name(bus, sw_addr, table, num);
-   if (name) {
-   ps = devm_kzalloc(dsa_dev, sizeof(*ps), GFP_KERNEL);
-   if (!ps)
-   return NULL;
-   *priv = ps;
-   ps->bus = dsa_host_dev_to_mii_bus(host_dev);
-   if (!ps->bus)
-   return NULL;
-   ps->sw_addr = sw_addr;
-   }
+   id = __mv88e6xxx_reg_read(bus, sw_addr, REG_PORT(0), PORT_SWITCH_ID);
+   if (id < 0)
+   return NULL;
+
+   prod_num = (id & 0xfff0) >> 4;
+   rev = id & 0x000f;
+
+   name = mv88e6xxx_lookup_name(id, table, num);
+   if (!name)
+   return NULL;
+
+   ps = devm_kzalloc(dsa_dev, sizeof(*ps), GFP_KERNEL);
+   if (!ps)
+   return NULL;
+
+   ps->bus = bus;
+   ps->sw_addr = sw_addr;
+   ps->id = id & 0xfff0;
+
+   *priv = ps;
+
+   dev_info(>bus->dev, "switch 0x%x probed: %s, revision %u\n",
+prod_num, name, rev);
+
return name;
 }
 
-- 
2.8.0



[PATCH net-next v3 1/8] net: dsa: mv88e6xxx: drop double ds assignment

2016-04-16 Thread Vivien Didelot
Every driver assigns ps->ds even though it gets assigned in the shared
mv88e6xxx_setup_common function. Kill redundancy.

Signed-off-by: Vivien Didelot 
Reviewed-by: Andrew Lunn 
---
 drivers/net/dsa/mv88e6123.c | 2 --
 drivers/net/dsa/mv88e6131.c | 2 --
 drivers/net/dsa/mv88e6171.c | 2 --
 drivers/net/dsa/mv88e6352.c | 2 --
 4 files changed, 8 deletions(-)

diff --git a/drivers/net/dsa/mv88e6123.c b/drivers/net/dsa/mv88e6123.c
index c34283d..88a812d 100644
--- a/drivers/net/dsa/mv88e6123.c
+++ b/drivers/net/dsa/mv88e6123.c
@@ -76,8 +76,6 @@ static int mv88e6123_setup(struct dsa_switch *ds)
struct mv88e6xxx_priv_state *ps = ds_to_priv(ds);
int ret;
 
-   ps->ds = ds;
-
ret = mv88e6xxx_setup_common(ds);
if (ret < 0)
return ret;
diff --git a/drivers/net/dsa/mv88e6131.c b/drivers/net/dsa/mv88e6131.c
index f5d75fc..6b2bcb0 100644
--- a/drivers/net/dsa/mv88e6131.c
+++ b/drivers/net/dsa/mv88e6131.c
@@ -94,8 +94,6 @@ static int mv88e6131_setup(struct dsa_switch *ds)
struct mv88e6xxx_priv_state *ps = ds_to_priv(ds);
int ret;
 
-   ps->ds = ds;
-
ret = mv88e6xxx_setup_common(ds);
if (ret < 0)
return ret;
diff --git a/drivers/net/dsa/mv88e6171.c b/drivers/net/dsa/mv88e6171.c
index f562250..40222b0 100644
--- a/drivers/net/dsa/mv88e6171.c
+++ b/drivers/net/dsa/mv88e6171.c
@@ -72,8 +72,6 @@ static int mv88e6171_setup(struct dsa_switch *ds)
struct mv88e6xxx_priv_state *ps = ds_to_priv(ds);
int ret;
 
-   ps->ds = ds;
-
ret = mv88e6xxx_setup_common(ds);
if (ret < 0)
return ret;
diff --git a/drivers/net/dsa/mv88e6352.c b/drivers/net/dsa/mv88e6352.c
index e54ee27..dbd920e 100644
--- a/drivers/net/dsa/mv88e6352.c
+++ b/drivers/net/dsa/mv88e6352.c
@@ -84,8 +84,6 @@ static int mv88e6352_setup(struct dsa_switch *ds)
struct mv88e6xxx_priv_state *ps = ds_to_priv(ds);
int ret;
 
-   ps->ds = ds;
-
ret = mv88e6xxx_setup_common(ds);
if (ret < 0)
return ret;
-- 
2.8.0



[PATCH net-next v3 6/8] net: dsa: mv88e6xxx: add number of ports to info

2016-04-16 Thread Vivien Didelot
Drop the ps->num_ports variable in favor of a new member of the info
structure. This removes the need to assign it at setup time.

Signed-off-by: Vivien Didelot 
Reviewed-by: Andrew Lunn 
---
 drivers/net/dsa/mv88e6123.c | 16 +++-
 drivers/net/dsa/mv88e6131.c | 22 +-
 drivers/net/dsa/mv88e6171.c |  7 ---
 drivers/net/dsa/mv88e6352.c |  8 ++--
 drivers/net/dsa/mv88e6xxx.c | 38 +++---
 drivers/net/dsa/mv88e6xxx.h |  3 +--
 6 files changed, 38 insertions(+), 56 deletions(-)

diff --git a/drivers/net/dsa/mv88e6123.c b/drivers/net/dsa/mv88e6123.c
index 93429d2..e3802b4 100644
--- a/drivers/net/dsa/mv88e6123.c
+++ b/drivers/net/dsa/mv88e6123.c
@@ -22,14 +22,17 @@ static const struct mv88e6xxx_info mv88e6123_table[] = {
.prod_num = PORT_SWITCH_ID_PROD_NUM_6123,
.family = MV88E6XXX_FAMILY_6165,
.name = "Marvell 88E6123",
+   .num_ports = 3,
}, {
.prod_num = PORT_SWITCH_ID_PROD_NUM_6161,
.family = MV88E6XXX_FAMILY_6165,
.name = "Marvell 88E6161",
+   .num_ports = 6,
}, {
.prod_num = PORT_SWITCH_ID_PROD_NUM_6165,
.family = MV88E6XXX_FAMILY_6165,
.name = "Marvell 88E6165",
+   .num_ports = 6,
}
 };
 
@@ -77,25 +80,12 @@ static int mv88e6123_setup_global(struct dsa_switch *ds)
 
 static int mv88e6123_setup(struct dsa_switch *ds)
 {
-   struct mv88e6xxx_priv_state *ps = ds_to_priv(ds);
int ret;
 
ret = mv88e6xxx_setup_common(ds);
if (ret < 0)
return ret;
 
-   switch (ps->id) {
-   case PORT_SWITCH_ID_6123:
-   ps->num_ports = 3;
-   break;
-   case PORT_SWITCH_ID_6161:
-   case PORT_SWITCH_ID_6165:
-   ps->num_ports = 6;
-   break;
-   default:
-   return -ENODEV;
-   }
-
ret = mv88e6xxx_switch_reset(ds, false);
if (ret < 0)
return ret;
diff --git a/drivers/net/dsa/mv88e6131.c b/drivers/net/dsa/mv88e6131.c
index ec06321..f6b465b 100644
--- a/drivers/net/dsa/mv88e6131.c
+++ b/drivers/net/dsa/mv88e6131.c
@@ -22,18 +22,22 @@ static const struct mv88e6xxx_info mv88e6131_table[] = {
.prod_num = PORT_SWITCH_ID_PROD_NUM_6095,
.family = MV88E6XXX_FAMILY_6095,
.name = "Marvell 88E6095/88E6095F",
+   .num_ports = 11,
}, {
.prod_num = PORT_SWITCH_ID_PROD_NUM_6085,
.family = MV88E6XXX_FAMILY_6097,
.name = "Marvell 88E6085",
+   .num_ports = 10,
}, {
.prod_num = PORT_SWITCH_ID_PROD_NUM_6131,
.family = MV88E6XXX_FAMILY_6185,
.name = "Marvell 88E6131",
+   .num_ports = 8,
}, {
.prod_num = PORT_SWITCH_ID_PROD_NUM_6185,
.family = MV88E6XXX_FAMILY_6185,
.name = "Marvell 88E6185",
+   .num_ports = 10,
}
 };
 
@@ -103,7 +107,6 @@ static int mv88e6131_setup_global(struct dsa_switch *ds)
 
 static int mv88e6131_setup(struct dsa_switch *ds)
 {
-   struct mv88e6xxx_priv_state *ps = ds_to_priv(ds);
int ret;
 
ret = mv88e6xxx_setup_common(ds);
@@ -112,21 +115,6 @@ static int mv88e6131_setup(struct dsa_switch *ds)
 
mv88e6xxx_ppu_state_init(ds);
 
-   switch (ps->id) {
-   case PORT_SWITCH_ID_6085:
-   case PORT_SWITCH_ID_6185:
-   ps->num_ports = 10;
-   break;
-   case PORT_SWITCH_ID_6095:
-   ps->num_ports = 11;
-   break;
-   case PORT_SWITCH_ID_6131:
-   ps->num_ports = 8;
-   break;
-   default:
-   return -ENODEV;
-   }
-
ret = mv88e6xxx_switch_reset(ds, false);
if (ret < 0)
return ret;
@@ -142,7 +130,7 @@ static int mv88e6131_port_to_phy_addr(struct dsa_switch 
*ds, int port)
 {
struct mv88e6xxx_priv_state *ps = ds_to_priv(ds);
 
-   if (port >= 0 && port < ps->num_ports)
+   if (port >= 0 && port < ps->info->num_ports)
return port;
 
return -EINVAL;
diff --git a/drivers/net/dsa/mv88e6171.c b/drivers/net/dsa/mv88e6171.c
index efe3c0f..cdfa899 100644
--- a/drivers/net/dsa/mv88e6171.c
+++ b/drivers/net/dsa/mv88e6171.c
@@ -22,18 +22,22 @@ static const struct mv88e6xxx_info mv88e6171_table[] = {
.prod_num = PORT_SWITCH_ID_PROD_NUM_6171,
.family = MV88E6XXX_FAMILY_6351,
.name = "Marvell 88E6171",
+   .num_ports = 7,
}, {
.prod_num = PORT_SWITCH_ID_PROD_NUM_6175,
.family = MV88E6XXX_FAMILY_6351,
.name = "Marvell 88E6175",
+   .num_ports = 7,
}, {

[PATCH net-next v3 4/8] net: dsa: mv88e6xxx: add switch info

2016-04-16 Thread Vivien Didelot
Add a new switch info structure which is meant to store switch models
static information, such as product number, name, number of ports,
number of databases, etc.

Signed-off-by: Vivien Didelot 
---
 drivers/net/dsa/mv88e6123.c | 15 +++
 drivers/net/dsa/mv88e6131.c | 19 ++-
 drivers/net/dsa/mv88e6171.c | 19 ++-
 drivers/net/dsa/mv88e6352.c | 27 ---
 drivers/net/dsa/mv88e6xxx.c | 21 -
 drivers/net/dsa/mv88e6xxx.h | 28 +++-
 6 files changed, 94 insertions(+), 35 deletions(-)

diff --git a/drivers/net/dsa/mv88e6123.c b/drivers/net/dsa/mv88e6123.c
index 00c1121..9120fcf 100644
--- a/drivers/net/dsa/mv88e6123.c
+++ b/drivers/net/dsa/mv88e6123.c
@@ -17,10 +17,17 @@
 #include 
 #include "mv88e6xxx.h"
 
-static const struct mv88e6xxx_switch_id mv88e6123_table[] = {
-   { PORT_SWITCH_ID_6123, "Marvell 88E6123" },
-   { PORT_SWITCH_ID_6161, "Marvell 88E6161" },
-   { PORT_SWITCH_ID_6165, "Marvell 88E6165" },
+static const struct mv88e6xxx_info mv88e6123_table[] = {
+   {
+   .prod_num = PORT_SWITCH_ID_PROD_NUM_6123,
+   .name = "Marvell 88E6123",
+   }, {
+   .prod_num = PORT_SWITCH_ID_PROD_NUM_6161,
+   .name = "Marvell 88E6161",
+   }, {
+   .prod_num = PORT_SWITCH_ID_PROD_NUM_6165,
+   .name = "Marvell 88E6165",
+   }
 };
 
 static char *mv88e6123_drv_probe(struct device *dsa_dev,
diff --git a/drivers/net/dsa/mv88e6131.c b/drivers/net/dsa/mv88e6131.c
index df534da..82ff0c4 100644
--- a/drivers/net/dsa/mv88e6131.c
+++ b/drivers/net/dsa/mv88e6131.c
@@ -17,11 +17,20 @@
 #include 
 #include "mv88e6xxx.h"
 
-static const struct mv88e6xxx_switch_id mv88e6131_table[] = {
-   { PORT_SWITCH_ID_6085, "Marvell 88E6085" },
-   { PORT_SWITCH_ID_6095, "Marvell 88E6095/88E6095F" },
-   { PORT_SWITCH_ID_6131, "Marvell 88E6131" },
-   { PORT_SWITCH_ID_6185, "Marvell 88E6185" },
+static const struct mv88e6xxx_info mv88e6131_table[] = {
+   {
+   .prod_num = PORT_SWITCH_ID_PROD_NUM_6095,
+   .name = "Marvell 88E6095/88E6095F",
+   }, {
+   .prod_num = PORT_SWITCH_ID_PROD_NUM_6085,
+   .name = "Marvell 88E6085",
+   }, {
+   .prod_num = PORT_SWITCH_ID_PROD_NUM_6131,
+   .name = "Marvell 88E6131",
+   }, {
+   .prod_num = PORT_SWITCH_ID_PROD_NUM_6185,
+   .name = "Marvell 88E6185",
+   }
 };
 
 static char *mv88e6131_drv_probe(struct device *dsa_dev,
diff --git a/drivers/net/dsa/mv88e6171.c b/drivers/net/dsa/mv88e6171.c
index 40222b0..5e9eb8c 100644
--- a/drivers/net/dsa/mv88e6171.c
+++ b/drivers/net/dsa/mv88e6171.c
@@ -17,11 +17,20 @@
 #include 
 #include "mv88e6xxx.h"
 
-static const struct mv88e6xxx_switch_id mv88e6171_table[] = {
-   { PORT_SWITCH_ID_6171, "Marvell 88E6171" },
-   { PORT_SWITCH_ID_6175, "Marvell 88E6175" },
-   { PORT_SWITCH_ID_6350, "Marvell 88E6350" },
-   { PORT_SWITCH_ID_6351, "Marvell 88E6351" },
+static const struct mv88e6xxx_info mv88e6171_table[] = {
+   {
+   .prod_num = PORT_SWITCH_ID_PROD_NUM_6171,
+   .name = "Marvell 88E6171",
+   }, {
+   .prod_num = PORT_SWITCH_ID_PROD_NUM_6175,
+   .name = "Marvell 88E6175",
+   }, {
+   .prod_num = PORT_SWITCH_ID_PROD_NUM_6350,
+   .name = "Marvell 88E6350",
+   }, {
+   .prod_num = PORT_SWITCH_ID_PROD_NUM_6351,
+   .name = "Marvell 88E6351",
+   }
 };
 
 static char *mv88e6171_drv_probe(struct device *dsa_dev,
diff --git a/drivers/net/dsa/mv88e6352.c b/drivers/net/dsa/mv88e6352.c
index 30fc5f6..3a53cfb 100644
--- a/drivers/net/dsa/mv88e6352.c
+++ b/drivers/net/dsa/mv88e6352.c
@@ -22,13 +22,26 @@
 #include 
 #include "mv88e6xxx.h"
 
-static const struct mv88e6xxx_switch_id mv88e6352_table[] = {
-   { PORT_SWITCH_ID_6172, "Marvell 88E6172" },
-   { PORT_SWITCH_ID_6176, "Marvell 88E6176" },
-   { PORT_SWITCH_ID_6240, "Marvell 88E6240" },
-   { PORT_SWITCH_ID_6320, "Marvell 88E6320" },
-   { PORT_SWITCH_ID_6321, "Marvell 88E6321" },
-   { PORT_SWITCH_ID_6352, "Marvell 88E6352" },
+static const struct mv88e6xxx_info mv88e6352_table[] = {
+   {
+   .prod_num = PORT_SWITCH_ID_PROD_NUM_6320,
+   .name = "Marvell 88E6320",
+   }, {
+   .prod_num = PORT_SWITCH_ID_PROD_NUM_6321,
+   .name = "Marvell 88E6321",
+   }, {
+   .prod_num = PORT_SWITCH_ID_PROD_NUM_6172,
+   .name = "Marvell 88E6172",
+   }, {
+   .prod_num = PORT_SWITCH_ID_PROD_NUM_6176,
+   .name = "Marvell 88E6176",
+   }, {
+   .prod_num = PORT_SWITCH_ID_PROD_NUM_6240,
+   .name = "Marvell 88E6240",
+   }, {
+   .prod_num = 

[PATCH net-next v3 0/8] net: dsa: mv88e6xxx: factorize switch info

2016-04-16 Thread Vivien Didelot
This patchset factorizes the mv88e6xxx code by sharing a new extendable
info structure to store static data such as switch family, product
number, number of ports, number of databases and the name.

The next step is to add a "flags" bitmap member to the info structure in
order to simplify the shared code with a feature-based logic instead of
checking their family/ID.

This is a step forward having a single mv88e6xxx driver supporting many
similar devices, like any usual Linux driver.

Changes v2 -> v3:
  - update commit messages and add Andrew's tags
  - keep the info lookup code in a separated function
  - split the single switch ID reading in probe in a new commit

Changes v1 -> v2:
  - define PORT_SWITCH_ID_PROD_NUM_* values
  - use plain struct mv88e6xxx_info
  - remove non used yet ps->rev

Vivien Didelot (8):
  net: dsa: mv88e6xxx: drop double ds assignment
  net: dsa: mv88e6xxx: drop revision probing
  net: dsa: mv88e6xxx: read switch ID in probe
  net: dsa: mv88e6xxx: add switch info
  net: dsa: mv88e6xxx: add family to info
  net: dsa: mv88e6xxx: add number of ports to info
  net: dsa: mv88e6xxx: add number of db to info
  net: dsa: mv88e6xxx: remove switch ID from ps

 drivers/net/dsa/mv88e6123.c |  45 +-
 drivers/net/dsa/mv88e6131.c |  53 ++--
 drivers/net/dsa/mv88e6171.c |  36 +---
 drivers/net/dsa/mv88e6352.c |  55 
 drivers/net/dsa/mv88e6xxx.c | 206 ++--
 drivers/net/dsa/mv88e6xxx.h |  92 
 6 files changed, 214 insertions(+), 273 deletions(-)

-- 
2.8.0



[PATCH net-next v3 2/8] net: dsa: mv88e6xxx: drop revision probing

2016-04-16 Thread Vivien Didelot
There is no point in having a special case for the revision when probing
a switch model. The code gets cluttered with unnecessary defines, and
leads to errors when code such as mv88e6131_setup compares
PORT_SWITCH_ID_6131_B2 to ps->id which masks the revision.

Drop every revision definition, and lookup only the product number.

Signed-off-by: Vivien Didelot 
---
 drivers/net/dsa/mv88e6123.c |  6 --
 drivers/net/dsa/mv88e6131.c |  2 --
 drivers/net/dsa/mv88e6352.c |  6 --
 drivers/net/dsa/mv88e6xxx.c | 14 +-
 drivers/net/dsa/mv88e6xxx.h | 15 ---
 5 files changed, 1 insertion(+), 42 deletions(-)

diff --git a/drivers/net/dsa/mv88e6123.c b/drivers/net/dsa/mv88e6123.c
index 88a812d..00c1121 100644
--- a/drivers/net/dsa/mv88e6123.c
+++ b/drivers/net/dsa/mv88e6123.c
@@ -19,14 +19,8 @@
 
 static const struct mv88e6xxx_switch_id mv88e6123_table[] = {
{ PORT_SWITCH_ID_6123, "Marvell 88E6123" },
-   { PORT_SWITCH_ID_6123_A1, "Marvell 88E6123 (A1)" },
-   { PORT_SWITCH_ID_6123_A2, "Marvell 88E6123 (A2)" },
{ PORT_SWITCH_ID_6161, "Marvell 88E6161" },
-   { PORT_SWITCH_ID_6161_A1, "Marvell 88E6161 (A1)" },
-   { PORT_SWITCH_ID_6161_A2, "Marvell 88E6161 (A2)" },
{ PORT_SWITCH_ID_6165, "Marvell 88E6165" },
-   { PORT_SWITCH_ID_6165_A1, "Marvell 88E6165 (A1)" },
-   { PORT_SWITCH_ID_6165_A2, "Marvell 88e6165 (A2)" },
 };
 
 static char *mv88e6123_drv_probe(struct device *dsa_dev,
diff --git a/drivers/net/dsa/mv88e6131.c b/drivers/net/dsa/mv88e6131.c
index 6b2bcb0..df534da 100644
--- a/drivers/net/dsa/mv88e6131.c
+++ b/drivers/net/dsa/mv88e6131.c
@@ -21,7 +21,6 @@ static const struct mv88e6xxx_switch_id mv88e6131_table[] = {
{ PORT_SWITCH_ID_6085, "Marvell 88E6085" },
{ PORT_SWITCH_ID_6095, "Marvell 88E6095/88E6095F" },
{ PORT_SWITCH_ID_6131, "Marvell 88E6131" },
-   { PORT_SWITCH_ID_6131_B2, "Marvell 88E6131 (B2)" },
{ PORT_SWITCH_ID_6185, "Marvell 88E6185" },
 };
 
@@ -109,7 +108,6 @@ static int mv88e6131_setup(struct dsa_switch *ds)
ps->num_ports = 11;
break;
case PORT_SWITCH_ID_6131:
-   case PORT_SWITCH_ID_6131_B2:
ps->num_ports = 8;
break;
default:
diff --git a/drivers/net/dsa/mv88e6352.c b/drivers/net/dsa/mv88e6352.c
index dbd920e..30fc5f6 100644
--- a/drivers/net/dsa/mv88e6352.c
+++ b/drivers/net/dsa/mv88e6352.c
@@ -27,14 +27,8 @@ static const struct mv88e6xxx_switch_id mv88e6352_table[] = {
{ PORT_SWITCH_ID_6176, "Marvell 88E6176" },
{ PORT_SWITCH_ID_6240, "Marvell 88E6240" },
{ PORT_SWITCH_ID_6320, "Marvell 88E6320" },
-   { PORT_SWITCH_ID_6320_A1, "Marvell 88E6320 (A1)" },
-   { PORT_SWITCH_ID_6320_A2, "Marvell 88e6320 (A2)" },
{ PORT_SWITCH_ID_6321, "Marvell 88E6321" },
-   { PORT_SWITCH_ID_6321_A1, "Marvell 88E6321 (A1)" },
-   { PORT_SWITCH_ID_6321_A2, "Marvell 88e6321 (A2)" },
{ PORT_SWITCH_ID_6352, "Marvell 88E6352" },
-   { PORT_SWITCH_ID_6352_A0, "Marvell 88E6352 (A0)" },
-   { PORT_SWITCH_ID_6352_A1, "Marvell 88E6352 (A1)" },
 };
 
 static char *mv88e6352_drv_probe(struct device *dsa_dev,
diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
index 9985a0c..b63e985 100644
--- a/drivers/net/dsa/mv88e6xxx.c
+++ b/drivers/net/dsa/mv88e6xxx.c
@@ -3081,22 +3081,10 @@ static char *mv88e6xxx_lookup_name(struct mii_bus *bus, 
int sw_addr,
if (ret < 0)
return NULL;
 
-   /* Look up the exact switch ID */
for (i = 0; i < num; ++i)
-   if (table[i].id == ret)
+   if (table[i].id == (ret & 0xfff0))
return table[i].name;
 
-   /* Look up only the product number */
-   for (i = 0; i < num; ++i) {
-   if (table[i].id == (ret & PORT_SWITCH_ID_PROD_NUM_MASK)) {
-   dev_warn(>dev,
-"unknown revision %d, using base switch 
0x%x\n",
-ret & PORT_SWITCH_ID_REV_MASK,
-ret & PORT_SWITCH_ID_PROD_NUM_MASK);
-   return table[i].name;
-   }
-   }
-
return NULL;
 }
 
diff --git a/drivers/net/dsa/mv88e6xxx.h b/drivers/net/dsa/mv88e6xxx.h
index 5d27dec..9242aea 100644
--- a/drivers/net/dsa/mv88e6xxx.h
+++ b/drivers/net/dsa/mv88e6xxx.h
@@ -68,8 +68,6 @@
 #define PORT_PCS_CTRL_UNFORCED 0x03
 #define PORT_PAUSE_CTRL0x02
 #define PORT_SWITCH_ID 0x03
-#define PORT_SWITCH_ID_PROD_NUM_MASK   0xfff0
-#define PORT_SWITCH_ID_REV_MASK0x000f
 #define PORT_SWITCH_ID_60310x0310
 #define PORT_SWITCH_ID_60350x0350
 #define PORT_SWITCH_ID_60460x0480
@@ -84,18 +82,11 @@
 #define PORT_SWITCH_ID_61210x1040
 #define PORT_SWITCH_ID_61220x1050
 #define PORT_SWITCH_ID_61230x1210
-#define PORT_SWITCH_ID_6123_A1 

[PATCH net-next v3 5/8] net: dsa: mv88e6xxx: add family to info

2016-04-16 Thread Vivien Didelot
Add an mv88e6xxx_family enum to the info structure for better family
indentification.

Signed-off-by: Vivien Didelot 
Reviewed-by: Andrew Lunn 
---
 drivers/net/dsa/mv88e6123.c |  3 ++
 drivers/net/dsa/mv88e6131.c |  4 +++
 drivers/net/dsa/mv88e6171.c |  4 +++
 drivers/net/dsa/mv88e6352.c |  6 
 drivers/net/dsa/mv88e6xxx.c | 71 +
 drivers/net/dsa/mv88e6xxx.h | 13 +
 6 files changed, 38 insertions(+), 63 deletions(-)

diff --git a/drivers/net/dsa/mv88e6123.c b/drivers/net/dsa/mv88e6123.c
index 9120fcf..93429d2 100644
--- a/drivers/net/dsa/mv88e6123.c
+++ b/drivers/net/dsa/mv88e6123.c
@@ -20,12 +20,15 @@
 static const struct mv88e6xxx_info mv88e6123_table[] = {
{
.prod_num = PORT_SWITCH_ID_PROD_NUM_6123,
+   .family = MV88E6XXX_FAMILY_6165,
.name = "Marvell 88E6123",
}, {
.prod_num = PORT_SWITCH_ID_PROD_NUM_6161,
+   .family = MV88E6XXX_FAMILY_6165,
.name = "Marvell 88E6161",
}, {
.prod_num = PORT_SWITCH_ID_PROD_NUM_6165,
+   .family = MV88E6XXX_FAMILY_6165,
.name = "Marvell 88E6165",
}
 };
diff --git a/drivers/net/dsa/mv88e6131.c b/drivers/net/dsa/mv88e6131.c
index 82ff0c4..ec06321 100644
--- a/drivers/net/dsa/mv88e6131.c
+++ b/drivers/net/dsa/mv88e6131.c
@@ -20,15 +20,19 @@
 static const struct mv88e6xxx_info mv88e6131_table[] = {
{
.prod_num = PORT_SWITCH_ID_PROD_NUM_6095,
+   .family = MV88E6XXX_FAMILY_6095,
.name = "Marvell 88E6095/88E6095F",
}, {
.prod_num = PORT_SWITCH_ID_PROD_NUM_6085,
+   .family = MV88E6XXX_FAMILY_6097,
.name = "Marvell 88E6085",
}, {
.prod_num = PORT_SWITCH_ID_PROD_NUM_6131,
+   .family = MV88E6XXX_FAMILY_6185,
.name = "Marvell 88E6131",
}, {
.prod_num = PORT_SWITCH_ID_PROD_NUM_6185,
+   .family = MV88E6XXX_FAMILY_6185,
.name = "Marvell 88E6185",
}
 };
diff --git a/drivers/net/dsa/mv88e6171.c b/drivers/net/dsa/mv88e6171.c
index 5e9eb8c..efe3c0f 100644
--- a/drivers/net/dsa/mv88e6171.c
+++ b/drivers/net/dsa/mv88e6171.c
@@ -20,15 +20,19 @@
 static const struct mv88e6xxx_info mv88e6171_table[] = {
{
.prod_num = PORT_SWITCH_ID_PROD_NUM_6171,
+   .family = MV88E6XXX_FAMILY_6351,
.name = "Marvell 88E6171",
}, {
.prod_num = PORT_SWITCH_ID_PROD_NUM_6175,
+   .family = MV88E6XXX_FAMILY_6351,
.name = "Marvell 88E6175",
}, {
.prod_num = PORT_SWITCH_ID_PROD_NUM_6350,
+   .family = MV88E6XXX_FAMILY_6351,
.name = "Marvell 88E6350",
}, {
.prod_num = PORT_SWITCH_ID_PROD_NUM_6351,
+   .family = MV88E6XXX_FAMILY_6351,
.name = "Marvell 88E6351",
}
 };
diff --git a/drivers/net/dsa/mv88e6352.c b/drivers/net/dsa/mv88e6352.c
index 3a53cfb..c051c02 100644
--- a/drivers/net/dsa/mv88e6352.c
+++ b/drivers/net/dsa/mv88e6352.c
@@ -25,21 +25,27 @@
 static const struct mv88e6xxx_info mv88e6352_table[] = {
{
.prod_num = PORT_SWITCH_ID_PROD_NUM_6320,
+   .family = MV88E6XXX_FAMILY_6320,
.name = "Marvell 88E6320",
}, {
.prod_num = PORT_SWITCH_ID_PROD_NUM_6321,
+   .family = MV88E6XXX_FAMILY_6320,
.name = "Marvell 88E6321",
}, {
.prod_num = PORT_SWITCH_ID_PROD_NUM_6172,
+   .family = MV88E6XXX_FAMILY_6352,
.name = "Marvell 88E6172",
}, {
.prod_num = PORT_SWITCH_ID_PROD_NUM_6176,
+   .family = MV88E6XXX_FAMILY_6352,
.name = "Marvell 88E6176",
}, {
.prod_num = PORT_SWITCH_ID_PROD_NUM_6240,
+   .family = MV88E6XXX_FAMILY_6352,
.name = "Marvell 88E6240",
}, {
.prod_num = PORT_SWITCH_ID_PROD_NUM_6352,
+   .family = MV88E6XXX_FAMILY_6352,
.name = "Marvell 88E6352",
}
 };
diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
index 1f69b28..b3f0fd5 100644
--- a/drivers/net/dsa/mv88e6xxx.c
+++ b/drivers/net/dsa/mv88e6xxx.c
@@ -369,111 +369,56 @@ static bool mv88e6xxx_6065_family(struct dsa_switch *ds)
 {
struct mv88e6xxx_priv_state *ps = ds_to_priv(ds);
 
-   switch (ps->id) {
-   case PORT_SWITCH_ID_6031:
-   case PORT_SWITCH_ID_6061:
-   case PORT_SWITCH_ID_6035:
-   case PORT_SWITCH_ID_6065:
-   return true;
-   }
-   return false;
+   return ps->info->family == MV88E6XXX_FAMILY_6065;
 }
 
 static bool mv88e6xxx_6095_family(struct dsa_switch *ds)
 

[PATCH net-next v3 8/8] net: dsa: mv88e6xxx: remove switch ID from ps

2016-04-16 Thread Vivien Didelot
ps->id is not needed anymore, so remove it as well as the related
defined values.

Signed-off-by: Vivien Didelot 
Reviewed-by: Andrew Lunn 
---
 drivers/net/dsa/mv88e6xxx.c |  1 -
 drivers/net/dsa/mv88e6xxx.h | 32 
 2 files changed, 33 deletions(-)

diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
index e6e657b..e8a198c 100644
--- a/drivers/net/dsa/mv88e6xxx.c
+++ b/drivers/net/dsa/mv88e6xxx.c
@@ -3041,7 +3041,6 @@ char *mv88e6xxx_drv_probe(struct device *dsa_dev, struct 
device *host_dev,
ps->bus = bus;
ps->sw_addr = sw_addr;
ps->info = info;
-   ps->id = id & 0xfff0;
 
*priv = ps;
 
diff --git a/drivers/net/dsa/mv88e6xxx.h b/drivers/net/dsa/mv88e6xxx.h
index 4b3121b..4c5f434 100644
--- a/drivers/net/dsa/mv88e6xxx.h
+++ b/drivers/net/dsa/mv88e6xxx.h
@@ -85,37 +85,6 @@
 #define PORT_SWITCH_ID_PROD_NUM_6352   0x352
 #define PORT_SWITCH_ID_PROD_NUM_6350   0x371
 #define PORT_SWITCH_ID_PROD_NUM_6351   0x375
-#define PORT_SWITCH_ID_60310x0310
-#define PORT_SWITCH_ID_60350x0350
-#define PORT_SWITCH_ID_60460x0480
-#define PORT_SWITCH_ID_60610x0610
-#define PORT_SWITCH_ID_60650x0650
-#define PORT_SWITCH_ID_60850x04a0
-#define PORT_SWITCH_ID_60920x0970
-#define PORT_SWITCH_ID_60950x0950
-#define PORT_SWITCH_ID_60960x0980
-#define PORT_SWITCH_ID_60970x0990
-#define PORT_SWITCH_ID_61080x1070
-#define PORT_SWITCH_ID_61210x1040
-#define PORT_SWITCH_ID_61220x1050
-#define PORT_SWITCH_ID_61230x1210
-#define PORT_SWITCH_ID_61310x1060
-#define PORT_SWITCH_ID_61520x1a40
-#define PORT_SWITCH_ID_61550x1a50
-#define PORT_SWITCH_ID_61610x1610
-#define PORT_SWITCH_ID_61650x1650
-#define PORT_SWITCH_ID_61710x1710
-#define PORT_SWITCH_ID_61720x1720
-#define PORT_SWITCH_ID_61750x1750
-#define PORT_SWITCH_ID_61760x1760
-#define PORT_SWITCH_ID_61820x1a60
-#define PORT_SWITCH_ID_61850x1a70
-#define PORT_SWITCH_ID_62400x2400
-#define PORT_SWITCH_ID_63200x1150
-#define PORT_SWITCH_ID_63210x3100
-#define PORT_SWITCH_ID_63500x3710
-#define PORT_SWITCH_ID_63510x3750
-#define PORT_SWITCH_ID_63520x3520
 #define PORT_CONTROL   0x04
 #define PORT_CONTROL_USE_CORE_TAG  BIT(15)
 #define PORT_CONTROL_DROP_ON_LOCK  BIT(14)
@@ -457,7 +426,6 @@ struct mv88e6xxx_priv_state {
 */
struct mutex eeprom_mutex;
 
-   int id; /* switch product id */
struct mv88e6xxx_priv_port  ports[DSA_MAX_PORTS];
 
DECLARE_BITMAP(port_state_update_mask, DSA_MAX_PORTS);
-- 
2.8.0



[PATCH net-next v3 7/8] net: dsa: mv88e6xxx: add number of db to info

2016-04-16 Thread Vivien Didelot
Add the number of databases to the info structure.

Signed-off-by: Vivien Didelot 
Reviewed-by: Andrew Lunn 
---
 drivers/net/dsa/mv88e6123.c |  3 +++
 drivers/net/dsa/mv88e6131.c |  4 
 drivers/net/dsa/mv88e6171.c |  4 
 drivers/net/dsa/mv88e6352.c |  6 ++
 drivers/net/dsa/mv88e6xxx.c | 19 +--
 drivers/net/dsa/mv88e6xxx.h |  1 +
 6 files changed, 19 insertions(+), 18 deletions(-)

diff --git a/drivers/net/dsa/mv88e6123.c b/drivers/net/dsa/mv88e6123.c
index e3802b4..b3cbf8e 100644
--- a/drivers/net/dsa/mv88e6123.c
+++ b/drivers/net/dsa/mv88e6123.c
@@ -22,16 +22,19 @@ static const struct mv88e6xxx_info mv88e6123_table[] = {
.prod_num = PORT_SWITCH_ID_PROD_NUM_6123,
.family = MV88E6XXX_FAMILY_6165,
.name = "Marvell 88E6123",
+   .num_databases = 4096,
.num_ports = 3,
}, {
.prod_num = PORT_SWITCH_ID_PROD_NUM_6161,
.family = MV88E6XXX_FAMILY_6165,
.name = "Marvell 88E6161",
+   .num_databases = 4096,
.num_ports = 6,
}, {
.prod_num = PORT_SWITCH_ID_PROD_NUM_6165,
.family = MV88E6XXX_FAMILY_6165,
.name = "Marvell 88E6165",
+   .num_databases = 4096,
.num_ports = 6,
}
 };
diff --git a/drivers/net/dsa/mv88e6131.c b/drivers/net/dsa/mv88e6131.c
index f6b465b..8a161c5 100644
--- a/drivers/net/dsa/mv88e6131.c
+++ b/drivers/net/dsa/mv88e6131.c
@@ -22,21 +22,25 @@ static const struct mv88e6xxx_info mv88e6131_table[] = {
.prod_num = PORT_SWITCH_ID_PROD_NUM_6095,
.family = MV88E6XXX_FAMILY_6095,
.name = "Marvell 88E6095/88E6095F",
+   .num_databases = 256,
.num_ports = 11,
}, {
.prod_num = PORT_SWITCH_ID_PROD_NUM_6085,
.family = MV88E6XXX_FAMILY_6097,
.name = "Marvell 88E6085",
+   .num_databases = 4096,
.num_ports = 10,
}, {
.prod_num = PORT_SWITCH_ID_PROD_NUM_6131,
.family = MV88E6XXX_FAMILY_6185,
.name = "Marvell 88E6131",
+   .num_databases = 256,
.num_ports = 8,
}, {
.prod_num = PORT_SWITCH_ID_PROD_NUM_6185,
.family = MV88E6XXX_FAMILY_6185,
.name = "Marvell 88E6185",
+   .num_databases = 256,
.num_ports = 10,
}
 };
diff --git a/drivers/net/dsa/mv88e6171.c b/drivers/net/dsa/mv88e6171.c
index cdfa899..689824f 100644
--- a/drivers/net/dsa/mv88e6171.c
+++ b/drivers/net/dsa/mv88e6171.c
@@ -22,21 +22,25 @@ static const struct mv88e6xxx_info mv88e6171_table[] = {
.prod_num = PORT_SWITCH_ID_PROD_NUM_6171,
.family = MV88E6XXX_FAMILY_6351,
.name = "Marvell 88E6171",
+   .num_databases = 4096,
.num_ports = 7,
}, {
.prod_num = PORT_SWITCH_ID_PROD_NUM_6175,
.family = MV88E6XXX_FAMILY_6351,
.name = "Marvell 88E6175",
+   .num_databases = 4096,
.num_ports = 7,
}, {
.prod_num = PORT_SWITCH_ID_PROD_NUM_6350,
.family = MV88E6XXX_FAMILY_6351,
.name = "Marvell 88E6350",
+   .num_databases = 4096,
.num_ports = 7,
}, {
.prod_num = PORT_SWITCH_ID_PROD_NUM_6351,
.family = MV88E6XXX_FAMILY_6351,
.name = "Marvell 88E6351",
+   .num_databases = 4096,
.num_ports = 7,
}
 };
diff --git a/drivers/net/dsa/mv88e6352.c b/drivers/net/dsa/mv88e6352.c
index 9aaddca..abd9113 100644
--- a/drivers/net/dsa/mv88e6352.c
+++ b/drivers/net/dsa/mv88e6352.c
@@ -27,31 +27,37 @@ static const struct mv88e6xxx_info mv88e6352_table[] = {
.prod_num = PORT_SWITCH_ID_PROD_NUM_6320,
.family = MV88E6XXX_FAMILY_6320,
.name = "Marvell 88E6320",
+   .num_databases = 4096,
.num_ports = 7,
}, {
.prod_num = PORT_SWITCH_ID_PROD_NUM_6321,
.family = MV88E6XXX_FAMILY_6320,
.name = "Marvell 88E6321",
+   .num_databases = 4096,
.num_ports = 7,
}, {
.prod_num = PORT_SWITCH_ID_PROD_NUM_6172,
.family = MV88E6XXX_FAMILY_6352,
.name = "Marvell 88E6172",
+   .num_databases = 4096,
.num_ports = 7,
}, {
.prod_num = PORT_SWITCH_ID_PROD_NUM_6176,
.family = MV88E6XXX_FAMILY_6352,
.name = "Marvell 88E6176",
+   .num_databases = 4096,
.num_ports = 7,
}, {
.prod_num 

Re: [PATCH v3 0/5] net: w5100: add support W5100/W5200 for SPI interface

2016-04-16 Thread David Miller
From: Akinobu Mita 
Date: Fri, 15 Apr 2016 00:11:28 +0900

> This series add support for Wiznet W5100 and W5200 for SPI interface.

Series applied, thank you.


Re: [PATCH net-next] vxlan: reduce usage of synchronize_net in ndo_stop

2016-04-16 Thread David Miller
From: Hannes Frederic Sowa 
Date: Sat,  9 Apr 2016 12:46:23 +0200

> We only need to do the synchronize_net dance once for both, ipv4 and
> ipv6 sockets, thus removing one synchronize_net in case both sockets get
> dismantled.
> 
> Signed-off-by: Hannes Frederic Sowa 

Applied.


Re: [PATCH net-next v2] vxlan: synchronously and race-free destruction of vxlan sockets

2016-04-16 Thread David Miller
From: Hannes Frederic Sowa 
Date: Fri,  8 Apr 2016 22:55:01 +0200

> Due to the fact that the udp socket is destructed asynchronously in a
> work queue, we have some nondeterministic behavior during shutdown of
> vxlan tunnels and creating new ones. Fix this by keeping the destruction
> process synchronous in regards to the user space process so IFF_UP can
> be reliably set.
> 
> udp_tunnel_sock_release destroys vs->sock->sk if reference counter
> indicates so. We expect to have the same lifetime of vxlan_sock and
> vxlan_sock->sock->sk even in fast paths with only rcu locks held. So
> only destruct the whole socket after we can be sure it cannot be found
> by searching vxlan_net->sock_list.
> 
> Cc: Eric Dumazet 
> Cc: Jiri Benc 
> Cc: Marcelo Ricardo Leitner 
> Signed-off-by: Hannes Frederic Sowa 

Applied.


[PATCH V2] net: ethernet: mellanox: correct page conversion

2016-04-16 Thread Sinan Kaya
Current code is assuming that the address returned by dma_alloc_coherent
is a logical address. This is not true on ARM/ARM64 systems. This patch
replaces dma_alloc_coherent with dma_map_page API. The address returned
can later by virtually mapped from the CPU side with vmap API.

Signed-off-by: Sinan Kaya 
---
 drivers/net/ethernet/mellanox/mlx4/alloc.c | 37 ++
 1 file changed, 27 insertions(+), 10 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx4/alloc.c 
b/drivers/net/ethernet/mellanox/mlx4/alloc.c
index 0c51c69..22a7ae7 100644
--- a/drivers/net/ethernet/mellanox/mlx4/alloc.c
+++ b/drivers/net/ethernet/mellanox/mlx4/alloc.c
@@ -618,13 +618,26 @@ int mlx4_buf_alloc(struct mlx4_dev *dev, int size, int 
max_direct,
return -ENOMEM;
 
for (i = 0; i < buf->nbufs; ++i) {
-   buf->page_list[i].buf =
-   dma_alloc_coherent(>persist->pdev->dev,
-  PAGE_SIZE,
-  , gfp);
-   if (!buf->page_list[i].buf)
+   struct page *page;
+
+   page = alloc_page(GFP_KERNEL);
+   if (!page)
goto err_free;
 
+   t = dma_map_page(>persist->pdev->dev, page, 0,
+PAGE_SIZE, DMA_BIDIRECTIONAL);
+
+   if (dma_mapping_error(>persist->pdev->dev, t)) {
+   __free_page(page);
+   goto err_free;
+   }
+
+   buf->page_list[i].buf = page_address(page);
+   if (!buf->page_list[i].buf) {
+   __free_page(page);
+   goto err_free;
+   }
+
buf->page_list[i].map = t;
 
memset(buf->page_list[i].buf, 0, PAGE_SIZE);
@@ -666,11 +679,15 @@ void mlx4_buf_free(struct mlx4_dev *dev, int size, struct 
mlx4_buf *buf)
vunmap(buf->direct.buf);
 
for (i = 0; i < buf->nbufs; ++i)
-   if (buf->page_list[i].buf)
-   dma_free_coherent(>persist->pdev->dev,
- PAGE_SIZE,
- buf->page_list[i].buf,
- buf->page_list[i].map);
+   if (buf->page_list[i].buf) {
+   struct page *page;
+
+   page = virt_to_page(buf->page_list[i].buf);
+   dma_unmap_page(>persist->pdev->dev,
+  buf->page_list[i].map,
+  PAGE_SIZE, DMA_BIDIRECTIONAL);
+   __free_page(page);
+   }
kfree(buf->page_list);
}
 }
-- 
1.8.2.1



[PATCH] of_mdio: make of_mdiobus_register_{device|phy}() *void*

2016-04-16 Thread Sergei Shtylyov
The results of of_mdiobus_register_{device|phy}() are never checked, so we
can make  both these functions *void*...

Signed-off-by: Sergei Shtylyov 

---
The patch is against DaveM's 'net-next.git' repo.

 drivers/of/of_mdio.c |   21 -
 1 file changed, 8 insertions(+), 13 deletions(-)

Index: net-next/drivers/of/of_mdio.c
===
--- net-next.orig/drivers/of/of_mdio.c
+++ net-next/drivers/of/of_mdio.c
@@ -41,8 +41,8 @@ static int of_get_phy_id(struct device_n
return -EINVAL;
 }
 
-static int of_mdiobus_register_phy(struct mii_bus *mdio, struct device_node 
*child,
-  u32 addr)
+static void of_mdiobus_register_phy(struct mii_bus *mdio,
+   struct device_node *child, u32 addr)
 {
struct phy_device *phy;
bool is_c45;
@@ -57,7 +57,7 @@ static int of_mdiobus_register_phy(struc
else
phy = get_phy_device(mdio, addr, is_c45);
if (IS_ERR_OR_NULL(phy))
-   return 1;
+   return;
 
rc = irq_of_parse_and_map(child, 0);
if (rc > 0) {
@@ -81,25 +81,22 @@ static int of_mdiobus_register_phy(struc
if (rc) {
phy_device_free(phy);
of_node_put(child);
-   return 1;
+   return;
}
 
dev_dbg(>dev, "registered phy %s at address %i\n",
child->name, addr);
-
-   return 0;
 }
 
-static int of_mdiobus_register_device(struct mii_bus *mdio,
- struct device_node *child,
- u32 addr)
+static void of_mdiobus_register_device(struct mii_bus *mdio,
+  struct device_node *child, u32 addr)
 {
struct mdio_device *mdiodev;
int rc;
 
mdiodev = mdio_device_create(mdio, addr);
if (IS_ERR(mdiodev))
-   return 1;
+   return;
 
/* Associate the OF node with the device structure so it
 * can be looked up later.
@@ -112,13 +109,11 @@ static int of_mdiobus_register_device(st
if (rc) {
mdio_device_free(mdiodev);
of_node_put(child);
-   return 1;
+   return;
}
 
dev_dbg(>dev, "registered mdio device %s at address %i\n",
child->name, addr);
-
-   return 0;
 }
 
 int of_mdio_parse_addr(struct device *dev, const struct device_node *np)



Re: [PATCH] netlink: don't send NETLINK_URELEASE for unbound sockets

2016-04-16 Thread Johannes Berg
On Sat, 2016-04-16 at 14:30 +0800, Herbert Xu wrote:
> Johannes Berg  wrote:
> > 
> > 
> > diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
> > index 215fc08c02ab..330ebd600f25 100644
> > --- a/net/netlink/af_netlink.c
> > +++ b/net/netlink/af_netlink.c
> > @@ -688,7 +688,7 @@ static int netlink_release(struct socket *sock)
> > 
> >    skb_queue_purge(>sk_write_queue);
> > 
> > -   if (nlk->portid) {
> > +   if (nlk->portid && nlk->bound) {
> Any reason why we're still testing portid at all? Isn't testing
> bound enough?

The reason is that while I felt confident in understanding the problem
and its solution, I didn't realize that bound follows portid, and that,
for example, a kernel socket can't get bound. :-)

But yeah - looking at the code after your comment does show that
testing portid is pointless now.

In fact, now that I look at it, I wonder how this situation came about?

In the current code, you can only trigger the problematic situation
through an error condition, afaict - you have to try to bind a socket
with the same portid as an already existing one, and __netlink_insert()
will then fail, but netlink_insert() won't reset the nlk_sk(sk)->portid 
since your commit da314c9923fe ("netlink: Replace rhash_portid with
bound"), even though you had previously fixed precisely this issue
already - commit c0bb07df7d98 ("netlink: Reset portid after
netlink_insert failure"). You then close the socket, and since portid
is assigned, that will trigger NETLINK_URELEASE.

So before the rhash_portid -> bound change, this doesn't seem to have
been a problem, and I guess we didn't get the "stuck in limbo" problem
back because we now check bound everywhere relevant, for purposes of
calling netlink_autobind.

IOW - I'm now even more convinced that the patch is correct, and I'm
also convinced that until fairly recently (da314c9923fe) this wasn't
even a problem.

Maybe we can take the opportunity of removing the "portid" check to put
most of the above into a commit message, but I think you should review
it first.

johannes


Re: [PATCH] devlink: fix devlink_sb_register prototype

2016-04-16 Thread Jiri Pirko
Sat, Apr 16, 2016 at 10:27:06PM CEST, a...@arndb.de wrote:
>The devlink shared buffer interface contains two different
>prototypes for devlink_sb_register, and the one that is
>used when NET_DEVLINK is disabled does not work:
>
>drivers/net/ethernet/mellanox/mlxsw/spectrum_buffers.c: In function 
>'mlxsw_sp_buffers_init':
>drivers/net/ethernet/mellanox/mlxsw/spectrum_buffers.c:547:9: error: too many 
>arguments to function 'devlink_sb_register'
>  return devlink_sb_register(priv_to_devlink(mlxsw_sp->core), 0,
>
>This makes the two prototypes have the same argument list.
>
>Signed-off-by: Arnd Bergmann 
>Fixes: bf7974710a40 ("devlink: add shared buffer configuration")

Already fixed by:

commit de33efd0fb7f923cd41671b1f743c3a0d44dd953
Author: Jiri Pirko 
Date:   Fri Apr 15 09:17:08 2016 +0200

devlink: fix sb register stub in case devlink is disabled


[PATCH] ixgbe: use msleep for long delays

2016-04-16 Thread Arnd Bergmann
The newly added x550em_a support causes a link failure on ARM because of
an overly long time passed into udelay():

ERROR: "__bad_udelay" [drivers/net/ethernet/intel/ixgbe/ixgbe.ko] undefined!

There are multiple variants of the ixgbe_acquire_swfw_sync_*() function,
and the other ones all use msleep(), so we can safely assume that all
callers are allowed to sleep, which makes msleep() a better replacement
than mdelay().

Signed-off-by: Arnd Bergmann 
Fixes: 49425dfc7451 ("ixgbe: Add support for x550em_a 10G MAC type")
---
 drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c 
b/drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c
index c71e93ed4451..21c0fce47e15 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c
@@ -2765,7 +2765,7 @@ static s32 ixgbe_acquire_swfw_sync_x550em_a(struct 
ixgbe_hw *hw, u32 mask)
ixgbe_release_swfw_sync_X540(hw, hmask);
if (status != IXGBE_ERR_TOKEN_RETRY)
return status;
-   udelay(FW_PHY_TOKEN_DELAY * 1000);
+   msleep(FW_PHY_TOKEN_DELAY);
}
 
return status;
-- 
2.7.0



[PATCH] bpf: avoid warning for wrong pointer cast

2016-04-16 Thread Arnd Bergmann
Two new functions in bpf contain a cast from a 'u64' to a
pointer. This works on 64-bit architectures but causes a warning
on all 32-bit architectures:

kernel/trace/bpf_trace.c: In function 'bpf_perf_event_output_tp':
kernel/trace/bpf_trace.c:350:13: error: cast to pointer from integer of 
different size [-Werror=int-to-pointer-cast]
  u64 ctx = *(long *)r1;

This changes the cast to first convert the u64 argument into a uintptr_t,
which is guaranteed to be the same size as a pointer.

Signed-off-by: Arnd Bergmann 
Fixes: 9940d67c93b5 ("bpf: support bpf_get_stackid() and 
bpf_perf_event_output() in tracepoint programs")
---
 kernel/trace/bpf_trace.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index 413ec5614180..c082313a523a 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -347,7 +347,7 @@ static u64 bpf_perf_event_output_tp(u64 r1, u64 r2, u64 
index, u64 r4, u64 size)
 * from bpf program and contain a pointer to 'struct pt_regs'. Fetch it
 * from there and call the same bpf_perf_event_output() helper
 */
-   u64 ctx = *(long *)r1;
+   u64 ctx = *(long *)(uintptr_t)r1;
 
return bpf_perf_event_output(ctx, r2, index, r4, size);
 }
@@ -365,7 +365,7 @@ static const struct bpf_func_proto 
bpf_perf_event_output_proto_tp = {
 
 static u64 bpf_get_stackid_tp(u64 r1, u64 r2, u64 r3, u64 r4, u64 r5)
 {
-   u64 ctx = *(long *)r1;
+   u64 ctx = *(long *)(uintptr_t)r1;
 
return bpf_get_stackid(ctx, r2, r3, r4, r5);
 }
-- 
2.7.0



[PATCH] devlink: fix devlink_sb_register prototype

2016-04-16 Thread Arnd Bergmann
The devlink shared buffer interface contains two different
prototypes for devlink_sb_register, and the one that is
used when NET_DEVLINK is disabled does not work:

drivers/net/ethernet/mellanox/mlxsw/spectrum_buffers.c: In function 
'mlxsw_sp_buffers_init':
drivers/net/ethernet/mellanox/mlxsw/spectrum_buffers.c:547:9: error: too many 
arguments to function 'devlink_sb_register'
  return devlink_sb_register(priv_to_devlink(mlxsw_sp->core), 0,

This makes the two prototypes have the same argument list.

Signed-off-by: Arnd Bergmann 
Fixes: bf7974710a40 ("devlink: add shared buffer configuration")
---
 include/net/devlink.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/include/net/devlink.h b/include/net/devlink.h
index be64218e0254..1d45b61cb320 100644
--- a/include/net/devlink.h
+++ b/include/net/devlink.h
@@ -184,7 +184,9 @@ static inline void devlink_port_split_set(struct 
devlink_port *devlink_port,
 static inline int devlink_sb_register(struct devlink *devlink,
  unsigned int sb_index, u32 size,
  u16 ingress_pools_count,
- u16 egress_pools_count, u16 tc_count)
+ u16 egress_pools_count,
+ u16 ingress_tc_count,
+ u16 egress_tc_count)
 {
return 0;
 }
-- 
2.7.0



[PATCH] netfilter: ctnetlink: add more #ifdef around unused code

2016-04-16 Thread Arnd Bergmann
A recent patch removed many 'inline' annotations for static
functions in this file, which has caused warnings for functions
that are not used in a given configuration, in particular when
CONFIG_NF_CONNTRACK_EVENTS is disabled:

nf_conntrack_netlink.c:572:15: 'ctnetlink_timestamp_size' defined but not used
nf_conntrack_netlink.c:546:15: 'ctnetlink_acct_size' defined but not used
nf_conntrack_netlink.c:339:12: 'ctnetlink_label_size' defined but not used

I first tried to replace some of the existing #ifdefs with nicer
'if (IS_ENABLED())' checks, but ran into several other problems
with that, so this patch adds even more #ifdef conditionals to
avoid the remaining warnings. Another option would be to put
'__maybe_unused' annotations in place of the previous 'inline'
keyword.

Signed-off-by: Arnd Bergmann 
Fixes: 4054ff45454a ("netfilter: ctnetlink: remove unnecessary inlining")
---
 net/netfilter/nf_conntrack_netlink.c | 26 +++---
 1 file changed, 15 insertions(+), 11 deletions(-)

diff --git a/net/netfilter/nf_conntrack_netlink.c 
b/net/netfilter/nf_conntrack_netlink.c
index caa4efe5930b..f893012986c7 100644
--- a/net/netfilter/nf_conntrack_netlink.c
+++ b/net/netfilter/nf_conntrack_netlink.c
@@ -336,6 +336,7 @@ nla_put_failure:
 #endif
 
 #ifdef CONFIG_NF_CONNTRACK_LABELS
+#ifdef CONFIG_NF_CONNTRACK_EVENTS
 static int ctnetlink_label_size(const struct nf_conn *ct)
 {
struct nf_conn_labels *labels = nf_ct_labels_find(ct);
@@ -344,6 +345,7 @@ static int ctnetlink_label_size(const struct nf_conn *ct)
return 0;
return nla_total_size(labels->words * sizeof(long));
 }
+#endif
 
 static int
 ctnetlink_dump_labels(struct sk_buff *skb, const struct nf_conn *ct)
@@ -526,6 +528,7 @@ nla_put_failure:
return -1;
 }
 
+#if defined(CONFIG_NF_CONNTRACK_EVENTS) || 
defined(CONFIG_NETFILTER_NETLINK_GLUE_CT)
 static size_t ctnetlink_proto_size(const struct nf_conn *ct)
 {
struct nf_conntrack_l3proto *l3proto;
@@ -543,16 +546,6 @@ static size_t ctnetlink_proto_size(const struct nf_conn 
*ct)
return len;
 }
 
-static size_t ctnetlink_acct_size(const struct nf_conn *ct)
-{
-   if (!nf_ct_ext_exist(ct, NF_CT_EXT_ACCT))
-   return 0;
-   return 2 * nla_total_size(0) /* CTA_COUNTERS_ORIG|REPL */
-  + 2 * nla_total_size(sizeof(uint64_t)) /* CTA_COUNTERS_PACKETS */
-  + 2 * nla_total_size(sizeof(uint64_t)) /* CTA_COUNTERS_BYTES */
-  ;
-}
-
 static int ctnetlink_secctx_size(const struct nf_conn *ct)
 {
 #ifdef CONFIG_NF_CONNTRACK_SECMARK
@@ -568,6 +561,18 @@ static int ctnetlink_secctx_size(const struct nf_conn *ct)
return 0;
 #endif
 }
+#endif
+
+#ifdef CONFIG_NF_CONNTRACK_EVENTS
+static size_t ctnetlink_acct_size(const struct nf_conn *ct)
+{
+   if (!nf_ct_ext_exist(ct, NF_CT_EXT_ACCT))
+   return 0;
+   return 2 * nla_total_size(0) /* CTA_COUNTERS_ORIG|REPL */
+  + 2 * nla_total_size(sizeof(uint64_t)) /* CTA_COUNTERS_PACKETS */
+  + 2 * nla_total_size(sizeof(uint64_t)) /* CTA_COUNTERS_BYTES */
+  ;
+}
 
 static size_t ctnetlink_timestamp_size(const struct nf_conn *ct)
 {
@@ -580,7 +585,6 @@ static size_t ctnetlink_timestamp_size(const struct nf_conn 
*ct)
 #endif
 }
 
-#ifdef CONFIG_NF_CONNTRACK_EVENTS
 static size_t ctnetlink_nlmsg_size(const struct nf_conn *ct)
 {
return NLMSG_ALIGN(sizeof(struct nfgenmsg))
-- 
2.7.0



Re: WARNING: CPU: 1 PID: 2485 at drivers/net/wireless/intel/iwlwifi/pcie/trans.c:1752 iwl_trans_pcie_grab_nic_access+0x110/0x120 [iwlwifi]

2016-04-16 Thread Grumbach, Emmanuel
On Sat, 2016-04-16 at 17:43 +0200, Borislav Petkov wrote:
> On Fri, Apr 15, 2016 at 04:16:02AM +, Grumbach, Emmanuel wrote:
> > [1] 
> > https://git.kernel.org/cgit/linux/kernel/git/iwlwifi/backport-iwlwi
> > fi.git/
> 
> It is very strange to pull from this repo, git fetch is doing
> something
> for a while now without any forward progress.

This is not surprising at all. This tree is not a kernel tree, but
rather a backport tree. It doesn't contain anything besides the Wifi
stack and the backport code. It has no common commit with the Linux
kernel. I understand that you fetched this tree from a kernel tree but
that's not a good idea. Git will try to find a common ancestor but that
will fail... after a huge number of tentatives. You'd better clone it.

> In any case, 4.5 is bad too, testing 4.4 now.

Here you go.

> I 'm travelling currently
> so the whole bisection deal will take a whole but I'll get to it
> eventually.

I'll be glad to see something coming out of this, but I can't say I am
very optimistic.

> 
> Thanks for taking a look.
> 

Re: [PATCH] net: ipv6: Do not fix up linklocal and loopback addresses

2016-04-16 Thread David Ahern

On 4/15/16 9:13 PM, Mike Manning wrote:

f1705ec197e7 added the option to retain user configured addresses on an
admin down. A comment to one of the later revisions suggested using the
IFA_F_PERMANENT flag rather than adding a user_managed boolean to the
ifaddr struct. A side effect of this change is that link local and
loopback addresses are also retained which is not part of the objective
of f1705ec197e7. Add check so that these addresses are not fixed up,
given that a related fix 70af921db6f8 ensures that they are not kept in
the first place, otherwise this incorrect fixup triggers a crash in fib6.


oops in fib6_del?



Fixes: f1705ec197e7 ("net: ipv6: Make address flushing on ifdown optional")
Signed-off-by: Mike Manning 
---


for the change
Acked-by: David Ahern 



Re: WARNING: CPU: 1 PID: 2485 at drivers/net/wireless/intel/iwlwifi/pcie/trans.c:1752 iwl_trans_pcie_grab_nic_access+0x110/0x120 [iwlwifi]

2016-04-16 Thread Borislav Petkov
On Fri, Apr 15, 2016 at 04:16:02AM +, Grumbach, Emmanuel wrote:
> [1] https://git.kernel.org/cgit/linux/kernel/git/iwlwifi/backport-iwlwi
> fi.git/

It is very strange to pull from this repo, git fetch is doing something
for a while now without any forward progress.

In any case, 4.5 is bad too, testing 4.4 now. I'm travelling currently
so the whole bisection deal will take a whole but I'll get to it
eventually.

Thanks for taking a look.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply. Srsly.


Re: [PATCH v2] carl9170: Clarify kconfig text

2016-04-16 Thread Christian Lamparter
On Saturday, April 16, 2016 05:18:56 PM Lauri Kasanen wrote:
> The previous text was confusing, leading readers to think this
> driver was a duplicate, and so didn't need to be enabled.
> 
> After the removal of the older staging driver, this is the only
> driver in mainline for these devices.
> 
> Signed-off-by: Lauri Kasanen 
Acked-by: Christian Lamparter 

> ---
> v2: Remove the mention of the previous driver, suggested by Christian.

Thanks!
 
>  drivers/net/wireless/ath/carl9170/Kconfig | 8 +++-
>  1 file changed, 3 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/net/wireless/ath/carl9170/Kconfig 
> b/drivers/net/wireless/ath/carl9170/Kconfig
> index 1a796e5..2e34bae 100644
> --- a/drivers/net/wireless/ath/carl9170/Kconfig
> +++ b/drivers/net/wireless/ath/carl9170/Kconfig
> @@ -5,12 +5,10 @@ config CARL9170
>   select FW_LOADER
>   select CRC32
>   help
> -   This is another driver for the Atheros "otus" 802.11n USB devices.
> +   This is the mainline driver for the Atheros "otus" 802.11n USB 
> devices.
>  
> -   This driver provides more features than the original,
> -   but it needs a special firmware (carl9170-1.fw) to do that.
> -
> -   The firmware can be downloaded from our wiki here:
> +   It needs a special firmware (carl9170-1.fw), which can be downloaded
> +   from our wiki here:
> 
>  
> If you choose to build a module, it'll be called carl9170.
> 



Re: [PATCH] net: ipv6: Do not fix up linklocal and loopback addresses

2016-04-16 Thread Sergei Shtylyov

Hello.

On 4/16/2016 6:13 AM, Mike Manning wrote:


f1705ec197e7 added the option to retain user configured addresses on an
admin down. A comment to one of the later revisions suggested using the
IFA_F_PERMANENT flag rather than adding a user_managed boolean to the
ifaddr struct. A side effect of this change is that link local and
loopback addresses are also retained which is not part of the objective
of f1705ec197e7. Add check so that these addresses are not fixed up,
given that a related fix 70af921db6f8 ensures that they are not kept in


   scripts/checkpatch.pl now enforces commit citing certain style: <12-digit 
SHA1> ("").



the first place, otherwise this incorrect fixup triggers a crash in fib6.

Fixes: f1705ec197e7 ("net: ipv6: Make address flushing on ifdown optional")
Signed-off-by: Mike Manning 

[...]

MBR, Sergei



[PATCH v2] carl9170: Clarify kconfig text

2016-04-16 Thread Lauri Kasanen
The previous text was confusing, leading readers to think this
driver was a duplicate, and so didn't need to be enabled.

After the removal of the older staging driver, this is the only
driver in mainline for these devices.

Signed-off-by: Lauri Kasanen 
---
v2: Remove the mention of the previous driver, suggested by Christian.

 drivers/net/wireless/ath/carl9170/Kconfig | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/ath/carl9170/Kconfig 
b/drivers/net/wireless/ath/carl9170/Kconfig
index 1a796e5..2e34bae 100644
--- a/drivers/net/wireless/ath/carl9170/Kconfig
+++ b/drivers/net/wireless/ath/carl9170/Kconfig
@@ -5,12 +5,10 @@ config CARL9170
select FW_LOADER
select CRC32
help
- This is another driver for the Atheros "otus" 802.11n USB devices.
+ This is the mainline driver for the Atheros "otus" 802.11n USB 
devices.
 
- This driver provides more features than the original,
- but it needs a special firmware (carl9170-1.fw) to do that.
-
- The firmware can be downloaded from our wiki here:
+ It needs a special firmware (carl9170-1.fw), which can be downloaded
+ from our wiki here:
  
 
  If you choose to build a module, it'll be called carl9170.
-- 
2.6.2



Grant Donation

2016-04-16 Thread Julie Leach


-- 
You have a cash grant donation of $2,500.000.00 USD, I am Julie Leach;Won 
$310.5 million Powerball jackpot winner. To verify the genuineness of this 
email and my winnings, please you can read more about me by viewing the below 
links:

http://www.powerball.com/powerball/winners/2015/MI_Leach_093015.shtml

For more details, kindly reply to this message for complete information.

Julie Leach.


[PATCH net-next 5/6] nfp: remove buggy RX buffer length validation

2016-04-16 Thread Jakub Kicinski
Meaning of data_len and meta_len RX WB descriptor fields is
slightly confusing.  Add a comment with a diagram clarifying
the layout.  Also remove the buffer length validation:
(a) it's imprecise for static rx-offsets; (b) if firmware
is buggy enough to DMA past the end of the buffer
WARN_ON_ONCE() doesn't seem like a strong enough response.
skb_put() will do the checking for us anyway.

Signed-off-by: Jakub Kicinski 
---
 .../net/ethernet/netronome/nfp/nfp_net_common.c| 26 --
 1 file changed, 14 insertions(+), 12 deletions(-)

diff --git a/drivers/net/ethernet/netronome/nfp/nfp_net_common.c 
b/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
index 0bdff390c958..5235e86eb684 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
+++ b/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
@@ -1298,23 +1298,25 @@ static int nfp_net_rx(struct nfp_net_rx_ring *rx_ring, 
int budget)
 
nfp_net_rx_give_one(rx_ring, new_skb, new_dma_addr);
 
+   /* < meta_len >
+*  <-- [rx_offset] -->
+*  -
+* | [XX] |  metadata  | packet   |  |
+*  -
+* < data_len --->
+*
+* The rx_offset is fixed for all packets, the meta_len can vary
+* on a packet by packet basis. If rx_offset is set to zero
+* (_RX_OFFSET_DYNAMIC) metadata starts at the beginning of the
+* buffer and is immediately followed by the packet (no [XX]).
+*/
meta_len = rxd->rxd.meta_len_dd & PCIE_DESC_RX_META_LEN_MASK;
data_len = le16_to_cpu(rxd->rxd.data_len);
 
-   if (WARN_ON_ONCE(data_len > nn->fl_bufsz)) {
-   dev_kfree_skb_any(skb);
-   continue;
-   }
-
-   if (nn->rx_offset == NFP_NET_CFG_RX_OFFSET_DYNAMIC) {
-   /* The packet data starts after the metadata */
+   if (nn->rx_offset == NFP_NET_CFG_RX_OFFSET_DYNAMIC)
skb_reserve(skb, meta_len);
-   } else {
-   /* The packet data starts at a fixed offset */
+   else
skb_reserve(skb, nn->rx_offset);
-   }
-
-   /* Adjust the SKB for the dynamic meta data pre-pended */
skb_put(skb, data_len - meta_len);
 
nfp_net_set_hash(nn->netdev, skb, rxd);
-- 
1.9.1



[PATCH net-next 6/6] nfp: add async reconfiguration mechanism

2016-04-16 Thread Jakub Kicinski
Some callers of nfp_net_reconfig() are in atomic context so
we used to busy wait for commands to complete.  In worst case
scenario that means locking up a core for up to 5 seconds
when a command times out.  Lets add a timer-based mechanism
of asynchronously checking whether reconfiguration completed
successfully for atomic callers to use.  Non-atomic callers
can now just sleep.

The approach taken is quite simple because (1) synchronous
reconfigurations always happen under RTNL (or before device
is registered); (2) we can coalesce pending reconfigs.
There is no need for request queues, timer which eventually
takes a look at reconfiguration result to report errors is
good enough.

Signed-off-by: Jakub Kicinski 
---
 drivers/net/ethernet/netronome/nfp/nfp_net.h   |  12 +-
 .../net/ethernet/netronome/nfp/nfp_net_common.c| 172 ++---
 2 files changed, 157 insertions(+), 27 deletions(-)

diff --git a/drivers/net/ethernet/netronome/nfp/nfp_net.h 
b/drivers/net/ethernet/netronome/nfp/nfp_net.h
index 3d53fcf323eb..e744acc18ef4 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_net.h
+++ b/drivers/net/ethernet/netronome/nfp/nfp_net.h
@@ -59,8 +59,8 @@
netdev_warn((nn)->netdev, fmt, ## args);\
} while (0)
 
-/* Max time to wait for NFP to respond on updates (in ms) */
-#define NFP_NET_POLL_TIMEOUT   5000
+/* Max time to wait for NFP to respond on updates (in seconds) */
+#define NFP_NET_POLL_TIMEOUT   5
 
 /* Bar allocation */
 #define NFP_NET_CRTL_BAR   0
@@ -447,6 +447,10 @@ static inline bool nfp_net_fw_ver_eq(struct 
nfp_net_fw_version *fw_ver,
  * @shared_name:Name for shared interrupt
  * @me_freq_mhz:ME clock_freq (MHz)
  * @reconfig_lock: Protects HW reconfiguration request regs/machinery
+ * @reconfig_posted:   Pending reconfig bits coming from async sources
+ * @reconfig_timer_active:  Timer for reading reconfiguration results is 
pending
+ * @reconfig_sync_present:  Some thread is performing synchronous reconfig
+ * @reconfig_timer:Timer for async reading of reconfig results
  * @link_up:Is the link up?
  * @link_status_lock:  Protects @link_up and ensures atomicity with BAR reading
  * @rx_coalesce_usecs:  RX interrupt moderation usecs delay parameter
@@ -531,6 +535,10 @@ struct nfp_net {
spinlock_t link_status_lock;
 
spinlock_t reconfig_lock;
+   u32 reconfig_posted;
+   bool reconfig_timer_active;
+   bool reconfig_sync_present;
+   struct timer_list reconfig_timer;
 
u32 rx_coalesce_usecs;
u32 rx_coalesce_max_frames;
diff --git a/drivers/net/ethernet/netronome/nfp/nfp_net_common.c 
b/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
index 5235e86eb684..fa47c14c743a 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
+++ b/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
@@ -80,6 +80,116 @@ void nfp_net_get_fw_version(struct nfp_net_fw_version 
*fw_ver,
put_unaligned_le32(reg, fw_ver);
 }
 
+/* Firmware reconfig
+ *
+ * Firmware reconfig may take a while so we have two versions of it -
+ * synchronous and asynchronous (posted).  All synchronous callers are holding
+ * RTNL so we don't have to worry about serializing them.
+ */
+static void nfp_net_reconfig_start(struct nfp_net *nn, u32 update)
+{
+   nn_writel(nn, NFP_NET_CFG_UPDATE, update);
+   /* ensure update is written before pinging HW */
+   nn_pci_flush(nn);
+   nfp_qcp_wr_ptr_add(nn->qcp_cfg, 1);
+}
+
+/* Pass 0 as update to run posted reconfigs. */
+static void nfp_net_reconfig_start_async(struct nfp_net *nn, u32 update)
+{
+   update |= nn->reconfig_posted;
+   nn->reconfig_posted = 0;
+
+   nfp_net_reconfig_start(nn, update);
+
+   nn->reconfig_timer_active = true;
+   mod_timer(>reconfig_timer, jiffies + NFP_NET_POLL_TIMEOUT * HZ);
+}
+
+static bool nfp_net_reconfig_check_done(struct nfp_net *nn, bool last_check)
+{
+   u32 reg;
+
+   reg = nn_readl(nn, NFP_NET_CFG_UPDATE);
+   if (reg == 0)
+   return true;
+   if (reg & NFP_NET_CFG_UPDATE_ERR) {
+   nn_err(nn, "Reconfig error: 0x%08x\n", reg);
+   return true;
+   } else if (last_check) {
+   nn_err(nn, "Reconfig timeout: 0x%08x\n", reg);
+   return true;
+   }
+
+   return false;
+}
+
+static int nfp_net_reconfig_wait(struct nfp_net *nn, unsigned long deadline)
+{
+   bool timed_out = false;
+
+   /* Poll update field, waiting for NFP to ack the config */
+   while (!nfp_net_reconfig_check_done(nn, timed_out)) {
+   msleep(1);
+   timed_out = time_is_before_eq_jiffies(deadline);
+   }
+
+   if (nn_readl(nn, NFP_NET_CFG_UPDATE) & NFP_NET_CFG_UPDATE_ERR)
+   return -EIO;
+
+   return timed_out ? -EIO : 0;
+}
+
+static void nfp_net_reconfig_timer(unsigned long data)
+{
+   struct nfp_net *nn = 

[PATCH net-next 2/6] nfp: remove unnecessary static

2016-04-16 Thread Jakub Kicinski
There is no reason for those local variables to be static.

Signed-off-by: Jakub Kicinski 
---
 drivers/net/ethernet/netronome/nfp/nfp_net_debugfs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/netronome/nfp/nfp_net_debugfs.c 
b/drivers/net/ethernet/netronome/nfp/nfp_net_debugfs.c
index d77ae4d0e4dc..f7c9a5bc4aa3 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_net_debugfs.c
+++ b/drivers/net/ethernet/netronome/nfp/nfp_net_debugfs.c
@@ -187,7 +187,7 @@ static const struct file_operations nfp_tx_q_fops = {
 
 void nfp_net_debugfs_adapter_add(struct nfp_net *nn)
 {
-   static struct dentry *queues, *tx, *rx;
+   struct dentry *queues, *tx, *rx;
char int_name[16];
int i;
 
-- 
1.9.1



[PATCH net-next 4/6] nfp: remove unused suspicious mask defines

2016-04-16 Thread Jakub Kicinski
NFP_NET_RXR_MASK sounds like a mask which could be used on
NFP_NET_CFG_RXRS_ENABLE register but its value is quite
strange.  In fact there are no users of this define so let's
just remove it.  Same for TX rings.

Signed-off-by: Jakub Kicinski 
---
 drivers/net/ethernet/netronome/nfp/nfp_net_ctrl.h | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/net/ethernet/netronome/nfp/nfp_net_ctrl.h 
b/drivers/net/ethernet/netronome/nfp/nfp_net_ctrl.h
index 3ec950555892..ad6c4e31cedd 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_net_ctrl.h
+++ b/drivers/net/ethernet/netronome/nfp/nfp_net_ctrl.h
@@ -81,14 +81,10 @@
 
 /**
  * @NFP_NET_TXR_MAX: Maximum number of TX rings
- * @NFP_NET_TXR_MASK:Mask for TX rings
  * @NFP_NET_RXR_MAX: Maximum number of RX rings
- * @NFP_NET_RXR_MASK:Mask for RX rings
  */
 #define NFP_NET_TXR_MAX 64
-#define NFP_NET_TXR_MASK(NFP_NET_TXR_MAX - 1)
 #define NFP_NET_RXR_MAX 64
-#define NFP_NET_RXR_MASK(NFP_NET_RXR_MAX - 1)
 
 /**
  * Read/Write config words (0x - 0x002c)
-- 
1.9.1



[PATCH net-next 3/6] nfp: correct names of constants in comments

2016-04-16 Thread Jakub Kicinski
Documentation in comments lacks CFG in some names.

Signed-off-by: Jakub Kicinski 
---
 drivers/net/ethernet/netronome/nfp/nfp_net_ctrl.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/netronome/nfp/nfp_net_ctrl.h 
b/drivers/net/ethernet/netronome/nfp/nfp_net_ctrl.h
index 8692003aeed8..3ec950555892 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_net_ctrl.h
+++ b/drivers/net/ethernet/netronome/nfp/nfp_net_ctrl.h
@@ -152,9 +152,9 @@
  * @NFP_NET_CFG_VERSION: Firmware version number
  * @NFP_NET_CFG_STS: Status
  * @NFP_NET_CFG_CAP: Capabilities (same bits as @NFP_NET_CFG_CTRL)
- * @NFP_NET_MAX_TXRINGS: Maximum number of TX rings
- * @NFP_NET_MAX_RXRINGS: Maximum number of RX rings
- * @NFP_NET_MAX_MTU: Maximum support MTU
+ * @NFP_NET_CFG_MAX_TXRINGS: Maximum number of TX rings
+ * @NFP_NET_CFG_MAX_RXRINGS: Maximum number of RX rings
+ * @NFP_NET_CFG_MAX_MTU: Maximum support MTU
  * @NFP_NET_CFG_START_TXQ:   Start Queue Control Queue to use for TX (PF only)
  * @NFP_NET_CFG_START_RXQ:   Start Queue Control Queue to use for RX (PF only)
  *
-- 
1.9.1



[PATCH net-next 1/6] nfp: check the right pointer for errors

2016-04-16 Thread Jakub Kicinski
Correct checking error condition on wrong pointer -
copy/paste mistake most likely.

Signed-off-by: Jakub Kicinski 
---
 drivers/net/ethernet/netronome/nfp/nfp_net_debugfs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/netronome/nfp/nfp_net_debugfs.c 
b/drivers/net/ethernet/netronome/nfp/nfp_net_debugfs.c
index f86a1f13d27b..d77ae4d0e4dc 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_net_debugfs.c
+++ b/drivers/net/ethernet/netronome/nfp/nfp_net_debugfs.c
@@ -200,7 +200,7 @@ void nfp_net_debugfs_adapter_add(struct nfp_net *nn)
 
/* Create queue debugging sub-tree */
queues = debugfs_create_dir("queue", nn->debugfs_dir);
-   if (IS_ERR_OR_NULL(nn->debugfs_dir))
+   if (IS_ERR_OR_NULL(queues))
return;
 
rx = debugfs_create_dir("rx", queues);
-- 
1.9.1



[PATCH net-next 0/6] nfp: cleanups and improvements

2016-04-16 Thread Jakub Kicinski
Hi!

Main purpose of this set is to get rid of doing potentially long
mdelay()s but it also contains some trivial changes I've accumulated.
First two patches fix harmless copy-paste errors, next two clean up
the documentation and remove unused defines.  Patch 5 clarifies the
interpretation of RX descriptor fields.  Patch 6, by far the biggest,
adds ability to perform FW reconfig asynchronously thanks to which
we can stop using mdelay().


Jakub Kicinski (6):
  nfp: check the right pointer for errors
  nfp: remove unnecessary static
  nfp: correct names of constants in comments
  nfp: remove unused suspicious mask defines
  nfp: remove buggy RX buffer length validation
  nfp: add async reconfiguration mechanism

 drivers/net/ethernet/netronome/nfp/nfp_net.h   |  12 +-
 .../net/ethernet/netronome/nfp/nfp_net_common.c| 198 +
 drivers/net/ethernet/netronome/nfp/nfp_net_ctrl.h  |  10 +-
 .../net/ethernet/netronome/nfp/nfp_net_debugfs.c   |   4 +-
 4 files changed, 176 insertions(+), 48 deletions(-)

-- 
1.9.1



Re: qdisc spin lock

2016-04-16 Thread Andrew
I think that it isn't a good solution - unless you can bind specified 
host (src/dst) to specified txq. Usually traffic is spreaded on txqs by 
src+dst IP (or even IP:port) hash which results in traffic spreading 
among all mqs on device, and wrong bandwidth limiting (N*bandwidth on 
multi-session load like p2p/server traffic)...


People said that hfsc shaper have better performance, but I didn't 
tested it.


01.04.2016 02:41, Michael Ma пишет:

Thanks for the suggestion - I'll try the MQ solution out. It seems to
be able to solve the problem well with the assumption that bandwidth
can be statically partitioned.

2016-03-31 12:18 GMT-07:00 Jesper Dangaard Brouer :

On Wed, 30 Mar 2016 00:20:03 -0700 Michael Ma  wrote:


I know this might be an old topic so bare with me – what we are facing
is that applications are sending small packets using hundreds of
threads so the contention on spin lock in __dev_xmit_skb increases the
latency of dev_queue_xmit significantly. We’re building a network QoS
solution to avoid interference of different applications using HTB.

Yes, as you have noticed with HTB there is a single qdisc lock, and
congestion obviously happens :-)

It is possible with different tricks to make it scale.  I believe
Google is using a variant of HTB, and it scales for them.  They have
not open source their modifications to HTB (which likely also involves
a great deal of setup tricks).

If your purpose it to limit traffic/bandwidth per "cloud" instance,
then you can just use another TC setup structure.  Like using MQ and
assigning a HTB per MQ queue (where the MQ queues are bound to each
CPU/HW queue)... But you have to figure out this setup yourself...



But in this case when some applications send massive small packets in
parallel, the application to be protected will get its throughput
affected (because it’s doing synchronous network communication using
multiple threads and throughput is sensitive to the increased latency)

Here is the profiling from perf:

-  67.57%   iperf  [kernel.kallsyms] [k] _spin_lock
   - 99.94% dev_queue_xmit
   -  96.91% _spin_lock
  - 2.62%  __qdisc_run
   - 98.98% sch_direct_xmit
- 99.98% _spin_lock

As far as I understand the design of TC is to simplify locking schema
and minimize the work in __qdisc_run so that throughput won’t be
affected, especially with large packets. However if the scenario is
that multiple classes in the queueing discipline only have the shaping
limit, there isn’t really a necessary correlation between different
classes. The only synchronization point should be when the packet is
dequeued from the qdisc queue and enqueued to the transmit queue of
the device. My question is – is it worth investing on avoiding the
locking contention by partitioning the queue/lock so that this
scenario is addressed with relatively smaller latency?

Yes, there is a lot go gain, but it is not easy ;-)


I must have oversimplified a lot of details since I’m not familiar
with the TC implementation at this point – just want to get your input
in terms of whether this is a worthwhile effort or there is something
fundamental that I’m not aware of. If this is just a matter of quite
some additional work, would also appreciate helping to outline the
required work here.

Also would appreciate if there is any information about the latest
status of this work http://www.ijcset.com/docs/IJCSET13-04-04-113.pdf

This article seems to be very low quality... spelling errors, only 5
pages, no real code, etc.

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




[PATCH] carl9170: Clarify kconfig text

2016-04-16 Thread Lauri Kasanen
The previous text was confusing, leading readers to think this
driver was a duplicate, and so didn't need to be enabled.

After the removal of the older staging driver, this is the only
driver in mainline for these devices.

Signed-off-by: Lauri Kasanen 
---
 drivers/net/wireless/ath/carl9170/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/carl9170/Kconfig 
b/drivers/net/wireless/ath/carl9170/Kconfig
index 1a796e5..f3e3222 100644
--- a/drivers/net/wireless/ath/carl9170/Kconfig
+++ b/drivers/net/wireless/ath/carl9170/Kconfig
@@ -5,7 +5,7 @@ config CARL9170
select FW_LOADER
select CRC32
help
- This is another driver for the Atheros "otus" 802.11n USB devices.
+ This is the mainline driver for the Atheros "otus" 802.11n USB 
devices.
 
  This driver provides more features than the original,
  but it needs a special firmware (carl9170-1.fw) to do that.
-- 
2.6.2



Re: [PATCH net-next v3 RFC 2/2] ipv6: add support for stats via RTM_GETSTATS

2016-04-16 Thread Thomas Graf
On 04/15/16 at 08:28pm, Roopa Prabhu wrote:
> +static size_t inet6_get_link_af_stats_size(const struct net_device *dev,
> +u32 filter_mask)
> +{
> + if (!(filter_mask & IFLA_STATS_FILTER_BIT(IFLA_STATS_LINK_INET6)))
> + return 0;
> +
> + if (!__in6_dev_get(dev))
> + return 0;
> +
> + return nla_total_size(sizeof(struct nlattr)) /* IFLA_STATS_LINK_INET6 */
> + + nla_total_size(IPSTATS_MIB_MAX * 8) /* IFLA_INET6_STATS */
> + + nla_total_size(ICMP6_MIB_MAX * sizeof(u64));/* 
> IFLA_INET6_ICMP6STATS */
> +}

I think this is a good example. The above is an expensive way to
figure out whether you have at least one interface with IPv6
statistics. I'd suggest to turn this into:

if (filter_mask & IFLA_STATS_FILTER_BIT(IFLA_STATS_LINK_INET6)) {
size += nla_total_size(sizeof(struct nlattr)) /* IFLA_STATS_LINK_INET6 
*/
+ nla_total_size(IPSTATS_MIB_MAX * 8) /* IFLA_INET6_STATS */
+ nla_total_size(ICMP6_MIB_MAX * sizeof(u64));/* 
IFLA_INET6_ICMP6STATS */
}

... and put it into the main calcit function. The user has explicitly opted into
IPv6 statistics so I think it's not a waste to allocate resources for it in the
message. You could also make it depend on "disable_ipv6" to be more accurate but
I think even the above is good enough.


Re: [PATCH net-next v3 1/2] rtnetlink: add new RTM_GETSTATS message to query stats

2016-04-16 Thread Thomas Graf
On 04/15/16 at 08:28pm, Roopa Prabhu wrote:
> +static u16 rtnl_stats_calcit(struct sk_buff *skb, struct nlmsghdr *nlh)
> +{
> + struct net *net = sock_net(skb->sk);
> + struct net_device *dev;
> + u16 min_ifinfo_dump_size = 0;
> + struct if_stats_msg *ifsm;
> + u32 filter_mask;
> +
> + ifsm = nlmsg_data(nlh);
> + filter_mask = ifsm->filter_mask;
> +
> + /* traverse the list of net devices and compute the minimum
> +  * buffer size based upon the filter mask.
> +  */
> + list_for_each_entry(dev, >dev_base_head, dev_list) {
> + min_ifinfo_dump_size = max_t(u16, min_ifinfo_dump_size,
> +  if_nlmsg_stats_size(dev,
> +  filter_mask));
> + }

Iterating over all net_devices in the namespace is quite an expensive
operation and it would now be done twice.

I understand that this code is taken over from rtnl_calcit() but there
the cost is at least only paid if ext_filter_mask is actually set and
the user opts into additional statistics.

I wonder if we can reduce the cost for the stats interface as its
purpose is to be minimal cost. I suggest we only add the loop once we
have an extension which actually depends on it. We can then try and
figure out to not require it.


Re: [PATCH] netlink: don't send NETLINK_URELEASE for unbound sockets

2016-04-16 Thread Herbert Xu
Johannes Berg  wrote:
>
> diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
> index 215fc08c02ab..330ebd600f25 100644
> --- a/net/netlink/af_netlink.c
> +++ b/net/netlink/af_netlink.c
> @@ -688,7 +688,7 @@ static int netlink_release(struct socket *sock)
> 
>skb_queue_purge(>sk_write_queue);
> 
> -   if (nlk->portid) {
> +   if (nlk->portid && nlk->bound) {

Any reason why we're still testing portid at all? Isn't testing
bound enough?

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