- 24 May, 2017 12 commits
-
-
Karim Eshapa authored
Use time_after kernel macro for time comparison. Signed-off-by: Karim Eshapa <karim.eshapa@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Prameela Rani Garnepudi authored
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: Prameela Rani Garnepudi <prameela.j04cs@gmail.com> Signed-off-by: Amitkumar Karwar <amit.karwar@redpinesignals.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Prameela Rani Garnepudi authored
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: Prameela Rani Garnepudi <prameela.j04cs@gmail.com> Signed-off-by: Amitkumar Karwar <amit.karwar@redpinesignals.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Prameela Rani Garnepudi authored
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: Prameela Rani Garnepudi <prameela.j04cs@gmail.com> Signed-off-by: Amitkumar Karwar <amit.karwar@redpinesignals.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Prameela Rani Garnepudi authored
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: Prameela Rani Garnepudi <prameela.j04cs@gmail.com> Signed-off-by: Amitkumar Karwar <amit.karwar@redpinesignals.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Prameela Rani Garnepudi authored
USB multibyte read will be used in the new firmware loading method for RS9113 chipset. Signed-off-by: Prameela Rani Garnepudi <prameela.j04cs@gmail.com> Signed-off-by: Amitkumar Karwar <amit.karwar@redpinesignals.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Prameela Rani Garnepudi authored
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: Prameela Rani Garnepudi <prameela.j04cs@gmail.com> Signed-off-by: Amitkumar Karwar <amit.karwar@redpinesignals.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Prameela Rani Garnepudi authored
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: Prameela Rani Garnepudi <prameela.j04cs@gmail.com> Signed-off-by: Amitkumar Karwar <amit.karwar@redpinesignals.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Prameela Rani Garnepudi authored
USB read and write registers maximum size is limited 2^16. More than this size is not used in the driver. Signed-off-by: Prameela Rani Garnepudi <prameela.j04cs@gmail.com> Signed-off-by: Amitkumar Karwar <amit.karwar@redpinesignals.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
amit karwar authored
RSI_USB_BUF_SIZE macro is used instead of hardcoding a buffer size to 4096. Signed-off-by: Amitkumar Karwar <amit.karwar@redpinesignals.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Prameela Rani Garnepudi authored
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: Prameela Rani Garnepudi <prameela.j04cs@gmail.com> Signed-off-by: Amitkumar Karwar <amit.karwar@redpinesignals.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Prameela Rani Garnepudi authored
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: Prameela Rani Garnepudi <prameela.j04cs@gmail.com> Signed-off-by: Amitkumar Karwar <amit.karwar@redpinesignals.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
- 22 May, 2017 7 commits
-
-
Dan Carpenter authored
We have the number of longs, but we should be calculating the number of bytes needed. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Kees Cook authored
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: Kees Cook <keescook@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Elena Reshetova authored
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: Elena Reshetova <elena.reshetova@intel.com> Signed-off-by: Hans Liljestrand <ishkamiel@gmail.com> Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: David Windsor <dwindsor@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Elena Reshetova authored
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: Elena Reshetova <elena.reshetova@intel.com> Signed-off-by: Hans Liljestrand <ishkamiel@gmail.com> Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: David Windsor <dwindsor@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Chi-hsien Lin authored
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: Wright Feng <wright.feng@cypress.com> Signed-off-by: Chi-hsien Lin <Chi-Hsien.Lin@cypress.com> [kvalo@codeaurora.org: rephased commit log based on discussion] Signed-off-by: Wright Feng <wright.feng@cypress.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Xie Qirong authored
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: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Xie Qirong <cheerx1994@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Takashi Iwai authored
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: Takashi Iwai <tiwai@suse.de> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
- 19 May, 2017 20 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.gitKalle Valo authored
ath.git patches for 4.13. Major changes: ath10k * add initial SDIO support (still work in progress)
-
Stanislaw Gruszka authored
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: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
-
Gustavo A. R. Silva authored
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: Gustavo A. R. Silva <garsilva@embeddedor.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
-
Geliang Tang authored
Use memdup_user() helper instead of open-coding to simplify the code. Signed-off-by: Geliang Tang <geliangtang@gmail.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
-
Colin Ian King authored
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: Colin Ian King <colin.king@canonical.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
-
Ammly Fredrick authored
It's spelled hardware, not harware. Signed-off-by: Ammly Fredrick <ammlyf@gmail.com> [kvalo@qca.qualcomm.com: improve commit log] Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
-
Arend Van Spriel authored
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: Arend van Spriel <arend.vanspriel@broadcom.com> Tested-by: Steve deRosier <derosier@gmail.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
-
Johan Hovold authored
Add the missing endianness conversions to a debug statement printing the USB device-descriptor bcdUSB field during probe. Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Brian Norris authored
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: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Brian Norris authored
Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Brian Norris authored
These pointers are retrieved via container_of(). There's no way they are NULL. Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Brian Norris authored
We're using 'adapter' right before calling this. Stop being unnecessarily paranoid. Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Brian Norris authored
If mwifiex_shutdown_drv() is racing with another mwifiex_shutdown_drv(), we *really* have problems. Kill the lock. Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Brian Norris authored
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: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Brian Norris authored
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: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Douglas Anderson authored
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: Douglas Anderson <dianders@chromium.org> Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Douglas Anderson authored
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: Douglas Anderson <dianders@chromium.org> Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Douglas Anderson authored
Despite the macro list_for_each_entry_safe() having the word "safe" in the name, it's still not actually safe to release the list spinlock while iterating over the list. The "safe" in the macro name actually only means that it's safe to delete the current entry while iterating over the list. Releasing the spinlock while iterating over the list means that someone else could come in and adjust the list while we don't have the spinlock. If they do that it can totally mix up our iteration and fully corrupt the list. Later iterating over a corrupted list while holding a spinlock and having IRQs off can cause all sorts of hard to debug problems. As evidenced by the other call to mwifiex_11n_delete_tx_ba_stream_tbl_entry() in mwifiex_11n_delete_all_tx_ba_stream_tbl(), it's actually safe to skip the spinlock release. Let's do that. No known problems are fixed by this patch, but it could fix all sorts of weird problems and it should be very safe. Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Brian Norris authored
If we fail to add an interface in mwifiex_add_virtual_intf(), we might hit a BUG_ON() in the networking code, because we didn't tear things down properly. Among the problems: (a) when failing to allocate workqueues, we fail to unregister the netdev before calling free_netdev() (b) even if we do try to unregister the netdev, we're still holding the rtnl lock, so the device never properly unregistered; we'll be at state NETREG_UNREGISTERING, and then hit free_netdev()'s: BUG_ON(dev->reg_state != NETREG_UNREGISTERED); (c) we're allocating some dependent resources (e.g., DFS workqueues) after we've registered the interface; this may or may not cause problems, but it's good practice to allocate these before registering (d) we're not even trying to unwind anything when mwifiex_send_cmd() or mwifiex_sta_init_cmd() fail To fix these issues, let's: * add a stacked set of error handling labels, to keep error handling consistent and properly ordered (resolving (a) and (d)) * move the workqueue allocations before the registration (to resolve (c); also resolves (b) by avoiding error cases where we have to unregister) [Incidentally, it's pretty easy to interrupt the alloc_workqueue() in, e.g., the following: iw phy phy0 interface add mlan0 type station by sending it SIGTERM.] This bugfix covers commits like commit 7d652034 ("mwifiex: channel switch support for mwifiex"), but parts of this bug exist all the way back to the introduction of dynamic interface handling in commit 93a1df48 ("mwifiex: add cfg80211 handlers add/del_virtual_intf"). Cc: <stable@vger.kernel.org> Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Brian Norris authored
This code was duplicated as part of the PCIe FLR code added to this driver. Let's de-duplicate it to: * make things easier to read (mwifiex_pcie_free_buffers() now has a corresponding mwifiex_pcie_alloc_buffers()) * reduce likelihood of bugs * make error logging equally verbose * save lines of code! Also drop some of the commentary that isn't really needed. Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
- 18 May, 2017 1 commit
-
-
Colin Ian King authored
Trivial fix to spelling mistake in RT_TRACE text Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-