For some reason it didn't coused obvious problems.
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
not sure why.
Initially provided by Ashish Patro <patro@cs.wisc.edu>
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
and rename exports from ath9k_spectral_* to ath9k_cmn_spectral_*
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Now we should be ready to make this code common.
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
last preparation before moving ath9k_spectral_scan_ to spectral.c
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
we don't have here any ieee80211_hw dependencies any way.
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
spectral code mostly depends on ath_hw, not on ath_softc
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
this will alow us to make ath_softc independent code.
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
and move rfs_chan_spec_scan to this struct. We will need it
for common spectral scan code.
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We see this warning while starting mwifiex AP:
Unsupported RX-STBC, default to 2x2
This was happening because of wrong offset while copying HT
capabilities from BSS configuration of start_ap handler.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
It is observed that device sometimes sends BA setup requests for
broadcast mac address.
This patch adds a check to avoid checking availability of
AMPDU/AMSDU streams for broadcast mac address.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
On some platforms, system goes out of memory during heavy
Rx traffic with our USB chipsets.
In case of SDIO/PCIe, after receiving 50 packets in Rx queue
we stop processing interrupts till packets pending fall below
low threshold i.e 20. We don't have similar logic for USB,
so if host platform is slow, we would hit a case where firmware
keeps on pushing packets at high speed than driver/kernel can
process.
We will stop submitting URBs for Rx data when pending packet
count reaches high threshold and restart them when enough
packets are consumed to solve the problem.
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=85071
Reported-by: Marek Belisko <marek.belisko@gmail.com>
Tested-by: Marek Belisko <marek.belisko@gmail.com>
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Cathy Luo <cluo@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch removes redundant data complete handler.
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Cathy Luo <cluo@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch adds RX workqueue support for USB interfaces.
Currently rx_pending is applicable for cmd/events and Rx
data in USB interface. Let's use it only for Rx data.
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Cathy Luo <cluo@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Track it per channel context instead of in the softc
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Based on the reference clock, which could be 25MHz or 40MHz,
AR_RTC_DERIVED_CLK is programmed differently for AR9340 and AR9550.
But, when a chip reset is done, processing the initvals
sets the register back to the default value.
Fix this by moving the code in ath9k_hw_init_pll() to
ar9003_hw_override_ini(). Also, do this override for AR9531.
Cc: stable@vger.kernel.org
Signed-off-by: Miaoqing Pan <miaoqing@qca.qualcomm.com>
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The function chandef_to_chanspec() failed when converting a
chandef with bandwidth set to NL80211_CHAN_WIDTH_20_NOHT. This
was reported by user running the device in AP mode.
------------[ cut here ]------------
WARNING: CPU: 0 PID: 304 at
drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c:381
chandef_to_chanspec.isra.11+0x158/0x184()
Modules linked in:
CPU: 0 PID: 304 Comm: hostapd Not tainted 3.16.0-rc7-abb+g64aa90f #8
[<c0014bb4>] (unwind_backtrace) from [<c0012314>] (show_stack+0x10/0x14)
[<c0012314>] (show_stack) from [<c001d3f8>] (warn_slowpath_common+0x6c/0x8c)
[<c001d3f8>] (warn_slowpath_common) from [<c001d4b4>] (warn_slowpath_null+0x1c/0x24)
[<c001d4b4>] (warn_slowpath_null) from [<c03449a4>] (chandef_to_chanspec.isra.11+0x158/0x184)
[<c03449a4>] (chandef_to_chanspec.isra.11) from [<c0348e00>] (brcmf_cfg80211_start_ap+0x1e4/0x614)
[<c0348e00>] (brcmf_cfg80211_start_ap) from [<c04d1468>] (nl80211_start_ap+0x288/0x414)
[<c04d1468>] (nl80211_start_ap) from [<c043d144>] (genl_rcv_msg+0x21c/0x38c)
[<c043d144>] (genl_rcv_msg) from [<c043c740>] (netlink_rcv_skb+0xac/0xc0)
[<c043c740>] (netlink_rcv_skb) from [<c043cf14>] (genl_rcv+0x20/0x34)
[<c043cf14>] (genl_rcv) from [<c043c0a0>] (netlink_unicast+0x150/0x20c)
[<c043c0a0>] (netlink_unicast) from [<c043c4b8>] (netlink_sendmsg+0x2b8/0x398)
[<c043c4b8>] (netlink_sendmsg) from [<c04066a4>] (sock_sendmsg+0x84/0xa8)
[<c04066a4>] (sock_sendmsg) from [<c0407c5c>] (___sys_sendmsg.part.29+0x268/0x278)
[<c0407c5c>] (___sys_sendmsg.part.29) from [<c0408bdc>] (__sys_sendmsg+0x4c/0x7c)
[<c0408bdc>] (__sys_sendmsg) from [<c000ec60>] (ret_fast_syscall+0x0/0x44)
---[ end trace 965ee2158c9905a2 ]---
Cc: stable@vger.kernel.org # v3.17
Reported-by: Pontus Fuchs <pontusf@broadcom.com>
Reviewed-by: Hante Meuleman <meuleman@broadcom.com>
Reviewed-by: Daniel (Deognyoun) Kim <dekim@broadcom.com>
Reviewed-by: Franky (Zhenhui) Lin <frankyl@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
RT2800 and newer hardware require padding between header and payload if
header length is not multiple of 4.
For historical reasons we also align payload to to 4 bytes boundary, but
such alignment is not needed on modern H/W.
Patch fixes skb_under_panic problems reported from time to time:
https://bugzilla.kernel.org/show_bug.cgi?id=84911https://bugzilla.kernel.org/show_bug.cgi?id=72471http://marc.info/?l=linux-wireless&m=139108549530402&w=2https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1087591
Panic happened because we eat 4 bytes of skb headroom on each
(re)transmission when sending frame without the payload and the header
length not being multiple of 4 (i.e. QoS header has 26 bytes). On such
case because paylad_aling=2 is bigger than header_align=0 we increase
header_align by 4 bytes. To prevent that we could change the check to:
if (payload_length && payload_align > header_align)
header_align += 4;
but not aligning payload at all is more effective and alignment is not
really needed by H/W (that has been tested on OpenWrt project for few
years now).
Reported-and-tested-by: Antti S. Lankila <alankila@bel.fi>
Debugged-by: Antti S. Lankila <alankila@bel.fi>
Reported-by: Henrik Asp <solenskiner@gmail.com>
Originally-From: Helmut Schaa <helmut.schaa@googlemail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
was cut short by RFKILL which confused cfg80211. As a
result, the latter wouldn't allow to run another scan.
Liad fixes a small bug in the firmware dump.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJUYZ/SAAoJEC0Llv5uNjIBx94P/R9SXr9/Ub9z/z71KwWZqbf7
AiNQelIOdN9sZIAMwP1Txa+bRv1HKY61dc81NN6CNvpbZ2HAWMwf3GEPIcwv+Azo
tH9BTqS6cdC5ezkB2x6dIOy0CRJYgNng31+DWUDuZYegMEEcTkd7HFogiz7Q1YG5
XoGwdzkor3VooNYJwWpmDgCbJ6jbWVFvnhiOuFbWilgeZ5CNOX1IS79pA1KCx414
zv8hRJNwtLa7pKqSIwe1eRjeTWJYiRJ8sMkEFOqjsSpK6evXFTCpFjX0rEqeRQ8Z
d91jOzvRm4KhN8LnslFqvbx/Gyy/gMzXOHq2Xc2JJUGKLqSAi9JbPPZFFZpYRzd6
1frz2oVL9QLDFusjbJkY8VUM1NLRaE+4zyYmJA+hpYjUvI320fLv13zukGaQsVY4
qx8iw6EYnwnVom5uhpL8o4TGs++6y7XMpklpRlcqxkiz05GExMTbC/FvZkyZJe4H
ImdEr/vss09BuE+N4F5xxQ6fzuaRIvUxoKzbDxXYTnamQwOFTQo01RXFDFCx72cA
dDCny1KhReZy9cyoM5x69igeNKxu9g4BCFK0H/9tlTTFQHHZiTJeaArEB7x/ZS0h
omoWTx5SN5vi8s9xc+lTqh/Un1LDytFtDaWPcH1Y+27PklKIBavugZdCW4O/6R0p
kbxJ5LZnDUSQ7zB/XXjp
=lnlA
-----END PGP SIGNATURE-----
Merge tag 'iwlwifi-for-john-2014-11-10' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes
Emmanuel Grumbach <egrumbach@gmail.com> says:
"Two fixes here - we weren't updating mac80211 if a scan
was cut short by RFKILL which confused cfg80211. As a
result, the latter wouldn't allow to run another scan.
Liad fixes a small bug in the firmware dump."
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When aborting d0i3 due to taken refs, other threads might
already wait on d0i3_exit_waitq for IWL_MVM_STATUS_IN_D0I3
to get cleared (it's somewhat likely, as synchronize_rcu()
might take a while), so make sure to wake them up.
Signed-off-by: Eliad Peller <eliadx.peller@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
In some rare cases, the firmware can put the device to
sleep after the driver requested the access. This is
because the access request can take a short time to be
propagated to the firmware.
If that happens, the driver may think that it has access
since the firmware hasn't put the device to sleep yet, but
right after the driver's check, the firmware might put the
device to sleep.
Warn when this happens by allowing the firmware to finish
the "put the device sleep" flow so that the driver will
not get access to the device. This will make the issue
visible.
This still doesn't fix the race, but at least it makes
it more visible.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Currently, the firmware only sends temperature notificaitions inside
RX statistics notifications, which are tied to beacon filtering. This
is a problem because beacon filtering is not used with vifs that don't
receive beacons (e.g. P2P GO and AP), so the driver doesn't receive
temperature notifications in those cases. To solve that, the firmware
will be changed so that it sends DTS_MEASUREMENT_NOTIFICATIONs,
independently from the beacon filtering flows.
To support that, the driver needs to also handle unsolicited
DTS_MEASUREMENT_NOTIFICATIONs, that are not triggered by
DTS_TRIGGER_CMD_FLAGS_TEMP requests.
This change is backwards compatible and will simply not be used with
firmware versions that do not send the notifications.
Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Refactor the temperature handling code so that it is easier to reuse
it with other notification flows.
Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
The code to capture firmware errors works during the reconfiguration
phase after an error. As the D3->D0 transition uses the same flow to
get the D0 image reconfigured, this triggered and caused a firmware
coredump to be collected. This in turn, if it isn't picked up by
userspace, can cause module unloading to fail, which is how the bug
was detected.
To fix this issue, introduce a new status flag (D3_RECONFIG) and use
it to detect that during reconfiguration no coredump should be taken
and reported.
Reported-by: Avi Kraif <avix.kraif@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
When we need only one antenna, we should refrain from using
the antenna that is shared with BT if BT load is high.
Fix this.
Reviewed-by: Eyal Shapira <eyal@wizery.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
When Tx STBC is being used and RS switches to a search column
using the alternate antenna from the current one there is a
problem with using rs_rate_match to figure out which table
is the active and which one is the search one. The root cause
is because in STBC the antenna mask in the ucode rate is set
to ANT_AB and in this specific scenario it matches both the
active and search table (e.g. SISO_ANT_A and SISO_ANT_B).
This leads to tx stats being updated in the wrong table and later
on to getting stuck in a test window and not moving on to other
columns. If this happens during the initial search cycle we
never end it and therefore never enable aggregation which leads
naturally to severe througput degradation.
Fix it by deducing which table is which by knowing whether we're
in a search or not like it's being done in rs_rate_scale_perform
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>
Other contexts might call iwl_mvm_ref_sync() right before
we set IWL_MVM_STATUS_IN_D0I3, and then assume the fw/bus
is not in d0i3 state.
However, since we currently don't check for held references
in the d0i3_enter flow, we might enter d0i3 although there
is an active reference.
Solve it by aborting the d0i3 enter flow if there is an
active reference. Since users are assumed to use
iwl_mvm_ref_sync, which takes a ref before checking the
flag, we don't need further locking.
Signed-off-by: Eliad Peller <eliadx.peller@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
This was taken care of in case we're doing STBC with HT
but not when working with VHT.
Signed-off-by: Eyal Shapira <eyalx.shapira@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Even if running the driver with param init_dbg=1 - on INIT
image error - iwl_trans_stop_device() was still called. This
patch fixes that and calls iwl_trans_stop_device() on INIT
image failure only if init_dbg=0.
Signed-off-by: Liad Kaufman <liad.kaufman@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
The length counting previously done had an error in it, causing
the length down the data dumping function to be shorter than it
should be, causing the end of the data to get truncated off and
lost.
Cc: <stable@vger.kernel.org> [3.17+]
Fixes: 67c65f2cf7 ("iwlwifi: dump periphery registers to fw-error-dump")
Signed-off-by: Liad Kaufman <liad.kaufman@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
The variable 'tid' is already defined in this function, so use
just 't' for the new one. As we return from the function just
overwriting 'tid' would be acceptable, but less obvious to the
reader.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Mostly functions related to building Tx-commands for sending to FW.
Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
The status variable should be unsigned as the function call
requires a u32 not int pointer, fix that.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
phy_read and phy_write are not set for every phy any more sine this:
commit d342b95dd7
Author: Rafał Miłecki <zajec5@gmail.com>
Date: Thu Jul 31 21:59:43 2014 +0200
b43: don't duplicate common PHY read/write ops
b43_phy_copy() accesses phy_read and phy_write directly and will fail
with some phys. This patch fixes the regression by using the
b43_phy_read() and b43_phy_write() functions which should be used for
read and write access.
This should fix this bug report:
https://bugzilla.kernel.org/show_bug.cgi?id=87731
Reported-by: Volker Kempter <v.kempter@pe.tu-clausthal.de>
Tested-by: Volker Kempter <v.kempter@pe.tu-clausthal.de>
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Changes in the vendor driver were added to rtlwifi, but some updates
to rtl8192se were missed, and the driver could neither scan nor connect.
There are other changes that will enhance performance, but this minimal
set fix the basic functionality.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
There are typos in the handling of the descriptor pointers where the wrong
descriptor is referenced. There is also an error in which the pointer is
incremented twice.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Device RTL8192EE uses a new form of trx flow. This fix sets up the descriptors
correctly.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Radiotap vendor namespace data might still be useful, but we
reverted it because it used too much space in the RX status.
Put it back, but address the space problem by using a single
bit only and putting everything else into the skb->data.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
following:
* large mac80211-hwsim changes from Ben, Jukka and a bit myself
* OCB/WAVE/11p support from Rostislav on behalf of the Czech Technical
University in Prague and Volkswagen Group Research
* minstrel VHT work from Karl
* more CSA work from Luca
* WMM admission control support in mac80211 (myself)
* various smaller fixes, spelling corrections, and minor API additions
-----BEGIN PGP SIGNATURE-----
iQIcBAABCAAGBQJUWMs/AAoJEDBSmw7B7bqrmBQQAIbfAe7wH1WifRtOnhw3zWQQ
K36+Edf3HlQ+EIkSs63QousRj2e7pGDOyhzMWLaqsmeTLteUtlGbr7qwiJO1QZdf
Ml2V5O2s+b8hUIClDBVQF2L6+GGUmRUdQqvDDhkN1guoxD/Nk8cNtsRkSdiXWJWy
R48NzvYDflBhc8uqPtR8jDb10eM3c00YP9HB+w9hYAfizD+FRue7UNp4MQIqwp9V
HdKRT6L2n/6QA+Mzse0rMDes5qI7nIUNgj+hjqgJSnhITPMgGR5j/pitnVHrr81M
ngOipBFG3svsQrwZh8nM4Llp0cM4Gs+GlgCieu9+TJpr2sY00Z3kYcp0pxtDoSxz
Wblqz9n/bnW9mrkEfl12XqwwT5vguchwHoZ9cXhejDxSawWXoTRx20uW4ahO8ArA
kWwwjTBVsQ5WMCtOBiqggzNKghwCc2ILmcZnjGdg9aNXcWsmQ4vyeCfG2QxBz/UB
Grv/f9NSy6mzKQ34yv+lyR7rFZ8XcT03EVAnZSYz8X0ZZGxwtFupRp1RrBh1KPtD
TJoe6Q71FfHKYRJ2xgygYkQFo+r9d0BKBeerq+Vu2hBeaqyi4aUwSj7d1sUaaq6N
tL8fmAUqFjVOOUFeH1g07Xke5QD+yrEC7sJKkeRMfcRGB+dEa+2m3I5p4WDz9bWM
AEvFSsYr/I9KI4d1huXD
=6GIj
-----END PGP SIGNATURE-----
Merge tag 'mac80211-next-for-john-2014-11-04' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next
Johannes Berg <johannes@sipsolutions.net> says:
"This relatively large batch of changes is comprised of the
following:
* large mac80211-hwsim changes from Ben, Jukka and a bit myself
* OCB/WAVE/11p support from Rostislav on behalf of the Czech Technical
University in Prague and Volkswagen Group Research
* minstrel VHT work from Karl
* more CSA work from Luca
* WMM admission control support in mac80211 (myself)
* various smaller fixes, spelling corrections, and minor API additions"
Conflicts:
drivers/net/wireless/ath/wil6210/cfg80211.c
Signed-off-by: John W. Linville <linville@tuxdriver.com>
over the place and most of the bugs are old, one even dates back
to the original mac80211 we merged into the kernel.
-----BEGIN PGP SIGNATURE-----
iQIcBAABCAAGBQJUWJSYAAoJEDBSmw7B7bqr17IP/3RFbqI4S/ceZzrVNLtvGDUd
MIlkGhngDdhpFhSxTdOH4opFM/j9bkwndk0F35d4r94mCeB5eJQKrtUfeon/7aft
AKaRa3CNsEVQgCempCYOKGwlJZQQ86IL6IvU4CW5CTNHENUBLA83KHqX+6Aoumhm
mdJxhSzmB53Qn1bteIJXyJmOjgxQvBZggBIF/25Xnosb3FBH3hvPsH0qbIKZaicy
PlD5JWk9UseySjLNwk1/jriQ4koF5Dy/BVRyQ/0fRYswdmS3o2EiC4JOWjsOfIUi
NE9Ax+DAKvHHGYNcsX/hXsPJTc6fYgq3INEZBvnK04GHVFVGLq1WoEIfOeLugK7o
j7OIEJbkKAQjJSnEpB9Y6YHO/jPXEokJjUNT7VuZJqLElp4Hd8K9jnhKD9jkZBA6
TGjNO5NJqgGdlxnq3nu4+XFh9StAam6J1Ey1TWarc6Kxd8Gtg3Ymkj3cO46rHcQU
JX3i3RGlYqibEQ0NVtZ4EfnGjtcGx0Vbf+yAc9ZpWzKFvX9YKS1wuOd5i/eZI8bb
hxMjHFwmViV3Ifk9GjBNKioXkCpEfk9Q3pKzRllHQn56ueTu1mBvAfIe93PRm9kR
y/giIZvHEhs8VH2PHVuHzT16YMVnNfQniAi+BK73QWC3zAhj1ss3xN33+Q8FfpMM
xw/prlY9IAH2A9zis1Vz
=8uwd
-----END PGP SIGNATURE-----
Merge tag 'mac80211-for-john-2014-11-04' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211
Johannes Berg <johannes@sipsolutions.net> says:
"This contains another small set of fixes for 3.18, these are all
over the place and most of the bugs are old, one even dates back
to the original mac80211 we merged into the kernel."
Signed-off-by: John W. Linville <linville@tuxdriver.com>
loading flow. A user reported that he couldn't load the
driver because the rfkill line was pulled up while we
were running the calibrations. This was happening while
booting the system: systemd was restoring the "disable
wifi settings" and that raised an RFKILL interrupt during
the calibration. Our driver didn't handle that properly
and this is now fixed.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJUV9s6AAoJEC0Llv5uNjIBd+0P+gIWPyBhONNgFPWpo1v+cRVo
p8aGIPc3ZMroZFcSO6gLukkXuM4xmZz1ldyZmw6Pnfeakqu2mhix15a+uh8z1s8r
KJWRVT379ZZ5yWQVzeEtEnT8ZYAkzta5DayCRGhBngCeM5zRlYtQLHXDrCaYj7Ag
95IzrNdOWS7IS3L+mNeB0mm1OUgMfAEVkpHu5OQdFH3i64NADU4toq1FslNbret7
ERp0kFBXDIHyPNc+/oynDpJwRWMTImVwe6S4eua9BGVEtRp1gjRs2eSh19XGwGst
ZUg16YyMVg/tjpiopsHKHc1+p99MRdeL/A4lb9toqMjLiziMhOjZZY6vqLLnYFju
XTP2fnVJQPWFDiJih9AmEuQIIdy52R6OwlU9CCxx5SVXVNaz6gkgzI3NYXupEq1E
tgTJw1NrxlLdevLaeG+jywoW0ll3HkTA6heiNmYwLQL+G+rCTWoSy2Ht+QphM5GG
VWBEsyVF/w/4+xvKzUEKd/0n5oU1sJdx75gnoSDQK7WIyyWRC2jibqZ9vNaXSo35
a1WIlErC8hj10wfaSF62TG0cnCxxPj6RkZlPyqwMEKwBzfWf4qqaMs+295rHs0dn
YKvy1N/deJ6bZIL1JpL0yYJd3S2Kc02ZvahyYx7kDfGJfJkIOA7GtYU2SEZqFCNH
jc9vQfxZY4w9Cyo7ksTi
=3v6b
-----END PGP SIGNATURE-----
Merge tag 'iwlwifi-for-john-2014-11-03' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes
Emmanuel Grumbach <egrumbach@gmail.com> says:
"I fix here two issues that are related to the firmware
loading flow. A user reported that he couldn't load the
driver because the rfkill line was pulled up while we
were running the calibrations. This was happening while
booting the system: systemd was restoring the "disable
wifi settings" and that raised an RFKILL interrupt during
the calibration. Our driver didn't handle that properly
and this is now fixed."
Signed-off-by: John W. Linville <linville@tuxdriver.com>
