We now have two different minimum valid values for
umac_error_event_table.  To avoid hardcoding the minimum value in the
driver, add a value to cfg where it can be read from.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

There's no point in checking the validity of the
umac_error_event_table pointer every time we generate a dump.  It's
cleaner to do so when we read the value, namely when we receive the
alive data.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

Currently, UMAC error data reading is restricted to DCCM.
A000 NICs use SMEM for this data.
Signed-off-by: Beni Lev <beni.lev@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

All callers of iwl_mvm_release_frames() already have the baid_data
pointer, so we don't need to (re)calculate it inside the function.
Just pass it instead.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

The reason station id and tid fields are both in baid data and
in the reorder buffer per queue is that we couldn't access the
baid_data in the reorder timer functions.
Now that we do some pointer math and access it anyway, those
fields can be removed.
This save some space and some code.
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

Now that we may have up to 256 entries per reorder buffer, and possibly up
to 16 queues, we can use a LOT of memory for this (64k for each station).
Allocate it according to what we need, which is of course much less for HT
stations (only 16k at a max of 16 queues).

However, this comes at the expense of complicating the code a bit to
calculate the right entry structure to use for each frame.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

Using bcma_debug gives a device-specific prefix for messages and pr_cont
is a common helper for continuing a line.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Acked-By: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

The kbuild test robot reports two conditions with no effect (if == else).
These are the result of copy and paste typographical errors.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Ping-Ke Shih <pkshih@realtek.com>
Cc: Yan-Hsuan Chuang <yhchuang@realtek.com>
Cc: Birming Chiu <birming@realtek.com>
Cc: Shaofu <shaofu@realtek.com>
Cc: Steven Ting <steventing@realtek.com>
Cc: kbuild-all@01.org
Cc: Julia Lawall <julia.lawall@lip6.fr>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

Mark Brown reported that there are conflicts in iwlwifi between the two trees
so fix those now.

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: eac4eed3 ("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>

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>

Encryption info is a constant part of STA settings, no point
to pass it as an optional TLV.
Remove QTN_TLV_ID_CRYPTO type as it's not used anymore.
Signed-off-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

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>

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>

QTNF_STATE_AP_CONFIG is redundant and its usage can be safely removed.
Signed-off-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

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>

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>

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>

Clean up unused cur_rfstate variables in rtl8188ee, rtl8723ae, rtl8723be
and rtl8821ae.
Signed-off-by: Christos Gkekas <chris.gekas@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

On some platforms, enable ASPM will cause AER error to be logged, thus
we use a parameter to selectively turn on ASPM.
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>

- 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>

These fields are unused, and we will define them in phydm later.
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>

These definition will be used by phydm later.
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>

The statistic variables use u64 to get higher precision.
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>

Convert from the value of ieee80211_tx_queue_params to Realtek's
register value.
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>

Originally, we get legacy rate only, so we extend to get HT and VHT rate.
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>

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>

The semicolon can cause compiler error, if it exists in if...else
statement.
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>

Use put_unaligned_le32 rather than using byte ordering function and
memcpy which makes code clear.
Also, add the header file where it is declared.

Done using Coccinelle and semantic patch used is :

@ rule1 @
identifier tmp; expression ptr,x; type T;
@@

- tmp = cpu_to_le32(x);

  <+... when != tmp
- memcpy(ptr, (T)&tmp, ...);
+ put_unaligned_le32(x,ptr);
  ...+>

@ depends on rule1 @
type j; identifier tmp;
@@

- j tmp;
  ...when != tmp
Signed-off-by: Himanshu Jha <himanshujha199640@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

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>

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>

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>

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;

Driver will advertise RANDOM_MAC support only if the device
supports this feature.
Signed-off-by: Karthik Ananthapadmanabha <karthida@marvell.com>
Signed-off-by: Ganapathi Bhat <gbhat@marvell.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

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>

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().

Found by syzkaller.

INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
CPU: 1 PID: 1404 Comm: kworker/1:1 Not tainted
4.14.0-rc1-42251-gebb2c243-dirty #205
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
 __dump_stack lib/dump_stack.c:16
 dump_stack+0x292/0x395 lib/dump_stack.c:52
 register_lock_class+0x6c4/0x1a00 kernel/locking/lockdep.c:769
 __lock_acquire+0x27e/0x4550 kernel/locking/lockdep.c:3385
 lock_acquire+0x259/0x620 kernel/locking/lockdep.c:4002
 flush_work+0xf0/0x8c0 kernel/workqueue.c:2886
 __cancel_work_timer+0x51d/0x870 kernel/workqueue.c:2961
 cancel_delayed_work_sync+0x1f/0x30 kernel/workqueue.c:3081
 p54_unregister_leds+0x6c/0xc0 drivers/net/wireless/intersil/p54/led.c:160
 p54_unregister_common+0x3d/0xb0 drivers/net/wireless/intersil/p54/main.c:856
 p54u_disconnect+0x86/0x120 drivers/net/wireless/intersil/p54/p54usb.c:1073
 usb_unbind_interface+0x21c/0xa90 drivers/usb/core/driver.c:423
 __device_release_driver drivers/base/dd.c:861
 device_release_driver_internal+0x4f4/0x5c0 drivers/base/dd.c:893
 device_release_driver+0x1e/0x30 drivers/base/dd.c:918
 bus_remove_device+0x2f4/0x4b0 drivers/base/bus.c:565
 device_del+0x5c4/0xab0 drivers/base/core.c:1985
 usb_disable_device+0x1e9/0x680 drivers/usb/core/message.c:1170
 usb_disconnect+0x260/0x7a0 drivers/usb/core/hub.c:2124
 hub_port_connect drivers/usb/core/hub.c:4754
 hub_port_connect_change drivers/usb/core/hub.c:5009
 port_event drivers/usb/core/hub.c:5115
 hub_event+0x1318/0x3740 drivers/usb/core/hub.c:5195
 process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
 process_scheduled_works kernel/workqueue.c:2179
 worker_thread+0xb2b/0x1850 kernel/workqueue.c:2255
 kthread+0x3a1/0x470 kernel/kthread.c:231
 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431

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>

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.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>