RE: next build: 235 warnings 3 failures (next/next-20151117)

[David Laight]

From: Will Deacon
> Sent: 18 November 2015 12:28
> On Wed, Nov 18, 2015 at 12:11:25PM +, David Laight wrote:
> > From: Will Deacon
> > > Sent: 18 November 2015 10:14
> > > On Tue, Nov 17, 2015 at 08:17:17PM +0100, Arnd Bergmann wrote:
> > > > On Tuesday 17 November 2015 17:12:37 Will Deacon wrote:
> > > > > On Tue, Nov 17, 2015 at 06:03:40PM +0100, Arnd Bergmann wrote:
> > > > > > On Tuesday 17 November 2015 16:44:53 Will Deacon wrote:
> > > > > > > > 8<
> > > > > > > > Subject: ARM64: make smp_load_acquire() work with const 
> > > > > > > > arguments
> > > > > > > >
> > > > > > > > smp_load_acquire() uses typeof() to declare a local variable 
> > > > > > > > for temporarily
> > > > > > > > storing the output of the memory access. This fails when the 
> > > > > > > > argument is
> > > > > > > > constant, because the assembler complains about using a 
> > > > > > > > constant register
> > > > > > > > as output:
> > > > > > > >
> > > > > > > >  arch/arm64/include/asm/barrier.h:71:3: error: read-only 
> > > > > > > > variable '___p1'
> > > > > > > >  used as 'asm' output
> > > > > > >
> > > > > > > Do you know the usage in the kernel causing this warning?
> > > > > >
> > > > > > A newly introduced function in include/net/sock.h:
> > > > > >
> > > > > > static inline int sk_state_load(const struct sock *sk)
> > > > > > {
> > > > > > return smp_load_acquire(>sk_state);
> > > > > > }
> > > > >
> > > > > Hmm, maybe we could play a similar trick to READ_ONCE by declaring an
> > > > > anonymous union and writing through the non-const member?
> > > >
> > > > Yes, I think that would work, if you think we need to care about the
> > > > case where we read into a structure.
> > > >
> > > > Can you come up with a patch for that?
> > >
> > > Done:
> > >
> > >   
> > > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-November/386094.html
> >
> > That patch forces a memory write-read and returns uninitialised stack
> > for short reads.
> 
> Really? The disassembly looks fine to me. Do you have a concrete example
> of where you think it goes wrong, please?
> 
> > Who knows what happens on big-endian systems.
> 
> The same thing as READ_ONCE? I'll test it there to make sure, but I
> don't see a problem.

Ah, god, it is absolutely horrid. But probably right :-(

Do all the lda variants zero extend to 64 bits ?
If so maybe you could use a single 64 bit variable for the result of the read
and then cast it to typeof(*p) to get the required sign extension for
small integer types.

David

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

Re: [PATCH -next] net: tcp: move to timewait when receiving data post active-close

[Eric Dumazet]

On Wed, 2015-11-18 at 16:03 +0100, Florian Westphal wrote:
> RFC 1122, 4.2.2.13:
>  [..] if new data is received after CLOSE is called, its TCP
>  SHOULD send a RST to show that data was lost.
> 
>  When a connection is closed actively, it MUST linger in
>  TIME-WAIT state [..].
> 
> We reset a connection, but destroy state immediately.
> 
> After discussing this with Hannes, we decided it was preferable
> to also move to TW state to avoid immediate port reuse.
> 
> packetdrill testcase:
> 
> 0.000 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
> 0.000 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
> 0.000 bind(3, ..., ...) = 0
> 0.000 listen(3, 1) = 0
> 0.100 < S 0:0(0) win 29200 
> 0.100 > S. 0:0(0) ack 1 
> 0.200 < . 1:1(0) ack 1 win 257
> 0.200 accept(3, ..., ...) = 4
> // close our side.
> 0.210 close(4) = 0
> // we should expect to see FIN now, sk moves to FIN_WAIT_1
> 0.210 > F. 1:1(0) ack 1 win 29200
> // receive data, but sk already closed -> Reset
> 0.300 < P. 1:1001(1000) ack 1 win 46
> 0.300 > R 1:1(0) win 0

Thanks for using packetdrill ;)

This packetdrill test shows nothing special regarding your patch, it
should work right now with current kernels ???

lpk51:~# tcpdump: verbose output suppressed, use -v or -vv for full protocol 
decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
lpk51:~# ./packetdrill Florian.pkt 
07:26:49.656548 IP 192.0.2.1.59883 > 192.168.155.177.8080: Flags [S], seq 0, 
win 29200, options [mss 1460], length 0
07:26:49.656611 IP 192.168.155.177.8080 > 192.0.2.1.59883: Flags [S.], seq 
1433468786, ack 1, win 29200, options [mss 1460], length 0
07:26:49.756530 IP 192.0.2.1.59883 > 192.168.155.177.8080: Flags [.], ack 1, 
win 257, length 0
07:26:49.766529 IP 192.168.155.177.8080 > 192.0.2.1.59883: Flags [F.], seq 1, 
ack 1, win 29200, length 0
07:26:49.856529 IP 192.0.2.1.59883 > 192.168.155.177.8080: Flags [P.], seq 
1:1001, ack 1, win 46, length 1000: HTTP
07:26:49.856560 IP 192.168.155.177.8080 > 192.0.2.1.59883: Flags [R], seq 
1433468787, win 0, length 0
07:26:49.856806 IP 192.0.2.1.59883 > 192.168.155.177.8080: Flags [R.], seq 
1001, ack 1, win 46, length 0


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

Re: [RFC][PATCH] net: arinc429: Add ARINC-429 stack

[Marek Vasut]

On Wednesday, November 18, 2015 at 05:38:02 PM, Aleksander Morgado wrote:
> On Tue, Nov 10, 2015 at 5:15 PM, Marek Vasut  wrote:
> >> >> >>> > About the parity -- can we add some flag into the datagram to
> >> >> >>> > indicate we want hardware to calculate the parity for that
> >> >> >>> > particular datagram for us? And we'd also need to indicate what
> >> >> >>> > type of parity. I dunno if this is worth the hassle.
> >> >> >>> 
> >> >> >>> This  is HW configuration property, it does not belong to 
> >> >> >>> datagram. Also for TX channels,  parity could  be  two  kinds: 
> >> >> >>> odd and even, for RX it is only on/off.
> >> >> >> 
> >> >> >> There are datagrams which do contain parity and ones which do not
> >> >> >> contain it, correct ? Thus, it's a property of that particular
> >> >> >> datagram.
> >> >> 
> >> >> All ARINC words have bit #31 as parity bit; whether it's used or not
> >> >> depends on the setup as Andrey says below.
> >> > 
> >> > Can bit 31 be ever used for DATA instead of parity ? Or is this just
> >> > me not understanding the parlance of the specification, where "DATA"
> >> > actually means "DATA with parity" ?
> >> 
> >> Well, as far as I know bit 31 is always parity bit, never used for
> >> actual data contents. Which is the spec section that got you confused?
> >> Maybe I'm the one which didn't read it well?
> > 
> > Sorry for being so late into the discussion.
> > 
> > I got confused by hi-3585_v-rev-l.pdf page 7 right, CR4 lets you treat
> > bit 32 as either data or parity. But I guess this is not the general
> > case.
> > 
> > So I wonder, does it make sense to treat the P bit as data always and do
> > parity in software or not ?
> 
> I don't have an strong opinion on this, truth be told. It really
> depends on whether we can tell the HW "go compute the parity
> yourself". If we can ask for that, maybe we should allow configuring
> that in the API with some flag. But anyway, treating P as data (i.e.
> software should set parity bit to whatever is needed) is the most
> generic thing you could do for a start, that shouldn't be wrong.

OK, let's treat it as data.

Since RC1 is out, I should start reworking the framework into more sensible
shape and repost before I miss the opportunity.

Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH -next] net: tcp: move to timewait when receiving data post active-close

[Hannes Frederic Sowa]

On Wed, Nov 18, 2015, at 18:28, Eric Dumazet wrote:
> On Wed, 2015-11-18 at 16:54 +0100, Hannes Frederic Sowa wrote:
> 
> > Still, the RST packet can be dropped along the way. So the teardown of
> > the socket on the other side might not happen.
> 
> This is why it is better to send RST for every incoming in-excess packet

I agree it would be better to send a RST than ACK incoming data. Just
thinking out loud, would it make sense to add a sub-state to timewait so
we RST all other packets for TIMEWAIT_LEN duration?

> Try following packetdrill test, before and after your patch :
> 
> 0.000 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
> 0.000 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
> 0.000 bind(3, ..., ...) = 0
> 0.000 listen(3, 1) = 0
> 0.100 < S 0:0(0) win 29200 
> 0.100 > S. 0:0(0) ack 1 
> 0.200 < . 1:1(0) ack 1 win 257
> 0.200 accept(3, ..., ...) = 4
> // close our side.
> 0.210 close(4) = 0
> // we should expect to see FIN now, sk moves to FIN_WAIT_1
> 0.210 > F. 1:1(0) ack 1 win 29200
> 
> // receive data, but sk already closed -> Reset
> +.010 < P. 1:1001(1000) ack 1 win 46
> +0> R 1:1(0) win 0
> 
> // Are we properly sending a RST like prior packet did ?
> +.010 < P. 1001:2001(1000) ack 1 win 46
> +0> R 1:1(0) win 0

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

Re: [PATCH] ethernet/atheros/alx: add Killer E2400 device ID

[Sergei Shtylyov]

On 11/18/2015 05:52 PM, Jason Gerard DeRose wrote:


From: Ben Pope 

This patch adds the PCI device ID (0xe0a1) and alx_pci_tbl entry for the
Killer E2400 Ethernet controller, modeled after the Killer E2200
controller support (0xe091) already present in the alx driver.

This patch was originally authored by Ben Pope, but it got held up by
issues in the commit message, so I'm resubmitting it on his behalf.

I've extensively used a kernel with this patch on a System76 serw9
laptop and am quite confident it works well (at least on the hardware I
have available for testing).

Note that as a favor to System76, Ubuntu has been carrying this as a
sauce patch in their 4.2 based Wily kernel, which presumably has given
it real-world testing on other E2400 equipped hardware (I don't know of
any Ubuntu kernel bugs filed about it):

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1498633

Signed-off-by: Jason Gerard DeRose 


No sign-off from Ben?


Apologies, this is my first time submitting a kernel patch :)

Should I use git send-email to send this again,


   I didn't notice if your mailer corrupted the patch but if it did 'git 
send-email' should be used indeed.



this time with the sign-off from Ben?


   No need to resend if it wasn't corrupted. Just replying to this patch with 
his sign-off should be enough -- patchwork should collect the tags from the 
follow-ups.



And if so, should I do so as a reply to this thread?


   No, not on this list. DaveM prefers the patch reposts to be done as the 
fresh new postings.



Thanks for you time!


   Your, I guess? Not at all. :-)

MBR, Sergei

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

Re: [PATCH -next] net: tcp: move to timewait when receiving data post active-close

[Florian Westphal]

Eric Dumazet  wrote:
> On Wed, 2015-11-18 at 16:54 +0100, Hannes Frederic Sowa wrote:
> 
> > Still, the RST packet can be dropped along the way. So the teardown of
> > the socket on the other side might not happen.
> 
> This is why it is better to send RST for every incoming in-excess packet

I'm convinced and marked patch as rejected in patchwork.

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

Re: [PATCH net] net/ip6_tunnel: fix dst leak

[Martin KaFai Lau]

On Wed, Nov 18, 2015 at 04:40:19PM +0100, Paolo Abeni wrote:
> the commit cdf3464e6c6b ("ipv6: Fix dst_entry refcnt bugs in ip6_tunnel")
> introduced percpu storage for ip6_tunnel dst cache, but while clearing
> such cache it used raw_cpu_ptr to walk the per cpu entries, so cached
> dst on non current cpu are not actually reset.
>
> This patch replaces raw_cpu_ptr with per_cpu_ptr, properly cleaning
> such storage.
Thanks for fixing it.

Acked-by: Martin KaFai Lau 

>
> Fixes: cdf3464e6c6b ("ipv6: Fix dst_entry refcnt bugs in ip6_tunnel")
>
> Signed-off-by: Paolo Abeni 
> ---
>  net/ipv6/ip6_tunnel.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
> index eabffbb..137fca4 100644
> --- a/net/ipv6/ip6_tunnel.c
> +++ b/net/ipv6/ip6_tunnel.c
> @@ -177,7 +177,7 @@ void ip6_tnl_dst_reset(struct ip6_tnl *t)
>   int i;
>
>   for_each_possible_cpu(i)
> - ip6_tnl_per_cpu_dst_set(raw_cpu_ptr(t->dst_cache), NULL);
> + ip6_tnl_per_cpu_dst_set(per_cpu_ptr(t->dst_cache, i), NULL);
>  }
>  EXPORT_SYMBOL_GPL(ip6_tnl_dst_reset);
>
> --
> 1.8.3.1
>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v7] net: ethernet: add driver for Aurora VLSI NB8800 Ethernet controller

[Mans Rullgard]

This adds a driver for the Aurora VLSI NB8800 Ethernet controller.
It is an almost complete rewrite of a driver originally found in
a Sigma Designs 2.6.22 tree.

Signed-off-by: Mans Rullgard 
---
Changes:
- fix int / unsigned int mismatch
- spell out "unsigned int"
---
 drivers/net/ethernet/Kconfig |1 +
 drivers/net/ethernet/Makefile|1 +
 drivers/net/ethernet/aurora/Kconfig  |   20 +
 drivers/net/ethernet/aurora/Makefile |1 +
 drivers/net/ethernet/aurora/nb8800.c | 1552 ++
 drivers/net/ethernet/aurora/nb8800.h |  316 +++
 6 files changed, 1891 insertions(+)
 create mode 100644 drivers/net/ethernet/aurora/Kconfig
 create mode 100644 drivers/net/ethernet/aurora/Makefile
 create mode 100644 drivers/net/ethernet/aurora/nb8800.c
 create mode 100644 drivers/net/ethernet/aurora/nb8800.h

diff --git a/drivers/net/ethernet/Kconfig b/drivers/net/ethernet/Kconfig
index 05aa759..8310163 100644
--- a/drivers/net/ethernet/Kconfig
+++ b/drivers/net/ethernet/Kconfig
@@ -29,6 +29,7 @@ source "drivers/net/ethernet/apm/Kconfig"
 source "drivers/net/ethernet/apple/Kconfig"
 source "drivers/net/ethernet/arc/Kconfig"
 source "drivers/net/ethernet/atheros/Kconfig"
+source "drivers/net/ethernet/aurora/Kconfig"
 source "drivers/net/ethernet/cadence/Kconfig"
 source "drivers/net/ethernet/adi/Kconfig"
 source "drivers/net/ethernet/broadcom/Kconfig"
diff --git a/drivers/net/ethernet/Makefile b/drivers/net/ethernet/Makefile
index ddfc808..b435fb0 100644
--- a/drivers/net/ethernet/Makefile
+++ b/drivers/net/ethernet/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_NET_XGENE) += apm/
 obj-$(CONFIG_NET_VENDOR_APPLE) += apple/
 obj-$(CONFIG_NET_VENDOR_ARC) += arc/
 obj-$(CONFIG_NET_VENDOR_ATHEROS) += atheros/
+obj-$(CONFIG_NET_VENDOR_AURORA) += aurora/
 obj-$(CONFIG_NET_CADENCE) += cadence/
 obj-$(CONFIG_NET_BFIN) += adi/
 obj-$(CONFIG_NET_VENDOR_BROADCOM) += broadcom/
diff --git a/drivers/net/ethernet/aurora/Kconfig 
b/drivers/net/ethernet/aurora/Kconfig
new file mode 100644
index 000..a3c7106
--- /dev/null
+++ b/drivers/net/ethernet/aurora/Kconfig
@@ -0,0 +1,20 @@
+config NET_VENDOR_AURORA
+   bool "Aurora VLSI devices"
+   help
+ If you have a network (Ethernet) device belonging to this class,
+ say Y.
+
+ Note that the answer to this question doesn't directly affect the
+ kernel: saying N will just cause the configurator to skip all
+ questions about Aurora devices. If you say Y, you will be asked
+ for your specific device in the following questions.
+
+if NET_VENDOR_AURORA
+
+config AURORA_NB8800
+   tristate "Aurora AU-NB8800 support"
+   select PHYLIB
+   help
+Support for the AU-NB8800 gigabit Ethernet controller.
+
+endif
diff --git a/drivers/net/ethernet/aurora/Makefile 
b/drivers/net/ethernet/aurora/Makefile
new file mode 100644
index 000..6cb528a
--- /dev/null
+++ b/drivers/net/ethernet/aurora/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_AURORA_NB8800) += nb8800.o
diff --git a/drivers/net/ethernet/aurora/nb8800.c 
b/drivers/net/ethernet/aurora/nb8800.c
new file mode 100644
index 000..c55d000
--- /dev/null
+++ b/drivers/net/ethernet/aurora/nb8800.c
@@ -0,0 +1,1552 @@
+/*
+ * Copyright (C) 2015 Mans Rullgard 
+ *
+ * Mostly rewritten, based on driver from Sigma Designs.  Original
+ * copyright notice below.
+ *
+ *
+ * Driver for tangox SMP864x/SMP865x/SMP867x/SMP868x builtin Ethernet Mac.
+ *
+ * Copyright (C) 2005 Maxime Bizon 
+ *
+ * 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "nb8800.h"
+
+static void nb8800_tx_done(struct net_device *dev);
+static int nb8800_dma_stop(struct net_device *dev);
+
+static inline u8 nb8800_readb(struct nb8800_priv *priv, int reg)
+{
+   return readb(priv->base + reg);
+}
+
+static inline u32 nb8800_readl(struct nb8800_priv *priv, int reg)
+{
+   return readl(priv->base + reg);
+}
+
+static inline void nb8800_writeb(struct nb8800_priv *priv, int reg, u8 val)
+{
+   writeb(val, priv->base + reg);
+}
+
+static inline void nb8800_writew(struct nb8800_priv *priv, int reg, u16 val)
+{
+   writew(val, priv->base + reg);
+}
+
+static inline void nb8800_writel(struct nb8800_priv *priv, int reg, u32 val)
+{
+   writel(val, priv->base + reg);
+}
+
+static 

Re: [PATCH -next] net: tcp: move to timewait when receiving data post active-close

[Eric Dumazet]

On Wed, 2015-11-18 at 16:54 +0100, Hannes Frederic Sowa wrote:

> Still, the RST packet can be dropped along the way. So the teardown of
> the socket on the other side might not happen.

This is why it is better to send RST for every incoming in-excess packet

Try following packetdrill test, before and after your patch :

0.000 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
0.000 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
0.000 bind(3, ..., ...) = 0
0.000 listen(3, 1) = 0
0.100 < S 0:0(0) win 29200 
0.100 > S. 0:0(0) ack 1 
0.200 < . 1:1(0) ack 1 win 257
0.200 accept(3, ..., ...) = 4
// close our side.
0.210 close(4) = 0
// we should expect to see FIN now, sk moves to FIN_WAIT_1
0.210 > F. 1:1(0) ack 1 win 29200

// receive data, but sk already closed -> Reset
+.010 < P. 1:1001(1000) ack 1 win 46
+0> R 1:1(0) win 0

// Are we properly sending a RST like prior packet did ?
+.010 < P. 1001:2001(1000) ack 1 win 46
+0> R 1:1(0) win 0



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

Re: [PATCH -next] net: tcp: move to timewait when receiving data post active-close

[Eric Dumazet]

On Wed, 2015-11-18 at 16:36 +0100, Florian Westphal wrote:

> Yes, but we kill the socket.
> 
> I should have added
> 
> 0.400 `ss -nito state time-wait`
> 
> as last line...
> 
> Before patch: no output
> after patch: tw socket shown.
> 
> The on-wire behavior doesn't change unless further packets arrive.
> Old behaviour: more RST
> New behaviour: acks+tw timer restart

Just add few more incoming packets to the packetdrill test then ?

Also, is your customer really _not_ using TCP timestamps ?

This is kind of a requirement for port reuse anyway.

Anyway, having a TIMEWAIT setup after sending a RST makes little sense
to me.

When a RST packet is sent, the remote peer will forget everything about
this previous connection, and another connect() might reuse the tuple
and I do not think we should forbid this. Normal PAWS checks were
invented for a good reason.

RFC 1122, 4.2.2.13 can be interpreted in very different ways.

Please show us real issue your customer has.



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

RE: next build: 235 warnings 3 failures (next/next-20151117)

[David Laight]

From: Will Deacon [mailto:will.dea...@arm.com]
> Sent: 18 November 2015 15:37
> On Wed, Nov 18, 2015 at 03:21:19PM +, David Laight wrote:
> > From: Will Deacon
> > > Sent: 18 November 2015 12:28
> > > On Wed, Nov 18, 2015 at 12:11:25PM +, David Laight wrote:
> > > > From: Will Deacon
> > > > >   
> > > > > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-November/386094.html
> > > >
> > > > That patch forces a memory write-read and returns uninitialised stack
> > > > for short reads.
> > >
> > > Really? The disassembly looks fine to me. Do you have a concrete example
> > > of where you think it goes wrong, please?
> > >
> > > > Who knows what happens on big-endian systems.
> > >
> > > The same thing as READ_ONCE? I'll test it there to make sure, but I
> > > don't see a problem.
> >
> > Ah, god, it is absolutely horrid. But probably right :-(
> 
> Yeah, I wasn't pretending it was nice :) FWIW, I've given it a reasonable
> testing in both little-endian and big-endian configurations and it seems
> to be happy.

I was missing the fact that the *(int_type *) is always reading
the full union.
The next version of the compiler might decide to barf at the code
that appears to be reading beyond the end of the union.

> > Do all the lda variants zero extend to 64 bits ?
> 
> Yes.
> 
> > If so maybe you could use a single 64 bit variable for the result of the 
> > read
> > and then cast it to typeof(*p) to get the required sign extension for
> > small integer types.
> 
> That was the original proposal from Arnd, but I want this to work with
> structures smaller than 64-bit (e.g. arch_spinlock_t), so that's why
> I decided to follow the approach laid down by READ_ONCE.

That would still be ok.
You'd have something that is effectively:
_u64 val = *p;
return typeof(*p)val;
The compiler might mask unsigned values - but it may be able to
determine it isn't needed (which is probably true of your version).
For signed types both versions require the compile sign-extend
the value.

David

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

Re: [PATCH -next] net: tcp: move to timewait when receiving data post active-close

[Florian Westphal]

Eric Dumazet  wrote:
> On Wed, 2015-11-18 at 16:03 +0100, Florian Westphal wrote:
> > RFC 1122, 4.2.2.13:
> >  [..] if new data is received after CLOSE is called, its TCP
> >  SHOULD send a RST to show that data was lost.
> > 
> >  When a connection is closed actively, it MUST linger in
> >  TIME-WAIT state [..].
> > 
> > We reset a connection, but destroy state immediately.
> > 
> > After discussing this with Hannes, we decided it was preferable
> > to also move to TW state to avoid immediate port reuse.
> > 
> > packetdrill testcase:
> > 
> > 0.000 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
> > 0.000 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
> > 0.000 bind(3, ..., ...) = 0
> > 0.000 listen(3, 1) = 0
> > 0.100 < S 0:0(0) win 29200 
> > 0.100 > S. 0:0(0) ack 1 
> > 0.200 < . 1:1(0) ack 1 win 257
> > 0.200 accept(3, ..., ...) = 4
> > // close our side.
> > 0.210 close(4) = 0
> > // we should expect to see FIN now, sk moves to FIN_WAIT_1
> > 0.210 > F. 1:1(0) ack 1 win 29200
> > // receive data, but sk already closed -> Reset
> > 0.300 < P. 1:1001(1000) ack 1 win 46
> > 0.300 > R 1:1(0) win 0


> This packetdrill test shows nothing special regarding your patch, it
> should work right now with current kernels ???

Yes, but we kill the socket.

I should have added

0.400 `ss -nito state time-wait`

as last line...

Before patch: no output
after patch: tw socket shown.

The on-wire behavior doesn't change unless further packets arrive.
Old behaviour: more RST
New behaviour: acks+tw timer restart

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

Re: next build: 235 warnings 3 failures (next/next-20151117)

[Will Deacon]

On Wed, Nov 18, 2015 at 03:21:19PM +, David Laight wrote:
> From: Will Deacon
> > Sent: 18 November 2015 12:28
> > On Wed, Nov 18, 2015 at 12:11:25PM +, David Laight wrote:
> > > From: Will Deacon
> > > >   
> > > > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-November/386094.html
> > >
> > > That patch forces a memory write-read and returns uninitialised stack
> > > for short reads.
> > 
> > Really? The disassembly looks fine to me. Do you have a concrete example
> > of where you think it goes wrong, please?
> > 
> > > Who knows what happens on big-endian systems.
> > 
> > The same thing as READ_ONCE? I'll test it there to make sure, but I
> > don't see a problem.
> 
> Ah, god, it is absolutely horrid. But probably right :-(

Yeah, I wasn't pretending it was nice :) FWIW, I've given it a reasonable
testing in both little-endian and big-endian configurations and it seems
to be happy.

> Do all the lda variants zero extend to 64 bits ?

Yes.

> If so maybe you could use a single 64 bit variable for the result of the read
> and then cast it to typeof(*p) to get the required sign extension for
> small integer types.

That was the original proposal from Arnd, but I want this to work with
structures smaller than 64-bit (e.g. arch_spinlock_t), so that's why
I decided to follow the approach laid down by READ_ONCE.

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

Re: Add a SOCK_DESTROY operation to close sockets from userspace

[Eric Dumazet]

On Wed, 2015-11-18 at 15:56 +0100, Hannes Frederic Sowa wrote:
> On Wed, Nov 18, 2015, at 15:45, Lorenzo Colitti wrote:
> > On Wed, Nov 18, 2015 at 10:31 PM, Hannes Frederic Sowa
> >  wrote:
> > > I was not saying using tcp_close literally, sorry for not making that
> > > clear, but just model the state transitions after tcp_close. At least it
> > > seems like a normal close to me.
> > 
> > But it shouldn't be a normal close. Consider calling SOCK_DESTROY on a
> > socket that is streaming data to a peer. If SOCK_DESTROY results in
> > the kernel sending a FIN, the remote side might think that the sender
> > closed the connection gracefully, even though the local side aborted
> > the connection.
> 
> Oh, yes, I understand. The connection wasn't closed by the application
> but by the administrator forcefully. So we should never indicate a
> successful TCP shutdown with FIN but with RST. A TIME_WAIT period
> actuallty still seems useful to me, maybe with different semantics, only
> RST incoming data?

There is some confusion.

TIME_WAIT are used to be able to send ACK packets to incoming valid
packets.

To send RST, you need nothing at all.

TIME_WAIT are hints for normal ending connections, to handle old packets
(and or duplicates)



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

Re: Add a SOCK_DESTROY operation to close sockets from userspace

[Hannes Frederic Sowa]

On Wed, Nov 18, 2015, at 16:16, Eric Dumazet wrote:
> On Wed, 2015-11-18 at 15:56 +0100, Hannes Frederic Sowa wrote:
> > On Wed, Nov 18, 2015, at 15:45, Lorenzo Colitti wrote:
> > > On Wed, Nov 18, 2015 at 10:31 PM, Hannes Frederic Sowa
> > >  wrote:
> > > > I was not saying using tcp_close literally, sorry for not making that
> > > > clear, but just model the state transitions after tcp_close. At least it
> > > > seems like a normal close to me.
> > > 
> > > But it shouldn't be a normal close. Consider calling SOCK_DESTROY on a
> > > socket that is streaming data to a peer. If SOCK_DESTROY results in
> > > the kernel sending a FIN, the remote side might think that the sender
> > > closed the connection gracefully, even though the local side aborted
> > > the connection.
> > 
> > Oh, yes, I understand. The connection wasn't closed by the application
> > but by the administrator forcefully. So we should never indicate a
> > successful TCP shutdown with FIN but with RST. A TIME_WAIT period
> > actuallty still seems useful to me, maybe with different semantics, only
> > RST incoming data?
> 
> There is some confusion.
> 
> TIME_WAIT are used to be able to send ACK packets to incoming valid
> packets.

I was only talking to prevent fast address/port reuse on the same socket
and preventing delayed packets being accepted by a 
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH -next] net: tcp: move to timewait when receiving data post active-close

[Hannes Frederic Sowa]

On Wed, Nov 18, 2015, at 16:46, Eric Dumazet wrote:
> On Wed, 2015-11-18 at 16:36 +0100, Florian Westphal wrote:
> 
> > Yes, but we kill the socket.
> > 
> > I should have added
> > 
> > 0.400 `ss -nito state time-wait`
> > 
> > as last line...
> > 
> > Before patch: no output
> > after patch: tw socket shown.
> > 
> > The on-wire behavior doesn't change unless further packets arrive.
> > Old behaviour: more RST
> > New behaviour: acks+tw timer restart
> 
> Just add few more incoming packets to the packetdrill test then ?
> 
> Also, is your customer really _not_ using TCP timestamps ?

Windows mostly does not use TCP timestamps. Also we have cases were
security folks tell customers to turn off timestamps as they enable
attackers to guess uptime. :(

> This is kind of a requirement for port reuse anyway.
> 
> Anyway, having a TIMEWAIT setup after sending a RST makes little sense
> to me.
> 
> When a RST packet is sent, the remote peer will forget everything about
> this previous connection, and another connect() might reuse the tuple
> and I do not think we should forbid this. Normal PAWS checks were
> invented for a good reason.

Still, the RST packet can be dropped along the way. So the teardown of
the socket on the other side might not happen.

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

Re: [PATCH 13/14] mm: memcontrol: account socket memory in unified hierarchy memory controller

[Michal Hocko]

On Mon 16-11-15 13:18:10, Johannes Weiner wrote:
> On Mon, Nov 16, 2015 at 04:59:25PM +0100, Michal Hocko wrote:
> > On Thu 12-11-15 18:41:32, Johannes Weiner wrote:
> > > Socket memory can be a significant share of overall memory consumed by
> > > common workloads. In order to provide reasonable resource isolation in
> > > the unified hierarchy, this type of memory needs to be included in the
> > > tracking/accounting of a cgroup under active memory resource control.
> > > 
> > > Overhead is only incurred when a non-root control group is created AND
> > > the memory controller is instructed to track and account the memory
> > > footprint of that group. cgroup.memory=nosocket can be specified on
> > > the boot commandline to override any runtime configuration and
> > > forcibly exclude socket memory from active memory resource control.
> > 
> > Do you have any numbers about the overhead?
> 
> Hm? Performance numbers make sense when you have a specific scenario
> and a theory on how to optimize the implementation for it.

The fact that there was a strong push to use static branches to put
the code out of line to reduce an overhead before the feature was
merged shows that people are sensitive to network performance and that
significant effort has been spent to eliminate it. My point was that you
are enabling the feature for all memcg users in unified hierarchy now
without having a performance impact overview which users can use
to judge whether to keep it enabled or disable before they start seeing
regressions or to make regression easier to track once it happens.

> What load would you test and what would be the baseline to compare it
> to?

It seems like netperf with a stream load running in a memcg with no
limits vs. in root memcg (and no other cgroups) should give at least a
hint about the runtime overhead, no?
-- 
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 21/27] realtek: create separate Kconfig file

[Larry Finger]

On 11/18/2015 08:46 AM, Kalle Valo wrote:

Add new a Kconfig file and a vendor config for realtek. Also update MAINTAINERS
which we missed to do when earlier moving rtlwifi.

Signed-off-by: Kalle Valo 
---


Acked-by: Larry Finger 

Thanks,

Larry


  MAINTAINERS  |8 
  drivers/net/wireless/Kconfig |5 +
  drivers/net/wireless/Makefile|3 +--
  drivers/net/wireless/realtek/Kconfig |   18 ++
  4 files changed, 24 insertions(+), 10 deletions(-)
  create mode 100644 drivers/net/wireless/realtek/Kconfig

diff --git a/MAINTAINERS b/MAINTAINERS
index 2c41981e4fdd..a9f7f968f64e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9035,7 +9035,7 @@ L:linux-wirel...@vger.kernel.org
  W:http://wireless.kernel.org/
  T:git 
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git
  S:Orphan
-F: drivers/net/wireless/rtl818x/rtl8180/
+F: drivers/net/wireless/realtek/rtl818x/rtl8180/

  RTL8187 WIRELESS DRIVER
  M:Herton Ronaldo Krzesinski 
@@ -9045,7 +9045,7 @@ L:linux-wirel...@vger.kernel.org
  W:http://wireless.kernel.org/
  T:git 
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git
  S:Maintained
-F: drivers/net/wireless/rtl818x/rtl8187/
+F: drivers/net/wireless/realtek/rtl818x/rtl8187/

  RTL8192CE WIRELESS DRIVER
  M:Larry Finger 
@@ -9054,8 +9054,8 @@ L:linux-wirel...@vger.kernel.org
  W:http://wireless.kernel.org/
  T:git 
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git
  S:Maintained
-F: drivers/net/wireless/rtlwifi/
-F: drivers/net/wireless/rtlwifi/rtl8192ce/
+F: drivers/net/wireless/realtek/rtlwifi/
+F: drivers/net/wireless/realtek/rtlwifi/rtl8192ce/

  RTL8XXXU WIRELESS DRIVER (rtl8xxxu)
  M:Jes Sorensen 
diff --git a/drivers/net/wireless/Kconfig b/drivers/net/wireless/Kconfig
index c92671f8b1c6..28af8b10a66e 100644
--- a/drivers/net/wireless/Kconfig
+++ b/drivers/net/wireless/Kconfig
@@ -24,6 +24,7 @@ source "drivers/net/wireless/cisco/Kconfig"
  source "drivers/net/wireless/intel/Kconfig"
  source "drivers/net/wireless/intersil/Kconfig"
  source "drivers/net/wireless/marvell/Kconfig"
+source "drivers/net/wireless/realtek/Kconfig"
  source "drivers/net/wireless/st/Kconfig"
  source "drivers/net/wireless/zydas/Kconfig"

@@ -81,8 +82,6 @@ config USB_NET_RNDIS_WLAN

  If you choose to build a module, it'll be called rndis_wlan.

-source "drivers/net/wireless/realtek/rtl818x/Kconfig"
-
  config MAC80211_HWSIM
tristate "Simulated radio testing tool for mac80211"
depends on MAC80211
@@ -99,8 +98,6 @@ config MAC80211_HWSIM
  source "drivers/net/wireless/ath/Kconfig"
  source "drivers/net/wireless/rt2x00/Kconfig"
  source "drivers/net/wireless/mediatek/Kconfig"
-source "drivers/net/wireless/realtek/rtlwifi/Kconfig"
-source "drivers/net/wireless/realtek/rtl8xxxu/Kconfig"
  source "drivers/net/wireless/ti/Kconfig"
  source "drivers/net/wireless/rsi/Kconfig"

diff --git a/drivers/net/wireless/Makefile b/drivers/net/wireless/Makefile
index 679a1a0a048d..12f6c59668a5 100644
--- a/drivers/net/wireless/Makefile
+++ b/drivers/net/wireless/Makefile
@@ -9,11 +9,10 @@ obj-$(CONFIG_WLAN_VENDOR_CISCO) += cisco/
  obj-$(CONFIG_WLAN_VENDOR_INTEL) += intel/
  obj-$(CONFIG_WLAN_VENDOR_INTERSIL) += intersil/
  obj-$(CONFIG_WLAN_VENDOR_MARVELL) += marvell/
+obj-$(CONFIG_WLAN_VENDOR_REALTEK) += realtek/
  obj-$(CONFIG_WLAN_VENDOR_ST) += st/
  obj-$(CONFIG_WLAN_VENDOR_ZYDAS) += zydas/

-obj-$(CONFIG_WLAN) += realtek/
-
  # 16-bit wireless PCMCIA client drivers
  obj-$(CONFIG_PCMCIA_RAYCS)+= ray_cs.o
  obj-$(CONFIG_PCMCIA_WL3501)   += wl3501_cs.o
diff --git a/drivers/net/wireless/realtek/Kconfig 
b/drivers/net/wireless/realtek/Kconfig
new file mode 100644
index ..8a8ba2003964
--- /dev/null
+++ b/drivers/net/wireless/realtek/Kconfig
@@ -0,0 +1,18 @@
+config WLAN_VENDOR_REALTEK
+   bool "Realtek devices"
+   default y
+   ---help---
+ If you have a wireless card belonging to this class, say Y.
+
+ Note that the answer to this question doesn't directly affect the
+ kernel: saying N will just cause the configurator to skip all
+ the questions about  cards. If you say Y, you will be asked for
+ your specific card in the following questions.
+
+if WLAN_VENDOR_REALTEK
+
+source "drivers/net/wireless/realtek/rtl818x/Kconfig"
+source "drivers/net/wireless/realtek/rtlwifi/Kconfig"
+source "drivers/net/wireless/realtek/rtl8xxxu/Kconfig"
+
+endif # WLAN_VENDOR_REALTEK



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

[PATCH net] net/ip6_tunnel: fix dst leak

[Paolo Abeni]

the commit cdf3464e6c6b ("ipv6: Fix dst_entry refcnt bugs in ip6_tunnel")
introduced percpu storage for ip6_tunnel dst cache, but while clearing
such cache it used raw_cpu_ptr to walk the per cpu entries, so cached
dst on non current cpu are not actually reset.

This patch replaces raw_cpu_ptr with per_cpu_ptr, properly cleaning
such storage.

Fixes: cdf3464e6c6b ("ipv6: Fix dst_entry refcnt bugs in ip6_tunnel")

Signed-off-by: Paolo Abeni 
---
 net/ipv6/ip6_tunnel.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index eabffbb..137fca4 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -177,7 +177,7 @@ void ip6_tnl_dst_reset(struct ip6_tnl *t)
int i;
 
for_each_possible_cpu(i)
-   ip6_tnl_per_cpu_dst_set(raw_cpu_ptr(t->dst_cache), NULL);
+   ip6_tnl_per_cpu_dst_set(per_cpu_ptr(t->dst_cache, i), NULL);
 }
 EXPORT_SYMBOL_GPL(ip6_tnl_dst_reset);
 
-- 
1.8.3.1

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

Re: [PATCH 14/14] mm: memcontrol: hook up vmpressure to socket pressure

[Vladimir Davydov]

On Tue, Nov 17, 2015 at 05:22:17PM -0500, Johannes Weiner wrote:
> On Tue, Nov 17, 2015 at 11:18:50PM +0300, Vladimir Davydov wrote:
> > AFAIK vmpressure was designed to allow userspace to tune hard limits of
> > cgroups in accordance with their demands, in which case the way how
> > vmpressure notifications work makes sense.
> 
> You can still do that when the reporting happens on the reclaim level,
> it's easy to figure out where the pressure comes from once a group is
> struggling to reclaim its LRU pages.

Right, one only needs to check usage-vs-limit in the cgroup that
received a notification and all its ascendants, but I doubt existing
applications do that.

> 
> Reporting on the pressure level does nothing but destroy valuable
> information that would be useful in scenarios other than tuning a
> hierarchical memory limit.

Agree.

> 
> > > But you guys were wary about the patch that changed it, and this
> > 
> > Changing vmpressure semantics as you proposed in v1 would result in
> > userspace getting notifications even if cgroup does not hit its limit.
> > May be it could be useful to someone (e.g. it could help tuning
> > memory.low), but I am pretty sure this would also result in breakages
> > for others.
> 
> Maybe. I'll look into a two-layer vmpressure recording/reporting model
> that would give us reclaim-level events internally while retaining
> pressure-level events for the existing userspace interface.

It would be great. I think vmpressure, as you propose to implement it,
could be useful even in the unified hierarchy for tuning memory.low and
memory.high.

> 
> > > series has kicked up enough dust already, so I backed it out.
> > > 
> > > But this will still be useful. Yes, it won't help in rebalancing an
> > > regularly working system, which would be cool, but it'll still help
> > > contain a worklad that is growing beyond expectations, which is the
> > > scenario that kickstarted this work.
> > 
> > I haven't looked through all the previous patches in the series, but
> > AFAIU they should do the trick, no? Notifying sockets about vmpressure
> > is rather needed to protect a workload from itself.
> 
> No, the only critical thing is to protect the system from OOM
> conditions caused by what should be containerized processes.
> 
> That's a correctness issue.
> 
> How much we mitigate the consequences inside the container when the
> workload screws up is secondary. But even that is already much better
> in this series compared to memcg v1, while leaving us with all the
> freedom to continue improving this internal mitigation in the future.
> 
> > And with this patch it will work this way, but only if sum limits <
> > total ram, which is rather rare in practice. On tightly packed
> > systems it does nothing.
> 
> That's not true, it's still useful when things go south inside a
> cgroup, even with overcommitted limits. See above.

I meant solely this patch here, not the rest of the patch set. In the
overcommitted case there is no difference if we have the last patch or
not AFAIU.

> 
> We can optimize the continuous global pressure rebalancing later on;
> whether that'll be based on a modified vmpressure implementation, or
> adding reclaim efficiency to the shrinker API or whatever.
> 
> > That said, I don't think we should commit this particular patch. Neither
> > do I think socket accounting should be enabled by default in the unified
> > hierarchy for now, since the implementation is still incomplete. IMHO.
> 
> I don't see a technical basis for either of those suggestions.
> 

IMHO users switching to the unified hierarchy don't expect that
something gets broken in the default setup unless it's a bug. They
expect API changes, new functionality appeared, some features dropped,
but not breakages.

With this patch set, one gets socket accounting enabled by default,
which would be OK if it always worked right, at least in theory. But it
does not if the node is overcommitted - one might get unexpected local
OOMs due to growing socket buffers, which have never been seen in the
legacy hierarchy.

You say that it will help coping with global OOM, which is true, but it
looks like trading an old problem for a new one, which is unaccepted in
this particular case IMHO, because the legacy hierarchy has been used
for years and people are likely to be used to old problems such as lack
of socket buffers accounting - they might already work around this
problem by tuning global tcp limits for instance. After switching to the
unified hierarchy they'll get a new problem in the default setup, which
is no good IMHO.

I'm not against enabling socket buffers accounting by default, but only
once it is expected to work in 99% cases, at least theoretically.

Why can't we apply all patches but the last one (they look OK at first
glance, but I need more time to review them carefully) and disable
socket accounting by default for now? Then you or someone else would
prepare a separate patch set introducing vmpressure 

Re: [RFC][PATCH] net: arinc429: Add ARINC-429 stack

[Aleksander Morgado]

On Tue, Nov 10, 2015 at 5:15 PM, Marek Vasut  wrote:
>> >> >>> > About the parity -- can we add some flag into the datagram to
>> >> >>> > indicate we want hardware to calculate the parity for that
>> >> >>> > particular datagram for us? And we'd also need to indicate what
>> >> >>> > type of parity. I dunno if this is worth the hassle.
>> >> >>>
>> >> >>> This  is HW configuration property, it does not belong to  datagram.
>> >> >>> Also for TX channels,  parity could  be  two  kinds:  odd and even,
>> >> >>> for RX it is only on/off.
>> >> >>
>> >> >> There are datagrams which do contain parity and ones which do not
>> >> >> contain it, correct ? Thus, it's a property of that particular
>> >> >> datagram.
>> >>
>> >> All ARINC words have bit #31 as parity bit; whether it's used or not
>> >> depends on the setup as Andrey says below.
>> >
>> > Can bit 31 be ever used for DATA instead of parity ? Or is this just me
>> > not understanding the parlance of the specification, where "DATA"
>> > actually means "DATA with parity" ?
>>
>> Well, as far as I know bit 31 is always parity bit, never used for
>> actual data contents. Which is the spec section that got you confused?
>> Maybe I'm the one which didn't read it well?
>
> Sorry for being so late into the discussion.
>
> I got confused by hi-3585_v-rev-l.pdf page 7 right, CR4 lets you treat bit
> 32 as either data or parity. But I guess this is not the general case.
>
> So I wonder, does it make sense to treat the P bit as data always and do
> parity in software or not ?

I don't have an strong opinion on this, truth be told. It really
depends on whether we can tell the HW "go compute the parity
yourself". If we can ask for that, maybe we should allow configuring
that in the API with some flag. But anyway, treating P as data (i.e.
software should set parity bit to whatever is needed) is the most
generic thing you could do for a start, that shouldn't be wrong.

-- 
Aleksander
https://aleksander.es
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Add a SOCK_DESTROY operation to close sockets from userspace

[Hannes Frederic Sowa]

On Wed, Nov 18, 2015, at 16:32, Hannes Frederic Sowa wrote:
> On Wed, Nov 18, 2015, at 16:16, Eric Dumazet wrote:
> > On Wed, 2015-11-18 at 15:56 +0100, Hannes Frederic Sowa wrote:
> > > On Wed, Nov 18, 2015, at 15:45, Lorenzo Colitti wrote:
> > > > On Wed, Nov 18, 2015 at 10:31 PM, Hannes Frederic Sowa
> > > >  wrote:
> > > > > I was not saying using tcp_close literally, sorry for not making that
> > > > > clear, but just model the state transitions after tcp_close. At least 
> > > > > it
> > > > > seems like a normal close to me.
> > > > 
> > > > But it shouldn't be a normal close. Consider calling SOCK_DESTROY on a
> > > > socket that is streaming data to a peer. If SOCK_DESTROY results in
> > > > the kernel sending a FIN, the remote side might think that the sender
> > > > closed the connection gracefully, even though the local side aborted
> > > > the connection.
> > > 
> > > Oh, yes, I understand. The connection wasn't closed by the application
> > > but by the administrator forcefully. So we should never indicate a
> > > successful TCP shutdown with FIN but with RST. A TIME_WAIT period
> > > actuallty still seems useful to me, maybe with different semantics, only
> > > RST incoming data?
> > 
> > There is some confusion.
> > 
> > TIME_WAIT are used to be able to send ACK packets to incoming valid
> > packets.
> 
> I was only talking to prevent fast address/port reuse on the same socket
> and preventing delayed packets being accepted by a 

sorry...

accepted by a later connection reusing the same quadrupel.

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

Your Package

[FedExDelivery]

-- 
We have a parcel right here in our office to be delivered to you...
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[iproute PATCH 2/2] lnstat: fix header displaying mechanism

[Phil Sutter]

The algorithm depends on the loop counter ('i') to increment by one in
each iteration. Though if running endlessly (count==0), the counter was
not incremented at all.

Also change formatting of the header printing conditional a bit so it's
hopefully easier to read.

Fixes: e7e2913 ("lnstat: run indefinitely by default")
Signed-off-by: Phil Sutter 
---
 misc/lnstat.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/misc/lnstat.c b/misc/lnstat.c
index 529bc33..264c953 100644
--- a/misc/lnstat.c
+++ b/misc/lnstat.c
@@ -359,21 +359,19 @@ int main(int argc, char **argv)
if (interval < 1 )
interval = 1;
 
-   for (i = 0; i < count || !count; ) {
+   for (i = 0; i < count || !count; i++) {
lnstat_update(lnstat_files);
if (mode == MODE_JSON)
print_json(stdout, lnstat_files, );
else {
-   if  ((hdr > 1 &&
- (! (i % 20))) || (hdr == 1 && i == 0))
+   if  ((hdr > 1 && !(i % 20)) ||
+(hdr == 1 && i == 0))
print_hdr(stdout, header);
print_line(stdout, lnstat_files, );
}
fflush(stdout);
if (i < count - 1 || !count)
sleep(interval);
-   if (count)
-   ++i;
}
break;
}
-- 
2.5.0

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

[iproute PATCH 0/2] lnstat: review --subject option

[Phil Sutter]

Add missing description in help output, fix algorithm.

Phil Sutter (2):
  lnstat: describe -s option in help output
  lnstat: fix header displaying mechanism

 misc/lnstat.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

-- 
2.5.0

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

[iproute PATCH 1/2] lnstat: describe -s option in help output

[Phil Sutter]

Signed-off-by: Phil Sutter 
---
 misc/lnstat.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/misc/lnstat.c b/misc/lnstat.c
index 1e547d0..529bc33 100644
--- a/misc/lnstat.c
+++ b/misc/lnstat.c
@@ -73,7 +73,10 @@ static int usage(char *name, int exit_code)
fprintf(stderr, "\t-i --interval \t"
"Set interval to 'intv' seconds\n");
fprintf(stderr, "\t-k --keys k,k,k,...\tDisplay only keys specified\n");
-   fprintf(stderr, "\t-s --subject [0-2]\t?\n");
+   fprintf(stderr, "\t-s --subject [0-2]\tControl header printing:\n");
+   fprintf(stderr, "\t\t\t\t0 = never\n");
+   fprintf(stderr, "\t\t\t\t1 = once\n");
+   fprintf(stderr, "\t\t\t\t2 = every 20 lines (default))\n");
fprintf(stderr, "\t-w --width n,n,n,...\tWidth for each field\n");
fprintf(stderr, "\n");
 
-- 
2.5.0

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

Re: [PATCH] unix: avoid use-after-free in ep_remove_wait_queue (w/ Fixes:)

[Rainer Weikusat]

David Miller  writes:
> From: Rainer Weikusat 
> Date: Mon, 16 Nov 2015 22:28:40 +
>
>> An AF_UNIX datagram socket being the client in an n:1

[...]

> So because of a corner case of epoll handling and sender socket release,
> every single datagram sendmsg has to do a double lock now?
>
> I do not dispute the correctness of your fix at this point, but that
> added cost in the fast path is really too high.

Some more information on this: Running the test program included below
on my 'work' system (otherwise idle, after logging in via VT with no GUI
running)/ quadcore AMD A10-5700, 3393.984 for 20 times/ patched 4.3 resulted in 
the
following throughput statistics[*]:

avg 13.617  M/s
median  13.393  M/s
max 17.14   M/s
min 13.047  M/s
deviation   0.85

I'll try to post the results for 'unpatched' later as I'm also working
on a couple of other things.

[*] I do not use my fingers for counting, hence, these are binary and
not decimal units.


#include 
#include 
#include 
#include 
#include 
#include 
#include 

enum {
MSG_SZ =16,
MSGS =  100
};

static char msg[MSG_SZ];

static uint64_t tv2u(struct timeval *tv)
{
uint64_t u;

u = tv->tv_sec;
u *= 100;
return u + tv->tv_usec;
}

int main(void)
{
struct timeval start, stop;
uint64_t t_diff;
double rate;
int sks[2];
unsigned remain;
char buf[MSG_SZ];

socketpair(AF_UNIX, SOCK_SEQPACKET, 0, sks);

if (fork() == 0) {
close(*sks);

gettimeofday(, 0);
while (read(sks[1], buf, sizeof(buf)) > 0);
gettimeofday(, 0);

t_diff = tv2u();
t_diff -= tv2u();
rate = MSG_SZ * MSGS;
rate /= t_diff;
rate *= 100;
printf("rate %fM/s\n", rate / (1 << 20));

fflush(stdout);
_exit(0);
}

close(sks[1]);

remain = MSGS;
do write(*sks, msg, sizeof(msg)); while (--remain);
close(*sks);

wait(NULL);
return 0;
}
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 net-next 1/5] net:hns: Add support of Hip06 SoC to the Hislicon Network Subsystem

[David Miller]

From: Salil 
Date: Wed, 18 Nov 2015 02:52:23 +0800

> @@ -387,19 +409,23 @@ static void hns_rcb_ring_get_cfg(struct hnae_queue *q, 
> int ring_type)
>   struct rcb_common_cb *rcb_common;
>   struct ring_pair_cb *ring_pair_cb;
>   u32 buf_size;
> - u16 desc_num;
> - int irq_idx;
> + u16 desc_num, mdnum_ppkt;
> + int irq_idx, is_ver1;

Please use "bool" and true/false for boolean conditions like is_ver1.

Please audit your entire submission for this problem.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net-next] net: encx24j600: quiet logging noise on open

[David Miller]

From: j...@ringle.org
Date: Tue, 17 Nov 2015 16:42:31 -0500

> From: Jon Ringle 
> 
> When encx24j600 is open and closed many times due to userspace polling the
> interface, the log gets noise with this log message. Change logging level
> to debug
> 
> Signed-off-by: Jon Ringle 

This should be moved into the probe method instead, as that's where
outputting something like that belongs.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ethernet/atheros/alx: add Killer E2400 device ID

[Jason Gerard DeRose]

On 11/18/2015 10:47 AM, Sergei Shtylyov wrote:

On 11/18/2015 05:52 PM, Jason Gerard DeRose wrote:


From: Ben Pope 

This patch adds the PCI device ID (0xe0a1) and alx_pci_tbl entry for
the
Killer E2400 Ethernet controller, modeled after the Killer E2200
controller support (0xe091) already present in the alx driver.

This patch was originally authored by Ben Pope, but it got held up by
issues in the commit message, so I'm resubmitting it on his behalf.

I've extensively used a kernel with this patch on a System76 serw9
laptop and am quite confident it works well (at least on the hardware I
have available for testing).

Note that as a favor to System76, Ubuntu has been carrying this as a
sauce patch in their 4.2 based Wily kernel, which presumably has given
it real-world testing on other E2400 equipped hardware (I don't know of
any Ubuntu kernel bugs filed about it):

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1498633

Signed-off-by: Jason Gerard DeRose 


No sign-off from Ben?


Apologies, this is my first time submitting a kernel patch :)

Should I use git send-email to send this again,


I didn't notice if your mailer corrupted the patch but if it did
'git send-email' should be used indeed.


I originally used `git send-email`, so the patch should not have been 
corrupted.



this time with the sign-off from Ben?


No need to resend if it wasn't corrupted. Just replying to this
patch with his sign-off should be enough -- patchwork should collect the
tags from the follow-ups.


Okay, thanks for the clarification!


And if so, should I do so as a reply to this thread?


No, not on this list. DaveM prefers the patch reposts to be done as
the fresh new postings.


Thanks for you time!


Your, I guess? Not at all. :-)


Also thank you for enduring my typos ;)


MBR, Sergei


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

Re: [PATCH -next] net: tcp: move to timewait when receiving data post active-close

[Eric Dumazet]

On Wed, 2015-11-18 at 18:35 +0100, Hannes Frederic Sowa wrote:
> On Wed, Nov 18, 2015, at 18:28, Eric Dumazet wrote:
> > On Wed, 2015-11-18 at 16:54 +0100, Hannes Frederic Sowa wrote:
> > 
> > > Still, the RST packet can be dropped along the way. So the teardown of
> > > the socket on the other side might not happen.
> > 
> > This is why it is better to send RST for every incoming in-excess packet
> 
> I agree it would be better to send a RST than ACK incoming data. Just
> thinking out loud, would it make sense to add a sub-state to timewait so
> we RST all other packets for TIMEWAIT_LEN duration?

Intuitively this timewait creation looks dangerous to me, maybe from
an attack surface perspective.

An out of sequence packet sends an advisory RST packet, which is already
a hint for building some kinds of attacks.

Now if we also create a timewait socket, and its associated timer, we
also add quite a risk of memory and cpu consumption.

So I am fine you create a timewait, only if you can prove there is no
change in security.

Thanks !


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

[PATCH iproute2] Add support for rt_tables.d

[David Ahern]

Add support for reading table id/name mappings from rt_tables.d
directory.

Signed-off-by: David Ahern 
---
 lib/rt_names.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/lib/rt_names.c b/lib/rt_names.c
index e87c65dad39e..d835ff9c7ee0 100644
--- a/lib/rt_names.c
+++ b/lib/rt_names.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -339,6 +340,8 @@ static int rtnl_rttable_init;
 
 static void rtnl_rttable_initialize(void)
 {
+   struct dirent *de;
+   DIR *d;
int i;
 
rtnl_rttable_init = 1;
@@ -348,6 +351,21 @@ static void rtnl_rttable_initialize(void)
}
rtnl_hash_initialize(CONFDIR "/rt_tables",
 rtnl_rttable_hash, 256);
+
+   d = opendir(CONFDIR "/rt_tables.d");
+   if (!d)
+   return;
+
+   while ((de = readdir(d)) != NULL) {
+   char path[PATH_MAX];
+
+   if (*de->d_name == '.')
+   continue;
+
+   snprintf(path, sizeof(path), CONFDIR "/rt_tables.d/%s", 
de->d_name);
+   rtnl_hash_initialize(path, rtnl_rttable_hash, 256);
+   }
+   closedir(d);
 }
 
 const char * rtnl_rttable_n2a(__u32 id, char *buf, int len)
-- 
1.9.1

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

Re: lockdep problem? netlink_dump & rtnl_lock

[Cong Wang]

On Wed, Nov 18, 2015 at 2:11 AM, Arkadiusz Miskiewicz
 wrote:
>
> Hi.
>
> I'm running 4.3.0 kernel (+ few backported mm patches). Machine is doing many 
> rsnapshots
> in parallel (so heavily loaded).
>
> I'm seeing this from time to time (below). What would be the reason for so 
> long hangs?


It is not a lockdep problem, it is that someone was holding that mutex
for a long time or that mutex was not released correctly.

Can you do a sysrq-t when you reproduce this problem?

Thanks!

>
> [ 2278.385668] INFO: task snmpd:1775 blocked for more than 120 seconds.
> [ 2278.392089]   Not tainted 4.3.0-0.1 #1
> [ 2278.396226] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
> this message.
> [ 2278.404111] snmpd   D 88081fc158c0 0  1775  1 
> 0x
> [ 2278.411229]  8807e6a8bcf8 0082 81c13500 
> 8807ebb88d80
> [ 2278.418753]  8807e6a8c000 8807ebb88d80 81cc7c84 
> 
> [ 2278.426286]  81cc7c88 8807e6a8bd10 8161c203 
> 81cc7c80
> [ 2278.433854] Call Trace:
> [ 2278.436341]  [] schedule+0x33/0x80
> [ 2278.441349]  [] schedule_preempt_disabled+0xe/0x10
> [ 2278.447733]  [] __mutex_lock_slowpath+0xb3/0x120
> [ 2278.453956]  [] mutex_lock+0x1f/0x30
> [ 2278.459133]  [] rtnl_lock+0x15/0x20
> [ 2278.464212]  [] devinet_ioctl+0xd2/0x6e0
> [ 2278.469757]  [] ? mntput+0x24/0x40
> [ 2278.474769]  [] ? __fput+0x142/0x200
> [ 2278.479955]  [] inet_ioctl+0x50/0x70
> [ 2278.485122]  [] sock_do_ioctl+0x25/0x50
> [ 2278.490578]  [] sock_ioctl+0x1d2/0x290
> [ 2278.495920]  [] do_vfs_ioctl+0x295/0x470
> [ 2278.501444]  [] ? sock_alloc_file+0xa6/0x130
> [ 2278.507338]  [] ? task_work_add+0x44/0x60
> [ 2278.512942]  [] ? fput+0x47/0x90
> [ 2278.517771]  [] SyS_ioctl+0x79/0x90
> [ 2278.522845]  [] entry_SYSCALL_64_fastpath+0x16/0x75
> [ 2278.529341] INFO: task sudo:4534 blocked for more than 120 seconds.
> [ 2278.535635]   Not tainted 4.3.0-0.1 #1
> [ 2278.539759] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
> this message.
> [ 2278.547680] sudoD  0  4534  1 
> 0x0004
> [ 2278.554825]  880080677bb8 0086 8807f3874380 
> 8807f3eb8000
> [ 2278.562389]  880080678000 8807f3eb8000 81cc7c84 
> 
> [ 2278.569914]  81cc7c88 880080677bd0 8161c203 
> 81cc7c80
> [ 2278.577436] Call Trace:
> [ 2278.579911]  [] schedule+0x33/0x80
> [ 2278.584918]  [] schedule_preempt_disabled+0xe/0x10
> [ 2278.591329]  [] __mutex_lock_slowpath+0xb3/0x120
> [ 2278.597571]  [] mutex_lock+0x1f/0x30
> [ 2278.602743]  [] __netlink_dump_start+0x5e/0x190
> [ 2278.608890]  [] ? rtnl_fill_ifinfo+0x13f0/0x13f0
> [ 2278.615105]  [] rtnetlink_rcv_msg+0x1bc/0x230
> [ 2278.621054]  [] ? rtnl_fill_ifinfo+0x13f0/0x13f0
> [ 2278.627262]  [] ? rtnetlink_rcv+0x30/0x30
> [ 2278.632861]  [] netlink_rcv_skb+0xa4/0xc0
> [ 2278.638463]  [] rtnetlink_rcv+0x28/0x30
> [ 2278.643908]  [] netlink_unicast+0x127/0x1a0
> [ 2278.649692]  [] netlink_sendmsg+0x4f4/0x5f0
> [ 2278.655480]  [] sock_sendmsg+0x38/0x50
> [ 2278.660830]  [] SyS_sendto+0x101/0x150
> [ 2278.666189]  [] ? sock_alloc_file+0xa6/0x130
> [ 2278.672064]  [] ? fd_install+0x25/0x30
> [ 2278.677407]  [] ? SyS_socket+0x9f/0xf0
> [ 2278.682749]  [] entry_SYSCALL_64_fastpath+0x16/0x75
>
>
>
>
>
>
>
>
>  [ 7433.492510] INFO: task bird:1503 blocked for more than 120 seconds.
> [ 7433.498819]   Not tainted 4.3.0-0.1 #1
> [ 7433.502954] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
> this message.
> [ 7433.510840] birdD 88081fd158c0 0  1503  1 
> 0x
> [ 7433.517966]  8807eb923bb8 0086 8807fb711b00 
> 8807f38a4380
> [ 7433.525493]  8807eb924000 8807f38a4380 81cc7c84 
> 
> [ 7433.533017]  81cc7c88 8807eb923bd0 8161c203 
> 81cc7c80
> [ 7433.540561] Call Trace:
> [ 7433.543050]  [] schedule+0x33/0x80
> [ 7433.548041]  [] schedule_preempt_disabled+0xe/0x10
> [ 7433.554415]  [] __mutex_lock_slowpath+0xb3/0x120
> [ 7433.560624]  [] mutex_lock+0x1f/0x30
> [ 7433.565810]  [] netlink_dump+0x21/0x2c0
> [ 7433.571236]  [] netlink_recvmsg+0x249/0x3d0
> [ 7433.577005]  [] sock_recvmsg+0x3b/0x50
> [ 7433.582347]  [] ___sys_recvmsg+0xdb/0x1f0
> [ 7433.587952]  [] ? __switch_to+0x25c/0x4a0
> [ 7433.593579]  [] ? update_curr+0xb7/0x130
> [ 7433.599115]  [] ? __enqueue_entity+0x6c/0x70
> [ 7433.604970]  [] ? set_next_entity+0x71/0x840
> [ 7433.610832]  [] ? __switch_to+0x25c/0x4a0
> [ 7433.616431]  [] __sys_recvmsg+0x51/0x90
> [ 7433.621873]  [] SyS_recvmsg+0x12/0x20
> [ 7433.627125]  [] entry_SYSCALL_64_fastpath+0x16/0x75
> [ 7433.633642] INFO: task kworker/3:4:12895 blocked for more than 120 seconds.
> [ 7433.640651]   Not tainted 4.3.0-0.1 #1
> [ 7433.644797] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
> this 

Re: [PATCH] net ipv4: use preferred log methods

[David Miller]

From: Bastian Stender 
Date: Fri, 13 Nov 2015 11:40:34 +0100

> Replace printk calls with preferred unconditional log method calls to keep
> kernel messages clean.
> 
> Added newline to "too small MTU" message.
> 
> Signed-off-by: Bastian Stender 

Applied to net-next, thanks.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 14/14] mm: memcontrol: hook up vmpressure to socket pressure

[Johannes Weiner]

On Wed, Nov 18, 2015 at 07:02:54PM +0300, Vladimir Davydov wrote:
> On Tue, Nov 17, 2015 at 05:22:17PM -0500, Johannes Weiner wrote:
> > On Tue, Nov 17, 2015 at 11:18:50PM +0300, Vladimir Davydov wrote:
> > > And with this patch it will work this way, but only if sum limits <
> > > total ram, which is rather rare in practice. On tightly packed
> > > systems it does nothing.
> > 
> > That's not true, it's still useful when things go south inside a
> > cgroup, even with overcommitted limits. See above.
> 
> I meant solely this patch here, not the rest of the patch set. In the
> overcommitted case there is no difference if we have the last patch or
> not AFAIU.

Even this patch, and even in the overcommitted case. When things go
bad inside a cgroup it can steal free memory (it's rare that machines
are at 100% utilization in practice) or memory from other groups until
it hits its own limit. I expect most users except, for some largescale
deployments, to frequently hit memory.high (or max) in practice.

Obviously the utopian case of full utilization will be even smoother
when we make vmpressure more finegrained, but why would that be an
argument *against* this patch here, which is useful everywhere else?

> Why can't we apply all patches but the last one (they look OK at first
> glance, but I need more time to review them carefully) and disable
> socket accounting by default for now? Then you or someone else would
> prepare a separate patch set introducing vmpressure propagation to
> socket code, so that socket accounting could be enabled by default.

This is not going to happen, and we discussed this several times
before. I really wish Michal and you would put more thought into
interface implications. It's trivial to fix up implementation if
actual shortcomings are observed, but it's nigh impossible to fix
interfaces and user-visible behavior once published. It requires
enormous undertakings such as unified hierarchy to rectify things.

Please take your time to review this series, no problem.

But I'm no longer reacting to suggestions to make interface tradeoffs
because new code is not proven to work 99% of the time. That's simply
ridiculous. Any problems will have to be fixed either way, and we're
giving users the cmdline options to work around them in the meantime.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 06/27] brcm80211: move under broadcom vendor directory

[Hauke Mehrtens]

On 11/18/2015 03:45 PM, Kalle Valo wrote:
> Part of reorganising wireless drivers directory and Kconfig. Note that I had 
> to
> edit Makefiles from subdirectories to use the new location.
> 
> Signed-off-by: Kalle Valo 
> ---

I would prefer to remove the brcm80211 directory in this process and create:
drivers/net/wireless/broadcom/brcmfmac
drivers/net/wireless/broadcom/brcmsmac
drivers/net/wireless/broadcom/brcmutil
drivers/net/wireless/broadcom/include

This way we have one directory less.

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

Re: [PATCH v3 net-next] net: hisilicon: fix binding document of mdio

[David Miller]

From: huangdaode 
Date: Wed, 18 Nov 2015 10:08:00 +0800

> This patch explains the occasion of "hisilcon,mdio" and
> "hisilicon,hns-mdio" according to Arnd's comments.
> and reformat it according to comments from Rob.
> 
> Signed-off-by: huangdaode 

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

Re: [PATCH v2 06/27] brcm80211: move under broadcom vendor directory

[Florian Fainelli]

On 18/11/15 11:19, Hauke Mehrtens wrote:
> On 11/18/2015 03:45 PM, Kalle Valo wrote:
>> Part of reorganising wireless drivers directory and Kconfig. Note that I had 
>> to
>> edit Makefiles from subdirectories to use the new location.
>>
>> Signed-off-by: Kalle Valo 
>> ---
> 
> I would prefer to remove the brcm80211 directory in this process and create:
> drivers/net/wireless/broadcom/brcmfmac
> drivers/net/wireless/broadcom/brcmsmac
> drivers/net/wireless/broadcom/brcmutil
> drivers/net/wireless/broadcom/include
> 
> This way we have one directory less.

Would not that make keeping track of the previous and future history
harder for people contributing to these drivers? I could imagine that
for Arend and other Broadcom engineers, dealing with a simple level move
would be manageable, but having to account for a different directory
hierarchy could be a pain.

What is the impact on compat-wireless after/before these changes by the way?
-- 
Florian
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] hdlc: fix null-deref on allocation failure

[David Miller]

From: Stephen Hemminger 
Date: Tue, 17 Nov 2015 14:26:06 -0800

> If alloc_netdev() failed and return NULL, then the next instruction
> would dereference it. Found by Coverity.
> 
> Compile tested only. Not sure if anyone still uses this driver
> (or the whole WAN subsystem).
> 
> Signed-off-by: Stephen Hemminger 

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

Re: [PATCH] ethernet/atheros/alx: add Killer E2400 device ID

[David Miller]

From: Jason Gerard DeRose 
Date: Tue, 17 Nov 2015 18:21:07 -0700

> From: Ben Pope 
> 
> This patch adds the PCI device ID (0xe0a1) and alx_pci_tbl entry for the
> Killer E2400 Ethernet controller, modeled after the Killer E2200
> controller support (0xe091) already present in the alx driver.
> 
> This patch was originally authored by Ben Pope, but it got held up by
> issues in the commit message, so I'm resubmitting it on his behalf.
> 
> I've extensively used a kernel with this patch on a System76 serw9
> laptop and am quite confident it works well (at least on the hardware I
> have available for testing).
> 
> Note that as a favor to System76, Ubuntu has been carrying this as a
> sauce patch in their 4.2 based Wily kernel, which presumably has given
> it real-world testing on other E2400 equipped hardware (I don't know of
> any Ubuntu kernel bugs filed about it):
> 
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1498633
> 
> Signed-off-by: Jason Gerard DeRose 

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

Re: [PATCH] fm10k: fix memory leak

[David Miller]

From: Stephen Hemminger 
Date: Tue, 17 Nov 2015 14:24:27 -0800

> This was detected by Coverity.
> The function skb_cow_head leaves skb alone on failure, so caller needs
> to free.
> 
> Signed-off-by: Stephen Hemminger 

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

Re: udp: remove duplicate include

[David Miller]

From: Stephen Hemminger 
Date: Tue, 17 Nov 2015 13:46:48 -0800

> Signed-off-by: Stephen Hemminger 

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

Re: [PATCH] net: macb: Add support for sgmii phy interface

[David Miller]

From: Punnaiah Choudary Kalluri 
Date: Wed, 18 Nov 2015 09:03:50 +0530

> This patch adds support for the sgmii phy interface.
> 
> Signed-off-by: Punnaiah Choudary Kalluri 

Applied to net-next, thanks.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH net,stable] net: qmi_wwan: add XS Stick W100-2 from 4G Systems

[Bjørn Mork]

Thomas reports
"
4gsystems sells two total different LTE-surfsticks under the same name.
..
The newer version of XS Stick W100 is from "omega"
..
Under windows the driver switches to the same ID, and uses MI03\6 for
network and MI01\6 for modem.
..
echo "1c9e 9b01" > /sys/bus/usb/drivers/qmi_wwan/new_id
echo "1c9e 9b01" > /sys/bus/usb-serial/drivers/option1/new_id

T:  Bus=01 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#=  4 Spd=480 MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=1c9e ProdID=9b01 Rev=02.32
S:  Manufacturer=USB Modem
S:  Product=USB Modem
S:  SerialNumber=
C:  #Ifs= 5 Cfg#= 1 Atr=80 MxPwr=500mA
I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I:  If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I:  If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
I:  If#= 4 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage

Now all important things are there:

wwp0s29f7u2i3 (net), ttyUSB2 (at), cdc-wdm0 (qmi), ttyUSB1 (at)

There is also ttyUSB0, but it is not usable, at least not for at.

The device works well with qmi and ModemManager-NetworkManager.
"

Reported-by: Thomas Schäfer 
Signed-off-by: Bjørn Mork 
---
 drivers/net/usb/qmi_wwan.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 34799eaace41..9a5be8b85186 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -725,6 +725,7 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x2357, 0x9000, 4)},/* TP-LINK MA260 */
{QMI_FIXED_INTF(0x1bc7, 0x1200, 5)},/* Telit LE920 */
{QMI_FIXED_INTF(0x1bc7, 0x1201, 2)},/* Telit LE920 */
+   {QMI_FIXED_INTF(0x1c9e, 0x9b01, 3)},/* XS Stick W100-2 from 4G 
Systems */
{QMI_FIXED_INTF(0x0b3c, 0xc000, 4)},/* Olivetti Olicard 100 */
{QMI_FIXED_INTF(0x0b3c, 0xc001, 4)},/* Olivetti Olicard 120 */
{QMI_FIXED_INTF(0x0b3c, 0xc002, 4)},/* Olivetti Olicard 140 */
-- 
2.1.4

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

Re: [PATCH] net: dns_resolver: convert time_t to time64_t

[David Miller]

From: Aya Mahfouz 
Date: Wed, 18 Nov 2015 08:36:44 +0200

> Changes the definition of the pointer _expiry from time_t to
> time64_t. This is to handle the Y2038 problem where time_t
> will overflow in the year 2038. The change is safe because
> the kernel subsystems that call dns_query pass NULL.
> 
> Signed-off-by: Arnd Bergmann 
> Signed-off-by: Aya Mahfouz 
> ---
> Changelog:
> v1: The changes were originally made by Arnd Bergmann in
> relation to time_t. I've broken down a patch sent to me
> into two independent patches.

Want me to apply this to 'net'?
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH net] tcp: md5: fix lockdep annotation

[Eric Dumazet]

From: Eric Dumazet 

When a passive TCP is created, we eventually call tcp_md5_do_add()
with sk pointing to the child. It is not owner by the user yet (we
will add this socket into listener accept queue a bit later anyway)

But we do own the spinlock, so amend the lockdep annotation to avoid
following splat :

[ 8451.090932] net/ipv4/tcp_ipv4.c:923 suspicious rcu_dereference_protected() 
usage!
[ 8451.090932]
[ 8451.090932] other info that might help us debug this:
[ 8451.090932]
[ 8451.090934]
[ 8451.090934] rcu_scheduler_active = 1, debug_locks = 1
[ 8451.090936] 3 locks held by socket_sockopt_/214795:
[ 8451.090936]  #0:  (rcu_read_lock){.+.+..}, at: [] 
__netif_receive_skb_core+0x151/0xe90
[ 8451.090947]  #1:  (rcu_read_lock){.+.+..}, at: [] 
ip_local_deliver_finish+0x43/0x2b0
[ 8451.090952]  #2:  (slock-AF_INET){+.-...}, at: [] 
sk_clone_lock+0x1c5/0x500
[ 8451.090958]
[ 8451.090958] stack backtrace:
[ 8451.090960] CPU: 7 PID: 214795 Comm: socket_sockopt_ 

[ 8451.091215] Call Trace:
[ 8451.091216][] dump_stack+0x55/0x76
[ 8451.091229]  [] lockdep_rcu_suspicious+0xeb/0x110
[ 8451.091235]  [] tcp_md5_do_add+0x1bf/0x1e0
[ 8451.091239]  [] tcp_v4_syn_recv_sock+0x1f1/0x4c0
[ 8451.091242]  [] ? tcp_v4_md5_hash_skb+0x167/0x190
[ 8451.091246]  [] tcp_check_req+0x3c8/0x500
[ 8451.091249]  [] ? tcp_v4_inbound_md5_hash+0x11e/0x190
[ 8451.091253]  [] tcp_v4_rcv+0x3c0/0x9f0
[ 8451.091256]  [] ? ip_local_deliver_finish+0x43/0x2b0
[ 8451.091260]  [] ip_local_deliver_finish+0xb6/0x2b0
[ 8451.091263]  [] ? ip_local_deliver_finish+0x43/0x2b0
[ 8451.091267]  [] ip_local_deliver+0x48/0x80
[ 8451.091270]  [] ip_rcv_finish+0x160/0x700
[ 8451.091273]  [] ip_rcv+0x29e/0x3d0
[ 8451.091277]  [] __netif_receive_skb_core+0xb47/0xe90

Fixes: a8afca0329988 ("tcp: md5: protects md5sig_info with RCU")
Signed-off-by: Eric Dumazet 
Reported-by: Willem de Bruijn 
---
 net/ipv4/tcp_ipv4.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index ba09016d1bfd..db003438aaf5 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -921,7 +921,8 @@ int tcp_md5_do_add(struct sock *sk, const union 
tcp_md5_addr *addr,
}
 
md5sig = rcu_dereference_protected(tp->md5sig_info,
-  sock_owned_by_user(sk));
+  sock_owned_by_user(sk) ||
+  lockdep_is_held(>sk_lock.slock));
if (!md5sig) {
md5sig = kmalloc(sizeof(*md5sig), gfp);
if (!md5sig)


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

Re: [PATCH net-next] be2net: remove local variable 'status'

[David Miller]

From: Ivan Vecera 
Date: Wed, 18 Nov 2015 14:06:34 +0100

> The lancer_cmd_get_file_len() uses lancer_cmd_read_object() to get
> the current size of registers for ethtool registers dump. Returned status
> value is stored but not checked. The check itself is not necessary as
> the data_read output variable is initialized to 0 and status variable
> can be removed.
> 
> Signed-off-by: Ivan Vecera 

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

Re: [PATCH] arm64: bpf: fix buffer pointer

[David Miller]

From: Zi Shen Lim 
Date: Wed, 18 Nov 2015 00:56:02 -0800

> During code review, I noticed we were passing a bad buffer pointer
> to bpf_load_pointer helper function called by jitted code.
> 
> Point to the buffer allocated by JIT, so we don't silently corrupt
> other parts of the stack.
> 
> Signed-off-by: Zi Shen Lim 

Can I get some review from other ARM folks before I apply this?

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

Re: Add a SOCK_DESTROY operation to close sockets from userspace

[David Miller]

From: Lorenzo Colitti 
Date: Wed, 18 Nov 2015 19:47:21 +0900

> On Wed, Nov 18, 2015 at 7:19 PM, Hannes Frederic Sowa
>  wrote:
>> I bet there will soon be a timewaitd which handles the not configurable
>> (David has rejected all those patches so far) timeout of TIME_WAIT
>> sockets. And I bet it will be used. :/
> 
> No, SOCK_DESTROY has no effect on TCP_TIME_WAIT sockets or any other
> non-full socket.
> 
> When called on any socket where sk_fullsock(sk) is false, it returns
> EOPNOTSUPP because there is nothing to do. Its purpose is to interrupt
> blocked userspace socket calls, not to release resources.

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

Re: Add a SOCK_DESTROY operation to close sockets from userspace

[Hannes Frederic Sowa]

On Wed, Nov 18, 2015, at 21:35, David Miller wrote:
> From: Lorenzo Colitti 
> Date: Wed, 18 Nov 2015 19:47:21 +0900
> 
> > On Wed, Nov 18, 2015 at 7:19 PM, Hannes Frederic Sowa
> >  wrote:
> >> I bet there will soon be a timewaitd which handles the not configurable
> >> (David has rejected all those patches so far) timeout of TIME_WAIT
> >> sockets. And I bet it will be used. :/
> > 
> > No, SOCK_DESTROY has no effect on TCP_TIME_WAIT sockets or any other
> > non-full socket.
> > 
> > When called on any socket where sk_fullsock(sk) is false, it returns
> > EOPNOTSUPP because there is nothing to do. Its purpose is to interrupt
> > blocked userspace socket calls, not to release resources.
> 
> +1

Basically my concern is the same one I tried to express in the other
patch about Florian's patch "[PATCH -next] net: tcp: move to timewait
when receiving data post active-close": we could give the socket back
way too early so the quadruple can be reused. If timestamps are not in
use or we are dealing with NAT were we have dozens of synchronized
clocks behind the masquerading device, we could end up in accepting
delayed data. Especially this scenario can come up when the address is
actually not released but someone uses this feature on a server.

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

Re: [PATCH] fm10k: fix memory leak

[Jeff Kirsher]

On Wed, 2015-11-18 at 15:06 -0500, David Miller wrote:
> From: Stephen Hemminger 
> Date: Tue, 17 Nov 2015 14:24:27 -0800
> 
> > This was detected by Coverity.
> > The function skb_cow_head leaves skb alone on failure, so caller
> > needs
> > to free.
> > 
> > Signed-off-by: Stephen Hemminger 
> 
> Applied.

Thanks, got slammed with emails and this got overlooked.

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

lockdep problem? netlink_dump & rtnl_lock

[Arkadiusz Miskiewicz]

Hi.

I'm running 4.3.0 kernel (+ few backported mm patches). Machine is doing many 
rsnapshots
in parallel (so heavily loaded).

I'm seeing this from time to time (below). What would be the reason for so long 
hangs?

[ 2278.385668] INFO: task snmpd:1775 blocked for more than 120 seconds.
[ 2278.392089]   Not tainted 4.3.0-0.1 #1
[ 2278.396226] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[ 2278.404111] snmpd   D 88081fc158c0 0  1775  1 0x
[ 2278.411229]  8807e6a8bcf8 0082 81c13500 
8807ebb88d80
[ 2278.418753]  8807e6a8c000 8807ebb88d80 81cc7c84 

[ 2278.426286]  81cc7c88 8807e6a8bd10 8161c203 
81cc7c80
[ 2278.433854] Call Trace:
[ 2278.436341]  [] schedule+0x33/0x80
[ 2278.441349]  [] schedule_preempt_disabled+0xe/0x10
[ 2278.447733]  [] __mutex_lock_slowpath+0xb3/0x120
[ 2278.453956]  [] mutex_lock+0x1f/0x30
[ 2278.459133]  [] rtnl_lock+0x15/0x20
[ 2278.464212]  [] devinet_ioctl+0xd2/0x6e0
[ 2278.469757]  [] ? mntput+0x24/0x40
[ 2278.474769]  [] ? __fput+0x142/0x200
[ 2278.479955]  [] inet_ioctl+0x50/0x70
[ 2278.485122]  [] sock_do_ioctl+0x25/0x50
[ 2278.490578]  [] sock_ioctl+0x1d2/0x290
[ 2278.495920]  [] do_vfs_ioctl+0x295/0x470
[ 2278.501444]  [] ? sock_alloc_file+0xa6/0x130
[ 2278.507338]  [] ? task_work_add+0x44/0x60
[ 2278.512942]  [] ? fput+0x47/0x90
[ 2278.517771]  [] SyS_ioctl+0x79/0x90
[ 2278.522845]  [] entry_SYSCALL_64_fastpath+0x16/0x75
[ 2278.529341] INFO: task sudo:4534 blocked for more than 120 seconds.
[ 2278.535635]   Not tainted 4.3.0-0.1 #1
[ 2278.539759] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[ 2278.547680] sudoD  0  4534  1 0x0004
[ 2278.554825]  880080677bb8 0086 8807f3874380 
8807f3eb8000
[ 2278.562389]  880080678000 8807f3eb8000 81cc7c84 

[ 2278.569914]  81cc7c88 880080677bd0 8161c203 
81cc7c80
[ 2278.577436] Call Trace:
[ 2278.579911]  [] schedule+0x33/0x80
[ 2278.584918]  [] schedule_preempt_disabled+0xe/0x10
[ 2278.591329]  [] __mutex_lock_slowpath+0xb3/0x120
[ 2278.597571]  [] mutex_lock+0x1f/0x30
[ 2278.602743]  [] __netlink_dump_start+0x5e/0x190
[ 2278.608890]  [] ? rtnl_fill_ifinfo+0x13f0/0x13f0
[ 2278.615105]  [] rtnetlink_rcv_msg+0x1bc/0x230
[ 2278.621054]  [] ? rtnl_fill_ifinfo+0x13f0/0x13f0
[ 2278.627262]  [] ? rtnetlink_rcv+0x30/0x30
[ 2278.632861]  [] netlink_rcv_skb+0xa4/0xc0
[ 2278.638463]  [] rtnetlink_rcv+0x28/0x30
[ 2278.643908]  [] netlink_unicast+0x127/0x1a0
[ 2278.649692]  [] netlink_sendmsg+0x4f4/0x5f0
[ 2278.655480]  [] sock_sendmsg+0x38/0x50
[ 2278.660830]  [] SyS_sendto+0x101/0x150
[ 2278.666189]  [] ? sock_alloc_file+0xa6/0x130
[ 2278.672064]  [] ? fd_install+0x25/0x30
[ 2278.677407]  [] ? SyS_socket+0x9f/0xf0
[ 2278.682749]  [] entry_SYSCALL_64_fastpath+0x16/0x75








 [ 7433.492510] INFO: task bird:1503 blocked for more than 120 seconds.
[ 7433.498819]   Not tainted 4.3.0-0.1 #1
[ 7433.502954] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[ 7433.510840] birdD 88081fd158c0 0  1503  1 0x
[ 7433.517966]  8807eb923bb8 0086 8807fb711b00 
8807f38a4380
[ 7433.525493]  8807eb924000 8807f38a4380 81cc7c84 

[ 7433.533017]  81cc7c88 8807eb923bd0 8161c203 
81cc7c80
[ 7433.540561] Call Trace:
[ 7433.543050]  [] schedule+0x33/0x80
[ 7433.548041]  [] schedule_preempt_disabled+0xe/0x10
[ 7433.554415]  [] __mutex_lock_slowpath+0xb3/0x120
[ 7433.560624]  [] mutex_lock+0x1f/0x30
[ 7433.565810]  [] netlink_dump+0x21/0x2c0
[ 7433.571236]  [] netlink_recvmsg+0x249/0x3d0
[ 7433.577005]  [] sock_recvmsg+0x3b/0x50
[ 7433.582347]  [] ___sys_recvmsg+0xdb/0x1f0
[ 7433.587952]  [] ? __switch_to+0x25c/0x4a0
[ 7433.593579]  [] ? update_curr+0xb7/0x130
[ 7433.599115]  [] ? __enqueue_entity+0x6c/0x70
[ 7433.604970]  [] ? set_next_entity+0x71/0x840
[ 7433.610832]  [] ? __switch_to+0x25c/0x4a0
[ 7433.616431]  [] __sys_recvmsg+0x51/0x90
[ 7433.621873]  [] SyS_recvmsg+0x12/0x20
[ 7433.627125]  [] entry_SYSCALL_64_fastpath+0x16/0x75
[ 7433.633642] INFO: task kworker/3:4:12895 blocked for more than 120 seconds.
[ 7433.640651]   Not tainted 4.3.0-0.1 #1
[ 7433.644797] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[ 7433.652682] kworker/3:4 D  0 12895  2 0x
[ 7433.659794] Workqueue: ipv6_addrconf addrconf_verify_work
[ 7433.665240]  8803b0073d58 0046 880781adb600 
880736aa3600
[ 7433.672763]  8803b0074000 880736aa3600 81cc7c84 

[ 7433.680287]  81cc7c88 8803b0073d70 8161c203 
81cc7c80
[ 7433.687811] Call Trace:
[ 7433.690288]  [] schedule+0x33/0x80
[ 7433.695297]  [] 

Re: Add a SOCK_DESTROY operation to close sockets from userspace

[Hannes Frederic Sowa]

Hello,

On Wed, Nov 18, 2015, at 02:43, Lorenzo Colitti wrote:
> This patch series adds the ability for a privileged process to
> destroy sockets belonging to other userspace processes via the
> sock_diag interface, and implements that for TCP sockets.
> 
> This functionality is needed on laptops and mobile hosts to
> ensure that network switches / disconnects do not result in
> applications being blocked for long periods of time (minutes) in
> read or connect calls on TCP sockets that will never succeed
> because the IP address they are bound to is gone. Closing the
> sockets in the protocol layer causes these calls to fail fast and
> allows applications to reconnect on another network.

I regularly do this with gdb, connecting to the process, looking up the
filedescriptors in /proc/pid/fd and closing the socket. Actually it will
also be removed from the poll tables and thus unlocks the system. I
think a user space approach would be preferred to do so, or some out of
band signalling (which we actually already have in terms of netlink
monitor).

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

[PATCH 2/3] net/ceph: do not define list_entry_next

[Sergey Senozhatsky]

Cosmetic.

Do not define list_entry_next() and use list_next_entry()
from list.h.

Signed-off-by: Sergey Senozhatsky 
---
 net/ceph/messenger.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/net/ceph/messenger.c b/net/ceph/messenger.c
index 9981039..77ccca9 100644
--- a/net/ceph/messenger.c
+++ b/net/ceph/messenger.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #ifdef CONFIG_BLOCK
 #include 
 #endif /* CONFIG_BLOCK */
@@ -23,9 +24,6 @@
 #include 
 #include 
 
-#define list_entry_next(pos, member)   \
-   list_entry(pos->member.next, typeof(*pos), member)
-
 /*
  * Ceph uses the messenger to exchange ceph_msg messages with other
  * hosts in the system.  The messenger provides ordered and reliable
@@ -1042,7 +1040,7 @@ static bool ceph_msg_data_pagelist_advance(struct 
ceph_msg_data_cursor *cursor,
/* Move on to the next page */
 
BUG_ON(list_is_last(>page->lru, >head));
-   cursor->page = list_entry_next(cursor->page, lru);
+   cursor->page = list_next_entry(cursor->page, lru);
cursor->last_piece = cursor->resid <= PAGE_SIZE;
 
return true;
@@ -1166,7 +1164,7 @@ static bool ceph_msg_data_advance(struct 
ceph_msg_data_cursor *cursor,
if (!cursor->resid && cursor->total_resid) {
WARN_ON(!cursor->last_piece);
BUG_ON(list_is_last(>data->links, cursor->data_head));
-   cursor->data = list_entry_next(cursor->data, links);
+   cursor->data = list_next_entry(cursor->data, links);
__ceph_msg_data_cursor_init(cursor);
new_piece = true;
}
-- 
2.6.2.280.g74301d6

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

Re: Add a SOCK_DESTROY operation to close sockets from userspace

[Lorenzo Colitti]

On Wed, Nov 18, 2015 at 7:19 PM, Hannes Frederic Sowa
 wrote:
> I bet there will soon be a timewaitd which handles the not configurable
> (David has rejected all those patches so far) timeout of TIME_WAIT
> sockets. And I bet it will be used. :/

No, SOCK_DESTROY has no effect on TCP_TIME_WAIT sockets or any other
non-full socket.

When called on any socket where sk_fullsock(sk) is false, it returns
EOPNOTSUPP because there is nothing to do. Its purpose is to interrupt
blocked userspace socket calls, not to release resources.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[iproute PATCH 1/2] bridge.8: document fdb replace command

[Phil Sutter]

Despite commit 45a82e5 ("iproute vxlan add support for fdb replace
command"), the 'fdb replace' command was not mentioned in bridge.8.

Signed-off-by: Phil Sutter 
---
 man/man8/bridge.8 | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/man/man8/bridge.8 b/man/man8/bridge.8
index 222a438..3c5bc47 100644
--- a/man/man8/bridge.8
+++ b/man/man8/bridge.8
@@ -50,7 +50,7 @@ bridge \- show / manipulate bridge addresses and devices
 .IR DEV " ]"
 
 .ti -8
-.BR "bridge fdb" " { " add " | " append " | " del " } "
+.BR "bridge fdb" " { " add " | " append " | " del " | " replace " } "
 .I LLADDR
 .B  dev
 .IR DEV " { "
@@ -407,6 +407,13 @@ This command removes an existing fdb entry.
 The arguments are the same as with
 .BR "bridge fdb add" ,
 
+.SS bridge fdb replace - replace a forwarding database entry
+If no matching entry is found, a new one will be created instead.
+
+.PP
+The arguments are the same as with
+.BR "bridge fdb add" ,
+
 .SS bridge fdb show - list forwarding entries.
 
 This command displays the current forwarding table.
-- 
2.5.0

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

RE: next build: 235 warnings 3 failures (next/next-20151117)

[David Laight]

From: Will Deacon
> Sent: 18 November 2015 10:14
> On Tue, Nov 17, 2015 at 08:17:17PM +0100, Arnd Bergmann wrote:
> > On Tuesday 17 November 2015 17:12:37 Will Deacon wrote:
> > > On Tue, Nov 17, 2015 at 06:03:40PM +0100, Arnd Bergmann wrote:
> > > > On Tuesday 17 November 2015 16:44:53 Will Deacon wrote:
> > > > > > 8<
> > > > > > Subject: ARM64: make smp_load_acquire() work with const arguments
> > > > > >
> > > > > > smp_load_acquire() uses typeof() to declare a local variable for 
> > > > > > temporarily
> > > > > > storing the output of the memory access. This fails when the 
> > > > > > argument is
> > > > > > constant, because the assembler complains about using a constant 
> > > > > > register
> > > > > > as output:
> > > > > >
> > > > > >  arch/arm64/include/asm/barrier.h:71:3: error: read-only variable 
> > > > > > '___p1'
> > > > > >  used as 'asm' output
> > > > >
> > > > > Do you know the usage in the kernel causing this warning?
> > > >
> > > > A newly introduced function in include/net/sock.h:
> > > >
> > > > static inline int sk_state_load(const struct sock *sk)
> > > > {
> > > > return smp_load_acquire(>sk_state);
> > > > }
> > >
> > > Hmm, maybe we could play a similar trick to READ_ONCE by declaring an
> > > anonymous union and writing through the non-const member?
> >
> > Yes, I think that would work, if you think we need to care about the
> > case where we read into a structure.
> >
> > Can you come up with a patch for that?
> 
> Done:
> 
>   
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-November/386094.html

That patch forces a memory write-read and returns uninitialised stack
for short reads.
Who knows what happens on big-endian systems.

You need a static inline function with separate temporaries in each branch.

David

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

Re: net-scm: Macro for special pattern?

[Eric Dumazet]

On Wed, 2015-11-18 at 08:45 +0100, SF Markus Elfring wrote:
> > You mean this likely() annotation of yours?
> 
> How do you think about to express the software design pattern
> which is applied at the mentioned source code place by a dedicated
> preprocessor macro?

likely()/unlikely() are not always applicable.

In the Ipv6 case I mentioned to you, it all depends if an application
for some reason absolutely wants the sockets to store the extra skb

There are seldom used socket options. _if_/_when_ they are used, a
likely()/unlikely() would give the wrong signal.

likely() should only be used in contexts we know better than branch
predictor/compiler.



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

[PATCH net-next] be2net: remove local variable 'status'

[Ivan Vecera]

The lancer_cmd_get_file_len() uses lancer_cmd_read_object() to get
the current size of registers for ethtool registers dump. Returned status
value is stored but not checked. The check itself is not necessary as
the data_read output variable is initialized to 0 and status variable
can be removed.

Signed-off-by: Ivan Vecera 
---
 drivers/net/ethernet/emulex/benet/be_ethtool.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/emulex/benet/be_ethtool.c 
b/drivers/net/ethernet/emulex/benet/be_ethtool.c
index 734f655..d2a5baf 100644
--- a/drivers/net/ethernet/emulex/benet/be_ethtool.c
+++ b/drivers/net/ethernet/emulex/benet/be_ethtool.c
@@ -241,13 +241,11 @@ static u32 lancer_cmd_get_file_len(struct be_adapter 
*adapter, u8 *file_name)
u32 data_read = 0, eof;
u8 addn_status;
struct be_dma_mem data_len_cmd;
-   int status;
 
memset(_len_cmd, 0, sizeof(data_len_cmd));
/* data_offset and data_size should be 0 to get reg len */
-   status = lancer_cmd_read_object(adapter, _len_cmd, 0, 0,
-   file_name, _read, ,
-   _status);
+   lancer_cmd_read_object(adapter, _len_cmd, 0, 0, file_name,
+  _read, , _status);
 
return data_read;
 }
-- 
2.4.10

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

RE: Add a SOCK_DESTROY operation to close sockets from userspace

[David Laight]

From: Maciej Zenczykowski
> Sent: 18 November 2015 03:57
> I don't know what the right fix is...
> 
> However, speaking as an end user with laptops on wifi and/or home
> gateways on dialup connections where the IP address occasionally (or
> constantly) changes, I find it very frustrating that by default as IP
> addresses get removed from interfaces all the related state (whether
> conntrack or open connections) doesn't get cleaned up.

Right, but I don't want it happening when an interface temporarily
goes down for some reason.
Trip over the cable to a USB network interface and you want the connections
to still be alive when you plug it back in.
We've had to put USB interfaces into a 'bond' to get a stable address.

Now, if you have a DHCP assigned address you may want to force a
lease renewal after a network 'glitch'. If you get back a different
address then it might be reasonable for the stack to error any
connections using the old address - after all another system
could be using the old IP address.

I suspect that the only way to avoid horrid timing windows is
to simulate the receipt of RST packets.

David

Re: [PATCH net] net: fix feature changes on devices without ndo_set_features

[Sergei Shtylyov]

Hello.

On 11/18/2015 2:10 AM, Nikolay Aleksandrov wrote:


From: Nikolay Aleksandrov 

When __netdev_update_features() was updated to ensure some features are
disabled on new lower devices, an error was introduced for devices which
don't have the ndo_set_features() method set. Before we'll just set the
new features, but now we return an error and don't set them. Fix this by
returning the old behaviour and setting err to 0 when ndo_set_features
is not present.

Fixes: e7868a85e1b2 ("net/core: ensure features get disabled on new lower devs")
CC: Jarod Wilson 
CC: Jiri Pirko 
CC: Ido Schimmel 
CC: Sander Eikelenboom 
CC: Andy Gospodarek 
CC: Florian Fainelli 
Signed-off-by: Nikolay Aleksandrov 
---
Sander please feel free to give your Tested-by.

   net/core/dev.c | 2 ++
   1 file changed, 2 insertions(+)

diff --git a/net/core/dev.c b/net/core/dev.c
index ab9b8d0d115e..4a1d198dbbff 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -6426,6 +6426,8 @@ int __netdev_update_features(struct net_device *dev)

   if (dev->netdev_ops->ndo_set_features)
   err = dev->netdev_ops->ndo_set_features(dev, features);
+else
+err = 0;


This makes the 'err' initializer pointless.


It doesn't, there's a previous goto statement that might get hit and we
need it to be -1 so we don't signal a feature change.


   Ah, sorry, it was late and I was being stupid. :-<

MBR, Sergei

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

Re: Add a SOCK_DESTROY operation to close sockets from userspace

[Hannes Frederic Sowa]

On Wed, Nov 18, 2015, at 11:47, Lorenzo Colitti wrote:
> On Wed, Nov 18, 2015 at 7:19 PM, Hannes Frederic Sowa
>  wrote:
> > I bet there will soon be a timewaitd which handles the not configurable
> > (David has rejected all those patches so far) timeout of TIME_WAIT
> > sockets. And I bet it will be used. :/
> 
> No, SOCK_DESTROY has no effect on TCP_TIME_WAIT sockets or any other
> non-full socket.
> 
> When called on any socket where sk_fullsock(sk) is false, it returns
> EOPNOTSUPP because there is nothing to do. Its purpose is to interrupt
> blocked userspace socket calls, not to release resources.

Okay, thanks for clarification! Still I don't see how you enter
TIME_WAIT in case you kill an active socket. At least my start-up idea
timewaitd seems to be not implementable. ;)

I was wondering why you didn't use tcp_close function, because still we
could have the address and we would like to do a proper shutdown of the
connection. While this patchset wants to tear down sockets for addresses
no longer alive, it still can be used with full sockets.

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

[iproute PATCH 2/2] bridge.8: minor formatting cleanup

[Phil Sutter]

- Replace commas at end of subsection with dots.
- Remove whitespace at EOL.
- Replace double whitespace by single one.

Signed-off-by: Phil Sutter 
---
 man/man8/bridge.8 | 50 +-
 1 file changed, 25 insertions(+), 25 deletions(-)

diff --git a/man/man8/bridge.8 b/man/man8/bridge.8
index 3c5bc47..1ae1e77 100644
--- a/man/man8/bridge.8
+++ b/man/man8/bridge.8
@@ -25,14 +25,14 @@ bridge \- show / manipulate bridge addresses and devices
 
 .ti -8
 .BR "bridge link set"
-.B  dev
+.B dev
 .IR DEV
 .IR " [ "
-.B  cost
+.B cost
 .IR COST " ] [ "
-.B  priority
-.IR PRIO " ]  [ "
-.B  state
+.B priority
+.IR PRIO " ] [ "
+.B state
 .IR STATE "] ["
 .BR guard " { " on " | " off " } ] [ "
 .BR hairpin " { " on " | " off " } ] [ "
@@ -42,21 +42,21 @@ bridge \- show / manipulate bridge addresses and devices
 .BR learning_sync " { " on " | " off " } ] [ "
 .BR flood " { " on " | " off " } ] [ "
 .BR hwmode " { " vepa " | " veb " } ] [ "
-.BR self " ]  [ " master " ] "
+.BR self " ] [ " master " ] "
 
 .ti -8
 .BR "bridge link" " [ " show " ] [ "
-.B  dev
+.B dev
 .IR DEV " ]"
 
 .ti -8
 .BR "bridge fdb" " { " add " | " append " | " del " | " replace " } "
 .I LLADDR
-.B  dev
+.B dev
 .IR DEV " { "
 .BR local " | " temp " } [ "
 .BR self " ] [ " master " ] [ " router " ] [ " use " ] [ "
-.B  dst
+.B dst
 .IR IPADDR " ] [ "
 .B vni
 .IR VNI " ] ["
@@ -67,12 +67,12 @@ bridge \- show / manipulate bridge addresses and devices
 
 .ti -8
 .BR "bridge fdb" " [ " show " ] [ "
-.B  dev
+.B dev
 .IR DEV " ]"
 
 .ti -8
 .BR "bridge mdb" " { " add " | " del " } "
-.B  dev
+.B dev
 .IR DEV
 .B port
 .IR PORT
@@ -84,21 +84,21 @@ bridge \- show / manipulate bridge addresses and devices
 
 .ti -8
 .BR "bridge mdb show " [ "
-.B  dev
+.B dev
 .IR DEV " ]"
 
 .ti -8
 .BR "bridge vlan" " { " add " | " del " } "
-.B  dev
+.B dev
 .IR DEV
-.B  vid 
+.B vid
 .IR VID " [ "
-.BR  pvid " ] [ " untagged " ]  [ "
-.BR  self " ]  [ " master " ] "
+.BR pvid " ] [ " untagged " ] [ "
+.BR self " ] [ " master " ] "
 
 .ti -8
 .BR "bridge vlan" " [ " show " ] [ "
-.B  dev
+.B dev
 .IR DEV " ]"
 
 .ti -8
@@ -159,7 +159,7 @@ return code will be non zero.
 - Bridge port.
 
 .TP
-.B fdb 
+.B fdb
 - Forwarding Database entry.
 
 .TP
@@ -319,7 +319,7 @@ This command displays the current bridge port configuration 
and flags.
 .SH bridge fdb - forwarding database management
 
 .B fdb
-objects contain known Ethernet addresses on a  link.
+objects contain known Ethernet addresses on a link.
 
 .P
 The corresponding commands display fdb entries, add new entries,
@@ -384,7 +384,7 @@ If omitted the default value is used.
 .BI via " DEVICE"
 device name of the outgoing interface for the
 VXLAN device driver to reach the
-remote VXLAN tunnel endpoint. 
+remote VXLAN tunnel endpoint.
 
 .SS bridge fdb append - append a forwarding database entry
 This command adds a new fdb entry with an already known
@@ -398,21 +398,21 @@ sends a copy of the data packet to each entry found.
 
 .PP
 The arguments are the same as with
-.BR "bridge fdb add" ,
+.BR "bridge fdb add" .
 
 .SS bridge fdb delete - delete a forwarding database entry
 This command removes an existing fdb entry.
 
 .PP
 The arguments are the same as with
-.BR "bridge fdb add" ,
+.BR "bridge fdb add" .
 
 .SS bridge fdb replace - replace a forwarding database entry
 If no matching entry is found, a new one will be created instead.
 
 .PP
 The arguments are the same as with
-.BR "bridge fdb add" ,
+.BR "bridge fdb add" .
 
 .SS bridge fdb show - list forwarding entries.
 
@@ -548,7 +548,7 @@ This command displays the current VLAN filter table.
 
 The
 .B bridge
-utility can monitor the state of devices and  addresses
+utility can monitor the state of devices and addresses
 continuously. This option has a slightly different format.
 Namely, the
 .B monitor
@@ -560,7 +560,7 @@ command is the first in the command line and then the 
object list follows:
 .I OBJECT-LIST
 is the list of object types that we want to monitor.
 It may contain
-.BR link ",  " fdb ", and " mdb "."
+.BR link ", " fdb ", and " mdb "."
 If no
 .B file
 argument is given,
-- 
2.5.0

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

[iproute PATCH 0/2] minor update to bridge.8

[Phil Sutter]

This was originally some leftover in RHEL patches, as well. Though the
question whether 'fdb replace' should be documented or not was not
exactly trivial:

- In August 2012, 'fdb change' and 'fdb replace' commands were removed
  (commit 57b9785).
- In September 2012, bridge.8 was adjusted accordingly (commit d611682).
- In July 2013 though, 'fdb replace' was added again (commit 45a82e5).

The latter maybe should have been a revert, as it misses to add 'fdb
change' as well. Anyway, this series fixes bridge.8 again and
additionally reviews formatting.


Phil Sutter (2):
  bridge.8: document fdb replace command
  bridge.8: minor formatting cleanup

 man/man8/bridge.8 | 57 +++
 1 file changed, 32 insertions(+), 25 deletions(-)

-- 
2.5.0

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

Re: Add a SOCK_DESTROY operation to close sockets from userspace

[Eric Dumazet]

On Wed, 2015-11-18 at 12:19 +0100, Hannes Frederic Sowa wrote:
> On Wed, Nov 18, 2015, at 11:47, Lorenzo Colitti wrote:
> > On Wed, Nov 18, 2015 at 7:19 PM, Hannes Frederic Sowa
> >  wrote:
> > > I bet there will soon be a timewaitd which handles the not configurable
> > > (David has rejected all those patches so far) timeout of TIME_WAIT
> > > sockets. And I bet it will be used. :/
> > 
> > No, SOCK_DESTROY has no effect on TCP_TIME_WAIT sockets or any other
> > non-full socket.
> > 
> > When called on any socket where sk_fullsock(sk) is false, it returns
> > EOPNOTSUPP because there is nothing to do. Its purpose is to interrupt
> > blocked userspace socket calls, not to release resources.
> 
> Okay, thanks for clarification! Still I don't see how you enter
> TIME_WAIT in case you kill an active socket. At least my start-up idea
> timewaitd seems to be not implementable. ;)
> 
> I was wondering why you didn't use tcp_close function, because still we
> could have the address and we would like to do a proper shutdown of the
> connection. While this patchset wants to tear down sockets for addresses
> no longer alive, it still can be used with full sockets.

I guess this could work, but we would have to also propose a mechanism
where no FIN/RST message is sent.

This might be the time for upstreaming our TCP_SILENT_CLOSE
implementation.

/* on close(): free sock, no FIN/RST */

It seems there is a lot of confusion on this thread about these patches.

Proposal is _not_ changing TCP stack behavior, as David Laight seems to
fear.



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

Re: next build: 235 warnings 3 failures (next/next-20151117)

[Will Deacon]

On Wed, Nov 18, 2015 at 12:11:25PM +, David Laight wrote:
> From: Will Deacon
> > Sent: 18 November 2015 10:14
> > On Tue, Nov 17, 2015 at 08:17:17PM +0100, Arnd Bergmann wrote:
> > > On Tuesday 17 November 2015 17:12:37 Will Deacon wrote:
> > > > On Tue, Nov 17, 2015 at 06:03:40PM +0100, Arnd Bergmann wrote:
> > > > > On Tuesday 17 November 2015 16:44:53 Will Deacon wrote:
> > > > > > > 8<
> > > > > > > Subject: ARM64: make smp_load_acquire() work with const arguments
> > > > > > >
> > > > > > > smp_load_acquire() uses typeof() to declare a local variable for 
> > > > > > > temporarily
> > > > > > > storing the output of the memory access. This fails when the 
> > > > > > > argument is
> > > > > > > constant, because the assembler complains about using a constant 
> > > > > > > register
> > > > > > > as output:
> > > > > > >
> > > > > > >  arch/arm64/include/asm/barrier.h:71:3: error: read-only variable 
> > > > > > > '___p1'
> > > > > > >  used as 'asm' output
> > > > > >
> > > > > > Do you know the usage in the kernel causing this warning?
> > > > >
> > > > > A newly introduced function in include/net/sock.h:
> > > > >
> > > > > static inline int sk_state_load(const struct sock *sk)
> > > > > {
> > > > > return smp_load_acquire(>sk_state);
> > > > > }
> > > >
> > > > Hmm, maybe we could play a similar trick to READ_ONCE by declaring an
> > > > anonymous union and writing through the non-const member?
> > >
> > > Yes, I think that would work, if you think we need to care about the
> > > case where we read into a structure.
> > >
> > > Can you come up with a patch for that?
> > 
> > Done:
> > 
> >   
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-November/386094.html
> 
> That patch forces a memory write-read and returns uninitialised stack
> for short reads.

Really? The disassembly looks fine to me. Do you have a concrete example
of where you think it goes wrong, please?

> Who knows what happens on big-endian systems.

The same thing as READ_ONCE? I'll test it there to make sure, but I
don't see a problem.

> You need a static inline function with separate temporaries in each
> branch.

I'm just following the precedent set out by READ_ONCE, since that's
tackling exactly the same problem and appears to be working for people.

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

Re: Add a SOCK_DESTROY operation to close sockets from userspace

[Lorenzo Colitti]

On Wed, Nov 18, 2015 at 8:19 PM, Hannes Frederic Sowa
 wrote:
> I was wondering why you didn't use tcp_close function, because still we
> could have the address and we would like to do a proper shutdown of the
> connection. While this patchset wants to tear down sockets for addresses
> no longer alive, it still can be used with full sockets.

>From the perspective of the TCP state machine, there's not much
difference. In most TCP states, tcp_close takes the socket straight to
TCP_CLOSE (not into TCP_TIME_WAIT).

There is a difference in that tcp_close() sends a RST by calling
tcp_send_active_reset. We could make tcp_diag_destroy do that too. Not
sure it's worth it because in most of the the cases where you'd want
to use SOCK_DESTROY (e.g., you've lost a network connection, a VPN
connected, etc.), tcp_send_active_reset is either not going to send a
RST at all or it's going send on the wrong network. Even if we're
still connected to the same network (e.g., in the case where you're
running "ss --kill" to close a socket instead of the bad old days
where you had to load your process in gdb and call close() from there
:-)), not sending a RST is not the end of the world, because as soon
as the peer sends us a packet we'll send a RST anyway.

In any case calling tcp_close itself won't work - that's intended for
userspace closes. It calls sock_orphan, which nulls out the
backpointer to the userspace socket structure, and assumes that there
are no userspace references to the protocol socket. If we make
SOCK_DESTROY call tcp_close without releasing the userspace
components, things blow up as soon as the app calls close().
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] net/ceph: do not define list_entry_next

[Ilya Dryomov]

On Wed, Nov 18, 2015 at 1:13 PM, Sergey Senozhatsky
 wrote:
> Cosmetic.
>
> Do not define list_entry_next() and use list_next_entry()
> from list.h.
>
> Signed-off-by: Sergey Senozhatsky 
> ---
>  net/ceph/messenger.c | 8 +++-
>  1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/net/ceph/messenger.c b/net/ceph/messenger.c
> index 9981039..77ccca9 100644
> --- a/net/ceph/messenger.c
> +++ b/net/ceph/messenger.c
> @@ -10,6 +10,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #ifdef CONFIG_BLOCK
>  #include 
>  #endif /* CONFIG_BLOCK */
> @@ -23,9 +24,6 @@
>  #include 
>  #include 
>
> -#define list_entry_next(pos, member)   \
> -   list_entry(pos->member.next, typeof(*pos), member)
> -
>  /*
>   * Ceph uses the messenger to exchange ceph_msg messages with other
>   * hosts in the system.  The messenger provides ordered and reliable
> @@ -1042,7 +1040,7 @@ static bool ceph_msg_data_pagelist_advance(struct 
> ceph_msg_data_cursor *cursor,
> /* Move on to the next page */
>
> BUG_ON(list_is_last(>page->lru, >head));
> -   cursor->page = list_entry_next(cursor->page, lru);
> +   cursor->page = list_next_entry(cursor->page, lru);
> cursor->last_piece = cursor->resid <= PAGE_SIZE;
>
> return true;
> @@ -1166,7 +1164,7 @@ static bool ceph_msg_data_advance(struct 
> ceph_msg_data_cursor *cursor,
> if (!cursor->resid && cursor->total_resid) {
> WARN_ON(!cursor->last_piece);
> BUG_ON(list_is_last(>data->links, cursor->data_head));
> -   cursor->data = list_entry_next(cursor->data, links);
> +   cursor->data = list_next_entry(cursor->data, links);
> __ceph_msg_data_cursor_init(cursor);
> new_piece = true;
> }

Someone beat you to it ;)

https://github.com/ceph/ceph-client/commit/76b4a27faebb369c1c50df01ef08b614a2854fc5

Thanks,

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

Re: [PATCH 3/3] dl2k: Implement suspend

[Ondrej Zary]

On Tuesday 17 November 2015, Francois Romieu wrote:
> Ondrej Zary  :
> [...]
>
> > diff --git a/drivers/net/ethernet/dlink/dl2k.c
> > b/drivers/net/ethernet/dlink/dl2k.c index 9e9baa0..b53dfa7 100644
> > --- a/drivers/net/ethernet/dlink/dl2k.c
> > +++ b/drivers/net/ethernet/dlink/dl2k.c
> > @@ -1824,11 +1824,57 @@ rio_remove1 (struct pci_dev *pdev)
> > }
> >  }
> >
> > +#ifdef CONFIG_PM
> > +static int rio_suspend(struct pci_dev *pdev, pm_message_t state)
> > +{
> > +   struct net_device *dev = pci_get_drvdata(pdev);
> > +   struct netdev_private *np = netdev_priv(dev);
> > +
> > +   pci_save_state(pdev);
>
> Cargo-cultism ?
>
> > +
> > +   if (netif_running(dev)) {
> > +   netif_device_detach(dev);
> > +   del_timer_sync(>timer);
> > +   rio_hw_stop(dev);
> > +   free_list(dev);
>
> If free_list is used here, so must alloc_list be in resume, whence
> an extra failure opportunity.
>
> You may not need to free both Tx and Rx here.

I'll better drop the free_list/alloc_list from suspend/resume (as you 
suggested before).

> [...]
>
> >  static struct pci_driver rio_driver = {
> > .name   = "dl2k",
> > .id_table   = rio_pci_tbl,
> > .probe  = rio_probe1,
> > .remove = rio_remove1,
> > +#ifdef CONFIG_PM
> > +   .suspend= rio_suspend,
> > +   .resume = rio_resume,
> > +#endif /* CONFIG_PM */
>
> It looks a bit old school.
>
> See Documentation/power/pci.txt and drivers/net/ethernet/via/via-rhine.c
> for an instance of SIMPLE_DEV_PM_OPS.
>
> At some point you'll probably support runtime power management though.

Thanks for suggestion, I've been looking at the wrong drivers as none of them 
used dev_pm_ops.

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

Re: [PATCH 1/2] can: m_can: Increase delay to ensure written INIT accepted

[Marc Kleine-Budde]

On 11/18/2015 11:04 AM, Wenyou Yang wrote:
> Increase the delay time until the value written to INIT can be
> read back to ensure that the previous value written to INIT has
> been accepted.
> 
> Signed-off-by: Wenyou Yang 

The patch looks ok, can you please add to your commit message which SoCs
are affected by this problem.

> ---
> 
>  drivers/net/can/m_can/m_can.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
> index ef65517..fd1caa0 100644
> --- a/drivers/net/can/m_can/m_can.c
> +++ b/drivers/net/can/m_can/m_can.c
> @@ -320,7 +320,7 @@ static inline void m_can_config_endisable(const struct 
> m_can_priv *priv,
> bool enable)
>  {
>   u32 cccr = m_can_read(priv, M_CAN_CCCR);
> - u32 timeout = 10;
> + u32 timeout = 1000;
>   u32 val = 0;
>  
>   if (enable) {
> 

Marc

-- 
Pengutronix e.K.  | Marc Kleine-Budde   |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund  | Fax:   +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |



signature.asc
Description: OpenPGP digital signature

RE: next build: 235 warnings 3 failures (next/next-20151117)

[David Laight]

From: Arnd Bergmann
> Sent: 17 November 2015 19:17
> On Tuesday 17 November 2015 17:12:37 Will Deacon wrote:
> > On Tue, Nov 17, 2015 at 06:03:40PM +0100, Arnd Bergmann wrote:
> > > On Tuesday 17 November 2015 16:44:53 Will Deacon wrote:
> > > > > 8<
> > > > > Subject: ARM64: make smp_load_acquire() work with const arguments
> > > > >
> > > > > smp_load_acquire() uses typeof() to declare a local variable for 
> > > > > temporarily
> > > > > storing the output of the memory access. This fails when the argument 
> > > > > is
> > > > > constant, because the assembler complains about using a constant 
> > > > > register
> > > > > as output:
> > > > >
> > > > >  arch/arm64/include/asm/barrier.h:71:3: error: read-only variable 
> > > > > '___p1'
> > > > >  used as 'asm' output
> > > >
> > > > Do you know the usage in the kernel causing this warning?
> > >
> > > A newly introduced function in include/net/sock.h:
> > >
> > > static inline int sk_state_load(const struct sock *sk)
> > > {
> > > return smp_load_acquire(>sk_state);
> > > }
> >
> > Hmm, maybe we could play a similar trick to READ_ONCE by declaring an
> > anonymous union and writing through the non-const member?
> 
> Yes, I think that would work, if you think we need to care about the
> case where we read into a structure.

How are you going to find the right type/size for the non-const member of the 
union?
If the type/size is fixed then why use typeof()?

If the variable being read (sk->sk_state above) might only be 8 or 16 bits then
you might be able to use sizeof() to select between code paths.

David

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

[PATCH] arm64: bpf: fix buffer pointer

[Zi Shen Lim]

During code review, I noticed we were passing a bad buffer pointer
to bpf_load_pointer helper function called by jitted code.

Point to the buffer allocated by JIT, so we don't silently corrupt
other parts of the stack.

Signed-off-by: Zi Shen Lim 
---
 arch/arm64/net/bpf_jit_comp.c | 27 +--
 1 file changed, 13 insertions(+), 14 deletions(-)

diff --git a/arch/arm64/net/bpf_jit_comp.c b/arch/arm64/net/bpf_jit_comp.c
index d6a53ef..7cf032b 100644
--- a/arch/arm64/net/bpf_jit_comp.c
+++ b/arch/arm64/net/bpf_jit_comp.c
@@ -139,6 +139,12 @@ static inline int epilogue_offset(const struct jit_ctx 
*ctx)
 /* Stack must be multiples of 16B */
 #define STACK_ALIGN(sz) (((sz) + 15) & ~15)
 
+#define _STACK_SIZE \
+   (MAX_BPF_STACK \
++ 4 /* extra for skb_copy_bits buffer */)
+
+#define STACK_SIZE STACK_ALIGN(_STACK_SIZE)
+
 static void build_prologue(struct jit_ctx *ctx)
 {
const u8 r6 = bpf2a64[BPF_REG_6];
@@ -150,10 +156,6 @@ static void build_prologue(struct jit_ctx *ctx)
const u8 rx = bpf2a64[BPF_REG_X];
const u8 tmp1 = bpf2a64[TMP_REG_1];
const u8 tmp2 = bpf2a64[TMP_REG_2];
-   int stack_size = MAX_BPF_STACK;
-
-   stack_size += 4; /* extra for skb_copy_bits buffer */
-   stack_size = STACK_ALIGN(stack_size);
 
/*
 * BPF prog stack layout
@@ -165,12 +167,13 @@ static void build_prologue(struct jit_ctx *ctx)
 *| ... | callee saved registers
 *+-+
 *| | x25/x26
-* BPF fp register => -80:+-+
+* BPF fp register => -80:+-+ <= (BPF_FP)
 *| |
 *| ... | BPF prog stack
 *| |
-*| |
-* current A64_SP =>  +-+
+*+-+ <= (BPF_FP - MAX_BPF_STACK)
+*|RSVD | JIT scratchpad
+* current A64_SP =>  +-+ <= (BPF_FP - STACK_SIZE)
 *| |
 *| ... | Function call stack
 *| |
@@ -196,7 +199,7 @@ static void build_prologue(struct jit_ctx *ctx)
emit(A64_MOV(1, fp, A64_SP), ctx);
 
/* Set up function call stack */
-   emit(A64_SUB_I(1, A64_SP, A64_SP, stack_size), ctx);
+   emit(A64_SUB_I(1, A64_SP, A64_SP, STACK_SIZE), ctx);
 
/* Clear registers A and X */
emit_a64_mov_i64(ra, 0, ctx);
@@ -213,13 +216,9 @@ static void build_epilogue(struct jit_ctx *ctx)
const u8 fp = bpf2a64[BPF_REG_FP];
const u8 tmp1 = bpf2a64[TMP_REG_1];
const u8 tmp2 = bpf2a64[TMP_REG_2];
-   int stack_size = MAX_BPF_STACK;
-
-   stack_size += 4; /* extra for skb_copy_bits buffer */
-   stack_size = STACK_ALIGN(stack_size);
 
/* We're done with BPF stack */
-   emit(A64_ADD_I(1, A64_SP, A64_SP, stack_size), ctx);
+   emit(A64_ADD_I(1, A64_SP, A64_SP, STACK_SIZE), ctx);
 
/* Restore fs (x25) and x26 */
emit(A64_POP(fp, A64_R(26), A64_SP), ctx);
@@ -658,7 +657,7 @@ emit_cond_jmp:
return -EINVAL;
}
emit_a64_mov_i64(r3, size, ctx);
-   emit(A64_ADD_I(1, r4, fp, MAX_BPF_STACK), ctx);
+   emit(A64_SUB_I(1, r4, fp, STACK_SIZE), ctx);
emit_a64_mov_i64(r5, (unsigned long)bpf_load_pointer, ctx);
emit(A64_PUSH(A64_FP, A64_LR, A64_SP), ctx);
emit(A64_MOV(1, A64_FP, A64_SP), ctx);
-- 
1.9.1

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

Re: [PATCH v3 net-next] net: hisilicon: fix binding document of mdio

[Arnd Bergmann]

On Wednesday 18 November 2015 10:08:00 huangdaode wrote:
> This patch explains the occasion of "hisilcon,mdio" and
> "hisilicon,hns-mdio" according to Arnd's comments.
> and reformat it according to comments from Rob.
> 
> Signed-off-by: huangdaode 
> 

Thanks a lot for addressing this!

Reviewed-by: Arnd Bergmann 

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

Re: next build: 235 warnings 3 failures (next/next-20151117)

[Will Deacon]

On Tue, Nov 17, 2015 at 08:17:17PM +0100, Arnd Bergmann wrote:
> On Tuesday 17 November 2015 17:12:37 Will Deacon wrote:
> > On Tue, Nov 17, 2015 at 06:03:40PM +0100, Arnd Bergmann wrote:
> > > On Tuesday 17 November 2015 16:44:53 Will Deacon wrote:
> > > > > 8<
> > > > > Subject: ARM64: make smp_load_acquire() work with const arguments
> > > > > 
> > > > > smp_load_acquire() uses typeof() to declare a local variable for 
> > > > > temporarily
> > > > > storing the output of the memory access. This fails when the argument 
> > > > > is
> > > > > constant, because the assembler complains about using a constant 
> > > > > register
> > > > > as output:
> > > > > 
> > > > >  arch/arm64/include/asm/barrier.h:71:3: error: read-only variable 
> > > > > '___p1'
> > > > >  used as 'asm' output
> > > > 
> > > > Do you know the usage in the kernel causing this warning?
> > > 
> > > A newly introduced function in include/net/sock.h:
> > > 
> > > static inline int sk_state_load(const struct sock *sk)
> > > {
> > > return smp_load_acquire(>sk_state);
> > > }
> > 
> > Hmm, maybe we could play a similar trick to READ_ONCE by declaring an
> > anonymous union and writing through the non-const member?
> 
> Yes, I think that would work, if you think we need to care about the
> case where we read into a structure.
> 
> Can you come up with a patch for that?

Done:

  
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-November/386094.html

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

Re: [PATCH 2/2] can: m_can: Add CAN clock generated by UPLLCK support

[Marc Kleine-Budde]

On 11/18/2015 11:04 AM, Wenyou Yang wrote:
> As said SAMA5D2 datasheet, it is recommended to use the CAN clock
> at frequencies of 20, 40 or 80 MHz. To achieve these frequencies,
> PMC GCK3 must select the UPLLCK(480 MHz) as source clock and
> divide by 24, 12 or 6. In this patch the CAN clock at 20 MHz.
> 
> As it is configured through DT, it doesn't affect the M_CAN
> without configuring CAN clock and its generated clock.
> 
> Signed-off-by: Wenyou Yang 

NACK

Please do this setup in your SoC code, where you setup the clock
infrastructure or have a look at
Documentation/devicetree/bindings/clock/clock-bindings.txt "Assigned
clock parents and rates"

> ---
> 
>  drivers/net/can/m_can/m_can.c |   16 +++-
>  1 file changed, 15 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
> index fd1caa0..2ca47db 100644
> --- a/drivers/net/can/m_can/m_can.c
> +++ b/drivers/net/can/m_can/m_can.c
> @@ -269,6 +269,8 @@ enum m_can_mram_cfg {
>  #define TX_BUF_XTD   BIT(30)
>  #define TX_BUF_RTR   BIT(29)
>  
> +#define AT91_CAN_CLK_FREQ2000
> +
>  /* address offset and element number for each FIFO/Buffer in the Message RAM 
> */
>  struct mram_cfg {
>   u16 off;
> @@ -1188,7 +1190,7 @@ static int m_can_plat_probe(struct platform_device 
> *pdev)
>   struct m_can_priv *priv;
>   struct resource *res;
>   void __iomem *addr;
> - struct clk *hclk, *cclk;
> + struct clk *hclk, *cclk, *upll_clk;
>   int irq, ret;
>  
>   hclk = devm_clk_get(>dev, "hclk");
> @@ -1198,6 +1200,18 @@ static int m_can_plat_probe(struct platform_device 
> *pdev)
>   return -ENODEV;
>   }
>  
> + upll_clk = devm_clk_get(>dev, "upllclk");
> + if (!IS_ERR(upll_clk)) {
> + ret = clk_set_parent(cclk, upll_clk);
> + if (!ret) {
> + ret = clk_set_rate(cclk, AT91_CAN_CLK_FREQ);
> + if (ret) {
> + dev_err(>dev, "failed to set gck\n");
> + return -ENODEV;
> + }
> + }
> + }
> +
>   res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "m_can");
>   addr = devm_ioremap_resource(>dev, res);
>   irq = platform_get_irq_byname(pdev, "int0");
> 

regards,
Marc

-- 
Pengutronix e.K.  | Marc Kleine-Budde   |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund  | Fax:   +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |



signature.asc
Description: OpenPGP digital signature

[PATCH 0/2] can: m_can: Add CAN clock generated by UPLLCK support

[Wenyou Yang]

This patch set is to make M_CAN work on SAMA5D2.

The orignal delay is not enough for M_CAN on SAMA5D2 to syschronize
the two clock domains. Increase the delay time to ensure the value
written to INIT can be read back.

Add CAN clock generated by UPLLCK(480 MHz) support, the implementation
doesn't affect the M_CAN without configuring additional CAN clock and
its generated clock.


Wenyou Yang (2):
  can: m_can: Increase delay to ensure written INIT accepted
  can: m_can: Add CAN clock generated by UPLLCK support

 drivers/net/can/m_can/m_can.c |   18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

-- 
1.7.9.5

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

[PATCH 2/2] can: m_can: Add CAN clock generated by UPLLCK support

[Wenyou Yang]

As said SAMA5D2 datasheet, it is recommended to use the CAN clock
at frequencies of 20, 40 or 80 MHz. To achieve these frequencies,
PMC GCK3 must select the UPLLCK(480 MHz) as source clock and
divide by 24, 12 or 6. In this patch the CAN clock at 20 MHz.

As it is configured through DT, it doesn't affect the M_CAN
without configuring CAN clock and its generated clock.

Signed-off-by: Wenyou Yang 
---

 drivers/net/can/m_can/m_can.c |   16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
index fd1caa0..2ca47db 100644
--- a/drivers/net/can/m_can/m_can.c
+++ b/drivers/net/can/m_can/m_can.c
@@ -269,6 +269,8 @@ enum m_can_mram_cfg {
 #define TX_BUF_XTD BIT(30)
 #define TX_BUF_RTR BIT(29)
 
+#define AT91_CAN_CLK_FREQ  2000
+
 /* address offset and element number for each FIFO/Buffer in the Message RAM */
 struct mram_cfg {
u16 off;
@@ -1188,7 +1190,7 @@ static int m_can_plat_probe(struct platform_device *pdev)
struct m_can_priv *priv;
struct resource *res;
void __iomem *addr;
-   struct clk *hclk, *cclk;
+   struct clk *hclk, *cclk, *upll_clk;
int irq, ret;
 
hclk = devm_clk_get(>dev, "hclk");
@@ -1198,6 +1200,18 @@ static int m_can_plat_probe(struct platform_device *pdev)
return -ENODEV;
}
 
+   upll_clk = devm_clk_get(>dev, "upllclk");
+   if (!IS_ERR(upll_clk)) {
+   ret = clk_set_parent(cclk, upll_clk);
+   if (!ret) {
+   ret = clk_set_rate(cclk, AT91_CAN_CLK_FREQ);
+   if (ret) {
+   dev_err(>dev, "failed to set gck\n");
+   return -ENODEV;
+   }
+   }
+   }
+
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "m_can");
addr = devm_ioremap_resource(>dev, res);
irq = platform_get_irq_byname(pdev, "int0");
-- 
1.7.9.5

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

[PATCH 1/2] can: m_can: Increase delay to ensure written INIT accepted

[Wenyou Yang]

Increase the delay time until the value written to INIT can be
read back to ensure that the previous value written to INIT has
been accepted.

Signed-off-by: Wenyou Yang 
---

 drivers/net/can/m_can/m_can.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
index ef65517..fd1caa0 100644
--- a/drivers/net/can/m_can/m_can.c
+++ b/drivers/net/can/m_can/m_can.c
@@ -320,7 +320,7 @@ static inline void m_can_config_endisable(const struct 
m_can_priv *priv,
  bool enable)
 {
u32 cccr = m_can_read(priv, M_CAN_CCCR);
-   u32 timeout = 10;
+   u32 timeout = 1000;
u32 val = 0;
 
if (enable) {
-- 
1.7.9.5

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

Re: [PATCH 1/3] dl2k: Handle memory allocation errors in alloc_list

[Ondrej Zary]

On Tuesday 17 November 2015, Francois Romieu wrote:
> Ondrej Zary  :
> > If memory allocation fails in alloc_list(), free the already allocated
> > memory and return -ENODEV. In rio_open(), call alloc_list() first and
> > abort if it fails. Move HW access (set RFDListPtr) out ot alloc_list().
> >
> > Signed-off-by: Ondrej Zary 
>
> ENODEV vs ENOMEM aside, it's ok with me.

Will fix the description in v2.

> The driver may avoid depleting the receive ring when
> netdev_alloc_skb_ip_align fails in receive_packet (drop and increase
> stats->rx_dropped).
>
> Then you may replace the pci_* dma helpers with the plain dma_* ones (they
> can fail).
>
> And perform a plain napi conversion.

NAPI is on the todo list. Thanks for suggestions.

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

Re: Add a SOCK_DESTROY operation to close sockets from userspace

[Hannes Frederic Sowa]

Hi,

On Wed, Nov 18, 2015, at 05:04, Eric Dumazet wrote:
> On Tue, 2015-11-17 at 19:27 -0800, Stephen Hemminger wrote:
> 
> > I understand why you might want this, but it smells like the same
> > kind of problems that the "forced unmount" patch had which eventually
> > led to it not being accepted in mainline.  Lots of corner
> > cases and race conditions waiting to blow up.
> 
> Well, disconnecting a TCP socket seems straightforward, once you get a
> sk pointer.
> 
> Code looks good.
> 
> > 
> > Look at the issues that the multi-thread socket close has.
> > This looks worse.
> 
> I do not see a problem here. A RST packet has roughly same effect, and
> we do process them.
> 
> Cookies are 64bits and uniquely identify a socket.
> 
> Once you make sure the request comes from a privileged user, we are
> good.
> 
> This user could easily install some iptables rules to generate RST
> packets anyway.

I bet there will soon be a timewaitd which handles the not configurable
(David has rejected all those patches so far) timeout of TIME_WAIT
sockets. And I bet it will be used. :/

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

Re: [PATCH] ethernet/atheros/alx: add Killer E2400 device ID

[Ben Pope]

18/11/15 09:21, Jason Gerard DeRose wrote:

From: Ben Pope 

This patch adds the PCI device ID (0xe0a1) and alx_pci_tbl entry for the
Killer E2400 Ethernet controller, modeled after the Killer E2200
controller support (0xe091) already present in the alx driver.

This patch was originally authored by Ben Pope, but it got held up by
issues in the commit message, so I'm resubmitting it on his behalf.

I've extensively used a kernel with this patch on a System76 serw9
laptop and am quite confident it works well (at least on the hardware I
have available for testing).

Note that as a favor to System76, Ubuntu has been carrying this as a
sauce patch in their 4.2 based Wily kernel, which presumably has given
it real-world testing on other E2400 equipped hardware (I don't know of
any Ubuntu kernel bugs filed about it):

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1498633

Signed-off-by: Jason Gerard DeRose 
---
  drivers/net/ethernet/atheros/alx/main.c | 2 ++
  drivers/net/ethernet/atheros/alx/reg.h  | 1 +
  2 files changed, 3 insertions(+)

diff --git a/drivers/net/ethernet/atheros/alx/main.c 
b/drivers/net/ethernet/atheros/alx/main.c
index c8af3ce..bd377a6 100644
--- a/drivers/net/ethernet/atheros/alx/main.c
+++ b/drivers/net/ethernet/atheros/alx/main.c
@@ -1534,6 +1534,8 @@ static const struct pci_device_id alx_pci_tbl[] = {
  .driver_data = ALX_DEV_QUIRK_MSI_INTX_DISABLE_BUG },
{ PCI_VDEVICE(ATTANSIC, ALX_DEV_ID_E2200),
  .driver_data = ALX_DEV_QUIRK_MSI_INTX_DISABLE_BUG },
+   { PCI_VDEVICE(ATTANSIC, ALX_DEV_ID_E2400),
+ .driver_data = ALX_DEV_QUIRK_MSI_INTX_DISABLE_BUG },
{ PCI_VDEVICE(ATTANSIC, ALX_DEV_ID_AR8162),
  .driver_data = ALX_DEV_QUIRK_MSI_INTX_DISABLE_BUG },
{ PCI_VDEVICE(ATTANSIC, ALX_DEV_ID_AR8171) },
diff --git a/drivers/net/ethernet/atheros/alx/reg.h 
b/drivers/net/ethernet/atheros/alx/reg.h
index af006b4..0959e68 100644
--- a/drivers/net/ethernet/atheros/alx/reg.h
+++ b/drivers/net/ethernet/atheros/alx/reg.h
@@ -37,6 +37,7 @@
  
  #define ALX_DEV_ID_AR81610x1091

  #define ALX_DEV_ID_E2200  0xe091
+#define ALX_DEV_ID_E2400   0xe0a1
  #define ALX_DEV_ID_AR8162 0x1090
  #define ALX_DEV_ID_AR8171 0x10A1
  #define ALX_DEV_ID_AR8172 0x10A0


Signed-off-by: Ben Pope 

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

[PATCH v2 net-next 06/14] mlx5: add busy polling support

[Eric Dumazet]

It is now easy to add busy polling support to a NAPI driver,
with very little impact on normal input path.

This patch serves as a reference implementation.

Note:

A followup patch will add proper napi_complete_done() in mlx5,
so that LINUX_MIB_BUSYPOLLRXPACKETS snmp counter is properly handled.

Tested:

Normal TCP_RR results without busy polling :

lpk51:~# echo 0 >/proc/sys/net/core/busy_read
lpk52:~# echo 0 >/proc/sys/net/core/busy_read

lpk51:~# ./netperf -H 192.168.4.52 -t TCP_RR -l 10
MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 
192.168.4.52 () port 0 AF_INET : first burst 0
Local /Remote
Socket Size   Request  Resp.   Elapsed  Trans.
Send   Recv   Size SizeTime Rate
bytes  Bytes  bytesbytes   secs.per sec

16384  87380  11   10.0053509.49
16384  87380

Now enable busy polling :

lpk51:~# echo 70 >/proc/sys/net/core/busy_read
lpk52:~# echo 70 >/proc/sys/net/core/busy_read

lpk51:~# ./netperf -H 192.168.4.52 -t TCP_RR -l 10
MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 
192.168.4.52 () port 0 AF_INET : first burst 0
Local /Remote
Socket Size   Request  Resp.   Elapsed  Trans.
Send   Recv   Size SizeTime Rate
bytes  Bytes  bytesbytes   secs.per sec

16384  87380  11   10.0097530.92
16384  87380

Signed-off-by: Eric Dumazet 
---
 drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 6 ++
 drivers/net/ethernet/mellanox/mlx5/core/en_rx.c   | 2 ++
 2 files changed, 8 insertions(+)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c 
b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
index 1e52db32c73d..ffb1f9c1b973 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
@@ -982,6 +982,7 @@ static int mlx5e_open_channel(struct mlx5e_priv *priv, int 
ix,
mlx5e_build_channeltc_to_txq_map(priv, ix);
 
netif_napi_add(netdev, >napi, mlx5e_napi_poll, 64);
+   napi_hash_add(>napi);
 
err = mlx5e_open_tx_cqs(c, cparam);
if (err)
@@ -1020,6 +1021,7 @@ err_close_tx_cqs:
 
 err_napi_del:
netif_napi_del(>napi);
+   napi_hash_del(>napi);
kfree(c);
 
return err;
@@ -1033,6 +1035,10 @@ static void mlx5e_close_channel(struct mlx5e_channel *c)
mlx5e_close_cq(>rq.cq);
mlx5e_close_tx_cqs(c);
netif_napi_del(>napi);
+
+   napi_hash_del(>napi);
+   synchronize_rcu();
+
kfree(c);
 }
 
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c 
b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
index cf0098596e85..54800c61a563 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "en.h"
 
 static inline int mlx5e_alloc_rx_wqe(struct mlx5e_rq *rq,
@@ -242,6 +243,7 @@ bool mlx5e_poll_rx_cq(struct mlx5e_cq *cq, int budget)
wqe= mlx5_wq_ll_get_wqe(>wq, wqe_counter);
skb= rq->skb[wqe_counter];
prefetch(skb->data);
+   skb_mark_napi_id(skb, cq->napi);
rq->skb[wqe_counter] = NULL;
 
dma_unmap_single(rq->pdev,
-- 
2.6.0.rc2.230.g3dd15c0

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

[PATCH v2 net-next 10/14] net: move skb_mark_napi_id() into core networking stack

[Eric Dumazet]

We would like to automatically provide busy polling support
to all NAPI drivers, without them having to implement anything.

skb_mark_napi_id() can be called from napi_gro_receive() and
napi_get_frags().

Few drivers are still calling skb_mark_napi_id() because
they use netif_receive_skb(). They should eventually call
napi_gro_receive() instead. I will leave this to drivers
maintainers.

Signed-off-by: Eric Dumazet 
---
 drivers/net/ethernet/amd/xgbe/xgbe-drv.c | 1 -
 drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c  | 2 --
 drivers/net/ethernet/chelsio/cxgb4/sge.c | 1 -
 drivers/net/ethernet/emulex/benet/be_main.c  | 1 -
 drivers/net/ethernet/intel/i40e/i40e_txrx.c  | 1 -
 drivers/net/ethernet/intel/i40evf/i40e_txrx.c| 1 -
 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c| 2 +-
 drivers/net/ethernet/mellanox/mlx4/en_rx.c   | 3 ---
 drivers/net/ethernet/mellanox/mlx5/core/en_rx.c  | 1 -
 drivers/net/ethernet/myricom/myri10ge/myri10ge.c | 2 +-
 drivers/net/ethernet/sfc/rx.c| 1 -
 drivers/net/virtio_net.c | 2 --
 net/core/dev.c   | 2 ++
 13 files changed, 4 insertions(+), 16 deletions(-)

diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-drv.c 
b/drivers/net/ethernet/amd/xgbe/xgbe-drv.c
index 53ce1222b11d..8a9b493566c9 100644
--- a/drivers/net/ethernet/amd/xgbe/xgbe-drv.c
+++ b/drivers/net/ethernet/amd/xgbe/xgbe-drv.c
@@ -2024,7 +2024,6 @@ read_again:
skb->dev = netdev;
skb->protocol = eth_type_trans(skb, netdev);
skb_record_rx_queue(skb, channel->queue_index);
-   skb_mark_napi_id(skb, napi);
 
napi_gro_receive(napi, skb);
 
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c 
b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
index ca208a7eecd5..ab9222924bd9 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
@@ -1094,8 +1094,6 @@ reuse_rx:
__vlan_hwaccel_put_tag(skb, htons(ETH_P_8021Q),
   le16_to_cpu(cqe_fp->vlan_tag));
 
-   skb_mark_napi_id(skb, >napi);
-
napi_gro_receive(>napi, skb);
 next_rx:
rx_buf->data = NULL;
diff --git a/drivers/net/ethernet/chelsio/cxgb4/sge.c 
b/drivers/net/ethernet/chelsio/cxgb4/sge.c
index b7b93e7a643d..f650f295f264 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/sge.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/sge.c
@@ -1864,7 +1864,6 @@ static void do_gro(struct sge_eth_rxq *rxq, const struct 
pkt_gl *gl,
skb->truesize += skb->data_len;
skb->ip_summed = CHECKSUM_UNNECESSARY;
skb_record_rx_queue(skb, rxq->rspq.idx);
-   skb_mark_napi_id(skb, >rspq.napi);
pi = netdev_priv(skb->dev);
if (pi->rxtstamp)
cxgb4_sgetim_to_hwtstamp(adapter, skb_hwtstamps(skb),
diff --git a/drivers/net/ethernet/emulex/benet/be_main.c 
b/drivers/net/ethernet/emulex/benet/be_main.c
index b6ad02909d6b..c29d62496ad9 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -2184,7 +2184,6 @@ static void be_rx_compl_process_gro(struct be_rx_obj *rxo,
skb_set_hash(skb, rxcp->rss_hash, PKT_HASH_TYPE_L3);
 
skb->csum_level = rxcp->tunneled;
-   skb_mark_napi_id(skb, napi);
 
if (rxcp->vlanf)
__vlan_hwaccel_put_tag(skb, htons(ETH_P_8021Q), rxcp->vlan_tag);
diff --git a/drivers/net/ethernet/intel/i40e/i40e_txrx.c 
b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
index 635b3ac17877..6649ce4ba2de 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_txrx.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
@@ -1632,7 +1632,6 @@ static int i40e_clean_rx_irq_ps(struct i40e_ring 
*rx_ring, int budget)
continue;
}
 #endif
-   skb_mark_napi_id(skb, _ring->q_vector->napi);
i40e_receive_skb(rx_ring, skb, vlan_tag);
 
rx_desc->wb.qword1.status_error_len = 0;
diff --git a/drivers/net/ethernet/intel/i40evf/i40e_txrx.c 
b/drivers/net/ethernet/intel/i40evf/i40e_txrx.c
index 47e9a90d6b10..77968b184b1f 100644
--- a/drivers/net/ethernet/intel/i40evf/i40e_txrx.c
+++ b/drivers/net/ethernet/intel/i40evf/i40e_txrx.c
@@ -1090,7 +1090,6 @@ static int i40e_clean_rx_irq_ps(struct i40e_ring 
*rx_ring, int budget)
continue;
}
 #endif
-   skb_mark_napi_id(skb, _ring->q_vector->napi);
i40e_receive_skb(rx_ring, skb, vlan_tag);
 
rx_desc->wb.qword1.status_error_len = 0;
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c 
b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 47395ff5d908..4089d776d01a 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -1659,6 +1659,7 @@ 

[PATCH v2 net-next 08/14] bnx2x: remove bnx2x_low_latency_recv() support

[Eric Dumazet]

Switch to native NAPI polling, as this reduces overhead and complexity.

Normal path is faster, since one cmpxchg() is not anymore requested,
and busy polling with the NAPI polling has same performance.

Tested:
lpk50:~# cat /proc/sys/net/core/busy_read
70
lpk50:~# nstat >/dev/null;./netperf -H lpk55 -t TCP_RR;nstat
MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 
lpk55.prod.google.com () port 0 AF_INET : first burst 0
Local /Remote
Socket Size   Request  Resp.   Elapsed  Trans.
Send   Recv   Size SizeTime Rate
bytes  Bytes  bytesbytes   secs.per sec

16384  87380  11   10.0040095.07
16384  87380
IpInReceives401062 0.0
IpInDelivers401062 0.0
IpOutRequests   401079 0.0
TcpActiveOpens  7  0.0
TcpPassiveOpens 3  0.0
TcpAttemptFails 3  0.0
TcpEstabResets  5  0.0
TcpInSegs   401036 0.0
TcpOutSegs  401052 0.0
TcpOutRsts  38 0.0
UdpInDatagrams  26 0.0
UdpOutDatagrams 27 0.0
Ip6OutNoRoutes  1  0.0
TcpExtDelayedACKs   1  0.0
TcpExtTCPPrequeued  98 0.0
TcpExtTCPDirectCopyFromPrequeue 98 0.0
TcpExtTCPHPHits 4  0.0
TcpExtTCPHPHitsToUser   98 0.0
TcpExtTCPPureAcks   5  0.0
TcpExtTCPHPAcks 1010.0
TcpExtTCPAbortOnData6  0.0
TcpExtBusyPollRxPackets 400832 0.0
TcpExtTCPOrigDataSent   400983 0.0
IpExtInOctets   21273867   0.0
IpExtOutOctets  21261254   0.0
IpExtInNoECTPkts401064 0.0

Signed-off-by: Eric Dumazet 
---
 drivers/net/ethernet/broadcom/bnx2x/bnx2x.h  | 113 ---
 drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c  |  46 +
 drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h  |   7 --
 drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c |   3 -
 4 files changed, 2 insertions(+), 167 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h 
b/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
index b5e64b02200c..0b214b5d944a 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
@@ -540,10 +540,6 @@ struct bnx2x_fastpath {
 
struct napi_struct  napi;
 
-#ifdef CONFIG_NET_RX_BUSY_POLL
-   unsigned long   busy_poll_state;
-#endif
-
union host_hc_status_block  status_blk;
/* chip independent shortcuts into sb structure */
__le16  *sb_index_values;
@@ -617,115 +613,6 @@ struct bnx2x_fastpath {
 #define bnx2x_fp_stats(bp, fp) (&((bp)->fp_stats[(fp)->index]))
 #define bnx2x_fp_qstats(bp, fp)
(&((bp)->fp_stats[(fp)->index].eth_q_stats))
 
-#ifdef CONFIG_NET_RX_BUSY_POLL
-
-enum bnx2x_fp_state {
-   BNX2X_STATE_FP_NAPI = BIT(0), /* NAPI handler owns the queue */
-
-   BNX2X_STATE_FP_NAPI_REQ_BIT = 1, /* NAPI would like to own the queue */
-   BNX2X_STATE_FP_NAPI_REQ = BIT(1),
-
-   BNX2X_STATE_FP_POLL_BIT = 2,
-   BNX2X_STATE_FP_POLL = BIT(2), /* busy_poll owns the queue */
-
-   BNX2X_STATE_FP_DISABLE_BIT = 3, /* queue is dismantled */
-};
-
-static inline void bnx2x_fp_busy_poll_init(struct bnx2x_fastpath *fp)
-{
-   WRITE_ONCE(fp->busy_poll_state, 0);
-}
-
-/* called from the device poll routine to get ownership of a FP */
-static inline bool bnx2x_fp_lock_napi(struct bnx2x_fastpath *fp)
-{
-   unsigned long prev, old = READ_ONCE(fp->busy_poll_state);
-
-   while (1) {
-   switch (old) {
-   case BNX2X_STATE_FP_POLL:
-   /* make sure bnx2x_fp_lock_poll() wont starve us */
-   set_bit(BNX2X_STATE_FP_NAPI_REQ_BIT,
-   >busy_poll_state);
-   /* fallthrough */
-   case BNX2X_STATE_FP_POLL | BNX2X_STATE_FP_NAPI_REQ:
-   return false;
-   default:
-   break;
-   }
-   prev = cmpxchg(>busy_poll_state, old, BNX2X_STATE_FP_NAPI);
-   if (unlikely(prev != old)) {
-   old = prev;
-   continue;
-   }
-   return true;
-   }
-}
-
-static inline void bnx2x_fp_unlock_napi(struct bnx2x_fastpath *fp)
-{
-   smp_wmb();
-   fp->busy_poll_state = 0;
-}
-
-/* called from bnx2x_low_latency_poll() */
-static inline bool bnx2x_fp_lock_poll(struct 

[PATCH v2 net-next 05/14] net: network drivers no longer need to implement ndo_busy_poll()

[Eric Dumazet]

Instead of having to implement complex ndo_busy_poll() method,
drivers can simply rely on NAPI poll logic.

Busy polling gains are mainly coming from polling itself,
not on exact details on how we poll the device.

ndo_busy_poll() if implemented can avoid touching
napi state, but it adds extra synchronization between
normal napi->poll() and busy poll handler, slowing down
the common path (non busy polling) with extra atomic operations.
In practice few drivers ever got busy poll because of the complexity.

We could go one step further, and make busy polling
available for all NAPI drivers, but this would require
that all netif_napi_del() calls are done in process context
so that we can call synchronize_rcu().
Full audit would be required.

Before this is done, a driver still needs to call :

- skb_mark_napi_id() for each skb provided to the stack.
- napi_hash_add() and napi_hash_del() to allocate a napi_id per napi struct.
- Make sure RCU grace period is respected after napi_hash_del() before
  memory containing napi structure is freed.

Followup patch implements busy poll for mlx5 driver as an example.

Signed-off-by: Eric Dumazet 
---
 net/core/dev.c | 25 -
 1 file changed, 20 insertions(+), 5 deletions(-)

diff --git a/net/core/dev.c b/net/core/dev.c
index 2002eec2617d..93009610aee8 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4677,10 +4677,11 @@ static struct napi_struct *napi_by_id(unsigned int 
napi_id)
 }
 
 #if defined(CONFIG_NET_RX_BUSY_POLL)
+#define BUSY_POLL_BUDGET 8
 bool sk_busy_loop(struct sock *sk, int nonblock)
 {
unsigned long end_time = !nonblock ? sk_busy_loop_end_time(sk) : 0;
-   const struct net_device_ops *ops;
+   int (*busy_poll)(struct napi_struct *dev);
struct napi_struct *napi;
int rc = false;
 
@@ -4690,13 +4691,27 @@ bool sk_busy_loop(struct sock *sk, int nonblock)
if (!napi)
goto out;
 
-   ops = napi->dev->netdev_ops;
-   if (!ops->ndo_busy_poll)
-   goto out;
+   /* Note: ndo_busy_poll method is optional in linux-4.5 */
+   busy_poll = napi->dev->netdev_ops->ndo_busy_poll;
 
do {
+   rc = 0;
local_bh_disable();
-   rc = ops->ndo_busy_poll(napi);
+   if (busy_poll) {
+   rc = busy_poll(napi);
+   } else if (napi_schedule_prep(napi)) {
+   void *have = netpoll_poll_lock(napi);
+
+   if (test_bit(NAPI_STATE_SCHED, >state)) {
+   rc = napi->poll(napi, BUSY_POLL_BUDGET);
+   trace_napi_poll(napi);
+   if (rc == BUSY_POLL_BUDGET) {
+   napi_complete_done(napi, rc);
+   napi_schedule(napi);
+   }
+   }
+   netpoll_poll_unlock(have);
+   }
if (rc > 0)
NET_ADD_STATS_BH(sock_net(sk),
 LINUX_MIB_BUSYPOLLRXPACKETS, rc);
-- 
2.6.0.rc2.230.g3dd15c0

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

[PATCH v2 net-next 07/14] mlx5: support napi_complete_done()

[Eric Dumazet]

A NAPI poll handler should return number of RX packets processed,
instead of 0 / budget.

This allows proper busy poll accounting through LINUX_MIB_BUSYPOLLRXPACKETS
SNMP counter.

napi_complete_done() allows /sys/class/net/ethX/gro_flush_timeout
to be used for finer GRO aggregation control.

Tested:

Enabled busy polling, and checked TcpExtBusyPollRxPackets counter is increasing.

echo 70 >/proc/sys/net/core/busy_read
nstat >/dev/null
netperf -H target -t TCP_RR >/dev/null
nstat | grep TcpExtBusyPollRxPackets
TcpExtBusyPollRxPackets 490958 0.0

Signed-off-by: Eric Dumazet 
Cc: Eli Cohen 
---
 drivers/net/ethernet/mellanox/mlx5/core/en.h  |  2 +-
 drivers/net/ethernet/mellanox/mlx5/core/en_rx.c   | 14 ++
 drivers/net/ethernet/mellanox/mlx5/core/en_txrx.c | 11 ++-
 3 files changed, 13 insertions(+), 14 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en.h 
b/drivers/net/ethernet/mellanox/mlx5/core/en.h
index 22e72bf1ae48..69f1c1a412b4 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en.h
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en.h
@@ -564,7 +564,7 @@ void mlx5e_completion_event(struct mlx5_core_cq *mcq);
 void mlx5e_cq_error_event(struct mlx5_core_cq *mcq, enum mlx5_event event);
 int mlx5e_napi_poll(struct napi_struct *napi, int budget);
 bool mlx5e_poll_tx_cq(struct mlx5e_cq *cq);
-bool mlx5e_poll_rx_cq(struct mlx5e_cq *cq, int budget);
+int mlx5e_poll_rx_cq(struct mlx5e_cq *cq, int budget);
 bool mlx5e_post_rx_wqes(struct mlx5e_rq *rq);
 struct mlx5_cqe64 *mlx5e_get_cqe(struct mlx5e_cq *cq);
 
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c 
b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
index 54800c61a563..fe752f8e24b9 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
@@ -216,16 +216,16 @@ static inline void mlx5e_build_rx_skb(struct mlx5_cqe64 
*cqe,
   be16_to_cpu(cqe->vlan_info));
 }
 
-bool mlx5e_poll_rx_cq(struct mlx5e_cq *cq, int budget)
+int mlx5e_poll_rx_cq(struct mlx5e_cq *cq, int budget)
 {
struct mlx5e_rq *rq = container_of(cq, struct mlx5e_rq, cq);
-   int i;
+   int work_done;
 
/* avoid accessing cq (dma coherent memory) if not needed */
if (!test_and_clear_bit(MLX5E_CQ_HAS_CQES, >flags))
-   return false;
+   return 0;
 
-   for (i = 0; i < budget; i++) {
+   for (work_done = 0; work_done < budget; work_done++) {
struct mlx5e_rx_wqe *wqe;
struct mlx5_cqe64 *cqe;
struct sk_buff *skb;
@@ -271,10 +271,8 @@ wq_ll_pop:
/* ensure cq space is freed before enabling more cqes */
wmb();
 
-   if (i == budget) {
+   if (work_done == budget)
set_bit(MLX5E_CQ_HAS_CQES, >flags);
-   return true;
-   }
 
-   return false;
+   return work_done;
 }
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_txrx.c 
b/drivers/net/ethernet/mellanox/mlx5/core/en_txrx.c
index 2c7cb6755d1d..4ac8d716dbdd 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_txrx.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_txrx.c
@@ -54,6 +54,7 @@ int mlx5e_napi_poll(struct napi_struct *napi, int budget)
struct mlx5e_channel *c = container_of(napi, struct mlx5e_channel,
   napi);
bool busy = false;
+   int work_done;
int i;
 
clear_bit(MLX5E_CHANNEL_NAPI_SCHED, >flags);
@@ -61,26 +62,26 @@ int mlx5e_napi_poll(struct napi_struct *napi, int budget)
for (i = 0; i < c->num_tc; i++)
busy |= mlx5e_poll_tx_cq(>sq[i].cq);
 
-   busy |= mlx5e_poll_rx_cq(>rq.cq, budget);
-
+   work_done = mlx5e_poll_rx_cq(>rq.cq, budget);
+   busy |= work_done == budget;
busy |= mlx5e_post_rx_wqes(>rq);
 
if (busy)
return budget;
 
-   napi_complete(napi);
+   napi_complete_done(napi, work_done);
 
/* avoid losing completion event during/after polling cqs */
if (test_bit(MLX5E_CHANNEL_NAPI_SCHED, >flags)) {
napi_schedule(napi);
-   return 0;
+   return work_done;
}
 
for (i = 0; i < c->num_tc; i++)
mlx5e_cq_arm(>sq[i].cq);
mlx5e_cq_arm(>rq.cq);
 
-   return 0;
+   return work_done;
 }
 
 void mlx5e_completion_event(struct mlx5_core_cq *mcq)
-- 
2.6.0.rc2.230.g3dd15c0

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

[PATCH v2 26/27] ath: unify Kconfig with other vendors

[Kalle Valo]

Change menuconfig to config to keep the Kconfig entries unified. Part of
reorganising wireless drivers directory and Kconfig.

Signed-off-by: Kalle Valo 
---
 drivers/net/wireless/Kconfig |3 +--
 drivers/net/wireless/Makefile|3 +--
 drivers/net/wireless/ath/Kconfig |   17 ++---
 3 files changed, 12 insertions(+), 11 deletions(-)

diff --git a/drivers/net/wireless/Kconfig b/drivers/net/wireless/Kconfig
index cb115db309ce..3af6d0b9ca21 100644
--- a/drivers/net/wireless/Kconfig
+++ b/drivers/net/wireless/Kconfig
@@ -18,6 +18,7 @@ menuconfig WLAN
 if WLAN
 
 source "drivers/net/wireless/admtek/Kconfig"
+source "drivers/net/wireless/ath/Kconfig"
 source "drivers/net/wireless/atmel/Kconfig"
 source "drivers/net/wireless/broadcom/Kconfig"
 source "drivers/net/wireless/cisco/Kconfig"
@@ -99,6 +100,4 @@ config MAC80211_HWSIM
  To compile this driver as a module, choose M here: the module will be
  called mac80211_hwsim.  If unsure, say N.
 
-source "drivers/net/wireless/ath/Kconfig"
-
 endif # WLAN
diff --git a/drivers/net/wireless/Makefile b/drivers/net/wireless/Makefile
index 8c99b9faab09..f00d42953fb8 100644
--- a/drivers/net/wireless/Makefile
+++ b/drivers/net/wireless/Makefile
@@ -3,6 +3,7 @@
 #
 
 obj-$(CONFIG_WLAN_VENDOR_ADMTEK) += admtek/
+obj-$(CONFIG_WLAN_VENDOR_ATH) += ath/
 obj-$(CONFIG_WLAN_VENDOR_ATMEL) += atmel/
 obj-$(CONFIG_WLAN_VENDOR_BROADCOM) += broadcom/
 obj-$(CONFIG_WLAN_VENDOR_CISCO) += cisco/
@@ -23,6 +24,4 @@ obj-$(CONFIG_PCMCIA_WL3501)   += wl3501_cs.o
 
 obj-$(CONFIG_USB_NET_RNDIS_WLAN)   += rndis_wlan.o
 
-obj-$(CONFIG_ATH_CARDS)+= ath/
-
 obj-$(CONFIG_MAC80211_HWSIM)   += mac80211_hwsim.o
diff --git a/drivers/net/wireless/ath/Kconfig b/drivers/net/wireless/ath/Kconfig
index ce7826009eeb..44b2470af81d 100644
--- a/drivers/net/wireless/ath/Kconfig
+++ b/drivers/net/wireless/ath/Kconfig
@@ -1,13 +1,16 @@
 config ATH_COMMON
tristate
 
-menuconfig ATH_CARDS
-   tristate "Atheros Wireless Cards"
-   depends on CFG80211 && (!UML || BROKEN)
+config WLAN_VENDOR_ATH
+   bool "Atheros/Qualcomm devices"
+   default y
---help---
- This will enable the support for the Atheros wireless drivers.
- ath5k, ath9k, ath9k_htc and ar9170 drivers share some common code, 
this option
- enables the common ath.ko module which shares common helpers.
+ If you have a wireless card belonging to this class, say Y.
+
+ Note that the answer to this question doesn't directly affect the
+ kernel: saying N will just cause the configurator to skip all
+ the questions about  cards. If you say Y, you will be asked for
+ your specific card in the following questions.
 
  For more information and documentation on this module you can visit:
 
@@ -17,7 +20,7 @@ menuconfig ATH_CARDS
 
  http://wireless.kernel.org/en/users/Drivers/Atheros
 
-if ATH_CARDS
+if WLAN_VENDOR_ATH
 
 config ATH_DEBUG
bool "Atheros wireless debugging"
-- 
1.7.9.5

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

[PATCH v2 27/27] mac80211_hwsim: move Kconfig entry for sorting alphabetically

[Kalle Valo]

mac80211_hwsim was not placed alphabetically correctly in menuconfig, fix that.

Signed-off-by: Kalle Valo 
---
 drivers/net/wireless/Kconfig |   26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/net/wireless/Kconfig b/drivers/net/wireless/Kconfig
index 3af6d0b9ca21..8c8edaf1bba6 100644
--- a/drivers/net/wireless/Kconfig
+++ b/drivers/net/wireless/Kconfig
@@ -58,6 +58,19 @@ config PCMCIA_WL3501
  It has basic support for Linux wireless extensions and initial
  micro support for ethtool.
 
+config MAC80211_HWSIM
+   tristate "Simulated radio testing tool for mac80211"
+   depends on MAC80211
+   ---help---
+ This driver is a developer testing tool that can be used to test
+ IEEE 802.11 networking stack (mac80211) functionality. This is not
+ needed for normal wireless LAN usage and is only for testing. See
+ Documentation/networking/mac80211_hwsim for more information on how
+ to use this tool.
+
+ To compile this driver as a module, choose M here: the module will be
+ called mac80211_hwsim.  If unsure, say N.
+
 config USB_NET_RNDIS_WLAN
tristate "Wireless RNDIS USB support"
depends on USB
@@ -87,17 +100,4 @@ config USB_NET_RNDIS_WLAN
 
  If you choose to build a module, it'll be called rndis_wlan.
 
-config MAC80211_HWSIM
-   tristate "Simulated radio testing tool for mac80211"
-   depends on MAC80211
-   ---help---
- This driver is a developer testing tool that can be used to test
- IEEE 802.11 networking stack (mac80211) functionality. This is not
- needed for normal wireless LAN usage and is only for testing. See
- Documentation/networking/mac80211_hwsim for more information on how
- to use this tool.
-
- To compile this driver as a module, choose M here: the module will be
- called mac80211_hwsim.  If unsure, say N.
-
 endif # WLAN
-- 
1.7.9.5

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

[PATCH v2 16/27] zd1211rw: move under zydas vendor directory

[Kalle Valo]

Part of reorganising wireless drivers directory and Kconfig.

Signed-off-by: Kalle Valo 
---
 MAINTAINERS|2 +-
 drivers/net/wireless/Kconfig   |1 -
 drivers/net/wireless/Makefile  |1 -
 drivers/net/wireless/zydas/Kconfig |2 ++
 drivers/net/wireless/zydas/Makefile|2 ++
 drivers/net/wireless/{ => zydas}/zd1211rw/Kconfig  |0
 drivers/net/wireless/{ => zydas}/zd1211rw/Makefile |0
 .../net/wireless/{ => zydas}/zd1211rw/zd_chip.c|0
 .../net/wireless/{ => zydas}/zd1211rw/zd_chip.h|0
 drivers/net/wireless/{ => zydas}/zd1211rw/zd_def.h |0
 drivers/net/wireless/{ => zydas}/zd1211rw/zd_mac.c |0
 drivers/net/wireless/{ => zydas}/zd1211rw/zd_mac.h |0
 drivers/net/wireless/{ => zydas}/zd1211rw/zd_rf.c  |0
 drivers/net/wireless/{ => zydas}/zd1211rw/zd_rf.h  |0
 .../wireless/{ => zydas}/zd1211rw/zd_rf_al2230.c   |0
 .../wireless/{ => zydas}/zd1211rw/zd_rf_al7230b.c  |0
 .../wireless/{ => zydas}/zd1211rw/zd_rf_rf2959.c   |0
 .../wireless/{ => zydas}/zd1211rw/zd_rf_uw2453.c   |0
 drivers/net/wireless/{ => zydas}/zd1211rw/zd_usb.c |0
 drivers/net/wireless/{ => zydas}/zd1211rw/zd_usb.h |0
 20 files changed, 5 insertions(+), 3 deletions(-)
 rename drivers/net/wireless/{ => zydas}/zd1211rw/Kconfig (100%)
 rename drivers/net/wireless/{ => zydas}/zd1211rw/Makefile (100%)
 rename drivers/net/wireless/{ => zydas}/zd1211rw/zd_chip.c (100%)
 rename drivers/net/wireless/{ => zydas}/zd1211rw/zd_chip.h (100%)
 rename drivers/net/wireless/{ => zydas}/zd1211rw/zd_def.h (100%)
 rename drivers/net/wireless/{ => zydas}/zd1211rw/zd_mac.c (100%)
 rename drivers/net/wireless/{ => zydas}/zd1211rw/zd_mac.h (100%)
 rename drivers/net/wireless/{ => zydas}/zd1211rw/zd_rf.c (100%)
 rename drivers/net/wireless/{ => zydas}/zd1211rw/zd_rf.h (100%)
 rename drivers/net/wireless/{ => zydas}/zd1211rw/zd_rf_al2230.c (100%)
 rename drivers/net/wireless/{ => zydas}/zd1211rw/zd_rf_al7230b.c (100%)
 rename drivers/net/wireless/{ => zydas}/zd1211rw/zd_rf_rf2959.c (100%)
 rename drivers/net/wireless/{ => zydas}/zd1211rw/zd_rf_uw2453.c (100%)
 rename drivers/net/wireless/{ => zydas}/zd1211rw/zd_usb.c (100%)
 rename drivers/net/wireless/{ => zydas}/zd1211rw/zd_usb.h (100%)

diff --git a/MAINTAINERS b/MAINTAINERS
index ec098370ef3d..f2e78420488c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11883,7 +11883,7 @@ W:  http://zd1211.ath.cx/wiki/DriverRewrite
 L: linux-wirel...@vger.kernel.org
 L: zd1211-d...@lists.sourceforge.net (subscribers-only)
 S: Maintained
-F: drivers/net/wireless/zd1211rw/
+F: drivers/net/wireless/zydas/zd1211rw/
 
 ZPOOL COMPRESSED PAGE STORAGE API
 M: Dan Streetman 
diff --git a/drivers/net/wireless/Kconfig b/drivers/net/wireless/Kconfig
index 35155e2dc8bf..e86dcdd5cfcb 100644
--- a/drivers/net/wireless/Kconfig
+++ b/drivers/net/wireless/Kconfig
@@ -124,7 +124,6 @@ source "drivers/net/wireless/mediatek/Kconfig"
 source "drivers/net/wireless/realtek/rtlwifi/Kconfig"
 source "drivers/net/wireless/realtek/rtl8xxxu/Kconfig"
 source "drivers/net/wireless/ti/Kconfig"
-source "drivers/net/wireless/zd1211rw/Kconfig"
 source "drivers/net/wireless/rsi/Kconfig"
 
 endif # WLAN
diff --git a/drivers/net/wireless/Makefile b/drivers/net/wireless/Makefile
index 4ee6d6d08743..8f54adde831e 100644
--- a/drivers/net/wireless/Makefile
+++ b/drivers/net/wireless/Makefile
@@ -16,7 +16,6 @@ obj-$(CONFIG_HERMES)  += orinoco/
 obj-$(CONFIG_PRISM54)  += prism54/
 
 obj-$(CONFIG_HOSTAP)   += hostap/
-obj-$(CONFIG_ZD1211RW) += zd1211rw/
 obj-$(CONFIG_WLAN) += realtek/
 
 # 16-bit wireless PCMCIA client drivers
diff --git a/drivers/net/wireless/zydas/Kconfig 
b/drivers/net/wireless/zydas/Kconfig
index 6140dfa04fed..a58c0f65e376 100644
--- a/drivers/net/wireless/zydas/Kconfig
+++ b/drivers/net/wireless/zydas/Kconfig
@@ -30,4 +30,6 @@ config USB_ZD1201
  To compile this driver as a module, choose M here: the
  module will be called zd1201.
 
+source "drivers/net/wireless/zydas/zd1211rw/Kconfig"
+
 endif # WLAN_VENDOR_ZYDAS
diff --git a/drivers/net/wireless/zydas/Makefile 
b/drivers/net/wireless/zydas/Makefile
index 37179ef890ea..679fbbf3a6cd 100644
--- a/drivers/net/wireless/zydas/Makefile
+++ b/drivers/net/wireless/zydas/Makefile
@@ -1 +1,3 @@
+obj-$(CONFIG_ZD1211RW) += zd1211rw/
+
 obj-$(CONFIG_USB_ZD1201)   += zd1201.o
diff --git a/drivers/net/wireless/zd1211rw/Kconfig 
b/drivers/net/wireless/zydas/zd1211rw/Kconfig
similarity index 100%
rename from drivers/net/wireless/zd1211rw/Kconfig
rename to drivers/net/wireless/zydas/zd1211rw/Kconfig
diff --git a/drivers/net/wireless/zd1211rw/Makefile 
b/drivers/net/wireless/zydas/zd1211rw/Makefile
similarity index 100%
rename from drivers/net/wireless/zd1211rw/Makefile
rename to 

[PATCH v2 02/27] airo: move under cisco vendor directory

[Kalle Valo]

Part of reorganising wireless drivers directory and Kconfig.

Signed-off-by: Kalle Valo 
---
 drivers/net/wireless/Kconfig   |   43 +
 drivers/net/wireless/Makefile  |4 +-
 drivers/net/wireless/cisco/Kconfig |   56 
 drivers/net/wireless/cisco/Makefile|2 +
 drivers/net/wireless/{ => cisco}/airo.c|0
 drivers/net/wireless/{ => cisco}/airo.h|0
 drivers/net/wireless/{ => cisco}/airo_cs.c |0
 7 files changed, 60 insertions(+), 45 deletions(-)
 create mode 100644 drivers/net/wireless/cisco/Kconfig
 create mode 100644 drivers/net/wireless/cisco/Makefile
 rename drivers/net/wireless/{ => cisco}/airo.c (100%)
 rename drivers/net/wireless/{ => cisco}/airo.h (100%)
 rename drivers/net/wireless/{ => cisco}/airo_cs.c (100%)

diff --git a/drivers/net/wireless/Kconfig b/drivers/net/wireless/Kconfig
index 7d8f47117c4d..ce5211ba1b29 100644
--- a/drivers/net/wireless/Kconfig
+++ b/drivers/net/wireless/Kconfig
@@ -18,6 +18,7 @@ menuconfig WLAN
 if WLAN
 
 source "drivers/net/wireless/admtek/Kconfig"
+source "drivers/net/wireless/cisco/Kconfig"
 
 config PCMCIA_RAYCS
tristate "Aviator/Raytheon 2.4GHz wireless support"
@@ -53,26 +54,6 @@ config LIBERTAS_THINFIRM_USB
---help---
  A driver for Marvell Libertas 8388 USB devices using thinfirm.
 
-config AIRO
-   tristate "Cisco/Aironet 34X/35X/4500/4800 ISA and PCI cards"
-   depends on CFG80211 && ISA_DMA_API && (PCI || BROKEN)
-   select WIRELESS_EXT
-   select CRYPTO
-   select WEXT_SPY
-   select WEXT_PRIV
-   ---help---
- This is the standard Linux driver to support Cisco/Aironet ISA and
- PCI 802.11 wireless cards.
- It supports the new 802.11b cards from Cisco (Cisco 34X, Cisco 35X
- - with or without encryption) as well as card before the Cisco
- acquisition (Aironet 4500, Aironet 4800, Aironet 4800B).
-
- This driver support both the standard Linux Wireless Extensions
- and Cisco proprietary API, so both the Linux Wireless Tools and the
- Cisco Linux utilities can be used to configure the card.
-
- The driver can be compiled as a module and will be named "airo".
-
 config ATMEL
   tristate "Atmel at76c50x chipset  802.11b support"
   depends on CFG80211 && (PCI || PCMCIA)
@@ -116,28 +97,6 @@ config AT76C50X_USB
   Enable support for USB Wireless devices using Atmel at76c503,
   at76c505 or at76c505a chips.
 
-config AIRO_CS
-   tristate "Cisco/Aironet 34X/35X/4500/4800 PCMCIA cards"
-   depends on CFG80211 && PCMCIA && (BROKEN || !M32R)
-   select WIRELESS_EXT
-   select WEXT_SPY
-   select WEXT_PRIV
-   select CRYPTO
-   select CRYPTO_AES
-   ---help---
- This is the standard Linux driver to support Cisco/Aironet PCMCIA
- 802.11 wireless cards.  This driver is the same as the Aironet
- driver part of the Linux Pcmcia package.
- It supports the new 802.11b cards from Cisco (Cisco 34X, Cisco 35X
- - with or without encryption) as well as card before the Cisco
- acquisition (Aironet 4500, Aironet 4800, Aironet 4800B). It also
- supports OEM of Cisco such as the DELL TrueMobile 4800 and Xircom
- 802.11b cards.
-
- This driver support both the standard Linux Wireless Extensions
- and Cisco proprietary API, so both the Linux Wireless Tools and the
- Cisco Linux utilities can be used to configure the card.
-
 config PCMCIA_WL3501
tristate "Planet WL3501 PCMCIA cards"
depends on CFG80211 && PCMCIA
diff --git a/drivers/net/wireless/Makefile b/drivers/net/wireless/Makefile
index be215f43ec1d..853294d84fa9 100644
--- a/drivers/net/wireless/Makefile
+++ b/drivers/net/wireless/Makefile
@@ -3,15 +3,13 @@
 #
 
 obj-$(CONFIG_WLAN_VENDOR_ADMTEK) += admtek/
+obj-$(CONFIG_WLAN_VENDOR_CISCO) += cisco/
 
 obj-$(CONFIG_IPW2100) += ipw2x00/
 obj-$(CONFIG_IPW2200) += ipw2x00/
 
 obj-$(CONFIG_HERMES)   += orinoco/
 
-obj-$(CONFIG_AIRO) += airo.o
-obj-$(CONFIG_AIRO_CS)  += airo_cs.o airo.o
-
 obj-$(CONFIG_ATMEL) += atmel.o
 obj-$(CONFIG_PCI_ATMEL) += atmel_pci.o 
 obj-$(CONFIG_PCMCIA_ATMEL)  += atmel_cs.o
diff --git a/drivers/net/wireless/cisco/Kconfig 
b/drivers/net/wireless/cisco/Kconfig
new file mode 100644
index ..b22567dff893
--- /dev/null
+++ b/drivers/net/wireless/cisco/Kconfig
@@ -0,0 +1,56 @@
+config WLAN_VENDOR_CISCO
+   bool "Cisco devices"
+   default y
+   ---help---
+ If you have a wireless card belonging to this class, say Y.
+
+ Note that the answer to this question doesn't directly affect the
+ kernel: saying N will just cause the configurator to skip all
+ the questions about  cards. If you say Y, you will be asked for
+ your specific card in the 

[PATCH v2 03/27] atmel: move under atmel vendor directory

[Kalle Valo]

Part of reorganising wireless drivers directory and Kconfig.

Signed-off-by: Kalle Valo 
---
 MAINTAINERS |2 +-
 drivers/net/wireless/Kconfig|   44 +
 drivers/net/wireless/Makefile   |7 +--
 drivers/net/wireless/atmel/Kconfig  |   57 +++
 drivers/net/wireless/atmel/Makefile |5 ++
 drivers/net/wireless/{ => atmel}/at76c50x-usb.c |0
 drivers/net/wireless/{ => atmel}/at76c50x-usb.h |0
 drivers/net/wireless/{ => atmel}/atmel.c|0
 drivers/net/wireless/{ => atmel}/atmel.h|0
 drivers/net/wireless/{ => atmel}/atmel_cs.c |0
 drivers/net/wireless/{ => atmel}/atmel_pci.c|0
 11 files changed, 65 insertions(+), 50 deletions(-)
 create mode 100644 drivers/net/wireless/atmel/Kconfig
 create mode 100644 drivers/net/wireless/atmel/Makefile
 rename drivers/net/wireless/{ => atmel}/at76c50x-usb.c (100%)
 rename drivers/net/wireless/{ => atmel}/at76c50x-usb.h (100%)
 rename drivers/net/wireless/{ => atmel}/atmel.c (100%)
 rename drivers/net/wireless/{ => atmel}/atmel.h (100%)
 rename drivers/net/wireless/{ => atmel}/atmel_cs.c (100%)
 rename drivers/net/wireless/{ => atmel}/atmel_pci.c (100%)

diff --git a/MAINTAINERS b/MAINTAINERS
index f1adb66094f1..2f3ea01c101c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1992,7 +1992,7 @@ L:linux-wirel...@vger.kernel.org
 W: http://www.thekelleys.org.uk/atmel
 W: http://atmelwlandriver.sourceforge.net/
 S: Maintained
-F: drivers/net/wireless/atmel*
+F: drivers/net/wireless/atmel/atmel*
 
 ATMEL MAXTOUCH DRIVER
 M: Nick Dyer 
diff --git a/drivers/net/wireless/Kconfig b/drivers/net/wireless/Kconfig
index ce5211ba1b29..275b6ed93f15 100644
--- a/drivers/net/wireless/Kconfig
+++ b/drivers/net/wireless/Kconfig
@@ -18,6 +18,7 @@ menuconfig WLAN
 if WLAN
 
 source "drivers/net/wireless/admtek/Kconfig"
+source "drivers/net/wireless/atmel/Kconfig"
 source "drivers/net/wireless/cisco/Kconfig"
 
 config PCMCIA_RAYCS
@@ -54,49 +55,6 @@ config LIBERTAS_THINFIRM_USB
---help---
  A driver for Marvell Libertas 8388 USB devices using thinfirm.
 
-config ATMEL
-  tristate "Atmel at76c50x chipset  802.11b support"
-  depends on CFG80211 && (PCI || PCMCIA)
-  select WIRELESS_EXT
-  select WEXT_PRIV
-  select FW_LOADER
-  select CRC32
-   ---help---
-A driver 802.11b wireless cards based on the Atmel fast-vnet
-chips. This driver supports standard Linux wireless extensions.
-
-Many  cards based on this chipset do not have flash memory
-and need their firmware loaded at start-up. If yours is
-one of these, you will need to provide a firmware image
-to be loaded into the card by the driver. The Atmel
-firmware package can be downloaded from
-
-
-config PCI_ATMEL
-  tristate "Atmel at76c506 PCI cards"
-  depends on ATMEL && PCI
-   ---help---
-Enable support for PCI and mini-PCI cards containing the
-Atmel at76c506 chip.
-
-config PCMCIA_ATMEL
-   tristate "Atmel at76c502/at76c504 PCMCIA cards"
-   depends on ATMEL && PCMCIA
-   select WIRELESS_EXT
-   select FW_LOADER
-   select CRC32
-   ---help---
- Enable support for PCMCIA cards containing the
- Atmel at76c502 and at76c504 chips.
-
-config AT76C50X_USB
-tristate "Atmel at76c503/at76c505/at76c505a USB cards"
-depends on MAC80211 && USB
-select FW_LOADER
----help---
-  Enable support for USB Wireless devices using Atmel at76c503,
-  at76c505 or at76c505a chips.
-
 config PCMCIA_WL3501
tristate "Planet WL3501 PCMCIA cards"
depends on CFG80211 && PCMCIA
diff --git a/drivers/net/wireless/Makefile b/drivers/net/wireless/Makefile
index 853294d84fa9..87eb6b2f3227 100644
--- a/drivers/net/wireless/Makefile
+++ b/drivers/net/wireless/Makefile
@@ -3,6 +3,7 @@
 #
 
 obj-$(CONFIG_WLAN_VENDOR_ADMTEK) += admtek/
+obj-$(CONFIG_WLAN_VENDOR_ATMEL) += atmel/
 obj-$(CONFIG_WLAN_VENDOR_CISCO) += cisco/
 
 obj-$(CONFIG_IPW2100) += ipw2x00/
@@ -10,12 +11,6 @@ obj-$(CONFIG_IPW2200) += ipw2x00/
 
 obj-$(CONFIG_HERMES)   += orinoco/
 
-obj-$(CONFIG_ATMEL) += atmel.o
-obj-$(CONFIG_PCI_ATMEL) += atmel_pci.o 
-obj-$(CONFIG_PCMCIA_ATMEL)  += atmel_cs.o
-
-obj-$(CONFIG_AT76C50X_USB)  += at76c50x-usb.o
-
 obj-$(CONFIG_PRISM54)  += prism54/
 
 obj-$(CONFIG_HOSTAP)   += hostap/
diff --git a/drivers/net/wireless/atmel/Kconfig 
b/drivers/net/wireless/atmel/Kconfig
new file mode 100644
index ..a43cfd163254
--- /dev/null
+++ b/drivers/net/wireless/atmel/Kconfig
@@ -0,0 +1,57 @@
+config WLAN_VENDOR_ATMEL
+   bool "Atmel devices"
+   default y
+   ---help---
+ If you have a 

[PATCH v2 00/27] wireless drivers vendor directories

[Kalle Valo]

Hi,

I started to reorganise drivers/net/wireless directory and follow what
drivers/net/ethernet has. The major change is that new vendor
directories are created and most of the drivers are now under those
vendor directories:

admtek/
ath/
atmel/
broadcom/
cisco/
intel/
intersil/
marvell/
mediatek/
ralink/
realtek/
rsi/
st/
ti/
zydas/

Only exception are these four drivers as they didn't have any sensible
vendor name to use:

mac80211_hwsim
ray_cs
wl3501_cs
rndis_wlan

These Kconfig options are renamed:

CONFIG_WL_MEDIATEK -> CONFIG_WLAN_VENDOR_MEDIATEK
CONFIG_WL_TI -> CONFIG_WLAN_VENDOR_TI
CONFIG_ATH_CARDS -> CONFIG_WLAN_VENDOR_ATH

With these patches, and manually disabling all vendors and drivers,
menuconfig will look like this:

--- Wireless LAN
  
[ ]   ADMtek devices
  
[ ]   Atheros/Qualcomm devices  
  
[ ]   Atmel devices 
  
[ ]   Broadcom devices  
  
[ ]   Cisco devices 
  
[ ]   Intel devices 
  
[ ]   Intersil devices  
  
[ ]   Marvell devices   
  
[ ]   Mediatek devices  
  
[ ]   Realtek devices   
  
[ ]   Redpine Signals Inc devices   
  
[ ]   STMicroelectronics devices
  
[ ]   Texas Instrument devices  
  
[ ]   ZyDAS devices 
  
< >   Aviator/Raytheon 2.4GHz wireless support  
  
< >   Planet WL3501 PCMCIA cards
  
< >   Simulated radio testing tool for mac80211 
  
< >   Wireless RNDIS USB support
  

There's also a git branch which I keep up-to-date:

https://git.kernel.org/cgit/linux/kernel/git/kvalo/wireless-drivers-next.git/log/?h=wd-reorg

Please review and send comments.

v2:

* move all drivers

Kalle Valo (27):
  adm80211: move under admtek vendor directory
  airo: move under cisco vendor directory
  atmel: move under atmel vendor directory
  b43: move under broadcom vendor directory
  b43legacy: move under broadcom vendor directory
  brcm80211: move under broadcom vendor directory
  cw1200: move under st vendor directory
  ipw2x00: move under intel vendor directory
  iwlegacy: move under intel directory
  iwlwifi: move under intel vendor directory
  libertas: move under marvell vendor directory
  libertas_tf: move under marvell vendor directory
  mwifiex: move under marvell vendor directory
  mwl8k: move under marvell vendor directory
  zd1201: move under zydas vendor directory
  zd1211rw: move under zydas vendor directory
  hostap: move under intersil vendor directory
  p54: move under intersil vendor directory
  orinoco: move under intersil vendor directory
  prism54: move under intersil vendor directory
  realtek: create separate Kconfig file
  rsi: add vendor Kconfig entry
  rt2x00: move under ralink vendor directory
  mediatek: unify Kconfig with other vendors
  ti: unify Kconfig with other vendors
  ath: unify Kconfig with other vendors
  mac80211_hwsim: move Kconfig entry for sorting alphabetically

 MAINTAINERS|   46 ++--
 drivers/net/wireless/Kconfig   |  238 +++-
 drivers/net/wireless/Makefile  |   65 ++
 drivers/net/wireless/admtek/Kconfig|   41 
 drivers/net/wireless/admtek/Makefile   |1 +
 drivers/net/wireless/{ => admtek}/adm8211.c|0
 drivers/net/wireless/{ => admtek}/adm8211.h|0
 drivers/net/wireless/ath/Kconfig   |   17 +-
 drivers/net/wireless/atmel/Kconfig |   57 +
 drivers/net/wireless/atmel/Makefile|5 +
 drivers/net/wireless/{ => atmel}/at76c50x-usb.c|0
 drivers/net/wireless/{ => atmel}/at76c50x-usb.h|0
 drivers/net/wireless/{ => atmel}/atmel.c   |0
 drivers/net/wireless/{ => atmel}/atmel.h   |0
 drivers/net/wireless/{ => atmel}/atmel_cs.c|0
 drivers/net/wireless/{ => atmel}/atmel_pci.c   |0
 drivers/net/wireless/broadcom/Kconfig  |   18 ++
 drivers/net/wireless/broadcom/Makefile |5 +
 drivers/net/wireless/{ => broadcom}/b43/Kconfig|0
 drivers/net/wireless/{ 

[PATCH v2 01/27] adm80211: move under admtek vendor directory

[Kalle Valo]

Part of reorganising wireless drivers directory and Kconfig.

Signed-off-by: Kalle Valo 
---
 MAINTAINERS |2 +-
 drivers/net/wireless/Kconfig|   29 ++-
 drivers/net/wireless/Makefile   |4 +--
 drivers/net/wireless/admtek/Kconfig |   41 +++
 drivers/net/wireless/admtek/Makefile|1 +
 drivers/net/wireless/{ => admtek}/adm8211.c |0
 drivers/net/wireless/{ => admtek}/adm8211.h |0
 7 files changed, 47 insertions(+), 30 deletions(-)
 create mode 100644 drivers/net/wireless/admtek/Kconfig
 create mode 100644 drivers/net/wireless/admtek/Makefile
 rename drivers/net/wireless/{ => admtek}/adm8211.c (100%)
 rename drivers/net/wireless/{ => admtek}/adm8211.h (100%)

diff --git a/MAINTAINERS b/MAINTAINERS
index 35fe7ae0492e..f1adb66094f1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -388,7 +388,7 @@ ADM8211 WIRELESS DRIVER
 L: linux-wirel...@vger.kernel.org
 W: http://wireless.kernel.org/
 S: Orphan
-F: drivers/net/wireless/adm8211.*
+F: drivers/net/wireless/admtek/adm8211.*
 
 ADP1653 FLASH CONTROLLER DRIVER
 M: Sakari Ailus 
diff --git a/drivers/net/wireless/Kconfig b/drivers/net/wireless/Kconfig
index f9f94229bf1b..7d8f47117c4d 100644
--- a/drivers/net/wireless/Kconfig
+++ b/drivers/net/wireless/Kconfig
@@ -17,6 +17,8 @@ menuconfig WLAN
 
 if WLAN
 
+source "drivers/net/wireless/admtek/Kconfig"
+
 config PCMCIA_RAYCS
tristate "Aviator/Raytheon 2.4GHz wireless support"
depends on PCMCIA
@@ -214,33 +216,6 @@ config USB_NET_RNDIS_WLAN
 
  If you choose to build a module, it'll be called rndis_wlan.
 
-config ADM8211
-   tristate "ADMtek ADM8211 support"
-   depends on MAC80211 && PCI
-   select CRC32
-   select EEPROM_93CX6
-   ---help---
- This driver is for ADM8211A, ADM8211B, and ADM8211C based cards.
- These are PCI/mini-PCI/Cardbus 802.11b chips found in cards such as:
-
- Xterasys Cardbus XN-2411b
- Blitz NetWave Point PC
- TrendNet 221pc
- Belkin F5D6001
- SMC 2635W
- Linksys WPC11 v1
- Fiberline FL-WL-200X
- 3com Office Connect (3CRSHPW796)
- Corega WLPCIB-11
- SMC 2602W V2 EU
- D-Link DWL-520 Revision C
-
- However, some of these cards have been replaced with other chips
- like the RTL8180L (Xterasys Cardbus XN-2411b, Belkin F5D6001) or
- the Ralink RT2400 (SMC2635W) without a model number change.
-
- Thanks to Infineon-ADMtek for their support of this driver.
-
 source "drivers/net/wireless/realtek/rtl818x/Kconfig"
 
 config MAC80211_HWSIM
diff --git a/drivers/net/wireless/Makefile b/drivers/net/wireless/Makefile
index 740fdd353c5d..be215f43ec1d 100644
--- a/drivers/net/wireless/Makefile
+++ b/drivers/net/wireless/Makefile
@@ -2,6 +2,8 @@
 # Makefile for the Linux Wireless network device drivers.
 #
 
+obj-$(CONFIG_WLAN_VENDOR_ADMTEK) += admtek/
+
 obj-$(CONFIG_IPW2100) += ipw2x00/
 obj-$(CONFIG_IPW2200) += ipw2x00/
 
@@ -35,8 +37,6 @@ obj-$(CONFIG_LIBERTAS)+= libertas/
 
 obj-$(CONFIG_LIBERTAS_THINFIRM)+= libertas_tf/
 
-obj-$(CONFIG_ADM8211)  += adm8211.o
-
 obj-$(CONFIG_MWL8K)+= mwl8k.o
 
 obj-$(CONFIG_IWLWIFI)  += iwlwifi/
diff --git a/drivers/net/wireless/admtek/Kconfig 
b/drivers/net/wireless/admtek/Kconfig
new file mode 100644
index ..d5a2dc728078
--- /dev/null
+++ b/drivers/net/wireless/admtek/Kconfig
@@ -0,0 +1,41 @@
+config WLAN_VENDOR_ADMTEK
+   bool "ADMtek devices"
+   default y
+   ---help---
+ If you have a wireless card belonging to this class, say Y.
+
+ Note that the answer to this question doesn't directly affect the
+ kernel: saying N will just cause the configurator to skip all
+ the questions about  cards. If you say Y, you will be asked for
+ your specific card in the following questions.
+
+if WLAN_VENDOR_ADMTEK
+
+config ADM8211
+   tristate "ADMtek ADM8211 support"
+   depends on MAC80211 && PCI
+   select CRC32
+   select EEPROM_93CX6
+   ---help---
+ This driver is for ADM8211A, ADM8211B, and ADM8211C based cards.
+ These are PCI/mini-PCI/Cardbus 802.11b chips found in cards such as:
+
+ Xterasys Cardbus XN-2411b
+ Blitz NetWave Point PC
+ TrendNet 221pc
+ Belkin F5D6001
+ SMC 2635W
+ Linksys WPC11 v1
+ Fiberline FL-WL-200X
+ 3com Office Connect (3CRSHPW796)
+ Corega WLPCIB-11
+ SMC 2602W V2 EU
+ D-Link DWL-520 Revision C
+
+ However, some of these cards have been replaced with other chips
+ like the RTL8180L (Xterasys Cardbus XN-2411b, Belkin F5D6001) or
+ the Ralink RT2400 (SMC2635W) without a model number change.
+
+ Thanks to Infineon-ADMtek for their support 

Re: [PATCH net-next 4/4] ravb: Add support for r8a7795 SoC

[Sergei Shtylyov]

Hello.

On 9/30/2015 9:15 AM, Simon Horman wrote:


From: Kazuya Mizuguchi 

This patch supports the r8a7795 SoC by:
- Using two interrupts
   + One for E-MAC
   + One for everything else
   + Both can be handled by the existing common interrupt handler, which
 affords a simpler update to support the new SoC. In future some
 consideration may be given to implementing multiple interrupt handlers
- Limiting the phy speed to 100Mbit/s for the new SoC;
   at this time it is not clear how this restriction may be lifted
   but I hope it will be possible as more information comes to light

Signed-off-by: Kazuya Mizuguchi 
[horms: reworked]
Signed-off-by: Simon Horman 

---
v0 [Kazuya Mizuguchi]

v1 [Simon Horman]
* Updated patch subject

v2 [Simon Horman]
* Reworked based on extensive feedback from
   Geert Uytterhoeven and Sergei Shtylyov.
* Broke binding update out into separate patch

v3 [Simon Horman]
* Check new return value of phy_set_max_speed()

v4
* No change
---
  drivers/net/ethernet/renesas/ravb.h  |  7 
  drivers/net/ethernet/renesas/ravb_main.c | 63 
  2 files changed, 62 insertions(+), 8 deletions(-)

diff --git a/drivers/net/ethernet/renesas/ravb.h 
b/drivers/net/ethernet/renesas/ravb.h
index a157ff6a..0623fff932e4 100644
--- a/drivers/net/ethernet/renesas/ravb.h
+++ b/drivers/net/ethernet/renesas/ravb.h
@@ -766,6 +766,11 @@ struct ravb_ptp {
struct ravb_ptp_perout perout[N_PER_OUT];
  };

+enum ravb_chip_id {
+   RCAR_GEN2,
+   RCAR_GEN3,
+};
+
  struct ravb_private {
struct net_device *ndev;
struct platform_device *pdev;
@@ -806,6 +811,8 @@ struct ravb_private {
int msg_enable;
int speed;
int duplex;
+   int emac_irq;
+   enum ravb_chip_id chip_id;

unsigned no_avb_link:1;
unsigned avb_link_active_low:1;
diff --git a/drivers/net/ethernet/renesas/ravb_main.c 
b/drivers/net/ethernet/renesas/ravb_main.c
index 4ca093d033f8..8cc5ec5ed19a 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c

[...]

@@ -1197,6 +1213,15 @@ static int ravb_open(struct net_device *ndev)
goto out_napi_off;
}

+   if (priv->chip_id == RCAR_GEN3) {
+   error = request_irq(priv->emac_irq, ravb_interrupt,
+   IRQF_SHARED, ndev->name, ndev);
+   if (error) {
+   netdev_err(ndev, "cannot request IRQ\n");
+   goto out_free_irq;
+   }
+   }
+
/* Device init */
error = ravb_dmac_init(ndev);
if (error)
@@ -1220,6 +1245,7 @@ out_ptp_stop:
ravb_ptp_stop(ndev);
  out_free_irq:
free_irq(ndev->irq, ndev);
+   free_irq(priv->emac_irq, ndev);


   Grr, this sloppy code causes WARNING in __free_irq() on gen2 SoCs. I'll 
deal with it...



  out_napi_off:
napi_disable(>napi[RAVB_NC]);
napi_disable(>napi[RAVB_BE]);

[...]

MBR, Sergei

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

[PATCH v2 18/27] p54: move under intersil vendor directory

[Kalle Valo]

Part of reorganising wireless drivers directory and Kconfig.

Signed-off-by: Kalle Valo 
---
 MAINTAINERS|2 +-
 drivers/net/wireless/Kconfig   |1 -
 drivers/net/wireless/Makefile  |2 --
 drivers/net/wireless/intersil/Kconfig  |1 +
 drivers/net/wireless/intersil/Makefile |1 +
 drivers/net/wireless/{ => intersil}/p54/Kconfig|0
 drivers/net/wireless/{ => intersil}/p54/Makefile   |0
 drivers/net/wireless/{ => intersil}/p54/eeprom.c   |0
 drivers/net/wireless/{ => intersil}/p54/eeprom.h   |0
 drivers/net/wireless/{ => intersil}/p54/fwio.c |0
 drivers/net/wireless/{ => intersil}/p54/led.c  |0
 drivers/net/wireless/{ => intersil}/p54/lmac.h |0
 drivers/net/wireless/{ => intersil}/p54/main.c |0
 drivers/net/wireless/{ => intersil}/p54/p54.h  |0
 drivers/net/wireless/{ => intersil}/p54/p54pci.c   |0
 drivers/net/wireless/{ => intersil}/p54/p54pci.h   |0
 drivers/net/wireless/{ => intersil}/p54/p54spi.c   |0
 drivers/net/wireless/{ => intersil}/p54/p54spi.h   |0
 .../wireless/{ => intersil}/p54/p54spi_eeprom.h|0
 drivers/net/wireless/{ => intersil}/p54/p54usb.c   |0
 drivers/net/wireless/{ => intersil}/p54/p54usb.h   |0
 drivers/net/wireless/{ => intersil}/p54/txrx.c |0
 22 files changed, 3 insertions(+), 4 deletions(-)
 rename drivers/net/wireless/{ => intersil}/p54/Kconfig (100%)
 rename drivers/net/wireless/{ => intersil}/p54/Makefile (100%)
 rename drivers/net/wireless/{ => intersil}/p54/eeprom.c (100%)
 rename drivers/net/wireless/{ => intersil}/p54/eeprom.h (100%)
 rename drivers/net/wireless/{ => intersil}/p54/fwio.c (100%)
 rename drivers/net/wireless/{ => intersil}/p54/led.c (100%)
 rename drivers/net/wireless/{ => intersil}/p54/lmac.h (100%)
 rename drivers/net/wireless/{ => intersil}/p54/main.c (100%)
 rename drivers/net/wireless/{ => intersil}/p54/p54.h (100%)
 rename drivers/net/wireless/{ => intersil}/p54/p54pci.c (100%)
 rename drivers/net/wireless/{ => intersil}/p54/p54pci.h (100%)
 rename drivers/net/wireless/{ => intersil}/p54/p54spi.c (100%)
 rename drivers/net/wireless/{ => intersil}/p54/p54spi.h (100%)
 rename drivers/net/wireless/{ => intersil}/p54/p54spi_eeprom.h (100%)
 rename drivers/net/wireless/{ => intersil}/p54/p54usb.c (100%)
 rename drivers/net/wireless/{ => intersil}/p54/p54usb.h (100%)
 rename drivers/net/wireless/{ => intersil}/p54/txrx.c (100%)

diff --git a/MAINTAINERS b/MAINTAINERS
index 63c601b04e68..818899a4c268 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7956,7 +7956,7 @@ M:Christian Lamparter 
 L: linux-wirel...@vger.kernel.org
 W: http://wireless.kernel.org/en/users/Drivers/p54
 S: Maintained
-F: drivers/net/wireless/p54/
+F: drivers/net/wireless/intersil/p54/
 
 PA SEMI ETHERNET DRIVER
 M: Olof Johansson 
diff --git a/drivers/net/wireless/Kconfig b/drivers/net/wireless/Kconfig
index da10b00d8af1..bea2fbb4a238 100644
--- a/drivers/net/wireless/Kconfig
+++ b/drivers/net/wireless/Kconfig
@@ -118,7 +118,6 @@ config MAC80211_HWSIM
 
 source "drivers/net/wireless/ath/Kconfig"
 source "drivers/net/wireless/orinoco/Kconfig"
-source "drivers/net/wireless/p54/Kconfig"
 source "drivers/net/wireless/rt2x00/Kconfig"
 source "drivers/net/wireless/mediatek/Kconfig"
 source "drivers/net/wireless/realtek/rtlwifi/Kconfig"
diff --git a/drivers/net/wireless/Makefile b/drivers/net/wireless/Makefile
index a60c5e55b55e..046963fc3958 100644
--- a/drivers/net/wireless/Makefile
+++ b/drivers/net/wireless/Makefile
@@ -28,8 +28,6 @@ obj-$(CONFIG_RT2X00)  += rt2x00/
 
 obj-$(CONFIG_WL_MEDIATEK)  += mediatek/
 
-obj-$(CONFIG_P54_COMMON)   += p54/
-
 obj-$(CONFIG_ATH_CARDS)+= ath/
 
 obj-$(CONFIG_MAC80211_HWSIM)   += mac80211_hwsim.o
diff --git a/drivers/net/wireless/intersil/Kconfig 
b/drivers/net/wireless/intersil/Kconfig
index ec80b9117fd2..4bc3688bfa93 100644
--- a/drivers/net/wireless/intersil/Kconfig
+++ b/drivers/net/wireless/intersil/Kconfig
@@ -12,5 +12,6 @@ config WLAN_VENDOR_INTERSIL
 if WLAN_VENDOR_INTERSIL
 
 source "drivers/net/wireless/intersil/hostap/Kconfig"
+source "drivers/net/wireless/intersil/p54/Kconfig"
 
 endif # WLAN_VENDOR_INTERSIL
diff --git a/drivers/net/wireless/intersil/Makefile 
b/drivers/net/wireless/intersil/Makefile
index 4890ef79f280..90a72830b1ae 100644
--- a/drivers/net/wireless/intersil/Makefile
+++ b/drivers/net/wireless/intersil/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_HOSTAP)   += hostap/
+obj-$(CONFIG_P54_COMMON)   += p54/
diff --git a/drivers/net/wireless/p54/Kconfig 
b/drivers/net/wireless/intersil/p54/Kconfig
similarity index 100%
rename from drivers/net/wireless/p54/Kconfig
rename to drivers/net/wireless/intersil/p54/Kconfig
diff --git a/drivers/net/wireless/p54/Makefile 

Re: Hardware capabilities and bonding offload

[Andrew Lunn]

On Wed, Nov 18, 2015 at 03:29:23PM +0100, Jiri Pirko wrote:
> Wed, Nov 18, 2015 at 03:05:12PM CET, and...@lunn.ch wrote:
> >> To be honest though this is more of an argument in theory versus
> >> some existing management agent I know of today. If you need to do
> >> bonding type X in your network and the particular switch doesn't support
> >> it I'm not even sure what the mgmt layer is going to do. Maybe just
> >> put the switch offline for that network segment.
> >> 
> >> If you leave the sw bit out in the first iteration I'm OK with that
> >> we can easily add it when we have software that needs it.
> >
> >Taking a step back...
> >
> >Have we defined a consistent way for signalling:
> >
> >1) Failed to offload to the hardware, because the hardware cannot do
> >   what you requested.
> >2) Do this in software, rather than trying and failing to offload to
> >   hardware.
> >
> >At least in DSA, we return EOPNOTSUP for 1).
> 
> Well for example in case of bonding there is quite impossible to do
> things in software in case the hardware datapath simply cannot pass
> packets to kernel. Driver should know and should forbid such
> non-functional setup.

I said, "taking a step back..." meaning, in the general case, do we
have a well defined way to do this. What we don't want is X different
ways for Y difference API calls to say, if offload of this to hardware
fails, do it in software, if that is possible.

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

[PATCH v2 21/27] realtek: create separate Kconfig file

[Kalle Valo]

Add new a Kconfig file and a vendor config for realtek. Also update MAINTAINERS
which we missed to do when earlier moving rtlwifi.

Signed-off-by: Kalle Valo 
---
 MAINTAINERS  |8 
 drivers/net/wireless/Kconfig |5 +
 drivers/net/wireless/Makefile|3 +--
 drivers/net/wireless/realtek/Kconfig |   18 ++
 4 files changed, 24 insertions(+), 10 deletions(-)
 create mode 100644 drivers/net/wireless/realtek/Kconfig

diff --git a/MAINTAINERS b/MAINTAINERS
index 2c41981e4fdd..a9f7f968f64e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9035,7 +9035,7 @@ L:linux-wirel...@vger.kernel.org
 W: http://wireless.kernel.org/
 T: git 
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git
 S: Orphan
-F: drivers/net/wireless/rtl818x/rtl8180/
+F: drivers/net/wireless/realtek/rtl818x/rtl8180/
 
 RTL8187 WIRELESS DRIVER
 M: Herton Ronaldo Krzesinski 
@@ -9045,7 +9045,7 @@ L:linux-wirel...@vger.kernel.org
 W: http://wireless.kernel.org/
 T: git 
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git
 S: Maintained
-F: drivers/net/wireless/rtl818x/rtl8187/
+F: drivers/net/wireless/realtek/rtl818x/rtl8187/
 
 RTL8192CE WIRELESS DRIVER
 M: Larry Finger 
@@ -9054,8 +9054,8 @@ L:linux-wirel...@vger.kernel.org
 W: http://wireless.kernel.org/
 T: git 
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git
 S: Maintained
-F: drivers/net/wireless/rtlwifi/
-F: drivers/net/wireless/rtlwifi/rtl8192ce/
+F: drivers/net/wireless/realtek/rtlwifi/
+F: drivers/net/wireless/realtek/rtlwifi/rtl8192ce/
 
 RTL8XXXU WIRELESS DRIVER (rtl8xxxu)
 M: Jes Sorensen 
diff --git a/drivers/net/wireless/Kconfig b/drivers/net/wireless/Kconfig
index c92671f8b1c6..28af8b10a66e 100644
--- a/drivers/net/wireless/Kconfig
+++ b/drivers/net/wireless/Kconfig
@@ -24,6 +24,7 @@ source "drivers/net/wireless/cisco/Kconfig"
 source "drivers/net/wireless/intel/Kconfig"
 source "drivers/net/wireless/intersil/Kconfig"
 source "drivers/net/wireless/marvell/Kconfig"
+source "drivers/net/wireless/realtek/Kconfig"
 source "drivers/net/wireless/st/Kconfig"
 source "drivers/net/wireless/zydas/Kconfig"
 
@@ -81,8 +82,6 @@ config USB_NET_RNDIS_WLAN
 
  If you choose to build a module, it'll be called rndis_wlan.
 
-source "drivers/net/wireless/realtek/rtl818x/Kconfig"
-
 config MAC80211_HWSIM
tristate "Simulated radio testing tool for mac80211"
depends on MAC80211
@@ -99,8 +98,6 @@ config MAC80211_HWSIM
 source "drivers/net/wireless/ath/Kconfig"
 source "drivers/net/wireless/rt2x00/Kconfig"
 source "drivers/net/wireless/mediatek/Kconfig"
-source "drivers/net/wireless/realtek/rtlwifi/Kconfig"
-source "drivers/net/wireless/realtek/rtl8xxxu/Kconfig"
 source "drivers/net/wireless/ti/Kconfig"
 source "drivers/net/wireless/rsi/Kconfig"
 
diff --git a/drivers/net/wireless/Makefile b/drivers/net/wireless/Makefile
index 679a1a0a048d..12f6c59668a5 100644
--- a/drivers/net/wireless/Makefile
+++ b/drivers/net/wireless/Makefile
@@ -9,11 +9,10 @@ obj-$(CONFIG_WLAN_VENDOR_CISCO) += cisco/
 obj-$(CONFIG_WLAN_VENDOR_INTEL) += intel/
 obj-$(CONFIG_WLAN_VENDOR_INTERSIL) += intersil/
 obj-$(CONFIG_WLAN_VENDOR_MARVELL) += marvell/
+obj-$(CONFIG_WLAN_VENDOR_REALTEK) += realtek/
 obj-$(CONFIG_WLAN_VENDOR_ST) += st/
 obj-$(CONFIG_WLAN_VENDOR_ZYDAS) += zydas/
 
-obj-$(CONFIG_WLAN) += realtek/
-
 # 16-bit wireless PCMCIA client drivers
 obj-$(CONFIG_PCMCIA_RAYCS) += ray_cs.o
 obj-$(CONFIG_PCMCIA_WL3501)+= wl3501_cs.o
diff --git a/drivers/net/wireless/realtek/Kconfig 
b/drivers/net/wireless/realtek/Kconfig
new file mode 100644
index ..8a8ba2003964
--- /dev/null
+++ b/drivers/net/wireless/realtek/Kconfig
@@ -0,0 +1,18 @@
+config WLAN_VENDOR_REALTEK
+   bool "Realtek devices"
+   default y
+   ---help---
+ If you have a wireless card belonging to this class, say Y.
+
+ Note that the answer to this question doesn't directly affect the
+ kernel: saying N will just cause the configurator to skip all
+ the questions about  cards. If you say Y, you will be asked for
+ your specific card in the following questions.
+
+if WLAN_VENDOR_REALTEK
+
+source "drivers/net/wireless/realtek/rtl818x/Kconfig"
+source "drivers/net/wireless/realtek/rtlwifi/Kconfig"
+source "drivers/net/wireless/realtek/rtl8xxxu/Kconfig"
+
+endif # WLAN_VENDOR_REALTEK
-- 
1.7.9.5

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

Re: Hardware capabilities and bonding offload

[Jiri Pirko]

Wed, Nov 18, 2015 at 03:05:12PM CET, and...@lunn.ch wrote:
>> To be honest though this is more of an argument in theory versus
>> some existing management agent I know of today. If you need to do
>> bonding type X in your network and the particular switch doesn't support
>> it I'm not even sure what the mgmt layer is going to do. Maybe just
>> put the switch offline for that network segment.
>> 
>> If you leave the sw bit out in the first iteration I'm OK with that
>> we can easily add it when we have software that needs it.
>
>Taking a step back...
>
>Have we defined a consistent way for signalling:
>
>1) Failed to offload to the hardware, because the hardware cannot do
>   what you requested.
>2) Do this in software, rather than trying and failing to offload to
>   hardware.
>
>At least in DSA, we return EOPNOTSUP for 1).

Well for example in case of bonding there is quite impossible to do
things in software in case the hardware datapath simply cannot pass
packets to kernel. Driver should know and should forbid such
non-functional setup.


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

[PATCH v2 23/27] rt2x00: move under ralink vendor directory

[Kalle Valo]

Part of reorganising wireless drivers directory and Kconfig.

Signed-off-by: Kalle Valo 
---
 MAINTAINERS|2 +-
 drivers/net/wireless/Kconfig   |2 +-
 drivers/net/wireless/Makefile  |3 +--
 drivers/net/wireless/ralink/Kconfig|   16 
 drivers/net/wireless/ralink/Makefile   |1 +
 drivers/net/wireless/{ => ralink}/rt2x00/Kconfig   |0
 drivers/net/wireless/{ => ralink}/rt2x00/Makefile  |0
 .../net/wireless/{ => ralink}/rt2x00/rt2400pci.c   |0
 .../net/wireless/{ => ralink}/rt2x00/rt2400pci.h   |0
 .../net/wireless/{ => ralink}/rt2x00/rt2500pci.c   |0
 .../net/wireless/{ => ralink}/rt2x00/rt2500pci.h   |0
 .../net/wireless/{ => ralink}/rt2x00/rt2500usb.c   |0
 .../net/wireless/{ => ralink}/rt2x00/rt2500usb.h   |0
 drivers/net/wireless/{ => ralink}/rt2x00/rt2800.h  |0
 .../net/wireless/{ => ralink}/rt2x00/rt2800lib.c   |0
 .../net/wireless/{ => ralink}/rt2x00/rt2800lib.h   |0
 .../net/wireless/{ => ralink}/rt2x00/rt2800mmio.c  |0
 .../net/wireless/{ => ralink}/rt2x00/rt2800mmio.h  |0
 .../net/wireless/{ => ralink}/rt2x00/rt2800pci.c   |0
 .../net/wireless/{ => ralink}/rt2x00/rt2800pci.h   |0
 .../net/wireless/{ => ralink}/rt2x00/rt2800soc.c   |0
 .../net/wireless/{ => ralink}/rt2x00/rt2800usb.c   |0
 .../net/wireless/{ => ralink}/rt2x00/rt2800usb.h   |0
 drivers/net/wireless/{ => ralink}/rt2x00/rt2x00.h  |0
 .../wireless/{ => ralink}/rt2x00/rt2x00config.c|0
 .../wireless/{ => ralink}/rt2x00/rt2x00crypto.c|0
 .../net/wireless/{ => ralink}/rt2x00/rt2x00debug.c |0
 .../net/wireless/{ => ralink}/rt2x00/rt2x00debug.h |0
 .../net/wireless/{ => ralink}/rt2x00/rt2x00dev.c   |0
 .../net/wireless/{ => ralink}/rt2x00/rt2x00dump.h  |0
 .../wireless/{ => ralink}/rt2x00/rt2x00firmware.c  |0
 .../net/wireless/{ => ralink}/rt2x00/rt2x00leds.c  |0
 .../net/wireless/{ => ralink}/rt2x00/rt2x00leds.h  |0
 .../net/wireless/{ => ralink}/rt2x00/rt2x00lib.h   |0
 .../net/wireless/{ => ralink}/rt2x00/rt2x00link.c  |0
 .../net/wireless/{ => ralink}/rt2x00/rt2x00mac.c   |0
 .../net/wireless/{ => ralink}/rt2x00/rt2x00mmio.c  |0
 .../net/wireless/{ => ralink}/rt2x00/rt2x00mmio.h  |0
 .../net/wireless/{ => ralink}/rt2x00/rt2x00pci.c   |0
 .../net/wireless/{ => ralink}/rt2x00/rt2x00pci.h   |0
 .../net/wireless/{ => ralink}/rt2x00/rt2x00queue.c |0
 .../net/wireless/{ => ralink}/rt2x00/rt2x00queue.h |0
 .../net/wireless/{ => ralink}/rt2x00/rt2x00reg.h   |0
 .../net/wireless/{ => ralink}/rt2x00/rt2x00soc.c   |0
 .../net/wireless/{ => ralink}/rt2x00/rt2x00soc.h   |0
 .../net/wireless/{ => ralink}/rt2x00/rt2x00usb.c   |0
 .../net/wireless/{ => ralink}/rt2x00/rt2x00usb.h   |0
 drivers/net/wireless/{ => ralink}/rt2x00/rt61pci.c |0
 drivers/net/wireless/{ => ralink}/rt2x00/rt61pci.h |0
 drivers/net/wireless/{ => ralink}/rt2x00/rt73usb.c |0
 drivers/net/wireless/{ => ralink}/rt2x00/rt73usb.h |0
 51 files changed, 20 insertions(+), 4 deletions(-)
 create mode 100644 drivers/net/wireless/ralink/Kconfig
 create mode 100644 drivers/net/wireless/ralink/Makefile
 rename drivers/net/wireless/{ => ralink}/rt2x00/Kconfig (100%)
 rename drivers/net/wireless/{ => ralink}/rt2x00/Makefile (100%)
 rename drivers/net/wireless/{ => ralink}/rt2x00/rt2400pci.c (100%)
 rename drivers/net/wireless/{ => ralink}/rt2x00/rt2400pci.h (100%)
 rename drivers/net/wireless/{ => ralink}/rt2x00/rt2500pci.c (100%)
 rename drivers/net/wireless/{ => ralink}/rt2x00/rt2500pci.h (100%)
 rename drivers/net/wireless/{ => ralink}/rt2x00/rt2500usb.c (100%)
 rename drivers/net/wireless/{ => ralink}/rt2x00/rt2500usb.h (100%)
 rename drivers/net/wireless/{ => ralink}/rt2x00/rt2800.h (100%)
 rename drivers/net/wireless/{ => ralink}/rt2x00/rt2800lib.c (100%)
 rename drivers/net/wireless/{ => ralink}/rt2x00/rt2800lib.h (100%)
 rename drivers/net/wireless/{ => ralink}/rt2x00/rt2800mmio.c (100%)
 rename drivers/net/wireless/{ => ralink}/rt2x00/rt2800mmio.h (100%)
 rename drivers/net/wireless/{ => ralink}/rt2x00/rt2800pci.c (100%)
 rename drivers/net/wireless/{ => ralink}/rt2x00/rt2800pci.h (100%)
 rename drivers/net/wireless/{ => ralink}/rt2x00/rt2800soc.c (100%)
 rename drivers/net/wireless/{ => ralink}/rt2x00/rt2800usb.c (100%)
 rename drivers/net/wireless/{ => ralink}/rt2x00/rt2800usb.h (100%)
 rename drivers/net/wireless/{ => ralink}/rt2x00/rt2x00.h (100%)
 rename drivers/net/wireless/{ => ralink}/rt2x00/rt2x00config.c (100%)
 rename drivers/net/wireless/{ => ralink}/rt2x00/rt2x00crypto.c (100%)
 rename drivers/net/wireless/{ => ralink}/rt2x00/rt2x00debug.c (100%)
 rename drivers/net/wireless/{ => ralink}/rt2x00/rt2x00debug.h (100%)
 rename drivers/net/wireless/{ => ralink}/rt2x00/rt2x00dev.c (100%)
 rename drivers/net/wireless/{ => 

[PATCH v2 20/27] prism54: move under intersil vendor directory

[Kalle Valo]

Part of reorganising wireless drivers directory and Kconfig.

Signed-off-by: Kalle Valo 
---
 MAINTAINERS|2 +-
 drivers/net/wireless/Kconfig   |   20 
 drivers/net/wireless/Makefile  |2 --
 drivers/net/wireless/intersil/Kconfig  |   20 
 drivers/net/wireless/intersil/Makefile |1 +
 .../net/wireless/{ => intersil}/prism54/Makefile   |0
 .../net/wireless/{ => intersil}/prism54/isl_38xx.c |0
 .../net/wireless/{ => intersil}/prism54/isl_38xx.h |0
 .../wireless/{ => intersil}/prism54/isl_ioctl.c|0
 .../wireless/{ => intersil}/prism54/isl_ioctl.h|0
 .../net/wireless/{ => intersil}/prism54/isl_oid.h  |0
 .../wireless/{ => intersil}/prism54/islpci_dev.c   |0
 .../wireless/{ => intersil}/prism54/islpci_dev.h   |0
 .../wireless/{ => intersil}/prism54/islpci_eth.c   |0
 .../wireless/{ => intersil}/prism54/islpci_eth.h   |0
 .../{ => intersil}/prism54/islpci_hotplug.c|0
 .../wireless/{ => intersil}/prism54/islpci_mgt.c   |0
 .../wireless/{ => intersil}/prism54/islpci_mgt.h   |0
 .../net/wireless/{ => intersil}/prism54/oid_mgt.c  |0
 .../net/wireless/{ => intersil}/prism54/oid_mgt.h  |0
 .../wireless/{ => intersil}/prism54/prismcompat.h  |0
 21 files changed, 22 insertions(+), 23 deletions(-)
 rename drivers/net/wireless/{ => intersil}/prism54/Makefile (100%)
 rename drivers/net/wireless/{ => intersil}/prism54/isl_38xx.c (100%)
 rename drivers/net/wireless/{ => intersil}/prism54/isl_38xx.h (100%)
 rename drivers/net/wireless/{ => intersil}/prism54/isl_ioctl.c (100%)
 rename drivers/net/wireless/{ => intersil}/prism54/isl_ioctl.h (100%)
 rename drivers/net/wireless/{ => intersil}/prism54/isl_oid.h (100%)
 rename drivers/net/wireless/{ => intersil}/prism54/islpci_dev.c (100%)
 rename drivers/net/wireless/{ => intersil}/prism54/islpci_dev.h (100%)
 rename drivers/net/wireless/{ => intersil}/prism54/islpci_eth.c (100%)
 rename drivers/net/wireless/{ => intersil}/prism54/islpci_eth.h (100%)
 rename drivers/net/wireless/{ => intersil}/prism54/islpci_hotplug.c (100%)
 rename drivers/net/wireless/{ => intersil}/prism54/islpci_mgt.c (100%)
 rename drivers/net/wireless/{ => intersil}/prism54/islpci_mgt.h (100%)
 rename drivers/net/wireless/{ => intersil}/prism54/oid_mgt.c (100%)
 rename drivers/net/wireless/{ => intersil}/prism54/oid_mgt.h (100%)
 rename drivers/net/wireless/{ => intersil}/prism54/prismcompat.h (100%)

diff --git a/MAINTAINERS b/MAINTAINERS
index 53c15af0d967..2c41981e4fdd 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8498,7 +8498,7 @@ M:"Luis R. Rodriguez" 
 L: linux-wirel...@vger.kernel.org
 W: http://wireless.kernel.org/en/users/Drivers/p54
 S: Obsolete
-F: drivers/net/wireless/prism54/
+F: drivers/net/wireless/intersil/prism54/
 
 PS3 NETWORK SUPPORT
 M: Geoff Levand 
diff --git a/drivers/net/wireless/Kconfig b/drivers/net/wireless/Kconfig
index cc1f168603dc..c92671f8b1c6 100644
--- a/drivers/net/wireless/Kconfig
+++ b/drivers/net/wireless/Kconfig
@@ -52,26 +52,6 @@ config PCMCIA_WL3501
  It has basic support for Linux wireless extensions and initial
  micro support for ethtool.
 
-config PRISM54
-   tristate 'Intersil Prism GT/Duette/Indigo PCI/Cardbus (DEPRECATED)'
-   depends on PCI
-   select WIRELESS_EXT
-   select WEXT_SPY
-   select WEXT_PRIV
-   select FW_LOADER
-   ---help---
- This enables support for FullMAC PCI/Cardbus prism54 devices. This
- driver is now deprecated in favor for the SoftMAC driver, p54pci.
- p54pci supports FullMAC PCI/Cardbus devices as well.
-
- For more information refer to the p54 wiki:
-
- http://wireless.kernel.org/en/users/Drivers/p54
-
- Note: You need a motherboard with DMA support to use any of these 
cards
-
- When built as module you get the module prism54
-
 config USB_NET_RNDIS_WLAN
tristate "Wireless RNDIS USB support"
depends on USB
diff --git a/drivers/net/wireless/Makefile b/drivers/net/wireless/Makefile
index dd6d17cc4b7e..679a1a0a048d 100644
--- a/drivers/net/wireless/Makefile
+++ b/drivers/net/wireless/Makefile
@@ -12,8 +12,6 @@ obj-$(CONFIG_WLAN_VENDOR_MARVELL) += marvell/
 obj-$(CONFIG_WLAN_VENDOR_ST) += st/
 obj-$(CONFIG_WLAN_VENDOR_ZYDAS) += zydas/
 
-obj-$(CONFIG_PRISM54)  += prism54/
-
 obj-$(CONFIG_WLAN) += realtek/
 
 # 16-bit wireless PCMCIA client drivers
diff --git a/drivers/net/wireless/intersil/Kconfig 
b/drivers/net/wireless/intersil/Kconfig
index 2b056b6daef8..9da136049955 100644
--- a/drivers/net/wireless/intersil/Kconfig
+++ b/drivers/net/wireless/intersil/Kconfig
@@ -15,4 +15,24 @@ source "drivers/net/wireless/intersil/hostap/Kconfig"
 source