John W. Linville says:

====================
pull request: wireless 2014-09-11

Please pull this batch of fixes intended for the 3.17 stream:

For the mac80211 bits, Johannes says:

"Two more fixes for mac80211 - one of them addresses a long-standing
issue that we only found when using vendor events more frequently;
the other addresses some bad information being reported in userspace
that people were starting to actually look at."

For the iwlwifi bits, Emmanuel says:

"I re-enable scheduled scan on firmware that contain the fix for
the bug that Linus reported.  A few trivial fixes: endianity issues,
the same DTIM period fix that I did in mac80211.  Eyal fixes a few
issues we identified with EAPOL, we now send them just as if they were
management frames, this solves interrop issues.  Johannes has another
set of trivial fixes, while Luca fixes the way we configure the filters
in the firmware. Last but not least, a new device is added by Oren."

Emmanuel was traveling, resulting in his pull to be a bit larger than
I would have liked to see at this point.  FWIW, I have asked Emmanuel
to be much more strict for any more pull requests in this cycle.

In addition to the above, Sujith Manoharan reverts an earlier ath9k
patch.  The earlier change was found to allow for the device to sleep
too long and miss beacons.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>

Marc Kleine-Budde says:

====================
pull-request: can 2014-09-11

this is a pull request for the current release cycle of a single patch.

The patch by David Jander fixes a scheduling while atomic problem in the
flexcan driver, that was introduced by me in v3.14-rc6.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>

If we try to rmmod the driver for an interface while sockets with
setsockopt(JOIN_ANYCAST) are alive, some refcounts aren't cleaned up
and we get stuck on:

  unregister_netdevice: waiting for ens3 to become free. Usage count = 1

If we LEAVE_ANYCAST/close everything before rmmod'ing, there is no
problem.

We need to perform a cleanup similar to the one for multicast in
addrconf_ifdown(how == 1).
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>

Beniamino Galvani says:

====================
net: arc_emac: fix tx issues

the patches below solve some issues found in the tx ring reclaim
strategy currently implemented in the arc_emac driver.

Without these patches a simple outgoing UDP flow blocks almost
immediately with the socket send buffer full, until some new rx
packets trigger a clean of the tx ring.

Everything seems to work fine on a Radxa Rock with this fix applied.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>

This patch changes the logic in tx path to ensure that tx descriptors
are reused for transmission only after they have been reclaimed by
arc_emac_tx_clean().
Signed-off-by: Beniamino Galvani <b.galvani@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

In the current implementation the cleaning of tx ring is done by the
NAPI poll handler, which is scheduled after rx interrupts. Thus, in
absence of received packets the reclaim of used tx buffers is never
executed, blocking further transmission.

This can be easily reproduced starting the transmission of a UDP flow
with iperf, which blocks almost immediately because skbs are not
returned to the stack and the socket send buffer becomes full.

The patch enables tx interrupts so that the tx reclaim is scheduled
after completed transmissions.
Signed-off-by: Beniamino Galvani <b.galvani@gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

This reverts commit 09ebb810.

ath9k_hw_set_sta_beacon_timers() configures AR_TIM_PERIOD with
the beacon interval. Before this commit, the sleepduration was
never greater than the beacon interval. But now, the behavior
has changed. For example, with an AP that uses a beacon interval of 100:

ath: phy9: next beacon 61128704
ath: phy9: beacon period 204800
ath: phy9: DTIM period 204800

If the sleepduration is calculated based on the listen time, then
the bmiss threshold should also be changed since the HW would
be in sleep state for a longer time, but that is not done currently.

To avoid configuring a higher beacon interval based on the sleepduration,
revert to the original behavior. Power consumption is not a
problem since PS is disabled in ath9k anyway.

Cc: stable@vger.kernel.org
Cc: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Apparently can_restart() runs from a (timer-) interrupt and can call
flexcan_chip_[en|dis]able(), so avoid using usleep_range()
Signed-off-by: David Jander <david@protonic.nl>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>

MIPS supports BPF JIT since v3.16-rc1

Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Daniel Borkmann <dborkman@redhat.com>
Cc: Alexei Starovoitov <ast@plumgrid.com>
Cc: linux-doc@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Acked-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
Acked-by: Alexei Starovoitov <ast@plumgrid.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

We wrongly tested QP context bits without BE conversion
as was spotted by sparse...

drivers/infiniband/hw/mlx4/qp.c:1685:38: sparse: restricted __be32 degrades to integer

Fix that!

Fixes: d2fce8a9 ('mlx4: Set user-space raw Ethernet QPs to properly handle VXLAN traffic')
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Or Gerlitz says:

====================
mlx4 SRIOV fixes

This series contains few SRIOV related fixes from Matan, please apply to net.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>

Changing the vlan stripping policy of the QP isn't supported by older
firmware versions for the INIT2RTR command. Nevertheless, we've used it.

Fix that by doing this policy change using INIT2RTR only if the firmware
supports it, otherwise, we call UPDATE_QP command to do the task.

Fixes: 7677fc9 ('net/mlx4: Strengthen VLAN tags/priorities enforcement in VST mode')
Signed-off-by: Matan Barak <matanb@mellanox.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

The current wrapper implementation of the UPDATE_QP command tries to get
the MAC index, even if MAC wasn't set by the VF. Fix it up to only handle
the MAC field if it's valid.

Fixes: ce8d9e0d ('net/mlx4_core: Add UPDATE_QP SRIOV wrapper support')
Signed-off-by: Matan Barak <matanb@mellanox.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

When doing VGT->VST->VGT state changes, we used an incorrect mask
for the vlan-stripping-disable (VSD) flag, hence the vlan related policy
for user-space Raw Ethernet QPs open by VFs wasn't really applied.

Fix that, by using the correct mask.

Fixes: f0f829bf ('net/mlx4_core: Add immediate activate for VGT->VST->VGT')
Signed-off-by: Matan Barak <matanb@mellanox.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Single port VFs are seen PCI wise on both ports of the PF (we don't have
single port PFs with ConnectX). With this in mind, it's possible for
virtualization tools to try and configure a single ported VF through
the "wrong" PF port.

To handle that, we use the PF driver mapping of single port VFs to NIC
ports and adjust the port value before calling into the low level
code that does the actual VF configuration

Fixes: 449fc488 ('net/mlx4: Adapt code for N-Port VF')
Signed-off-by: Matan Barak <matanb@mellanox.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

In Dual EMAC, when both interface are up and while doing ifdown with heavy
traffic then skbs already processed by DMA from that slave emac has to be
requeued as still the other interface is up and running.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Fix a missing __user annotation in a cast of a user space pointer (found by
checker).
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

This patch adds missing space between "interface" and "by"
in bonding module parameter description.
Signed-off-by: Masanari Iida <standby24x7@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Linux manpage for recvmsg and sendmsg calls does not explicitly mention setting msg_namelen to 0 when
msg_name passed set as NULL. When developers don't set msg_namelen member in msghdr, it might contain garbage
value which will fail the validation check and sendmsg and recvmsg calls from kernel will return EINVAL. This will
break old binaries and any code for which there is no access to source code.
To fix this, we set msg_namelen to 0 when msg_name is passed as NULL from userland.
Signed-off-by: Ani Sinha <ani@arista.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Merge tag 'mac80211-for-john-2014-09-08' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211

Johannes Berg <johannes@sipsolutions.net> says:

"Two more fixes for mac80211 - one of them addresses a long-standing
issue that we only found when using vendor events more frequently;
the other addresses some bad information being reported in userspace
that people were starting to actually look at."
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Florian Fainelli says:

====================
net: systemport and bcmgenet OOM fixes

These two patches fix similar Out of Memory code paths in the SYSTEMPORT and
GENET drivers. Under high memory pressure, we could produce an OOPS by
passing a NULL pointer to dma_unmap_single().
====================
Signed-off-by: David S. Miller <davem@davemloft.net>

There is a potential case where we might be failing to refill a
control block, leaving it with both a NULL skb pointer *and* a NULL
dma_unmap_addr.

The way we process incoming packets, by first calling
dma_unmap_single(), and then only checking for a potential NULL skb can
lead to situations where do pass a NULL dma_unmap_addr() to
dma_unmap_single(), resulting in an oops.

Fix this my moving the NULL skb check earlier, since no backing skb
also means no corresponding DMA mapping for this packet.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

There is a potential case where we might be failing to refill a
control block, leaving it with both a NULL skb pointer *and* a NULL
dma_unmap_addr.

The way we process incoming packets, by first calling
dma_unmap_single(), and then only checking for a potential NULL skb can
lead to situations where do pass a NULL dma_unmap_addr() to
dma_unmap_single(), resulting in an oops.

Fix this my moving the NULL skb check earlier, since no backing skb
also means no corresponding DMA mapping for this packet.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

The driver does not support pause autonegotiation so it should return
-EINVAL when the function is called with non-zero autoneg.

Cc: Amir Vadai <amirv@mellanox.com>
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Fix the following compiler warning:

drivers/net/ethernet/octeon/octeon_mgmt.c: In function 'octeon_mgmt_clean_tx_buffers':
drivers/net/ethernet/octeon/octeon_mgmt.c:295:4: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
    u64 ns = cvmx_read_csr(CVMX_MIXX_TSTAMP(p->port));
    ^
Signed-off-by: Aaro Koskinen <aaro.koskinen@nsn.com>
Acked-by: David Daney <david.daney@cavium.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

In commit d9b2938a ("net: attempt a single high order allocation)
I forgot to update kerneldoc, as @prio parameter was renamed to @gfp
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

The sunvnet driver does not have an rmb() in the ring consumer corresponding
to the wmb() in the producer. According to Documentation/memory-barriers.txt:

"When dealing with CPU-CPU interactions, certain types of memory barrier should
always be paired.  A lack of appropriate pairing is almost certainly an error."

In cases where an rmb() is not a no-op and a consumer is removing data from
the ring while a producer is adding new entries, a load reorder would allow

CPU1						CPU2
----						----
						LOAD desc.size [e.g]
STORE desc.size
<wmb>
set desc.hdr.state = VIO_DESC_READY
						LOAD desc.hdr.state
						[because VIO_DESC_READY, use
						 old desc.size, already loaded
						 out of order]

[CPU2 has reordered apparently unrelated LOADs]

To ensure other desc fields are not loaded before checking VIO_DESC_READY, we
need an rmb() between the check and desc data accesses.

I've also moved the viodbg() call to after the rmb() so that it, too, has
current descriptor data even with reordering, which has the side effect that
it won't print anything for descriptors that are not VIO_DESC_READY as before.
That's a) probably a good thing, since the fields are not necessarily set and,
b) better than adding another rmb() just for viodbg().

This would not be possible if strict-ordering is enforced, but then the
memory barriers should be no-ops in that case.
Signed-off-by: David L Stevens <david.stevens@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

The idea here is to translate a value of 0 received from
the firmware to the lowest rssi figure. As rx_status->chain_signal
is a signed byte the lowest possible value is -128 and not -256.
-256 was causing 0 to get stored in the signed byte.
Signed-off-by: Eyal Shapira <eyalx.shapira@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

This change does the following:
1) Add a new 7265 series PCI ID
2) Add two new 3160 series PCI IDs
3) Add the new 3165 series PCI IDs and configurations
Signed-off-by: Oren Givon <oren.givon@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

Pull s390 fixes from Martin Schwidefsky:
 "A bug fix for the vdso code, the loadparm for booting from SCSI is
  added and the access permissions for the dasd module parameters are
  corrected"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
  s390/vdso: remove NULL pointer check from clock_gettime
  s390/ipl: Add missing SCSI loadparm attributes to /sys/firmware
  s390/dasd: Make module parameter visible in sysfs

In
https://bugzilla.kernel.org/show_bug.cgi?id=84031,
the submitter said that disabling power saving helped,
do just that.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

smps_mode is used uninitialized in a debug statement in AP
mode, so always initialize it.

While at it, fix a typo.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-by: Luciano Coelho <luciano.coelho@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

The latter is meant for software implementation of power
save and is not per-virtual interface. Since our driver
supports multiple virtual interfaces, we need to use
vif->bss_conf.dtim_period.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

Using the LQ table which is initially set according to
the rssi could lead to EAPOLs being sent in high legacy
rates like 54mbps.
It's better to avoid sending EAPOLs in high rates as it reduces
the chances of a successful 4-Way handshake.
Avoid this and treat them like other mgmt frames which would
initially get sent at the basic rate.

Cc: <stable@vger.kernel.org> [3.13+]
Signed-off-by: Eyal Shapira <eyalx.shapira@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

When mac80211 requests multiple BSS config changes, as for example
while associating, we ignore power management and QoS changes and
only apply them later. Fix that by removing the "else" and making
the conditions independent.

Also move it after (potential) beacon filter enablement to have
that already enabled when going into power management code.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

The chip is able to transmit up to 22dBm, so set
the constant appropriately.

CC: <stable@vger.kernel.org> [3.13+]
Signed-off-by: Eliad Peller <eliadx.peller@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

This code was broken on big endian systems. Sparse didn't
catch the bug since the firmware command was not tagged as
little endian.
Fix the bug for big endian systems and tag the field in the
firmware command to prevent such issues in the future.

Cc: stable@vger.kernel.org [3.14+]
Fixes: 1f3b0ff8 ("iwlwifi: mvm: Add Smart FIFO support")
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

In commit cad3f08c (iwlwifi: mvm: enable MAC_FILTER_IN_BEACON when
forced_assoc_off is set) the code to set the MAC_FILTER_IN_BEACON flag
was accidentally moved to the main block of the if statement, while it
should be in the else block instead.  Move it to the right place.

Fixes: cad3f08c ("iwlwifi: mvm: enable MAC_FILTER_IN_BEACON when forced_assoc_off is set")
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>

The variable 'u32 mode' exists twice, the latter shadowing
the former - remove the latter since there's no need for
two variables.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>