* Re: stmmac driver...
From: Alexandre Torgue @ 2016-12-08 13:55 UTC (permalink / raw)
To: David Miller, peppe.cavallaro; +Cc: netdev
In-Reply-To: <20161207.130654.1484281922991494182.davem@davemloft.net>
Hi David,
On 12/07/2016 07:06 PM, David Miller wrote:
>
> Giuseppe and Alexandre,
>
> There are a lot of patches and discussions happening around the stammc
> driver lately and both of you are listed as the maintainers.
>
> I really need prompt and conclusive reviews of these patch submissions
> from you, and participation in all discussions about the driver.
>
> Otherwise I have only three things I can do: 1) let the patches rot in
> patchwork for days 2) trust that the patches are sane and fit your
> desires and goals and just apply them or 3) reject them since they
> aren't being reviewed properly.
Sorry for the delay. I reviewed Niklas series this morning. I'm testing
"net: ethernet: stmmac: remove private tx queue lock".
Maybe I forget some series. Do you have others in mind ?
Regards
Alex
>
> Thanks in advance.
>
^ permalink raw reply
* Re: [PATCH] net: handle no dst on skb in icmp6_send
From: Hannes Frederic Sowa @ 2016-12-08 14:04 UTC (permalink / raw)
To: David Miller, dsa; +Cc: netdev, andreyknvl
In-Reply-To: <20161128.161344.1778661062306703117.davem@davemloft.net>
Hello David,
On Mon, Nov 28, 2016, at 22:13, David Miller wrote:
> From: David Ahern <dsa@cumulusnetworks.com>
> Date: Sun, 27 Nov 2016 18:52:53 -0800
>
> > Andrey reported the following while fuzzing the kernel with syzkaller:
> ...
> > icmp6_send / icmpv6_send is invoked for both rx and tx paths. In both
> > cases the dst->dev should be preferred for determining the L3 domain
> > if the dst has been set on the skb. Fallback to the skb->dev if it has
> > not. This covers the case reported here where icmp6_send is invoked on
> > Rx before the route lookup.
> >
> > Fixes: 5d41ce29e ("net: icmp6_send should use dst dev to determine L3 domain")
> > Reported-by: Andrey Konovalov <andreyknvl@google.com>
> > Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
>
> Applied, thanks David.
could you queue this patch up for stable. You can remotely kill machines
with this bug.
Thanks,
Hannes
^ permalink raw reply
* Re: [PATCH 2/2] net: ethernet: stmmac: remove private tx queue lock
From: Pavel Machek @ 2016-12-08 14:08 UTC (permalink / raw)
To: David Miller
Cc: LinoSanfilippo, bh74.an, ks.giri, vipul.pandya, peppe.cavallaro,
alexandre.torgue, linux-kernel, netdev
In-Reply-To: <20161207.184111.1365236213357532881.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1160 bytes --]
On Wed 2016-12-07 18:41:11, David Miller wrote:
> From: Pavel Machek <pavel@ucw.cz>
> Date: Wed, 7 Dec 2016 22:37:57 +0100
>
> > diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> > index 982c952..7415bc2 100644
> > --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> > +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> > @@ -1308,7 +1308,7 @@ static void stmmac_tx_clean(struct stmmac_priv *priv)
> > unsigned int bytes_compl = 0, pkts_compl = 0;
> > unsigned int entry = priv->dirty_tx;
> >
> > - spin_lock(&priv->tx_lock);
> > + netif_tx_lock_bh(priv->dev);
> >
> > priv->xstats.tx_clean++;
> >
>
> stmmac_tx_clean() runs from either the timer or the NAPI poll handler,
> both execute from software interrupts, therefore _bh() should be
> unnecessary.
I've tried the test again with netif_tx_lock() (not _bh()) and it
survived for more then four hours. Strange...
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH] net: add one ethtool option to set relax ordering mode
From: Andrew Lunn @ 2016-12-08 14:11 UTC (permalink / raw)
To: Mao Wenan; +Cc: netdev, jeffrey.t.kirsher
In-Reply-To: <1481179898-10668-1-git-send-email-maowenan@huawei.com>
On Thu, Dec 08, 2016 at 02:51:37PM +0800, Mao Wenan wrote:
> This patch provides one way to set/unset IXGBE NIC TX and RX
> relax ordering mode, which can be set by ethtool.
> Relax ordering is one mode of 82599 NIC, to enable this mode
> can enhance the performance for some cpu architecure.
> example:
> ethtool -s enp1s0f0 relaxorder off
> ethtool -s enp1s0f0 relaxorder on
Since this is a simple on/off, could it not be done with a feature?
ethtool --feature?
Andrew
^ permalink raw reply
* Re: [PATCH 08/10] vsock/virtio: mark an internal function static
From: Michael S. Tsirkin @ 2016-12-08 14:25 UTC (permalink / raw)
To: Jason Wang
Cc: kvm, netdev, linux-kernel, virtualization, Stefan Hajnoczi,
David S. Miller
In-Reply-To: <487d3d4a-7a53-cb45-2cfd-5eb68d9b73f0@redhat.com>
On Wed, Dec 07, 2016 at 12:21:22PM +0800, Jason Wang wrote:
>
>
> On 2016年12月06日 23:41, Michael S. Tsirkin wrote:
> > virtio_transport_alloc_pkt is only used locally, make it static.
> >
> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > ---
> > net/vmw_vsock/virtio_transport_common.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c
> > index a53b3a1..6120384 100644
> > --- a/net/vmw_vsock/virtio_transport_common.c
> > +++ b/net/vmw_vsock/virtio_transport_common.c
> > @@ -32,7 +32,7 @@ static const struct virtio_transport *virtio_transport_get_ops(void)
> > return container_of(t, struct virtio_transport, transport);
> > }
> > -struct virtio_vsock_pkt *
> > +static struct virtio_vsock_pkt *
> > virtio_transport_alloc_pkt(struct virtio_vsock_pkt_info *info,
> > size_t len,
> > u32 src_cid,
>
> Git grep shows it was used by tracing.
True but trace_virtio_transport_alloc_pkt is also local to
virtio_transport_common.c
--
MST
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* RE: [RFC PATCH net-next v3 1/2] macb: Add 1588 support in Cadence GEM.
From: Andrei.Pistirica @ 2016-12-08 14:41 UTC (permalink / raw)
To: richardcochran
Cc: netdev, linux-kernel, linux-arm-kernel, davem, nicolas.ferre,
harinikatakamlinux, harini.katakam, punnaia, michals, anirudh,
boris.brezillon, alexandre.belloni, tbultel, rafalo
In-Reply-To: <20161207210416.GA27622@netboy>
> -----Original Message-----
> From: Richard Cochran [mailto:richardcochran@gmail.com]
> Sent: Wednesday, December 07, 2016 11:04 PM
> To: Andrei Pistirica - M16132
> Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-
> kernel@lists.infradead.org; davem@davemloft.net;
> nicolas.ferre@atmel.com; harinikatakamlinux@gmail.com;
> harini.katakam@xilinx.com; punnaia@xilinx.com; michals@xilinx.com;
> anirudh@xilinx.com; boris.brezillon@free-electrons.com;
> alexandre.belloni@free-electrons.com; tbultel@pixelsurmer.com;
> rafalo@cadence.com
> Subject: Re: [RFC PATCH net-next v3 1/2] macb: Add 1588 support in
> Cadence GEM.
>
> On Wed, Dec 07, 2016 at 08:39:09PM +0100, Richard Cochran wrote:
> > > +static s32 gem_ptp_max_adj(unsigned int f_nom) {
> > > + u64 adj;
> > > +
> > > + /* The 48 bits of seconds for the GEM overflows every:
> > > + * 2^48/(365.25 * 24 * 60 *60) =~ 8 925 512 years (~= 9 mil years),
> > > + * thus the maximum adjust frequency must not overflow CNS
> register:
> > > + *
> > > + * addend = 10^9/nominal_freq
> > > + * adj_max = +/- addend*ppb_max/10^9
> > > + * max_ppb = (2^8-1)*nominal_freq-10^9
> > > + */
> > > + adj = f_nom;
> > > + adj *= 0xffff;
> > > + adj -= 1000000000ULL;
> >
> > What is this computation, and how does it relate to the comment?
I considered the following simple equation: increment value at nominal frequency (which is 10^9/nominal frequency nsecs) + the maximum drift value (nsecs) <= maximum increment value at nominal frequency (which is 8bit:0xffff).
If maximum drift is written as function of nominal frequency and maximum ppb, then the equation above yields that the maximum ppb is: (2^8 - 1) *nominal_frequency - 10^9. The equation is also simplified by the fact that the drift is written as ppm + 16bit_fractions and the increment value is written as nsec + 16bit_fractions.
Rafal said that this value is hardcoded: 0x64E6, while Harini said: 250000000.
I need to dig into this...
>
> I am not sure what you meant, but it sounds like you are on the wrong track.
> Let me explain...
Thanks.
>
> The max_adj has nothing at all to do with the width of the time register.
> Rather, it should reflect the maximum possible change in the tuning word.
>
> For example, with a nominal 8 ns period, the tuning word is 0x80000.
> Looking at running the clock more slowly, the slowest possible word is
> 0x00001, meaning a difference of 0x7FFFF. This implies an adjustment of
> 0x7FFFF/0x80000 or 999998092 ppb. Running more quickly, we can already
> have 0x100000, twice as fast, or just under 2 billion ppb.
>
> You should consider the extreme cases to determine the most limited
> (smallest) max_adj value:
>
> Case 1 - high frequency
> ~~~~~~~~~~~~~~~~~~~~~~~
>
> With a nominal 1 ns period, we have the nominal tuning word 0x10000.
> The smallest is 0x1 for a difference of 0xFFFF. This corresponds to an
> adjustment of 0xFFFF/0x10000 = .9999847412109375 or 999984741 ppb.
>
> Case 2 - low frequency
> ~~~~~~~~~~~~~~~~~~~~~~
>
> With a nominal 255 ns period, the nominal word is 0xFF0000, the largest
> 0xFFFFFF, and the difference is 0xFFFF. This corresponds to and adjustment
> of 0xFFFF/0xFF0000 = .0039215087890625 or 3921508 ppb.
>
> Since 3921508 ppb is a huge adjustment, you can simply use that as a safe
> maximum, ignoring the actual input clock.
>
> Thanks,
> Richard
>
>
Regards,
Andrei
^ permalink raw reply
* fs, net: deadlock between bind/splice on af_unix
From: Dmitry Vyukov @ 2016-12-08 14:47 UTC (permalink / raw)
To: Al Viro, linux-fsdevel@vger.kernel.org, LKML, David Miller,
Rainer Weikusat, Hannes Frederic Sowa, Cong Wang, netdev,
Eric Dumazet
Cc: syzkaller
Hello,
I am getting the following deadlock reports while running syzkaller
fuzzer on 318c8932ddec5c1c26a4af0f3c053784841c598e (Dec 7).
[ INFO: possible circular locking dependency detected ]
4.9.0-rc8+ #77 Not tainted
-------------------------------------------------------
syz-executor0/3155 is trying to acquire lock:
(&u->bindlock){+.+.+.}, at: [<ffffffff871bca1a>]
unix_autobind.isra.26+0xca/0x8a0 net/unix/af_unix.c:852
but task is already holding lock:
(&pipe->mutex/1){+.+.+.}, at: [< inline >] pipe_lock_nested
fs/pipe.c:66
(&pipe->mutex/1){+.+.+.}, at: [<ffffffff81a8ea4b>]
pipe_lock+0x5b/0x70 fs/pipe.c:74
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
[ 202.103497] [< inline >] validate_chain
kernel/locking/lockdep.c:2265
[ 202.103497] [<ffffffff81569576>]
__lock_acquire+0x2156/0x3380 kernel/locking/lockdep.c:3338
[ 202.103497] [<ffffffff8156b672>] lock_acquire+0x2a2/0x790
kernel/locking/lockdep.c:3749
[ 202.103497] [< inline >] __mutex_lock_common
kernel/locking/mutex.c:521
[ 202.103497] [<ffffffff88195bcf>]
mutex_lock_nested+0x23f/0xf20 kernel/locking/mutex.c:621
[ 202.103497] [< inline >] pipe_lock_nested fs/pipe.c:66
[ 202.103497] [<ffffffff81a8ea4b>] pipe_lock+0x5b/0x70 fs/pipe.c:74
[ 202.103497] [<ffffffff81b451f7>]
iter_file_splice_write+0x267/0xfa0 fs/splice.c:717
[ 202.103497] [< inline >] do_splice_from fs/splice.c:869
[ 202.103497] [< inline >] do_splice fs/splice.c:1160
[ 202.103497] [< inline >] SYSC_splice fs/splice.c:1410
[ 202.103497] [<ffffffff81b473c7>] SyS_splice+0x7d7/0x16a0
fs/splice.c:1393
[ 202.103497] [<ffffffff881a5f85>] entry_SYSCALL_64_fastpath+0x23/0xc6
[ 202.103497] [< inline >] validate_chain
kernel/locking/lockdep.c:2265
[ 202.103497] [<ffffffff81569576>]
__lock_acquire+0x2156/0x3380 kernel/locking/lockdep.c:3338
[ 202.103497] [<ffffffff8156b672>] lock_acquire+0x2a2/0x790
kernel/locking/lockdep.c:3749
[ 202.103497] [< inline >]
percpu_down_read_preempt_disable include/linux/percpu-rwsem.h:35
[ 202.103497] [< inline >] percpu_down_read
include/linux/percpu-rwsem.h:58
[ 202.103497] [<ffffffff81a7bb33>]
__sb_start_write+0x193/0x2a0 fs/super.c:1252
[ 202.103497] [< inline >] sb_start_write
include/linux/fs.h:1549
[ 202.103497] [<ffffffff81af9954>] mnt_want_write+0x44/0xb0
fs/namespace.c:389
[ 202.103497] [<ffffffff81ab09f6>] filename_create+0x156/0x620
fs/namei.c:3598
[ 202.103497] [<ffffffff81ab0ef8>] kern_path_create+0x38/0x50
fs/namei.c:3644
[ 202.103497] [< inline >] unix_mknod net/unix/af_unix.c:967
[ 202.103497] [<ffffffff871c0e11>] unix_bind+0x4d1/0xe60
net/unix/af_unix.c:1035
[ 202.103497] [<ffffffff86a76b7e>] SYSC_bind+0x20e/0x4c0
net/socket.c:1382
[ 202.103497] [<ffffffff86a7a509>] SyS_bind+0x29/0x30 net/socket.c:1368
[ 202.103497] [<ffffffff881a5f85>] entry_SYSCALL_64_fastpath+0x23/0xc6
[ 202.103497] [< inline >] check_prev_add
kernel/locking/lockdep.c:1828
[ 202.103497] [<ffffffff8156309b>]
check_prevs_add+0xaab/0x1c20 kernel/locking/lockdep.c:1938
[ 202.103497] [< inline >] validate_chain
kernel/locking/lockdep.c:2265
[ 202.103497] [<ffffffff81569576>]
__lock_acquire+0x2156/0x3380 kernel/locking/lockdep.c:3338
[ 202.103497] [<ffffffff8156b672>] lock_acquire+0x2a2/0x790
kernel/locking/lockdep.c:3749
[ 202.103497] [< inline >] __mutex_lock_common
kernel/locking/mutex.c:521
[ 202.103497] [<ffffffff88196b82>]
mutex_lock_interruptible_nested+0x2d2/0x11d0
kernel/locking/mutex.c:650
[ 202.103497] [<ffffffff871bca1a>]
unix_autobind.isra.26+0xca/0x8a0 net/unix/af_unix.c:852
[ 202.103497] [<ffffffff871c76dd>]
unix_dgram_sendmsg+0x105d/0x1730 net/unix/af_unix.c:1667
[ 202.103497] [<ffffffff871c7ea8>]
unix_seqpacket_sendmsg+0xf8/0x170 net/unix/af_unix.c:2071
[ 202.103497] [< inline >] sock_sendmsg_nosec net/socket.c:621
[ 202.103497] [<ffffffff86a7618f>] sock_sendmsg+0xcf/0x110
net/socket.c:631
[ 202.103497] [<ffffffff86a7683c>] kernel_sendmsg+0x4c/0x60
net/socket.c:639
[ 202.103497] [<ffffffff86a8101d>]
sock_no_sendpage+0x20d/0x310 net/core/sock.c:2321
[ 202.103497] [<ffffffff86a74c95>] kernel_sendpage+0x95/0xf0
net/socket.c:3289
[ 202.103497] [<ffffffff86a74d92>] sock_sendpage+0xa2/0xd0
net/socket.c:775
[ 202.103497] [<ffffffff81b3ee1e>]
pipe_to_sendpage+0x2ae/0x390 fs/splice.c:469
[ 202.103497] [< inline >] splice_from_pipe_feed fs/splice.c:520
[ 202.103497] [<ffffffff81b42f3f>]
__splice_from_pipe+0x31f/0x750 fs/splice.c:644
[ 202.103497] [<ffffffff81b4665c>]
splice_from_pipe+0x1dc/0x300 fs/splice.c:679
[ 202.103497] [<ffffffff81b467c5>]
generic_splice_sendpage+0x45/0x60 fs/splice.c:850
[ 202.103497] [< inline >] do_splice_from fs/splice.c:869
[ 202.103497] [< inline >] do_splice fs/splice.c:1160
[ 202.103497] [< inline >] SYSC_splice fs/splice.c:1410
[ 202.103497] [<ffffffff81b473c7>] SyS_splice+0x7d7/0x16a0
fs/splice.c:1393
[ 202.103497] [<ffffffff881a5f85>] entry_SYSCALL_64_fastpath+0x23/0xc6
other info that might help us debug this:
Chain exists of:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&pipe->mutex/1);
lock(sb_writers#5);
lock(&pipe->mutex/1);
lock(&u->bindlock);
*** DEADLOCK ***
1 lock held by syz-executor0/3155:
#0: (&pipe->mutex/1){+.+.+.}, at: [< inline >]
pipe_lock_nested fs/pipe.c:66
#0: (&pipe->mutex/1){+.+.+.}, at: [<ffffffff81a8ea4b>]
pipe_lock+0x5b/0x70 fs/pipe.c:74
stack backtrace:
CPU: 3 PID: 3155 Comm: syz-executor0 Not tainted 4.9.0-rc8+ #77
Hardware name: Google Google/Google, BIOS Google 01/01/2011
ffff88004b1fe288 ffffffff834c44f9 ffffffff00000003 1ffff1000963fbe4
ffffed000963fbdc 0000000041b58ab3 ffffffff895816f0 ffffffff834c420b
0000000000000000 0000000000000000 0000000000000000 0000000000000000
Call Trace:
[< inline >] __dump_stack lib/dump_stack.c:15
[<ffffffff834c44f9>] dump_stack+0x2ee/0x3f5 lib/dump_stack.c:51
[<ffffffff81560cb0>] print_circular_bug+0x310/0x3c0
kernel/locking/lockdep.c:1202
[< inline >] check_prev_add kernel/locking/lockdep.c:1828
[<ffffffff8156309b>] check_prevs_add+0xaab/0x1c20 kernel/locking/lockdep.c:1938
[< inline >] validate_chain kernel/locking/lockdep.c:2265
[<ffffffff81569576>] __lock_acquire+0x2156/0x3380 kernel/locking/lockdep.c:3338
[<ffffffff8156b672>] lock_acquire+0x2a2/0x790 kernel/locking/lockdep.c:3749
[< inline >] __mutex_lock_common kernel/locking/mutex.c:521
[<ffffffff88196b82>] mutex_lock_interruptible_nested+0x2d2/0x11d0
kernel/locking/mutex.c:650
[<ffffffff871bca1a>] unix_autobind.isra.26+0xca/0x8a0 net/unix/af_unix.c:852
[<ffffffff871c76dd>] unix_dgram_sendmsg+0x105d/0x1730 net/unix/af_unix.c:1667
[<ffffffff871c7ea8>] unix_seqpacket_sendmsg+0xf8/0x170 net/unix/af_unix.c:2071
[< inline >] sock_sendmsg_nosec net/socket.c:621
[<ffffffff86a7618f>] sock_sendmsg+0xcf/0x110 net/socket.c:631
[<ffffffff86a7683c>] kernel_sendmsg+0x4c/0x60 net/socket.c:639
[<ffffffff86a8101d>] sock_no_sendpage+0x20d/0x310 net/core/sock.c:2321
[<ffffffff86a74c95>] kernel_sendpage+0x95/0xf0 net/socket.c:3289
[<ffffffff86a74d92>] sock_sendpage+0xa2/0xd0 net/socket.c:775
[<ffffffff81b3ee1e>] pipe_to_sendpage+0x2ae/0x390 fs/splice.c:469
[< inline >] splice_from_pipe_feed fs/splice.c:520
[<ffffffff81b42f3f>] __splice_from_pipe+0x31f/0x750 fs/splice.c:644
[<ffffffff81b4665c>] splice_from_pipe+0x1dc/0x300 fs/splice.c:679
[<ffffffff81b467c5>] generic_splice_sendpage+0x45/0x60 fs/splice.c:850
[< inline >] do_splice_from fs/splice.c:869
[< inline >] do_splice fs/splice.c:1160
[< inline >] SYSC_splice fs/splice.c:1410
[<ffffffff81b473c7>] SyS_splice+0x7d7/0x16a0 fs/splice.c:1393
[<ffffffff881a5f85>] entry_SYSCALL_64_fastpath+0x23/0xc6
^ permalink raw reply
* [PATCH] ipv4: Should use consistent conditional judgement for ip fragment in __ip_append_data and ip_finish_output
From: Zheng Li @ 2016-12-08 14:48 UTC (permalink / raw)
To: netdev, davem, kuznet, jmorris, yoshfuji, kaber
Cc: allen.y.zhao, hua.lv, james.z.li
From: zheng li <james.z.li@ericsson.com>
There is an inconsitent conditional judgement in __ip_append_data and ip_finish_output functions,
the variable length in __ip_append_data just include the length of applicatoin's payload and udp
header, don't include the length of ip header, but in ip_finish_output use (skb->len > ip_skb_dst_mtu(skb))
as judgement, and skb->len include the length of ip header.
That cuase some particular applicatoin's udp payload whose length is between (MTU - IP Header) and MTU
were framented by ip_fragment even though the rst->dev support UFO features.
Add the length of ip header to length in __ip_append_data to keep consistent conditional judgement as
ip_finish_output for ip fragment.
Signed-off-by: Zheng Li <james.z.li@ericsson.com>
---
net/ipv4/ip_output.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
index 877bdb0..12a0149 100644
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@ -936,7 +936,7 @@ static int __ip_append_data(struct sock *sk,
csummode = CHECKSUM_PARTIAL;
cork->length += length;
- if (((length > mtu) || (skb && skb_is_gso(skb))) &&
+ if ((((length + fragheaderlen) > mtu) || (skb && skb_is_gso(skb))) &&
(sk->sk_protocol == IPPROTO_UDP) &&
(rt->dst.dev->features & NETIF_F_UFO) && !rt->dst.header_len &&
(sk->sk_type == SOCK_DGRAM) && !sk->sk_no_check_tx) {
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] sh_eth: add wake-on-lan support via magic packet
From: Niklas Söderlund @ 2016-12-08 14:56 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: Simon Horman, netdev, linux-renesas-soc
In-Reply-To: <59a1f246-9062-20e1-3f85-a1c5f6fcfc29@cogentembedded.com>
Hi Sergei,
Thanks for your feedback.
On 2016-12-08 15:28:48 +0300, Sergei Shtylyov wrote:
> Hello!
>
> Good to see that somebody cares still about this driver, one more task
> off my back. :-)
>
> On 12/07/2016 07:28 PM, Niklas Söderlund wrote:
>
> You only enable the WOL support fo the R-Car gen2 chips but never say that
> explicitly, neither in the subject nor here.
>
> > Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
> > ---
> > drivers/net/ethernet/renesas/sh_eth.c | 120 +++++++++++++++++++++++++++++++---
> > drivers/net/ethernet/renesas/sh_eth.h | 4 ++
> > 2 files changed, 116 insertions(+), 8 deletions(-)
>
> > diff --git a/drivers/net/ethernet/renesas/sh_eth.c b/drivers/net/ethernet/renesas/sh_eth.c
> > index 05b0dc5..3974046 100644
> > --- a/drivers/net/ethernet/renesas/sh_eth.c
> > +++ b/drivers/net/ethernet/renesas/sh_eth.c
> > @@ -624,7 +624,7 @@ static struct sh_eth_cpu_data r8a779x_data = {
> >
> > .register_type = SH_ETH_REG_FAST_RCAR,
> >
> > - .ecsr_value = ECSR_PSRTO | ECSR_LCHNG | ECSR_ICD,
> > + .ecsr_value = ECSR_PSRTO | ECSR_LCHNG | ECSR_ICD | ECSR_MPD,
> > .ecsipr_value = ECSIPR_PSRTOIP | ECSIPR_LCHNGIP | ECSIPR_ICDIP,
> > .eesipr_value = 0x01ff009f,
> >
> > @@ -641,6 +641,7 @@ static struct sh_eth_cpu_data r8a779x_data = {
> > .tpauser = 1,
> > .hw_swap = 1,
> > .rmiimode = 1,
> > + .magic = 1,
> > };
> > #endif /* CONFIG_OF */
>
> So I suggest that you add the general WOL support code in the 1st patch
> and enable the new feature per SoC family in the follow up patches.
Ok I will split this up in v2.
>
> > @@ -1657,6 +1658,10 @@ static irqreturn_t sh_eth_interrupt(int irq, void *netdev)
> > goto out;
> >
> > if (!likely(mdp->irq_enabled)) {
>
> Oops, I guess unlikely(!mdp->irq_enabled) was meant here...
I can correct this in a separate patch if you wish.
>
> > + /* Handle MagicPacket interrupt */
> > + if (sh_eth_read(ndev, ECSR) & ECSR_MPD)
>
> Why do it here?
See bellow.
>
> > + sh_eth_modify(ndev, ECSR, 0, ECSR_MPD);
> > +
> > sh_eth_write(ndev, 0, EESIPR);
> > goto out;
> > }
> [...]
> > @@ -3017,6 +3051,11 @@ static int sh_eth_drv_probe(struct platform_device *pdev)
> > goto out_release;
> > }
> >
> > + /* Get clock, if not found that's OK but Wake-On-Lan is unavailable */
> > + mdp->clk = devm_clk_get(&pdev->dev, NULL);
>
> Luckily, we have <linux/clk.h> #include'd...
>
> > + if (IS_ERR(mdp->clk))
> > + mdp->clk = NULL;
> > +
> > ndev->base_addr = res->start;
> >
> > spin_lock_init(&mdp->lock);
> > @@ -3111,6 +3150,10 @@ static int sh_eth_drv_probe(struct platform_device *pdev)
> > if (ret)
> > goto out_napi_del;
> >
> > + mdp->wol_enabled = false;
>
> No need, the '*mdp' was kzalloc'ed.
OK, i prefer to explicitly set for easier reading of the code. But if
you wish I will remove this in v2.
>
> > + if (mdp->cd->magic && mdp->clk)
> > + device_set_wakeup_capable(&pdev->dev, 1);
> > +
> > /* print device information */
> > netdev_info(ndev, "Base address at 0x%x, %pM, IRQ %d.\n",
> > (u32)ndev->base_addr, ndev->dev_addr, ndev->irq);
> > @@ -3150,15 +3193,71 @@ static int sh_eth_drv_remove(struct platform_device *pdev)
> >
> > #ifdef CONFIG_PM
> > #ifdef CONFIG_PM_SLEEP
> > +static int sh_eth_wol_setup(struct net_device *ndev)
> > +{
> > + struct sh_eth_private *mdp = netdev_priv(ndev);
> > +
> > + /* Only allow ECI interrupts */
> > + mdp->irq_enabled = false;
>
> Why 'false' if you enable IRQs below?
I mask all interrupts except MagicPacket (ECSIPR_MPDIP) interrupts form
the ECI (DMAC_M_ECI) and by setting irq_enabled to false the interrupt
handler will only ack any residue interrupt. This is how it's done in
other parts of the driver when disabling interrupts.
This is also why I only check for MagicPacket interrupts if irq_enabled
is false.
>
> > + synchronize_irq(ndev->irq);
> > + napi_disable(&mdp->napi);
> > + sh_eth_write(ndev, DMAC_M_ECI, EESIPR);
> > +
> > + /* Enable ECI MagicPacket interrupt */
> > + sh_eth_write(ndev, ECSIPR_MPDIP, ECSIPR);
> > +
> > + /* Enable MagicPacket */
> > + sh_eth_modify(ndev, ECMR, 0, ECMR_PMDE);
> > +
> > + /* Increased clock usage so device won't be suspended */
> > + clk_enable(mdp->clk);
>
> Hum, intermixiggn runtime PM with clock API doesn't look good...
I agree it looks weird but I need a way to increment the usage count for
the clock otherwise the PM code will disable the module clock and WoL
will not work. Note that this call will not enable the clock just
increase the usage count so it won't be disabled when the PM code
decrease it after the sh_eth suspend function is run.
If you know of a different way of ensuring that the clock is not turned
off I be happy to look at it. I did some investigation into this and
calling clk_enable() directly is for example what happens in the
enable_irq_wake() call path to ensure the clock for the irq_chip is not
turned off if it is a wakeup source, se for example
gpio_rcar_irq_set_wake() in drivers/gpio/gpio-rcar.c.
>
> > +
> > + return enable_irq_wake(ndev->irq);
> > +}
> > +
> > +static int sh_eth_wol_restore(struct net_device *ndev)
> > +{
> > + struct sh_eth_private *mdp = netdev_priv(ndev);
> > + int ret;
> > +
> > + napi_enable(&mdp->napi);
> > +
> > + /* Disable MagicPacket */
> > + sh_eth_modify(ndev, ECMR, ECMR_PMDE, 0);
> > +
> > + /* The device need to be reset to restore MagicPacket logic
> > + * for next wakeup. If we close and open the device it will
> > + * both be reset and all registers restored. This is what
> > + * happens during suspend and resume without WoL enabled.
> > + */
> > + ret = sh_eth_close(ndev);
> > + if (ret < 0)
> > + return ret;
> > + ret = sh_eth_open(ndev);
> > + if (ret < 0)
> > + return ret;
> > +
> > + /* Restore clock usage count */
> > + clk_disable(mdp->clk);
>
> Hm... and RPM will think the clock is still enabled?
> Why disable the clock here anyway if we're resuming?
This call is needed to decrease the usage count for the clock we
increased with clk_enable() in the suspend path.
>
> > +
> > + return disable_irq_wake(ndev->irq);
> > +}
> > +
> [...]
> > @@ -3166,14 +3265,19 @@ static int sh_eth_suspend(struct device *dev)
> > static int sh_eth_resume(struct device *dev)
> > {
> > struct net_device *ndev = dev_get_drvdata(dev);
> > + struct sh_eth_private *mdp = netdev_priv(ndev);
> > int ret = 0;
> >
> > - if (netif_running(ndev)) {
> > + if (!netif_running(ndev))
> > + return 0;
> > +
> > + if (mdp->wol_enabled)
> > + ret = sh_eth_wol_restore(ndev);
> > + else
> > ret = sh_eth_open(ndev);
> > - if (ret < 0)
> > - return ret;
> > +
> > + if (!ret)
>
> Please keep the original error return logic, so that you can return 0 at
> the end...
Will fix for v2.
>
> > netif_device_attach(ndev);
> > - }
> >
> > return ret;
> > }
> > diff --git a/drivers/net/ethernet/renesas/sh_eth.h b/drivers/net/ethernet/renesas/sh_eth.h
> > index d050f37..26c6620 100644
> > --- a/drivers/net/ethernet/renesas/sh_eth.h
> > +++ b/drivers/net/ethernet/renesas/sh_eth.h
> > @@ -493,6 +493,7 @@ struct sh_eth_cpu_data {
> > unsigned shift_rd0:1; /* shift Rx descriptor word 0 right by 16 */
> > unsigned rmiimode:1; /* EtherC has RMIIMODE register */
> > unsigned rtrate:1; /* EtherC has RTRATE register */
> > + unsigned magic:1; /* EtherC have PMDE in ECMR and MPDIP in ECSIPR */
>
> OK, e.g. RZ/A1 doesn't have these bits...
>
> [...]
>
> MBR, Sergei
>
--
Regards,
Niklas Söderlund
^ permalink raw reply
* Re: [PATCH] sh_eth: add wake-on-lan support via magic packet
From: Niklas Söderlund @ 2016-12-08 15:01 UTC (permalink / raw)
To: Simon Horman
Cc: Geert Uytterhoeven, Sergei Shtylyov, netdev@vger.kernel.org,
Linux-Renesas
In-Reply-To: <20161208132241.GA7150@verge.net.au>
Hi Simon,
Thanks for your feedback.
On 2016-12-08 14:22:44 +0100, Simon Horman wrote:
<snip>
> > >
> > > > --- a/drivers/net/ethernet/renesas/sh_eth.h
> > > > +++ b/drivers/net/ethernet/renesas/sh_eth.h
> > > > @@ -493,6 +493,7 @@ struct sh_eth_cpu_data {
> > > > unsigned shift_rd0:1; /* shift Rx descriptor word 0 right by 16 */
> > > > unsigned rmiimode:1; /* EtherC has RMIIMODE register */
> > > > unsigned rtrate:1; /* EtherC has RTRATE register */
> > > > + unsigned magic:1; /* EtherC have PMDE in ECMR and MPDIP in ECSIPR */
> > >
> > > Instead of adding a new flag, perhaps you can just check for the ECSR_MPD flag
> > > in ecsr_value?
> >
> > I briefly considered this but decided against it since I do not have
> > documentation for all versions of the device and no way to test it. You
> > tested and confirmed functionality on r8a7740, which leaves:
> >
> > - sh7734-gether
> > - sh7763-gether
> > - sh7757-gether
> >
> > To figure out if they support MagicPacket in the same fashion as r8a7740
> > and r8a779x. If anyone have access to documentation or hardware to
> > confirm this I be more then happy to get rid of the magic flag in favor
> > och checking for ECSR_MPD in ecsr_value.
>
> Perhaps documentation can be found but if not I wonder if we can use some
> other mechanism to blacklist SoC which we are unsure about.
>
> From my POV it would be very nice if things just worked™ on SoCs where
> the feature has been verified.
I agree, I will follow Sergies advice and Geerts testing to enable Gen2
family and r8a7740/armadillo in two separate patches. Then if we later
can confirm it works on other models we can enable them in separate
patches by setting the magic flag in struct sh_eth_cpu_data for those
models. Do you agree this is the best way to handle this?
--
Regards,
Niklas Söderlund
^ permalink raw reply
* Re: [PATCH] sh_eth: add wake-on-lan support via magic packet
From: Geert Uytterhoeven @ 2016-12-08 15:13 UTC (permalink / raw)
To: Niklas Söderlund
Cc: Sergei Shtylyov, Simon Horman, netdev@vger.kernel.org,
Linux-Renesas
In-Reply-To: <20161208145635.GH21834@bigcity.dyn.berto.se>
On Thu, Dec 8, 2016 at 3:56 PM, Niklas Söderlund
<niklas.soderlund@ragnatech.se> wrote:
>> > + /* Increased clock usage so device won't be suspended */
>> > + clk_enable(mdp->clk);
>>
>> Hum, intermixiggn runtime PM with clock API doesn't look good...
>
> I agree it looks weird but I need a way to increment the usage count for
> the clock otherwise the PM code will disable the module clock and WoL
> will not work. Note that this call will not enable the clock just
> increase the usage count so it won't be disabled when the PM code
> decrease it after the sh_eth suspend function is run.
>
> If you know of a different way of ensuring that the clock is not turned
> off I be happy to look at it. I did some investigation into this and
> calling clk_enable() directly is for example what happens in the
> enable_irq_wake() call path to ensure the clock for the irq_chip is not
> turned off if it is a wakeup source, se for example
> gpio_rcar_irq_set_wake() in drivers/gpio/gpio-rcar.c.
Ideally we want to prevent the PM code from disabling the clock, and from
powering down the power area, if present.
The latter may matter on other SoCs. But on r8a7740, Ethernet is part of
power area A4S, which we already prevent from being powered down because
it contains the memory controller.
Gr{oetje,eeting}s,
Geert
^ permalink raw reply
* Re: [PATCH v3 6/6] net: smmac: allow configuring lower pbl values
From: David Miller @ 2016-12-08 15:18 UTC (permalink / raw)
To: alexandre.torgue
Cc: niklas.cassel, robh+dt, mark.rutland, corbet, peppe.cavallaro,
preid, eric, pavel, afaerber, manabian, vpalatin,
gabriel.fernandez, niklass, netdev, devicetree, linux-kernel,
linux-doc
In-Reply-To: <4d43479f-8373-308b-8c7d-cfed5346dc53@st.com>
From: Alexandre Torgue <alexandre.torgue@st.com>
Date: Thu, 8 Dec 2016 11:42:56 +0100
> Thanks for this patch, you can add my Acked-by.
Please simply state:
Acked-by: Alexandre Torgue <alexandre.torgue@st.com>
in your reply and it will automatically appear when the patch is
applied. You don't have to ask the patch submitter or the person who
applies it to do it as you are doing here.
^ permalink raw reply
* Re: [PATCH v3 1/6] net: stmmac: return error if no DMA configuration is found
From: David Miller @ 2016-12-08 15:19 UTC (permalink / raw)
To: alexandre.torgue
Cc: niklas.cassel, peppe.cavallaro, niklass, netdev, linux-kernel
In-Reply-To: <d18098a5-a4a4-0c63-f64c-cdb7144dd67e@st.com>
From: Alexandre Torgue <alexandre.torgue@st.com>
Date: Thu, 8 Dec 2016 11:44:35 +0100
> Acked-by: Alexandre Torgue <alexandre.torgue@stcom>
Typo in your email.
I would suggest that you put this into an editor macro or
similar in order to avoid such typos in the future. That's
what people do who review a lot of patches.
^ permalink raw reply
* Re: stmmac driver...
From: David Miller @ 2016-12-08 15:25 UTC (permalink / raw)
To: alexandre.torgue; +Cc: peppe.cavallaro, netdev
In-Reply-To: <e8370557-b11a-0fe6-f87f-3af2e5990f27@st.com>
From: Alexandre Torgue <alexandre.torgue@st.com>
Date: Thu, 8 Dec 2016 14:55:04 +0100
> Maybe I forget some series. Do you have others in mind ?
Please see the thread titled:
"net: ethernet: Initial driver for Synopsys DWC XLGMAC"
which seems to be discussing consolidation of various drivers
for the same IP core, of which stmmac is one.
I personally am against any change of the driver name and
things like this, and wish the people doing that work would
simply contribute to making whatever changes they need directly
to the stmmac driver.
You really need to voice your opinion when major changes are being
proposed for the driver you maintain.
^ permalink raw reply
* Re: [PATCH 2/2] net: ethernet: stmmac: remove private tx queue lock
From: David Miller @ 2016-12-08 15:26 UTC (permalink / raw)
To: pavel
Cc: LinoSanfilippo, bh74.an, ks.giri, vipul.pandya, peppe.cavallaro,
alexandre.torgue, linux-kernel, netdev
In-Reply-To: <20161208140846.GA24327@amd>
From: Pavel Machek <pavel@ucw.cz>
Date: Thu, 8 Dec 2016 15:08:46 +0100
> On Wed 2016-12-07 18:41:11, David Miller wrote:
>> From: Pavel Machek <pavel@ucw.cz>
>> Date: Wed, 7 Dec 2016 22:37:57 +0100
>>
>> > diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> > index 982c952..7415bc2 100644
>> > --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> > +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> > @@ -1308,7 +1308,7 @@ static void stmmac_tx_clean(struct stmmac_priv *priv)
>> > unsigned int bytes_compl = 0, pkts_compl = 0;
>> > unsigned int entry = priv->dirty_tx;
>> >
>> > - spin_lock(&priv->tx_lock);
>> > + netif_tx_lock_bh(priv->dev);
>> >
>> > priv->xstats.tx_clean++;
>> >
>>
>> stmmac_tx_clean() runs from either the timer or the NAPI poll handler,
>> both execute from software interrupts, therefore _bh() should be
>> unnecessary.
>
> I've tried the test again with netif_tx_lock() (not _bh()) and it
> survived for more then four hours. Strange...
It's not strange, it's completely expected.
^ permalink raw reply
* Re: [PATCH net-next] udp: under rx pressure, try to condense skbs
From: Eric Dumazet @ 2016-12-08 15:30 UTC (permalink / raw)
To: Jesper Dangaard Brouer; +Cc: David Miller, netdev, Paolo Abeni
In-Reply-To: <20161208104620.5fc691b8@redhat.com>
On Thu, 2016-12-08 at 10:46 +0100, Jesper Dangaard Brouer wrote:
> Hmmm... I'm not thrilled to have such heuristics, that change memory
> behavior when half of the queue size (sk->sk_rcvbuf) is reached.
Well, copybreak drivers do that unconditionally, even under no stress at
all, you really should complain then.
copybreak is interesting, not only for performance point of view, but
ability to handle DOS/DDOS : Attackers need to send bigger packets to
eventually force us to consume one page per packet.
My idea (which I already described in the past) is to perform the
(small) copy only in contexts we know packet might sit for a long time
in a socket queue, and only if we know we are in stress conditions.
ACK packets for example do not need copybreak, since they wont be queued
for a long time.
>
> Most of the win comes from doing a local atomic page-refcnt decrement
> oppose to doing a remote CPU refcnf-dec. And as you noticed the
> benefit is quite high saving 241 cycles (see [1]). And you patch is
> "using" these cycles to copy the packet instead.
So, just to let you know, I have a patch series which achieve ~100 %
perf increase, without the 2nd queue I envisioned for linux-4.11
A single thread doing mere recvmsg() system calls can now read ~2Mpps.
This skb_condense() is done before producer cpus are competing using a
busylock array (not a per socket new spinlock, but a shared hashed
array, out of line).
I plan using it tcp_add_backlog() to replace the :
if (!skb->data_len)
skb->truesize = SKB_TRUESIZE(skb_end_offset(skb));
> This might no be a win in the future. I'm working on a more generic
> solution (page_pool) that (as one objective) target this remote recfnt.
Very well, when all drivers can use this, we might revert this patch if
proved not beneficial.
But make sure we can hold 1,000,000 pages in skbs stored in ~100,000
TCP/UDP sockets.
Your ideas sound fine in controlled environments, I am sure you will be
able to demonstrate their gains independently of the counter measures we
put in place in the protocol handlers.
^ permalink raw reply
* Re: [PATCH] sh_eth: add wake-on-lan support via magic packet
From: Simon Horman @ 2016-12-08 15:31 UTC (permalink / raw)
To: Niklas Söderlund
Cc: Geert Uytterhoeven, Sergei Shtylyov, netdev@vger.kernel.org,
Linux-Renesas
In-Reply-To: <20161208150105.GI21834@bigcity.dyn.berto.se>
On Thu, Dec 08, 2016 at 04:01:05PM +0100, Niklas Söderlund wrote:
> Hi Simon,
>
> Thanks for your feedback.
>
> On 2016-12-08 14:22:44 +0100, Simon Horman wrote:
>
> <snip>
>
> > > >
> > > > > --- a/drivers/net/ethernet/renesas/sh_eth.h
> > > > > +++ b/drivers/net/ethernet/renesas/sh_eth.h
> > > > > @@ -493,6 +493,7 @@ struct sh_eth_cpu_data {
> > > > > unsigned shift_rd0:1; /* shift Rx descriptor word 0 right by 16 */
> > > > > unsigned rmiimode:1; /* EtherC has RMIIMODE register */
> > > > > unsigned rtrate:1; /* EtherC has RTRATE register */
> > > > > + unsigned magic:1; /* EtherC have PMDE in ECMR and MPDIP in ECSIPR */
> > > >
> > > > Instead of adding a new flag, perhaps you can just check for the ECSR_MPD flag
> > > > in ecsr_value?
> > >
> > > I briefly considered this but decided against it since I do not have
> > > documentation for all versions of the device and no way to test it. You
> > > tested and confirmed functionality on r8a7740, which leaves:
> > >
> > > - sh7734-gether
> > > - sh7763-gether
> > > - sh7757-gether
> > >
> > > To figure out if they support MagicPacket in the same fashion as r8a7740
> > > and r8a779x. If anyone have access to documentation or hardware to
> > > confirm this I be more then happy to get rid of the magic flag in favor
> > > och checking for ECSR_MPD in ecsr_value.
> >
> > Perhaps documentation can be found but if not I wonder if we can use some
> > other mechanism to blacklist SoC which we are unsure about.
> >
> > From my POV it would be very nice if things just worked™ on SoCs where
> > the feature has been verified.
>
> I agree, I will follow Sergies advice and Geerts testing to enable Gen2
> family and r8a7740/armadillo in two separate patches. Then if we later
> can confirm it works on other models we can enable them in separate
> patches by setting the magic flag in struct sh_eth_cpu_data for those
> models. Do you agree this is the best way to handle this?
Yes, I think that is reasonable.
^ permalink raw reply
* pull-request: can 2016-12-08
From: Marc Kleine-Budde @ 2016-12-08 15:35 UTC (permalink / raw)
To: netdev; +Cc: davem, linux-can, kernel
Hello David,
this is a pull request for one patch.
Jiho Chu found and fixed a use-after-free error in the cleanup path in the peak
pcan USB CAN driver.
regards,
Marc
---
The following changes since commit ec988ad78ed6d184a7f4ca6b8e962b0e8f1de461:
phy: Don't increment MDIO bus refcount unless it's a different owner (2016-12-07 13:27:14 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can.git tags/linux-can-fixes-for-4.9-20161208
for you to fetch changes up to b67d0dd7d0dc9e456825447bbeb935d8ef43ea7c:
can: peak: fix bad memory access and free sequence (2016-12-08 15:59:52 +0100)
----------------------------------------------------------------
linux-can-fixes-for-4.9-20161208
----------------------------------------------------------------
추지호 (1):
can: peak: fix bad memory access and free sequence
drivers/net/can/usb/peak_usb/pcan_usb_core.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
^ permalink raw reply
* [PATCH] can: peak: fix bad memory access and free sequence
From: Marc Kleine-Budde @ 2016-12-08 15:35 UTC (permalink / raw)
To: netdev
Cc: davem, linux-can, kernel, 추지호, linux-stable,
Marc Kleine-Budde
In-Reply-To: <20161208153552.18122-1-mkl@pengutronix.de>
From: 추지호 <jiho.chu@samsung.com>
Fix for bad memory access while disconnecting. netdev is freed before
private data free, and dev is accessed after freeing netdev.
This makes a slub problem, and it raise kernel oops with slub debugger
config.
Signed-off-by: Jiho Chu <jiho.chu@samsung.com>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/usb/peak_usb/pcan_usb_core.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/can/usb/peak_usb/pcan_usb_core.c b/drivers/net/can/usb/peak_usb/pcan_usb_core.c
index f3141ca56bc3..0b0302af3bd2 100644
--- a/drivers/net/can/usb/peak_usb/pcan_usb_core.c
+++ b/drivers/net/can/usb/peak_usb/pcan_usb_core.c
@@ -870,23 +870,25 @@ static int peak_usb_create_dev(const struct peak_usb_adapter *peak_usb_adapter,
static void peak_usb_disconnect(struct usb_interface *intf)
{
struct peak_usb_device *dev;
+ struct peak_usb_device *dev_prev_siblings;
/* unregister as many netdev devices as siblings */
- for (dev = usb_get_intfdata(intf); dev; dev = dev->prev_siblings) {
+ for (dev = usb_get_intfdata(intf); dev; dev = dev_prev_siblings) {
struct net_device *netdev = dev->netdev;
char name[IFNAMSIZ];
+ dev_prev_siblings = dev->prev_siblings;
dev->state &= ~PCAN_USB_STATE_CONNECTED;
strncpy(name, netdev->name, IFNAMSIZ);
unregister_netdev(netdev);
- free_candev(netdev);
kfree(dev->cmd_buf);
dev->next_siblings = NULL;
if (dev->adapter->dev_free)
dev->adapter->dev_free(dev);
+ free_candev(netdev);
dev_info(&intf->dev, "%s removed\n", name);
}
--
2.10.2
^ permalink raw reply related
* Re: [PATCH net-next] udp: under rx pressure, try to condense skbs
From: Rick Jones @ 2016-12-08 15:36 UTC (permalink / raw)
To: Eric Dumazet, Jesper Dangaard Brouer; +Cc: David Miller, netdev, Paolo Abeni
In-Reply-To: <1481211015.4930.100.camel@edumazet-glaptop3.roam.corp.google.com>
On 12/08/2016 07:30 AM, Eric Dumazet wrote:
> On Thu, 2016-12-08 at 10:46 +0100, Jesper Dangaard Brouer wrote:
>
>> Hmmm... I'm not thrilled to have such heuristics, that change memory
>> behavior when half of the queue size (sk->sk_rcvbuf) is reached.
>
> Well, copybreak drivers do that unconditionally, even under no stress at
> all, you really should complain then.
Isn't that behaviour based (in part?) on the observation/belief that it
is fewer cycles to copy the small packet into a small buffer than to
send the larger buffer up the stack and have to allocate and map a
replacement?
rick jones
^ permalink raw reply
* Re: [PATCH v3 1/6] net: stmmac: return error if no DMA configuration is found
From: Alexandre Torgue @ 2016-12-08 15:41 UTC (permalink / raw)
To: David Miller
Cc: niklas.cassel, peppe.cavallaro, niklass, netdev, linux-kernel
In-Reply-To: <20161208.101915.2006667298193036157.davem@davemloft.net>
Hi David,
On 12/08/2016 04:19 PM, David Miller wrote:
> From: Alexandre Torgue <alexandre.torgue@st.com>
> Date: Thu, 8 Dec 2016 11:44:35 +0100
>
>> Acked-by: Alexandre Torgue <alexandre.torgue@stcom>
>
> Typo in your email.
>
> I would suggest that you put this into an editor macro or
> similar in order to avoid such typos in the future. That's
> what people do who review a lot of patches.
Sorry, I will pay attention next time.
>
^ permalink raw reply
* Re: [PATCH] cxgb4: Support compressed error vector for T6
From: kbuild test robot @ 2016-12-08 15:44 UTC (permalink / raw)
To: Ganesh Goudar
Cc: kbuild-all, netdev, davem, nirranjan, Arjun V, Santosh Rastapur,
Hariprasad Shenai, Ganesh Goudar
In-Reply-To: <1481202113-16266-1-git-send-email-ganeshgr@chelsio.com>
[-- Attachment #1: Type: text/plain, Size: 2004 bytes --]
Hi Arjun,
[auto build test ERROR on net-next/master]
[also build test ERROR on v4.9-rc8 next-20161208]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Ganesh-Goudar/cxgb4-Support-compressed-error-vector-for-T6/20161208-222814
config: xtensa-allmodconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 4.9.0
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=xtensa
All errors (new ones prefixed by >>):
drivers/net/ethernet/chelsio/cxgb4/sge.c: In function 't4_ethrx_handler':
>> drivers/net/ethernet/chelsio/cxgb4/sge.c:2102:9: error: 'adapter' undeclared (first use in this function)
if (adapter->params.tp.rx_pkt_encap)
^
drivers/net/ethernet/chelsio/cxgb4/sge.c:2102:9: note: each undeclared identifier is reported only once for each function it appears in
>> drivers/net/ethernet/chelsio/cxgb4/sge.c:2104:9: error: 'T6_COMPR_RXERR_CSUM_F' undeclared (first use in this function)
T6_COMPR_RXERR_CSUM_F;
^
vim +/adapter +2102 drivers/net/ethernet/chelsio/cxgb4/sge.c
2096 #define CPL_RX_PKT_FLAGS (RXF_PSH_F | RXF_SYN_F | RXF_UDP_F | \
2097 RXF_TCP_F | RXF_IP_F | RXF_IP6_F | RXF_LRO_F)
2098
2099 if (!(pkt->l2info & cpu_to_be32(CPL_RX_PKT_FLAGS))) {
2100 if ((pkt->l2info & cpu_to_be32(RXF_FCOE_F)) &&
2101 (pi->fcoe.flags & CXGB_FCOE_ENABLED)) {
> 2102 if (adapter->params.tp.rx_pkt_encap)
2103 csum_ok = err_vec &
> 2104 T6_COMPR_RXERR_CSUM_F;
2105 else
2106 csum_ok = err_vec & RXERR_CSUM_F;
2107 if (!csum_ok)
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 47264 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] net: ethernet: stmmac: remove private tx queue lock
From: Pavel Machek @ 2016-12-08 15:46 UTC (permalink / raw)
To: David Miller
Cc: LinoSanfilippo, bh74.an, ks.giri, vipul.pandya, peppe.cavallaro,
alexandre.torgue, linux-kernel, netdev
In-Reply-To: <20161208.102641.2159772626439340664.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1518 bytes --]
On Thu 2016-12-08 10:26:41, David Miller wrote:
> From: Pavel Machek <pavel@ucw.cz>
> Date: Thu, 8 Dec 2016 15:08:46 +0100
>
> > On Wed 2016-12-07 18:41:11, David Miller wrote:
> >> From: Pavel Machek <pavel@ucw.cz>
> >> Date: Wed, 7 Dec 2016 22:37:57 +0100
> >>
> >> > diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> >> > index 982c952..7415bc2 100644
> >> > --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> >> > +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> >> > @@ -1308,7 +1308,7 @@ static void stmmac_tx_clean(struct stmmac_priv *priv)
> >> > unsigned int bytes_compl = 0, pkts_compl = 0;
> >> > unsigned int entry = priv->dirty_tx;
> >> >
> >> > - spin_lock(&priv->tx_lock);
> >> > + netif_tx_lock_bh(priv->dev);
> >> >
> >> > priv->xstats.tx_clean++;
> >> >
> >>
> >> stmmac_tx_clean() runs from either the timer or the NAPI poll handler,
> >> both execute from software interrupts, therefore _bh() should be
> >> unnecessary.
> >
> > I've tried the test again with netif_tx_lock() (not _bh()) and it
> > survived for more then four hours. Strange...
>
> It's not strange, it's completely expected.
Well, I tried that exact test before, and it survived for something
like 10 minutes. So yes... this surprised me.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: stmmac driver...
From: Alexandre Torgue @ 2016-12-08 15:49 UTC (permalink / raw)
To: David Miller; +Cc: peppe.cavallaro, netdev
In-Reply-To: <20161208.102552.714315690167693892.davem@davemloft.net>
On 12/08/2016 04:25 PM, David Miller wrote:
> From: Alexandre Torgue <alexandre.torgue@st.com>
> Date: Thu, 8 Dec 2016 14:55:04 +0100
>
>> Maybe I forget some series. Do you have others in mind ?
>
> Please see the thread titled:
>
> "net: ethernet: Initial driver for Synopsys DWC XLGMAC"
>
> which seems to be discussing consolidation of various drivers
> for the same IP core, of which stmmac is one.
>
> I personally am against any change of the driver name and
> things like this, and wish the people doing that work would
> simply contribute to making whatever changes they need directly
> to the stmmac driver.
>
> You really need to voice your opinion when major changes are being
> proposed for the driver you maintain.
For sure I agree. I miss this one as it doesn't modify (yet) stmmac
driver. I gonna respond to the thread;
Regards
Alex
>
^ permalink raw reply
* Re: [PATCH net-next 0/2] Initial driver for Synopsys DWC XLGMAC
From: Alexandre Torgue @ 2016-12-08 15:59 UTC (permalink / raw)
To: Jie Deng, davem, f.fainelli, netdev
Cc: linux-kernel, CARLOS.PALMINHA, lars.persson, thomas.lendacky
In-Reply-To: <cover.1481075763.git.jiedeng@synopsys.com>
Hi
On 12/07/2016 04:57 AM, Jie Deng wrote:
> This series provides the support for 25/40/50/100 GbE
> devices using Synopsys DWC Enterprise Ethernet (XLGMAC).
Can you explain which GMAC are you targeted ?
A driver which support some Synopsys GMAC IP already exists. It support
GMAC 3.5, 3.7, 4.0, 4.10 versions. You can find it in:
drivers/net/ethernet/stmicro/stmmac/. When I look at all files your
gonna to create, it looks like to ones in stmmac driver so maybe you
could easily add your IP inside stmmac driver.
Note that an other driver is existing for synopsys GMAC 4.0 IP. it is
located in drivers/net/ethernet/synopsys/dwc_eth_qos.c and coming from
AXIS guys. A task is ongoing to only have stmmac driver so it should be
harmful to create a new one.
Regards
Alex
>
> The first patch adds support for Synopsys XLGMII.
> The second patch provides the initial driver for Synopsys XLGMAC
>
> The driver has three layers by refactoring AMD XGBE.
>
> dwc-eth-xxx.x
> The DWC ethernet core layer (DWC ECL). This layer contains codes
> can be shared by different DWC series ethernet cores
>
> dwc-xxx.x (e.g. dwc-xlgmac.c)
> The DWC MAC HW adapter layer (DWC MHAL). This layer contains
> special support for a specific MAC. e.g. currently, XLGMAC.
>
> xxx-xxx-pci.c xxx-xxx-plat.c (e.g. dwc-xlgmac-pci.c)
> The glue adapter layer (GAL). Vendors who adopt Synopsys Etherent
> cores can develop a glue driver for their platform.
>
> Jie Deng (2):
> net: phy: add extension of phy-mode for XLGMII
> net: ethernet: Initial driver for Synopsys DWC XLGMAC
>
> Documentation/devicetree/bindings/net/ethernet.txt | 1 +
> MAINTAINERS | 6 +
> drivers/net/ethernet/synopsys/Kconfig | 2 +
> drivers/net/ethernet/synopsys/Makefile | 1 +
> drivers/net/ethernet/synopsys/dwc/Kconfig | 37 +
> drivers/net/ethernet/synopsys/dwc/Makefile | 9 +
> drivers/net/ethernet/synopsys/dwc/dwc-eth-dcb.c | 228 ++
> .../net/ethernet/synopsys/dwc/dwc-eth-debugfs.c | 328 +++
> drivers/net/ethernet/synopsys/dwc/dwc-eth-desc.c | 715 +++++
> .../net/ethernet/synopsys/dwc/dwc-eth-ethtool.c | 567 ++++
> drivers/net/ethernet/synopsys/dwc/dwc-eth-hw.c | 3098 ++++++++++++++++++++
> drivers/net/ethernet/synopsys/dwc/dwc-eth-mdio.c | 252 ++
> drivers/net/ethernet/synopsys/dwc/dwc-eth-net.c | 2319 +++++++++++++++
> drivers/net/ethernet/synopsys/dwc/dwc-eth-ptp.c | 216 ++
> drivers/net/ethernet/synopsys/dwc/dwc-eth-regacc.h | 1115 +++++++
> drivers/net/ethernet/synopsys/dwc/dwc-eth.h | 738 +++++
> drivers/net/ethernet/synopsys/dwc/dwc-xlgmac-pci.c | 538 ++++
> drivers/net/ethernet/synopsys/dwc/dwc-xlgmac.c | 135 +
> drivers/net/ethernet/synopsys/dwc/dwc-xlgmac.h | 85 +
> include/linux/phy.h | 3 +
> 20 files changed, 10393 insertions(+)
> create mode 100644 drivers/net/ethernet/synopsys/dwc/Kconfig
> create mode 100644 drivers/net/ethernet/synopsys/dwc/Makefile
> create mode 100644 drivers/net/ethernet/synopsys/dwc/dwc-eth-dcb.c
> create mode 100644 drivers/net/ethernet/synopsys/dwc/dwc-eth-debugfs.c
> create mode 100644 drivers/net/ethernet/synopsys/dwc/dwc-eth-desc.c
> create mode 100644 drivers/net/ethernet/synopsys/dwc/dwc-eth-ethtool.c
> create mode 100644 drivers/net/ethernet/synopsys/dwc/dwc-eth-hw.c
> create mode 100644 drivers/net/ethernet/synopsys/dwc/dwc-eth-mdio.c
> create mode 100644 drivers/net/ethernet/synopsys/dwc/dwc-eth-net.c
> create mode 100644 drivers/net/ethernet/synopsys/dwc/dwc-eth-ptp.c
> create mode 100644 drivers/net/ethernet/synopsys/dwc/dwc-eth-regacc.h
> create mode 100644 drivers/net/ethernet/synopsys/dwc/dwc-eth.h
> create mode 100644 drivers/net/ethernet/synopsys/dwc/dwc-xlgmac-pci.c
> create mode 100644 drivers/net/ethernet/synopsys/dwc/dwc-xlgmac.c
> create mode 100644 drivers/net/ethernet/synopsys/dwc/dwc-xlgmac.h
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox