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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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 7d652034d1 ("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
93a1df48d2 ("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>
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>
For time division multiple access, the wifi and bt take turns to
transmit, but we need to let AP know that wifi is under standby mode by
sending null data to "pretend" entering power saving state using lps
rpwm.
But, the fw does not know if it is the actual power saving mode or just a
fake one to cheat to the AP. Hence, before fw setting the tdma duration,
the fw needs the driver to check the power saving state first.
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>
When driver is going to sleep, it does not leave LPS/IPS, thus the
BTCoex may have mismatch when driver wakes up. To avoid that, BTCoex
needs to clear the IPS/LPS state when it receives a pnp notify, then
it can properly set up the hw when driver wakes up.
Routine ex_btc8821a2ant_pnp_notify() restored.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Pkshih <pkshih@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>
In file halbtc8192e2ant.c, there are directives that depend on an
undocumented configuration parameter BT_AUTO_REPORT_ONLY_8192E_2ANT
that cannot be set from Kconfig. This parameter is replaced by a
boolean in the main structure used by all routines. It still cannot
be changed dynamically, but it is easier to document.
Upon the advice of Realtek, the auto report option is turned on with
this patch.
Routine btc8192e2ant_is_wifi_status_changed() is restored.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Yan-Hsuan Chuang <yhchuang@realtek.com>
Cc: Pkshih <pkshih@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>
In file halbtc8723b2ant.c, there are directives that depend on an
undocumented configuration parameter BT_AUTO_REPORT_ONLY_8723B_2ANT
that cannot be set from Kconfig. This parameter is replaced by a
boolean in the main structure used by all routines. It still cannot
be changed dynamically, but it is easier to document.
Routines halbtc8723b2ant_set_bt_auto_report(), and
btc8723b2ant_bt_auto_report() are restored.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Yan-Hsuan Chuang <yhchuang@realtek.com>
Cc: Pkshih <pkshih@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>
In file halbtc8723b1ant.c, there are directives that depend on an
undocumented configuration parameter BT_AUTO_REPORT_ONLY_8723B_1ANT
that cannot be set from Kconfig. This parameter is replaced by a
boolean in the main structure used by all routines. It still cannot
be changed dynamically, but it is easier to document.
The following routines are restored:
halbtc8723b1ant_bt_auto_report()
halbtc8723b1ant_set_bt_auto_report()
halbtc8723b1ant_action_wifi_only()
halbtc8723b1ant_monitor_bt_enable_disable()
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Yan-Hsuan Chuang <yhchuang@realtek.com>
Cc: Pkshih <pkshih@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>
In file halbtc8821a1ant.c, there are directives that depend on an
undocumented configuration parameter BT_AUTO_REPORT_ONLY_8821A_1ANT
that cannot be set from Kconfig. This parameter is replaced by a
boolean in the main structure used by all routines. It still cannot
be changed dynamically, but it is easier to document.
Using a suggestion from Realtek, the auto report is turned on with this
patch.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Yan-Hsuan Chuang <yhchuang@realtek.com>
Cc: Pkshih <pkshih@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>
