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

tg3: Release tp->lock before invoking synchronize_irq()

2015-01-14T22:05:51+00:00

synchronize_irq() can sleep waiting, for pending IRQ handlers so driver
should release the tp->lock spin lock before invoking synchronize_irq()

Reported-by: Peter Hurley 
Tested-by: Peter Hurley 
Signed-off-by: Prashant Sreedharan 
Signed-off-by: Michael Chan 
Signed-off-by: David S. Miller

tg3: tg3_reset_task() needs to use rtnl_lock to synchronize

2015-01-14T22:05:51+00:00

Currently tg3_reset_task() uses only tp->lock for synchronizing with code
paths like tg3_open() etc. But since tp->lock is released before doing
synchronize_irq(), rtnl_lock should be taken in tg3_reset_task() to
synchronize it with other code paths.

Reported-by: Peter Hurley 
Tested-by: Peter Hurley 
Signed-off-by: Prashant Sreedharan 
Signed-off-by: Michael Chan 
Signed-off-by: David S. Miller

tg3: tg3_timer() should grab tp->lock before checking for tp->irq_sync

2015-01-14T22:05:50+00:00

This is to avoid the race between tg3_timer() and the execution paths
which does not invoke tg3_timer_stop() and releases tp->lock before
calling synchronize_irq()

Reported-by: Peter Hurley 
Tested-by: Peter Hurley 
Signed-off-by: Prashant Sreedharan 
Signed-off-by: Michael Chan 
Signed-off-by: David S. Miller

team: avoid possible underflow of count_pending value for notify_peers and mcast_rejoin

2015-01-14T21:53:57+00:00

This patch is fixing a race condition that may cause setting
count_pending to -1, which results in unwanted big bulk of arp messages
(in case of "notify peers").

Consider following scenario:

count_pending == 2
   CPU0                                           CPU1
					team_notify_peers_work
					  atomic_dec_and_test (dec count_pending to 1)
					  schedule_delayed_work
 team_notify_peers
   atomic_add (adding 1 to count_pending)
					team_notify_peers_work
					  atomic_dec_and_test (dec count_pending to 1)
					  schedule_delayed_work
					team_notify_peers_work
					  atomic_dec_and_test (dec count_pending to 0)
   schedule_delayed_work
					team_notify_peers_work
					  atomic_dec_and_test (dec count_pending to -1)

Fix this race by using atomic_dec_if_positive - that will prevent
count_pending running under 0.

Fixes: fc423ff00df3a1955441 ("team: add peer notification")
Fixes: 492b200efdd20b8fcfd  ("team: add support for sending multicast rejoins")
Signed-off-by: Jiri Pirko 
Signed-off-by: Jiri Benc 
Signed-off-by: David S. Miller

i40e: adds FCoE configure option

2015-01-14T21:48:39+00:00

Adds FCoE config option I40E_FCOE, so that FCoE can be enabled
as needed but otherwise have it disabled by default.

This also eliminate multiple FCoE config checks, instead now just
one config check for CONFIG_I40E_FCOE.

The I40E FCoE was added with 3.17 kernel and therefore this patch
shall be applied to stable 3.17 kernel also.

CC: 
Signed-off-by: Vasu Dev 
Tested-by: Jim Young 
Signed-off-by: Jeff Kirsher 
Signed-off-by: David S. Miller

cxgb4vf: Fix queue allocation for 40G adapter

2015-01-14T21:48:08+00:00

Signed-off-by: Hariprasad Shenai 
Signed-off-by: David S. Miller

net: fec: fix MDIO bus assignement for dual fec SoC's

2015-01-14T05:27:10+00:00

On i.MX28, the MDIO bus is shared between the two FEC instances.
The driver makes sure that the second FEC uses the MDIO bus of the
first FEC. This is done conditionally if FEC_QUIRK_ENET_MAC is set.
However, in newer designs, such as Vybrid or i.MX6SX, each FEC MAC
has its own MDIO bus. Simply removing the quirk FEC_QUIRK_ENET_MAC
is not an option since other logic, triggered by this quirk, is
still needed.

Furthermore, there are board designs which use the same MDIO bus
for both PHY's even though the second bus would be available on the
SoC side. Such layout are popular since it saves pins on SoC side.
Due to the above quirk, those boards currently do work fine. The
boards in the mainline tree with such a layout are:
- Freescale Vybrid Tower with TWR-SER2 (vf610-twr.dts)
- Freescale i.MX6 SoloX SDB Board (imx6sx-sdb.dts)

This patch adds a new quirk FEC_QUIRK_SINGLE_MDIO for i.MX28, which
makes sure that the MDIO bus of the first FEC is used in any case.

However, the boards above do have a SoC with a MDIO bus for each FEC
instance. But the PHY's are not connected in a 1:1 configuration. A
proper device tree description is needed to allow the driver to
figure out where to find its PHY. This patch fixes that shortcoming
by adding a MDIO bus child node to the first FEC instance, along
with the two PHY's on that bus, and making use of the phy-handle
property to add a reference to the PHY's.

Acked-by: Sascha Hauer 
Signed-off-by: Stefan Agner 
Signed-off-by: David S. Miller

xen-netfront: use different locks for Rx and Tx stats

2015-01-13T22:22:11+00:00

In netfront the Rx and Tx path are independent and use different
locks.  The Tx lock is held with hard irqs disabled, but Rx lock is
held with only BH disabled.  Since both sides use the same stats lock,
a deadlock may occur.

  [ INFO: possible irq lock inversion dependency detected ]
  3.16.2 #16 Not tainted
  ---------------------------------------------------------
  swapper/0/0 just changed the state of lock:
   (&(&queue->tx_lock)->rlock){-.....}, at: []
  xennet_tx_interrupt+0x14/0x34
  but this lock took another, HARDIRQ-unsafe lock in the past:
   (&stat->syncp.seq#2){+.-...}
  and interrupts could create inverse lock ordering between them.
  other info that might help us debug this:
   Possible interrupt unsafe locking scenario:

         CPU0                    CPU1
         ----                    ----
    lock(&stat->syncp.seq#2);
                                 local_irq_disable();
                                 lock(&(&queue->tx_lock)->rlock);
                                 lock(&stat->syncp.seq#2);
    
      lock(&(&queue->tx_lock)->rlock);

Using separate locks for the Rx and Tx stats fixes this deadlock.

Reported-by: Dmitry Piotrovsky 
Signed-off-by: David Vrabel 
Signed-off-by: David S. Miller

drivers: net: cpsw: fix multicast flush in dual emac mode

2015-01-13T21:54:23+00:00

Since ALE table is a common resource for both the interfaces in Dual EMAC
mode and while bringing up the second interface in cpsw_ndo_set_rx_mode()
all the multicast entries added by the first interface is flushed out and
only second interface multicast addresses are added. Fixing this by
flushing multicast addresses based on dual EMAC port vlans which will not
affect the other emac port multicast addresses.

Fixes: d9ba8f9 (driver: net: ethernet: cpsw: dual emac interface implementation)
Cc:  # v3.9+
Signed-off-by: Mugunthan V N 
Signed-off-by: David S. Miller

cxgb4vf: Initialize mdio_addr before using it

2015-01-13T21:31:52+00:00

In commit 5ad24def21b205a8 ("cxgb4vf: Fix ethtool get_settings for VF driver")
mdio_addr of port_info structure was used unininitialzed. Fixing it.

Signed-off-by: Hariprasad Shenai 
Signed-off-by: David S. Miller