Arnd Bergmann [Thu, 5 Oct 2017 12:05:24 +0000 (14:05 +0200)]
rsi: fix integer overflow warning
gcc produces a harmless warning about a recently introduced
signed integer overflow:
drivers/net/wireless/rsi/rsi_91x_hal.c: In function 'rsi_prepare_mgmt_desc':
include/uapi/linux/swab.h:13:15: error: integer overflow in expression [-Werror=overflow]
(((__u16)(x) & (__u16)0x00ffU) << 8) | \
~~~~~~~~~~~~^~~~~~~~~~~~~~~~~
include/uapi/linux/swab.h:104:2: note: in expansion of macro '___constant_swab16'
___constant_swab16(x) : \
^~~~~~~~~~~~~~~~~~
include/uapi/linux/byteorder/big_endian.h:34:43: note: in expansion of macro '__swab16'
#define __cpu_to_le16(x) ((__force __le16)__swab16((x)))
^~~~~~~~
include/linux/byteorder/generic.h:89:21: note: in expansion of macro '__cpu_to_le16'
#define cpu_to_le16 __cpu_to_le16
^~~~~~~~~~~~~
drivers/net/wireless/rsi/rsi_91x_hal.c:136:3: note: in expansion of macro 'cpu_to_le16'
cpu_to_le16((tx_params->vap_id << RSI_DESC_VAP_ID_OFST) &
^~~~~~~~~~~
The problem is that the 'mask' value is a signed integer that gets
turned into a negative number when truncated to 16 bits. Making it
an unsigned constant avoids this.
Fixes: eac4eed3224b ("rsi: tx and rx path enhancements for p2p mode") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Igor Mitsyanko [Thu, 5 Oct 2017 01:38:13 +0000 (18:38 -0700)]
qtnfmac: do not cache current channel info in driver's state
Linux Wireless device structure already has current channel
information that can be used when needed. Start using it.
Since driver's channel info is not used anymore, remove it.
Signed-off-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Igor Mitsyanko [Thu, 5 Oct 2017 01:38:11 +0000 (18:38 -0700)]
qtnfmac: do not cache BSS state in per-VIF structure
This cached state is used only once immediately after it is
initilized, except for BSSID value that is used for events processing.
There is no reason in keeping unused data in driver's state.
Signed-off-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Igor Mitsyanko [Thu, 5 Oct 2017 01:38:10 +0000 (18:38 -0700)]
qtnfmac: get rid of QTNF_STATE_AP_START flag
QTNF_STATE_AP_START usage is redundant and imposes additional state
synchronization maintenance. We may as well leave state checking
to network card and upper layers (cfg80211, nl80211 and userspace).
Signed-off-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Igor Mitsyanko [Thu, 5 Oct 2017 01:38:08 +0000 (18:38 -0700)]
qtnfmac: pass channel definition to WiFi card on START_AP command
Introduce "channel definition" TLV containing full channel
description (center frequence for both segments + BW) and pass it to
wireless card in a payload to START_AP command.
Signed-off-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Igor Mitsyanko [Thu, 5 Oct 2017 01:38:07 +0000 (18:38 -0700)]
qtnfmac: pass all AP settings to wireless card for processing
Modify QLINK START_AP command payload to pass all AP settings
contained within struct cfg80211_ap_settings.
Make most of settings a constant part of "config AP" command
instead of passing it as an optional TLVs.
Signed-off-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Igor Mitsyanko [Thu, 5 Oct 2017 01:38:06 +0000 (18:38 -0700)]
qtnfmac: do not cache AP settings in driver structures
Cached AP setings are passed to WiFi card right after they are
initialized and are never used for anything else. There is no
point in keeping them in driver state.
Signed-off-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
rtlwifi: Add bw_update parameter for RA mask update.
- Add new parameter "is_bw_update" to control if current bandwidth setting
is updated to FW RA.
- After this commit, we keep the same setting as before.
- Later, bandwidth update in watchdog is changed to false for 8822BE.
Signed-off-by: Tsang-Shian Lin <thlin@realtek.com> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Cc: Yan-Hsuan Chuang <yhchuang@realtek.com> Cc: Birming Chiu <birming@realtek.com> Cc: Shaofu <shaofu@realtek.com> Cc: Steven Ting <steventing@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
rtlwifi: rtl8192ee: Make driver support 64bits DMA.
1. Both 32-bit and 64-bit use the same TX/RX buffer desc layout
2. Extend set_desc() and get_desc() to set and get 64-bit address
3. Remove directive DMA_IS_64BIT
4. Add module parameter to turn on 64-bit dma
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Cc: Yan-Hsuan Chuang <yhchuang@realtek.com> Cc: Birming Chiu <birming@realtek.com> Cc: Shaofu <shaofu@realtek.com> Cc: Steven Ting <steventing@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
We must choose only one of VHT_CAP among
IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_3895,
IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_7991 and
IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_11454.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Cc: Yan-Hsuan Chuang <yhchuang@realtek.com> Cc: Birming Chiu <birming@realtek.com> Cc: Shaofu <shaofu@realtek.com> Cc: Steven Ting <steventing@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Rohit Fule [Wed, 4 Oct 2017 12:06:06 +0000 (17:36 +0530)]
mwifiex: double the size of chan_stats array in adapter
When a user requests scan, driver sends multiple scan requests
to firmware, which might be active or passive. Firmware will
send channel statistics for each channel in the request. This will
be stored in chan_stats array.
Few channels might report hidden SSIDs in passive scan results.
So, once the original scan request is finished, driver issues an
active scan request for all channels which reported hidden SSIDs.
This will cause duplicates in the chan_stats array. At worst,
every channel will have a hidden SSID, in which case the driver
can issue active scan requests for each channel. So the complete
scan statistics size will be twice of existing limit.
At present maximum number of channels returned in scan statistics
is 31(BG) + 14(A) = 45. Clearly there will be an overflow of the
chan_stats array in the above mentioned scenario. To fix this
double the size of chan_stats array.
Signed-off-by: Rohit Fule <rohitf@marvell.com> Signed-off-by: Mangesh Malusare <mmangesh@marvell.com> Signed-off-by: Ganapathi Bhat <gbhat@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
mwifiex: minor cleanups w/ sta_list_spinlock in cfg80211.c
The sta_list_spinlock looks to be used to control locking of the
list. Specifically when someone has the lock they may be allowed
to modify or delete elements of the list.
That implies that we shouldn't access the fields of the elements
returned by mwifiex_get_sta_entry() after we've released the
spinlock. Let's make some small changes so this is true.
It's unlikely that this matters since it looks to be just error
handling, but it's nice to be clean.
Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Ganapathi Bhat <gbhat@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
There's absolutely no reason to check to see if a list is empty
before iterating through it. It's just like writing code like
this:
if (count != 0) {
for (i = 0; i < count; i++) {
...
}
}
The loop will already be avoided if "count == 0" so there was no
reason to check.
Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Ganapathi Bhat <gbhat@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Randy Dunlap [Wed, 27 Sep 2017 20:01:49 +0000 (13:01 -0700)]
bcma: keep *config menu together
Use "if BCMA"/"endif" around all Kconfig symbols so that they are
kept together in *config menus instead of showing up in unexpected
places. Also remove "depends on BCMA" since this is handled by the
"if BCMA" addition.
Tested with ARCH={x86_64,MIPS} using make {n,menu,g,x}config.
Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Kalle Valo [Wed, 11 Oct 2017 08:36:47 +0000 (11:36 +0300)]
Merge tag 'iwlwifi-next-for-kalle-2017-10-06-2' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next
First batch of iwlwifi patches for 4.15 (v2)
* Cleanups: - remove an unused value that we read from the NVM;
- remove link quality measurement code that was never used;
* One FW command API update;
* A fix and an addition for PCI devices for the A000 family;
* Tiny refactor of ref/unref code used by runtime-PM;
* Some debugging improvements;
* Implementation of a more flexible way to define command queue sizes;
* ACPI code refactoring;
* Some coding-style fixes;
* Avoid redundant command to the firmware;
* Add a struct with the format of one FW command;
* Change an error log to a warning when the FW API is not aligned with
the driver (important during development);
* Change a WARN_ON to WARN_ONCE to make it more descriptive and less
noisy (i.e. no repeated warnings on a firmware triggered error);
* Dump PCI registers when an error occurs, to make it easier to debug;
Dan Carpenter [Fri, 29 Sep 2017 07:52:34 +0000 (10:52 +0300)]
rtlwifi: silence underflow warning
My static checker complains that we have an upper bound but no lower
bound. I suspect neither are really required but it doesn't hurt to add
a check for negatives.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
p54: don't unregister leds when they are not initialized
ieee80211_register_hw() in p54_register_common() may fail and leds won't
get initialized. Currently p54_unregister_common() doesn't check that and
always calls p54_unregister_leds(). The fix is to check priv->registered
flag before calling p54_unregister_leds().
Cc: stable@vger.kernel.org Signed-off-by: Andrey Konovalov <andreyknvl@google.com> Acked-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Kalle Valo [Mon, 9 Oct 2017 14:31:39 +0000 (17:31 +0300)]
Merge tag 'iwlwifi-for-kalle-2017-10-06' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes
Second set of iwlwifi fixes for 4.14
* Fix support for 3168 device series;
* Fix a potential crash when using FW debugging recording;
* Improve channel flags parsing to avoid warnings on too long traces;
* Return -ENODATA when the temperature is not available, since the
-EIO we were returning was causing fatal errors in userspace;
* Avoid printing too many messages in dmesg when using monitor mode,
since this can become very noisy and completely flood the logs;
The default power limit read from the SPLC method in ACPI doesn't
have anything to do with the transport and is only used in the opmode,
so we can remove it from the trans. Additionally, this value is only
user when the opmode is starting, so we don't need to store it
anywhere.
Remove the dflt_pwr_limit element from the trans and move call to
iwl_acpi_get_pwr_limit() call to mvm.
Johannes Berg [Tue, 26 Sep 2017 14:37:12 +0000 (16:37 +0200)]
iwlwifi: mvm: warn on invalid statistics size
Getting the wrong statistics size is a problem, having a warning
will help us catch it quicker during firmware/driver development.
In released firmware/driver versions, we obviously make sure this
won't happen.
Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Move most of the set_dflt_pwr_limit() function to acpi.c and make it
return the pwr_limit value instead of setting directly. Also rename
it to iwl_acpi_get_pwr_limit().
iwlwifi: acpi: move function to get mcc into acpi code
The iwl_get_bios_mcc() function was in the iwl-nvm-parse.c file, but
it has nothing to do with the NVM. Move it to fw/acpi.c and rename it
to iwl_acpi_get_mcc().
iwlwifi: acpi: make iwl_get_bios_mcc() use the common acpi functions
The way iwl_get_bios_mcc() gets the WiFi package and checks for its
integrity is almost identical to the new iwl_acpi_get_wifi_pkg()
function. Instead of having duplicate code, convert it to use the
common code.
iwlwifi: acpi: use iwl_acpi_get_wifi_pkg when reading reading SPLC
Instead of finding the wifi package with its own code, we can reuse
the new iwl_acpi_get_wifi_pkg() function when reading the default
power limit from SPLC.
iwlwifi: acpi: move ACPI method definitions to acpi.h
Instead of defining each method where they are used and re-defining
WIFI_DOMAIN in each one of them, move all the definitions to a central
place and define the domain only a single time.
There are many places where the same process of invoking a method from
ACPI is used, causing a lot of duplicate code. To improve this,
introduce a new function to get an ACPI object by invoking an ACPI
method that can be reused.
Additionally, since this function needs to be called when we only have
the trans, the opmode or the device, introduce a new debug macro that
gets the device as a parameter so it can be used in the new function.
Sara Sharon [Thu, 28 Sep 2017 08:11:51 +0000 (11:11 +0300)]
iwlwifi: mvm: change warning to warn_once()
In case there is a FW bug where the BAID value in the
metadata is not properly initialized we hit the warning for
every RX packet.
Change it to warn once and add elaborate message.
Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Rajat Jain [Thu, 17 Aug 2017 19:05:12 +0000 (12:05 -0700)]
iwlwifi: pcie: dump registers when HW becomes inaccessible
We conclude the HW became inaccessible when we timeout waiting for
a bit to be set in a memory mapped register (CSR_GP_CNTRL). This
conclusion may not be true because the bit may not get set due to:
- a firmware issue
- a driver issue
- a PCI bus issue
- a platform issue
There are a lot of such reports with really no good debug information
beyond this message to help us.
Add some debug information and attempt to dump the different register
spaces at such a failure:
* Dump some configuration space of device - this will tell us if
something very basic is broken in the PCIe bus (so that configuration
accesses are failing). If this works, the PCIe bus seems OK. If this
does not work, it is definitely an PCIe issue.
* Dump some memory mapped registers - if we're reading some sane'ish
values, this will tell us that the PCIe bus is OK, but may be a firmware
/ driver issue. If this does not work, it may be a PCI configuration
issue or a driver/firmware issue.
* Dump parent and device's AER registers, will give us some straws to
chew on.
When we have an AP which supports HT and a single HT
station is connected, we change the min_width from
NL80211_CHAN_WIDTH_20_NOHT to NL80211_CHAN_WIDTH_20. This
of course has no implication on the channel width but still
sends a command to the firmware.
Remember the last width that was sent and refrain from
sending unnecessary commands to the firmware.
Sending a PHY_CTXT_CMD to the firmware has a cost since it
recalculates the presence on the medium and because of that
it closes the transmit queues for a short while.
Devices in the A000 family can use a different size for the command queue.
To allow this, make the command queue size configurable and set the size
for A000 devices to 32.
Signed-off-by: Shahar S Matityahu <shahar.s.matityahu@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
iwlwifi: nvm: set the correct offsets to 3168 series
The driver currently handles two NVM formats,
one for 7000 family and below, and one for 8000 family and above.
The 3168 series uses something in between,
so currently the driver uses incorrect offsets for it.
Fix the incorrect offsets.
Fixes: c4836b056d83 ("iwlwifi: Add PCI IDs for the new 3168 series") Signed-off-by: Chaya Rachel Ivgi <chaya.rachel.ivgi@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Johannes Berg [Thu, 21 Sep 2017 09:03:50 +0000 (11:03 +0200)]
iwlwifi: nvm-parse: unify channel flags printing
The current channel flags printing is very strange and messy,
in LAR we sometimes print the channel number and sometimes the
frequency, in both we print a calculated value (whether ad-hoc
is supported or not) etc.
Unify all this to
* print the channel number, not the frequency
* remove the band print (2.4/5.2 GHz, it's obvious)
* remove the calculated Ad-Hoc print
Doing all of this also gets the length of the string to a max
of 101 characters, which is below the max of 110 for tracing,
and thus avoids the warning that came up on certain channels
with certain flag combinations.
Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
iwlwifi: mvm: return -ENODATA when reading the temperature with the FW down
It seems that libsensors treats -EIO as a special non-recoverable
failure when it tries to read the temperature while the firmware is
not running. To solve that, change the error code to a milder
-ENODATA.
This fixes https://bugzilla.kernel.org/show_bug.cgi?id=196941
iwlwifi: mvm: do not print security error in monitor mode
In monitor mode we are not expected to decrypt encrypted
packets (not having the keys).
Hence we are expected to get an unknown rx security status.
Keeping the print in monitor mode causes a print for each
captured packet flooding the dmesg.
Kevin Cernekee [Sun, 17 Sep 2017 04:08:23 +0000 (21:08 -0700)]
brcmfmac: Delete redundant length check
brcmf_fweh_process_event() sets event->datalen to the
endian-swapped value of event_packet->msg.datalen, which is the
same as emsg.datalen. This length is already validated in
brcmf_fweh_process_event(), so there is no need to check it
again upon dequeuing the event.
Suggested-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kevin Cernekee <cernekee@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Kevin Cernekee [Sun, 17 Sep 2017 04:08:22 +0000 (21:08 -0700)]
brcmfmac: Avoid possible out-of-bounds read
In brcmf_p2p_notify_rx_mgmt_p2p_probereq(), chanspec is assigned before
the length of rxframe is validated. This could lead to uninitialized
data being accessed (but not printed). Since we already have a
perfectly good endian-swapped copy of rxframe->chanspec in ch.chspec,
and ch.chspec is not modified by decchspec(), avoid the extra
assignment and use ch.chspec in the debug print.
Suggested-by: Mattias Nissler <mnissler@chromium.org> Signed-off-by: Kevin Cernekee <cernekee@chromium.org> Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
brcmsmac: make some local variables 'static const' to reduce stack size
With KASAN and a couple of other patches applied, this driver is one
of the few remaining ones that actually use more than 2048 bytes of
kernel stack:
broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function 'wlc_phy_workarounds_nphy_gainctrl':
broadcom/brcm80211/brcmsmac/phy/phy_n.c:16065:1: warning: the frame size of 3264 bytes is larger than 2048 bytes [-Wframe-larger-than=]
broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function 'wlc_phy_workarounds_nphy':
broadcom/brcm80211/brcmsmac/phy/phy_n.c:17138:1: warning: the frame size of 2864 bytes is larger than 2048 bytes [-Wframe-larger-than=]
Here, I'm reducing the stack size by marking as many local variables as
'static const' as I can without changing the actual code.
This is the first of three patches to improve the stack usage in this
driver. It would be good to have this backported to stabl kernels
to get all drivers in 'allmodconfig' below the 2048 byte limit so
we can turn on the frame warning again globally, but I realize that
the patch is larger than the normal limit for stable backports.
The other two patches do not need to be backported.
Cc: <stable@vger.kernel.org> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Kevin Cernekee [Sun, 17 Sep 2017 04:08:24 +0000 (21:08 -0700)]
brcmfmac: Add check for short event packets
The length of the data in the received skb is currently passed into
brcmf_fweh_process_event() as packet_len, but this value is not checked.
event_packet should be followed by DATALEN bytes of additional event
data. Ensure that the received packet actually contains at least
DATALEN bytes of additional data, to avoid copying uninitialized memory
into event->data.
Cc: <stable@vger.kernel.org> # v3.8 Suggested-by: Mattias Nissler <mnissler@chromium.org> Signed-off-by: Kevin Cernekee <cernekee@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Larry Finger [Wed, 20 Sep 2017 21:15:05 +0000 (16:15 -0500)]
rtlwifi: rtl8821ae: Fix connection lost problem
In commit 40b368af4b75 ("rtlwifi: Fix alignment issues"), the read
of REG_DBI_READ was changed from 16 to 8 bits. For unknown reasonsi
this change results in reduced stability for the wireless connection.
This regression was located using bisection.
Fixes: 40b368af4b75 ("rtlwifi: Fix alignment issues") Reported-and-tested-by: James Cameron <quozl@laptop.org> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Cc: Stable <stable@vger.kernel.org> # 4.11+ Cc: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Colin Ian King [Thu, 21 Sep 2017 22:56:30 +0000 (23:56 +0100)]
iwlegacy: make const array static to shink object code size
Don't populate const array ac_to_fifo on the stack in an inlined
function, instead make it static. Makes the object code smaller
by over 800 bytes:
text data bss dec hex filename
159029 33154 1216 193399 2f377 4965-mac.o
text data bss dec hex filename
158122 33250 1216 192588 2f04c 4965-mac.o
(gcc version 7.2.0 x86_64)
Signed-off-by: Colin Ian King <colin.king@canonical.com> Acked-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Igor Mitsyanko [Thu, 21 Sep 2017 21:34:37 +0000 (14:34 -0700)]
qtnfmac: do not report channel changes until wiphy is registered
Wireless device may send "channel changed" event before driver
registered this device with wireless core, which will result in
warnings.
Once device is registered, higher layer will query channel info
manually using .get_channel callback.
Signed-off-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Igor Mitsyanko [Thu, 21 Sep 2017 21:34:34 +0000 (14:34 -0700)]
qtnfmac: pass VIF info to SendChannel command
Do not assume whether wireless device can or can not handle switching
several interfaces on a single radio to different channels. Device will
handle it itself and will return appropriate error code.
Signed-off-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Igor Mitsyanko [Thu, 21 Sep 2017 21:34:33 +0000 (14:34 -0700)]
qtnfmac: let wifi card handle channel switch request to the same chan
No reason to verify channel switch request in driver, it can simply be
forwarded to wireless device. Device can perform required checks and
return appropriate error code, and driver may not even have information
on current operational channel.
Signed-off-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Igor Mitsyanko [Thu, 21 Sep 2017 21:34:31 +0000 (14:34 -0700)]
qtnfmac: retrieve current channel info from EP
Do not try to cache current operational channel info in driver, this
is a potential source of synchronization issues + driver does not
really need that info.
Introduce GET_CHANNEL command and process it appropriately.
Signed-off-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Igor Mitsyanko [Thu, 21 Sep 2017 21:34:30 +0000 (14:34 -0700)]
qtnfmac: make "Channel change" event report full channel info
Specifically, it has to report center frequency, secondary center
frequency (for 80+80) and BW.
Introduce channel definition structure to qlink and modify channel
change event processing function accordingly.
Signed-off-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Igor Mitsyanko [Thu, 21 Sep 2017 21:34:29 +0000 (14:34 -0700)]
qtnfmac: convert channel width from bitfiled to simple enum
This will allow to use qlink channel width values to specify BW setting
corresponding to enum nl80211_chan_width.
Current user is converted to apply BIT() macro manually to each individual
qlink_channel_width enumeration value.
Signed-off-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Adam Borowski [Fri, 8 Sep 2017 10:30:00 +0000 (12:30 +0200)]
rtl8xxxu: Don't printk raw binary if serial number is not burned in.
I assume that a blank efuse comes with all ones, thus I did not bother
recognizing other possible junk values. This matches 100% of dongles
I've seen (a single Gembird 8192eu).
Signed-off-by: Adam Borowski <kilobyte@angband.pl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Colin Ian King [Fri, 22 Sep 2017 14:03:16 +0000 (15:03 +0100)]
brcmsmac: make const array ucode_ofdm_rates static, reduces object code size
Don't populate const array ucode_ofdm_rates on the stack, instead make it
static. Makes the object code smaller by 100 bytes:
Before:
text data bss dec hex filename
39482 564 0 40046 9c6e phy_cmn.o
After
text data bss dec hex filename
39326 620 0 39946 9c0a phy_cmn.o
(gcc 6.3.0, x86-64)
Signed-off-by: Colin Ian King <colin.king@canonical.com> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
When CONFIG_PM_SLEEP is disabled, we get a compile-time
warning:
drivers/net/wireless/ath/ath10k/pci.c:3417:12: error: 'ath10k_pci_pm_resume' defined but not used [-Werror=unused-function]
static int ath10k_pci_pm_resume(struct device *dev)
^~~~~~~~~~~~~~~~~~~~
drivers/net/wireless/ath/ath10k/pci.c:3401:12: error: 'ath10k_pci_pm_suspend' defined but not used [-Werror=unused-function]
static int ath10k_pci_pm_suspend(struct device *dev)
Rather than fixing the #ifdef, this just marks both functions
as __maybe_unused, which is a more robust way to do this.
Fixes: 32faa3f0ee50 ("ath10k: add the PCI PM core suspend/resume ops") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Avoid calculating random MAC address in driver. Instead make
use of 'get_random_mask_addr()' function.
Signed-off-by: Ganapathi Bhat <gbhat@marvell.com> Reviewed-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Application will keep track of whether MAC address randomization
is enabled or not during scan. But at present driver is storing
'random_mac' in mwifiex_private which implies even after scan is
done driver has some reference to the earlier 'scan request'. To
avoid this, make use of 'mac_addr' variable in 'scan_request' to
store 'random_mac'. This structure will be freed by cfg80211 once
scan is done.
Signed-off-by: Ganapathi Bhat <gbhat@marvell.com> Reviewed-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
If driver is loaded with 'mfg_mode' enabled, then the sending
commands are not allowed. So, skip sending commands, to firmware
in mwifiex_add_virtual_intf if 'mfg_mode' is enabled.
Fixes: 7311ea850079 ("mwifiex: fix AP start problem for newly added interface") Signed-off-by: Ganapathi Bhat <gbhat@marvell.com> Reviewed-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Ganapathi Bhat [Wed, 30 Aug 2017 19:38:35 +0000 (01:08 +0530)]
mwifiex: notify cfg80211 about scan abort
Driver sends a series of scan commands to firmware to serve a
user scan request. If an intermediate scan command fails, driver
aborts the scan but it is not being informed to cfg80211. This
will cause issues in applications performing periodic scans.
Fix this by informing scan abort.
Signed-off-by: Cathy Luo <cluo@marvell.com> Signed-off-by: Ganapathi Bhat <gbhat@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Larry Finger [Thu, 14 Sep 2017 18:17:44 +0000 (13:17 -0500)]
rtlwifi: rtl8192ee: Fix memory leak when loading firmware
In routine rtl92ee_set_fw_rsvdpagepkt(), the driver allocates an skb, but
never calls rtl_cmd_send_packet(), which will free the buffer. All other
rtlwifi drivers perform this operation correctly.
This problem has been in the driver since it was included in the kernel.
Fortunately, each firmware load only leaks 4 buffers, which likely
explains why it has not previously been detected.
Cc: Stable <stable@vger.kernel.org> # 3.18+ Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Colin Ian King [Tue, 5 Sep 2017 18:16:58 +0000 (19:16 +0100)]
b43legacy: fix unitialized reads of ret by initializing the array to zero
The u8 char array ret is not being initialized and elements outside
the range start to end contain just garbage values from the stack.
This results in a later scan of the array to read potentially
uninitialized values. Fix this by initializing the array to zero.
This seems to have been an issue since the very first commit.
Detected by CoverityScan CID#139653 ("Uninitialized scalar variable")
Signed-off-by: Colin Ian King <colin.king@canonical.com> Reviewed-by: Michael Buesch <m@bues.ch> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Colin Ian King [Tue, 5 Sep 2017 18:15:50 +0000 (19:15 +0100)]
b43: fix unitialized reads of ret by initializing the array to zero
The u8 char array ret is not being initialized and elements outside
the range start to end contain just garbage values from the stack.
This results in a later scan of the array to read potentially
uninitialized values. Fix this by initializing the array to zero.
This seems to have been an issue since the very first commit.
Detected by CoverityScan CID#139652 ("Uninitialized scalar variable")
Signed-off-by: Colin Ian King <colin.king@canonical.com> Reviewed-by: Michael Buesch <m@bues.ch> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>