In at least one place, the enter/exit debugging was not being correctly
matched. Based on mailing list feedback, it was desired to drop all of
these in favor of using ftrace instead.
Suggested-by: NJoe Perches <joe@perches.com>
Suggested-by: NKalle Valo <kvalo@codeaurora.org>
Signed-off-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Using memcpy() from a string that is shorter than the length copied means
the destination buffer is being filled with arbitrary data from the kernel
rodata segment. Instead, redefine the stat strings to be ETH_GSTRING_LEN
sizes, like other drivers. This lets us use a single memcpy that does not
leak rodata contents. Additionally adjust indentation to keep checkpatch.pl
happy.

This was found with the future CONFIG_FORTIFY_SOURCE feature.

Cc: Daniel Micay <danielmicay@gmail.com>
Signed-off-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

iwlegacy firmware can crash when power save is configured. PS was
allowed in "dbdac2b5 iwlegacy: properly enable power saving" with belive
that user who enable PS is aware of that and can relate firmware crahes
with PS. However some distributions seems to enable PS without user
intervention, so warn about that.
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

In the stable linux-3.16 branch, I ran into a warning in the
wlcore driver:

drivers/net/wireless/ti/wlcore/spi.c: In function 'wl12xx_spi_raw_write':
drivers/net/wireless/ti/wlcore/spi.c:315:1: error: the frame size of 12848 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]

Newer kernels no longer show the warning, but the bug is still there,
as the allocation is based on the CPU page size rather than the
actual capabilities of the hardware.

This replaces the PAGE_SIZE macro with the SZ_4K macro, i.e. 4096 bytes
per buffer.

Cc: stable@vger.kernel.org
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Use time_after kernel macro for time comparison.
Signed-off-by: NKarim Eshapa <karim.eshapa@gmail.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

The older firmware loading method is not usable by any Redpine chipset.
Hence removing that part of the code. Older firmware image with
rsi_91x.fw name is deprecated
Signed-off-by: NPrameela Rani Garnepudi <prameela.j04cs@gmail.com>
Signed-off-by: NAmitkumar Karwar <amit.karwar@redpinesignals.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

The older firmware loading method has been deprecated and not in use
for any chipets. New method is introduced which works based on soft
boot loader. In this method, complete RAM image and FLASH image are
present in the flash. Before loading the functional firmware, host
issues boot loader commands to verify whether firmware to load is
different from the current functional firmware. If not, firmware
upgrade progresses and boot loader will switch to the new functional
firmware.

"rs9113_wlan_qspi.rps" is the firmware filename used in this patch.
Signed-off-by: NPrameela Rani Garnepudi <prameela.j04cs@gmail.com>
Signed-off-by: NAmitkumar Karwar <amit.karwar@redpinesignals.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Host interface opearation master_reg_read, master_reg_write and
load_data_master_write are added. These functions are needed for the
new firmware loading method. As part of this, the function
master_access_msword is moved from rsi_91x_sdio_ops.c to rsi_91x_sdio.c.
Signed-off-by: NPrameela Rani Garnepudi <prameela.j04cs@gmail.com>
Signed-off-by: NAmitkumar Karwar <amit.karwar@redpinesignals.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Host interface operations are currently function pointers in rsi_hw
structure. As more host interface operations are going to be introduced,
separate structure is added for these for convenience.
Signed-off-by: NPrameela Rani Garnepudi <prameela.j04cs@gmail.com>
Signed-off-by: NAmitkumar Karwar <amit.karwar@redpinesignals.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

USB multibyte read will be used in the new firmware loading method
for RS9113 chipset.
Signed-off-by: NPrameela Rani Garnepudi <prameela.j04cs@gmail.com>
Signed-off-by: NAmitkumar Karwar <amit.karwar@redpinesignals.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

In function usb_write_register_multiple, if any intermediate block transfer
is failed, further operations should be terminated. 'else' is removed, as
there is no significance for it after return.
Signed-off-by: NPrameela Rani Garnepudi <prameela.j04cs@gmail.com>
Signed-off-by: NAmitkumar Karwar <amit.karwar@redpinesignals.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

For USB vendor read and write operations new macros added to avoid
redundant usage of long or'ed macros. Also for timeouts standard USB
macros are used.
Signed-off-by: NPrameela Rani Garnepudi <prameela.j04cs@gmail.com>
Signed-off-by: NAmitkumar Karwar <amit.karwar@redpinesignals.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

USB read and write registers maximum size is limited 2^16. More than
this size is not used in the driver.
Signed-off-by: NPrameela Rani Garnepudi <prameela.j04cs@gmail.com>
Signed-off-by: NAmitkumar Karwar <amit.karwar@redpinesignals.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

RSI_USB_BUF_SIZE macro is used instead of hardcoding a buffer
size to 4096.
Signed-off-by: NAmitkumar Karwar <amit.karwar@redpinesignals.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

SDIO read or write maximum size is limited to 2^16. This is done to make
the host interface operations common for SDIO and USB.
Signed-off-by: NPrameela Rani Garnepudi <prameela.j04cs@gmail.com>
Signed-off-by: NAmitkumar Karwar <amit.karwar@redpinesignals.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

The file rsi_91x_hal.c is going to contain device specific code i.e new
firmware loading method for RS9113 chipset. As the file rsi_91x_pkt.c
contains code to prepare device specific descriptors for transmit packet,
this file is renamed to rsi_91x_hal.c which is more relevant as per it's
functionality.
Signed-off-by: NPrameela Rani Garnepudi <prameela.j04cs@gmail.com>
Signed-off-by: NAmitkumar Karwar <amit.karwar@redpinesignals.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

We have the number of longs, but we should be calculating the number of
bytes needed.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Using memcpy() from a buffer that is shorter than the length copied means
the destination buffer is being filled with arbitrary data from the kernel
rodata segment. In this case, the source was made longer, since it did not
match the destination structure size. Additionally removes a needless cast.

This was found with the future CONFIG_FORTIFY_SOURCE feature.

Cc: Daniel Micay <danielmicay@gmail.com>
Signed-off-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: NElena Reshetova <elena.reshetova@intel.com>
Signed-off-by: NHans Liljestrand <ishkamiel@gmail.com>
Signed-off-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NDavid Windsor <dwindsor@gmail.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.
Signed-off-by: NElena Reshetova <elena.reshetova@intel.com>
Signed-off-by: NHans Liljestrand <ishkamiel@gmail.com>
Signed-off-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NDavid Windsor <dwindsor@gmail.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Upon stopping an AP interface the driver disable INFRA mode effectively
setting the interface in IBSS mode. However, this may affect other
interfaces running in INFRA mode. For instance, if user creates and stops
hostap daemon on virtual interface, then association cannot work on
primary interface because default BSS has been set to IBSS mode in
firmware side. The IBSS mode should be set when cfg80211 changes the
interface.
Reviewed-by: NWright Feng <wright.feng@cypress.com>
Signed-off-by: NChi-hsien Lin <Chi-Hsien.Lin@cypress.com>
[kvalo@codeaurora.org: rephased commit log based on discussion]
Signed-off-by: NWright Feng <wright.feng@cypress.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

setup_timer.cocci suggested the following improvement:
drivers/net/wireless/broadcom/brcm80211/brcmfmac/btcoex.c:383:1-11: Use
setup_timer function for function on line 384.

The combination of init_timer and setting up the data and function field
manually is equivalent to calling setup_timer(). This is an api
consolidation only and improves readability.
Acked-by: NArend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: NXie Qirong <cheerx1994@gmail.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Some firmware entries were forgotten to be added via MODULE_FIRMWARE(), which
may result in the non-functional state when the driver is loaded in initrd.

Link: http://bugzilla.opensuse.org/show_bug.cgi?id=1037344
Fixes: 15be8e89 ("b43: add more bcma cores")
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

ath.git patches for 4.13. Major changes:

ath10k

* add initial SDIO support (still work in progress)

When driver fail to reset card ah->curchan value stay NULL. When
later driver try to update tx power it oops by using ah->curchan
(calltrace is shown below).

This problem were reported at various places and for some it was
fixed by making ath9k_hw_chip_reset() do not fail. I have this bug
report on some oldish RHEL kernel with AR9285, however it's hard to
debug where reset fail when kernel OOPS, so I think this patch
should be applied. Hopefully ah->curchan is not used unconditionally
on other places until is initialized on ath9k_config().

ath: phy0: Chip reset failed
ath: phy0: Unable to reset hardware; reset status -22 (freq 2412 MHz)
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [<f8a35585>] ath9k_hw_set_txpowerlimit+0x25/0x80 [ath9k_hw]
Oops: 0000 [#1] SMP
<snip>
Call Trace:
 [<f8aac1aa>] ? ath9k_cmn_update_txpow+0x1a/0x30 [ath9k_common]
 [<f8cf4f4e>] ? ath_complete_reset+0x4e/0x130 [ath9k]
 [<f8cf54d7>] ? ath9k_start+0x127/0x1e0 [ath9k]
 [<f8c2e52f>] ? ieee80211_do_open+0x30f/0x910 [mac80211]
 [<c07bd96d>] ? dev_open+0x8d/0xf0
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

The array field eeprom_data in struct th9k_platform_data
is a fixed size array so it can never be NULL.

Addresses-Coverity-ID: 1364903
Cc: Arend Van Spriel <arend.vanspriel@broadcom.com>
Cc: Kalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: NGustavo A. R. Silva <garsilva@embeddedor.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Use memdup_user() helper instead of open-coding to simplify the code.
Signed-off-by: NGeliang Tang <geliangtang@gmail.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

The AR5K_EEPROM_READ macro returns with -EIO if a read error
occurs causing a memory leak on the allocated buffer buf. Fix
this by explicitly calling ath5k_hw_nvram_read and exiting on
the via the freebuf label that performs the necessary free'ing
of buf when a read error occurs.

Detected by CoverityScan, CID#1248782 ("Resource Leak")
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

It's spelled hardware, not harware.
Signed-off-by: NAmmly Fredrick <ammlyf@gmail.com>
[kvalo@qca.qualcomm.com: improve commit log]
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

An issue was found brcmfmac driver in which a skbuff in .start_xmit()
callback was actually cloned. So instead of checking for sufficient
headroom it should also be writable. Hence use skb_cow_head() to
check and expand the headroom appropriately.
Signed-off-by: NArend van Spriel <arend.vanspriel@broadcom.com>
Tested-by: NSteve deRosier <derosier@gmail.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Add the missing endianness conversions to a debug statement printing
the USB device-descriptor bcdUSB field during probe.
Signed-off-by: NJohan Hovold <johan@kernel.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

These are already handled by mwifiex_shutdown_sw() and
mwifiex_reinit_sw(). Ideally, we'll kill the flag entirely eventually,
as I suspect it breeds race conditions.
Signed-off-by: NBrian Norris <briannorris@chromium.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Signed-off-by: NBrian Norris <briannorris@chromium.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

These pointers are retrieved via container_of(). There's no way they are
NULL.
Signed-off-by: NBrian Norris <briannorris@chromium.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

We're using 'adapter' right before calling this. Stop being
unnecessarily paranoid.
Signed-off-by: NBrian Norris <briannorris@chromium.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

If mwifiex_shutdown_drv() is racing with another mwifiex_shutdown_drv(),
we *really* have problems. Kill the lock.
Signed-off-by: NBrian Norris <briannorris@chromium.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

When removing or resetting an mwifiex device, we don't remember to free
the saved beacon buffer. Use the (somewhat misleadingly-named)
mwifiex_free_priv() helper to handle this.

Noticed by kmemleak during tests:

echo 1 > /sys/bus/pci/devices/.../reset

unreferenced object 0xffffffc09d034a00 (size 256):
...
  backtrace:
    [<ffffffc0003cdce4>] create_object+0x228/0x3c4
    [<ffffffc000c0b9d8>] kmemleak_alloc+0x54/0x88
    [<ffffffc0003c0848>] __kmalloc+0x1cc/0x2dc
    [<ffffffbffc1500c4>] mwifiex_save_curr_bcn+0x80/0x308 [mwifiex]
    [<ffffffbffc1516b8>] mwifiex_ret_802_11_associate+0x4ec/0x5fc [mwifiex]
    [<ffffffbffc15da90>] mwifiex_process_sta_cmdresp+0xaf8/0x1fa4 [mwifiex]
    [<ffffffbffc1411e0>] mwifiex_process_cmdresp+0x40c/0x510 [mwifiex]
    [<ffffffbffc13b8f4>] mwifiex_main_process+0x4a4/0xb00 [mwifiex]
    [<ffffffbffc13bf84>] mwifiex_main_work_queue+0x34/0x40 [mwifiex]
Signed-off-by: NBrian Norris <briannorris@chromium.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

mwifiex_exec_next_cmd() seems to have a classic TOCTOU race, where we
drop the list lock in between retrieving the next command and deleting
it from the list. This potentially leaves room for someone else to also
retrieve / steal this node from the list (e.g.,
mwifiex_cancel_all_pending_cmd()).

Let's keep holding the lock while we do our 'ps_state' sanity checks.
There should be no harm in continuing to hold this lock for a bit more.

Noticed only by code inspection.
Signed-off-by: NBrian Norris <briannorris@chromium.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

The mwifiex_11n_delba() function walked the rx_reorder_tbl_ptr without
holding the lock, which was an obvious violation.

Grab the lock.

NOTE: we hold the lock while calling mwifiex_send_delba().  There's also
several callers in 11n_rxreorder.c that hold the lock and the comments
in the struct sound just like very other list/lock pair -- as if the
lock should definitely be help for all operations like this.
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Signed-off-by: NBrian Norris <briannorris@chromium.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Just like in the previous patch ("mwifiex: Don't release
tx_ba_stream_tbl_lock while iterating"), in
mwifiex_cancel_all_pending_cmd() we were itearting over a list protected
by a spinlock.  Again, it is not safe to release the spinlock while
iterating.  Don't do it.

Luckily in this case there should be no need to release the spinlock.
This is evidenced by:

1. The only function called while the spinlock was released was
   mwifiex_recycle_cmd_node()
2. Aside from atomic functions (which are safe to call), the only
   function called by mwifiex_recycle_cmd_node() was
   mwifiex_insert_cmd_to_free_q().
3. It can be seen in mwifiex_cancel_pending_scan_cmd() that it's OK to
   call mwifiex_insert_cmd_to_free_q() while holding a different
   spinlock (scan_pending_q_lock), so in general holding a spinlock
   should be OK.
4. It doesn't appear that mwifiex_insert_cmd_to_free_q() has any
   interaction with the cmd_pending_q_lock

No known bugs are fixed with this change, but as with other similar
changes this could fix random list corruption.
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Signed-off-by: NBrian Norris <briannorris@chromium.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>