A buggy or malicious frontend should not be able to confuse netback.
If we spot anything which is not as it should be then shutdown the
device and don't try to continue with the ring in a potentially
hostile state. Well behaved and non-hostile frontends will not be
penalised.

As well as making the existing checks for such errors fatal also add a
new check that ensures that there isn't an insane number of requests
on the ring (i.e. more than would fit in the ring). If the ring
contains garbage then previously is was possible to loop over this
insane number, getting an error each time and therefore not generating
any more pending requests and therefore not exiting the loop in
xen_netbk_tx_build_gops for an externded period.

Also turn various netdev_dbg calls which no precipitate a fatal error
into netdev_err, they are rate limited because the device is shutdown
afterwards.

This fixes at least one known DoS/softlockup of the backend domain.
Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
Reviewed-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Acked-by: NJan Beulich <JBeulich@suse.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

It is normal for minidrivers accumulating frames to return NULL
from their tx_fixup function. We do not want to count this as a
drop, or log any debug messages.  A different exit path is
therefore chosen for such drivers, skipping the debug message
and the tx_dropped increment.

The test for accumulating drivers was however completely bogus,
making the exit path selection depend on whether the user had
enabled tx_err logging or not. This would arbitrarily mess up
accounting for both accumulating and non-accumulating minidrivers,
and would result in unwanted debug messages for the accumulating
drivers.

Fix by testing for FLAG_MULTI_PACKET instead, which probably was
the intention from the beginning.  This usage match the documented
behaviour of this flag:

 Indicates to usbnet, that USB driver accumulates multiple IP packets.
 Affects statistic (counters) and short packet handling.
Signed-off-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

1) rhine_tx() should use dev_kfree_skb() not dev_kfree_skb_irq()

2) rhine_slow_event_task's NAPI triggering logic is racey, it
   should just hit the interrupt mask register.  This is the
   same as commit 7dbb4918
   ("r8169: avoid NAPI scheduling delay.") made to fix the same
   problem in the r8169 driver.  From Francois Romieu.
Reported-by: NJamie Gloudon <jamie.gloudon@gmail.com>
Tested-by: NJamie Gloudon <jamie.gloudon@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

According to C_CAN documentation, the reserved bit in IFx_MASK2 register is
fixed 1.

Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: NAlexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

Add VID, PID and fixed interface for Telit LE920
Signed-off-by: NDaniele Palmas <dnlplm@gmail.com>
Acked-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

A device sending 0 length frames as fast as it can has been
observed killing the host system due to the resulting memory
pressure.

Temporarily disable RX skb allocation and URB submission when
the current error ratio is high, preventing us from trying to
allocate an infinite number of skbs.  Reenable as soon as we
are finished processing the done queue, allowing the device
to continue working after short error bursts.
Signed-off-by: NBjørn Mork <bjorn@mork.no>
Acked-by: NOliver Neukum <oneukum@suse.de>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

A scan request is split into multiple scan commands queued in
scan_pending_q. Each scan command will be sent to firmware and
its response is handlded one after another.

If any error is detected while parsing IE in command response
buffer the remaining data will be ignored and error is returned.

We should check if there is any more scan commands pending in
the queue before returning error. This ensures that we will call
cfg80211_scan_done if this is the last scan command, or send
next scan command in scan_pending_q to firmware.

Cc: "3.6+" <stable@vger.kernel.org>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

vmxnet3 fails to set netif_carrier_off on probe, meaning that when an interface
is opened the __LINK_STATE_NOCARRIER bit is already cleared, and so
/sys/class/net/<ifname>/operstate remains in the unknown state.  Correct this by
setting netif_carrier_off on probe, like other drivers do.

Also, while we're at it, lets remove the netif_carrier_ok checks from the
link_state_update function, as that check is atomically contained within the
netif_carrier_[on|off] functions anyway

Tested successfully by myself
Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
CC: "David S. Miller" <davem@davemloft.net>
CC: "VMware, Inc." <pv-drivers@vmware.com>
CC: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

In rare instances, memory errors have been detected in the internal packet
buffer memory on I217/I218 when stressed under certain environmental
conditions.  Enable Error Correcting Code (ECC) in hardware to catch both
correctable and uncorrectable errors.  Correctable errors will be handled
by the hardware.  Uncorrectable errors in the packet buffer will cause the
packet to be received with an error indication in the buffer descriptor
causing the packet to be discarded.  If the uncorrectable error is in the
descriptor itself, the hardware will stop and interrupt the driver
indicating the error.  The driver will then reset the hardware in order to
clear the error and restart.

Both types of errors will be accounted for in statistics counters.
Signed-off-by: NBruce Allan <bruce.w.allan@intel.com>
Cc: <stable@vger.kernel.org> # 3.5.x & 3.6.x
Tested-by: NJeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When bonding module is loaded with primary parameter and one decides to unset
primary slave using sysfs these settings are not preserved during bond device
restart. Primary slave is only unset once and it's not remembered in
bond->params structure. Below is example of recreation.

 grep OPTS /etc/sysconfig/network-scripts/ifcfg-bond0
BONDING_OPTS="mode=active-backup miimon=100 primary=eth01"
 grep "Primary Slave" /proc/net/bonding/bond0
Primary Slave: eth01 (primary_reselect always)

 echo "" > /sys/class/net/bond0/bonding/primary
 grep "Primary Slave" /proc/net/bonding/bond0
Primary Slave: None

 sed -i -e 's/primary=eth01//' /etc/sysconfig/network-scripts/ifcfg-bond0
 grep OPTS /etc/sysconfig/network-scripts/ifcfg-bond
BONDING_OPTS="mode=active-backup miimon=100 "
 ifdown bond0 && ifup bond0

without patch:
 grep "Primary Slave" /proc/net/bonding/bond0
Primary Slave: eth01 (primary_reselect always)

with patch:
 grep "Primary Slave" /proc/net/bonding/bond0
Primary Slave: None
Reviewed-by: NJiri Pirko <jiri@resnulli.us>
Signed-off-by: NMilos Vyletel <milos.vyletel@sde.cz>
Signed-off-by: NJay Vosburgh <fubar@us.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NSarveshwar Bandi <sarveshwar.bandi@emulex.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

We forbid polling, writing and reading when the file were detached, this may
complex the user in several cases:

- when guest pass some buffers to vhost/qemu and then disable some queues,
  host/qemu needs to do its own cleanup on those buffers which is complex
  sometimes. We can do this simply by allowing a user can still write to an
  disabled queue. Write to an disabled queue will cause the packet pass to the
  kernel and read will get nothing.
- align the polling behavior with macvtap which never fails when the queue is
  created. This can simplify the polling errors handling of its user (e.g vhost)

We can simply achieve this by don't assign NULL to tfile->tun when detached.
Signed-off-by: NJason Wang <jasowang@redhat.com>
Acked-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Commit c8d68e6b removed carrier off call
from tun_detach since it's now called on queue disable and not only on
tun close.  This confuses userspace which used this flag to detect a
free tun. To fix, put this back but under if (clean).
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Tested-by: NJason Wang <jasowang@redhat.com>
Acked-by: NJason Wang <jasowang@redhat.com>
Tested-by: NToralf Förster <toralf.foerster@gmx.de>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

In routine _rtl_rx_pre_process(), skb_dequeue() is called to get an skb;
however, the wrong variable name is used in subsequent calls.
Reported-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Stable <stable@vger.kernel.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This issue was reported on the wireless list (see [1]) in which
brcmsmac ran into a fatal error:

[  588.284074] brcmsmac bcma0:0: frameid != txh->TxFrameID
[  588.284098] brcmsmac bcma0:0: MI_TFS: fatal
[  588.284103] brcmsmac bcma0:0: wl0: fatal error, reinitializing
[  588.286208] ieee80211 phy0: Hardware restart was requested

The tx status feedback is processed in a loop limiting the number of
frames processed in one run. The code terminate processing when the
limit is reached regardless the txstatus value read from the device
register. When that status is is flagged as being valid it must be
processed as the hardware will clear it after is has been read.

Bisecting was done by Seth Forshee and showed following commit as the
culprit:

commit 57fe5048
Author: Piotr Haber <phaber@broadcom.com>
Date:   Wed Nov 28 21:44:07 2012 +0100

    brcmsmac: fix bounds checking in tx/rx

[1] http://www.spinics.net/lists/linux-wireless/msg101293.htmlReported-by: NLinus Torvalds <torvalds@linux-foundation.org>
Tested-by: NSeth Forshee <seth.forshee@canonical.com>
Reviewed-by: NHante Meuleman <meuleman@broadcom.com>
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

dm9620 is a newer variant of dm9601 with more features (usb 2.0, checksum
offload, ..), but it can also be put in a dm9601 compatible mode, allowing
us to reuse the existing driver.

This does mean that the extended features like checksum offload cannot be
used, but that's hardly critical on a 100mbps interface.

Thanks to Sławek Wernikowski <slawek@wernikowski.net> for providing me
with a dm9620 based device to test.
Signed-off-by: NPeter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch fixes the setting of the INTR pin that is
valid for IP101 A/G device and not for the IP1001.
Reported-by: NAnunay Saxena <anunay.saxena@st.com>
Signed-off-by: NGiuseppe Cavallaro <peppe.cavallaro@st.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Like several other PHY devices which support RGMII, the IC+1001 allows
additional delays to by added to the RX_CLK and TX_CLK signals to
compensate for skew between the clock and data signals. Previously this
was always enabled, but this change makes use of the different RGMII
interface modes to allow the user to specify whether this should be
enabled.
Signed-off-by: NStuart Menefy <stuart.menefy@st.com>
Signed-off-by: NGiuseppe Cavallaro <peppe.cavallaro@st.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Control of receive descriptor must not be returned to ethernet chipset
before vlan tag processing is done.

VLAN tag receive word is now reset both in normal and error path.
Signed-off-by: NFrancois Romieu <romieu@fr.zoreil.com>
Spotted-by: NTimo Teras <timo.teras@iki.fi>
Cc: Hayes Wang <hayeswang@realtek.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

commit 9992c2e2 (net: cdc_ncm: workaround for missing CDC Union)
added code to lookup an IAD for the interface we are probing.
This is redundant.  The USB core has already done the lookup
and saved the result in the USB interface struct.  Use that
instead.

Cc: Greg Suarez <gsuarez@smithmicro.com>
Cc: Alexey Orishko <alexey.orishko@stericsson.com>
Signed-off-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Ben Greear reported crashes in ip_rcv_finish() on a stress
test involving many macvlans.

We tracked the bug to a dst use after free. ip_rcv_finish()
was calling dst->input() and got garbage for dst->input value.

It appears the bug is in loopback driver, lacking
a skb_dst_force() before calling netif_rx().

As a result, a non refcounted dst, normally protected by a
RCU read_lock section, was escaping this section and could
be freed before the packet being processed.

  [<ffffffff813a3c4d>] loopback_xmit+0x64/0x83
  [<ffffffff81477364>] dev_hard_start_xmit+0x26c/0x35e
  [<ffffffff8147771a>] dev_queue_xmit+0x2c4/0x37c
  [<ffffffff81477456>] ? dev_hard_start_xmit+0x35e/0x35e
  [<ffffffff8148cfa6>] ? eth_header+0x28/0xb6
  [<ffffffff81480f09>] neigh_resolve_output+0x176/0x1a7
  [<ffffffff814ad835>] ip_finish_output2+0x297/0x30d
  [<ffffffff814ad6d5>] ? ip_finish_output2+0x137/0x30d
  [<ffffffff814ad90e>] ip_finish_output+0x63/0x68
  [<ffffffff814ae412>] ip_output+0x61/0x67
  [<ffffffff814ab904>] dst_output+0x17/0x1b
  [<ffffffff814adb6d>] ip_local_out+0x1e/0x23
  [<ffffffff814ae1c4>] ip_queue_xmit+0x315/0x353
  [<ffffffff814adeaf>] ? ip_send_unicast_reply+0x2cc/0x2cc
  [<ffffffff814c018f>] tcp_transmit_skb+0x7ca/0x80b
  [<ffffffff814c3571>] tcp_connect+0x53c/0x587
  [<ffffffff810c2f0c>] ? getnstimeofday+0x44/0x7d
  [<ffffffff810c2f56>] ? ktime_get_real+0x11/0x3e
  [<ffffffff814c6f9b>] tcp_v4_connect+0x3c2/0x431
  [<ffffffff814d6913>] __inet_stream_connect+0x84/0x287
  [<ffffffff814d6b38>] ? inet_stream_connect+0x22/0x49
  [<ffffffff8108d695>] ? _local_bh_enable_ip+0x84/0x9f
  [<ffffffff8108d6c8>] ? local_bh_enable+0xd/0x11
  [<ffffffff8146763c>] ? lock_sock_nested+0x6e/0x79
  [<ffffffff814d6b38>] ? inet_stream_connect+0x22/0x49
  [<ffffffff814d6b49>] inet_stream_connect+0x33/0x49
  [<ffffffff814632c6>] sys_connect+0x75/0x98

This bug was introduced in linux-2.6.35, in commit
7fee226a (net: add a noref bit on skb dst)

skb_dst_force() is enforced in dev_queue_xmit() for devices having a
qdisc.
Reported-by: NBen Greear <greearb@candelatech.com>
Signed-off-by: NEric Dumazet <edumazet@google.com>
Tested-by: NBen Greear <greearb@candelatech.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Add a cpu notifier to virtio-net, so that we can reset the
virtqueue affinity if the cpu hotplug happens. It improve
the performance through enabling or disabling the virtqueue
affinity after doing cpu hotplug.

Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Jason Wang <jasowang@redhat.com>
Cc: Eric Dumazet <erdnetdev@gmail.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: virtualization@lists.linux-foundation.org
Cc: netdev@vger.kernel.org
Signed-off-by: NWanlong Gao <gaowanlong@cn.fujitsu.com>
Acked-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Split out the clean affinity function to virtnet_clean_affinity().

Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Jason Wang <jasowang@redhat.com>
Cc: Eric Dumazet <erdnetdev@gmail.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: virtualization@lists.linux-foundation.org
Cc: netdev@vger.kernel.org
Signed-off-by: NWanlong Gao <gaowanlong@cn.fujitsu.com>
Acked-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

As Michael mentioned, set affinity and select queue will not work very
well when CPU IDs are not consecutive, this can happen with hot unplug.
Fix this bug by traversal the online CPUs, and create a per cpu variable
to find the mapping from CPU to the preferable virtual-queue.

Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Jason Wang <jasowang@redhat.com>
Cc: Eric Dumazet <erdnetdev@gmail.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: virtualization@lists.linux-foundation.org
Cc: netdev@vger.kernel.org
Signed-off-by: NWanlong Gao <gaowanlong@cn.fujitsu.com>
Acked-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Errors in CAN protocol (location) are reported in data[3] of the can
frame instead of data[2].

Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: NOlivier Sobrie <olivier@sobrie.be>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

Errors in CAN protocol (location) are reported in data[3] of the can
frame instead of data[2].

Cc: linux-stable <stable@vger.kernel.org>
Cc: Anant Gole <anantgole@ti.com>
Signed-off-by: NOlivier Sobrie <olivier@sobrie.be>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

Errors in CAN protocol (location) are reported in data[3] of the can
frame instead of data[2].

Cc: linux-stable <stable@vger.kernel.org>
Cc: Bhupesh Sharma <bhupesh.sharma@st.com>
Signed-off-by: NOlivier Sobrie <olivier@sobrie.be>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

This reverts commit f590dcec
which has been reported to cause issues.

See https://lkml.org/lkml/2013/1/20/4 for further details.

Cc: stable@vger.kernel.org [3.7]
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This was introduced in commit 6dccd16b "r8169: merge with version
6.001.00 of Realtek's r8169 driver". I did not find the version
6.001.00 online, but in 6.002.00 or any later r8169 from Realtek
this hunk is no longer present.

Also commit 05af2142 "r8169: fix Ethernet Hangup for RTL8110SC
rev d" claims to have fixed this issue otherwise.

The magic compare mask of 0xfffe000 is dubious as it masks
parts of the Reserved part, and parts of the VLAN tag. But this
does not make much sense as the VLAN tag parts are perfectly
valid there. In matter of fact this seems to be triggered with
any VLAN tagged packet as RxVlanTag bit is matched. I would
suspect 0xfffe0000 was intended to test reserved part only.

Finally, this hunk is evil as it can cause more packets to be
handled than what was NAPI quota causing net/core/dev.c:
net_rx_action(): WARN_ON_ONCE(work > weight) to trigger, and
mess up the NAPI state causing device to hang.

As result, any system using VLANs and having high receive
traffic (so that NAPI poll budget limits rtl_rx) would result
in device hang.
Signed-off-by: NTimo Teräs <timo.teras@iki.fi>
Acked-by: NFrancois Romieu <romieu@fr.zoreil.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

We create new flow caches when a new flow is identified by tuntap, This may lead
some issues:

- userspace may produce a huge amount of short live flows to exhaust host memory
- the unlimited number of flow caches may produce a long list which increase the
  time in the linear searching

Solve this by introducing a limit of total number of flow caches.

Cc: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: NJason Wang <jasowang@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

A MAX_TAP_QUEUES(1024) queues of tuntap device is always allocated
unconditionally even userspace only requires a single queue device. This is
unnecessary and will lead a very high order of page allocation when has a high
possibility to fail. Solving this by creating a one queue net device when
userspace only use one queue and also reduce MAX_TAP_QUEUES to
DEFAULT_MAX_NUM_RSS_QUEUES which can guarantee the success of
the allocation.
Reported-by: NDirk Hohndel <dirk@hohndel.org>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: NJason Wang <jasowang@redhat.com>
Acked-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Reverting 328d7b8a and instead adding an exception for the
Sierra Wireless MC7710.

commit 328d7b8a (net: cdc_mbim: send ZLP after max sized NTBs)
added a workaround for an issue observed on one specific device.
Concerns were raised that this workaround adds a performance
penalty to all devices based on questionable, if not buggy,
behaviour of a single device:

 "If you add ZLP for NTBs of dwNtbOutMaxSize, you are heavily affecting CPU
  load, increasing interrupt load by factor of 2 in high load traffic
  scenario and possibly decreasing throughput for all other devices
  which behaves correctly."

 "The idea of NCM was to avoid extra ZLPs. If your transfer is exactly
  dwNtbOutMaxSize, it's known, you can submit such request on the receiver
  side and you do not need any EOT indicatation, so the frametime can be
  used for useful data."

Adding a device specific exception to prevent the workaround from
affecting well behaved devices.

The assumption here is that needing a ZLP is truly an *exception*.
We do not yet have enough data to verify this.  The generic
workaround in commit 328d7b8a should be considered acceptable despite
the performance penalty if the exception list becomes a maintainance
hassle.

Cc: Alexey ORISHKO <alexey.orishko@stericsson.com>
Cc: Yauheni Kaliuta <y.kaliuta@gmail.com>
Signed-off-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Add missing "!" as we are supposed to check "!card->adapter"
in PCIe suspend handler.

Cc: "3.2+" <stable@vger.kernel.org>
Signed-off-by: NAvinash Patil <patila@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Reviewed-by: NSergey V. <sftp.mtuci@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Cc: stable@vger.kernel.org
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Chain swapping should only be enabled when the EEPROM chainmask is set to 5,
regardless of what the runtime chainmask is.

Cc: stable@vger.kernel.org
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Cc: stable@vger.kernel.org
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The kbuild test robot reports the following warning with x86_64-randconfig-x955:

warning: (RTL8192CE && RTL8192SE && RTL8192DE && RTL8723AE && RTL8192CU) selects
 RTLWIFI which has unmet direct dependencies (NETDEVICES && WLAN &&
 (RTL8192CE || RTL8192CU || RTL8192SE || RTL8192DE))

This warning was introduced in commit a2905935, "rtlwifi: Modify files for addition
of rtl8723ae", and is d ue to a missing dependence of RTLWIFI on RTL8723AE.
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Cc: kbuild test robot <fengguang.wu@intel.com>
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We do not correctly change interface type when switching from
IBSS mode to STA mode, that results in microcode errors.

Resolves:
https://bugzilla.redhat.com/show_bug.cgi?id=886946Reported-by: NJaroslav Skarvada <jskarvad@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Christoph Paasch found netxen could trigger a BUG in its dismantle
phase, in netxen_release_tx_buffer(), using full size TSO packets.

cmd_buf->frag_count includes the skb->data part, so the loop must
start at index 1 instead of 0, or else we can make an out
of bound access to cmd_buff->frag_array[MAX_SKB_FRAGS + 2]

Christoph provided the fixes in netxen_map_tx_skb() function.
In case of a dma mapping error, its better to clear the dma fields
so that we don't try to unmap them again in netxen_release_tx_buffer()
Reported-by: NChristoph Paasch <christoph.paasch@uclouvain.be>
Signed-off-by: NEric Dumazet <edumazet@google.com>
Tested-by: NChristoph Paasch <christoph.paasch@uclouvain.be>
Cc: Sony Chacko <sony.chacko@qlogic.com>
Cc: Rajesh Borundia <rajesh.borundia@qlogic.com>
Signed-off-by: NChristoph Paasch <christoph.paasch@uclouvain.be>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Infineon(now Intel) HSPA Modem platform NCM cannot support ARP.
we can define a new common structure wwan_noarp_info.
Then more similiar NO ARP devices can be handled easily
Signed-off-by: NWei Shuai <cpuwolf@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>