linux-stable.git/drivers/net/wireless/microchip, branch linux-6.11.y Linux kernel stable tree wifi: wilc1000: Set MAC after operation mode 2024-12-05T12:53:15+00:00 Marek Vasut marex@denx.de 2024-10-03T13:24:17+00:00 f27d4f33a3da487b7c9b1000d489d982dafb3ccf [ Upstream commit 29dd3e48b9bd88bf65a1e760126fa18d1def7b30 ] It seems it is necessary to set WILC MAC address after operation mode, otherwise the MAC address of the WILC MAC is reset back to what is in nvmem. This causes a failure to associate with AP after the WILC MAC address was overridden by userspace. Test case: " ap$ cat << EOF > hostap.conf interface=wlan0 ssid=ssid hw_mode=g channel=6 wpa=2 wpa_passphrase=pass wpa_key_mgmt=WPA-PSK EOF ap$ hostapd -d hostap.conf ap$ ifconfig wlan0 10.0.0.1 " " sta$ ifconfig wlan0 hw ether 00:11:22:33:44:55 sta$ wpa_supplicant -i wlan0 -c <(wpa_passphrase ssid pass) sta$ ifconfig wlan0 10.0.0.2 sta$ ping 10.0.0.1 # fails without this patch " AP still indicates SA with original MAC address from nvmem without this patch: " nl80211: RX frame da=ff:ff:ff:ff:ff:ff sa=60:01:23:45:67:89 bssid=ff:ff:ff:ff:ff:ff ... ^^^^^^^^^^^^^^^^^ " Fixes: 83d9b54ee5d4 ("wifi: wilc1000: read MAC address from fuse at probe") Tested-by: Alexis Lothoré <alexis.lothore@bootlin.com> Signed-off-by: Marek Vasut <marex@denx.de> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20241003132504.52233-1-marex@denx.de Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 29dd3e48b9bd88bf65a1e760126fa18d1def7b30 ]

It seems it is necessary to set WILC MAC address after operation mode,
otherwise the MAC address of the WILC MAC is reset back to what is in
nvmem. This causes a failure to associate with AP after the WILC MAC
address was overridden by userspace.

Test case:
"
ap$ cat << EOF > hostap.conf
interface=wlan0
ssid=ssid
hw_mode=g
channel=6
wpa=2
wpa_passphrase=pass
wpa_key_mgmt=WPA-PSK
EOF
ap$ hostapd -d hostap.conf
ap$ ifconfig wlan0 10.0.0.1
"

"
sta$ ifconfig wlan0 hw ether 00:11:22:33:44:55
sta$ wpa_supplicant -i wlan0 -c <(wpa_passphrase ssid pass)
sta$ ifconfig wlan0 10.0.0.2
sta$ ping 10.0.0.1 # fails without this patch
"

AP still indicates SA with original MAC address from nvmem without this patch:
"
nl80211: RX frame da=ff:ff:ff:ff:ff:ff sa=60:01:23:45:67:89 bssid=ff:ff:ff:ff:ff:ff ...
                                          ^^^^^^^^^^^^^^^^^
"

Fixes: 83d9b54ee5d4 ("wifi: wilc1000: read MAC address from fuse at probe")
Tested-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Marek Vasut <marex@denx.de>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/20241003132504.52233-1-marex@denx.de
Signed-off-by: Sasha Levin <sashal@kernel.org>
wifi: radiotap: Avoid -Wflex-array-member-not-at-end warnings 2024-12-05T12:52:36+00:00 Gustavo A. R. Silva gustavoars@kernel.org 2024-10-04T20:14:44+00:00 119f99d7f6eff6d97f3b4f656ba4828c42e82bff [ Upstream commit 57be3d3562ca4aa62b8047bc681028cc402af8ce ] -Wflex-array-member-not-at-end was introduced in GCC-14, and we are getting ready to enable it, globally. So, in order to avoid ending up with a flexible-array member in the middle of multiple other structs, we use the `__struct_group()` helper to create a new tagged `struct ieee80211_radiotap_header_fixed`. This structure groups together all the members of the flexible `struct ieee80211_radiotap_header` except the flexible array. As a result, the array is effectively separated from the rest of the members without modifying the memory layout of the flexible structure. We then change the type of the middle struct members currently causing trouble from `struct ieee80211_radiotap_header` to `struct ieee80211_radiotap_header_fixed`. We also want to ensure that in case new members need to be added to the flexible structure, they are always included within the newly created tagged struct. For this, we use `static_assert()`. This ensures that the memory layout for both the flexible structure and the new tagged struct is the same after any changes. This approach avoids having to implement `struct ieee80211_radiotap_header_fixed` as a completely separate structure, thus preventing having to maintain two independent but basically identical structures, closing the door to potential bugs in the future. So, with these changes, fix the following warnings: drivers/net/wireless/ath/wil6210/txrx.c:309:50: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] drivers/net/wireless/intel/ipw2x00/ipw2100.c:2521:50: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] drivers/net/wireless/intel/ipw2x00/ipw2200.h:1146:42: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] drivers/net/wireless/intel/ipw2x00/libipw.h:595:36: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] drivers/net/wireless/marvell/libertas/radiotap.h:34:42: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] drivers/net/wireless/marvell/libertas/radiotap.h:5:42: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] drivers/net/wireless/microchip/wilc1000/mon.c:10:42: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] drivers/net/wireless/microchip/wilc1000/mon.c:15:42: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] drivers/net/wireless/virtual/mac80211_hwsim.c:758:42: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] drivers/net/wireless/virtual/mac80211_hwsim.c:767:42: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Link: https://patch.msgid.link/ZwBMtBZKcrzwU7l4@kspp Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 57be3d3562ca4aa62b8047bc681028cc402af8ce ]

-Wflex-array-member-not-at-end was introduced in GCC-14, and we are
getting ready to enable it, globally.

So, in order to avoid ending up with a flexible-array member in the
middle of multiple other structs, we use the `__struct_group()`
helper to create a new tagged `struct ieee80211_radiotap_header_fixed`.
This structure groups together all the members of the flexible
`struct ieee80211_radiotap_header` except the flexible array.

As a result, the array is effectively separated from the rest of the
members without modifying the memory layout of the flexible structure.
We then change the type of the middle struct members currently causing
trouble from `struct ieee80211_radiotap_header` to `struct
ieee80211_radiotap_header_fixed`.

We also want to ensure that in case new members need to be added to the
flexible structure, they are always included within the newly created
tagged struct. For this, we use `static_assert()`. This ensures that the
memory layout for both the flexible structure and the new tagged struct
is the same after any changes.

This approach avoids having to implement `struct ieee80211_radiotap_header_fixed`
as a completely separate structure, thus preventing having to maintain
two independent but basically identical structures, closing the door
to potential bugs in the future.

So, with these changes, fix the following warnings:
drivers/net/wireless/ath/wil6210/txrx.c:309:50: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
drivers/net/wireless/intel/ipw2x00/ipw2100.c:2521:50: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
drivers/net/wireless/intel/ipw2x00/ipw2200.h:1146:42: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
drivers/net/wireless/intel/ipw2x00/libipw.h:595:36: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
drivers/net/wireless/marvell/libertas/radiotap.h:34:42: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
drivers/net/wireless/marvell/libertas/radiotap.h:5:42: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
drivers/net/wireless/microchip/wilc1000/mon.c:10:42: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
drivers/net/wireless/microchip/wilc1000/mon.c:15:42: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
drivers/net/wireless/virtual/mac80211_hwsim.c:758:42: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
drivers/net/wireless/virtual/mac80211_hwsim.c:767:42: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]

Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Link: https://patch.msgid.link/ZwBMtBZKcrzwU7l4@kspp
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
wifi: wilc1000: Do not operate uninitialized hardware during suspend/resume 2024-10-10T10:03:15+00:00 Marek Vasut marex@denx.de 2024-08-21T18:36:03+00:00 e8a9219e91619d4da3a8a440dd92009963fc59a9 [ Upstream commit b0dc7018477e8fbb7e40c908c29cf663d06b17a7 ] In case the hardware is not initialized, do not operate it during suspend/resume cycle, the hardware is already off so there is no reason to access it. In fact, wilc_sdio_enable_interrupt() in the resume callback does interfere with the same call when initializing the hardware after resume and makes such initialization after resume fail. Fix this by not operating uninitialized hardware during suspend/resume. Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Alexis Lothoré <alexis.lothore@bootlin.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20240821183639.163187-1-marex@denx.de Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit b0dc7018477e8fbb7e40c908c29cf663d06b17a7 ]

In case the hardware is not initialized, do not operate it during
suspend/resume cycle, the hardware is already off so there is no
reason to access it.

In fact, wilc_sdio_enable_interrupt() in the resume callback does
interfere with the same call when initializing the hardware after
resume and makes such initialization after resume fail. Fix this
by not operating uninitialized hardware during suspend/resume.

Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/20240821183639.163187-1-marex@denx.de
Signed-off-by: Sasha Levin <sashal@kernel.org>
wifi: wilc1000: fix potential RCU dereference issue in wilc_parse_join_bss_param 2024-10-04T14:37:28+00:00 Jiawei Ye jiawei.ye@foxmail.com 2024-08-29T08:17:09+00:00 79510414a7626317f13cc9073244ab7a8deb3192 [ Upstream commit 6d7c6ae1efb1ff68bc01d79d94fdf0388f86cdd8 ] In the `wilc_parse_join_bss_param` function, the TSF field of the `ies` structure is accessed after the RCU read-side critical section is unlocked. According to RCU usage rules, this is illegal. Reusing this pointer can lead to unpredictable behavior, including accessing memory that has been updated or causing use-after-free issues. This possible bug was identified using a static analysis tool developed by myself, specifically designed to detect RCU-related issues. To address this, the TSF value is now stored in a local variable `ies_tsf` before the RCU lock is released. The `param->tsf_lo` field is then assigned using this local variable, ensuring that the TSF value is safely accessed. Fixes: 205c50306acf ("wifi: wilc1000: fix RCU usage in connect path") Signed-off-by: Jiawei Ye <jiawei.ye@foxmail.com> Reviewed-by: Alexis Lothoré <alexis.lothore@bootlin.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/tencent_466225AA599BA49627FB26F707EE17BC5407@qq.com Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 6d7c6ae1efb1ff68bc01d79d94fdf0388f86cdd8 ]

In the `wilc_parse_join_bss_param` function, the TSF field of the `ies`
structure is accessed after the RCU read-side critical section is
unlocked. According to RCU usage rules, this is illegal. Reusing this
pointer can lead to unpredictable behavior, including accessing memory
that has been updated or causing use-after-free issues.

This possible bug was identified using a static analysis tool developed
by myself, specifically designed to detect RCU-related issues.

To address this, the TSF value is now stored in a local variable
`ies_tsf` before the RCU lock is released. The `param->tsf_lo` field is
then assigned using this local variable, ensuring that the TSF value is
safely accessed.

Fixes: 205c50306acf ("wifi: wilc1000: fix RCU usage in connect path")
Signed-off-by: Jiawei Ye <jiawei.ye@foxmail.com>
Reviewed-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/tencent_466225AA599BA49627FB26F707EE17BC5407@qq.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net 2024-07-04T21:16:11+00:00 Jakub Kicinski kuba@kernel.org 2024-07-04T21:11:03+00:00 76ed626479ebe0227728eff16bb44544ebd98920 Cross-merge networking fixes after downstream PR. Conflicts: drivers/net/phy/aquantia/aquantia.h 219343755eae ("net: phy: aquantia: add missing include guards") 61578f679378 ("net: phy: aquantia: add support for PHY LEDs") drivers/net/ethernet/wangxun/libwx/wx_hw.c bd07a9817846 ("net: txgbe: remove separate irq request for MSI and INTx") b501d261a5b3 ("net: txgbe: add FDIR ATR support") https://lore.kernel.org/all/20240703112936.483c1975@canb.auug.org.au/ include/linux/mlx5/mlx5_ifc.h 048a403648fc ("net/mlx5: IFC updates for changing max EQs") 99be56171fa9 ("net/mlx5e: SHAMPO, Re-enable HW-GRO") https://lore.kernel.org/all/20240701133951.6926b2e3@canb.auug.org.au/ Adjacent changes: drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c 4130c67cd123 ("wifi: iwlwifi: mvm: check vif for NULL/ERR_PTR before dereference") 3f3126515fbe ("wifi: iwlwifi: mvm: add mvm-specific guard") include/net/mac80211.h 816c6bec09ed ("wifi: mac80211: fix BSS_CHANGED_UNSOL_BCAST_PROBE_RESP") 5a009b42e041 ("wifi: mac80211: track changes in AP's TPE") Signed-off-by: Jakub Kicinski <kuba@kernel.org> 
Cross-merge networking fixes after downstream PR.

Conflicts:

drivers/net/phy/aquantia/aquantia.h
  219343755eae ("net: phy: aquantia: add missing include guards")
  61578f679378 ("net: phy: aquantia: add support for PHY LEDs")

drivers/net/ethernet/wangxun/libwx/wx_hw.c
  bd07a9817846 ("net: txgbe: remove separate irq request for MSI and INTx")
  b501d261a5b3 ("net: txgbe: add FDIR ATR support")
https://lore.kernel.org/all/20240703112936.483c1975@canb.auug.org.au/

include/linux/mlx5/mlx5_ifc.h
  048a403648fc ("net/mlx5: IFC updates for changing max EQs")
  99be56171fa9 ("net/mlx5e: SHAMPO, Re-enable HW-GRO")
https://lore.kernel.org/all/20240701133951.6926b2e3@canb.auug.org.au/

Adjacent changes:

drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
  4130c67cd123 ("wifi: iwlwifi: mvm: check vif for NULL/ERR_PTR before dereference")
  3f3126515fbe ("wifi: iwlwifi: mvm: add mvm-specific guard")

include/net/mac80211.h
  816c6bec09ed ("wifi: mac80211: fix BSS_CHANGED_UNSOL_BCAST_PROBE_RESP")
  5a009b42e041 ("wifi: mac80211: track changes in AP's TPE")

Signed-off-by: Jakub Kicinski <kuba@kernel.org>
wifi: wilc1000: fix ies_len type in connect path 2024-07-03T13:49:53+00:00 Jozef Hopko jozef.hopko@altana.com 2024-07-01T16:23:20+00:00 39ab8fff623053a50951b659e5f6b72343d7d78c Commit 205c50306acf ("wifi: wilc1000: fix RCU usage in connect path") made sure that the IEs data was manipulated under the relevant RCU section. Unfortunately, while doing so, the commit brought a faulty implicit cast from int to u8 on the ies_len variable, making the parsing fail to be performed correctly if the IEs block is larger than 255 bytes. This failure can be observed with Access Points appending a lot of IEs TLVs in their beacon frames (reproduced with a Pixel phone acting as an Access Point, which brough 273 bytes of IE data in my testing environment). Fix IEs parsing by removing this undesired implicit cast. Fixes: 205c50306acf ("wifi: wilc1000: fix RCU usage in connect path") Signed-off-by: Jozef Hopko <jozef.hopko@altana.com> Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com> Acked-by: Ajay Singh <ajay.kathat@microchip.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20240701-wilc_fix_ies_data-v1-1-7486cbacf98a@bootlin.com 
Commit 205c50306acf ("wifi: wilc1000: fix RCU usage in connect path")
made sure that the IEs data was manipulated under the relevant RCU section.
Unfortunately, while doing so, the commit brought a faulty implicit cast
from int to u8 on the ies_len variable, making the parsing fail to be
performed correctly if the IEs block is larger than 255 bytes. This failure
can be observed with Access Points appending a lot of IEs TLVs in their
beacon frames (reproduced with a Pixel phone acting as an Access Point,
which brough 273 bytes of IE data in my testing environment).

Fix IEs parsing by removing this undesired implicit cast.

Fixes: 205c50306acf ("wifi: wilc1000: fix RCU usage in connect path")
Signed-off-by: Jozef Hopko <jozef.hopko@altana.com>
Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Acked-by: Ajay Singh <ajay.kathat@microchip.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/20240701-wilc_fix_ies_data-v1-1-7486cbacf98a@bootlin.com
wifi: wilc1000: disable SDIO func IRQ before suspend 2024-06-18T10:23:16+00:00 Alexis Lothoré alexis.lothore@bootlin.com 2024-06-13T14:06:45+00:00 5ad8897fd15a3716601509ed4a7bc47bf0cab661 Issuing a system suspend command raises the following warning: WARNING: CPU: 0 PID: 15 at drivers/mmc/core/sdio.c:1042 mmc_sdio_suspend+0xd4/0x19c CPU: 0 PID: 15 Comm: kworker/u2:1 Not tainted 6.7.0-rc1-wt+ #710 Hardware name: Atmel SAMA5 Workqueue: events_unbound async_run_entry_fn unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x34/0x48 dump_stack_lvl from __warn+0x98/0x160 __warn from warn_slowpath_fmt+0xcc/0x140 warn_slowpath_fmt from mmc_sdio_suspend+0xd4/0x19c mmc_sdio_suspend from mmc_bus_suspend+0x50/0x70 mmc_bus_suspend from dpm_run_callback+0xe4/0x248 dpm_run_callback from __device_suspend+0x234/0x91c __device_suspend from async_suspend+0x24/0x9c async_suspend from async_run_entry_fn+0x6c/0x210 async_run_entry_fn from process_one_work+0x3a0/0x870 [...] This warning is due to a check in SDIO core ensuring that interrupts do not remain enabled for cards being powered down during suspend. WILC driver currently does not set the MMC_PM_KEEP_POWER flag, so disable interrupt when entering resume. Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240613-wilc_suspend-v1-6-c2f766d0988c@bootlin.com 
Issuing a system suspend command raises the following warning:
WARNING: CPU: 0 PID: 15 at drivers/mmc/core/sdio.c:1042 mmc_sdio_suspend+0xd4/0x19c
CPU: 0 PID: 15 Comm: kworker/u2:1 Not tainted 6.7.0-rc1-wt+ #710
Hardware name: Atmel SAMA5
Workqueue: events_unbound async_run_entry_fn
 unwind_backtrace from show_stack+0x18/0x1c
 show_stack from dump_stack_lvl+0x34/0x48
 dump_stack_lvl from __warn+0x98/0x160
 __warn from warn_slowpath_fmt+0xcc/0x140
 warn_slowpath_fmt from mmc_sdio_suspend+0xd4/0x19c
 mmc_sdio_suspend from mmc_bus_suspend+0x50/0x70
 mmc_bus_suspend from dpm_run_callback+0xe4/0x248
 dpm_run_callback from __device_suspend+0x234/0x91c
 __device_suspend from async_suspend+0x24/0x9c
 async_suspend from async_run_entry_fn+0x6c/0x210
 async_run_entry_fn from process_one_work+0x3a0/0x870
[...]

This warning is due to a check in SDIO core ensuring that interrupts do not
remain enabled for cards being powered down during suspend. WILC driver
currently does not set the MMC_PM_KEEP_POWER flag, so disable interrupt
when entering resume.

Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240613-wilc_suspend-v1-6-c2f766d0988c@bootlin.com
wifi: wilc1000: remove suspend/resume from cfg80211 part 2024-06-18T10:23:16+00:00 Alexis Lothoré alexis.lothore@bootlin.com 2024-06-13T14:06:44+00:00 1e9e258d9fb5c46dbf78f1baf06ac3836a44f2fa WILC1000 suspend/resume implementation is currently composed of two parts: suspend/resume ops implemented in cfg80211 ops, which merely sets a flag, and suspend/resume ops in sdio/spi driver which, based on this flag, execute or not the suspend/resume mechanism. This dual set of ops is not really needed , so keep only the sdio part to implement suspend/resume. While doing so, remove the now unused suspend_event flag. Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240613-wilc_suspend-v1-5-c2f766d0988c@bootlin.com 
WILC1000 suspend/resume implementation is currently composed of two parts:
suspend/resume ops implemented in cfg80211 ops, which merely sets a
flag, and suspend/resume ops in sdio/spi driver which, based on this flag,
execute or not the suspend/resume mechanism. This dual set of ops is not
really needed , so keep only the sdio part to implement suspend/resume.

While doing so, remove the now unused suspend_event flag.

Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240613-wilc_suspend-v1-5-c2f766d0988c@bootlin.com
wifi: wilc1000: move sdio suspend method next to resume and pm ops definition 2024-06-18T10:23:16+00:00 Alexis Lothoré alexis.lothore@bootlin.com 2024-06-13T14:06:43+00:00 a814112e9545b873bcd82b2aafb6e88a82e6949f Just move the suspend method next to the resume method in the sdio part Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240613-wilc_suspend-v1-4-c2f766d0988c@bootlin.com 
Just move the suspend method next to the resume method in the sdio part

Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240613-wilc_suspend-v1-4-c2f766d0988c@bootlin.com
wifi: wilc1000: do not keep sdio bus claimed during suspend/resume 2024-06-18T10:23:15+00:00 Alexis Lothoré alexis.lothore@bootlin.com 2024-06-13T14:06:42+00:00 25d086ba196418a16b6328440226065aeefc6076 There is no reason to keep the MMC host claimed during suspend. Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240613-wilc_suspend-v1-3-c2f766d0988c@bootlin.com 
There is no reason to keep the MMC host claimed during suspend.

Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240613-wilc_suspend-v1-3-c2f766d0988c@bootlin.com