summaryrefslogtreecommitdiff
path: root/drivers/net/wireless/marvell/mwifiex/pcie.c
AgeCommit message (Collapse)Author
2025-04-23wifi: mwifiex: Don't use %pK through printkThomas Weißschuh
In the past %pK was preferable to %p as it would not leak raw pointer values into the kernel log. Since commit ad67b74d2469 ("printk: hash addresses printed with %p") the regular %p has been improved to avoid this issue. Furthermore, restricted pointers ("%pK") were never meant to be used through printk(). They can still unintentionally leak raw pointers or acquire sleeping looks in atomic contexts. Switch to the regular pointer formatting which is safer and easier to reason about. There are still a few users of %pK left, but these use it through seq_file, for which its usage is safe. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Acked-by: Brian Norris <briannorris@chromium.org> Link: https://patch.msgid.link/20250417-restricted-pointers-wifi-v1-1-b79cdaae5579@linutronix.de Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-04-05treewide: Switch/rename to timer_delete[_sync]()Thomas Gleixner
timer_delete[_sync]() replaces del_timer[_sync](). Convert the whole tree over and remove the historical wrapper inlines. Conversion was done with coccinelle plus manual fixups where necessary. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org>
2025-01-28wifi: mwifiex: Constify struct mwifiex_if_opsChristophe JAILLET
'struct mwifiex_if_ops' are not modified in these drivers. Constifying these structures moves some data to a read-only section, so increase overall security, especially when the structure holds some function pointers. On a x86_64, with allmodconfig, as an example: Before: ====== text data bss dec hex filename 61439 4367 32 65838 1012e drivers/net/wireless/marvell/mwifiex/pcie.o After: ===== text data bss dec hex filename 61699 4127 32 65858 10142 drivers/net/wireless/marvell/mwifiex/pcie.o Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/03d524b72f20a0302e4de5e0ebdc20ab69469dec.1737308889.git.christophe.jaillet@wanadoo.fr
2023-09-22wifi: mwifiex: followup PCIE and related cleanupsDmitry Antipov
Introduce a few more (PCIE and generic interface related) cleanups which becomes reasonable after the previous patch. Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Acked-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230919132804.73340-2-dmantipov@yandex.ru
2023-09-22wifi: mwifiex: simplify PCIE write operationsDmitry Antipov
Since 'mwifiex_write_reg()' just issues void 'iowrite32()', convert the former to 'void' and simplify all related users (with the only exception of 'read_poll_timeout()' which explicitly requires a non-void function argument). Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Acked-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230919132804.73340-1-dmantipov@yandex.ru
2023-09-21wifi: mwifiex: use MODULE_FIRMWARE to add firmware files metadataVíctor Gonzalo
The mwifiex_pcie driver is missing the MODULE_FIRMWARE macro to add the firmware files needed to the module metadata. Signed-off-by: Víctor Gonzalo <victor.gonzalo@anddroptable.net> Acked-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230914211938.28395-1-victor.gonzalo@anddroptable.net
2023-08-02wifi: mwifiex: fix error recovery in PCIE buffer descriptor managementDmitry Antipov
Add missing 'kfree_skb()' in 'mwifiex_init_rxq_ring()' and never do 'kfree(card->rxbd_ring_vbase)' because this area is DMAed and should be released with 'dma_free_coherent()'. The latter is performed in 'mwifiex_pcie_delete_rxbd_ring()', which is now called to recover from possible errors in 'mwifiex_pcie_create_rxbd_ring()'. Likewise for 'mwifiex_pcie_init_evt_ring()', 'kfree(card->evtbd_ring_vbase)' 'mwifiex_pcie_delete_evtbd_ring()' and 'mwifiex_pcie_create_rxbd_ring()'. Fixes: d930faee141b ("mwifiex: add support for Marvell pcie8766 chipset") Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Acked-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230731074334.56463-1-dmantipov@yandex.ru
2023-03-15wifi: mwifiex: mark OF related data as maybe unusedKrzysztof Kozlowski
The driver can be compile tested with !CONFIG_OF making certain data unused: drivers/net/wireless/marvell/mwifiex/sdio.c:498:34: error: ‘mwifiex_sdio_of_match_table’ defined but not used [-Werror=unused-const-variable=] drivers/net/wireless/marvell/mwifiex/pcie.c:175:34: error: ‘mwifiex_pcie_of_match_table’ defined but not used [-Werror=unused-const-variable=] Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230312132523.352182-1-krzysztof.kozlowski@linaro.org
2022-09-07wifi: mwifiex: mark a variable unusedJohannes Berg
We need to read a value from the device to wake it, but if it succeeds we don't really care about it. Mark the variable to avoid a compiler warning. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220904212910.5d67f55178a1.If0789ab326935896e5886fa06dbb9ef0da6c0b41@changeid
2022-08-04Merge tag 'spdx-6.0-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/spdx Pull SPDX updates from Greg KH: "Here is the set of SPDX comment updates for 6.0-rc1. Nothing huge here, just a number of updated SPDX license tags and cleanups based on the review of a number of common patterns in GPLv2 boilerplate text. Also included in here are a few other minor updates, two USB files, and one Documentation file update to get the SPDX lines correct. All of these have been in the linux-next tree for a very long time" * tag 'spdx-6.0-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/spdx: (28 commits) Documentation: samsung-s3c24xx: Add blank line after SPDX directive x86/crypto: Remove stray comment terminator treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_406.RULE treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_398.RULE treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_391.RULE treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_390.RULE treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_385.RULE treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_320.RULE treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_319.RULE treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_318.RULE treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_298.RULE treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_292.RULE treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_179.RULE treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_168.RULE (part 2) treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_168.RULE (part 1) treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_160.RULE treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_152.RULE treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_149.RULE treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_147.RULE treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_133.RULE ...
2022-07-27wifi: mwifiex: clean up one inconsistent indentingYang Li
Eliminate the follow smatch warning: drivers/net/wireless/marvell/mwifiex/pcie.c:3364 mwifiex_unregister_dev() warn: inconsistent indenting Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: Yang Li <yang.lee@linux.alibaba.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220615005316.9596-1-yang.lee@linux.alibaba.com
2022-06-10treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_391.RULEThomas Gleixner
Based on the normalized pattern: this software file (the file ) is distributed by nxp under the terms of the gnu general public license version 2 june 1991 (the license ) you may use redistribute and/or modify this file in accordance with the terms and conditions of the license a copy of which is available by writing to the free software foundation inc 51 franklin street fifth floor boston ma 02110-1301 usa or on the worldwide web at http://www gnu org/licenses/old-licenses/gpl-2 0 txt the file is distributed as-is without warranty of any kind and the implied warranties of merchantability or fitness for a particular purpose are expressly disclaimed the license provides additional details about this warranty disclaimer extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference. Reviewed-by: Allison Randal <allison@lohutok.net> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-26mwifiex: Ignore BTCOEX events from the 88W8897 firmwareJonas Dreßler
The firmware of the 88W8897 PCIe+USB card sends those events very unreliably, sometimes bluetooth together with 2.4ghz-wifi is used and no COEX event comes in, and sometimes bluetooth is disabled but the coexistance mode doesn't get disabled. This means we sometimes end up capping the rx/tx window size while bluetooth is not enabled anymore, artifically limiting wifi speeds even though bluetooth is not being used. Since we can't fix the firmware, let's just ignore those events on the 88W8897 device. From some Wireshark capture sessions it seems that the Windows driver also doesn't change the rx/tx window sizes when bluetooth gets enabled or disabled, so this is fairly consistent with the Windows driver. Signed-off-by: Jonas Dreßler <verdre@v0yd.nl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211103205827.14559-1-verdre@v0yd.nl
2021-10-18mwifiex: Try waking the firmware until we get an interruptJonas Dreßler
It seems that the PCIe+USB firmware (latest version 15.68.19.p21) of the 88W8897 card sometimes ignores or misses when we try to wake it up by writing to the firmware status register. This leads to the firmware wakeup timeout expiring and the driver resetting the card because we assume the firmware has hung up or crashed. Turns out that the firmware actually didn't hang up, but simply "missed" our wakeup request and didn't send us an interrupt with an AWAKE event. Trying again to read the firmware status register after a short timeout usually makes the firmware wake up as expected, so add a small retry loop to mwifiex_pm_wakeup_card() that looks at the interrupt status to check whether the card woke up. The number of tries and timeout lengths for this were determined experimentally: The firmware usually takes about 500 us to wake up after we attempt to read the status register. In some cases where the firmware is very busy (for example while doing a bluetooth scan) it might even miss our requests for multiple milliseconds, which is why after 15 tries the waiting time gets increased to 10 ms. The maximum number of tries it took to wake the firmware when testing this was around 20, so a maximum number of 50 tries should give us plenty of safety margin. Here's a reproducer for those firmware wakeup failures I've found: 1) Make sure wifi powersaving is enabled (iw dev wlp1s0 set power_save on) 2) Connect to any wifi network (makes firmware go into wifi powersaving mode, not deep sleep) 3) Make sure bluetooth is turned off (to ensure the firmware actually enters powersave mode and doesn't keep the radio active doing bluetooth stuff) 4) To confirm that wifi powersaving is entered ping a device on the LAN, pings should be a few ms higher than without powersaving 5) Run "while true; do iwconfig; sleep 0.0001; done", this wakes and suspends the firmware extremely often 6) Wait until things explode, for me it consistently takes <5 minutes BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=109681 Cc: stable@vger.kernel.org Signed-off-by: Jonas Dreßler <verdre@v0yd.nl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211011133224.15561-3-verdre@v0yd.nl
2021-10-18mwifiex: Read a PCI register after writing the TX ring write pointerJonas Dreßler
On the 88W8897 PCIe+USB card the firmware randomly crashes after setting the TX ring write pointer. The issue is present in the latest firmware version 15.68.19.p21 of the PCIe+USB card. Those firmware crashes can be worked around by reading any PCI register of the card after setting that register, so read the PCI_VENDOR_ID register here. The reason this works is probably because we keep the bus from entering an ASPM state for a bit longer, because that's what causes the cards firmware to crash. This fixes a bug where during RX/TX traffic and with ASPM L1 substates enabled (the specific substates where the issue happens appear to be platform dependent), the firmware crashes and eventually a command timeout appears in the logs. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=109681 Cc: stable@vger.kernel.org Signed-off-by: Jonas Dreßler <verdre@v0yd.nl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211011133224.15561-2-verdre@v0yd.nl
2021-08-29mwifiex: pcie: add reset_d3cold quirk for Surface gen4+ devicesTsuchiya Yuto
To reset mwifiex on Surface gen4+ (Pro 4 or later gen) devices, it seems that putting the wifi device into D3cold is required according to errata.inf file on Windows installation (Windows/INF/errata.inf). This patch adds a function that performs power-cycle (put into D3cold then D0) and call the function at the end of reset_prepare(). Note: Need to also reset the parent device (bridge) of wifi on SB1; it might be because the bridge of wifi always reports it's in D3hot. When I tried to reset only the wifi device (not touching parent), it gave the following error and the reset failed: acpi device:4b: Cannot transition to power state D0 for parent in D3hot mwifiex_pcie 0000:03:00.0: can't change power state from D3cold to D0 (config space inaccessible) Signed-off-by: Tsuchiya Yuto <kitakar@gmail.com> Signed-off-by: Jonas Dreßler <verdre@v0yd.nl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210820142050.35741-3-verdre@v0yd.nl
2021-08-29mwifiex: pcie: add DMI-based quirk implementation for Surface devicesJonas Dreßler
This commit adds the ability to apply device-specific quirks to the mwifiex driver. It uses DMI matching similar to the quirks brcmfmac uses with dmi.c. We'll add identifiers to match various MS Surface devices, which this is primarily meant for, later. This commit is a slightly modified version of a previous patch sent in by Tsuchiya Yuto. Co-developed-by: Tsuchiya Yuto <kitakar@gmail.com> Signed-off-by: Tsuchiya Yuto <kitakar@gmail.com> Signed-off-by: Jonas Dreßler <verdre@v0yd.nl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210820142050.35741-2-verdre@v0yd.nl
2021-05-17mwifiex: re-fix for unaligned accessesArnd Bergmann
A patch from 2017 changed some accesses to DMA memory to use get_unaligned_le32() and similar interfaces, to avoid problems with doing unaligned accesson uncached memory. However, the change in the mwifiex_pcie_alloc_sleep_cookie_buf() function ended up changing the size of the access instead, as it operates on a pointer to u8. Change this function back to actually access the entire 32 bits. Note that the pointer is aligned by definition because it came from dma_alloc_coherent(). Fixes: 92c70a958b0b ("mwifiex: fix for unaligned reads") Acked-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2021-01-14mwifiex: pcie: Drop bogus __refdata annotationGeert Uytterhoeven
As the Marvell PCIE WiFi-Ex driver does not have any code or data located in initmem, there is no need to annotate the mwifiex_pcie structure with __refdata. Drop the annotation, to avoid suppressing future section warnings. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20201211133835.2970384-1-geert+renesas@glider.be
2020-11-10mwifiex: pcie: skip cancel_work_sync() on reset failure pathTsuchiya Yuto
If a reset is performed, but even the reset fails for some reasons (e.g., on Surface devices, the fw reset requires another quirks), cancel_work_sync() hangs in mwifiex_cleanup_pcie(). # firmware went into a bad state [...] [ 1608.281690] mwifiex_pcie 0000:03:00.0: info: shutdown mwifiex... [ 1608.282724] mwifiex_pcie 0000:03:00.0: rx_pending=0, tx_pending=1, cmd_pending=0 [ 1608.292400] mwifiex_pcie 0000:03:00.0: PREP_CMD: card is removed [ 1608.292405] mwifiex_pcie 0000:03:00.0: PREP_CMD: card is removed # reset performed after firmware went into a bad state [ 1609.394320] mwifiex_pcie 0000:03:00.0: WLAN FW already running! Skip FW dnld [ 1609.394335] mwifiex_pcie 0000:03:00.0: WLAN FW is active # but even the reset failed [ 1619.499049] mwifiex_pcie 0000:03:00.0: mwifiex_cmd_timeout_func: Timeout cmd id = 0xfa, act = 0xe000 [ 1619.499094] mwifiex_pcie 0000:03:00.0: num_data_h2c_failure = 0 [ 1619.499103] mwifiex_pcie 0000:03:00.0: num_cmd_h2c_failure = 0 [ 1619.499110] mwifiex_pcie 0000:03:00.0: is_cmd_timedout = 1 [ 1619.499117] mwifiex_pcie 0000:03:00.0: num_tx_timeout = 0 [ 1619.499124] mwifiex_pcie 0000:03:00.0: last_cmd_index = 0 [ 1619.499133] mwifiex_pcie 0000:03:00.0: last_cmd_id: fa 00 07 01 07 01 07 01 07 01 [ 1619.499140] mwifiex_pcie 0000:03:00.0: last_cmd_act: 00 e0 00 00 00 00 00 00 00 00 [ 1619.499147] mwifiex_pcie 0000:03:00.0: last_cmd_resp_index = 3 [ 1619.499155] mwifiex_pcie 0000:03:00.0: last_cmd_resp_id: 07 81 07 81 07 81 07 81 07 81 [ 1619.499162] mwifiex_pcie 0000:03:00.0: last_event_index = 2 [ 1619.499169] mwifiex_pcie 0000:03:00.0: last_event: 58 00 58 00 58 00 58 00 58 00 [ 1619.499177] mwifiex_pcie 0000:03:00.0: data_sent=0 cmd_sent=1 [ 1619.499185] mwifiex_pcie 0000:03:00.0: ps_mode=0 ps_state=0 [ 1619.499215] mwifiex_pcie 0000:03:00.0: info: _mwifiex_fw_dpc: unregister device # mwifiex_pcie_work hang happening [ 1823.233923] INFO: task kworker/3:1:44 blocked for more than 122 seconds. [ 1823.233932] Tainted: G WC OE 5.10.0-rc1-1-mainline #1 [ 1823.233935] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 1823.233940] task:kworker/3:1 state:D stack: 0 pid: 44 ppid: 2 flags:0x00004000 [ 1823.233960] Workqueue: events mwifiex_pcie_work [mwifiex_pcie] [ 1823.233965] Call Trace: [ 1823.233981] __schedule+0x292/0x820 [ 1823.233990] schedule+0x45/0xe0 [ 1823.233995] schedule_timeout+0x11c/0x160 [ 1823.234003] wait_for_completion+0x9e/0x100 [ 1823.234012] __flush_work.isra.0+0x156/0x210 [ 1823.234018] ? flush_workqueue_prep_pwqs+0x130/0x130 [ 1823.234026] __cancel_work_timer+0x11e/0x1a0 [ 1823.234035] mwifiex_cleanup_pcie+0x28/0xd0 [mwifiex_pcie] [ 1823.234049] mwifiex_free_adapter+0x24/0xe0 [mwifiex] [ 1823.234060] _mwifiex_fw_dpc+0x294/0x560 [mwifiex] [ 1823.234074] mwifiex_reinit_sw+0x15d/0x300 [mwifiex] [ 1823.234080] mwifiex_pcie_reset_done+0x50/0x80 [mwifiex_pcie] [ 1823.234087] pci_try_reset_function+0x5c/0x90 [ 1823.234094] process_one_work+0x1d6/0x3a0 [ 1823.234100] worker_thread+0x4d/0x3d0 [ 1823.234107] ? rescuer_thread+0x410/0x410 [ 1823.234112] kthread+0x142/0x160 [ 1823.234117] ? __kthread_bind_mask+0x60/0x60 [ 1823.234124] ret_from_fork+0x22/0x30 [...] This is a deadlock caused by calling cancel_work_sync() in mwifiex_cleanup_pcie(): - Device resets are done via mwifiex_pcie_card_reset() - which schedules card->work to call mwifiex_pcie_card_reset_work() - which calls pci_try_reset_function(). - This leads to mwifiex_pcie_reset_done() be called on the same workqueue, which in turn calls - mwifiex_reinit_sw() and that calls - _mwifiex_fw_dpc(). The problem is now that _mwifiex_fw_dpc() calls mwifiex_free_adapter() in case firmware initialization fails. That ends up calling mwifiex_cleanup_pcie(). Note that all those calls are still running on the workqueue. So when mwifiex_cleanup_pcie() now calls cancel_work_sync(), it's really waiting on itself to complete, causing a deadlock. This commit fixes the deadlock by skipping cancel_work_sync() on a reset failure path. After this commit, when reset fails, the following output is expected to be shown: kernel: mwifiex_pcie 0000:03:00.0: info: _mwifiex_fw_dpc: unregister device kernel: mwifiex: Failed to bring up adapter: -5 kernel: mwifiex_pcie 0000:03:00.0: reinit failed: -5 To reproduce this issue, for example, try putting the root port of wifi into D3 (replace "00:1d.3" with your setup). # put into D3 (root port) sudo setpci -v -s 00:1d.3 CAP_PM+4.b=0b Cc: Maximilian Luz <luzmaximilian@gmail.com> Signed-off-by: Tsuchiya Yuto <kitakar@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20201028142346.18355-1-kitakar@gmail.com
2020-11-07mwifiex: pcie: Remove a couple of unchecked 'ret'sLee Jones
Fixes the following W=1 kernel build warning(s): drivers/net/wireless/marvell/mwifiex/pcie.c: In function ‘mwifiex_pcie_remove’: drivers/net/wireless/marvell/mwifiex/pcie.c:432:6: warning: variable ‘ret’ set but not used [-Wunused-but-set-variable] drivers/net/wireless/marvell/mwifiex/pcie.c: In function ‘mwifiex_cleanup_pcie’: drivers/net/wireless/marvell/mwifiex/pcie.c:3142:6: warning: variable ‘ret’ set but not used [-Wunused-but-set-variable] Cc: Amitkumar Karwar <amitkarwar@gmail.com> Cc: Ganapathi Bhat <ganapathi.bhat@nxp.com> Cc: Xinming Hu <huxinming820@gmail.com> Cc: Kalle Valo <kvalo@codeaurora.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Cc: linux-wireless@vger.kernel.org Cc: netdev@vger.kernel.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20201102112410.1049272-32-lee.jones@linaro.org
2020-09-01mwifiex: pcie: Move tables to the only place they're usedLee Jones
Saves on 10's of complains about 'defined but not used' variables. Fixes the following W=1 kernel build warning(s): In file included from drivers/net/wireless/marvell/mwifiex/main.h:57, from drivers/net/wireless/marvell/mwifiex/main.c:22: drivers/net/wireless/marvell/mwifiex/pcie.h:310:41: warning: ‘mwifiex_pcie8997’ defined but not used [-Wunused-const-variable=] 310 | static const struct mwifiex_pcie_device mwifiex_pcie8997 = { | ^~~~~~~~~~~~~~~~ drivers/net/wireless/marvell/mwifiex/pcie.h:300:41: warning: ‘mwifiex_pcie8897’ defined but not used [-Wunused-const-variable=] 300 | static const struct mwifiex_pcie_device mwifiex_pcie8897 = { | ^~~~~~~~~~~~~~~~ drivers/net/wireless/marvell/mwifiex/pcie.h:292:41: warning: ‘mwifiex_pcie8766’ defined but not used [-Wunused-const-variable=] 292 | static const struct mwifiex_pcie_device mwifiex_pcie8766 = { | ^~~~~~~~~~~~~~~~ NB: Repeats 10's of times - snipped for brevity. Cc: Amitkumar Karwar <amitkarwar@gmail.com> Cc: Ganapathi Bhat <ganapathi.bhat@nxp.com> Cc: Xinming Hu <huxinming820@gmail.com> Cc: Kalle Valo <kvalo@codeaurora.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Cc: linux-wireless@vger.kernel.org Cc: netdev@vger.kernel.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200826093401.1458456-2-lee.jones@linaro.org
2020-08-27mwifiex: Clean up some err and dbg messagesChristophe JAILLET
The error message if 'pci_set_consistent_dma_mask()' fails is misleading. The function call uses 32 bits, but the error message reports 64. Moreover, according to the comment above 'dma_set_mask_and_coherent()' definition, such an error can never happen. So, simplify code, axe the misleading message and use 'dma_set_mask_and_coherent()' instead of 'dma_set_mask()' + 'dma_set_coherent_mask()' While at it, make some clean-up: - add # when reporting allocated length to be consistent between functions - s/consistent/coherent/ - s/unsigned int/u32/ to be consistent between functions - align some code Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200819071853.113185-1-christophe.jaillet@wanadoo.fr
2020-08-27mwifiex: switch from 'pci_' to 'dma_' APIChristophe JAILLET
The wrappers in include/linux/pci-dma-compat.h should go away. The patch has been generated with the coccinelle script below and has been hand modified to replace GFP_ with a correct flag. It has been compile tested. When memory is allocated in 'mwifiex_pcie_alloc_buffers()' (see details in the call chain below) GFP_KERNEL can be used because both 'mwifiex_register()' and 'mwifiex_reinit_sw()' already use GFP_KERNEL. (for 'mwifiex_reinit_sw()', it is hidden in a call to 'alloc_workqueue()') The call chain is: mwifiex_register --> mwifiex_init_pcie (.init_if function, see mwifiex_if_ops) [ or ] mwifiex_reinit_sw -->mwifiex_pcie_up_dev (.up_dev function, see mwifiex_if_ops) [ then in both case ] -->mwifiex_pcie_alloc_buffers --> mwifiex_pcie_create_txbd_ring --> mwifiex_pcie_create_rxbd_ring --> mwifiex_pcie_create_evtbd_ring --> mwifiex_pcie_alloc_sleep_cookie_buf @@ @@ - PCI_DMA_BIDIRECTIONAL + DMA_BIDIRECTIONAL @@ @@ - PCI_DMA_TODEVICE + DMA_TO_DEVICE @@ @@ - PCI_DMA_FROMDEVICE + DMA_FROM_DEVICE @@ @@ - PCI_DMA_NONE + DMA_NONE @@ expression e1, e2, e3; @@ - pci_alloc_consistent(e1, e2, e3) + dma_alloc_coherent(&e1->dev, e2, e3, GFP_) @@ expression e1, e2, e3; @@ - pci_zalloc_consistent(e1, e2, e3) + dma_alloc_coherent(&e1->dev, e2, e3, GFP_) @@ expression e1, e2, e3, e4; @@ - pci_free_consistent(e1, e2, e3, e4) + dma_free_coherent(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_map_single(e1, e2, e3, e4) + dma_map_single(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_unmap_single(e1, e2, e3, e4) + dma_unmap_single(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4, e5; @@ - pci_map_page(e1, e2, e3, e4, e5) + dma_map_page(&e1->dev, e2, e3, e4, e5) @@ expression e1, e2, e3, e4; @@ - pci_unmap_page(e1, e2, e3, e4) + dma_unmap_page(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_map_sg(e1, e2, e3, e4) + dma_map_sg(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_unmap_sg(e1, e2, e3, e4) + dma_unmap_sg(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_single_for_cpu(e1, e2, e3, e4) + dma_sync_single_for_cpu(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_single_for_device(e1, e2, e3, e4) + dma_sync_single_for_device(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_sg_for_cpu(e1, e2, e3, e4) + dma_sync_sg_for_cpu(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_sg_for_device(e1, e2, e3, e4) + dma_sync_sg_for_device(&e1->dev, e2, e3, e4) @@ expression e1, e2; @@ - pci_dma_mapping_error(e1, e2) + dma_mapping_error(&e1->dev, e2) @@ expression e1, e2; @@ - pci_set_dma_mask(e1, e2) + dma_set_mask(&e1->dev, e2) @@ expression e1, e2; @@ - pci_set_consistent_dma_mask(e1, e2) + dma_set_coherent_mask(&e1->dev, e2) Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200819070152.111522-1-christophe.jaillet@wanadoo.fr
2020-02-14mwifiex: change license text from MARVELL to NXPGanapathi Bhat
As of 6-DEC-2019, NXP has acquired Marvell’s Wireless business unit. This change is to update the license text accordingly. Signed-off-by: James Cao <zheng.cao@nxp.com> Signed-off-by: Cathy Luo <xiaohua.luo@nxp.com> Signed-off-by: Ganapathi Bhat <ganapathi.bhat@nxp.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-10-09mwifiex: pcie: Fix memory leak in mwifiex_pcie_init_evt_ringNavid Emamdoost
In mwifiex_pcie_init_evt_ring, a new skb is allocated which should be released if mwifiex_map_pci_memory() fails. The release for skb and card->evtbd_ring_vbase is added. Fixes: 0732484b47b5 ("mwifiex: separate ring initialization and ring creation routines") Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com> Acked-by: Ganapathi Bhat <gbhat@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-10-09mwifiex: pcie: Fix memory leak in mwifiex_pcie_alloc_cmdrsp_bufNavid Emamdoost
In mwifiex_pcie_alloc_cmdrsp_buf, a new skb is allocated which should be released if mwifiex_map_pci_memory() fails. The release is added. Fixes: fc3314609047 ("mwifiex: use pci_alloc/free_consistent APIs for PCIe") Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com> Acked-by: Ganapathi Bhat <gbhat@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-08-06mwifiex: pcie: Use dev_get_drvdataChuhong Yuan
Instead of using to_pci_dev + pci_get_drvdata, use dev_get_drvdata to make code simpler. Signed-off-by: Chuhong Yuan <hslester96@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-06-25mwifiex: print PCI mmap with %pKBrian Norris
Unadorned '%p' has restrictive policies these days, such that it usually just prints garbage at early boot (see Documentation/core-api/printk-formats.rst, "kernel will print ``(ptrval)`` until it gathers enough entropy"). Annotating with %pK (for "kernel pointer") allows the kptr_restrict sysctl to control printing policy better. We might just as well drop this message entirely, but this fix was easy enough for now. Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-06-25mwifiex: drop 'set_consistent_dma_mask' log messageBrian Norris
This message is pointless. While we're at it, include the error code in the error message, which is not pointless. Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-07-31mwifiex: use atomic bitops to represent adapter status variablesGanapathi Bhat
Driver is using boolean variables to maintain vairous status information of adapter. These status variables are accessed by multiple threads and there is a possibility of a race. To avoid this, convert these variables to a set of bitops flags, to be operated atomically. Below variables of mwifiex_adapter are converted to bitop flags: surprise_removed is_cmd_timedout is_suspended is_hs_configured hs_enabling Signed-off-by: Ganapathi Bhat <gbhat@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-05-23mwifiex: support sysfs initiated device coredumpArend Van Spriel
Since commit 3c47d19ff4dc ("drivers: base: add coredump driver ops") it is possible to initiate a device coredump from user-space. This patch adds support for it adding the .coredump() driver callback. As there is no longer a need to initiate it through debugfs remove that code. Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-04-25mwifiex: pcie: tighten a check in mwifiex_pcie_process_event_ready()Dan Carpenter
If "evt_len" is 1 then we try to memcpy() negative 3 bytes and it would cause memory corruption. Fixes: d930faee141b ("mwifiex: add support for Marvell pcie8766 chipset") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-01-16mwifiex: resolve reset vs. remove()/shutdown() deadlocksBrian Norris
Commit b014e96d1abb ("PCI: Protect pci_error_handlers->reset_notify() usage with device_lock()") resolves races between driver reset and removal, but it introduces some new deadlock problems. If we see a timeout while we've already started suspending, removing, or shutting down the driver, we might see: (a) a worker thread, running mwifiex_pcie_work() -> mwifiex_pcie_card_reset_work() -> pci_reset_function() (b) a removal thread, running mwifiex_pcie_remove() -> mwifiex_free_adapter() -> mwifiex_unregister() -> mwifiex_cleanup_pcie() -> cancel_work_sync(&card->work) Unfortunately, mwifiex_pcie_remove() already holds the device lock that pci_reset_function() is now requesting, and so we see a deadlock. It's necessary to cancel and synchronize our outstanding work before tearing down the driver, so we can't have this work wait indefinitely for the lock. It's reasonable to only "try" to reset here, since this will mostly happen for cases where it's already difficult to reset the firmware anyway (e.g., while we're suspending or powering off the system). And if reset *really* needs to happen, we can always try again later. Fixes: b014e96d1abb ("PCI: Protect pci_error_handlers->reset_notify() usage with device_lock()") Cc: <stable@vger.kernel.org> Cc: Xinming Hu <huxm@marvell.com> Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-01-16Revert "mwifiex: cancel pcie/sdio work in remove/shutdown handler"Brian Norris
This reverts commit b713bbf1471b56b572ce26bd02b81a85c2b007f4. The "fix" in question does not actually fix all related problems, and it also introduces new deadlock possibilities. Since commit b014e96d1abb ("PCI: Protect pci_error_handlers->reset_notify() usage with device_lock()"), the race in question is actually resolved (PCIe reset cannot happen at the same time as remove()). Instead, this "fix" just introduces a deadlock where mwifiex_pcie_card_reset_work() is waiting on device_lock, which is held by PCIe device remove(), which is waiting on...mwifiex_pcie_card_reset_work(). The proper thing to do is just to fix the deadlock. Patch for this will come separately. Cc: Signed-off-by: Xinming Hu <huxm@marvell.com> Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-01-08mwifiex: cancel pcie/sdio work in remove/shutdown handlerXinming Hu
The last command used to shutdown firmware might be timeout, and trigger firmware dump in asynchronous pcie/sdio work. The remove/shutdown handler will continue free core data structure private/adapter, which might be dereferenced in pcie/sdio work, finally crash the kernel. Sync and Cancel pcie/sdio work, could be a fix for above cornel case. In this way, the last command timeout could be handled properly. Signed-off-by: Xinming Hu <huxm@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-01-08mwifiex: refactor device dump code to make it generic for usb interfaceXinming Hu
This patch refactor current device dump code to make it generic for subsequent implementation on usb interface. Signed-off-by: Xinming Hu <huxm@marvell.com> Signed-off-by: Cathy Luo <cluo@marvell.com> Signed-off-by: Ganapathi Bhat <gbhat@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2017-08-03mwifiex: pcie: compatible with wifi-only image while extract wifi-part fwXinming Hu
Sometimes, we might using wifi-only firmware with a combo firmware name, in this case, do not need to filter bluetooth part from header. Signed-off-by: Xinming Hu <huxm@marvell.com> Signed-off-by: Cathy Luo <cluo@marvell.com> Reviewed-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2017-07-28mwifiex: pcie: remove unnecessary 'pdev' checkBrian Norris
'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>
2017-07-28mwifiex: pcie: disable device DMA before unmapping/freeing buffersBrian Norris
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>
2017-07-28mwifiex: pcie: unify MSI-X / non-MSI-X interrupt processBrian Norris
After removing the interrupt loop in commit 5d5ddb5e0d9b ("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>
2017-07-28mwifiex: pcie: remove unnecessary masksBrian Norris
After removing the interrupt loop in commit 5d5ddb5e0d9b ("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>
2017-07-28mwifiex: pcie: don't allow cmd buffer reuse after resetBrian Norris
In rogue cases (due to other bugs) it's possible we try to process an old command response *after* resetting the device. This could trigger a double-free (or the SKB can get reallocated elsewhere...causing other memory corruptions) in mwifiex_pcie_process_cmd_complete(). For safety (and symmetry) let's always NULL out the command buffer as we free it up. We're already doing this for the command response buffer. Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2017-07-08Merge tag 'pci-v4.13-changes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci Pull PCI updates from Bjorn Helgaas: - add sysfs max_link_speed/width, current_link_speed/width (Wong Vee Khee) - make host bridge IRQ mapping much more generic (Matthew Minter, Lorenzo Pieralisi) - convert most drivers to pci_scan_root_bus_bridge() (Lorenzo Pieralisi) - mutex sriov_configure() (Jakub Kicinski) - mutex pci_error_handlers callbacks (Christoph Hellwig) - split ->reset_notify() into ->reset_prepare()/reset_done() (Christoph Hellwig) - support multiple PCIe portdrv interrupts for MSI as well as MSI-X (Gabriele Paoloni) - allocate MSI/MSI-X vector for Downstream Port Containment (Gabriele Paoloni) - fix MSI IRQ affinity pre/post/min_vecs issue (Michael Hernandez) - test INTx masking during enumeration, not at run-time (Piotr Gregor) - avoid using device_may_wakeup() for runtime PM (Rafael J. Wysocki) - restore the status of PCI devices across hibernation (Chen Yu) - keep parent resources that start at 0x0 (Ard Biesheuvel) - enable ECRC only if device supports it (Bjorn Helgaas) - restore PRI and PASID state after Function-Level Reset (CQ Tang) - skip DPC event if device is not present (Keith Busch) - check domain when matching SMBIOS info (Sujith Pandel) - mark Intel XXV710 NIC INTx masking as broken (Alex Williamson) - avoid AMD SB7xx EHCI USB wakeup defect (Kai-Heng Feng) - work around long-standing Macbook Pro poweroff issue (Bjorn Helgaas) - add Switchtec "running" status flag (Logan Gunthorpe) - fix dra7xx incorrect RW1C IRQ register usage (Arvind Yadav) - modify xilinx-nwl IRQ chip for legacy interrupts (Bharat Kumar Gogada) - move VMD SRCU cleanup after bus, child device removal (Jon Derrick) - add Faraday clock handling (Linus Walleij) - configure Rockchip MPS and reorganize (Shawn Lin) - limit Qualcomm TLP size to 2K (hardware issue) (Srinivas Kandagatla) - support Tegra MSI 64-bit addressing (Thierry Reding) - use Rockchip normal (not privileged) register bank (Shawn Lin) - add HiSilicon Kirin SoC PCIe controller driver (Xiaowei Song) - add Sigma Designs Tango SMP8759 PCIe controller driver (Marc Gonzalez) - add MediaTek PCIe host controller support (Ryder Lee) - add Qualcomm IPQ4019 support (John Crispin) - add HyperV vPCI protocol v1.2 support (Jork Loeser) - add i.MX6 regulator support (Quentin Schulz) * tag 'pci-v4.13-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci: (113 commits) PCI: tango: Add Sigma Designs Tango SMP8759 PCIe host bridge support PCI: Add DT binding for Sigma Designs Tango PCIe controller PCI: rockchip: Use normal register bank for config accessors dt-bindings: PCI: Add documentation for MediaTek PCIe PCI: Remove __pci_dev_reset() and pci_dev_reset() PCI: Split ->reset_notify() method into ->reset_prepare() and ->reset_done() PCI: xilinx: Make of_device_ids const PCI: xilinx-nwl: Modify IRQ chip for legacy interrupts PCI: vmd: Move SRCU cleanup after bus, child device removal PCI: vmd: Correct comment: VMD domains start at 0x10000, not 0x1000 PCI: versatile: Add local struct device pointers PCI: tegra: Do not allocate MSI target memory PCI: tegra: Support MSI 64-bit addressing PCI: rockchip: Use local struct device pointer consistently PCI: rockchip: Check for clk_prepare_enable() errors during resume MAINTAINERS: Remove Wenrui Li as Rockchip PCIe driver maintainer PCI: rockchip: Configure RC's MPS setting PCI: rockchip: Reconfigure configuration space header type PCI: rockchip: Split out rockchip_pcie_cfg_configuration_accesses() PCI: rockchip: Move configuration accesses into rockchip_pcie_cfg_atu() ...
2017-07-03PCI: Split ->reset_notify() method into ->reset_prepare() and ->reset_done()Christoph Hellwig
The pci_error_handlers->reset_notify() method had a flag to indicate whether to prepare for or clean up after a reset. The prepare and done cases have no shared functionality whatsoever, so split them into separate methods. [bhelgaas: changelog, update locking comments] Link: http://lkml.kernel.org/r/20170601111039.8913-3-hch@lst.de Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2017-05-31mwifiex: use variable interface header lengthXinming Hu
Usb tx aggregation feature will utilize 4-bytes bus interface header, otherwise it will be set to zero in default case. Signed-off-by: Xinming Hu <huxm@marvell.com> Signed-off-by: Cathy Luo <cluo@marvell.com> Signed-off-by: Ganapathi Bhat <gbhat@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2017-05-19mwifiex: pcie: stop setting/clearing 'surprise_removed'Brian Norris
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>
2017-05-19mwifiex: pcie: remove useless pdev checkBrian Norris
Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2017-05-19mwifiex: pcie: de-duplicate buffer allocation codeBrian Norris
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>
2017-05-18mwifiex: pcie: add card_reset() supportBrian Norris
Similar to the SDIO driver, we should implement this so that we will automatically reset the device whenever there's a command timeout or similar. Signed-off-by: Brian Norris <briannorris@chromium.org> Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
generated by cgit (git 2.34.1) at 2025-08-01 05:51:21 +0000