SDIO ID 0271:0418
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Bugzilla-ID: https://bugzilla.kernel.org/show_bug.cgi?id=67921Reviewed-by: NSteve deRosier <steve.derosier@lairdtech.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

This reverts commit 171f6402 ("ath9k_hw: implement temperature compensation
support for AR9003+"). Some users report that this commit causes a regression
in performance under some conditions.

Fixes: 171f6402 ("ath9k_hw: implement temperature compensation support for AR9003+")
Cc: <stable@vger.kernel.org> # 4.8
Signed-off-by: NFelix Fietkau <nbd@nbd.name>
[kvalo@qca.qualcomm.com: improve commit log]
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Commit 0b8e3c4c ("ath10k: move cal data len to hw_params") broke retrieving
the calibration data from cal_data debugfs file. The length of file was always
zero. The reason is:

    static ssize_t ath10k_debug_cal_data_read(struct file *file,
                                          char __user *user_buf,
                                          size_t count, loff_t *ppos)
    {
        struct ath10k *ar = file->private_data;
        void *buf = file->private_data;

This is obviously bogus, private_data cannot contain both struct ath10k and the
buffer. Fix it by caching calibration data to ar->debug.cal_data. This also
allows it to be accessed when the device is not active (interface is down).

The cal_data buffer is fixed size because during the first firmware probe we
don't yet know what will be the lenght of the calibration data. It was simplest
just to use a fixed length. There's a WARN_ON() in
ath10k_debug_cal_data_fetch() if the buffer is too small.

Tested with qca988x and firmware 10.2.4.70.56.
Reported-by: NNikolay Martynov <mar.kolya@gmail.com>
Fixes: 0b8e3c4c ("ath10k: move cal data len to hw_params")
Cc: stable@vger.kernel.org # 4.7+
Signed-off-by: NMarty Faltesek <mfaltesek@google.com>
[kvalo@qca.qualcomm.com: improve commit log and minor other changes]
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

In commit d86e6476 ("rtlwifi: rtl818x: constify local structures"),
the configuration struct for most of the drivers was changed to be
constant. The problem is that five of the modified drivers need to be
able to update the firmware name based on the exact model of the card.
As the file names were stored in one of the members of that struct,
these drivers would fail with a kernel BUG splat when they tried to
update the firmware name.

Rather than reverting the previous commit, I used a suggestion by
Johannes Berg and made the firmware file name pointers be local to
the routines that update the software variables.

The configuration struct of rtl8192cu, which was not touched in the
previous patch, is now constantfied.

Fixes: d86e6476 ("rtlwifi: rtl818x: constify local structures")
Suggested-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.kernel.org> # 4.8
Cc: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

The 8192eu suffered from two issues when reloading the driver.

The same problems as with the 8723bu where REG_RX_WAIT_CCA bits 22 and
23 didn't get set in rtl8192e_enable_rf().

In addition it also seems prone to issues when setting REG_RF_CTRL to
0 intead of just disabling the RF_ENABLE bit. Similar to what was
causing issues with the 8188eu.

With this patch I can successfully reload the driver and reassociate
to an APi with an 8192eu dongle.
Signed-off-by: NJes Sorensen <Jes.Sorensen@redhat.com>
Cc: stable@vger.kernel.org # 4.8+
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

The generic disable_rf() function clears bits 22 and 23 in
REG_RX_WAIT_CCA, however we did not re-enable them again in
rtl8723b_enable_rf()

This resolves the problem for me with 8723bu devices not working again
after reloading the driver.
Signed-off-by: NJes Sorensen <Jes.Sorensen@redhat.com>
Cc: stable@vger.kernel.org # 4.7+
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

The full RX descriptor is converted so converting tsfl again would
return it to it's original endian value.
Signed-off-by: NJes Sorensen <Jes.Sorensen@redhat.com>
Cc: stable@vger.kernel.org # 4.8+
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

A device running without RX package aggregation could return more data
in the USB packet than the actual network packet. In this case we
could would clone the skb but then determine that that there was no
packet to handle and exit without freeing the cloned skb first.

This has so far only been observed with 8188eu devices, but could
affect others.
Signed-off-by: NJes Sorensen <Jes.Sorensen@redhat.com>
Cc: stable@vger.kernel.org # 4.8+
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

It's not necessary to free memory allocated with devm_kzalloc
and using kfree leads to a double free.

Fixes: d776fc86 ("wlcore: sdio: Populate config firmware data")
Signed-off-by: NWei Yongjun <weiyongjun1@huawei.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

When building with W=1, we got one warning as belows:
drivers/net/wireless/ath/ath6kl/wmi.c:3509:6: warning: variable ‘ret’
set but not used [-Wunused-but-set-variable]

At the end of ath6kl_wmi_set_pvb_cmd, it is returned by 0 regardless of
return value of ath6kl_wmi_cmd_send.
This patch fixes return value from 0 to ret that has result of
ath6kl_wmi_cmd_send execution.
Signed-off-by: NChaehyun Lim <chaehyun.lim@gmail.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

ath9k RNG will dominates all the noise sources from the real HW
RNG, disable it by default. But we strongly recommand to enable
it if the system without HW RNG, especially on embedded systems.
Signed-off-by: NMiaoqing Pan <miaoqing@codeaurora.org>
Acked-by: NStephan Mueller <smueller@chronox.de>
Acked-by: NStephan Mueller <smueller@chronox.de>
Reviewed-by: NJason Cooper <jason@lakedaemon.net>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Firmware is running watchdog timer for tracking copy engine ring index
and write index. Whenever both indices are stuck at same location for
given duration, watchdog will be trigger to assert target. While
updating copy engine destination ring write index, driver ensures that
write index will not be same as read index by finding delta between these
two indices (CE_RING_DELTA).

HTT target to host copy engine (CE5) is special case where ring buffers
will be reused and delta check is not applied while updating write index.
In rare scenario, whenever CE5 ring is full, both indices will be referring
same location and this is causing CE ring stuck issue as explained
above. This issue is originally reported on IPQ4019 during long hour stress
testing and during veriwave max clients testsuites. The same issue is
also observed in other chips as well. Fix this by ensuring that write
index is one less than read index which means that full ring is
available for receiving data.

Cc: stable@vger.kernel.org
Tested-by: NTamizh chelvam <c_traja@qti.qualcomm.com>
Signed-off-by: NRajkumar Manoharan <rmanohar@qti.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Ignore processing further in SWBA event scheduled for a vif, if mac80211
has marked the particular vif for stop beaconing and brought the vdev
down in 'ath10k_control_beaconing'. This should potentially avoid ath10k
warning/error messages while running continuous wifi down/up with max
number of vaps configured. Found this change during code walk through
and going through other beacon configuration related functions in ath10k
Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Fix to return a negative error code from the error handling case
instead of 0, as done elsewhere in function ath10k_ahb_probe() or
ath10k_ahb_resource_init().
Signed-off-by: NWei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Flowrings contain skbs waiting for transmission that were passed to us
by netif. It means we checked every one of them looking for 802.1x
Ethernet type. When deleting flowring we have to use freeing function
that will check for 802.1x type as well.

Freeing skbs without a proper check was leading to counter not being
properly decreased. This was triggering a WARNING every time
brcmf_netdev_wait_pend8021x was called.
Signed-off-by: NRafał Miłecki <rafal@milecki.pl>
Acked-by: NArend van Spriel <arend@broadcom.com>
Cc: stable@vger.kernel.org # 4.5+
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Even with timeout increased to 950 ms we get WARNINGs from time to time.
It mostly happens on A-MPDU stalls (e.g. when station goes out of
range). It may take up to 5-10 secods for the firmware to recover and
for that time it doesn't process packets.

It's still useful to have a message on time out as it may indicate some
firmware problem and incorrect key update. Raising a WARNING however
wasn't really that necessary, it doesn't point to any driver bug anymore
and backtrace wasn't much useful.
Signed-off-by: NRafał Miłecki <rafal@milecki.pl>
Acked-by: NArend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

The entries in this enum may be referenced in debug output. Adding explicit
values simplifies the lookup.
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Only rtl8821ae implements WOWLAN; however, the other drivers may receive
a call requesting information about this mode. The other drivers need to
ignore the request rather than logging that the default branch of the
switch statement has been reached.

Reported by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Help along debugging by showing what switch/case variable is not
being processed in these messages.
Signed-off-by: NJoe Perches <joe@perches.com>
Acked-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

The (1 << x) - 1 trick won't work when you
are trying to fill up all 64 bits, so add special
case for that.
Signed-off-by: NBen Greear <greearb@candelatech.com>
[kvalo@qca.qualcomm.com: remove the sentence about moving limits]
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

They are not necessarily named in an intuitive manner,
so at least add some comments to help the next person.
Signed-off-by: NBen Greear <greearb@candelatech.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Signed-off-by: NBen Greear <greearb@candelatech.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Chipset from QCA99X0 onwards (QCA99X0, QCA9984, QCA4019 & future)
rx_hdr_status is not padded to align in 4-byte boundary. Define a
new hw_params field to handle different alignment behaviour between
different hw. This patch fixes improper retrieval of rfc1042 header
with QCA4019. This patch along with "ath10k: Properly remove padding
from the start of rx payload" will fix traffic failure in ethernet
decap mode for QCA4019.
Signed-off-by: NVasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Since reset_control_get() never returns NULL, we can use IS_ERR()
instead of IS_ERR_OR_NULL().  The return statements can be simpler
as well.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Use the managed variant of reset_control_get() to simplify the
failure path and the .remove callback.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Use the managed variant of clk_get() to simplify the failure path
and the .remove callback.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Correct some trivial comment typos.
Remove unnecessary parentheses in a long line.
Signed-off-by: NJoe Perches <joe@perches.com>
[kvalo@qca.qualcomm.com: drop the change for return]
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

When we unshare a queue, the ADD_STA was not properly
initialised.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

The firmware has a new smart linker, and this table can now be
in ICCM or in SMEM. It is not hardcoded, but depends on code
size. Allow the full range.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

This define should really be TX_CMD_SEC_KEY_FROM_TABLE
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

FW versions older than -17 for 3160 and 7260 and older than -22 for
newer NICs are not supported anymore.  Don't load these versions
and remove code that handles them.
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

They seem to be there from the first day. We calculate these values but
never use them.
Signed-off-by: NRafał Miłecki <rafal@milecki.pl>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

This function is called from get_station callback which means that every
time user space was getting/dumping station(s) we were leaking 2 KiB.
Signed-off-by: NRafał Miłecki <rafal@milecki.pl>
Fixes: 1f0dc59a ("brcmfmac: rework .get_station() callback")
Cc: stable@vger.kernel.org # 4.2+
Acked-by: NArend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

As soon as debugging is turned on, the logs are filled with messages
reporting the interrupt status. As this quantity is usually zero, this
output is not needed. In fact, there will be a report if the status is
not zero, thus the debug line in question could probably be deleted.
Rather than taking that action, I have changed it to only be printed
when the newly added RTL8XXXU_DEBUG_INTERRUPT bit is set in the debug
mask.
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NJes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

This saves some 217, or about, derefences of priv->fops.
Signed-off-by: NJes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Remove last_tx_page argument from the llt_init() function. The
rtl8xxxu_fileops structure contains the correct TX_TOTAL_PAGE_NUM
value for the device, and rtl8xxxu_auto_llt_table() doesn't need to
know the value in the first place.
Signed-off-by: NJes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

This was detected tracing the 8188eu driver, but doesn't seem to make
any difference when using it.
Signed-off-by: NJes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

This patch helps get rid of goto statement and improves readability.
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NCathy Luo <cluo@marvell.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

It's been observed that in a corner case mwifiex_usb_tx_complete()
gets called before we exit from mwifiex_usb_host_to_card() after
submitting the urb. 'data_sent' flag remains set in this case. It
blocks further Tx packets and triggers watchdog timeout.

The problem is fixed by setting data_sent and port_block flag at
correct place.
Signed-off-by: NCathy Luo <cluo@marvell.com>
Signed-off-by: NShengzhen Li <szli@marvell.com>
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Following crash issue is observed during TCP traffic stress
test

[ 2253.625439] NMI watchdog: BUG: soft lockup - CPU#3 stuck for 22s!
[kworker/u17:1:5191]
[ 2253.625520] Call Trace:
[ 2253.625527]  [<ffffffffc0b47030>] ? moal_spin_lock+0x30/0x30
[usb8xxx]
[ 2253.625533]  [<ffffffffc0ac3ceb>] ? wlan_wmm_lists_empty+0xb/0xf0
[mlan]
[ 2253.625537]  [<ffffffffc0ab0ea3>] mlan_main_process+0x1b3/0x720
[mlan]
[ 2253.625540]  [<ffffffffc0b337f5>] woal_main_work_queue+0x45/0x80
[usb8xxx]
[ 2253.625543]  [<ffffffff8108aaf0>] process_one_work+0x150/0x3f0
[ 2253.625545]  [<ffffffff8108b1e1>] worker_thread+0x121/0x520
[ 2253.625547]  [<ffffffff8108b0c0>] ? rescuer_thread+0x330/0x330
[ 2253.625549]  [<ffffffff81090222>] kthread+0xd2/0xf0
[ 2253.625551]  [<ffffffff81090150>] ?
kthread_create_on_node+0x1c0/0x1c0
[ 2253.625553]  [<ffffffff8179423c>] ret_from_fork+0x7c/0xb0
[ 2253.625555]  [<ffffffff81090150>] ?
kthread_create_on_node+0x1c0/0x1c0

In mwifiex_usb_tx_complete(), we are updating port->block_status first
and then freeing the skb attached to that URB. We may end up attaching
new skb to URB in a corner case and same will be freed. This results in
the kernel crash. The problem is solved by changing the sequence.
Signed-off-by: NCathy Luo <cluo@marvell.com>
Signed-off-by: NShengzhen Li <szli@marvell.com>
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>