litmus-rt-imx6.git/drivers/net/ethernet/marvell, branch master

net: ethernet: remove unnecessary platform_set_drvdata()

2014-04-16T13:00:58+00:00

The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.

Signed-off-by: Jingoo Han 
Acked-by: Nicolas Ferre 
Acked-by: Rob Herring 
Acked-by: Roland Stigge 
Acked-by: Mugunthan V N 
Reviewed-by: H Hartley Sweeten 
Tested-by: Roland Stigge 
Signed-off-by: David S. Miller

net: mv643xx_eth: fix orphaned statistics timer crash

2013-11-04T12:31:00+00:00

[ Upstream commit f564412c935111c583b787bcc18157377b208e2e ]

The periodic statistics timer gets started at port _probe() time, but
is stopped on _stop() only. In a modular environment, this can cause
the timer to access already deallocated memory, if the module is unloaded
without starting the eth device. To fix this, we add the timer right
before the port is started, instead of at _probe() time.

Signed-off-by: Sebastian Hesselbarth 
Acked-by: Jason Cooper 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: mv643xx_eth: update statistics timer from timer context only

2013-11-04T12:31:00+00:00

[ Upstream commit 041b4ddb84989f06ff1df0ca869b950f1ee3cb1c ]

Each port driver installs a periodic timer to update port statistics
by calling mib_counters_update. As mib_counters_update is also called
from non-timer context, we should not reschedule the timer there but
rather move it to timer-only context.

Signed-off-by: Sebastian Hesselbarth 
Acked-by: Jason Cooper 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: mvneta: properly disable HW PHY polling and ensure adjust_link() works

2013-09-14T13:54:56+00:00

[ Upstream commit 714086029116b6b0a34e67ba1dd2f0d1cf26770c ]

This commit fixes a long-standing bug that has been reported by many
users: on some Armada 370 platforms, only the network interface that
has been used in U-Boot to tftp the kernel works properly in
Linux. The other network interfaces can see a 'link up', but are
unable to transmit data. The reports were generally made on the Armada
370-based Mirabox, but have also been given on the Armada 370-RD
board.

The network MAC in the Armada 370/XP (supported by the mvneta driver
in Linux) has a functionality that allows it to continuously poll the
PHY and directly update the MAC configuration accordingly (speed,
duplex, etc.). The very first versions of the driver submitted for
review were using this hardware mechanism, but due to this, the driver
was not integrated with the kernel phylib. Following reviews, the
driver was changed to use the phylib, and therefore a software based
polling. In software based polling, Linux regularly talks to the PHY
over the MDIO bus, and sees if the link status has changed. If it's
the case then the adjust_link() callback of the driver is called to
update the MAC configuration accordingly.

However, it turns out that the adjust_link() callback was not
configuring the hardware in a completely correct way: while it was
setting the speed and duplex bits correctly, it wasn't telling the
hardware to actually take into account those bits rather than what the
hardware-based PHY polling mechanism has concluded. So, in fact the
adjust_link() callback was basically a no-op.

However, the network happened to be working because on the network
interfaces used by U-Boot for tftp on Armada 370 platforms because the
hardware PHY polling was enabled by the bootloader, and left enabled
by Linux. However, the second network interface not used for tftp (or
both network interfaces if the kernel is loaded from USB, NAND or SD
card) didn't had the hardware PHY polling enabled.

This patch fixes this situation by:

 (1) Making sure that the hardware PHY polling is disabled by clearing
     the MVNETA_PHY_POLLING_ENABLE bit in the MVNETA_UNIT_CONTROL
     register in the driver ->probe() function.

 (2) Making sure that the duplex and speed selections made by the
     adjust_link() callback are taken into account by clearing the
     MVNETA_GMAC_AN_SPEED_EN and MVNETA_GMAC_AN_DUPLEX_EN bits in the
     MVNETA_GMAC_AUTONEG_CONFIG register.

This patch has been tested on Armada 370 Mirabox, and now both network
interfaces are usable after boot.

[ Problem introduced by commit c5aff18 ("net: mvneta: driver for
  Marvell Armada 370/XP network unit") ]

Signed-off-by: Thomas Petazzoni 
Cc: Willy Tarreau 
Cc: Jochen De Smet 
Cc: Peter Sanford 
Cc: Ethan Tuttle 
Cc: Chény Yves-Gael 
Cc: Ryan Press 
Cc: Simon Guinot 
Cc: vdonnefort@lacie.com
Cc: stable@vger.kernel.org
Acked-by: Jason Cooper 
Tested-by: Vincent Donnefort 
Tested-by: Yves-Gael Cheny 
Tested-by: Gregory CLEMENT 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

mv643xx_eth: Allocate receive queue initialized to zero

2013-06-20T05:18:52+00:00

Zero pointer in rx_skb is how respective rxq_deinit() finds out out that a skb
slot is unallocated. If rxq_refill() fails (e.g. on OOM condition), subsequent
teardown would result in an attempt to kfree() invalid pointers.

Signed-off-by: Lubomir Rintel 
Cc: Lennert Buytenhek 
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: David S. Miller

pxa168_eth: Allocate receive queue initialized to zero

2013-06-20T05:18:52+00:00

Zero pointer in rx_skb or tx_skb is how respective *_deinit() functions find
out that a skb slot is unallocated. If *_init() functions unsuccessfully return
after the allocation (e.g. when subsequent dma_alloc_coherent() is not
successful), this would result in attempt to kfree() invalid pointers.

Signed-off-by: Lubomir Rintel 
Cc: Kosta Zertsekel 
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: David S. Miller

NET: mv643xx_eth: avoid lockdep dump on interface down

2013-05-16T21:56:21+00:00

When the interface is shutdown, the mv643xx_eth driver hits the following
lockdep dump:

=================================
[ INFO: inconsistent lock state ]
3.8.0+ #303 Not tainted
---------------------------------
inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
NetworkManager/3449 [HC0[0]:SC0[0]:HE1:SE1] takes:
 (_xmit_ETHER#2){+.?...}, at: [] txq_reclaim+0x60/0x230
{IN-SOFTIRQ-W} state was registered at:
  [] mark_irqflags+0xf8/0x1c4
  [] __lock_acquire+0x458/0x9a4
  [] lock_acquire+0x60/0x74
  [] _raw_spin_lock+0x40/0x50
  [] sch_direct_xmit+0xa4/0x2e4
  [] dev_queue_xmit+0x174/0x508
  [] ip6_finish_output2+0xd0/0x3c4
  [] mld_sendpack+0x190/0x368
  [] mld_ifc_timer_expire+0xc/0x58
  [] call_timer_fn+0x6c/0xe0
  [] run_timer_softirq+0x1d8/0x210
  [] __do_softirq+0xe0/0x1b4
  [] irq_exit+0x64/0x6c
  [] handle_IRQ+0x34/0x84
  [] __irq_usr+0x30/0x80
irq event stamp: 160603
hardirqs last  enabled at (160603): [] kfree+0xa8/0xe8
hardirqs last disabled at (160602): [] kfree+0x1c/0xe8
softirqs last  enabled at (160304): [] mib_counters_update+0x5ec/0x60c
softirqs last disabled at (160302): [] _raw_spin_lock_bh+0x14/0x54

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

       CPU0
       ----
  lock(_xmit_ETHER#2);
  
    lock(_xmit_ETHER#2);

 *** DEADLOCK ***

1 lock held by NetworkManager/3449:
 #0:  (rtnl_mutex){+.+.+.}, at: [] rtnetlink_rcv+0xc/0x24

stack backtrace:
[] (unwind_backtrace+0x0/0xf8) from [] (print_usage_bug+0x150/0x1d4)
[] (print_usage_bug+0x150/0x1d4) from [] (mark_lock_irq+0x248/0x290)
[] (mark_lock_irq+0x248/0x290) from [] (mark_lock+0x158/0x404)
[] (mark_lock+0x158/0x404) from [] (mark_irqflags+0x138/0x1c4)
[] (mark_irqflags+0x138/0x1c4) from [] (__lock_acquire+0x458/0x9a4)
[] (__lock_acquire+0x458/0x9a4) from [] (lock_acquire+0x60/0x74)
[] (lock_acquire+0x60/0x74) from [] (_raw_spin_lock+0x40/0x50)
[] (_raw_spin_lock+0x40/0x50) from [] (txq_reclaim+0x60/0x230)
[] (txq_reclaim+0x60/0x230) from [] (txq_deinit+0x24/0xcc)
[] (txq_deinit+0x24/0xcc) from [] (mv643xx_eth_stop+0x1a8/0x1bc)
[] (mv643xx_eth_stop+0x1a8/0x1bc) from [] (__dev_close_many+0x88/0xcc)
[] (__dev_close_many+0x88/0xcc) from [] (__dev_close+0x28/0x3c)
[] (__dev_close+0x28/0x3c) from [] (__dev_change_flags+0x7c/0x134)
[] (__dev_change_flags+0x7c/0x134) from [] (dev_change_flags+0x10/0x48)
[] (dev_change_flags+0x10/0x48) from [] (do_setlink+0x1a0/0x730)
[] (do_setlink+0x1a0/0x730) from [] (rtnl_newlink+0x304/0x4b0)
[] (rtnl_newlink+0x304/0x4b0) from [] (rtnetlink_rcv_msg+0x25c/0x2a0)
[] (rtnetlink_rcv_msg+0x25c/0x2a0) from [] (netlink_rcv_skb+0xbc/0xd8)
[] (netlink_rcv_skb+0xbc/0xd8) from [] (rtnetlink_rcv+0x1c/0x24)
[] (rtnetlink_rcv+0x1c/0x24) from [] (netlink_unicast_kernel+0x88/0xd4)
[] (netlink_unicast_kernel+0x88/0xd4) from [] (netlink_unicast+0x138/0x180)
[] (netlink_unicast+0x138/0x180) from [] (netlink_sendmsg+0x208/0x32c)
[] (netlink_sendmsg+0x208/0x32c) from [] (sock_sendmsg+0x84/0xa4)
[] (sock_sendmsg+0x84/0xa4) from [] (__sys_sendmsg+0x2ac/0x2c4)
[] (__sys_sendmsg+0x2ac/0x2c4) from [] (sys_sendmsg+0x3c/0x68)
[] (sys_sendmsg+0x3c/0x68) from [] (ret_fast_syscall+0x0/0x3c)

It seems that txq_reclaim() takes the netif tx lock:

        __netif_tx_lock(nq, smp_processor_id());

in a context outside of softirq context, and thus is susceptible to
deadlock should an interrupt occur.

Use __netif_tx_lock_bh()/__netif_tx_unlock_bh() instead.

Signed-off-by: Russell King 
Signed-off-by: David S. Miller

mv643xx_eth: fix NAPI weight being > 64

2013-05-14T18:32:05+00:00

3.10-rc1 issues the following warning:

netif_napi_add() called with weight 128 on device eth%d

This patch reduce the weight to 64, using NAPI_POLL_WEIGHT.

Signed-off-by: Andrew Lunn 
Acked-by: Eric Dumazet 
Signed-off-by: David S. Miller

sky2: Fix crash on receiving VLAN frames

2013-05-03T20:10:34+00:00

After recent 86a9bad3 (net: vlan: add protocol argument to packet
tagging functions) my sky2 started to crash on receive of tagged
frames, with backtrace similar to

    #CRASH!!!
    vlan_do_receive
    __netif_receive_skb_core
    __netif_receive_skb
    netif_receive_skb
    sky2_poll
    ...
    __net_rx_action
    __do_softirq

The problem turned out to be:

    1) sky2 copies small packets from ring on RX, and in its
       receive_copy() skb header is copied manually field, by field, and
       only for some fields;

    2) 86a9bad3  added skb->vlan_proto, which vlan_untag() or
       __vlan_hwaccel_put_tag() set, and which is later used in
       vlan_do_receive().

       That patch updated copy_skb_header() for newly introduced
       skb->vlan_proto, but overlooked the need to also copy it in sky2's
       receive_copy().

Because of 2, we have the following scenario:

    - frame is received and tagged in a ring, by sky2_rx_tag(). Both
      skb->vlan_proto and skb->vlan_tci are set;

    - later skb is decided to be copied, but skb->vlan_proto is
      forgotten and becomes 0.

    - in the beginning of vlan_do_receive() we call

        __be16 vlan_proto = skb->vlan_proto;
        vlan_dev = vlan_find_dev(skb->dev, vlan_proto, vlan_id);

      which eventually invokes

        vlan_proto_idx(vlan_proto)

      and that routine BUGs for everything except ETH_P_8021Q and
      ETH_P_8021AD.

      Oops.

Fix it.

P.S.

Stephen, I wonder, why copy_skb_header() is not used in
sky2.c::receive_copy() ? Problems, where receive_copy was updated field
by field showed several times already, e.g.

    3f42941b    (sky2: propogate rx hash when packet is copied)
    e072b3fa    (sky2: fix receive length error in mixed non-VLAN/VLAN traffic)

Cc: Patrick McHardy 
Cc: Stephen Hemminger 
Cc: Mirko Lindner 
Signed-off-by: Kirill Smelkov 
Acked-by: Stephen Hemminger 
Signed-off-by: David S. Miller

Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net

2013-04-23T00:32:51+00:00

Conflicts:
	drivers/net/ethernet/emulex/benet/be_main.c
	drivers/net/ethernet/intel/igb/igb_main.c
	drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c
	include/net/scm.h
	net/batman-adv/routing.c
	net/ipv4/tcp_input.c

The e{uid,gid} --> {uid,gid} credentials fix conflicted with the
cleanup in net-next to now pass cred structs around.

The be2net driver had a bug fix in 'net' that overlapped with the VLAN
interface changes by Patrick McHardy in net-next.

An IGB conflict existed because in 'net' the build_skb() support was
reverted, and in 'net-next' there was a comment style fix within that
code.

Several batman-adv conflicts were resolved by making sure that all
calls to batadv_is_my_mac() are changed to have a new bat_priv first
argument.

Eric Dumazet's TS ECR fix in TCP in 'net' conflicted with the F-RTO
rewrite in 'net-next', mostly overlapping changes.

Thanks to Stephen Rothwell and Antonio Quartulli for help with several
of these merge resolutions.

Signed-off-by: David S. Miller