- 01 Aug, 2017 3 commits
-
-
Johannes Berg authored
Track the current firmware image in the common code instead of in the opmode so that later patches can access it there in a common way. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
Johannes Berg authored
Refactor the shared memory command parsing into common code. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
Johannes Berg authored
Refactor the paging code from mvm to be used by different opmodes. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
- 28 Jul, 2017 37 commits
-
-
Dan Carpenter authored
The cast here is wrong. We want to cast the pointer but we accidentally do a no-op cast of the value. We normally want to set us_nav_upper to WIFI_NAV_UPPER_US (30000) but because of this bug we instead set it to 184 on little endian systems and 0 on big endian ones. Fixes: 3c05bedb ("Staging: rtl8812ae: Add Realtek 8821 PCI WIFI driver") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Souptick Joarder authored
This patch will fix memory leak when firmware request fails Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com> Acked-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Souptick Joarder authored
Removing unused dummy function Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Souptick Joarder authored
_rtl92cu_init_usb_aggregation() can be removed as it is dummy one Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Ping-Ke Shih authored
Use rtlpriv instead of rtlhal as argument, so driver and btcoex use the same definitions. 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>
-
Ping-Ke Shih authored
We should check addr1 to indicate a packet as broadcast or multicast in tx desc. An obvious example, a STA transmit an *unicast* ARP packet where addr1 and DA are the addresses of AP and broadcast respectively. 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>
-
Ping-Ke Shih authored
This is a common enumeration, so we use a common name. 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>
-
Ping-Ke Shih authored
There are new PHY table values for the RTL8723BE. The changes require new parsing code. 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>
-
Ping-Ke Shih authored
With correct amplifier_type, the phy praser can choose correct parameters. 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>
-
Ping-Ke Shih authored
With correct board_type, the phy praser can choose correct parameters. 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>
-
Ping-Ke Shih authored
We use H2C to ask BT's status, and C2H will return the status. 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>
-
Ping-Ke Shih authored
Because it isn't always correct to use EAPOL to check 4-way, we add a timer to handle exception. 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>
-
Colin Ian King authored
Trivial fix to spelling mistake in printk message Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Arvind Yadav authored
pci_device_id are not supposed to change at runtime. All functions working with pci_device_id provided by <linux/pci.h> work with const pci_device_id. So mark the non-const structs as const. Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Colin Ian King authored
Trivial fix to spelling mistake in PDEBUG debug message. Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Dan Williams authored
Causes the PCI stack to complain, and then eventually call the PCI remove function, which ipw2100 is not expecting. It then tries to unregister an already-released netdev and other nasty things, leading to a panic. Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1185518Signed-off-by: Dan Williams <dcbw@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Colin Ian King authored
Trivial fix to spelling mistake in mwifiex_dbg debug message Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Colin Ian King authored
Trivial fix to spelling mistake in aggr_ctrl module parameter message text. Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Xinming Hu authored
Tdls uapsd support capability is default disabled during tdls setup, correspondingly it should also been disabled in tdls config. Signed-off-by: Xinming Hu <huxm@marvell.com> Signed-off-by: Cathy Luo <cluo@marvell.com> Signed-off-by: Zhiyuan Yang <yangzy@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Dan Carpenter authored
We need to unlock if mwifiex_usb_prepare_tx_aggr_skb() fails. Fixes: a2ca85ad ("mwifiex: usb: add timer to flush aggregation packets") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Jeffy Chen authored
We inited wakeup info at the beginning of mwifiex_add_card, so we need to uninit it in the error handling. It's much the same as what we did in: 36908c4e mwifiex: uninit wakeup info when removing device Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com> Reviewed-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Shawn Lin authored
We got a compile warning shows below: drivers/net/wireless/marvell/mwifiex/sdio.c: In function 'mwifiex_sdio_remove': drivers/net/wireless/marvell/mwifiex/sdio.c:377:6: warning: variable 'ret' set but not used [-Wunused-but-set-variable] Per the code, it didn't check if mwifiex_sdio_read_fw_status finish successfully. We should at least check the return of mwifiex_sdio_read_fw_status, otherwise the following check of firmware_stat and adapter->mfg_mode is pointless as the device is probably dead. Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Reviewed-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Brian Norris authored
This print isn't very useful. It's also different between mwifiex_add_card() and mwifiex_reinit_sw(), and I'd like to consolidate them eventually. Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Brian Norris authored
It has some scary comments about "only being called" from the timeout handler, so let's help keep it that way. Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Brian Norris authored
'card->dev' is initialized once and is never cleared. Drop the unnecessary "safety" check, as it simply obscures things, and we don't do this check everywhere (and therefore it's not really "safe"). Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Brian Norris authored
In testing the mwifiex reset code path, I've noticed KASAN complaining about some "overwritten poison values" in our RX buffer descriptors. Because KASAN didn't notice this at the time of a CPU write, this seems to suggest that the device is writing to this memory. This makes a little sense, because when resetting, we don't necessarily expect the device to be responsive, so we don't have a chance to disable everything cleanly. We can at least take the precaution of disabling DMA for the device though, and in my testing that seems to clear up this particular issue. This patch reorders the removal path so that we disable the device *before* releasing our last PCIe buffers, and it clears/sets the bus master feature from the PCI device when resetting. Along the way, remove the insufficient (and confusing) error path in mwifiex_pcie_up_dev() (it doesn't unwind things well enough, and it doesn't propagate its errors upward anyway). Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Brian Norris authored
The card_reset() implementation should be setting our state flags and cancelling commands for us (i.e., in mwifiex_shutdown_drv()), so let's not do it here. Also, this debugfs file is useful for testing and debugging the reset feature, so we shouldn't do extra preparatory steps here, as that might cause different reset behavior, which could either cause new bugs or paper over existing ones that this debug feature should otherwise help us catch. Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Brian Norris authored
After removing the interrupt loop in commit 5d5ddb5e ("mwifiex: pcie: don't loop/retry interrupt status checks"), there is practically zero difference between mwifiex_process_pcie_int() (which handled legacy PCI interrupts and MSI interrupts) and mwifiex_process_msix_int() (which handled MSI-X interrupts). Let's add the one relevant line to mwifiex_process_pcie_int() and kill the copy-and-paste. Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Brian Norris authored
After removing the interrupt loop in commit 5d5ddb5e ("mwifiex: pcie: don't loop/retry interrupt status checks"), we don't need to keep track of the cleared interrupts (actually, we didn't need to do that before, but we *really* don't need to now). Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Brian Norris authored
It's always called with 'true' -- we only determine it 'false' locally within this function. So drop the parameter. Also, this should be 'bool' (since we use true/false), not 'u32'. 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
We're open-coding these. Just use the helpers. Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Brian Norris authored
It doesn't fail. Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Brian Norris authored
Despite the name (and meticulous comments), this function frees no memory and does not touch any locks. All it does is "delete" the list heads -- which just means they'll be dangling, and we'll need to re-init them if we use them again. It seems like this code would work OK as a sort of canary for using the list after we've torn everything down, so it's fine to keep the code; let's just get the name and comments to match what's actually happening. Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Brian Norris authored
The .idle_time field *should* be unused, but technically, we're allowing unitialized stack garbage to pass all the way through to the firmware host command. Let's zero it out instead. Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Brian Norris authored
In reading through _mwifiex_fw_dpc(), I noticed that after we've registered our wiphy, we still have error paths that don't free it back up. Let's do that. Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Brian Norris authored
When we leave the delete interface function, there are still netdev hooks that might try to process the device. We're short-circuiting some of that by changing the interface type and clearing ieee80211_ptr. This means we skip NETDEV_UNREGISTER_FINAL in cfg80211. Fortunately, that is currently a no-op. We don't need most of the cleanup here anyway: * the connection state will get (un)set as part of the disconnect process (which cfg80211 already initiates for us) * the interface type doesn't actually need to be cleared at all (it'll trigger a WARN_ON() in cfg80211 if we do) * the iee80211_ptr isn't really "ours" to clear anyway So stop resetting those 3 things. Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-