linux.git/drivers/net, branch v3.16-rc5

net: allwinner: emac: Add missing free_irq

2014-06-25T23:31:17+00:00

If the mdio probe function fails in emac_open, the interrupt we just requested
isn't freed. If emac_open is called again, for example because we try to set up
the interface again, the kernel will oops because the interrupt wasn't properly
released.

Signed-off-by: Maxime Ripard 
Cc:  # 3.11+
Signed-off-by: David S. Miller

cxgb4: use dev_port to identify ports

2014-06-25T23:01:54+00:00

Commit 3f85944fe207d0225ef21a2c0951d4946fc9a95d ("net: Add sysfs file
for port number") introduce dev_port to network devices. cxgb4 adapters
have multiple ports on the same PCI function, and used dev_id to
identify those ports. That use was removed by commit
8c367fcbe6549195d2eb11e62bea233f811aad41 ("cxgb4: Do not set
net_device::dev_id to VI index"), since dev_id should be used only when
devices share the same MAC address.

Using dev_port for cxgb4 allows different ports on the same PCI function
to be identified.

Signed-off-by: Thadeu Lima de Souza Cascardo 
Signed-off-by: David S. Miller

xen-netback: bookkeep number of active queues in our own module

2014-06-25T22:59:47+00:00

The original code uses netdev->real_num_tx_queues to bookkeep number of
queues and invokes netif_set_real_num_tx_queues to set the number of
queues. However, netif_set_real_num_tx_queues doesn't allow
real_num_tx_queues to be smaller than 1, which means setting the number
to 0 will not work and real_num_tx_queues is untouched.

This is bogus when xenvif_free is invoked before any number of queues is
allocated. That function needs to iterate through all queues to free
resources. Using the wrong number of queues results in NULL pointer
dereference.

So we bookkeep the number of queues in xen-netback to solve this
problem. This fixes a regression introduced by multiqueue patchset in
3.16-rc1.

There's another bug in original code that the real number of RX queues
is never set. In current Xen multiqueue design, the number of TX queues
and RX queues are in fact the same. We need to set the numbers of TX and
RX queues to the same value.

Also remove xenvif_select_queue and leave queue selection to core
driver, as suggested by David Miller.

Reported-by: Boris Ostrovsky 
Signed-off-by: Wei Liu 
CC: Ian Campbell 
CC: Paul Durrant 
Signed-off-by: David S. Miller

tg3: Change nvram command timeout value to 50ms

2014-06-25T22:56:21+00:00

Commit 506724c463fcd63477a5e404728a980b71f80bb7 "tg3: Override clock,
link aware and link idle mode during NVRAM dump" changed the timeout
value for nvram command execution from 100ms to 1ms. But the 1ms
timeout value was only sufficient for nvram read operations but not
write operations for most of the devices supported by tg3 driver.
This patch sets the MAX to 50ms. Also it uses usleep_range instead
of udelay.

Signed-off-by: Prashant Sreedharan 
Signed-off-by: Michael Chan 
Suggested-by: David Miller 
Signed-off-by: David S. Miller

cxgb4: Not need to hold the adap_rcu_lock lock when read adap_rcu_list

2014-06-24T22:51:49+00:00

cxgb4_netdev maybe lead to dead lock, since it uses a spin lock, and be called
in both thread and softirq context, but not disable BH, the lockdep report is
below; In fact, cxgb4_netdev only reads adap_rcu_list with RCU protection, so
not need to hold spin lock again.
	=================================
	[ INFO: inconsistent lock state ]
	3.14.7+ #24 Tainted: G         C O
	---------------------------------
	inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
	radvd/3794 [HC0[0]:SC1[1]:HE1:SE0] takes:
	 (adap_rcu_lock){+.?...}, at: [] clip_add+0x2c/0x116 [cxgb4]
	{SOFTIRQ-ON-W} state was registered at:
	  [] __lock_acquire+0x34a/0xe48
	  [] lock_acquire+0x82/0x9d
	  [] _raw_spin_lock+0x34/0x43
	  [] clip_add+0x2c/0x116 [cxgb4]
	  [] cxgb4_inet6addr_handler+0x117/0x12c [cxgb4]
	  [] notifier_call_chain+0x32/0x5c
	  [] __atomic_notifier_call_chain+0x44/0x6e
	  [] atomic_notifier_call_chain+0xf/0x11
	  [] inet6addr_notifier_call_chain+0x16/0x18
	  [] ipv6_add_addr+0x404/0x46e [ipv6]
	  [] addrconf_add_linklocal+0x5f/0x95 [ipv6]
	  [] addrconf_notify+0x632/0x841 [ipv6]
	  [] notifier_call_chain+0x32/0x5c
	  [] __raw_notifier_call_chain+0x9/0xb
	  [] raw_notifier_call_chain+0xf/0x11
	  [] call_netdevice_notifiers_info+0x4e/0x56
	  [] call_netdevice_notifiers+0x11/0x13
	  [] netdev_state_change+0x1f/0x38
	  [] linkwatch_do_dev+0x3b/0x49
	  [] __linkwatch_run_queue+0x10b/0x144
	  [] linkwatch_event+0x20/0x27
	  [] process_one_work+0x1cb/0x2ee
	  [] worker_thread+0x12e/0x1fc
	  [] kthread+0xc4/0xcc
	  [] ret_from_fork+0x7c/0xb0
	irq event stamp: 3388
	hardirqs last  enabled at (3388): []
	__local_bh_enable_ip+0xaa/0xd9
	hardirqs last disabled at (3387): []
	__local_bh_enable_ip+0x52/0xd9
	softirqs last  enabled at (3288): []
	rcu_read_unlock_bh+0x0/0x2f [ipv6]
	softirqs last disabled at (3289): []
	do_softirq_own_stack+0x1c/0x30

	other info that might help us debug this:
	 Possible unsafe locking scenario:

	       CPU0
	       ----
	  lock(adap_rcu_lock);
	  
	    lock(adap_rcu_lock);

	 *** DEADLOCK ***

	5 locks held by radvd/3794:
	 #0:  (sk_lock-AF_INET6){+.+.+.}, at: []
	rawv6_sendmsg+0x74b/0xa4d [ipv6]
	 #1:  (rcu_read_lock){.+.+..}, at: []
	rcu_lock_acquire+0x0/0x29
	 #2:  (rcu_read_lock){.+.+..}, at: []
	rcu_lock_acquire.constprop.16+0x0/0x30 [ipv6]
	 #3:  (rcu_read_lock){.+.+..}, at: []
	rcu_lock_acquire+0x0/0x29
	 #4:  (rcu_read_lock){.+.+..}, at: []
	rcu_lock_acquire.constprop.40+0x0/0x30 [cxgb4]

	stack backtrace:
	CPU: 7 PID: 3794 Comm: radvd Tainted: G         C O 3.14.7+ #24
	Hardware name: Supermicro X7DBU/X7DBU, BIOS 6.00 12/03/2007
	 ffffffff81f15990 ffff88012fdc36a8 ffffffff815d0016 0000000000000006
	 ffff8800c80dc2a0 ffff88012fdc3708 ffffffff815cc727 0000000000000001
	 0000000000000001 ffff880100000000 ffffffff81015b02 ffff8800c80dcb58
	Call Trace:
	   [] dump_stack+0x4e/0x71
	 [] print_usage_bug+0x1ec/0x1fd
	 [] ? save_stack_trace+0x27/0x44
	 [] ? check_usage_backwards+0xa0/0xa0
	 [] mark_lock+0x11b/0x212
	 [] __lock_acquire+0x2d4/0xe48
	 [] ? check_usage_backwards+0xa0/0xa0
	 [] ? check_usage_forwards+0x4c/0xa6
	 [] ? __local_bh_enable_ip+0xaf/0xd9
	 [] lock_acquire+0x82/0x9d
	 [] ? clip_add+0x2c/0x116 [cxgb4]
	 [] ? rcu_read_unlock+0x23/0x23 [cxgb4]
	 [] _raw_spin_lock+0x34/0x43
	 [] ? clip_add+0x2c/0x116 [cxgb4]
	 [] ? rcu_lock_acquire.constprop.40+0x2e/0x30 [cxgb4]
	 [] ? rcu_read_unlock+0x23/0x23 [cxgb4]
	 [] clip_add+0x2c/0x116 [cxgb4]
	 [] cxgb4_inet6addr_handler+0x117/0x12c [cxgb4]
	 [] ? lock_acquire+0x94/0x9d
	 [] ? raw_notifier_call_chain+0x11/0x11
	 [] notifier_call_chain+0x32/0x5c
	 [] __atomic_notifier_call_chain+0x44/0x6e
	 [] atomic_notifier_call_chain+0xf/0x11
	 [] inet6addr_notifier_call_chain+0x16/0x18
	 [] ipv6_add_addr+0x404/0x46e [ipv6]
	 [] ? trace_hardirqs_on+0xd/0xf
	 [] addrconf_prefix_rcv+0x385/0x6ea [ipv6]
	 [] ndisc_rcv+0x9d3/0xd76 [ipv6]
	 [] icmpv6_rcv+0x592/0x67b [ipv6]
	 [] ? __local_bh_enable_ip+0xaa/0xd9
	 [] ? __local_bh_enable_ip+0xaa/0xd9
	 [] ? lock_release+0x14e/0x17b
	 [] ? rcu_read_unlock+0x21/0x23 [ipv6]
	 [] ? rcu_read_unlock+0x23/0x23
	 [] ip6_input_finish+0x1e4/0x2fc [ipv6]
	 [] ip6_input+0x33/0x38 [ipv6]
	 [] ip6_mc_input+0x147/0x160 [ipv6]
	 [] ip6_rcv_finish+0x7c/0x81 [ipv6]
	 [] ipv6_rcv+0x3a1/0x3e2 [ipv6]
	 [] __netif_receive_skb_core+0x4ab/0x511
	 [] ? mark_held_locks+0x71/0x99
	 [] ? process_backlog+0x69/0x15e
	 [] __netif_receive_skb+0x49/0x5b
	 [] process_backlog+0x78/0x15e
	 [] ? net_rx_action+0x1a2/0x1cc
	 [] net_rx_action+0xac/0x1cc
	 [] ? __do_softirq+0xad/0x218
	 [] __do_softirq+0xf5/0x218
	 [] do_softirq_own_stack+0x1c/0x30
	   [] do_softirq+0x38/0x5d
	 [] ? ip6_copy_metadata+0x156/0x156 [ipv6]
	 [] __local_bh_enable_ip+0x9d/0xd9
	 [] rcu_read_unlock_bh+0x2d/0x2f [ipv6]
	 [] ip6_finish_output2+0x381/0x3d8 [ipv6]
	 [] ip6_finish_output+0x6e/0x73 [ipv6]
	 [] ip6_output+0x7c/0xa8 [ipv6]
	 [] dst_output+0x18/0x1c
	 [] ip6_local_out+0x1c/0x21
	 [] ip6_push_pending_frames+0x37d/0x427 [ipv6]
	 [] ? skb_orphan+0x39/0x39
	 [] ? rawv6_sendmsg+0x74b/0xa4d [ipv6]
	 [] rawv6_sendmsg+0x942/0xa4d [ipv6]
	 [] inet_sendmsg+0x3d/0x66
	 [] __sock_sendmsg_nosec+0x25/0x27
	 [] sock_sendmsg+0x5a/0x7b
	 [] ? lock_release+0x14e/0x17b
	 [] ? might_fault+0x9e/0xa5
	 [] ? might_fault+0x55/0xa5
	 [] ? copy_from_user+0x2a/0x2c
	 [] ___sys_sendmsg+0x226/0x2d9
	 [] ? __lock_acquire+0x5ee/0xe48
	 [] ? trace_hardirqs_on_caller+0x145/0x1a1
	 [] ? slab_free_hook.isra.71+0x50/0x59
	 [] ? release_pages+0xbc/0x181
	 [] ? lock_acquire+0x94/0x9d
	 [] ? read_seqcount_begin.constprop.25+0x73/0x90
	 [] __sys_sendmsg+0x3d/0x5b
	 [] SyS_sendmsg+0xd/0x19
	 [] system_call_fastpath+0x1a/0x1f

Reported-by: Ben Greear 
Cc: Casey Leedom 
Cc: Hariprasad Shenai 
Signed-off-by: Li RongQing 
Signed-off-by: Eric Dumazet 
Acked-by: Casey Leedom 
Signed-off-by: David S. Miller

be2net: fix qnq mode detection on VFs

2014-06-23T21:46:54+00:00

The driver (on PF or VF) needs to detect if the function is in qnq mode for
a HW hack in be_rx_compl_get() to work.

The driver queries this information using the GET_PROFILE_CONFIG cmd
(since the commit below can caused this regression.) But this cmd is not
available on VFs and so the VFs fail to detect qnq mode. This causes
vlan traffic to not work.

The fix is to use the the adapter->function_mode value queried via
QUERY_FIRMWARE_CONFIG cmd on both PFs and VFs to detect the qnq mode.

Also QNQ_MODE was incorrectly named FLEX10_MODE; correcting that too as the
fix reads much better with the name change.

Fixes: f93f160b5 ("refactor multi-channel config code for Skyhawk-R chip")

Signed-off-by: Suresh Reddy 
Signed-off-by: Sathya Perla 
Signed-off-by: David S. Miller

at86rf230: fix irq setup

2014-06-23T01:04:03+00:00

Commit 8eba0eefae24953962067 ("at86rf230: remove irq_type in
request_irq") removed the trigger configuration when requesting an irq,
and instead relied on the interrupt trigger to be properly configured
already. This does not seem to be an assumption that can be safely made,
since boards disable all interrupt triggers on boot.

On these boards, force the irq to trigger on rising edge, which is also
the default for the chip.

Signed-off-by: Phoebe Buckheister 
Signed-off-by: David S. Miller

net: phy: at803x: fix coccinelle warnings

2014-06-23T00:16:02+00:00

drivers/net/phy/at803x.c:196:26-32: ERROR: application of sizeof to pointer

 sizeof when applied to a pointer typed expression gives the size of
 the pointer

Generated by: scripts/coccinelle/misc/noderef.cocci

Signed-off-by: Fengguang Wu 
Acked-by: Daniel Mack 
Signed-off-by: David S. Miller

net/mlx4_core: Fix the error flow when probing with invalid VF configuration

2014-06-23T00:13:40+00:00

Single ported VF are currently not supported on configurations where
one or both ports are IB. When we hit this case, the relevant flow in
the driver didn't return error and jumped to the wrong label. Fix that.

Fixes: dd41cc3 ('net/mlx4: Adapt num_vfs/probed_vf params for single port VF')
Reported-by: Shirley Ma 
Signed-off-by: Or Gerlitz 
Signed-off-by: David S. Miller

tulip: Poll link status more frequently for Comet chips

2014-06-23T00:12:36+00:00

It now takes up to 60 seconds to detect cable (un)plug on ADMtek Comet chips.
That's too slow and might cause people to think that it doesn't work at all.

Poll link status every 2 seconds instead of 60 for ADMtek Comet chips.
That should be fast enough while not stressing the system too much.

Tested with ADMtek AN983B.

Signed-off-by: Ondrej Zary 
Signed-off-by: David S. Miller