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>
that can cause a kernel crash. I'm not sure it's remotely
exploitable, but it's an important fix nonetheless.
-----BEGIN PGP SIGNATURE-----
iQIcBAABCAAGBQJUYJNkAAoJEDBSmw7B7bqrgooP/ivTw/pJJ5i5wLsfAUUNV1tI
FDe3+w/kBsD0d0lNsnKoyq58iORyYIxHtmLhvFV+yuBMvpfADTNm9CkLDDjg939m
mU6/kjO6wbHv/SoLSL4rss/AggGaEsu+3ggGpmhXl2JApSUIVjw0z9XixNcU4Vnz
CEjIw9jsnKA5UOeH2cv+fwQLXImXKSsofAf2NgZ3zJ6Ci0zLOZtr/ZmO2o4IU9Do
HWp3CHsaehoWlaqtPx6r8JaodE7XPEPtim66aWoUaeSYueL9iYKJU7BS2jkTWJnQ
Kv8JuVQIQPlMsTuvTR8oHvpHZ29m0Z6mc8XsKeNu6UCNzoOBGS2Ak2YZwcAeqSLr
oQRDDBc4aKsY5YWcaChPx6N8gOEXRr4cQgfyY79o5vaPPJwixxLMPUUOU1rKHC3D
E61YfQ/tfoFWzEitksX14P3Gynas6abySku5mhM5y2L/1XFdDHugZjzRjcBv/1ry
J9x44k2EWbduvz8GBGGethmKMghKYYTqfB5rWh1cKxafgBEFt61ZcE4LuqaNnP17
sg+IlXFxZjJLnhhg0YL2oZt+++/CyCLl9G+mx6wZE4HLqsl26ElZ6ql2kekJ5baV
HKsPyBa2r48icJfrogA9WpjumI8b19ztG5OrsF0AQmK77IVSj80JFVnsTBal9/Y7
Ao2xMau9OghJq8AEJpOi
=H7HX
-----END PGP SIGNATURE-----
Merge tag 'mac80211-for-john-2014-11-10' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211
Johannes Berg <johannes@sipsolutions.net> says:
"This has just one fix, for an issue with the CCMP decryption
that can cause a kernel crash. I'm not sure it's remotely
exploitable, but it's an important fix nonetheless."
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Commit 7ec7c4a9a6 (mac80211: port CCMP to
cryptoapi's CCM driver) introduced a regression when decrypting empty
packets (data_len == 0). This will lead to backtraces like:
(scatterwalk_start) from [<c01312f4>] (scatterwalk_map_and_copy+0x2c/0xa8)
(scatterwalk_map_and_copy) from [<c013a5a0>] (crypto_ccm_decrypt+0x7c/0x25c)
(crypto_ccm_decrypt) from [<c032886c>] (ieee80211_aes_ccm_decrypt+0x160/0x170)
(ieee80211_aes_ccm_decrypt) from [<c031c628>] (ieee80211_crypto_ccmp_decrypt+0x1ac/0x238)
(ieee80211_crypto_ccmp_decrypt) from [<c032ef28>] (ieee80211_rx_handlers+0x870/0x1d24)
(ieee80211_rx_handlers) from [<c0330c7c>] (ieee80211_prepare_and_rx_handle+0x8a0/0x91c)
(ieee80211_prepare_and_rx_handle) from [<c0331260>] (ieee80211_rx+0x568/0x730)
(ieee80211_rx) from [<c01d3054>] (__carl9170_rx+0x94c/0xa20)
(__carl9170_rx) from [<c01d3324>] (carl9170_rx_stream+0x1fc/0x320)
(carl9170_rx_stream) from [<c01cbccc>] (carl9170_usb_tasklet+0x80/0xc8)
(carl9170_usb_tasklet) from [<c00199dc>] (tasklet_hi_action+0x88/0xcc)
(tasklet_hi_action) from [<c00193c8>] (__do_softirq+0xcc/0x200)
(__do_softirq) from [<c0019734>] (irq_exit+0x80/0xe0)
(irq_exit) from [<c0009c10>] (handle_IRQ+0x64/0x80)
(handle_IRQ) from [<c000c3a0>] (__irq_svc+0x40/0x4c)
(__irq_svc) from [<c0009d44>] (arch_cpu_idle+0x2c/0x34)
Such packets can appear for example when using the carl9170 wireless driver
because hardware sometimes generates garbage when the internal FIFO overruns.
This patch adds an additional length check.
Cc: stable@vger.kernel.org
Fixes: 7ec7c4a9a6 ("mac80211: port CCMP to cryptoapi's CCM driver")
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Ronald Wahl <ronald.wahl@raritan.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.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>
If the RFkill interrupt fires while we calibrate, it would
make the firmware fail and the driver wasn't able to recover.
Change the flow so that the driver will kill the firmware
in that case.
Since we have now two flows that are calling
trans_stop_device (the RFkill interrupt and the
op_mode_mvm_start function) - we need to better sync this.
Use the STATUS_DEVICE_ENABLED in the pcie transport in an
atomic way to achieve this.
This fixes: https://bugzilla.kernel.org/show_bug.cgi?id=86231
CC: <stable@vger.kernel.org> [3.10+]
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-by: Luciano Coelho <luciano.coelho@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Upon receiving the last fragment, all but the first fragment
are freed, but the multicast check for statistics at the end
of the function refers to the current skb (the last fragment)
causing a use-after-free bug.
Since multicast frames cannot be fragmented and we check for
this early in the function, just modify that check to also
do the accounting to fix the issue.
Cc: stable@vger.kernel.org
Reported-by: Yosef Khyal <yosefx.khyal@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
An error in the code makes the allocated space for firmware to be too
small.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Murilo Opsfelder Araujo <mopsfelder@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The new version of rtlwifi needs code in rtl92ce_get_desc() that returns
the buffer address for read operations.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Murilo Opsfelder Araujo <mopsfelder@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The new version of rtlwifi needs code in rtl92se_get_desc() that returns
the buffer address for read operations.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Murilo Opsfelder Araujo <mopsfelder@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Driver rtlwifi has been modified to call ieee80211_register_hw()
from the probe routine; however, the existing call in the callback
routine for deferred firmware loading was not removed.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Murilo Opsfelder Araujo <mopsfelder@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The recent changes in checking for Bluetooth status added some callbacks to code
in rtlwifi. To make certain that all callbacks are defined, a dummy routine has been
added to rtlwifi, and the drivers that need to use it are modified.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Murilo Opsfelder Araujo <mopsfelder@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
During 11n RX reordering, if there is a hole in RX table,
driver will not send packets to kernel until the rxreorder
timer expires or the table is full.
However, currently driver always restarts rxreorder timer when
receiving a packet, which causes the timer hardly to expire.
So while connected with to 11n AP in a busy environment,
ping packets may get blocked for about 30 seconds.
This patch fixes this timer restarting by ensuring rxreorder timer
would only be restarted either timer is not set or start_win
has changed.
Signed-off-by: Chin-Ran Lo <crlo@marvell.com>
Signed-off-by: Plus Chen <pchen@marvell.com>
Signed-off-by: Marc Yang <yangyang@marvell.com>
Signed-off-by: Cathy Luo <cluo@marvell.com>
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The right shift operation has higher precedence than the mask so we
left shift by "(i * 3)" and then immediately right shift by "(i * 3)"
then we mask. It should be left shift, mask, and then right shift.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When an interface is deleted, an ongoing hardware scan is canceled and
the driver must abort the scan, at the very least reporting completion
while the interface is removed.
However, if it scheduled the work that might only run after everything
is said and done, which leads to cfg80211 warning that the scan isn't
reported as finished yet; this is no fault of the driver, it already
did, but mac80211 hasn't processed it.
To fix this situation, flush the delayed work when the interface being
removed is the one that was executing the scan.
Cc: stable@vger.kernel.org
Reported-by: Sujith Manoharan <sujith@msujith.org>
Tested-by: Sujith Manoharan <sujith@msujith.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Due to the time it takes to process the beacon that started the CSA
process, we may be late for the switch if we try to reach exactly
beacon 0. To avoid that, use count - 1 when calculating the switch time.
Cc: stable@vger.kernel.org
Reported-by: Jouni Malinen <j@w1.fi>
Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
If we are switching from an HT40+ to an HT40- channel (or vice-versa),
we need the secondary channel offset IE to specify what is the
post-CSA offset to be used. This applies both to beacons and to probe
responses.
In ieee80211_parse_ch_switch_ie() we were ignoring this IE from
beacons and using the *current* HT information IE instead. This was
causing us to use the same offset as before the switch.
Fix that by using the secondary channel offset IE also for beacons and
don't ever use the pre-switch offset. Additionally, remove the
"beacon" argument from ieee80211_parse_ch_switch_ie(), since it's not
needed anymore.
Cc: stable@vger.kernel.org
Reported-by: Jouni Malinen <j@w1.fi>
Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Userspace can add keys to an AP mode interface before start_ap has been
called. If there have been no calls to start_ap/stop_ap in the mean
time, the keys will still be around when the interface is brought down.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
[adjust comments, fix AP_VLAN case]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
mvm->cur_ucode wasn't set before we actually load the
firmware. This caused issues when we boot in RFKILL since
we get an RFKILL interrupt upon boot even before we load
any firmware.
This leads to issues since iwl_mvm_set_hw_rfkill_state
(the RFKILL interrupts handler in mvm) relies on this
variable.
Fix this.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
RTS rate, one for a debugfs file, one to return the correct
channel to userspace, a sanity check for a userspace value
and the remaining two are just documentation fixes.
-----BEGIN PGP SIGNATURE-----
iQIcBAABCAAGBQJUSUotAAoJEDBSmw7B7bqr2TwP/2EJiYMOXhLTM5F/sEaGP5aX
+hN+/Za3hAuLu3GkYXnIEw8uJL0ooDpUkQLoyV7AUoqVKhgqCuMQPWbklU0Ns2Og
qubAl9BRY1DPgMtdGa3mMMJ3GYkIC8Hbh6kTOPqYASVZWover5NRKFlp2jp1uhbf
ypv0IfIJVO323s90TWv1ZQsTtnGxMtL9DaLwqBNKN8nSGKxe62cUZsQN+H5KGm4N
/n7eN62XPkidFUsTmdAXHfcgEpGv82rtSpxWmSrwxDbQEj12xkP66cRTuomZJ5v1
981OIzcxtV0ngLjfnoSGev6bvgO2TDEbvQScIsZiqfnaJuBfzPEAaghnWozox3op
dfolKkD3LecLGcxVVGJlKddxm3K4+2q7tuwkfDcxKNx2KFqtOqM6gY8z1uXYX8MW
Jv7669nwpKgWM0e3hsxz6WJauEsdWRVzarmimK/Ymitu0RgNmXTVbdvvFVSTenuZ
0HLqfr7Uk0gw5gQgWfj4F0qjNxzmjhnw/pz+c1DRtYs6w6SGToCqcm5yRU6f8pLt
SHc3LJ67xK5RnOq8+KJ8o92MfE29HH2CTzLzgghNrLnwqcYBTApuCr0OtpQb04Zf
AgQRMq61IGXwCDiVFE1ElpRgrW4/aekUZh/JB8pGHlhrAvl+HwNYVek66MBDeMyl
akmLeHhrCkuWstDHHz+o
=m/XT
-----END PGP SIGNATURE-----
Merge tag 'mac80211-for-john-2014-10-23' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211
Johannes Berg <johannes@sipsolutions.net> says:
"Here are a few fixes for the wireless stack: one fixes the
RTS rate, one for a debugfs file, one to return the correct
channel to userspace, a sanity check for a userspace value
and the remaining two are just documentation fixes."
Signed-off-by: John W. Linville <linville@tuxdriver.com>
dvm gets a fix for a bug that was reported by many users.
Two minor fixes for BT Coex and platform power fix that helps
reducing latency when the PCIe link goes to low power states.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJUSUeNAAoJEC0Llv5uNjIBN84P/0BlGCi+lXWaO867zMJ05g3i
dJQFV6Pm5fGIg4+Cjz8q18EBhf22OQnqNFXoDiIHpmVYx5gnNUqDsBQB8vy3tIZn
EdHWb3vAYaFScigk9cjSJ2J11TnIbXDFFlSeo2iv8zOlZm5PRELfKJP2+fv9vgEq
mEyZar81/8VVwLEVsx4wN9NeKC//+a3zgW22eTR5rKMvAv+NRwk82xltZP0Qd/vF
j+Lj8VFncH92W2ZzBYK18yEGWgfmsCsAddbAFj/6AYzJDUUvqSclTjONEsLood9N
6s+vowzCcH+c7PA5gA+8/ooNvzPsf+234jaqAApDxlqqlutZCldhnRXZBE76OekM
g9EmWWQg3iHmaLHsl89rP6bVm71T6WI+9I2IXg1MOBuMCxNIQeSydDpZwrqmNdJ0
4zdMToMJcRk+9wT6w26xH1fPc1yr8MOU8suhe6HTChbKeWaoigVsF59GbN6l/YAm
SmfabP4uS1+QbfZIoeXPyZvbFKUMQDQfH029ccx+LjsvspXrUg5vgr6Z1n5f4maO
mtZcew+FxsWiZXp9+ppmRJcu46jzONC9sCNQyBkoCGopOu84b+0LfCUVNLvIewX4
4zbuDOhhuzjOK8f8OZU7Ko3KUj+6H4Str9rAynLllG8q7bYAd5yaD+Q6su5sGIkc
VU8ifyGf3k+6k1GvjTvm
=iZLf
-----END PGP SIGNATURE-----
Merge tag 'iwlwifi-for-john-2014-10-23' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes
Emmanuel Grumbach <egrumbach@gmail.com> says:
"I revert here a patch that caused interoperability issues.
dvm gets a fix for a bug that was reported by many users.
Two minor fixes for BT Coex and platform power fix that helps
reducing latency when the PCIe link goes to low power states."
Signed-off-by: John W. Linville <linville@tuxdriver.com>
iwl_poll_bit may return a strictly positive value when the
poll doesn't match on the first try.
This was caught when WoWLAN started failing upon resume
even if the poll_bit actually succeeded.
Also change a wrong print. If we reach the end of
iwl_pcie_prepare_card_hw, it means that we couldn't
get the devices.
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-by: Luciano Coelho <luciano.coelho@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
When mac80211 wants to ensure that a frame is sent, it calls
the flush() callback. Until now, iwldvm implemented this by
waiting that all the frames are sent (ACKed or timeout).
In case of weak signal, this can take a significant amount
of time, delaying the next connection (in case of roaming).
Many users have reported that the flush would take too long
leading to the following error messages to be printed:
iwlwifi 0000:03:00.0: fail to flush all tx fifo queues Q 2
iwlwifi 0000:03:00.0: Current SW read_ptr 161 write_ptr 201
iwl data: 00000000: 00 00 00 00 00 00 00 00 fe ff 01 00 00 00 00 00
[snip]
iwlwifi 0000:03:00.0: FH TRBs(0) = 0x00000000
[snip]
iwlwifi 0000:03:00.0: Q 0 is active and mapped to fifo 3 ra_tid 0x0000 [9,9]
[snip]
Instead of waiting for these packets, simply drop them. This
significantly improves the responsiveness of the network.
Note that all the queues are flushed, but the VO one. This
is not typically used by the applications and it likely
contains management frames that are useful for connection
or roaming.
This bug is tracked here:
https://bugzilla.kernel.org/show_bug.cgi?id=56581
But it is duplicated in distributions' trackers.
A simple search in Ubuntu's database led to these bugs:
https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/1270808https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1305406https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1356236https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1360597https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1361809
Cc: <stable@vger.kernel.org>
Depends-on: 77be2c54c5 ("mac80211: add vif to flush call")
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Don't add the time event to the list. We added it several
times the same time event, which leads to an infinite loop
when walking the list.
Since we (currently) don't support more than one ROC for STA
vif at a time, enforce this and don't add the time event
to any list.
We were also missing the locking of the mutex which led to
a lockdep splat - fix that.
Signed-off-by: Matti Gottlieb <matti.gottlieb@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
The tx power should be limited from many reasons.
currently, setting the tx power is available by the mvm only for
station interface. Adding the tx power condition to
bss_info_changed_ap_ibss make it available also for AP.
Signed-off-by: Haim Dreyfuss <haim.dreyfuss@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
I changed the string but forgot to update the fix also to
MODULE_FIRMWARE().
Signed-off-by: Liad Kaufman <liad.kaufman@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
The LTR is the handshake between the device and the root
complex about the latency allowed when the bus exits power
save. This configuration was missing and this led to high
latency in the link power up. The end user could experience
high latency in the network because of this.
Cc: <stable@vger.kernel.org> [3.10+]
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Drivers that do not use the get_btc_status() callback may not define a
dummy routine. The caller needs to check before making the call.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Murilo Opsfelder Araujo <mopsfelder@gmail.com>
Cc: Mike Galbraith <umgwanakikbuti@gmail.com>
Cc: Thadeu Cascardo <cascardo@cascardo.eti.br>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
In some cases the limit may be the same as reg->power_limit, but the
actual value that the hardware uses is not up to date. In that case, a
wrong value for current tx power is tracked internally.
Fix this by unconditionally updating it.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
rtl92c_set_fw_rsvdpagepkt is used by rtl8192cu and its pci sibling rtl8192ce.
rtl_cmd_send_packet crashes when called inside rtl8192cu because it works on
memory allocated only by rtl8192ce.
Fix the crash by calling a dummy function when used in rtl8192cu.
Comparision with the realtek vendor driver makes me think, something is missing in
the dummy function.
Short test as WPA2 station show good results connected to an 802.11g basestation.
Traffic stops after few MBytes as WPA2 station connected to an 802.11n basestation.
Signed-off-by: Karsten Wiese <fzuuzf@googlemail.com>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
In a previous patch the call to ieee80211_register_hw was moved from the
load firmware callback to the rtl_pci_probe only.
rt8192cu also uses this callback. Currently it doesnt create a wlan%d device.
Fill in the call to ieee80211_register_hw in rtl_usb_probe.
Signed-off-by: Karsten Wiese <fzuuzf@googlemail.com>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Initialize function pointer with a function indicating bt coexist is not there.
Prevents Ooops.
Signed-off-by: Karsten Wiese <fzuuzf@googlemail.com>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Many AP devices do not have the proper regulatory domain programmed in
EEPROM. Instead they expect the software to set the appropriate region.
For these devices, the country code defaults to US, and the driver uses
the US CTL tables as well.
On devices bought in Europe this can lead to tx power being set too high
on the band edges, even if the cfg80211 regdomain is set correctly.
Fix this issue by taking into account the DFS region, but only when the
EEPROM regdomain is set to default.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The kbuild test robot reported a possible array overrun. The affected code
checks for overruns, but fails to take the steps necessary to fix them.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Enabling HW queue control for normal (non-mcc) mode
causes problems with queue management, resulting
in traffic stall. Since it is mainly required for
fairness in MCC mode, disable it for the general case.
Bug: https://dev.openwrt.org/ticket/18164
Cc: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Use "%s" in the workqueue allocation to make sure the rtl_hal_cfg name
can never accidentally leak information via a format string.
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
It was found attached to the BCM47081A0 SoC. Log:
bcma: bus0: Found chip with id 43228, rev 0x00 and package 0x08
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Replacing strncpy with strlcpy to avoid strings that lacks null terminate.
And changed from using strncat to strlcat to simplify code.
Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The driver logs a message when the default branch of switch statements are
taken. Such information is useful when debugging, but these log items should
not be seen for standard usage.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Commit 2101e533f4 ("bcma: register bcma as device tree driver")
introduces a hard dependency on OF_ADDRESS into the bcma driver.
OF_ADDRESS is specifically disabled for the sparc architecture.
This results in the following error when building sparc64:allmodconfig.
drivers/bcma/main.c: In function 'bcma_of_find_child_device':
drivers/bcma/main.c:150:3: error: implicit declaration of function 'of_translate_address'
Fixes: 2101e533f4 ("bcma: register bcma as device tree driver")
Reported-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
ATM an HT rc_stats line is 106 chars.
Times 8(MCS_GROUP_RATES)*3(SS)*2(GI)*2(BW) + CCK(4), i.e. x100, this is
well above the current 8192 - sizeof(*ms) currently allocated.
Fix this by squeezing the output as follows (not that we're short on
memory but this also improves readability and range, the new format adds
one more digit to *ok/*cum and ok/cum):
- Before (HT) (106 ch):
type rate throughput ewma prob this prob retry this succ/attempt success attempts
CCK/LP 5.5M 0.0 0.0 0.0 0 0( 0) 0 0
HT20/LGI ABCDP MCS0 0.0 0.0 0.0 1 0( 0) 0 0
- After (75 ch):
type rate tpt eprob *prob ret *ok(*cum) ok( cum)
CCK/LP 5.5M 0.0 0.0 0.0 0 0( 0) 0( 0)
HT20/LGI ABCDP MCS0 0.0 0.0 0.0 1 0( 0) 0( 0)
- Align non-HT format Before (non-HT) (83 ch):
rate throughput ewma prob this prob this succ/attempt success attempts
ABCDP 6 0.0 0.0 0.0 0( 0) 0 0
54 0.0 0.0 0.0 0( 0) 0 0
- After (61 ch):
rate tpt eprob *prob *ok(*cum) ok( cum)
ABCDP 1 0.0 0.0 0.0 0( 0) 0( 0)
54 0.0 0.0 0.0 0( 0) 0( 0)
*This also adds dynamic checks for overflow, lowers the size of the
non-HT request (allowing > 30 entries) and replaces the buddy-rounded
allocations (s/sizeof(*ms) + 8192/8192).
Signed-off-by: Karl Beldan <karl.beldan@rivierawaves.com>
Acked-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
debugging info, and some code clean-ups.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABAgAGBQJUQQXsAAoJEG5mS6x6i9IjtlcP/1kB9TzJ0XGGEhIMv98X989X
jzOuDHandfhfB6f0ch+1HUOji34Ig+hX2GmKRnUMOJJvXTdwEl9qpbEo3tUNl6S+
pMf0oNzuMJGfrWsHbDa7MkCdnm6aLQrK/NxwHWY42g5yB2gc6vgcr6vD4bFEODBC
fPgQIuogbLlVexFJFuVH6XbxNUhEXWiKf4vdq2m3tlgatLpe5NdVPQrq3qu8PLRa
sbyNHWgCAVussI2LJI2t4dJwIUMnGFGTWBVNpxQo6ceWxziRFGg9Yo5068NnWU6j
nDGL/TiQTM+Zp51U39Sd6eg5apnQMgrHTXumghSRDLnFe+odiVsRXX5IEqEAqXJS
g6Et+sh7/CPO/nWM2dpIH5sxKuV4HAV7cSGsGjQD0pw6gKW8CT0rQI4gWufkorKH
oR2etKjywN9j9+ofUN4w4FfKPlxeTgKp+zVbtTlUMOveJ4NIYBDDMvUS9KS9ZyMt
s2X5/EJ864higC0VhTU/DxfqGc/g3+nz/EtWynxn9q2VPWlz/Zp0lLWvx4J4qGjP
g4Pbv6EzWZqR1pia9L5alwR9nEYtn+bkwFKvvygp0tA+bor0G75qoRVy75KhUIPn
1oQllKGiFhSLlNq9q6OMnlLv/BMXgvSnm7NL291/TY2RWfiWatlwGaMvnmkLWKKm
wskyofD4yYOs4UJXgUJ8
=JVjj
-----END PGP SIGNATURE-----
Merge tag 'ntb-3.18' of git://github.com/jonmason/ntb
Pull ntb (non-transparent bridge) updates from Jon Mason:
"Add support for Haswell NTB split BARs, a debugfs entry for basic
debugging info, and some code clean-ups"
* tag 'ntb-3.18' of git://github.com/jonmason/ntb:
ntb: Adding split BAR support for Haswell platforms
ntb: use errata flag set via DID to implement workaround
ntb: conslidate reading of PPD to move platform detection earlier
ntb: move platform detection to separate function
NTB: debugfs device entry
