platform-drivers-x86-amd-wbrf-v6.8-1: v6.7-rc1 + AMD WBRF support
for merging into the wifi subsys and amdgpu driver for 6.8.
-----BEGIN PGP SIGNATURE-----
iQFIBAABCAAyFiEEuvA7XScYQRpenhd+kuxHeUQDJ9wFAmV26S0UHGhkZWdvZWRl
QHJlZGhhdC5jb20ACgkQkuxHeUQDJ9xhrggAndnZ23OehAMs+Tl5usEm/9RE6Al2
M9i/P3s2uzBUg4cRTAY0BLsNHIg9zvLv8unrJ0xoPQuoV/vI0864PMLQ1miVyvIa
V99/Cz/eCH0wZp9ADE1dL7EYI76aj5TXGgAxExTJ3EKVg5j/jWMkLLrsMZNT/23Z
YDPcDEPpaAGaKmJf0sJd+TRMn5hyJCVmkre9CEXJGDaogsX0BJGIhJ3nA2GzAwQ+
1oMxlkzMoECQ3U5ilzRtdREvmZtO1mjwUmwGMDZBKGwEvm0B8CrxDGmQjjMJcqTW
a85EeS/C3q+U7Pexq6/Wkixmv2pIuNzbQ1SV0P+qky8lPd6Rzp2fSmnnOg==
=UXod
-----END PGP SIGNATURE-----
Merge tag 'platform-drivers-x86-amd-wbrf-v6.8-1' into wireless-next
Merge the platform drivers tag for WRBF. Hans says:
Immutable branch between pdx86 amd wbrf branch and wifi / amdgpu due for the v6.8 merge window
platform-drivers-x86-amd-wbrf-v6.8-1: v6.7-rc1 + AMD WBRF support
for merging into the wifi subsys and amdgpu driver for 6.8.
Merge it so we can apply the wifi tie-in for this feature.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Due to electrical and mechanical constraints in certain platform designs
there may be likely interference of relatively high-powered harmonics of
the (G-)DDR memory clocks with local radio module frequency bands used
by Wifi 6/6e/7.
To mitigate this, AMD has introduced a mechanism that devices can use to
notify active use of particular frequencies so that other devices can make
relative internal adjustments as necessary to avoid this resonance.
Co-developed-by: Evan Quan <quanliangl@hotmail.com>
Signed-off-by: Evan Quan <quanliangl@hotmail.com>
Signed-off-by: Ma Jun <Jun.Ma2@amd.com>
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Add documentation about AMD's Wifi band RFI mitigation (WBRF) mechanism
explaining the theory and how it is used.
Signed-off-by: Ma Jun <Jun.Ma2@amd.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Don't enable firmware debug mode to prevent SER flow stuck due to fail
to reset payload buffer, and clear HALT_C2H_INT to avoid handling
unexpected interrupt at beginning.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20231204080751.15354-6-pkshih@realtek.com
To diagnose the reason why firmware or hardware get abnormal, add to dump
MAC registers related to counters and interrupt masks. With these values,
people can classify problems and check if registers values are unexpected,
and then correct them. However, it could possible false alarm because
firmware triggers this SER event by wrong conditions that we should
correct it at firmware or register settings.
In field, SER might happen under special conditions, and very hard to
happen again, so dump lots of registers to provide rich information to
catch the problem.
Signed-off-by: Chia-Yuan Li <leo.li@realtek.com>
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20231204080751.15354-5-pkshih@realtek.com
To activate SER (system error recovery) in firmware, we have to configure
IMR to trigger interrupts, and then SER can check registers to know if it
need to reset hardware or notify driver to re-configure whole settings.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20231204080751.15354-4-pkshih@realtek.com
Extend FW program counter dump for Wi-Fi 7 chip.
They poll different addresses.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20231204080751.15354-3-pkshih@realtek.com
RTL8922A FW supports CRASH_TRIGGER feature from v0.34.30.0.
After it, debugfs fw_crash can accept type 1 on RTL8922A to
trigger firmware crash and verify L2 recovery.
Besides, RTL8922A sync address offset of reserved payload engine.
And, SER (system error recovery) tweaks conversion from WCPU address
to indirect access address for RTL8922A. The new conversion works
for all supported chips.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20231204080751.15354-2-pkshih@realtek.com
This function has so many arguments already, before adding
yet another one, refactor it to take a struct instead.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
In concurrent mode, when STA interface is scanning, it causes
AP interface TX beacon on wrong channel. We modified it to scan
with the operating channel when one of the interfaces is already
connected. Additionally, STA interface need to stop scan when AP
interface is starting to avoid TX beacon on wrong channel. Finally,
AP interface need to stop TX beacon when STA interface is scanning
and switching to non-OP channel,This prevent other device to get
beacons on wrong channel.
Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20231129070046.18443-5-pkshih@realtek.com
We add a scanning check to avoid entering IPS after ROC (remain on
channel) during scanning. Additionally, When P2P scanning, the flow is
`1. p2p_listen step` and `2. configure filter` and `3. p2p_scan starts`
in wpas, but in kernel, cfg80211 uses another workqueue to notify driver
the filter change, so sometimes we see (1 > 3 > 2), that will cause Rx
filter related to scan to be cleared. Therefore, we add a scanning check
when configure filter to avoid scan results to be filtered. Finally, we
cancel the ROC delayed workqueue before entering ROC to avoid entering
twice, which might cause leaving ROC too early.
Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20231129070046.18443-4-pkshih@realtek.com
The interval between sending each probe request is regulated. Before
this patch, some packets are not sent out properly because of our HW
limit. Extend the 6 GHz channel dwell time to cope with this.
Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20231129070046.18443-3-pkshih@realtek.com
The attempt to enter power save mode might fail if there are still
beacons pending in the queue. This sometimes happens after stopping
P2P GO or AP mode. Extend stop AP function and flush all beacons to
resolve this.
Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20231129070046.18443-2-pkshih@realtek.com
We can run PCI/MMIO devices together with USB devices in the system.
Make watchdog parameter per device to avoid situation when plugin
USB device change modparam_watchdog for PCI/MMIO device.
Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
Tested-by: Shiji Yang <yangshiji66@outlook.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20231126195358.500259-1-stf_xl@wp.pl
The rtlwifi driver comes with a number of PCI related defines that are
unused and many would be provided by PCI core anyway if they'd be
needed again.
Similarly, the struct rtl_pci_capabilities_header is unused and no
driver should come up their own way to access PCI Capabilities anyway.
Remove the unused/duplicated PCI related defines and struct.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20231124084725.12738-10-ilpo.jarvinen@linux.intel.com
_rtl8821ae_clear_pci_pme_status() accesses the upper byte of the Power
Management Control/Status register (PMCS) with literal 5 offset.
Access the entire PMCS register using defines from pci_regs.h to
improve code readability.
While at it, remove the obvious comment and tweak debug prints
slightly to not sound misleading.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20231124084725.12738-9-ilpo.jarvinen@linux.intel.com
Instead of open coding the capability structure search, find the PM
Capability using pci_find_capability().
While at it, rename the generic 'cap_pointer' to 'pm_cap' which makes
the intent of the code more obvious.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20231124084725.12738-7-ilpo.jarvinen@linux.intel.com
BIT(7) (PME_Status) is first checked and then set unnecessarily. Remove
the unnecessary setting for the bit that is already on and adjust the
comment related to it.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20231124084725.12738-5-ilpo.jarvinen@linux.intel.com
The rtlwifi driver accesses PCIe capabilities through custom config
offsets. Convert the accesses to use the normal PCIe capability
accessors.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20231124084725.12738-4-ilpo.jarvinen@linux.intel.com
The rtlwifi driver comes with custom code to write into PCIe Link
Control register. RMW access for the Link Control register requires
locking that is already provided by the standard PCIe capability
accessors.
Convert the custom RMW code writing into LNKCTL register to standard
RMW capability accessors. The accesses are changed to cover the full
LNKCTL register instead of touching just a single byte of the register.
Fixes: 0c8173385e54 ("rtl8192ce: Add new driver")
Cc: stable@vger.kernel.org
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20231124084725.12738-3-ilpo.jarvinen@linux.intel.com
Ever since introduction in the commit 0c8173385e54 ("rtl8192ce: Add new
driver") the rtlwifi code has, according to comments, attempted to
disable/enable ASPM of the upstream bridge by writing into its LNKCTL
register. However, the code has never been correct because it performs
the writes to the device instead of the upstream bridge.
Worse yet, the offset where the PCIe capabilities reside is derived
from the offset of the upstream bridge. As a result, the write will use
an offset on the device that does not relate to the LNKCTL register
making the ASPM disable/enable code outright dangerous.
Because of those problems, there is no indication that the driver needs
disable/enable ASPM on the upstream bridge. As the Capabilities offset
is not correctly calculated for the write to target device's LNKCTL
register, the code is not disabling/enabling device's ASPM either.
Therefore, just remove the upstream bridge related ASPM disable/enable
code entirely.
The upstream bridge related ASPM code was the only user of the struct
mp_adapter members num4bytes, pcibridge_pciehdr_offset, and
pcibridge_linkctrlreg so those are removed as well.
Note: This change does not remove the code related to changing the
device's ASPM on purpose (which is independent of this flawed code
related to upstream bridge's ASPM).
Suggested-by: Bjorn Helgaas <bhelgaas@kernel.org>
Fixes: 0c8173385e54 ("rtl8192ce: Add new driver")
Fixes: 886e14b65a8f ("rtlwifi: Eliminate raw reads and writes from PCIe portion")
Cc: stable@vger.kernel.org
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20231124084725.12738-2-ilpo.jarvinen@linux.intel.com
Lukas reports skb_over_panic errors on his Banana Pi BPI-CM4 which comes
with an Amlogic A311D (G12B) SoC and a RTL8822CS SDIO wifi/Bluetooth
combo card. The error he observed is identical to what has been fixed
in commit e967229ead0e ("wifi: rtw88: sdio: Check the HISR RX_REQUEST
bit in rtw_sdio_rx_isr()") but that commit didn't fix Lukas' problem.
Lukas found that disabling or limiting RX aggregation works around the
problem for some time (but does not fully fix it). In the following
discussion a few key topics have been discussed which have an impact on
this problem:
- The Amlogic A311D (G12B) SoC has a hardware bug in the SDIO controller
which prevents DMA transfers. Instead all transfers need to go through
the controller SRAM which limits transfers to 1536 bytes
- rtw88 chips don't split incoming (RX) packets, so if a big packet is
received this is forwarded to the host in it's original form
- rtw88 chips can do RX aggregation, meaning more multiple incoming
packets can be pulled by the host from the card with one MMC/SDIO
transfer. This Depends on settings in the REG_RXDMA_AGG_PG_TH
register (BIT_RXDMA_AGG_PG_TH limits the number of packets that will
be aggregated, BIT_DMA_AGG_TO_V1 configures a timeout for aggregation
and BIT_EN_PRE_CALC makes the chip honor the limits more effectively)
Use multiple consecutive reads in rtw_sdio_read_port() and limit the
number of bytes which are copied by the host from the card in one
MMC/SDIO transfer. This allows receiving a buffer that's larger than
the hosts max_req_size (number of bytes which can be transferred in
one MMC/SDIO transfer). As a result of this the skb_over_panic error
is gone as the rtw88 driver is now able to receive more than 1536 bytes
from the card (either because the incoming packet is larger than that
or because multiple packets have been aggregated).
In case of an receive errors (-EILSEQ has been observed by Lukas) we
need to drain the remaining data from the card's buffer, otherwise the
card will return corrupt data for the next rtw_sdio_read_port() call.
Fixes: 65371a3f14e7 ("wifi: rtw88: sdio: Add HCI implementation for SDIO based chipsets")
Reported-by: Lukas F. Hartmann <lukas@mntre.com>
Closes: https://lore.kernel.org/linux-wireless/CAFBinCBaXtebixKbjkWKW_WXc5k=NdGNaGUjVE8NCPNxOhsb2g@mail.gmail.com/
Suggested-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Tested-by: Lukas F. Hartmann <lukas@mntre.com>
Reported-by: Lukas F. Hartmann <lukas@mntre.com>
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Tested-by: Lukas F. Hartmann <lukas@mntre.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20231120115726.1569323-1-martin.blumenstingl@googlemail.com
Add functions to configure HCI, DMAC (data MAC), DLE (data link engine),
HFC (HCI flow control), PLE (payload engine) and etc for WiFi 7 chips.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20231124071703.132549-9-pkshih@realtek.com
To share flow with WiFi 7 chips, abstract functions related hardware
engines and their quota, so use pointer to access them. This doesn't change
logic at all.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20231124071703.132549-8-pkshih@realtek.com
WiFi 7 chips will use the same functionalities but different registers to
control hardware components, so move these stuff into functions, and then
we can implement these for WiFi 7 chips later. This patch doesn't change
logic.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20231124071703.132549-7-pkshih@realtek.com
This function, currently called by WoWLAN flow, polls until specific HW
queues are empty. The polling bit definitions are not totally the same
between WiFi 6 and 7 chips. In addition, the check conditions are also
a little different. So, we differentiate the implementations according to
chip gen.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20231124071703.132549-6-pkshih@realtek.com
In queue empty check, one group contains 32 queues. And, the two elements,
wde_qempty_acq_num and wde_qempty_mgq_sel, are number of group and select
of group. To avoid confusing them with queue number and queue selection,
we refine their naming.
(don't change logic at all)
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20231124071703.132549-5-pkshih@realtek.com
DLE stands for Double Link Engine that is used to maintain buffer page.
To avoid linking to wrong pages, we check the used page size during
initialization and stop driver probe if the used size is unexpected.
Currently, we check the page size used by PLE (payload engine) and WDE
(WiFi descriptor engine). For coming WiFi 7 chips, additional reserved
size is added for BB as buffer to run LA mode, so add and check the
reserved size as well.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20231124071703.132549-4-pkshih@realtek.com
The reserved quota of DLE (data link engine) is used for processing next
packet. Add this to get quota number, and then WiFi 7 chips can use them.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20231124071703.132549-3-pkshih@realtek.com
Define 8922A buffer quota that are used by HCI control flow, payload
engine, descriptor engine and etc for operation modes, such as SCC (single
channel concurrence) and download firmware. Since WiFi 7 chips has more
buffer classifications, add fields and struct according to design.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20231124071703.132549-2-pkshih@realtek.com
A dynamic mechanism is usually an algorithm to adjust registers to adapt
to different environment every two seconds. In field, it could get
unexpected result, so we need to stop it and adjust registers manually, and
then fine tune the algorithm.
To stop mechanisms to assist debugging, add a debugfs entry shown as
Disabled DM: 0x1
[0] DYNAMIC_EDCCA: X
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20231122060458.30878-4-pkshih@realtek.com
Add dynamic mechanism EDCCA (Energy Detection Clear Channel Assessment)
in track work. Using a fixed-value threshold will make EDCCA particularly
sensitive and cause failure to transmit under certain circumstances.
Therefore, the threshold is dynamically adjusted to make EDCCA suitable
for any situation.
However, in some cases, we will adjust the EDCCA threshold to the highest
level so that urgent transmissions can be performed successfully, such as
scanning.
Finally, in order to observe the EDCCA report in time, add the EDCCA perIC
register macro and EDCCA HW report analysis. EDCCA logs can be displayed
by using the EDCCA debug mask.
Signed-off-by: Yi-Chen Chen <jamie_chen@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20231122060458.30878-3-pkshih@realtek.com
The coming dynamic mechanism of EDCCA adjustment will add a function to
dump registers to reflect status. However, if we are not debugging
the mechanism, we don't print anything, so avoid reading registers by
checking debug mask to reduce IO.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20231122060458.30878-2-pkshih@realtek.com
Clang static checker warns:
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c:184:49:
The result of the left shift is undefined due to shifting by '32',
which is greater or equal to the width of type 'u32'.
[core.UndefinedBinaryOperatorResult]
If the value of the right operand is negative or is greater than or
equal to the width of the promoted left operand, the behavior is
undefined.[1][2]
For example, when using different gcc's compilation optimization options
(-O0 or -O2), the result of '(u32)data << 32' is different. One is 0, the
other is old value of data. Let _rtl8821ae_phy_calculate_bit_shift()'s
return value less than 32 to fix this problem. Warn if bitmask is zero.
[1] https://stackoverflow.com/questions/11270492/what-does-the-c-standard-say-about-bitshifting-more-bits-than-the-width-of-type
[2] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf
Fixes: 21e4b0726dc6 ("rtlwifi: rtl8821ae: Move driver from staging to regular tree")
Signed-off-by: Su Hui <suhui@nfschina.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20231127013511.26694-2-suhui@nfschina.com
Clang static checker warns:
Value stored to 'v1' is never read [deadcode.DeadStores]
Value stored to 'channel' is never read [deadcode.DeadStores]
Remove them to save some place.
Signed-off-by: Su Hui <suhui@nfschina.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20231127013511.26694-1-suhui@nfschina.com
Commit 4b478bf6bdd8 ("wifi: libertas: drop 16-bit PCMCIA support") reworks
the dependencies for config LIBERTAS, and adds alternative dependencies for
USB, SDIO and SPI.
The config option SDIO however does not exist in the kernel tree. It was
probably intended to refer to the config option MMC, which represents
"MMC/SD/SDIO card support" and is used as dependency by various other
drivers that use SDIO.
Fix the dependency to the config option MMC for declaring the requirement
on provision of SDIO support.
Fixes: 4b478bf6bdd8 ("wifi: libertas: drop 16-bit PCMCIA support")
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20231122083047.12774-1-lukas.bulwahn@gmail.com
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20231117093056.873834-13-u.kleine-koenig@pengutronix.de
syzbot was able to trigger a crash [1] in page_pool_unlist()
page_pool_list() only inserts a page pool into a netdev page pool list
if a netdev was set in params.
Even if the kzalloc() call in page_pool_create happens to initialize
pool->user.list, I chose to be more explicit in page_pool_list()
adding one INIT_HLIST_NODE().
We could test in page_pool_unlist() if netdev was set,
but since netdev can be changed to lo, it seems more robust to
check if pool->user.list is hashed before calling hlist_del().
[1]
Illegal XDP return value 4294946546 on prog (id 2) dev N/A, expect packet loss!
general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
CPU: 0 PID: 5064 Comm: syz-executor391 Not tainted 6.7.0-rc2-syzkaller-00533-ga379972973a8 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023
RIP: 0010:__hlist_del include/linux/list.h:988 [inline]
RIP: 0010:hlist_del include/linux/list.h:1002 [inline]
RIP: 0010:page_pool_unlist+0xd1/0x170 net/core/page_pool_user.c:342
Code: df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 90 00 00 00 4c 8b a3 f0 06 00 00 48 b8 00 00 00 00 00 fc ff df 4c 89 e2 48 c1 ea 03 <80> 3c 02 00 75 68 48 85 ed 49 89 2c 24 74 24 e8 1b ca 07 f9 48 8d
RSP: 0018:ffffc900039ff768 EFLAGS: 00010246
RAX: dffffc0000000000 RBX: ffff88814ae02000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88814ae026f0
RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff1d57fdc
R10: ffffffff8eabfee3 R11: ffffffff8aa0008b R12: 0000000000000000
R13: ffff88814ae02000 R14: dffffc0000000000 R15: 0000000000000001
FS: 000055555717a380(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000002555398 CR3: 0000000025044000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
__page_pool_destroy net/core/page_pool.c:851 [inline]
page_pool_release+0x507/0x6b0 net/core/page_pool.c:891
page_pool_destroy+0x1ac/0x4c0 net/core/page_pool.c:956
xdp_test_run_teardown net/bpf/test_run.c:216 [inline]
bpf_test_run_xdp_live+0x1578/0x1af0 net/bpf/test_run.c:388
bpf_prog_test_run_xdp+0x827/0x1530 net/bpf/test_run.c:1254
bpf_prog_test_run kernel/bpf/syscall.c:4041 [inline]
__sys_bpf+0x11bf/0x4920 kernel/bpf/syscall.c:5402
__do_sys_bpf kernel/bpf/syscall.c:5488 [inline]
__se_sys_bpf kernel/bpf/syscall.c:5486 [inline]
__x64_sys_bpf+0x78/0xc0 kernel/bpf/syscall.c:5486
Fixes: 083772c9f972 ("net: page_pool: record pools per netdev")
Reported-and-tested-by: syzbot+f9f8efb58a4db2ca98d0@syzkaller.appspotmail.com
Signed-off-by: Eric Dumazet <edumazet@google.com>
Tested-by: Andrew Lunn <andrew@lunn.ch>
Link: https://lore.kernel.org/r/20231130092259.3797753-1-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Uwe Kleine-König says:
====================
net: ethernet: Convert to platform remove callback returning void
in (implicit) v1 of this series
(https://lore.kernel.org/netdev/20231117091655.872426-1-u.kleine-koenig@pengutronix.de)
I tried to address the resource leaks in the three cpsw drivers. However
this is hard to get right without being able to test the changes. So
here comes a series that just converts all drivers below
drivers/net/ethernet to use .remove_new() and adds a comment about the
potential leaks for someone else to fix the problem.
See commit 5c5a7680e67b ("platform: Provide a remove callback that
returns no value") for an extended explanation and the eventual goal.
The TL;DR; is to prevent bugs like the three noticed here.
Note this series results in no change of behaviour apart from improving
the error message for the three cpsw drivers from
remove callback returned a non-zero value. This will be ignored.
to
Failed to resume device (-ESOMETHING)
====================
Link: https://lore.kernel.org/r/20231128173823.867512-1-u.kleine-koenig@pengutronix.de
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Replace the error path returning a non-zero value by an error message
and a comment that there is more to do. With that this patch results in
no change of behaviour in this driver apart from improving the error
message.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Roger Quadros <rogerq@kernel.org>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
