* [PATCH net-net 0/4] Increase the limit of tuntap queues
From: Pankaj Gupta @ 2014-11-18 16:22 UTC (permalink / raw)
To: linux-kernel, netdev
Cc: davem, jasowang, mst, dgibson, vfalico, edumazet, vyasevic, hkchu,
wuzhy, xemul, therbert, bhutchings, xii, stephen, jiri,
sergei.shtylyov, Pankaj Gupta
This patch series is followup to the RFC posted as:
https://lkml.org/lkml/2014/8/18/392
Changes from RFC are:
PATCH 1: Sergei Shtylyov - Add an empty line after declarations.
PATCH 2: Jiri Pirko - Do not introduce new module paramaters.
Michael.S.Tsirkin - We can use sysctl for limiting max number
of queues.
Networking under KVM works best if we allocate a per-vCPU rx and tx
queue in a virtual NIC. This requires a per-vCPU queue on the host side.
Modern physical NICs have multiqueue support for large number of queues.
To scale vNIC to run multiple queues parallel to maximum number of vCPU's
we need to increase number of queues support in tuntap.
This series is to increase the limit of tuntap queues. Original work is being
done by 'jasowang@redhat.com'. I am taking this 'https://lkml.org/lkml/2013/6/19/29'
patch series as a reference. As per discussion in the patch series:
There were two reasons which prevented us from increasing number of tun queues:
- The netdev_queue array in netdevice were allocated through kmalloc, which may
cause a high order memory allocation too when we have several queues.
E.g. sizeof(netdev_queue) is 320, which means a high order allocation would
happens when the device has more than 16 queues.
- We store the hash buckets in tun_struct which results a very large size of
tun_struct, this high order memory allocation fail easily when the memory is
fragmented.
The patch 60877a32bce00041528576e6b8df5abe9251fa73 increases the number of tx
queues. Memory allocation fallback to vzalloc() when kmalloc() fails.
This series tries to address following issues:
- Increase the number of netdev_queue queues for rx similarly its done for tx
queues by falling back to vzalloc() when memory allocation with kmalloc() fails.
- Switches to use flex array to implement the flow caches to avoid higher order
allocations.
- Accept maximum number of queues as sysctl param so that any user space
application like libvirt can use this value to limit number of queues. Also
Administrators can specify maximum number of queues by updating this sysctl
entry.
- Increase number of queues to 256, maximum number is equal to maximum number
of vCPUS allowed in a guest.
I have done some testing to find out any regression and with sample program
which creates tun/tap for single queue / multiqueue device and it seems to be
working fine. I will also post the performance numbers.
tuntap: Increase the number of queues in tun
tuntap: Reduce the size of tun_struct by using flex array
tuntap: Accept tuntap max queue length as sysctl entry
net: allow large number of rx queues
drivers/net/tun.c | 91 +++++++++++++++++++++++++++++++++++---------
net/core/dev.c | 19 ++++++---
2 files changed, 86 insertions(+), 24 deletions(-)
^ permalink raw reply
* Re: [PATCH 1/1 net-next] wireless: remove unnecessary sizeof(u8)
From: Larry Finger @ 2014-11-18 16:12 UTC (permalink / raw)
To: Gheorhios, John W. Linville
Cc: Fabian Frederick, Emmanuel Grumbach, Stefano Brivio,
Johannes Berg, Julian Calaby, linux-wireless,
linux-kernel@vger.kernel.org, Intel Linux Wireless, Chaoming Li,
b43-dev, netdev
In-Reply-To: <CAFpvzpxYrjR_tSF99iosMGZTAmt=_6o_aA+iYjNhxRGJ9aJ6oA@mail.gmail.com>
On 11/18/2014 07:34 AM, Gheorhios wrote:
> Anyone could gently send the link for downloading B43 linux drivers for
> this procedure?
>
>
>
> Then transfer it over to your Ubuntu box.
>
> Now in your Ubuntu Box [computer] please make your way to your Home folder.
>
> Once you are at your home folder right click on your home folder and make a
> new folder and call it wireless.
>
> Now that you have made a new folder called wireless in your home directory,
> it is time to move the downloaded file into the new folder called wireless.
>
> Move The Wireless Folder To The Firmware Directory
>
> sudo cp -r ~/wireless/* /lib/firmware/
>
> Now let's double check to make sure the download made it to the firmware
> directory. To do this type this into the terminal:
>
> ls /lib/firmware
>
> Ok so now that the download is in the firmware directory we need to go to
> that directory. To go there open your terminal and type in:
>
> cd /lib/firmware
>
> Now that you have changed directories let's double check to make sure you
> are in the right directory, this next code tells us where we are in the
> computer file directory. This next code stands for "print working
> directory".
>
> pwd
>
> Are you at /lib/firmware if so good if not go back one step.
>
> Now that we are in the firmware directory. We have to extract the download,
> to do this type in:
>
> sudo -s
>
> Then enter your password then:
>
> tar xvf b43-all-fw.tar_.gz
>
> Now is the firmware extracted properly? check by typing:
>
> ls /lib/firmware/b43
>
> or:
>
> ls /lib/firmware/b43legacy
>
> Do you see the ucode files? if so then delete the gz file:
>
> sudo rm *.gz
>
> Then:
>
> exit
>
> Reboot
No, I do not know where that file is found. Even if I knew of such a file,
Broadcom has expressly declined to provide that firmware for redistribution.
Posting such a file could invite legal action. If someone else has violated
Broadcom's directive, I would not facilitate that violation.
Rather than doing that, the link at
http://wireless.kernel.org/en/users/Drivers/b43#firmwareinstallation shows what
to do for Ubuntu installations. Follow those instructions - they refer to a
legal way to get the firmware. I would have thought that asking this question on
an Ubuntu Forum would have been more productive.
By the way, piggybacking your request on this thread is very bad netiquette. You
should not have done a "reply-to".
Larry
^ permalink raw reply
* Re: [PATCH] usbnet: rtl8150: remove unused variable
From: Petko Manolov @ 2014-11-18 15:30 UTC (permalink / raw)
To: Sudip Mukherjee; +Cc: linux-usb, netdev, linux-kernel
In-Reply-To: <1416315599-16939-1-git-send-email-sudipm.mukherjee@gmail.com>
On 14-11-18 18:29:59, Sudip Mukherjee wrote:
> we were just returning the initial value of res, instead now
> we are returning the value directly.
Looks OK, but could you please fix the wording of the commit message to something like:
Remove unused variable.
This is a tiny patch and the code speaks for itself.
Petko
> Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
> ---
> drivers/net/usb/rtl8150.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/net/usb/rtl8150.c b/drivers/net/usb/rtl8150.c
> index 6e87e57..d37b7dc 100644
> --- a/drivers/net/usb/rtl8150.c
> +++ b/drivers/net/usb/rtl8150.c
> @@ -753,14 +753,13 @@ static int rtl8150_open(struct net_device *netdev)
> static int rtl8150_close(struct net_device *netdev)
> {
> rtl8150_t *dev = netdev_priv(netdev);
> - int res = 0;
>
> netif_stop_queue(netdev);
> if (!test_bit(RTL8150_UNPLUG, &dev->flags))
> disable_net_traffic(dev);
> unlink_all_urbs(dev);
>
> - return res;
> + return 0;
> }
>
> static void rtl8150_get_drvinfo(struct net_device *netdev, struct ethtool_drvinfo *info)
> --
> 1.8.1.2
>
^ permalink raw reply
* [PATCH net] net/mlx4_en: Add VXLAN ndo calls to the PF net device ops too
From: Or Gerlitz @ 2014-11-18 15:51 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Florian Westphal, Amir Vadai, Saeed Mahameed, Or Gerlitz
This is currently missing, which results in a crash when one attempts
to set VXLAN tunnel over the mlx4_en when acting as PF.
[ 2408.785472] BUG: unable to handle kernel NULL pointer dereference at (null)
[...]
[ 2408.994104] Call Trace:
[ 2408.996584] [<ffffffffa021f7f5>] ? vxlan_get_rx_port+0xd6/0x103 [vxlan]
[ 2409.003316] [<ffffffffa021f71f>] ? vxlan_lowerdev_event+0xf2/0xf2 [vxlan]
[ 2409.010225] [<ffffffffa0630358>] mlx4_en_start_port+0x862/0x96a [mlx4_en]
[ 2409.017132] [<ffffffffa063070f>] mlx4_en_open+0x17f/0x1b8 [mlx4_en]
While here, make sure to invoke vxlan_get_rx_port() only when VXLAN
offloads are actually enabled and not when they are only supported.
Reported-by: Ido Shamay <idos@mellanox.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
index c5fcc56..4d69e38 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
@@ -1693,7 +1693,7 @@ int mlx4_en_start_port(struct net_device *dev)
mlx4_set_stats_bitmap(mdev->dev, &priv->stats_bitmap);
#ifdef CONFIG_MLX4_EN_VXLAN
- if (priv->mdev->dev->caps.flags2 & MLX4_DEV_CAP_FLAG2_VXLAN_OFFLOADS)
+ if (priv->mdev->dev->caps.tunnel_offload_mode == MLX4_TUNNEL_OFFLOAD_MODE_VXLAN)
vxlan_get_rx_port(dev);
#endif
priv->port_up = true;
@@ -2422,6 +2422,11 @@ static const struct net_device_ops mlx4_netdev_ops_master = {
.ndo_rx_flow_steer = mlx4_en_filter_rfs,
#endif
.ndo_get_phys_port_id = mlx4_en_get_phys_port_id,
+#ifdef CONFIG_MLX4_EN_VXLAN
+ .ndo_add_vxlan_port = mlx4_en_add_vxlan_port,
+ .ndo_del_vxlan_port = mlx4_en_del_vxlan_port,
+ .ndo_gso_check = mlx4_en_gso_check,
+#endif
};
int mlx4_en_init_netdev(struct mlx4_en_dev *mdev, int port,
--
1.7.1
^ permalink raw reply related
* Re: [PATCH 0/4] Add lightweight memory barriers fast_rmb() and fast_wmb()
From: Alexander Duyck @ 2014-11-18 15:44 UTC (permalink / raw)
To: David Laight, linux-arch@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Cc: mathieu.desnoyers@polymtl.ca, peterz@infradead.org,
benh@kernel.crashing.org, heiko.carstens@de.ibm.com,
mingo@kernel.org, mikey@neuling.org, linux@arm.linux.org.uk,
donald.c.skidmore@intel.com, matthew.vick@intel.com,
geert@linux-m68k.org, jeffrey.t.kirsher@intel.com,
romieu@fr.zoreil.com, paulmck@linux.vnet.ibm.com,
nic_swsd@realtek.com, will.deacon@arm.com, michael@ellerman.id.au,
tony.luck@intel.com, "torvalds@li
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D1C9F2930@AcuExch.aculab.com>
On 11/18/2014 01:57 AM, David Laight wrote:
> From: Alexander Duyck
>> These patches introduce two new primitives for synchronizing cache-enabled
>> memory writes and reads. These two new primitives are:
>>
>> fast_rmb()
>> fast_wmb()
> Not sure I like the names.
> If the aim is to sync data into the local cache so that hardware
> that is doing cache-snooping accesses sees the data then maybe
> local_rmb() and local_wmb()
Yeah, that is the general consensus. I am planning to change them to
coherent_rmb() and coherent_wmb().
> IIRC read_barrier_depends() is a nop on everything except alpha.
> Maybe add the default if it isn't defined by the MD file?
>
> David
>
From my patch the only two I saw define it were alpha and blackfin. It
is already defined in asm-generic, the rest is just clean-up since I
suspect some of the arch tree barrier.h calls just borrowed from
asm-generic without sorting out what became redundancies.
Thanks,
Alex
^ permalink raw reply
* Re: [PATCH net-next] PPC: bpf_jit_comp: Unify BPF_MOD | BPF_X and BPF_DIV | BPF_X
From: Alexei Starovoitov @ 2014-11-18 15:37 UTC (permalink / raw)
To: Denis Kirjanov
Cc: Michael Ellerman, netdev@vger.kernel.org, Philippe Bergheaud,
linuxppc-dev, Daniel Borkmann
In-Reply-To: <CAOJe8K0_u51QkKmVoVmFuGaDtKfcHP6tSWx_fgJM_erRRoQfUA@mail.gmail.com>
On Mon, Nov 17, 2014 at 10:58 PM, Denis Kirjanov <kda@linux-powerpc.org> wrote:
> Hi Michael,
>
> This patch added no new functionality so I haven't put the test
> results (of course I ran the test suite to check the patch).
>
> The output :
> [ 650.198958] test_bpf: Summary: 60 PASSED, 0 FAILED
Acked-by: Alexei Starovoitov <ast@plumgrid.com>
btw, please don't top post.
^ permalink raw reply
* Re: [PATCH net] bonding: fix curr_active_slave/carrier with loadbalance arp monitoring
From: Andy Gospodarek @ 2014-11-18 15:28 UTC (permalink / raw)
To: Veaceslav Falico
Cc: Nikolay Aleksandrov, netdev, davem, Jay Vosburgh, Andy Gospodarek,
Ding Tianhong
In-Reply-To: <20141118143727.GA2643@raspberrypi>
On Tue, Nov 18, 2014 at 03:37:27PM +0100, Veaceslav Falico wrote:
> On Tue, Nov 18, 2014 at 03:14:44PM +0100, Nikolay Aleksandrov wrote:
> >Since commit 6fde8f037e60 ("bonding: fix locking in
> >bond_loadbalance_arp_mon()") we can have a stale bond carrier state and
> >stale curr_active_slave when using arp monitoring in loadbalance modes. The
> >reason is that in bond_loadbalance_arp_mon() we can't have
> >do_failover == true but slave_state_changed == false, whenever do_failover
> >is true then slave_state_changed is also true. Then the following piece
> >from bond_loadbalance_arp_mon():
> > if (slave_state_changed) {
> > bond_slave_state_change(bond);
> > if (BOND_MODE(bond) == BOND_MODE_XOR)
> > bond_update_slave_arr(bond, NULL);
> > } else if (do_failover) {
>
> Ouch, must have been a big PITA to track :).
Agreed!
>
> > block_netpoll_tx();
> > bond_select_active_slave(bond);
> > unblock_netpoll_tx();
> > }
> >
> >will execute only the first branch, always and regardless of do_failover.
> >Since these two events aren't related in such way, we need to decouple and
> >consider them separately.
> >
> >For example this issue could lead to the following result:
> >Bonding Mode: load balancing (round-robin)
> >*MII Status: down*
> >MII Polling Interval (ms): 0
> >Up Delay (ms): 0
> >Down Delay (ms): 0
> >ARP Polling Interval (ms): 100
> >ARP IP target/s (n.n.n.n form): 192.168.9.2
> >
> >Slave Interface: ens12
> >*MII Status: up*
> >Speed: 10000 Mbps
> >Duplex: full
> >Link Failure Count: 2
> >Permanent HW addr: 00:0f:53:01:42:2c
> >Slave queue ID: 0
> >
> >Slave Interface: eth1
> >*MII Status: up*
> >Speed: Unknown
> >Duplex: Unknown
> >Link Failure Count: 70
> >Permanent HW addr: 52:54:00:2f:0f:8e
> >Slave queue ID: 0
> >
> >Since some interfaces are up, then the status of the bond should also be
> >up, but it will never change unless something invokes bond_set_carrier()
> >(i.e. enslave, bond_select_active_slave etc). Now, if I force the
> >calling of bond_select_active_slave via for example changing
> >primary_reselect (it can change in any mode), then the MII status goes to
> >"up" because it calls bond_select_active_slave() which should've been done
> >from bond_loadbalance_arp_mon() itself.
> >
> >CC: Veaceslav Falico <vfalico@gmail.com>
>
> Acked-by: Veaceslav Falico <vfalico@gmail.com>
Acked-by: Andy Gospodarek <gospo@cumulusnetworks.com>
>
> >CC: Jay Vosburgh <j.vosburgh@gmail.com>
> >CC: Andy Gospodarek <andy@greyhouse.net>
> >CC: Ding Tianhong <dingtianhong@huawei.com>
> >
> >Fixes: 6fde8f037e60 ("bonding: fix locking in bond_loadbalance_arp_mon()")
> >Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com>
> >---
> >Note: I left the parent if() the same even though we can shorten it. I think
> > it's better this way since it shows that any of the two events can cause
> > it to enter even though currently we can't have do_failover without
> > slave_state_changed, that may also change in the future.
> >
> >drivers/net/bonding/bond_main.c | 3 ++-
> >1 file changed, 2 insertions(+), 1 deletion(-)
> >
> >diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
> >index c9ac06cfe6b7..a5115fb7cf33 100644
> >--- a/drivers/net/bonding/bond_main.c
> >+++ b/drivers/net/bonding/bond_main.c
> >@@ -2471,7 +2471,8 @@ static void bond_loadbalance_arp_mon(struct work_struct *work)
> > bond_slave_state_change(bond);
> > if (BOND_MODE(bond) == BOND_MODE_XOR)
> > bond_update_slave_arr(bond, NULL);
> >- } else if (do_failover) {
> >+ }
> >+ if (do_failover) {
> > block_netpoll_tx();
> > bond_select_active_slave(bond);
> > unblock_netpoll_tx();
> >--
> >1.9.3
> >
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net] bonding: fix curr_active_slave/carrier with loadbalance arp monitoring
From: Veaceslav Falico @ 2014-11-18 14:37 UTC (permalink / raw)
To: Nikolay Aleksandrov
Cc: netdev, davem, Jay Vosburgh, Andy Gospodarek, Ding Tianhong
In-Reply-To: <1416320084-25339-1-git-send-email-nikolay@redhat.com>
On Tue, Nov 18, 2014 at 03:14:44PM +0100, Nikolay Aleksandrov wrote:
>Since commit 6fde8f037e60 ("bonding: fix locking in
>bond_loadbalance_arp_mon()") we can have a stale bond carrier state and
>stale curr_active_slave when using arp monitoring in loadbalance modes. The
>reason is that in bond_loadbalance_arp_mon() we can't have
>do_failover == true but slave_state_changed == false, whenever do_failover
>is true then slave_state_changed is also true. Then the following piece
>from bond_loadbalance_arp_mon():
> if (slave_state_changed) {
> bond_slave_state_change(bond);
> if (BOND_MODE(bond) == BOND_MODE_XOR)
> bond_update_slave_arr(bond, NULL);
> } else if (do_failover) {
Ouch, must have been a big PITA to track :).
> block_netpoll_tx();
> bond_select_active_slave(bond);
> unblock_netpoll_tx();
> }
>
>will execute only the first branch, always and regardless of do_failover.
>Since these two events aren't related in such way, we need to decouple and
>consider them separately.
>
>For example this issue could lead to the following result:
>Bonding Mode: load balancing (round-robin)
>*MII Status: down*
>MII Polling Interval (ms): 0
>Up Delay (ms): 0
>Down Delay (ms): 0
>ARP Polling Interval (ms): 100
>ARP IP target/s (n.n.n.n form): 192.168.9.2
>
>Slave Interface: ens12
>*MII Status: up*
>Speed: 10000 Mbps
>Duplex: full
>Link Failure Count: 2
>Permanent HW addr: 00:0f:53:01:42:2c
>Slave queue ID: 0
>
>Slave Interface: eth1
>*MII Status: up*
>Speed: Unknown
>Duplex: Unknown
>Link Failure Count: 70
>Permanent HW addr: 52:54:00:2f:0f:8e
>Slave queue ID: 0
>
>Since some interfaces are up, then the status of the bond should also be
>up, but it will never change unless something invokes bond_set_carrier()
>(i.e. enslave, bond_select_active_slave etc). Now, if I force the
>calling of bond_select_active_slave via for example changing
>primary_reselect (it can change in any mode), then the MII status goes to
>"up" because it calls bond_select_active_slave() which should've been done
>from bond_loadbalance_arp_mon() itself.
>
>CC: Veaceslav Falico <vfalico@gmail.com>
Acked-by: Veaceslav Falico <vfalico@gmail.com>
>CC: Jay Vosburgh <j.vosburgh@gmail.com>
>CC: Andy Gospodarek <andy@greyhouse.net>
>CC: Ding Tianhong <dingtianhong@huawei.com>
>
>Fixes: 6fde8f037e60 ("bonding: fix locking in bond_loadbalance_arp_mon()")
>Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com>
>---
>Note: I left the parent if() the same even though we can shorten it. I think
> it's better this way since it shows that any of the two events can cause
> it to enter even though currently we can't have do_failover without
> slave_state_changed, that may also change in the future.
>
> drivers/net/bonding/bond_main.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
>diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
>index c9ac06cfe6b7..a5115fb7cf33 100644
>--- a/drivers/net/bonding/bond_main.c
>+++ b/drivers/net/bonding/bond_main.c
>@@ -2471,7 +2471,8 @@ static void bond_loadbalance_arp_mon(struct work_struct *work)
> bond_slave_state_change(bond);
> if (BOND_MODE(bond) == BOND_MODE_XOR)
> bond_update_slave_arr(bond, NULL);
>- } else if (do_failover) {
>+ }
>+ if (do_failover) {
> block_netpoll_tx();
> bond_select_active_slave(bond);
> unblock_netpoll_tx();
>--
>1.9.3
>
^ permalink raw reply
* Re: [net-next 03/12] i40e: Handle a single mss packet with more than 8 frags
From: Eric Dumazet @ 2014-11-18 14:33 UTC (permalink / raw)
To: David Laight
Cc: 'Nelson, Shannon', Kirsher, Jeffrey T,
davem@davemloft.net, Kong, Serey, netdev@vger.kernel.org,
nhorman@redhat.com, sassmann@redhat.com, jogreene@redhat.com
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D1C9F290B@AcuExch.aculab.com>
On Tue, 2014-11-18 at 09:46 +0000, David Laight wrote:
> That isn't entirely clear from the patch context.
gso_segs = 1 was not clear ???
gso_segs = 1;
if (skb_shinfo(skb)->nr_frags >= I40E_MAX_BUFFER_TXD)
skb_linearize(skb);
Nelson, what happens if a packet has 2 segments and uses 17 fragments ?
Is the hardware OK with that ?
netperf -t TCP_SENDFILE -- -m 171
I did the test and it seems fine on my host, but maybe it was pure luck.
While the following indeed froze the card :
netperf -H 7.7.7.27 -t TCP_SENDFILE -- -m 30
[3257268.702689] i40e 0000:84:00.0: requesting a pf reset
[3257268.831786] i40e 0000:84:00.0: i40e_ptp_init: added PHC on eth2
[3257268.912798] i40e 0000:84:00.0 eth2: NIC Link is Up 40 Gbps Full Duplex, Flow Control: RX/TX
[3257338.895753] i40e 0000:84:00.0: Detected Tx Unit Hang
[3257338.895753] VSI <518>
[3257338.895753] Tx Queue <16>
[3257338.895753] next_to_use <17c>
[3257338.895753] next_to_clean <b2>
[3257338.895757] i40e 0000:84:00.0: tx_bi[next_to_clean]
[3257338.895757] time_stamp <1c20f09c9>
[3257338.895757] jiffies <1c20f0eac>
[3257338.895759] i40e 0000:84:00.0: tx hang detected on queue 16, resetting adapter
[3257338.895769] i40e 0000:84:00.0 eth2: tx_timeout recovery level 1
[3257338.895926] i40e 0000:84:00.0: i40e_vsi_control_tx: VSI seid 518 Tx ring 0 disable timeout
[3257338.949922] i40e 0000:84:00.0: i40e_vsi_control_tx: VSI seid 520 Tx ring 64 disable timeout
[3257339.410705] i40e 0000:84:00.0: PF reset failed, -15
>
> For a non-TSO packet the skb_serialize() is less likely to fail
> since it doesn't need contiguous pages.
Any memory allocation can fail, regardless of the size.
We do not want a memory stress being able to crash the host,
likely or not. It is not worth discussing this, really.
^ permalink raw reply
* [PATCH net] bonding: fix curr_active_slave/carrier with loadbalance arp monitoring
From: Nikolay Aleksandrov @ 2014-11-18 14:14 UTC (permalink / raw)
To: netdev
Cc: davem, Nikolay Aleksandrov, Veaceslav Falico, Jay Vosburgh,
Andy Gospodarek, Ding Tianhong
Since commit 6fde8f037e60 ("bonding: fix locking in
bond_loadbalance_arp_mon()") we can have a stale bond carrier state and
stale curr_active_slave when using arp monitoring in loadbalance modes. The
reason is that in bond_loadbalance_arp_mon() we can't have
do_failover == true but slave_state_changed == false, whenever do_failover
is true then slave_state_changed is also true. Then the following piece
from bond_loadbalance_arp_mon():
if (slave_state_changed) {
bond_slave_state_change(bond);
if (BOND_MODE(bond) == BOND_MODE_XOR)
bond_update_slave_arr(bond, NULL);
} else if (do_failover) {
block_netpoll_tx();
bond_select_active_slave(bond);
unblock_netpoll_tx();
}
will execute only the first branch, always and regardless of do_failover.
Since these two events aren't related in such way, we need to decouple and
consider them separately.
For example this issue could lead to the following result:
Bonding Mode: load balancing (round-robin)
*MII Status: down*
MII Polling Interval (ms): 0
Up Delay (ms): 0
Down Delay (ms): 0
ARP Polling Interval (ms): 100
ARP IP target/s (n.n.n.n form): 192.168.9.2
Slave Interface: ens12
*MII Status: up*
Speed: 10000 Mbps
Duplex: full
Link Failure Count: 2
Permanent HW addr: 00:0f:53:01:42:2c
Slave queue ID: 0
Slave Interface: eth1
*MII Status: up*
Speed: Unknown
Duplex: Unknown
Link Failure Count: 70
Permanent HW addr: 52:54:00:2f:0f:8e
Slave queue ID: 0
Since some interfaces are up, then the status of the bond should also be
up, but it will never change unless something invokes bond_set_carrier()
(i.e. enslave, bond_select_active_slave etc). Now, if I force the
calling of bond_select_active_slave via for example changing
primary_reselect (it can change in any mode), then the MII status goes to
"up" because it calls bond_select_active_slave() which should've been done
from bond_loadbalance_arp_mon() itself.
CC: Veaceslav Falico <vfalico@gmail.com>
CC: Jay Vosburgh <j.vosburgh@gmail.com>
CC: Andy Gospodarek <andy@greyhouse.net>
CC: Ding Tianhong <dingtianhong@huawei.com>
Fixes: 6fde8f037e60 ("bonding: fix locking in bond_loadbalance_arp_mon()")
Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com>
---
Note: I left the parent if() the same even though we can shorten it. I think
it's better this way since it shows that any of the two events can cause
it to enter even though currently we can't have do_failover without
slave_state_changed, that may also change in the future.
drivers/net/bonding/bond_main.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index c9ac06cfe6b7..a5115fb7cf33 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -2471,7 +2471,8 @@ static void bond_loadbalance_arp_mon(struct work_struct *work)
bond_slave_state_change(bond);
if (BOND_MODE(bond) == BOND_MODE_XOR)
bond_update_slave_arr(bond, NULL);
- } else if (do_failover) {
+ }
+ if (do_failover) {
block_netpoll_tx();
bond_select_active_slave(bond);
unblock_netpoll_tx();
--
1.9.3
^ permalink raw reply related
* Re: Query about Dynamic Right Sizing implementation in linux-kernel
From: Eric Dumazet @ 2014-11-18 14:07 UTC (permalink / raw)
To: cprasad; +Cc: netdev
In-Reply-To: <400045440.131017.1416304451861.JavaMail.root@mail.cse.iitm.ac.in>
On Tue, 2014-11-18 at 15:24 +0530, cprasad@cse.iitm.ac.in wrote:
> Hi,
> I found a DRS patch for verison 2.4.8 in lanl.gov page and I have no
> idea if it is incorporated into the kernel. So I would like to know if
> Dynamic Right Sizing(DRS) is implemented in kernel.If so from which
> version of kernel was it implemented?
It is implemented yes.
Last patch we did about that was for linux-3.13
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b0983d3c9b132c33b6fb2e28d157a1edc18a173c
^ permalink raw reply
* [PATCH 2/2] net: can: comparison of unsigned variable
From: Sudip Mukherjee @ 2014-11-18 13:47 UTC (permalink / raw)
To: Wolfgang Grandegger, Marc Kleine-Budde, Michal Simek,
Sören Brinkmann
Cc: Sudip Mukherjee, linux-can, netdev, linux-arm-kernel,
linux-kernel
In-Reply-To: <1416318427-28676-1-git-send-email-sudipm.mukherjee@gmail.com>
err was of the type u32. it was being compared with < 0, and being
an unsigned variable the comparison would have been always false.
moreover, err was getting the return value from set_reset_mode()
and xcan_set_bittiming(), and both are returning int.
Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
---
drivers/net/can/xilinx_can.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/can/xilinx_can.c b/drivers/net/can/xilinx_can.c
index 72fe96f..67c2dd4 100644
--- a/drivers/net/can/xilinx_can.c
+++ b/drivers/net/can/xilinx_can.c
@@ -300,7 +300,8 @@ static int xcan_set_bittiming(struct net_device *ndev)
static int xcan_chip_start(struct net_device *ndev)
{
struct xcan_priv *priv = netdev_priv(ndev);
- u32 err, reg_msr, reg_sr_mask;
+ u32 reg_msr, reg_sr_mask;
+ int err;
unsigned long timeout;
/* Check if it is in reset mode */
--
1.8.1.2
^ permalink raw reply related
* [PATCH 1/2] net: can: remove unused variable
From: Sudip Mukherjee @ 2014-11-18 13:47 UTC (permalink / raw)
To: Wolfgang Grandegger, Marc Kleine-Budde
Cc: Sudip Mukherjee, linux-can, netdev, linux-kernel
these variable were only assigned some values, but then never
reused again.
so they are safe to be removed.
Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
---
drivers/net/can/sja1000/kvaser_pci.c | 5 +----
drivers/net/can/usb/ems_usb.c | 3 +--
drivers/net/can/usb/esd_usb2.c | 2 --
3 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/net/can/sja1000/kvaser_pci.c b/drivers/net/can/sja1000/kvaser_pci.c
index 8ff3424..15c00fa 100644
--- a/drivers/net/can/sja1000/kvaser_pci.c
+++ b/drivers/net/can/sja1000/kvaser_pci.c
@@ -214,7 +214,7 @@ static int kvaser_pci_add_chan(struct pci_dev *pdev, int channel,
struct net_device *dev;
struct sja1000_priv *priv;
struct kvaser_pci *board;
- int err, init_step;
+ int err;
dev = alloc_sja1000dev(sizeof(struct kvaser_pci));
if (dev == NULL)
@@ -235,7 +235,6 @@ static int kvaser_pci_add_chan(struct pci_dev *pdev, int channel,
if (channel == 0) {
board->xilinx_ver =
ioread8(board->res_addr + XILINX_VERINT) >> 4;
- init_step = 2;
/* Assert PTADR# - we're in passive mode so the other bits are
not important */
@@ -264,8 +263,6 @@ static int kvaser_pci_add_chan(struct pci_dev *pdev, int channel,
priv->irq_flags = IRQF_SHARED;
dev->irq = pdev->irq;
- init_step = 4;
-
dev_info(&pdev->dev, "reg_base=%p conf_addr=%p irq=%d\n",
priv->reg_base, board->conf_addr, dev->irq);
diff --git a/drivers/net/can/usb/ems_usb.c b/drivers/net/can/usb/ems_usb.c
index 00f2534..29d3f09 100644
--- a/drivers/net/can/usb/ems_usb.c
+++ b/drivers/net/can/usb/ems_usb.c
@@ -434,10 +434,9 @@ static void ems_usb_read_bulk_callback(struct urb *urb)
if (urb->actual_length > CPC_HEADER_SIZE) {
struct ems_cpc_msg *msg;
u8 *ibuf = urb->transfer_buffer;
- u8 msg_count, again, start;
+ u8 msg_count, start;
msg_count = ibuf[0] & ~0x80;
- again = ibuf[0] & 0x80;
start = CPC_HEADER_SIZE;
diff --git a/drivers/net/can/usb/esd_usb2.c b/drivers/net/can/usb/esd_usb2.c
index b7c9e8b..d25e88f 100644
--- a/drivers/net/can/usb/esd_usb2.c
+++ b/drivers/net/can/usb/esd_usb2.c
@@ -464,7 +464,6 @@ static void esd_usb2_write_bulk_callback(struct urb *urb)
{
struct esd_tx_urb_context *context = urb->context;
struct esd_usb2_net_priv *priv;
- struct esd_usb2 *dev;
struct net_device *netdev;
size_t size = sizeof(struct esd_usb2_msg);
@@ -472,7 +471,6 @@ static void esd_usb2_write_bulk_callback(struct urb *urb)
priv = context->priv;
netdev = priv->netdev;
- dev = priv->usb2;
/* free up our allocated buffer */
usb_free_coherent(urb->dev, size,
--
1.8.1.2
^ permalink raw reply related
* Re: ipx: fix locking regression in ipx_sendmsg and ipx_recvmsg
From: Arnd Bergmann @ 2014-11-18 13:37 UTC (permalink / raw)
To: Jiri Bohac; +Cc: Arnaldo Carvalho de Melo, netdev
In-Reply-To: <20141117013448.GA26743@midget.suse.cz>
On Monday 17 November 2014 02:34:48 Jiri Bohac wrote:
> This fixes an old regression introduced by commit
> b0d0d915 (ipx: remove the BKL).
>
> When a recvmsg syscall blocks waiting for new data, no data can be sent on the
> same socket with sendmsg because ipx_recvmsg() sleeps with the socket locked.
>
> This breaks mars-nwe (NetWare emulator):
> - the ncpserv process reads the request using recvmsg
> - ncpserv forks and spawns nwconn
> - ncpserv calls a (blocking) recvmsg and waits for new requests
> - nwconn deadlocks in sendmsg on the same socket
>
> Commit b0d0d915 has simply replaced BKL locking with
> lock_sock/release_sock. Unlike now, BKL got unlocked while
> sleeping, so a blocking recvmsg did not block a concurrent
> sendmsg.
>
> Similarly, a potentially sleeping sendmsg() could block calls to recvmsg().
>
> Only keep the socket locked while actually working with the socket data and
> release it prior to calling skb_recv_datagram() / ipxitf_send().
>
>
> Signed-off-by: Jiri Bohac <jbohac@suse.cz>
Hi Jiri,
I'm very sorry about the regression my patch introduced, glad you worked
it out. Your patch looks correct to me, but I suspect we can do it in
a simpler way, based on what I found I did in the respective appletalk
and x25 BKL removal patches. From all I can tell, those do not have
the same problem, which is a relief to me.
Some questions:
> @@ -1745,12 +1745,16 @@ static int ipx_sendmsg(struct kiocb *iocb, struct socket *sock,
> memcpy(usipx->sipx_node, ipxs->dest_addr.node, IPX_NODE_LEN);
> }
>
> + /* releases sk */
> rc = ipxrtr_route_packet(sk, usipx, msg->msg_iov, len,
> flags & MSG_DONTWAIT);
> if (rc >= 0)
> rc = len;
> -out:
> + goto out;
> +
> +out_release:
> release_sock(sk);
> +out:
> return rc;
> }
>
Does ipxrtr_route_packet() actually sleep while waiting for the network,
or is it possible that you only need to change the recvmsg path?
If you need to change this function, have you considered doing it
one of these two ways:
a) only change the ipxrtr_route_packet function to release the lock
before sleeping and then reaquiring it but not change ipx_sendmsg
b) figure out whether ipx_sendmsg actually relies on the lock at all,
and if it doesn't then remove the locking, or limit the scope to
the parts that do.
> @@ -1776,20 +1780,21 @@ static int ipx_recvmsg(struct kiocb *iocb, struct socket *sock,
> #ifdef CONFIG_IPX_INTERN
> rc = -ENETDOWN;
> if (!ipxs->intrfc)
> - goto out; /* Someone zonked the iface */
> + goto out_release; /* Someone zonked the iface */
> memcpy(uaddr.sipx_node, ipxs->intrfc->if_node, IPX_NODE_LEN);
> #endif /* CONFIG_IPX_INTERN */
>
> rc = __ipx_bind(sock, (struct sockaddr *)&uaddr,
> sizeof(struct sockaddr_ipx));
> if (rc)
> - goto out;
> + goto out_release;
> }
>
> rc = -ENOTCONN;
> if (sock_flag(sk, SOCK_ZAPPED))
> - goto out;
> + goto out_release;
>
> + release_sock(sk);
> skb = skb_recv_datagram(sk, flags & ~MSG_DONTWAIT,
> flags & MSG_DONTWAIT, &rc);
> if (!skb) {
Same thing here: I think your patch could be simplified if you just
release the socket lock before calling skb_recv_datagram and get
it back afterwards, and it would be much simpler if you could
show that the lock is not needed at all.
Arnd
^ permalink raw reply
* [PATCH] usbnet: rtl8150: remove unused variable
From: Sudip Mukherjee @ 2014-11-18 12:59 UTC (permalink / raw)
To: Petko Manolov; +Cc: Sudip Mukherjee, linux-usb, netdev, linux-kernel
we were just returning the initial value of res, instead now
we are returning the value directly.
Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
---
drivers/net/usb/rtl8150.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/usb/rtl8150.c b/drivers/net/usb/rtl8150.c
index 6e87e57..d37b7dc 100644
--- a/drivers/net/usb/rtl8150.c
+++ b/drivers/net/usb/rtl8150.c
@@ -753,14 +753,13 @@ static int rtl8150_open(struct net_device *netdev)
static int rtl8150_close(struct net_device *netdev)
{
rtl8150_t *dev = netdev_priv(netdev);
- int res = 0;
netif_stop_queue(netdev);
if (!test_bit(RTL8150_UNPLUG, &dev->flags))
disable_net_traffic(dev);
unlink_all_urbs(dev);
- return res;
+ return 0;
}
static void rtl8150_get_drvinfo(struct net_device *netdev, struct ethtool_drvinfo *info)
--
1.8.1.2
^ permalink raw reply related
* Re: [PATCH 2/4] arch: Add lightweight memory barriers fast_rmb() and fast_wmb()
From: Will Deacon @ 2014-11-18 11:58 UTC (permalink / raw)
To: Alexander Duyck
Cc: Benjamin Herrenschmidt, Alexander Duyck,
linux-arch@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, mathieu.desnoyers@polymtl.ca,
peterz@infradead.org, heiko.carstens@de.ibm.com, mingo@kernel.org,
mikey@neuling.org, linux@arm.linux.org.uk,
donald.c.skidmore@intel.com, matthew.vick@intel.com,
geert@linux-m68k.org, jeffrey.t.kirsher@intel.com,
romieu@fr.zoreil.com, paulmck@linux.vnet.ibm.com
In-Reply-To: <546AB959.1020602@redhat.com>
On Tue, Nov 18, 2014 at 03:13:29AM +0000, Alexander Duyck wrote:
> On 11/17/2014 04:39 PM, Benjamin Herrenschmidt wrote:
> > On Mon, 2014-11-17 at 12:24 -0800, Alexander Duyck wrote:
> >> Yes and no. So for example on ARM I used the dmb() operation, however
> >> I
> >> have to use the barrier at the system level instead of just the inner
> >> shared domain. However on many other architectures they are just the
> >> same as the smp_* variants.
> >>
> >> Basically the resultant code is somewhere between the smp and non-smp
> >> barriers in terms of what they cover.
> > There I don't quite follow you. You need to explain better especially in
> > the documentation because otherwise people will get it wrong...
> >
> > If it's ordering in the coherent domain, I fail to see how a DMA agent
> > is different than another processor when it comes to barriers, so I fail
> > to see the difference with smp_*
> >
> > I understand the MMIO vs. memory issue, we do have the same on powerpc,
> > but that other aspect eludes me.
> >
>
> ARM adds some funky things. They have two different types of
> primitives, a dmb() which is a data memory barrier, and a dsb() which is
> a data synchronization barrier. Then with each of those they have the
> "domains" the barriers are effective within.
>
> So for example on ARM a rmb() is dsb(sy) which means it is a system wide
> synchronization barrier which stops execution on the CPU core until the
> read completes. However the smp_rmb() is a dmb(ish) which means it is
> only a barrier as far as the inner shareable domain which I believe only
> goes as far as the local shared cache hierarchy and only guarantees read
> ordering without necessarily halting the CPU or stopping in-order
> speculative reads. So what a coherent_rmb() would be in my setup is
> dmb(sy) which means the barrier runs all the way out to memory, and it
> is allowed to speculative read as long as it does it in order.
>
> If it is still unclear you might check out Will Deacon's talk on the
> topic at https://www.youtube.com/watch?v=6ORn6_35kKo, at about 7:00 in
> he explains the whole domains thing, and at 13:30 he explains dmb()/dsb().
So actually, this is an interesting case where the barrier would like to
know whether the memory returned by dma_alloc_coherent is h/w coherent
(normal, cacheable) or s/w coherent (normal, non-cacheable). I think Ben
is thinking of the h/w coherent case (i.e. actual snooping into the CPU
caches by the DMA master).
For the former, we could use inner-shareable barriers. For the latter, we'd
need to use outer-shareable barriers.
If we can't tell, then these should be dmb(osh), which will work for both.
Will
^ permalink raw reply
* Re: [PATCH V4 2/3] can: m_can: update to support CAN FD features
From: Dong Aisheng @ 2014-11-18 11:22 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: Oliver Hartkopp, linux-can, wg, varkabhadram, netdev,
linux-arm-kernel
In-Reply-To: <5465CA47.4020802@pengutronix.de>
On Fri, Nov 14, 2014 at 10:24:23AM +0100, Marc Kleine-Budde wrote:
> On 11/13/2014 05:56 PM, Oliver Hartkopp wrote:
> > On 11/13/2014 11:10 AM, Marc Kleine-Budde wrote:
> >> On 11/07/2014 09:45 AM, Dong Aisheng wrote:
> >
> >>>
> >>> - if (id & RX_BUF_RTR) {
> >>> + if (id & RX_BUF_ESI) {
> >>> + cf->flags |= CANFD_ESI;
> >>> + netdev_dbg(dev, "ESI Error\n");
> >>> + }
> >>> +
> >>> + if (!(dlc & RX_BUF_EDL) && (id & RX_BUF_RTR)) {
> >>> cf->can_id |= CAN_RTR_FLAG;
> >>
> >> I just noticed, that you don't set the cf->dlc (or cf->len) in the RTR
> >> case. Please create a separate patch that fixes this problem.
> >>
> >>> } else {
> >>> id = m_can_fifo_read(priv, fgi, M_CAN_FIFO_DLC);
> >>> - cf->can_dlc = get_can_dlc((id >> 16) & 0x0F);
> >>> - *(u32 *)(cf->data + 0) = m_can_fifo_read(priv, fgi,
> >>> - M_CAN_FIFO_DATA(0));
> >>> - *(u32 *)(cf->data + 4) = m_can_fifo_read(priv, fgi,
> >>> - M_CAN_FIFO_DATA(1));
> >>> + if (dlc & RX_BUF_EDL)
> >>> + cf->len = can_dlc2len((id >> 16) & 0x0F);
> >>> + else
> >>> + cf->len = get_can_dlc((id >> 16) & 0x0F);
> >>> +
> >
> > Grr. I missed that one too :-(
> >
> > Thanks for catching it.
> >
> > As you committed patch 1 & 3 you expect a new single patch containing the
> > (fixed) content of this patch 2, right?
>
> No, please make it two patches:
>
> First the Bugfix: One setting the cf->dlc in the RTR case, too.
> Then the new feature: The other one adding CAN-FD support.
>
Thanks for finding this.
Will do a patch soon as you said.
Regards
Dong Aisheng
> Marc
>
> --
> Pengutronix e.K. | Marc Kleine-Budde |
> Industrial Linux Solutions | Phone: +49-231-2826-924 |
> Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
> Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
>
^ permalink raw reply
* [PATCH V5 2/2] can: m_can: update to support CAN FD features
From: Dong Aisheng @ 2014-11-18 11:00 UTC (permalink / raw)
To: linux-can
Cc: netdev, varkabhadram, mkl, linux-arm-kernel, socketcan, b29396,
wg
In-Reply-To: <1416308455-29134-1-git-send-email-b29396@freescale.com>
Bosch M_CAN is CAN FD capable device. This patch implements the CAN
FD features include up to 64 bytes payload and bitrate switch function.
1) Change the Rx FIFO and Tx Buffer to 64 bytes for support CAN FD
up to 64 bytes payload. It's backward compatible with old 8 bytes
normal CAN frame.
2) Allocate can frame or canfd frame based on EDL bit
3) Bitrate Switch function is disabled by default and will be enabled
according to CANFD_BRS bit in cf->flags.
Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: Dong Aisheng <b29396@freescale.com>
---
ChangeLog:
v4->v5:
* rebase version
v3->v4:
* no changes
v2->v3:
* integrate patch 4 into patch 1 in last series(allow to send std frame
on can fd mode)
* use suitable API to get cf->len according to RX_BUF_EDL bit
v1->v2:
* Allocate can frame or canfd frame based on EDL bit
* Only check and set RTR bit for normal frame (no EDL bit set)
---
drivers/net/can/m_can/m_can.c | 177 ++++++++++++++++++++++++++++++++----------
1 file changed, 134 insertions(+), 43 deletions(-)
diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
index 2f61676..d7bc462 100644
--- a/drivers/net/can/m_can/m_can.c
+++ b/drivers/net/can/m_can/m_can.c
@@ -105,14 +105,36 @@ enum m_can_mram_cfg {
MRAM_CFG_NUM,
};
+/* Fast Bit Timing & Prescaler Register (FBTP) */
+#define FBTR_FBRP_MASK 0x1f
+#define FBTR_FBRP_SHIFT 16
+#define FBTR_FTSEG1_SHIFT 8
+#define FBTR_FTSEG1_MASK (0xf << FBTR_FTSEG1_SHIFT)
+#define FBTR_FTSEG2_SHIFT 4
+#define FBTR_FTSEG2_MASK (0x7 << FBTR_FTSEG2_SHIFT)
+#define FBTR_FSJW_SHIFT 0
+#define FBTR_FSJW_MASK 0x3
+
/* Test Register (TEST) */
#define TEST_LBCK BIT(4)
/* CC Control Register(CCCR) */
-#define CCCR_TEST BIT(7)
-#define CCCR_MON BIT(5)
-#define CCCR_CCE BIT(1)
-#define CCCR_INIT BIT(0)
+#define CCCR_TEST BIT(7)
+#define CCCR_CMR_MASK 0x3
+#define CCCR_CMR_SHIFT 10
+#define CCCR_CMR_CANFD 0x1
+#define CCCR_CMR_CANFD_BRS 0x2
+#define CCCR_CMR_CAN 0x3
+#define CCCR_CME_MASK 0x3
+#define CCCR_CME_SHIFT 8
+#define CCCR_CME_CAN 0
+#define CCCR_CME_CANFD 0x1
+#define CCCR_CME_CANFD_BRS 0x2
+#define CCCR_TEST BIT(7)
+#define CCCR_MON BIT(5)
+#define CCCR_CCE BIT(1)
+#define CCCR_INIT BIT(0)
+#define CCCR_CANFD 0x10
/* Bit Timing & Prescaler Register (BTP) */
#define BTR_BRP_MASK 0x3ff
@@ -204,6 +226,7 @@ enum m_can_mram_cfg {
/* Rx Buffer / FIFO Element Size Configuration (RXESC) */
#define M_CAN_RXESC_8BYTES 0x0
+#define M_CAN_RXESC_64BYTES 0x777
/* Tx Buffer Configuration(TXBC) */
#define TXBC_NDTB_OFF 16
@@ -211,6 +234,7 @@ enum m_can_mram_cfg {
/* Tx Buffer Element Size Configuration(TXESC) */
#define TXESC_TBDS_8BYTES 0x0
+#define TXESC_TBDS_64BYTES 0x7
/* Tx Event FIFO Con.guration (TXEFC) */
#define TXEFC_EFS_OFF 16
@@ -219,11 +243,11 @@ enum m_can_mram_cfg {
/* Message RAM Configuration (in bytes) */
#define SIDF_ELEMENT_SIZE 4
#define XIDF_ELEMENT_SIZE 8
-#define RXF0_ELEMENT_SIZE 16
-#define RXF1_ELEMENT_SIZE 16
+#define RXF0_ELEMENT_SIZE 72
+#define RXF1_ELEMENT_SIZE 72
#define RXB_ELEMENT_SIZE 16
#define TXE_ELEMENT_SIZE 8
-#define TXB_ELEMENT_SIZE 16
+#define TXB_ELEMENT_SIZE 72
/* Message RAM Elements */
#define M_CAN_FIFO_ID 0x0
@@ -231,11 +255,17 @@ enum m_can_mram_cfg {
#define M_CAN_FIFO_DATA(n) (0x8 + ((n) << 2))
/* Rx Buffer Element */
+/* R0 */
#define RX_BUF_ESI BIT(31)
#define RX_BUF_XTD BIT(30)
#define RX_BUF_RTR BIT(29)
+/* R1 */
+#define RX_BUF_ANMF BIT(31)
+#define RX_BUF_EDL BIT(21)
+#define RX_BUF_BRS BIT(20)
/* Tx Buffer Element */
+/* R0 */
#define TX_BUF_XTD BIT(30)
#define TX_BUF_RTR BIT(29)
@@ -327,42 +357,67 @@ static inline void m_can_disable_all_interrupts(const struct m_can_priv *priv)
m_can_write(priv, M_CAN_ILE, 0x0);
}
-static void m_can_read_fifo(const struct net_device *dev, struct can_frame *cf,
- u32 rxfs)
+static void m_can_read_fifo(struct net_device *dev, u32 rxfs)
{
+ struct net_device_stats *stats = &dev->stats;
struct m_can_priv *priv = netdev_priv(dev);
+ struct canfd_frame *cf;
+ struct sk_buff *skb;
u32 id, fgi, dlc;
+ int i;
/* calculate the fifo get index for where to read data */
fgi = (rxfs & RXFS_FGI_MASK) >> RXFS_FGI_OFF;
+ dlc = m_can_fifo_read(priv, fgi, M_CAN_FIFO_DLC);
+ if (dlc & RX_BUF_EDL)
+ skb = alloc_canfd_skb(dev, &cf);
+ else
+ skb = alloc_can_skb(dev, (struct can_frame **)&cf);
+ if (!skb) {
+ stats->rx_dropped++;
+ return;
+ }
+
+ if (dlc & RX_BUF_EDL)
+ cf->len = can_dlc2len((dlc >> 16) & 0x0F);
+ else
+ cf->len = get_can_dlc((dlc >> 16) & 0x0F);
+
id = m_can_fifo_read(priv, fgi, M_CAN_FIFO_ID);
if (id & RX_BUF_XTD)
cf->can_id = (id & CAN_EFF_MASK) | CAN_EFF_FLAG;
else
cf->can_id = (id >> 18) & CAN_SFF_MASK;
- dlc = m_can_fifo_read(priv, fgi, M_CAN_FIFO_DLC);
- cf->can_dlc = get_can_dlc((dlc >> 16) & 0x0F);
+ if (id & RX_BUF_ESI) {
+ cf->flags |= CANFD_ESI;
+ netdev_dbg(dev, "ESI Error\n");
+ }
- if (id & RX_BUF_RTR) {
+ if (!(dlc & RX_BUF_EDL) && (id & RX_BUF_RTR)) {
cf->can_id |= CAN_RTR_FLAG;
} else {
- *(u32 *)(cf->data + 0) = m_can_fifo_read(priv, fgi,
- M_CAN_FIFO_DATA(0));
- *(u32 *)(cf->data + 4) = m_can_fifo_read(priv, fgi,
- M_CAN_FIFO_DATA(1));
+ if (dlc & RX_BUF_BRS)
+ cf->flags |= CANFD_BRS;
+
+ for (i = 0; i < cf->len; i += 4)
+ *(u32 *)(cf->data + i) =
+ m_can_fifo_read(priv, fgi,
+ M_CAN_FIFO_DATA(i / 4));
}
/* acknowledge rx fifo 0 */
m_can_write(priv, M_CAN_RXF0A, fgi);
+
+ stats->rx_packets++;
+ stats->rx_bytes += cf->len;
+
+ netif_receive_skb(skb);
}
static int m_can_do_rx_poll(struct net_device *dev, int quota)
{
struct m_can_priv *priv = netdev_priv(dev);
- struct net_device_stats *stats = &dev->stats;
- struct sk_buff *skb;
- struct can_frame *frame;
u32 pkts = 0;
u32 rxfs;
@@ -376,18 +431,7 @@ static int m_can_do_rx_poll(struct net_device *dev, int quota)
if (rxfs & RXFS_RFL)
netdev_warn(dev, "Rx FIFO 0 Message Lost\n");
- skb = alloc_can_skb(dev, &frame);
- if (!skb) {
- stats->rx_dropped++;
- return pkts;
- }
-
- m_can_read_fifo(dev, frame, rxfs);
-
- stats->rx_packets++;
- stats->rx_bytes += frame->can_dlc;
-
- netif_receive_skb(skb);
+ m_can_read_fifo(dev, rxfs);
quota--;
pkts++;
@@ -745,10 +789,23 @@ static const struct can_bittiming_const m_can_bittiming_const = {
.brp_inc = 1,
};
+static const struct can_bittiming_const m_can_data_bittiming_const = {
+ .name = KBUILD_MODNAME,
+ .tseg1_min = 2, /* Time segment 1 = prop_seg + phase_seg1 */
+ .tseg1_max = 16,
+ .tseg2_min = 1, /* Time segment 2 = phase_seg2 */
+ .tseg2_max = 8,
+ .sjw_max = 4,
+ .brp_min = 1,
+ .brp_max = 32,
+ .brp_inc = 1,
+};
+
static int m_can_set_bittiming(struct net_device *dev)
{
struct m_can_priv *priv = netdev_priv(dev);
const struct can_bittiming *bt = &priv->can.bittiming;
+ const struct can_bittiming *dbt = &priv->can.data_bittiming;
u16 brp, sjw, tseg1, tseg2;
u32 reg_btp;
@@ -759,7 +816,17 @@ static int m_can_set_bittiming(struct net_device *dev)
reg_btp = (brp << BTR_BRP_SHIFT) | (sjw << BTR_SJW_SHIFT) |
(tseg1 << BTR_TSEG1_SHIFT) | (tseg2 << BTR_TSEG2_SHIFT);
m_can_write(priv, M_CAN_BTP, reg_btp);
- netdev_dbg(dev, "setting BTP 0x%x\n", reg_btp);
+
+ if (priv->can.ctrlmode & CAN_CTRLMODE_FD) {
+ brp = dbt->brp - 1;
+ sjw = dbt->sjw - 1;
+ tseg1 = dbt->prop_seg + dbt->phase_seg1 - 1;
+ tseg2 = dbt->phase_seg2 - 1;
+ reg_btp = (brp << FBTR_FBRP_SHIFT) | (sjw << FBTR_FSJW_SHIFT) |
+ (tseg1 << FBTR_FTSEG1_SHIFT) |
+ (tseg2 << FBTR_FTSEG2_SHIFT);
+ m_can_write(priv, M_CAN_FBTP, reg_btp);
+ }
return 0;
}
@@ -779,8 +846,8 @@ static void m_can_chip_config(struct net_device *dev)
m_can_config_endisable(priv, true);
- /* RX Buffer/FIFO Element Size 8 bytes data field */
- m_can_write(priv, M_CAN_RXESC, M_CAN_RXESC_8BYTES);
+ /* RX Buffer/FIFO Element Size 64 bytes data field */
+ m_can_write(priv, M_CAN_RXESC, M_CAN_RXESC_64BYTES);
/* Accept Non-matching Frames Into FIFO 0 */
m_can_write(priv, M_CAN_GFC, 0x0);
@@ -789,8 +856,8 @@ static void m_can_chip_config(struct net_device *dev)
m_can_write(priv, M_CAN_TXBC, (1 << TXBC_NDTB_OFF) |
priv->mcfg[MRAM_TXB].off);
- /* only support 8 bytes firstly */
- m_can_write(priv, M_CAN_TXESC, TXESC_TBDS_8BYTES);
+ /* support 64 bytes payload */
+ m_can_write(priv, M_CAN_TXESC, TXESC_TBDS_64BYTES);
m_can_write(priv, M_CAN_TXEFC, (1 << TXEFC_EFS_OFF) |
priv->mcfg[MRAM_TXE].off);
@@ -805,7 +872,8 @@ static void m_can_chip_config(struct net_device *dev)
RXFC_FWM_1 | priv->mcfg[MRAM_RXF1].off);
cccr = m_can_read(priv, M_CAN_CCCR);
- cccr &= ~(CCCR_TEST | CCCR_MON);
+ cccr &= ~(CCCR_TEST | CCCR_MON | (CCCR_CMR_MASK << CCCR_CMR_SHIFT) |
+ (CCCR_CME_MASK << CCCR_CME_SHIFT));
test = m_can_read(priv, M_CAN_TEST);
test &= ~TEST_LBCK;
@@ -817,6 +885,9 @@ static void m_can_chip_config(struct net_device *dev)
test |= TEST_LBCK;
}
+ if (priv->can.ctrlmode & CAN_CTRLMODE_FD)
+ cccr |= CCCR_CME_CANFD_BRS << CCCR_CME_SHIFT;
+
m_can_write(priv, M_CAN_CCCR, cccr);
m_can_write(priv, M_CAN_TEST, test);
@@ -881,11 +952,13 @@ static struct net_device *alloc_m_can_dev(void)
priv->dev = dev;
priv->can.bittiming_const = &m_can_bittiming_const;
+ priv->can.data_bittiming_const = &m_can_data_bittiming_const;
priv->can.do_set_mode = m_can_set_mode;
priv->can.do_get_berr_counter = m_can_get_berr_counter;
priv->can.ctrlmode_supported = CAN_CTRLMODE_LOOPBACK |
CAN_CTRLMODE_LISTENONLY |
- CAN_CTRLMODE_BERR_REPORTING;
+ CAN_CTRLMODE_BERR_REPORTING |
+ CAN_CTRLMODE_FD;
return dev;
}
@@ -968,8 +1041,9 @@ static netdev_tx_t m_can_start_xmit(struct sk_buff *skb,
struct net_device *dev)
{
struct m_can_priv *priv = netdev_priv(dev);
- struct can_frame *cf = (struct can_frame *)skb->data;
- u32 id;
+ struct canfd_frame *cf = (struct canfd_frame *)skb->data;
+ u32 id, cccr;
+ int i;
if (can_dropped_invalid_skb(dev, skb))
return NETDEV_TX_OK;
@@ -988,11 +1062,28 @@ static netdev_tx_t m_can_start_xmit(struct sk_buff *skb,
/* message ram configuration */
m_can_fifo_write(priv, 0, M_CAN_FIFO_ID, id);
- m_can_fifo_write(priv, 0, M_CAN_FIFO_DLC, cf->can_dlc << 16);
- m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(0), *(u32 *)(cf->data + 0));
- m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(1), *(u32 *)(cf->data + 4));
+ m_can_fifo_write(priv, 0, M_CAN_FIFO_DLC, can_len2dlc(cf->len) << 16);
+
+ for (i = 0; i < cf->len; i += 4)
+ m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(i / 4),
+ *(u32 *)(cf->data + i));
+
can_put_echo_skb(skb, dev, 0);
+ if (priv->can.ctrlmode & CAN_CTRLMODE_FD) {
+ cccr = m_can_read(priv, M_CAN_CCCR);
+ cccr &= ~(CCCR_CMR_MASK << CCCR_CMR_SHIFT);
+ if (can_is_canfd_skb(skb)) {
+ if (cf->flags & CANFD_BRS)
+ cccr |= CCCR_CMR_CANFD_BRS << CCCR_CMR_SHIFT;
+ else
+ cccr |= CCCR_CMR_CANFD << CCCR_CMR_SHIFT;
+ } else {
+ cccr |= CCCR_CMR_CAN << CCCR_CMR_SHIFT;
+ }
+ m_can_write(priv, M_CAN_CCCR, cccr);
+ }
+
/* enable first TX buffer to start transfer */
m_can_write(priv, M_CAN_TXBTIE, 0x1);
m_can_write(priv, M_CAN_TXBAR, 0x1);
--
1.9.1
^ permalink raw reply related
* [PATCH V5 1/2] can: m_can: fix not set can_dlc for remote frame
From: Dong Aisheng @ 2014-11-18 11:00 UTC (permalink / raw)
To: linux-can
Cc: mkl, wg, varkabhadram, netdev, socketcan, b29396,
linux-arm-kernel
The original code missed to set the cf->can_dlc in the RTR case, so add it.
Signed-off-by: Dong Aisheng <b29396@freescale.com>
---
drivers/net/can/m_can/m_can.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
index 06541f1..2f61676 100644
--- a/drivers/net/can/m_can/m_can.c
+++ b/drivers/net/can/m_can/m_can.c
@@ -331,7 +331,7 @@ static void m_can_read_fifo(const struct net_device *dev, struct can_frame *cf,
u32 rxfs)
{
struct m_can_priv *priv = netdev_priv(dev);
- u32 id, fgi;
+ u32 id, fgi, dlc;
/* calculate the fifo get index for where to read data */
fgi = (rxfs & RXFS_FGI_MASK) >> RXFS_FGI_OFF;
@@ -341,11 +341,12 @@ static void m_can_read_fifo(const struct net_device *dev, struct can_frame *cf,
else
cf->can_id = (id >> 18) & CAN_SFF_MASK;
+ dlc = m_can_fifo_read(priv, fgi, M_CAN_FIFO_DLC);
+ cf->can_dlc = get_can_dlc((dlc >> 16) & 0x0F);
+
if (id & RX_BUF_RTR) {
cf->can_id |= CAN_RTR_FLAG;
} else {
- id = m_can_fifo_read(priv, fgi, M_CAN_FIFO_DLC);
- cf->can_dlc = get_can_dlc((id >> 16) & 0x0F);
*(u32 *)(cf->data + 0) = m_can_fifo_read(priv, fgi,
M_CAN_FIFO_DATA(0));
*(u32 *)(cf->data + 4) = m_can_fifo_read(priv, fgi,
--
1.9.1
^ permalink raw reply related
* [PATCH] ipv6: delete protocol when cleanup
From: Duan Jiong @ 2014-11-18 10:35 UTC (permalink / raw)
To: David Miller; +Cc: netdev
pim6_protocol was added when initiation, but it not deleted.
Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com>
---
net/ipv6/ip6mr.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/ipv6/ip6mr.c b/net/ipv6/ip6mr.c
index 0171f08..6dcdecd 100644
--- a/net/ipv6/ip6mr.c
+++ b/net/ipv6/ip6mr.c
@@ -1439,6 +1439,9 @@ reg_pernet_fail:
void ip6_mr_cleanup(void)
{
+#ifdef CONFIG_IPV6_PIMSM_V2
+ inet6_del_protocol(&pim6_protocol, IPPROTO_PIM);
+#endif
unregister_netdevice_notifier(&ip6_mr_notifier);
unregister_pernet_subsys(&ip6mr_net_ops);
kmem_cache_destroy(mrt_cachep);
--
1.8.3.1
^ permalink raw reply related
* [PATCH] [net]ip_tunnel: the lack of vti_link_ops' dellink() cause kernel panic
From: Xin Long @ 2014-11-18 10:37 UTC (permalink / raw)
To: network dev; +Cc: Xin Long
Now the vti_link_ops do not point the .dellink, rtnl_newlink will invoke
the default function, unregister_netdevice_queue, which will cause the
dev to unregister later. so when we delete a vti device, the net_device
will be removed, but the tunnel still in the tunnel list. then, we add
a new vti, in ip_tunnel_find():
hlist_for_each_entry_rcu(t, head, hash_node) {
if (local == t->parms.iph.saddr &&
remote == t->parms.iph.daddr &&
link == t->parms.link &&
type == t->dev->type &&
ip_tunnel_key_match(&t->parms, flags, key))
break;
}
the dev of ip_tunnel *t may be null because of unregister_netdevice_queue
motioned above. so the panic will happen:
[ 3835.072977] IP: [<ffffffffa04103fd>] ip_tunnel_find+0x9d/0xc0 [ip_tunnel]
[ 3835.073008] PGD b2c21067 PUD b7277067 PMD 0
[ 3835.073008] Oops: 0000 [#1] SMP
.....
[ 3835.073008] Stack:
[ 3835.073008] ffff8800b72d77f0 ffffffffa0411924 ffff8800bb956000 ffff8800b72d78e0
[ 3835.073008] ffff8800b72d78a0 0000000000000000 ffffffffa040d100 ffff8800b72d7858
[ 3835.073008] ffffffffa040b2e3 0000000000000000 0000000000000000 0000000000000000
[ 3835.073008] Call Trace:
[ 3835.073008] [<ffffffffa0411924>] ip_tunnel_newlink+0x64/0x160 [ip_tunnel]
[ 3835.073008] [<ffffffffa040b2e3>] vti_newlink+0x43/0x70 [ip_vti]
[ 3835.073008] [<ffffffff8150d4da>] rtnl_newlink+0x4fa/0x5f0
[ 3835.073008] [<ffffffff812f68bb>] ? nla_strlcpy+0x5b/0x70
[ 3835.073008] [<ffffffff81508fb0>] ? rtnl_link_ops_get+0x40/0x60
[ 3835.073008] [<ffffffff8150d11f>] ? rtnl_newlink+0x13f/0x5f0
[ 3835.073008] [<ffffffff81509cf4>] rtnetlink_rcv_msg+0xa4/0x270
[ 3835.073008] [<ffffffff8126adf5>] ? sock_has_perm+0x75/0x90
[ 3835.073008] [<ffffffff81509c50>] ? rtnetlink_rcv+0x30/0x30
[ 3835.073008] [<ffffffff81529e39>] netlink_rcv_skb+0xa9/0xc0
[ 3835.073008] [<ffffffff81509c48>] rtnetlink_rcv+0x28/0x30
....
the reproduction can be like this:
modprobe ip_vti
ip link del ip_vti0 type vti
ip link add ip_vti0 type vti
rmmod ip_vti
do that one or more time, kernel will panic.
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
net/ipv4/ip_vti.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipv4/ip_vti.c b/net/ipv4/ip_vti.c
index 3e86101..1a7e979 100644
--- a/net/ipv4/ip_vti.c
+++ b/net/ipv4/ip_vti.c
@@ -528,6 +528,7 @@ static struct rtnl_link_ops vti_link_ops __read_mostly = {
.validate = vti_tunnel_validate,
.newlink = vti_newlink,
.changelink = vti_changelink,
+ .dellink = ip_tunnel_dellink,
.get_size = vti_get_size,
.fill_info = vti_fill_info,
};
--
1.8.3.1
^ permalink raw reply related
* RE: [PATCH 0/4] Add lightweight memory barriers fast_rmb() and fast_wmb()
From: David Laight @ 2014-11-18 9:57 UTC (permalink / raw)
To: 'Alexander Duyck', linux-arch@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: mathieu.desnoyers@polymtl.ca, peterz@infradead.org,
benh@kernel.crashing.org, heiko.carstens@de.ibm.com,
mingo@kernel.org, mikey@neuling.org, linux@arm.linux.org.uk,
donald.c.skidmore@intel.com, matthew.vick@intel.com,
geert@linux-m68k.org, jeffrey.t.kirsher@intel.com,
romieu@fr.zoreil.com, paulmck@linux.vnet.ibm.com,
nic_swsd@realtek.com, will.deacon@arm.com, michael@ellerman.id.au,
tony.luck@intel.com, "torvalds@li
In-Reply-To: <20141117171005.22333.96544.stgit@ahduyck-server>
From: Alexander Duyck
> These patches introduce two new primitives for synchronizing cache-enabled
> memory writes and reads. These two new primitives are:
>
> fast_rmb()
> fast_wmb()
Not sure I like the names.
If the aim is to sync data into the local cache so that hardware
that is doing cache-snooping accesses sees the data then maybe
local_rmb() and local_wmb()
IIRC read_barrier_depends() is a nop on everything except alpha.
Maybe add the default if it isn't defined by the MD file?
David
^ permalink raw reply
* Query about Dynamic Right Sizing implementation in linux-kernel
From: cprasad @ 2014-11-18 9:54 UTC (permalink / raw)
To: netdev
In-Reply-To: <455193360.130995.1416303487033.JavaMail.root@mail.cse.iitm.ac.in>
Hi,
I found a DRS patch for verison 2.4.8 in lanl.gov page and I have no idea if it is incorporated into the kernel. So I would like to know if Dynamic Right Sizing(DRS) is implemented in kernel.If so from which version of kernel was it implemented?
Thanks and regards,
Giri
^ permalink raw reply
* RE: [net-next 03/12] i40e: Handle a single mss packet with more than 8 frags
From: David Laight @ 2014-11-18 9:46 UTC (permalink / raw)
To: 'Eric Dumazet'
Cc: 'Nelson, Shannon', Kirsher, Jeffrey T,
davem@davemloft.net, Kong, Serey, netdev@vger.kernel.org,
nhorman@redhat.com, sassmann@redhat.com, jogreene@redhat.com
In-Reply-To: <1416243484.5102.21.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet
> On Mon, 2014-11-17 at 16:16 +0000, David Laight wrote:
>
> > Except that a TSO packet is likely to be just under 64k and comprise of
> > a small header and 16 other fragments - most of which will be a complete 4k page.
> >
>
> This is the section of the code sending a _non_ TSO packet.
That isn't entirely clear from the patch context.
For a non-TSO packet the skb_serialize() is less likely to fail
since it doesn't need contiguous pages.
(Unless you are sending 9k jumbo frames).
Actually many of the older ethernet devices will suffer buffer underrun
if given too many small fragments due to lack of bus bandwidth.
The high latencies of PCIe will make that worse - especially at high speeds.
Presumably these devices use 'store and forward' when doing TSO (or
maybe even when just adding a checksum) removing any real problems
caused by PCIe latency?
David
^ permalink raw reply
* Re: [net-next v2 01/11] i40e: only warn once of PTP nonsupport in 100Mbit speed
From: Jeff Kirsher @ 2014-11-18 9:33 UTC (permalink / raw)
To: davem, Joe Perches, Florian Fainelli
Cc: Shannon Nelson, netdev, nhorman, sassmann, jogreene
In-Reply-To: <1416302731-11327-2-git-send-email-jeffrey.t.kirsher@intel.com>
[-- Attachment #1: Type: text/plain, Size: 1795 bytes --]
On Tue, 2014-11-18 at 01:25 -0800, Jeff Kirsher wrote:
> From: Shannon Nelson <shannon.nelson@intel.com>
>
> Only warn once that PTP is not supported when linked at 100Mbit.
>
> Yes, using a static this way means that this once-only message is not
> port specific, but once only for the life of the driver, regardless of
> the number of ports. That should be plenty.
>
> Change-ID: Ie6476530056df408452e195ef06afd4f57caa4b2
> Signed-off-by: Shannon Nelson <shannon.nelson@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> ---
> drivers/net/ethernet/intel/i40e/i40e_ptp.c | 12 +++++++++---
> 1 file changed, 9 insertions(+), 3 deletions(-)
Florian/Joe-
Since your patch to update the dev_level_once() function is going
through Greg KH's tree, we will stick with this patch until it gets
accepted and merged into Dave's tree. Then we will provide a patch to
update the driver.
>
> diff --git a/drivers/net/ethernet/intel/i40e/i40e_ptp.c b/drivers/net/ethernet/intel/i40e/i40e_ptp.c
> index 537b621..f9151037 100644
> --- a/drivers/net/ethernet/intel/i40e/i40e_ptp.c
> +++ b/drivers/net/ethernet/intel/i40e/i40e_ptp.c
> @@ -382,11 +382,17 @@ void i40e_ptp_set_increment(struct i40e_pf *pf)
> incval = I40E_PTP_1GB_INCVAL;
> break;
> case I40E_LINK_SPEED_100MB:
> - dev_warn(&pf->pdev->dev,
> - "%s: 1588 functionality is not supported at 100 Mbps. Stopping the PHC.\n",
> - __func__);
> + {
> + static int warn_once;
> +
> + if (!warn_once) {
> + dev_warn(&pf->pdev->dev,
> + "1588 functionality is not supported at 100 Mbps. Stopping the PHC.\n");
> + warn_once++;
> + }
> incval = 0;
> break;
> + }
> case I40E_LINK_SPEED_40GB:
> default:
> incval = I40E_PTP_40GB_INCVAL;
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ 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