On BE3, if the clear-interrupt bit of the EQ doorbell is not set the first
time it is armed, ocassionally we have observed that the EQ doesn't raise
anymore interrupts even if it is in armed state.
This patch fixes this by setting the clear-interrupt bit when EQs are
armed for the first time in be_open().
Signed-off-by: NSuresh Reddy <Suresh.Reddy@emulex.com>
Signed-off-by: NSathya Perla <sathya.perla@emulex.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

To get offloads to work with Generic Routing Encapsulation (GRE), the
outer transport header has to be reset after skb_push is done. This
patch has the support for this fix and hence GRE offloading.
Signed-off-by: NAmritha Nambiar <amritha.nambiar@intel.com>
Signed-off-by: NJoseph Gasparakis <joseph.gasparakis@intel.com>
Tested-By: NJim Young <jamesx.m.young@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

There are several issues in fst_add_one() and fst_init_card():
- invalid pointer dereference at card->ports[card->nports - 1] if
  register_hdlc_device() fails for the first port in fst_init_card();
- fst_card_array overflow at fst_card_array[no_of_cards_added]
  because there is no checks for array overflow;
- use after free because pointer to deallocated card is left in fst_card_array
  if something fails after fst_card_array[no_of_cards_added] = card;
- several leaks on failure paths in fst_add_one().

The patch fixes all the issues and makes code more readable.

Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: NAlexey Khoroshilov <khoroshilov@ispras.ru>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

John W. Linville says:

====================
pull request: wireless 2014-07-10

Please pull this batch of fixes intended for the 3.16 stream!

For the iwlwifi bits, Emmanuel says:

"I have here 2 patches that disable the usage of CTS to self. This
keeps making trouble to the firmware and is not a really reliable
protection anyway. We may re-enable it in the future, but in rarer
cases. Along with this, I have a fix from Ilan that prevents a
firmware assertion."

On top of that...

Amitkumar Karwar provides an mwifiex fix to properly initialize
(i.e. zero) tx_info/rx_info.

Andrea Merello stops rt2800usb from doing DMA operations on the
stack...yikes!
====================
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem

To properly re-initialize SR-IOV it is necessary to reset the device
even if it is already down. Not doing this may result in Tx unit hangs.

Cc: stable <stable@vger.kernel.org>
Signed-off-by: NStefan Assmann <sassmann@kpanic.de>
Tested-by: NAaron Brown <aaron.f.brown@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

On some devices, the internal PLL circuit occasionally provides the
wrong clock frequency after power up. The probability of failure is less
than one failure per 1000 power cycles. When the failure occurs, the
internal clock frequency is around 1/20 of the correct frequency.

Cc: stable <stable@vger.kernel.org>
Signed-off-by: NTodd Fujinaka <todd.fujinaka@intel.com>
Tested-by: NAaron Brown <aaron.f.brown@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The smsc95xx needs to resume with reset operation. Otherwise it causes
system hang by network error like below after resume. This case appears
on odroid u3 board.

[    9.727600] smsc95xx 1-2:1.0 eth0: kevent 2 may have been dropped
[    9.727648] smsc95xx 1-2:1.0 eth0: kevent 2 may have been dropped
[    9.727689] smsc95xx 1-2:1.0 eth0: kevent 2 may have been dropped
[    9.727728] smsc95xx 1-2:1.0 eth0: kevent 2 may have been dropped
[    9.729486] PM: resume of devices complete after 2011.219 msecs
[   10.117609] Restarting tasks ... done.
[   11.725099] smsc95xx 1-2:1.0 eth0: kevent 2 may have been dropped
[   13.480846] smsc95xx 1-2:1.0 eth0: kevent 2 may have been dropped
[   13.481361] smsc95xx 1-2:1.0 eth0: kevent 2 may have been dropped
...
Signed-off-by: NJoonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Currently status frames are only handled when packet timestamping is
enabled, but status frames are also needed for pin event timestamping.

Fix by moving packet timestamping check to after status frame decode.
Signed-off-by: NStefan Sørensen <stefan.sorensen@spectralink.com>
Acked-by: NRichard Cochran <richardcochran@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

For RTL8411, RTL8111G, RTL8402, RTL8105, and RTL8106, disable the feature
of entering the L2/L3 link state of the PCIe. When the nic starts the process
of entering the L2/L3 link state and the PCI reset occurs before the work
is finished, the work would be queued and continue after the next the PCI
reset occurs. This causes the device stays in L2/L3 link state, and the system
couldn't find the device.
Signed-off-by: NHayes Wang <hayeswang@realtek.com>
Acked-by: NFrancois Romieu <romieu@fr.zoreil.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

netlink_dump() returns a negative errno value on error.  Until now,
netlink_recvmsg() directly recorded that negative value in sk->sk_err, but
that's wrong since sk_err takes positive errno values.  (This manifests as
userspace receiving a positive return value from the recv() system call,
falsely indicating success.) This bug was introduced in the commit that
started checking the netlink_dump() return value, commit b44d211e (netlink:
handle errors from netlink_dump()).

Multithreaded Netlink dumps are one way to trigger this behavior in
practice, as described in the commit message for the userspace workaround
posted here:
    http://openvswitch.org/pipermail/dev/2014-June/042339.html

This commit also fixes the same bug in netlink_poll(), introduced in commit
cd1df525 (netlink: add flow control for memory mapped I/O).
Signed-off-by: NBen Pfaff <blp@nicira.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This commit fixes the command value generated for CSUM calculation
when running in big endian mode.  The Ethernet protocol ID for IP was
being unconditionally byte-swapped in the layer 3 protocol check (with
swab16), which caused the mvneta driver to not function correctly in
big endian mode.  This patch byte-swaps the ID conditionally with
htons.

Cc: <stable@vger.kernel.org> # v3.13+
Signed-off-by: NThomas Fitzsimmons <fitzsim@fitzsim.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

As reported by Maggie Mae Roxas, the mvneta driver doesn't behave
properly in 10 Mbit/s mode. This is due to a misconfiguration of the
MVNETA_GMAC_AUTONEG_CONFIG register: bit MVNETA_GMAC_CONFIG_MII_SPEED
must be set for a 100 Mbit/s speed, but cleared for a 10 Mbit/s speed,
which the driver was not properly doing. This commit adjusts that by
setting the MVNETA_GMAC_CONFIG_MII_SPEED bit only in 100 Mbit/s mode,
and relying on the fact that all the speed related bits of this
register are cleared at the beginning of the mvneta_adjust_link()
function.

This problem exists since c5aff182 ("net: mvneta: driver for
Marvell Armada 370/XP network unit") which is the commit that
introduced the mvneta driver in the kernel.

Cc: <stable@vger.kernel.org> # v3.8+
Fixes: c5aff182 ("net: mvneta: driver for Marvell Armada 370/XP network unit")
Reported-by: NMaggie Mae Roxas <maggie.mae.roxas@gmail.com>
Cc: Maggie Mae Roxas <maggie.mae.roxas@gmail.com>
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

It is recommended that TX work not count against the quota.
The cost of TX packet liberation is a minute percentage of what it costs to
process an RX frame. Furthermore, that SKB freeing makes memory available for
other paths in the stack.

Give the TX a larger budget and be more aggressive about cleaning up the Tx
descriptors this budget could be changed using ethtool:
$ ethtool -C eth1 tx-frames-irq <budget>
Signed-off-by: NAmir Vadai <amirv@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The device should be waked up from runtime suspend before dumping
the hw counter.
Signed-off-by: NHayes Wang <hayeswang@realtek.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Setting just skb->sk without taking its reference and setting a
destructor is invalid. However, in the places where this was done, skb
is used in a way not requiring skb->sk setting. So dropping the setting
of skb->sk.
Thanks to Eric Dumazet <eric.dumazet@gmail.com> for correct solution.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=79441Reported-by: NEd Martin <edman007@edman007.com>
Signed-off-by: NAndrey Utkin <andrey.krieger.utkin@gmail.com>
Signed-off-by: NEric Dumazet <edumazet@google.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch fixes 3 similar bugs where incoming packets might be routed into
wrong non-wildcard tunnels:

1) Consider the following setup:
    ip address add 1.1.1.1/24 dev eth0
    ip address add 1.1.1.2/24 dev eth0
    ip tunnel add ipip1 remote 2.2.2.2 local 1.1.1.1 mode ipip dev eth0
    ip link set ipip1 up

Incoming ipip packets from 2.2.2.2 were routed into ipip1 even if it has dst =
1.1.1.2. Moreover even if there was wildcard tunnel like
   ip tunnel add ipip0 remote 2.2.2.2 local any mode ipip dev eth0
but it was created before explicit one (with local 1.1.1.1), incoming ipip
packets with src = 2.2.2.2 and dst = 1.1.1.2 were still routed into ipip1.

Same issue existed with all tunnels that use ip_tunnel_lookup (gre, vti)

2)  ip address add 1.1.1.1/24 dev eth0
    ip tunnel add ipip1 remote 2.2.146.85 local 1.1.1.1 mode ipip dev eth0
    ip link set ipip1 up

Incoming ipip packets with dst = 1.1.1.1 were routed into ipip1, no matter what
src address is. Any remote ip address which has ip_tunnel_hash = 0 raised this
issue, 2.2.146.85 is just an example, there are more than 4 million of them.
And again, wildcard tunnel like
   ip tunnel add ipip0 remote any local 1.1.1.1 mode ipip dev eth0
wouldn't be ever matched if it was created before explicit tunnel like above.

Gre & vti tunnels had the same issue.

3)  ip address add 1.1.1.1/24 dev eth0
    ip tunnel add gre1 remote 2.2.146.84 local 1.1.1.1 key 1 mode gre dev eth0
    ip link set gre1 up

Any incoming gre packet with key = 1 were routed into gre1, no matter what
src/dst addresses are. Any remote ip address which has ip_tunnel_hash = 0 raised
the issue, 2.2.146.84 is just an example, there are more than 4 million of them.
Wildcard tunnel like
   ip tunnel add gre2 remote any local any key 1 mode gre dev eth0
wouldn't be ever matched if it was created before explicit tunnel like above.

All this stuff happened because while looking for a wildcard tunnel we didn't
check that matched tunnel is a wildcard one. Fixed.
Signed-off-by: NDmitry Popov <ixaphire@qrator.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

There is otherwise a risk of a possible null pointer dereference.

Was largely found by using a static code analysis program called cppcheck.
Signed-off-by: NRickard Strandqvist <rickard_strandqvist@spectrumdigital.se>

Since commit 37e22164 ("tipc: rename and
move message reassembly function") reassembly of long broadcast messages
has been broken. This is because we test for a non-NULL return value
of the *buf parameter as criteria for succesful reassembly. However, this
parameter is left defined even after reception of the first fragment,
when reassebly is still incomplete. This leads to a kernel crash as soon
as a the first fragment of a long broadcast message is received.

We fix this with this commit, by implementing a stricter behavior of the
function and its return values.

This commit should be applied to both net and net-next.
Signed-off-by: NJon Maloy <jon.maloy@ericsson.com>
Acked-by: NYing Xue <ying.xue@windriver.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch changes the IEEE 802.15.4 subsystem maintainer to Alexander Aring.
We discussed this change before via e-mail and I collected the acks from the
current maintainers.
Signed-off-by: NAlexander Aring <alex.aring@gmail.com>
Acked-by: NDmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Acked-by: NAlexander Smirnov <alex.bluesman.sminov@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

David Vrabel says:

====================
xen-netfront: multi-queue related locking fixes

Two fixes to the per-queue locking bugs in xen-netfront that were
introduced in 3.16-rc1 with the multi-queue support.
====================
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

In xennet_disconnect_backend(), netif_carrier_off() was called once
per queue when it needs to only be called once.

The queue locking around the netif_carrier_off() call looked very
odd. I think they were supposed to synchronize any NAPI instances with
the expectation that no further NAPI instances would be scheduled
because of the carrier being off (see the check in
xennet_rx_interrupt()).  But I can't easily tell if this works
correctly.

Instead, add a napi_synchronize() call after disabling the interrupts.
This is obviously correct as with no Rx interrupts, no further NAPI
instances will be scheduled.
Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The nesting of the per-queue rx_lock and tx_lock in xennet_connect()
is confusing to both humans and lockdep.  The locking is safe because
this is the only place where the locks are nested in this way but
lockdep still warns.

Instead of adding the missing lockdep annotations, refactor the
locking to avoid the confusing nesting.  This is still safe, because
the xenbus connection state changes are all serialized by the xenwatch
thread.
Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>
Reported-by: NSander Eikelenboom <linux@eikelenboom.it>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The undo code assumes that, upon entering loss recovery, TCP
1) always retransmit something
2) the retransmission never fails locally (e.g., qdisc drop)

so undo_marker is set in tcp_enter_recovery() and undo_retrans is
incremented only when tcp_retransmit_skb() is successful.

When the assumption is broken because TCP's cwnd is too small to
retransmit or the retransmit fails locally. The next (DUP)ACK
would incorrectly revert the cwnd and the congestion state in
tcp_try_undo_dsack() or tcp_may_undo(). Subsequent (DUP)ACKs
may enter the recovery state. The sender repeatedly enter and
(incorrectly) exit recovery states if the retransmits continue to
fail locally while receiving (DUP)ACKs.

The fix is to initialize undo_retrans to -1 and start counting on
the first retransmission. Always increment undo_retrans even if the
retransmissions fail locally because they couldn't cause DSACKs to
undo the cwnd reduction.
Signed-off-by: NYuchung Cheng <ycheng@google.com>
Signed-off-by: NNeal Cardwell <ncardwell@google.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The add_vxlan_port ndo driver code was wrongly testing whether HW vxlan offloads
are supported by the device instead of checking if they are currently enabled.

This causes the driver to configure the HW parser to conduct matching for vxlan
packets but since no steering rules were set, vxlan packets are dropped on RX.

Fix that by doing the right test, as done in the del_vxlan_port ndo handler.

Fixes: 1b136de1 ('net/mlx4: Implement vxlan ndo calls')
Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The problem was triggered by these steps:

1) create socket, bind and then setsockopt for add mc group.
   mreq.imr_multiaddr.s_addr = inet_addr("255.0.0.37");
   mreq.imr_interface.s_addr = inet_addr("192.168.1.2");
   setsockopt(sockfd, IPPROTO_IP, IP_ADD_MEMBERSHIP, &mreq, sizeof(mreq));

2) drop the mc group for this socket.
   mreq.imr_multiaddr.s_addr = inet_addr("255.0.0.37");
   mreq.imr_interface.s_addr = inet_addr("0.0.0.0");
   setsockopt(sockfd, IPPROTO_IP, IP_DROP_MEMBERSHIP, &mreq, sizeof(mreq));

3) and then drop the socket, I found the mc group was still used by the dev:

   netstat -g

   Interface       RefCnt Group
   --------------- ------ ---------------------
   eth2		   1	  255.0.0.37

Normally even though the IP_DROP_MEMBERSHIP return error, the mc group still need
to be released for the netdev when drop the socket, but this process was broken when
route default is NULL, the reason is that:

The ip_mc_leave_group() will choose the in_dev by the imr_interface.s_addr, if input addr
is NULL, the default route dev will be chosen, then the ifindex is got from the dev,
then polling the inet->mc_list and return -ENODEV, but if the default route dev is NULL,
the in_dev and ifIndex is both NULL, when polling the inet->mc_list, the mc group will be
released from the mc_list, but the dev didn't dec the refcnt for this mc group, so
when dropping the socket, the mc_list is NULL and the dev still keep this group.

v1->v2: According Hideaki's suggestion, we should align with IPv6 (RFC3493) and BSDs,
	so I add the checking for the in_dev before polling the mc_list, make sure when
	we remove the mc group, dec the refcnt to the real dev which was using the mc address.
	The problem would never happened again.
Signed-off-by: NDing Tianhong <dingtianhong@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

A bug was introduced in NETDEV_CHANGE notifier sequence causing the
arp table to be sometimes spuriously cleared (including manual arp
entries marked permanent), upon network link carrier changes.

The changed argument for the notifier was applied only to a single
caller of NETDEV_CHANGE, missing among others netdev_state_change().
So upon net_carrier events induced by the network, which are
triggering a call to netdev_state_change(), arp_netdev_event() would
decide whether to clear or not arp cache based on random/junk stack
values (a kind of read buffer overflow).

Fixes: be9efd36 ("net: pass changed flags along with NETDEV_CHANGE event")
Fixes: 6c8b4e3f ("arp: flush arp cache on IFF_NOARP change")
Signed-off-by: NLoic Prylli <loicp@google.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

There's a new version of the Telewell 4G modem working with, but not
recognized by this driver.
Signed-off-by: NBernd Wachter <bernd.wachter@jolla.com>
Acked-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This reverts commit 0acf1676.

Breaks the build due to missing reference to phy_resume in
the resulting dwmac-socfpga.o object.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

deal with a compile warning: comparison between
'enum qe_fltr_largest_external_tbl_lookup_key_size'
and 'enum qe_fltr_tbl_lookup_key_size'

the code:
	"if (ug_info->largestexternallookupkeysize ==
	     QE_FLTR_TABLE_LOOKUP_KEY_SIZE_8_BYTES)"
is warned because different enum, so modify it.

	"enum qe_fltr_largest_external_tbl_lookup_key_size
	             largestexternallookupkeysize;

	enum qe_fltr_tbl_lookup_key_size {
		 QE_FLTR_TABLE_LOOKUP_KEY_SIZE_8_BYTES
			 = 0x3f,         /* LookupKey parsed by the Generate LookupKey
					    CMD is truncated to 8 bytes */
		 QE_FLTR_TABLE_LOOKUP_KEY_SIZE_16_BYTES
			 = 0x5f,         /* LookupKey parsed by the Generate LookupKey
					    CMD is truncated to 16 bytes */
	 };

	 /* QE FLTR extended filtering Largest External Table Lookup Key Size */
	 enum qe_fltr_largest_external_tbl_lookup_key_size {
		 QE_FLTR_LARGEST_EXTERNAL_TABLE_LOOKUP_KEY_SIZE_NONE
			 = 0x0,/* not used */
		 QE_FLTR_LARGEST_EXTERNAL_TABLE_LOOKUP_KEY_SIZE_8_BYTES
			 = QE_FLTR_TABLE_LOOKUP_KEY_SIZE_8_BYTES,        /* 8 bytes */
		 QE_FLTR_LARGEST_EXTERNAL_TABLE_LOOKUP_KEY_SIZE_16_BYTES
			 = QE_FLTR_TABLE_LOOKUP_KEY_SIZE_16_BYTES,       /* 16 bytes */
	 };"
Signed-off-by: NZhao Qiang <B45475@freescale.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Pravin B Shelar says:

====================
Open vSwitch

A set of fixes for net.
First bug is related flow-table management.  Second one is in sample
action. Third is related flow stats and last one add gre-err handler for ovs.
====================
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

In process_backlog the input_pkt_queue is only checked once for new
packets and quota is artificially reduced to reflect precisely the
number of packets on the input_pkt_queue so that the loop exits
appropriately.

This patches changes the behavior to be more straightforward and
less convoluted. Packets are processed until either the quota
is met or there are no more packets to process.

This patch seems to provide a small, but noticeable performance
improvement. The performance improvement is a result of staying
in the process_backlog loop longer which can reduce number of IPI's.

Performance data using super_netperf TCP_RR with 200 flows:

Before fix:

88.06% CPU utilization
125/190/309 90/95/99% latencies
1.46808e+06 tps
1145382 intrs.sec.

With fix:

87.73% CPU utilization
122/183/296 90/95/99% latencies
1.4921e+06 tps
1021674.30 intrs./sec.
Signed-off-by: NTom Herbert <therbert@google.com>
Acked-by: NEric Dumazet <edumazet@google.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Some older router implementations still send Fragmentation Needed
errors with the Next-Hop MTU field set to zero. This is explicitly
described as an eventuality that hosts must deal with by the
standard (RFC 1191) since older standards specified that those
bits must be zero.

Linux had a generic (for all of IPv4) implementation of the algorithm
described in the RFC for searching a list of MTU plateaus for a good
value. Commit 46517008 ("ipv4: Kill ip_rt_frag_needed().")
removed this as part of the changes to remove the routing cache.
Subsequently any Fragmentation Needed packet with a zero Next-Hop
MTU has been discarded without being passed to the per-protocol
handlers or notifying userspace for raw sockets.

When there is a router which does not implement RFC 1191 on an
MTU limited path then this results in stalled connections since
large packets are discarded and the local protocols are not
notified so they never attempt to lower the pMTU.

One example I have seen is an OpenBSD router terminating IPSec
tunnels. It's worth pointing out that this case is distinct from
the BSD 4.2 bug which incorrectly calculated the Next-Hop MTU
since the commit in question dismissed that as a valid concern.

All of the per-protocols handlers implement the simple approach from
RFC 1191 of immediately falling back to the minimum value. Although
this is sub-optimal it is vastly preferable to connections hanging
indefinitely.

Remove the Next-Hop MTU != 0 check and allow such packets
to follow the normal path.

Fixes: 46517008 ("ipv4: Kill ip_rt_frag_needed().")
Signed-off-by: NEdward Allcutt <edward.allcutt@openmarket.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Function rt2800usb_autorun_detect() passes the address of a variable
allocated onto the stack to be used for DMA by the USB layer. This has
been caught by my debugging-enabled kernel.

This patch change things in order to allocate that variable via
kmalloc, and it adjusts things to handle the kmalloc failure case,
propagating the error.

[ 7363.238852] ------------[ cut here ]------------
[ 7363.243529] WARNING: CPU: 1 PID: 5235 at lib/dma-debug.c:1153 check_for_stack+0xa4/0xf0()
[ 7363.251759] ehci-pci 0000:00:04.1: DMA-API: device driver maps memory fromstack [addr=ffff88006b81bad4]
[ 7363.261210] Modules linked in: rt2800usb(O+) rt2800lib(O) rt2x00usb(O) rt2x00lib(O) rtl818x_pci(O) rtl8187 led_class eeprom_93cx6 mac80211 cfg80211 [last unloaded: rt2x00lib]
[ 7363.277143] CPU: 1 PID: 5235 Comm: systemd-udevd Tainted: G           O  3.16.0-rc3-wl+ #31
[ 7363.285546] Hardware name: System manufacturer System Product Name/M3N78 PRO, BIOS ASUS M3N78 PRO ACPI BIOS Revision 1402 12/04/2009
[ 7363.297511]  0000000000000009 ffff88006b81b710 ffffffff8175dcad ffff88006b81b758
[ 7363.305062]  ffff88006b81b748 ffffffff8106d372 ffff88006cf10098 ffff88006cead6a0
[ 7363.312622]  ffff88006b81bad4 ffffffff81c1e7c0 ffff88006cf10098 ffff88006b81b7a8
[ 7363.320161] Call Trace:
[ 7363.322661]  [<ffffffff8175dcad>] dump_stack+0x4d/0x6f
[ 7363.327847]  [<ffffffff8106d372>] warn_slowpath_common+0x82/0xb0
[ 7363.333893]  [<ffffffff8106d3e7>] warn_slowpath_fmt+0x47/0x50
[ 7363.339686]  [<ffffffff813a93b4>] check_for_stack+0xa4/0xf0
[ 7363.345298]  [<ffffffff813a995c>] debug_dma_map_page+0x10c/0x150
[ 7363.351367]  [<ffffffff81521bd9>] usb_hcd_map_urb_for_dma+0x229/0x720
[ 7363.357890]  [<ffffffff8152256d>] usb_hcd_submit_urb+0x2fd/0x930
[ 7363.363929]  [<ffffffff810eac31>] ? irq_work_queue+0x71/0xd0
[ 7363.369617]  [<ffffffff810ab5a7>] ? wake_up_klogd+0x37/0x50
[ 7363.375219]  [<ffffffff810ab7a5>] ? console_unlock+0x1e5/0x420
[ 7363.381081]  [<ffffffff810abc25>] ? vprintk_emit+0x245/0x530
[ 7363.386773]  [<ffffffff81523d3c>] usb_submit_urb+0x30c/0x580
[ 7363.392462]  [<ffffffff81524295>] usb_start_wait_urb+0x65/0xf0
[ 7363.398325]  [<ffffffff815243ed>] usb_control_msg+0xcd/0x110
[ 7363.404014]  [<ffffffffa005514d>] rt2x00usb_vendor_request+0xbd/0x170 [rt2x00usb]
[ 7363.411544]  [<ffffffffa0074292>] rt2800usb_autorun_detect+0x32/0x50 [rt2800usb]
[ 7363.418986]  [<ffffffffa0074aa1>] rt2800usb_read_eeprom+0x11/0x70 [rt2800usb]
[ 7363.426168]  [<ffffffffa0063ffd>] rt2800_probe_hw+0x11d/0xf90 [rt2800lib]
[ 7363.432989]  [<ffffffffa0074b7d>] rt2800usb_probe_hw+0xd/0x50 [rt2800usb]
[ 7363.439808]  [<ffffffffa00453d8>] rt2x00lib_probe_dev+0x238/0x7c0 [rt2x00lib]
[ 7363.446992]  [<ffffffffa00bfa48>] ? ieee80211_led_names+0xb8/0x100 [mac80211]
[ 7363.454156]  [<ffffffffa0056116>] rt2x00usb_probe+0x156/0x1f0 [rt2x00usb]
[ 7363.460971]  [<ffffffffa0074250>] rt2800usb_probe+0x10/0x20 [rt2800usb]
[ 7363.467616]  [<ffffffff8152799e>] usb_probe_interface+0xce/0x1c0
[ 7363.473651]  [<ffffffff81480c20>] really_probe+0x70/0x240
[ 7363.479079]  [<ffffffff81480f01>] __driver_attach+0xa1/0xb0
[ 7363.484682]  [<ffffffff81480e60>] ? __device_attach+0x70/0x70
[ 7363.490461]  [<ffffffff8147eef3>] bus_for_each_dev+0x63/0xa0
[ 7363.496146]  [<ffffffff814807c9>] driver_attach+0x19/0x20
[ 7363.501570]  [<ffffffff81480468>] bus_add_driver+0x178/0x220
[ 7363.507270]  [<ffffffff8148151b>] driver_register+0x5b/0xe0
[ 7363.512874]  [<ffffffff815271b0>] usb_register_driver+0xa0/0x170
[ 7363.518905]  [<ffffffffa007a000>] ? 0xffffffffa0079fff
[ 7363.524074]  [<ffffffffa007a01e>] rt2800usb_driver_init+0x1e/0x20 [rt2800usb]
[ 7363.531247]  [<ffffffff810002d4>] do_one_initcall+0x84/0x1b0
[ 7363.536932]  [<ffffffff8113aa60>] ? kfree+0xd0/0x110
[ 7363.541931]  [<ffffffff8112730a>] ? __vunmap+0xaa/0xf0
[ 7363.547538]  [<ffffffff810ca07e>] load_module+0x1aee/0x2040
[ 7363.553141]  [<ffffffff810c6f10>] ? store_uevent+0x50/0x50
[ 7363.558676]  [<ffffffff810ca66e>] SyS_init_module+0x9e/0xc0
[ 7363.564285]  [<ffffffff81764012>] system_call_fastpath+0x16/0x1b
[ 7363.570338] ---[ end trace 01ef5f822bea9882 ]---
Signed-off-by: NAndrea Merello <andrea.merello@gmail.com>
Acked-by: NHelmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

There are few places at the begining of Tx/Rx paths where
tx_info/rx_info is not correctly initialized. This patch
takes care of it.
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NAvinash Patil <patila@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Firmware folks seem say that this flag can make trouble.
Drop it. The advantage of CTS to self is that it slightly
reduces the cost of the protection, but make the protection
less reliable.

Cc: <stable@vger.kernel.org> [3.13+]
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

We should always prefer to use full RTS protection. Using
CTS to self gives a meaningless improvement, but this flow
is much harder for the firmware which is likely to have
issues with it.

CC: <stable@vger.kernel.org>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Vince Bridgers says:

====================
net: stmmac: Correct socfpga init/exit and

This patch series adds platform specific init/exit code so that socfpga
suspend/resume works as expected, and corrects a minor issue detected by
cppcheck.

V2: Address review comments by adding a line break at end of function and
    structure declaration. Add another trivial cppcheck patch.
====================
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Cppcheck found a case where a local variable was being assigned a value,
but not used. There seems to be no reason to read this register before
assigning a new value, so addressing thie issue.

cppcheck --force --enable=all --inline-suppr . shows ...

Variable 'value' is reassigned a value before the old one has been used.
Signed-off-by: NVince Bridgers <vbridgers2013@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>