* 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
* [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
* 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
* 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
* 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: [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 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: 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: 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 v3 6/6] net: smmac: allow configuring lower pbl values
From: Andreas Färber @ 2016-12-08 13:44 UTC (permalink / raw)
To: Alexandre Torgue, Niklas Cassel, Rob Herring, Mark Rutland,
Jonathan Corbet, Giuseppe Cavallaro, David S. Miller, Phil Reid,
Eric Engestrom, Pavel Machek, Joachim Eastwood, Vincent Palatin,
Gabriel Fernandez
Cc: Niklas Cassel, netdev, devicetree, linux-kernel, linux-doc
In-Reply-To: <4d43479f-8373-308b-8c7d-cfed5346dc53@st.com>
Hi,
In subject: s/smmac/stmmac/
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
^ permalink raw reply
* Re: stmmac DT property snps,axi_all
From: Alexandre Torgue @ 2016-12-08 13:36 UTC (permalink / raw)
To: Niklas Cassel, Giuseppe Cavallaro; +Cc: netdev
In-Reply-To: <51f8249e-bdb9-e3a7-5d82-7ac869316f0e@axis.com>
Hi Niklas,
On 12/05/2016 05:18 PM, Niklas Cassel wrote:
> Hello Giuseppe
>
>
> I'm trying to figure out what snps,axi_all is supposed to represent.
>
> It appears that the value is saved, but never used in the code.
>
> Looking at the register specification, I'm guessing that it represents
> Address-Aligned Beats, but there is already the property snps,aal
> for that.
IMO, it is not useful. Indeed AXI_AAL is a read only bit (in AXI bus
mode register) and reflects the aal bit in DMA bus register.
As you know we use "snps,aal" to set aal bit in DMA bus register.
So "snps,axi_all" entry seems useless. Let's see with Peppe.
Regards
Alex
>
>
> Regards,
> Niklas
>
^ permalink raw reply
* Re: [PATCH] sh_eth: add wake-on-lan support via magic packet
From: Simon Horman @ 2016-12-08 13:22 UTC (permalink / raw)
To: Niklas Söderlund
Cc: Geert Uytterhoeven, Sergei Shtylyov, netdev@vger.kernel.org,
Linux-Renesas
In-Reply-To: <20161208071620.GG21834@bigcity.dyn.berto.se>
On do, dec 08, 2016 at 08:16:20 +0100, Niklas Söderlund wrote:
> Hi Geert,
>
> Thanks for testing and your feedback.
>
> On 2016-12-07 19:14:40 +0100, Geert Uytterhoeven wrote:
> > Hi Niklas,
> >
> > On Wed, Dec 7, 2016 at 5:28 PM, Niklas Söderlund
> > <niklas.soderlund+renesas@ragnatech.se> wrote:
> > > Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
> >
> > Thanks, works fine on r8a7791/koelsch!
> >
> > Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
> >
> > > --- 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,
> >
> > Interestingly, the ECSR_MPD bit is already set for several SoCs.
>
> Yes, I noticed that and my assumption was that it was set 'just in case'
> to clear any MagicPacket interrupts at probe time.
>
> >
> > Hence adding ".magic = 1" to the entry for r8a7740 instantly gave me working
> > WoL support on r8a7740/armadillo. Cool!
>
> Cool, I will set ".magic = 1" for r8a7740 in v2.
>
> >
> > > --- 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.
> > > @@ -529,6 +530,9 @@ struct sh_eth_private {
> > > unsigned no_ether_link:1;
> > > unsigned ether_link_active_low:1;
> > > unsigned is_opened:1;
> > > +
> > > + bool wol_enabled;
> >
> > "unsigned wol_enabled:1", to merge with the bitfield above?
>
> Thanks, looking it it now I don't know what I was thinking. I will
> changes it for v2.
>
> >
> > > + struct clk *clk;
> >
> > It's a good practice to keep all pointers at the top of the struct, to avoid
> > gaps due to alignment restrictions, especially on 64-bit (I know that's not
> > the case here).
>
> Thanks, you learn new things everyday. I will move it for v2.
>
> >
> > Gr{oetje,eeting}s,
> >
> > Geert
> >
> > --
> > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> >
> > In personal conversations with technical people, I call myself a hacker. But
> > when I'm talking to journalists I just say "programmer" or something like that.
> > -- Linus Torvalds
>
> --
> Regards,
> Niklas Söderlund
>
^ permalink raw reply
* [PATCH] net: socket: preferred __aligned(size) for control buffer
From: kushwaha.a @ 2016-12-08 12:51 UTC (permalink / raw)
To: davem; +Cc: netdev, akkushwaha9896
From: Amit Kushwaha <kushwaha.a@samsung.com>
This patch cleanup checkpatch.pl warning
WARNING: __aligned(size) is preferred over __attribute__((aligned(size)))
Signed-off-by: Amit Kushwaha <kushwaha.a@samsung.com>
---
net/socket.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/socket.c b/net/socket.c
index e631894..5835383 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -1,3 +1,4 @@
+
/*
* NET An implementation of the SOCKET network access protocol.
*
@@ -1918,7 +1919,7 @@ static int ___sys_sendmsg(struct socket *sock, struct user_msghdr __user *msg,
struct sockaddr_storage address;
struct iovec iovstack[UIO_FASTIOV], *iov = iovstack;
unsigned char ctl[sizeof(struct cmsghdr) + 20]
- __attribute__ ((aligned(sizeof(__kernel_size_t))));
+ __aligned(sizeof(__kernel_size_t));
/* 20 is size of ipv6_pktinfo */
unsigned char *ctl_buf = ctl;
int ctl_len;
--
1.7.9.5
^ permalink raw reply related
* [PATCH] cxgb4: Support compressed error vector for T6
From: Ganesh Goudar @ 2016-12-08 13:01 UTC (permalink / raw)
To: netdev, davem
Cc: nirranjan, Arjun V, Santosh Rastapur, Hariprasad Shenai,
Ganesh Goudar
From: Arjun V <arjun@chelsio.com>
t6fw-1.15.15.0 enabled compressed error vector in cpl_rx_pkt for T6.
Updating driver to take care of these changes.
Signed-off-by: Santosh Rastapur <santosh@chelsio.com>
Signed-off-by: Arjun V <arjun@chelsio.com>
Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4.h | 5 +++++
drivers/net/ethernet/chelsio/cxgb4/sge.c | 16 ++++++++++++++--
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 7 +++++++
drivers/net/ethernet/chelsio/cxgb4/t4_msg.h | 10 ++++++++++
drivers/net/ethernet/chelsio/cxgb4/t4_regs.h | 4 ++++
5 files changed, 40 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
index 0bce1bf..9a49c42 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
@@ -263,6 +263,11 @@ struct tp_params {
u32 vlan_pri_map; /* cached TP_VLAN_PRI_MAP */
u32 ingress_config; /* cached TP_INGRESS_CONFIG */
+ /* cached TP_OUT_CONFIG compressed error vector
+ * and passing outer header info for encapsulated packets.
+ */
+ int rx_pkt_encap;
+
/* TP_VLAN_PRI_MAP Compressed Filter Tuple field offsets. This is a
* subset of the set of fields which may be present in the Compressed
* Filter Tuple portion of filters and TCP TCB connections. The
diff --git a/drivers/net/ethernet/chelsio/cxgb4/sge.c b/drivers/net/ethernet/chelsio/cxgb4/sge.c
index 9f60647..4576225 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/sge.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/sge.c
@@ -2038,13 +2038,20 @@ int t4_ethrx_handler(struct sge_rspq *q, const __be64 *rsp,
struct sge *s = &q->adap->sge;
int cpl_trace_pkt = is_t4(q->adap->params.chip) ?
CPL_TRACE_PKT : CPL_TRACE_PKT_T5;
+ u16 err_vec;
struct port_info *pi;
if (unlikely(*(u8 *)rsp == cpl_trace_pkt))
return handle_trace_pkt(q->adap, si);
pkt = (const struct cpl_rx_pkt *)rsp;
- csum_ok = pkt->csum_calc && !pkt->err_vec &&
+ /* Compressed error vector is enabled for T6 only */
+ if (q->adap->params.tp.rx_pkt_encap)
+ err_vec = T6_COMPR_RXERR_VEC_G(be16_to_cpu(pkt->err_vec));
+ else
+ err_vec = be16_to_cpu(pkt->err_vec);
+
+ csum_ok = pkt->csum_calc && !err_vec &&
(q->netdev->features & NETIF_F_RXCSUM);
if ((pkt->l2info & htonl(RXF_TCP_F)) &&
!(cxgb_poll_busy_polling(q)) &&
@@ -2092,7 +2099,12 @@ int t4_ethrx_handler(struct sge_rspq *q, const __be64 *rsp,
if (!(pkt->l2info & cpu_to_be32(CPL_RX_PKT_FLAGS))) {
if ((pkt->l2info & cpu_to_be32(RXF_FCOE_F)) &&
(pi->fcoe.flags & CXGB_FCOE_ENABLED)) {
- if (!(pkt->err_vec & cpu_to_be16(RXERR_CSUM_F)))
+ if (adapter->params.tp.rx_pkt_encap)
+ csum_ok = err_vec &
+ T6_COMPR_RXERR_CSUM_F;
+ else
+ csum_ok = err_vec & RXERR_CSUM_F;
+ if (!csum_ok)
skb->ip_summed = CHECKSUM_UNNECESSARY;
}
}
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
index e813951..cd5f437 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
@@ -7686,6 +7686,13 @@ int t4_init_tp_params(struct adapter *adap)
&adap->params.tp.ingress_config, 1,
TP_INGRESS_CONFIG_A);
}
+ /* For T6, cache the adapter's compressed error vector
+ * and passing outer header info for encapsulated packets.
+ */
+ if (CHELSIO_CHIP_VERSION(adap->params.chip) > CHELSIO_T5) {
+ v = t4_read_reg(adap, TP_OUT_CONFIG_A);
+ adap->params.tp.rx_pkt_encap = (v & CRXPKTENC_F) ? 1 : 0;
+ }
/* Now that we have TP_VLAN_PRI_MAP cached, we can calculate the field
* shift positions of several elements of the Compressed Filter Tuple
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4_msg.h b/drivers/net/ethernet/chelsio/cxgb4/t4_msg.h
index fba3b2a..5ca38e0 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4_msg.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4_msg.h
@@ -1162,6 +1162,16 @@ struct cpl_rx_pkt {
#define RXERR_CSUM_V(x) ((x) << RXERR_CSUM_S)
#define RXERR_CSUM_F RXERR_CSUM_V(1U)
+#define T6_COMPR_RXERR_LEN_S 1
+#define T6_COMPR_RXERR_LEN_V(x) ((x) << T6_COMPR_RXERR_LEN_S)
+#define T6_COMPR_RXERR_LEN_F T6_COMPR_RXERR_LEN_V(1U)
+
+#define T6_COMPR_RXERR_VEC_S 0
+#define T6_COMPR_RXERR_VEC_M 0x3F
+#define T6_COMPR_RXERR_VEC_V(x) ((x) << T6_COMPR_RXERR_LEN_S)
+#define T6_COMPR_RXERR_VEC_G(x) \
+ (((x) >> T6_COMPR_RXERR_VEC_S) & T6_COMPR_RXERR_VEC_M)
+
struct cpl_trace_pkt {
u8 opcode;
u8 intf;
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4_regs.h b/drivers/net/ethernet/chelsio/cxgb4/t4_regs.h
index 9fea255..e685163 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4_regs.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4_regs.h
@@ -1276,6 +1276,10 @@
#define DBGLARPTR_M 0x7fU
#define DBGLARPTR_V(x) ((x) << DBGLARPTR_S)
+#define CRXPKTENC_S 3
+#define CRXPKTENC_V(x) ((x) << CRXPKTENC_S)
+#define CRXPKTENC_F CRXPKTENC_V(1U)
+
#define TP_DBG_LA_DATAL_A 0x7ed8
#define TP_DBG_LA_CONFIG_A 0x7ed4
#define TP_OUT_CONFIG_A 0x7d04
--
2.1.0
^ permalink raw reply related
* [PATCH] cxgb4/cxgb4vf: Assign netdev->dev_port with port ID
From: Ganesh Goudar @ 2016-12-08 12:39 UTC (permalink / raw)
To: netdev, davem
Cc: nirranjan, Arjun V, Casey Leedom, Hariprasad Shenai,
Ganesh Goudar
From: Arjun V <arjun@chelsio.com>
Added missing dev_port assignment in cxgb4vf driver.
Also made dev_port assignment of cxgb4 in sync with cxgb4vf driver.
Signed-off-by: Casey Leedom <leedom@chelsio.com>
Signed-off-by: Arjun V <arjun@chelsio.com>
Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 1 +
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 1 -
drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c | 1 +
3 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index 48113c6..66c37fa 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -4921,6 +4921,7 @@ static int init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
*/
for_each_port(adapter, i) {
pi = adap2pinfo(adapter, i);
+ adapter->port[i]->dev_port = pi->lport;
netif_set_real_num_tx_queues(adapter->port[i], pi->nqsets);
netif_set_real_num_rx_queues(adapter->port[i], pi->nqsets);
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
index 20dec85..e813951 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
@@ -7851,7 +7851,6 @@ int t4_port_init(struct adapter *adap, int mbox, int pf, int vf)
return ret;
memcpy(adap->port[i]->dev_addr, addr, ETH_ALEN);
- adap->port[i]->dev_port = j;
j++;
}
return 0;
diff --git a/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c b/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c
index fa43e06d..0d1a134 100644
--- a/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c
@@ -2960,6 +2960,7 @@ static int cxgb4vf_pci_probe(struct pci_dev *pdev,
netdev->netdev_ops = &cxgb4vf_netdev_ops;
netdev->ethtool_ops = &cxgb4vf_ethtool_ops;
+ netdev->dev_port = pi->port_id;
/*
* Initialize the hardware/software state for the port.
--
2.1.0
^ permalink raw reply related
* Re: [PATCH] sh_eth: add wake-on-lan support via magic packet
From: Sergei Shtylyov @ 2016-12-08 12:28 UTC (permalink / raw)
To: Niklas Söderlund, Simon Horman, netdev, linux-renesas-soc
In-Reply-To: <20161207162843.4731-1-niklas.soderlund+renesas@ragnatech.se>
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.
> @@ -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...
> + /* Handle MagicPacket interrupt */
> + if (sh_eth_read(ndev, ECSR) & ECSR_MPD)
Why do it here?
> + 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.
> + 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?
> + 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...
> +
> + 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?
> +
> + 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...
> 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
^ permalink raw reply
* [PATCH] net: gianfar: add ethtool eee support
From: Shaohui Xie @ 2016-12-08 11:27 UTC (permalink / raw)
To: netdev, davem; +Cc: Shaohui Xie
Gianfar does not support EEE, but it can connect to a PHY which supports
EEE and the PHY advertises EEE by default, and its link partner also
advertises EEE, so the PHY enters low power mode when traffic rate is low,
which causes packet loss if an application's traffic rate is low. This
patch provides .get_eee and .set_eee so that to disable the EEE
advertisement via ethtool if needed, other EEE features are not supported.
Signed-off-by: Shaohui Xie <Shaohui.Xie@nxp.com>
---
drivers/net/ethernet/freescale/gianfar_ethtool.c | 28 ++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/drivers/net/ethernet/freescale/gianfar_ethtool.c b/drivers/net/ethernet/freescale/gianfar_ethtool.c
index 56588f2..9375078 100644
--- a/drivers/net/ethernet/freescale/gianfar_ethtool.c
+++ b/drivers/net/ethernet/freescale/gianfar_ethtool.c
@@ -184,6 +184,32 @@ static void gfar_gdrvinfo(struct net_device *dev,
strlcpy(drvinfo->bus_info, "N/A", sizeof(drvinfo->bus_info));
}
+static int gfar_get_eee(struct net_device *dev, struct ethtool_eee *et_eee)
+{
+ struct phy_device *phydev = dev->phydev;
+
+ if (!phydev)
+ return -ENODEV;
+
+ return phy_ethtool_get_eee(phydev, et_eee);
+}
+
+static int gfar_set_eee(struct net_device *dev, struct ethtool_eee *et_eee)
+{
+ struct phy_device *phydev = dev->phydev;
+
+ if (!phydev)
+ return -ENODEV;
+
+ if (et_eee->eee_enabled ||
+ et_eee->tx_lpi_enabled ||
+ et_eee->tx_lpi_timer) {
+ return -EOPNOTSUPP;
+ }
+
+ return phy_ethtool_set_eee(phydev, et_eee);
+}
+
/* Return the length of the register structure */
static int gfar_reglen(struct net_device *dev)
{
@@ -1548,6 +1574,8 @@ const struct ethtool_ops gfar_ethtool_ops = {
.get_strings = gfar_gstrings,
.get_sset_count = gfar_sset_count,
.get_ethtool_stats = gfar_fill_stats,
+ .get_eee = gfar_get_eee,
+ .set_eee = gfar_set_eee,
.get_msglevel = gfar_get_msglevel,
.set_msglevel = gfar_set_msglevel,
#ifdef CONFIG_PM
--
2.1.0.27.g96db324
^ permalink raw reply related
* Re: [PATCH net-next] openvswitch: fix VxLAN-gpe port can't be created in ovs compat mode
From: Yang, Yi @ 2016-12-08 12:01 UTC (permalink / raw)
To: Jiri Benc; +Cc: dev-yBygre7rU0TnMu66kgdUjQ, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161208123756.204af819@griffin>
On Thu, Dec 08, 2016 at 12:37:56PM +0100, Jiri Benc wrote:
> On Thu, 8 Dec 2016 18:57:51 +0800, Yang, Yi wrote:
> > So ovs out of tree modules need to adapt to upstream kernel, any
> > kernel-related changes must be accepted by Linux kernel at first.
>
> I'm perfectly aware of that and I'm saying that your patch is
> unacceptable for upstream kernel. This is a long standing policy of the
> kernel: there's no way you can get a patch into the kernel to
> accommodate an out of tree kernel module. The policy is there for good
> reasons and as paradoxical as it may sound, it benefits the projects
> that employ out of tree modules in the long run.
>
> If Open vSwitch wants to carry a non-upstream patch, it's its choice
> and we can have that discussion but that's not something to discuss on
> netdev@vger nor propose for net-next.
>
Jiri, according to your statement, we have to switch Linux 4.7 or above
if we want to use ovs VxLAN-gpe, Ubuntu 16.04 has had new kernel, but it
just use Linux kernel 4.4, you know Linux distributuions nerver uses the
latest stable Linux kernel because they have their own patches to
maintain, that will be a nightmare if they take the latest stable
kernel. You know RHEL also follows the same philosophy.
Current ovs master can be built on Ubuntu 14.04 which have Linux kernel
3.13, I think compatibility backward is very important, out of tree
modules are very important to ovs. If ovs installation will depend on
the latest kernel and force users to switch to new kernel, I believe it
nerver will be so popular in the industies.
^ permalink raw reply
* Re: [PATCH net-next] openvswitch: fix VxLAN-gpe port can't be created in ovs compat mode
From: Jiri Benc @ 2016-12-08 11:37 UTC (permalink / raw)
To: Yang, Yi; +Cc: dev-yBygre7rU0TnMu66kgdUjQ, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161208105750.GA14898-re2EX8HDrk21gSHoDXDV2kEOCMrvLtNR@public.gmane.org>
On Thu, 8 Dec 2016 18:57:51 +0800, Yang, Yi wrote:
> So ovs out of tree modules need to adapt to upstream kernel, any
> kernel-related changes must be accepted by Linux kernel at first.
I'm perfectly aware of that and I'm saying that your patch is
unacceptable for upstream kernel. This is a long standing policy of the
kernel: there's no way you can get a patch into the kernel to
accommodate an out of tree kernel module. The policy is there for good
reasons and as paradoxical as it may sound, it benefits the projects
that employ out of tree modules in the long run.
If Open vSwitch wants to carry a non-upstream patch, it's its choice
and we can have that discussion but that's not something to discuss on
netdev@vger nor propose for net-next.
Jiri
^ permalink raw reply
* Re: [PATCH] linux/types.h: enable endian checks for all sparse builds
From: Cornelia Huck @ 2016-12-08 11:25 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: kvm, Neil Armstrong, David Airlie, linux-remoteproc, dri-devel,
virtualization, linux-s390, James E.J. Bottomley, Herbert Xu,
linux-scsi, Christoph Hellwig, v9fs-developer, Asias He,
Arnd Bergmann, linux-kbuild, Jens Axboe, Michal Marek,
Stefan Hajnoczi, Matt Mackall, Greg Kroah-Hartman, linux-kernel,
linux-crypto, netdev, Linus Torvalds, David S. Miller
In-Reply-To: <1481164052-28036-1-git-send-email-mst@redhat.com>
On Thu, 8 Dec 2016 04:29:39 +0200
"Michael S. Tsirkin" <mst@redhat.com> wrote:
> By now, linux is mostly endian-clean. Enabling endian-ness
> checks for everyone produces about 200 new sparse warnings for me -
> less than 10% over the 2000 sparse warnings already there.
Out of curiousity: Where do most of those warnings show up?
>
> Not a big deal, OTOH enabling this helps people notice
> they are introducing new bugs.
>
> So let's just drop __CHECK_ENDIAN__. Follow-up patches
> can drop distinction between __bitwise and __bitwise__.
>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Suggested-by: Christoph Hellwig <hch@infradead.org>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> ---
>
> Linus, could you ack this for upstream? If yes I'll
> merge through my tree as a replacement for enabling
> this just for virtio.
>
> include/uapi/linux/types.h | 4 ----
> 1 file changed, 4 deletions(-)
>
> diff --git a/include/uapi/linux/types.h b/include/uapi/linux/types.h
> index acf0979..41e5914 100644
> --- a/include/uapi/linux/types.h
> +++ b/include/uapi/linux/types.h
> @@ -23,11 +23,7 @@
> #else
> #define __bitwise__
> #endif
> -#ifdef __CHECK_ENDIAN__
> #define __bitwise __bitwise__
> -#else
> -#define __bitwise
> -#endif
>
> typedef __u16 __bitwise __le16;
> typedef __u16 __bitwise __be16;
FWIW, I like this better than just enabling it for the virtio code.
^ permalink raw reply
* [PATCH] drivers: net: xgene: initialize slots
From: Colin King @ 2016-12-08 11:17 UTC (permalink / raw)
To: Iyappan Subramanian, Keyur Chudgar, netdev; +Cc: linux-kernel
From: Colin Ian King <colin.king@canonical.com>
static analysis using cppcheck detected that slots was uninitialized.
Fix this by initializing it to buf_pool->slots - 1
Found using static analysis with CoverityScan, CID #1387620
Fixes: a9380b0f7be818 ("drivers: net: xgene: Add support for Jumbo frame")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/ethernet/apm/xgene/xgene_enet_main.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_main.c b/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
index 6c7eea8..899163c 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
@@ -636,6 +636,7 @@ static void xgene_enet_free_pagepool(struct xgene_enet_desc_ring *buf_pool,
dev = ndev_to_dev(buf_pool->ndev);
head = buf_pool->head;
+ slots = buf_pool->slots - 1;
for (i = 0; i < 4; i++) {
frag_size = xgene_enet_get_data_len(le64_to_cpu(desc[i ^ 1]));
--
2.10.2
^ permalink raw reply related
* netlink: GPF in netlink_dump
From: Dmitry Vyukov @ 2016-12-08 11:14 UTC (permalink / raw)
To: David Miller, Matti Vaittinen, Tycho Andersen, stephen hemminger,
Cong Wang, Florian Westphal, netdev, LKML, Eric Dumazet
Cc: syzkaller
Hello,
The following program triggers GPF in netlink_dump:
// autogenerated by syzkaller (http://github.com/google/syzkaller)
#include <unistd.h>
#include <sys/syscall.h>
#include <sys/uio.h>
int main()
{
syscall(__NR_mmap, 0x20000000ul, 0xd25000ul, 0x3ul, 0x32ul, -1, 0);
int fd = syscall(__NR_socket, 0x10ul, 0x3ul, 0x10ul);
struct iovec iov;
iov.iov_base = "\x16\x00\x00\x00\x23\x00\x19\x07\x00\x00\x00\x46"
"\xf1\xff\xff\xe8\x03\x00\x04\xff\xff\x75";
iov.iov_len = 22;
syscall(__NR_writev, fd, &iov, 1);
return 0;
}
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN
Modules linked in:
CPU: 0 PID: 6913 Comm: a.out Not tainted 4.9.0-rc7+ #76
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: ffff88006716a840 task.stack: ffff880063a38000
RIP: 0010:[<ffffffff81567f65>] [<ffffffff81567f65>]
__lock_acquire+0xb35/0x3380 kernel/locking/lockdep.c:3221
RSP: 0018:ffff880063a3e578 EFLAGS: 00010006
RAX: dffffc0000000000 RBX: dffffc0000000000 RCX: 0000000000000000
RDX: 000000000000000c RSI: 0000000000000000 RDI: 1ffff1000c747d09
RBP: ffff880063a3eab0 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000060 R11: 0000000000000000 R12: ffff88006716a840
R13: 0000000000000001 R14: ffffffff8baba1a0 R15: 0000000000000001
FS: 000000000082a880(0000) GS:ffff88003ec00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000004b20e0 CR3: 000000003dd5d000 CR4: 00000000000006f0
Stack:
ffff88006716b060 ffff880063a3e5f0 ffff88006716b088 0000000041b58ab3
ffffffff894ee650 ffffffff81562600 ffff88006716b058 ffff880063a3e930
00000000894d005b 1ffff1000c747cbe 0000000100000000 ffffffff81557640
Call Trace:
[<ffffffff8156b682>] lock_acquire+0x2a2/0x790 kernel/locking/lockdep.c:3746
[< inline >] __mutex_lock_common kernel/locking/mutex.c:521
[<ffffffff88193a3f>] mutex_lock_nested+0x23f/0xf20 kernel/locking/mutex.c:621
[<ffffffff86cb2228>] netlink_dump+0xd8/0xd70 net/netlink/af_netlink.c:2067
[<ffffffff86cb6e8a>] __netlink_dump_start+0x4ea/0x760
net/netlink/af_netlink.c:2200
[<ffffffff86cc12e7>] genl_family_rcv_msg+0xa77/0x1070
net/netlink/genetlink.c:597
[<ffffffff86cc1a90>] genl_rcv_msg+0x1b0/0x260 net/netlink/genetlink.c:660
[<ffffffff86cbf66c>] netlink_rcv_skb+0x2bc/0x3a0 net/netlink/af_netlink.c:2281
[<ffffffff86cc085d>] genl_rcv+0x2d/0x40 net/netlink/genetlink.c:671
[< inline >] netlink_unicast_kernel net/netlink/af_netlink.c:1214
[<ffffffff86cbde8a>] netlink_unicast+0x51a/0x740 net/netlink/af_netlink.c:1240
[<ffffffff86cbeb54>] netlink_sendmsg+0xaa4/0xe50 net/netlink/af_netlink.c:1786
[< inline >] sock_sendmsg_nosec net/socket.c:621
[<ffffffff86a7517f>] sock_sendmsg+0xcf/0x110 net/socket.c:631
[<ffffffff86a754eb>] sock_write_iter+0x32b/0x620 net/socket.c:829
[<ffffffff81a6ef33>] do_iter_readv_writev+0x363/0x670 fs/read_write.c:695
[<ffffffff81a71981>] do_readv_writev+0x431/0x9b0 fs/read_write.c:872
[<ffffffff81a724bc>] vfs_writev+0x8c/0xc0 fs/read_write.c:911
[<ffffffff81a72605>] do_writev+0x115/0x2d0 fs/read_write.c:944
[< inline >] SYSC_writev fs/read_write.c:1017
[<ffffffff81a75dbc>] SyS_writev+0x2c/0x40 fs/read_write.c:1014
[<ffffffff881a3d05>] entry_SYSCALL_64_fastpath+0x23/0xc6
arch/x86/entry/entry_64.S:209
Code: e9 03 f3 48 ab 48 81 c4 10 05 00 00 44 89 e8 5b 41 5c 41 5d 41
5e 41 5f 5d c3 4c 89 d2 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80>
3c 02 00 0f 85 00 26 00 00 49 81 3a c0 64 e2 8a 41 bf 00 00
RIP [<ffffffff81567f65>] __lock_acquire+0xb35/0x3380
kernel/locking/lockdep.c:3221
RSP <ffff880063a3e578>
---[ end trace 8d9cfd5e00f7ff0c ]---
==================================================================
On commit 2caceb3294a78c389b462e7e236a4e744a53a474 (Dec 1).
^ permalink raw reply
* Re: [PATCH] linux/types.h: enable endian checks for all sparse builds
From: Greg Kroah-Hartman @ 2016-12-08 11:13 UTC (permalink / raw)
To: Bart Van Assche
Cc: kvm@vger.kernel.org, Michael S. Tsirkin, David Airlie,
linux-remoteproc@vger.kernel.org, dri-devel@lists.freedesktop.org,
virtualization@lists.linux-foundation.org,
linux-s390@vger.kernel.org, James E.J. Bottomley, Herbert Xu,
linux-scsi@vger.kernel.org, Neil Armstrong, Christoph Hellwig,
v9fs-developer@lists.sourceforge.net, Asias He, Arnd Bergmann,
linux-kbuild@vger.kernel.org, Jens Axboe, Michal Marek <
In-Reply-To: <BLUPR02MB168304F8FBA50C916A6A4E6081840@BLUPR02MB1683.namprd02.prod.outlook.com>
On Thu, Dec 08, 2016 at 06:38:11AM +0000, Bart Van Assche wrote:
> On 12/07/16 21:54, Michael S. Tsirkin wrote:
> > On Thu, Dec 08, 2016 at 05:21:47AM +0000, Bart Van Assche wrote:
> >> Additionally, there are notable exceptions to the rule that most drivers
> >> are endian-clean, e.g. drivers/scsi/qla2xxx. I would appreciate it if it
> >> would remain possible to check such drivers with sparse without enabling
> >> endianness checks. Have you considered to change #ifdef __CHECK_ENDIAN__
> >> into e.g. #ifndef __DONT_CHECK_ENDIAN__?
> >
> > The right thing is probably just to fix these, isn't it?
> > Until then, why not just ignore the warnings?
>
> Neither option is realistic. With endian-checking enabled the qla2xxx
> driver triggers so many warnings that it becomes a real challenge to
> filter the non-endian warnings out manually:
>
> $ for f in "" CF=-D__CHECK_ENDIAN__; do make M=drivers/scsi/qla2xxx C=2\
> $f | &grep -c ': warning:'; done
> 4
> 752
>
> If you think it would be easy to fix the endian warnings triggered by
> the qla2xxx driver, you are welcome to try to fix these.
Please don't let one crappy, obviously broken, driver prevent this good
change from happening which will help ensure that the rest of the kernel
(i.e. 99% of it) can be easily tested and fixed for endian issues.
Sounds like you should just fix the driver up if it has so many
problems, and it annoys you so much that you have to filter out some
warnings to see the others :)
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH net-next] openvswitch: fix VxLAN-gpe port can't be created in ovs compat mode
From: Yang, Yi @ 2016-12-08 10:57 UTC (permalink / raw)
To: Jiri Benc; +Cc: netdev, dev, pshelar
In-Reply-To: <20161208095401.3e4054c9@griffin>
On Thu, Dec 08, 2016 at 09:54:00AM +0100, Jiri Benc wrote:
> On Thu, 8 Dec 2016 16:20:10 +0800, Yi Yang wrote:
> > In ovs compat mode, ovs won't use LWT in current kernel, this is to
> > make sure ovs can work on the old kernels, Linux kernel v4.7 includes
> > VxLAN-gpe support but many Linux distributions' kernels are odler than
> > v4.7, this fix will ensure that ovs can create VxLAN-gpe port correctly
> > on old kernels, it has been verified on Ubuntu 16.04 x86_64 with Linux
> > kernel 4.4.0-53-generic.
>
> NAK. We do have a way to configure this and that's rtnetlink. Open
> vSwitch should use that to configure tunnels. Out of tree modules are
> on their own. Upstream kernel does not accommodate out of tree modules.
>
Jiri, this has used rtnetlink to confgiure, te below is my test code in ovs.
As Pravin mentioned, in compat mode, ovs won't use current in-kernel
module which is vxlan in upstream kernel, but ovs has its own vport_vxlan
module for this, it has different behaviour from LWT in upstream kernel.
If you try this in the kernels below v4.7, you will clearly know this.
ovs will port this patch into the below files in ovs soure code
datapath/linux/compat/include/linux/openvswitch.h and datapath/vport-vxlan.c once it is accepted,this is ovs upstream process, if Linux kernel doesn't include this, ovs won't accept it.
So ovs out of tree modules need to adapt to upstream kernel, any
kernel-related changes must be accepted by Linux kernel at first. Pravin
is a dedicated person doing such work, your L3 patches merged into
net-next will be ported into ovs out of tree modules by Pravin in the
same way.
diff --git a/lib/dpif-netlink.c b/lib/dpif-netlink.c
index 0d03334..7d8a0f4 100644
--- a/lib/dpif-netlink.c
+++ b/lib/dpif-netlink.c
@@ -1006,7 +1006,11 @@ netdev_vxlan_create(struct netdev *netdev)
nl_msg_put_string(&request, IFLA_IFNAME, name);
nl_msg_put_u32(&request, IFLA_MTU, UINT16_MAX);
linkinfo_off = nl_msg_start_nested(&request, IFLA_LINKINFO);
+#ifdef USE_UPSTREAM_TUNNEL
nl_msg_put_string(&request, IFLA_INFO_KIND, "vxlan");
+#else
+ nl_msg_put_string(&request, IFLA_INFO_KIND, "ovs_vxlan");
+#endif
infodata_off = nl_msg_start_nested(&request, IFLA_INFO_DATA);
nl_msg_put_u8(&request, IFLA_VXLAN_LEARNING, 0);
nl_msg_put_u8(&request, IFLA_VXLAN_COLLECT_METADATA, 1);
^ permalink raw reply related
* Re: [PATCH v3 1/6] net: stmmac: return error if no DMA configuration is found
From: Alexandre Torgue @ 2016-12-08 10:44 UTC (permalink / raw)
To: Niklas Cassel, Giuseppe Cavallaro; +Cc: Niklas Cassel, netdev, linux-kernel
In-Reply-To: <1481120409-18103-2-git-send-email-niklass@axis.com>
Hi Niklas,
On 12/07/2016 03:20 PM, Niklas Cassel wrote:
> From: Niklas Cassel <niklas.cassel@axis.com>
>
> All drivers except pci glue layer calls stmmac_probe_config_dt.
> stmmac_probe_config_dt does a kzalloc dma_cfg.
>
> pci glue layer does kzalloc dma_cfg explicitly, so all current
> drivers does a kzalloc dma_cfg.
>
> Return an error if no DMA configuration is found, that way
> we can assume that the DMA configuration always exists.
>
> Signed-off-by: Niklas Cassel <niklas.cassel@axis.com>
Acked-by: Alexandre Torgue <alexandre.torgue@stcom>
> ---
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 18 +++++++++---------
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index 982c95213da4..14366800e5e6 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -1578,16 +1578,12 @@ static void stmmac_check_ether_addr(struct stmmac_priv *priv)
> */
> static int stmmac_init_dma_engine(struct stmmac_priv *priv)
> {
> - int pbl = DEFAULT_DMA_PBL, fixed_burst = 0, aal = 0;
> - int mixed_burst = 0;
> int atds = 0;
> int ret = 0;
>
> - if (priv->plat->dma_cfg) {
> - pbl = priv->plat->dma_cfg->pbl;
> - fixed_burst = priv->plat->dma_cfg->fixed_burst;
> - mixed_burst = priv->plat->dma_cfg->mixed_burst;
> - aal = priv->plat->dma_cfg->aal;
> + if (!priv->plat->dma_cfg) {
> + dev_err(priv->device, "DMA configuration not found\n");
> + return -EINVAL;
> }
>
> if (priv->extend_desc && (priv->mode == STMMAC_RING_MODE))
> @@ -1599,8 +1595,12 @@ static int stmmac_init_dma_engine(struct stmmac_priv *priv)
> return ret;
> }
>
> - priv->hw->dma->init(priv->ioaddr, pbl, fixed_burst, mixed_burst,
> - aal, priv->dma_tx_phy, priv->dma_rx_phy, atds);
> + priv->hw->dma->init(priv->ioaddr,
> + priv->plat->dma_cfg->pbl,
> + priv->plat->dma_cfg->fixed_burst,
> + priv->plat->dma_cfg->mixed_burst,
> + priv->plat->dma_cfg->aal,
> + priv->dma_tx_phy, priv->dma_rx_phy, atds);
>
> if (priv->synopsys_id >= DWMAC_CORE_4_00) {
> priv->rx_tail_addr = priv->dma_rx_phy +
>
^ 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