summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-10-23regulator: dt-bindings: Add ADI MAX77503 supportGokhan Celik
Add ADI MAX77503 buck converter devicetree document. Signed-off-by: Gokhan Celik <gokhan.celik@analog.com> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/fb2cb32219eb1a5f85169d6c85cd2c057c5bb4a9.1698000185.git.gokhan.celik@analog.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-10-23regulator: max77503: Add ADI MAX77503 supportGokhan Celik
Add ADI MAX77503 buck converter driver support. Signed-off-by: Gokhan Celik <gokhan.celik@analog.com> Link: https://lore.kernel.org/r/10bb3894fea31a098d768e346c8721e730d7cb21.1698000185.git.gokhan.celik@analog.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-10-23ASoC: SOF: amd: add option to use sram for data bin loadingVijendar Mukunda
Provide an option to load DSP data bin to ACP SRAM. Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com> Link: https://lore.kernel.org/r/20231020062822.3913760-5-Vijendar.Mukunda@amd.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-10-23ASoC: SOF: amd: refactor acp dram usage for data bin loadingVijendar Mukunda
DSP data bin can be loaded in to ACP DRAM or ACP SRAM. Add conditional check for ACP DRAM usage for data bin loading. Rename DRAM base address macro to have symmetry. Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com> Link: https://lore.kernel.org/r/20231020062822.3913760-4-Vijendar.Mukunda@amd.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-10-23ASoC: SOF: amd: increase DSP cache window rangeVijendar Mukunda
Increase DSP cache window range to 2.5MB to align with ACP memory. Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com> Link: https://lore.kernel.org/r/20231020062822.3913760-3-Vijendar.Mukunda@amd.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-10-23ASoC: SOF: amd: add support for acp6.3 based platformVijendar Mukunda
Add SOF support for ACP6.3 version based platform Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com> Link: https://lore.kernel.org/r/20231020062822.3913760-2-Vijendar.Mukunda@amd.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-10-23ASoC: amd: Add acpi machine id for acp6.3 version based platformVijendar Mukunda
Add acpi machine id for ACP6.3 version based platform and configure driver data to enable SOF sound card support on newer boards. Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com> Link: https://lore.kernel.org/r/20231020062822.3913760-1-Vijendar.Mukunda@amd.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-10-23ASoC: es8328: Use rounded rate for es8328_set_sysclk()Chris Morgan
I have a board (RK3588 based) that sets the sysclk to 12287999. The es8328 driver fails to match this to the 12288000 rate and fails to load. Allow the rate comparison to work if the frequency is within 100hz by dividing it by 100 and rounding it, then multiplying it back by 100. Note the 100hz value was chosen arbitrarily by me, but it has only been tested with a 1hz difference. Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Link: https://lore.kernel.org/r/20231020171539.65513-1-macroalpha82@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-10-23ASoC: codecs: Modify max_register usage errorWeidong Wang
Modify the value of max_register, otherwirse the AW88261_EFRL1_REG register will not be accessible. Signed-off-by: Weidong Wang <wangweidong.a@awinic.com> Link: https://lore.kernel.org/r/20231020083426.302925-3-wangweidong.a@awinic.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-10-23ASoC: uniphier: Make uniphier_aio_remove() return voidUwe Kleine-König
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 (mostly) ignored 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. uniphier_aio_remove() returned zero unconditionally. Make it return void instead and convert all users to struct platform_device::remove_new(). Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20231013221945.1489203-16-u.kleine-koenig@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org>
2023-10-23ASoC: qcom: lpass: Make asoc_qcom_lpass_cpu_platform_remove() return voidUwe Kleine-König
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 (mostly) ignored 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. asoc_qcom_lpass_cpu_platform_remove() returned zero unconditionally. Make it return void instead and convert all users to struct platform_device::remove_new(). Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20231013221945.1489203-15-u.kleine-koenig@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org>
2023-10-23ASoC: meson: Make meson_card_remove() return voidUwe Kleine-König
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 (mostly) ignored 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. meson_card_remove() returned zero unconditionally. Make it return void instead and convert all users to struct platform_device::remove_new(). Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Jerome Brunet <jbrunet@baylibre.com> Link: https://lore.kernel.org/r/20231013221945.1489203-14-u.kleine-koenig@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org>
2023-10-23ASoC: simple-card-utils: Make simple_util_remove() return voidUwe Kleine-König
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 (mostly) ignored 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. simple_util_remove() returned zero unconditionally. Make it return void instead and convert all users to struct platform_device::remove_new(). Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Herve Codina <herve.codina@bootlin.com> Link: https://lore.kernel.org/r/20231013221945.1489203-13-u.kleine-koenig@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org>
2023-10-23ASoC: starfive/jh7110-pwmdac: Convert to platform remove callback returning voidUwe Kleine-König
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> Link: https://lore.kernel.org/r/20231013221945.1489203-12-u.kleine-koenig@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org>
2023-10-23ASoC: cs42l43: Convert to platform remove callback returning voidUwe Kleine-König
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> Link: https://lore.kernel.org/r/20231013221945.1489203-11-u.kleine-koenig@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org>
2023-10-23ASoC: rockchip: i2s_tdm: Convert to platform remove callback returning voidUwe Kleine-König
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 (mostly) ignored 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. 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> Link: https://lore.kernel.org/r/20231013221945.1489203-10-u.kleine-koenig@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org>
2023-10-23ASoC: SOF: sof-pci-dev: Fix community key quirk detectionMark Hasemeyer
Some Chromebooks do not populate the product family DMI value resulting in firmware load failures. Add another quirk detection entry that looks for "Google" in the BIOS version. Theoretically, PRODUCT_FAMILY could be replaced with BIOS_VERSION, but it is left as a quirk to be conservative. Cc: stable@vger.kernel.org Signed-off-by: Mark Hasemeyer <markhas@chromium.org> Acked-by: Curtis Malainey <cujomalainey@chromium.org> Link: https://lore.kernel.org/r/20231020145953.v1.1.Iaf5702dc3f8af0fd2f81a22ba2da1a5e15b3604c@changeid Signed-off-by: Mark Brown <broonie@kernel.org>
2023-10-23ASoC: fsl: Fix PM disable depth imbalance in fsl_easrc_probeZhang Shurong
The pm_runtime_enable will increase power disable depth. Thus a pairing decrement is needed on the error handling path to keep it balanced according to context. We fix it by calling pm_runtime_disable when error returns. Fixes: 955ac624058f ("ASoC: fsl_easrc: Add EASRC ASoC CPU DAI drivers") Signed-off-by: Zhang Shurong <zhang_shurong@foxmail.com> Link: https://lore.kernel.org/r/tencent_C0D62E6D89818179A02A04A0C248F0DDC40A@qq.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-10-23powerpc/mm: Fix boot crash with FLATMEMMichael Ellerman
Erhard reported that his G5 was crashing with v6.6-rc kernels: mpic: Setting up HT PICs workarounds for U3/U4 BUG: Unable to handle kernel data access at 0xfeffbb62ffec65fe Faulting instruction address: 0xc00000000005dc40 Oops: Kernel access of bad area, sig: 11 [#1] BE PAGE_SIZE=4K MMU=Hash SMP NR_CPUS=2 PowerMac Modules linked in: CPU: 0 PID: 0 Comm: swapper/0 Tainted: G T 6.6.0-rc3-PMacGS #1 Hardware name: PowerMac11,2 PPC970MP 0x440101 PowerMac NIP: c00000000005dc40 LR: c000000000066660 CTR: c000000000007730 REGS: c0000000022bf510 TRAP: 0380 Tainted: G T (6.6.0-rc3-PMacGS) MSR: 9000000000001032 <SF,HV,ME,IR,DR,RI> CR: 44004242 XER: 00000000 IRQMASK: 3 GPR00: 0000000000000000 c0000000022bf7b0 c0000000010c0b00 00000000000001ac GPR04: 0000000003c80000 0000000000000300 c0000000f20001ae 0000000000000300 GPR08: 0000000000000006 feffbb62ffec65ff 0000000000000001 0000000000000000 GPR12: 9000000000001032 c000000002362000 c000000000f76b80 000000000349ecd8 GPR16: 0000000002367ba8 0000000002367f08 0000000000000006 0000000000000000 GPR20: 00000000000001ac c000000000f6f920 c0000000022cd985 000000000000000c GPR24: 0000000000000300 00000003b0a3691d c0003e008030000e 0000000000000000 GPR28: c00000000000000c c0000000f20001ee feffbb62ffec65fe 00000000000001ac NIP hash_page_do_lazy_icache+0x50/0x100 LR __hash_page_4K+0x420/0x590 Call Trace: hash_page_mm+0x364/0x6f0 do_hash_fault+0x114/0x2b0 data_access_common_virt+0x198/0x1f0 --- interrupt: 300 at mpic_init+0x4bc/0x10c4 NIP: c000000002020a5c LR: c000000002020a04 CTR: 0000000000000000 REGS: c0000000022bf9f0 TRAP: 0300 Tainted: G T (6.6.0-rc3-PMacGS) MSR: 9000000000001032 <SF,HV,ME,IR,DR,RI> CR: 24004248 XER: 00000000 DAR: c0003e008030000e DSISR: 40000000 IRQMASK: 1 ... NIP mpic_init+0x4bc/0x10c4 LR mpic_init+0x464/0x10c4 --- interrupt: 300 pmac_setup_one_mpic+0x258/0x2dc pmac_pic_init+0x28c/0x3d8 init_IRQ+0x90/0x140 start_kernel+0x57c/0x78c start_here_common+0x1c/0x20 A bisect pointed to the breakage beginning with commit 9fee28baa601 ("powerpc: implement the new page table range API"). Analysis of the oops pointed to a struct page with a corrupted compound_head being loaded via page_folio() -> _compound_head() in hash_page_do_lazy_icache(). The access by the mpic code is to an MMIO address, so the expectation is that the struct page for that address would be initialised by init_unavailable_range(), as pointed out by Aneesh. Instrumentation showed that was not the case, which eventually lead to the realisation that pfn_valid() was returning false for that address, causing the struct page to not be initialised. Because the system is using FLATMEM, the version of pfn_valid() in memory_model.h is used: static inline int pfn_valid(unsigned long pfn) { ... return pfn >= pfn_offset && (pfn - pfn_offset) < max_mapnr; } Which relies on max_mapnr being initialised. Early in boot max_mapnr is zero meaning no PFNs are valid. max_mapnr is initialised in mem_init() called via: start_kernel() mm_core_init() # init/main.c:928 mem_init() But that is too late for the usage in init_unavailable_range() called via: start_kernel() setup_arch() # init/main.c:893 paging_init() free_area_init() init_unavailable_range() Although max_mapnr is currently set in mem_init(), the value is actually already available much earlier, as soon as mem_topology_setup() has completed, which is also before paging_init() is called. So move the initialisation there, which causes paging_init() to correctly initialise the struct page and fixes the bug. This bug seems to have been lurking for years, but went unnoticed because the pre-folio code was inspecting the uninitialised page->flags but not dereferencing it. Thanks to Erhard and Aneesh for help debugging. Reported-by: Erhard Furtner <erhard_f@mailbox.org> Closes: https://lore.kernel.org/all/20230929132750.3cd98452@yea/ Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20231023112500.1550208-1-mpe@ellerman.id.au
2023-10-23wifi: mac80211: don't drop all unprotected public action framesAvraham Stern
Not all public action frames have a protected variant. When MFP is enabled drop only public action frames that have a dual protected variant. Fixes: 76a3059cf124 ("wifi: mac80211: drop some unprotected action frames") Signed-off-by: Avraham Stern <avraham.stern@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20231016145213.2973e3c8d3bb.I6198b8d3b04cf4a97b06660d346caec3032f232a@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-10-23wifi: cfg80211: fix assoc response warning on failed linksJohannes Berg
The warning here shouldn't be done before we even set the bss field (or should've used the input data). Move the assignment before the warning to fix it. We noticed this now because of Wen's bugfix, where the bug fixed there had previously hidden this other bug. Fixes: 53ad07e9823b ("wifi: cfg80211: support reporting failed links") Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-10-23wifi: cfg80211: pass correct pointer to rdev_inform_bss()Ben Greear
Confusing struct member names here resulted in passing the wrong pointer, causing crashes. Pass the correct one. Fixes: eb142608e2c4 ("wifi: cfg80211: use a struct for inform_single_bss data") Signed-off-by: Ben Greear <greearb@candelatech.com> Link: https://lore.kernel.org/r/20231021154827.1142734-1-greearb@candelatech.com [rewrite commit message, add fixes] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-10-23MAINTAINERS: mmc: take over as maintainer of MCI & SDHCI MICROCHIP DRIVERSAubin Constans
On the one hand Eugen has taken responsibilities outside Microchip, on the other hand I have some experience with the Microchip SDMMC SDHCI controller. Change Eugen as reviewer and take over maintainership of the SDHCI MICROCHIP DRIVER. Also, take over maintainership of its predecessor, that is the MCI MICROCHIP DRIVER. Signed-off-by: Aubin Constans <aubin.constans@microchip.com> Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com> Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com> Acked-by: Eugen Hristev <eugen.hristev@collabora.com> Link: https://lore.kernel.org/r/20230911153246.137148-1-aubin.constans@microchip.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2023-10-23wifi: mac80211: drop robust action frames before assocJohannes Berg
To be able to more easily understand the code, drop robust action frames before being associated, even if there's no MFP in the end, as they are Class 3 Frames and shouldn't be transmitted in the first place. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20231001125722.b2fd37083371.Ie9f4906e2f6c698989bce6681956ed2f9454f27c@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-10-23wifi: cfg80211: Allow AP/P2PGO to indicate port authorization to peer ↵Vinayak Yadawad
STA/P2PClient In 4way handshake offload, cfg80211_port_authorized enables driver to indicate successful 4way handshake to cfg80211 layer. Currently this path of port authorization is restricted to interface type NL80211_IFTYPE_STATION and NL80211_IFTYPE_P2P_CLIENT. This patch extends the support for NL80211_IFTYPE_AP and NL80211_IFTYPE_P2P_GO interfaces to authorize peer STA/P2P_CLIENT, whenever authentication is offloaded on the AP/P2P_GO interface. Signed-off-by: Vinayak Yadawad <vinayak.yadawad@broadcom.com> Link: https://lore.kernel.org/r/dee3b0a2b4f617e932c90bff4504a89389273632.1695721435.git.vinayak.yadawad@broadcom.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-10-23wifi: iwlwifi: drop NULL pointer check in iwl_mvm_tzone_set_trip_temp()Dmitry Antipov
Since 'tz_device' is an in-place member of 'struct iwl_mvm', it can't be NULL and so relevant check may be dropped. Compile tested only. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Acked-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20231003092048.24998-1-dmantipov@yandex.ru Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-10-23wifi: iwlwifi: bump FW API to 86 for AX/BZ/SC devicesGregory Greenman
Start supporting API version 86 for new devices. Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20231022173519.e2f720799600.I6e22188a47efe0cbb4e013259955c4019843799f@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-10-23wifi: iwlwifi: read DSM func 2 for specific RF typesDaniel Gabay
By definition, this DSM func is valid only for HR/JF RF types. Until now firmware ignored this bit (if set) on other than the above types, but in future firmware versions sending this bit will lead to firmware 0x3426 assert. Avoid that by verifying the HW in driver first. Signed-off-by: Daniel Gabay <daniel.gabay@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20231022173519.eec3b5d6152f.Ibc7ffe5ef1c156d878f1300c6059c6c91b374114@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-10-23wifi: iwlwifi: mvm: show dump even for pldr_syncJohannes Berg
Worst case it's extra (garbage) data, best case we see why things failed ... Seems the trade-off is better if we print it. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20231022173519.30e614ecd540.I47324f555ebcf22d0dd0afa94e7ca0af53a9fdba@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-10-23wifi: iwlwifi: mvm: cycle FW link on chanctx removalJohannes Berg
When the vif is in MLD mode, we'll get a vif links change from non-zero to zero on disassociation, which removes all links in the firmware and adds the 'deflink' the driver/mac80211 has. This causes the firmware to clear some internal state. However, in non-MLD mode, this doesn't happen, and causes some state to be left around in firmware, which can particularly cause trouble with the ref-BSSID in multi-BSSID, leading to an assert later if immediately making a new multi-BSSID connection with a different ref-BSSID. Fix this by removing/re-adding the link in the non-MLD case when the channel is removed from the vif. This way, all of the state will get cleared out, even if we need the deflink, which is more for software architecture purposes than otherwise. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20231022173519.90c82837ba4d.I341fa30c480f7673b14b48a0e29a2241472c2e13@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-10-23wifi: iwlwifi: trace full frames with TX status requestJohannes Berg
If upper layers requested a TX status, then the frames are more important, so trace frames in that case. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20231022173519.0dfb60a2eaec.I3c3e46ed0eb05700a4d05d293f80d727354a402f@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-10-23wifi: iwlwifi: empty overflow queue during flushMiri Korenblit
If a TX queue has no space for new TX frames, the driver will keep these frames in the overflow queue, and during reclaim flow it will retry to send the frames from that queue. But if the reclaim flow was invoked from TX queue flush, we will also TX these frames, which is wrong as we don't want to TX anything after flush. This might also cause assert 0x125F when removing the queue, saying that the driver removes a non-empty queue Fix this by TXing the overflow queue's frames only if we are not in flush queue flow. Fixes: a44509805895 ("iwlwifi: move reclaim flows to the queue file") Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20231022173519.caf06c8709d9.Ibf664ccb3f952e836f8fa461ea58fc08e5c46e88@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-10-23wifi: iwlwifi: fw: Add support for UATS table in UHBMukesh Sisodiya
Driver need to provide details of VLP, AFC AP type supported for the specific MCC to firmware. Driver will read the UATS (UHB AP type support) table from BIOS and sent to firmware using UATS_TABLE_CMD. Add the support for the same in the driver. Signed-off-by: Mukesh Sisodiya <mukesh.sisodiya@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20231022173519.eb6cf7be17b2.I8977a660564412056d9fd383d57b236cd4b22d00@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-10-23wifi: iwlwifi: mvm: add a print when sending RLC commandMiri Korenblit
Expand RLC logging to simplify the debug. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20231022173519.ec227229263f.Iea36e64d4092e04ad561beb87002c7bb8c52596f@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-10-23wifi: iwlwifi: mvm: debugfs for fw system statsAnjaneyulu
Add debgufs handler for fw system statistics command. Signed-off-by: Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20231022173519.e77efee7cd85.I99f370f26f94f73e06aec2a8eaf21ebcc82f60a9@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-10-23wifi: iwlwifi: mvm: implement new firmware API for statisticsAnjaneyulu
The new firmware API uses a new command and notification, the command configures in which statistics types driver is interested and the notification is sent periodically. An additional change in the API is that most of the statistics data is accumulated and reported by the firmware per MLO link. Implement new command and notification handlers and adjust to per-link statistics. Signed-off-by: Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20231022173519.8cc7df0ebff2.If1dcb57145841c5b3c68ed112bbfcd0201f7acc3@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-10-23wifi: iwlwifi: mvm: fix regdb initializationGregory Greenman
In order to get regulatory domain, driver sends MCC_UPDATE_CMD to the FW. One of the parameters in the response is the status which can tell if the regdomain has changed or not. When iwl_mvm_init_mcc() is called during iwl_op_mode_mvm_start(), then sband is still NULL and channel parameters (i.e. chan->flags) cannot be initialized. When, further in the flow, iwl_mvm_update_mcc() is called during iwl_mvm_up(), it first checks if the regdomain has changed and then skips the update if it remains the same. But, since channel parameters weren't initialized yet, the update should be forced in this codepath. Fix that by adding a corresponding parameter to iwl_mvm_init_fw_regd(). Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20231017115047.78b2c5b891b0.Iac49d52e0bfc0317372015607c63ea9276bbb188@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-10-23wifi: iwlwifi: mvm: update IGTK in mvmvif upon D3 resumeYedidya Benshimol
During the D3 resume flow, all new rekeys are passed from the FW. Because the FW supports only one IGTK at a time, every IGTK rekey update should be done by removing the last IGTK. The mvmvif holds a pointer to the last IGTK for that reason and thus should be updated when a new IGTK is passed upon resume. Fixes: 04f78e242fff ("wifi: iwlwifi: mvm: Add support for IGTK in D3 resume flow") Signed-off-by: Yedidya Benshimol <yedidya.ben.shimol@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20231017115047.8ceaf7e5ece7.Ief444f6a2703ed76648b4d414f12bb4130bab36e@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-10-23wifi: iwlwifi: mvm: simplify the reorder bufferEmmanuel Grumbach
The firmware / hardware of devices supporting RSS is able to report duplicates and packets that time out inside the reoder buffer. We can now remove all the complex logic that was implemented to keep all the Rx queues more the less synchronized: we used to send a message to all the queues through the firmware to teach the different queues about what is the current SSN every 2048 packets. Now that we rely on the firmware / hardware to detect duplicates, we can completely remove the code that did that in the driver and it has been reported that this code was spuriously dropping legit packets. Suggested-by: Sultan Alsawaf <sultan@kerneltoast.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20231017115047.54cf4d3d5956.Ic06a08c9fb1e1ec315a4b49d632b78b8474dab79@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-10-23wifi: iwlwifi: disable multi rx queue for 9000Emmanuel Grumbach
Multi rx queue allows to spread the load of the Rx streams on different CPUs. 9000 series required complex synchronization mechanisms from the driver side since the hardware / firmware is not able to provide information about duplicate packets and timeouts inside the reordering buffer. Users have complained that for newer devices, all those synchronization mechanisms have caused spurious packet drops. Those packet drops disappeared if we simplify the code, but unfortunately, we can't have RSS enabled on 9000 series without this complex code. Remove support for RSS on 9000 so that we can make the code much simpler for newer devices and fix the bugs for them. The down side of this patch is a that all the Rx path will be routed to a single CPU, but this has never been an issue, the modern CPUs are just fast enough to cope with all the traffic. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20231017115047.2917eb8b7af9.Iddd7dcf335387ba46fcbbb6067ef4ff9cd3755a7@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-10-23wifi: iwlwifi: mvm: Return success if link could not be removedBenjamin Berg
iwl_mvm_remove_link would return an error if the link could not be removed. However, doing so prevents recovery if a link was not uploaded to the FW in the first place and the link_info was not allocated or fw_link_id is not set. Returning success means that we can still try to continue with adding new links in change_vif_links. Signed-off-by: Benjamin Berg <benjamin.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20231017115047.f89bc05aadf6.Idc8fbd671362d962c02b1df87fa6258733631580@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-10-23wifi: iwlwifi: mvm: fix size check for fw_link_idGregory Greenman
Check that fw_link_id does not exceed the size of link_id_to_link_conf array. There's no any codepath that can cause that, but it's still safer to verify in case fw_link_id gets corrupted. Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20231017115047.3385bd11f423.I2d30fdb464f951c648217553c47901857a0046c7@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-10-23wifi: iwlwifi: pcie: synchronize IRQs before NAPIJohannes Berg
When we want to synchronize the NAPI, which was added in commit 5af2bb3168db ("wifi: iwlwifi: call napi_synchronize() before freeing rx/tx queues"), we also need to make sure we can't actually reschedule the NAPI. Yes, this happens while interrupts are disabled, but interrupts may still be running or pending. Also call iwl_pcie_synchronize_irqs() to ensure we won't reschedule the NAPI. Fixes: 4cf2f5904d97 ("iwlwifi: queue: avoid memory leak in reset flow") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20231017115047.a0f4104b479a.Id5c50a944f709092aa6256e32d8c63b2b8d8d3ac@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-10-23wifi: iwlwifi: add support for SNPS DPHYIP region typeDaniel Gabay
Add the required logic for parsing and dumping this new region. Signed-off-by: Daniel Gabay <daniel.gabay@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20231017115047.c859539194e7.I965482de2871e28b09f4572f1aa87ae4e3b366be@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-10-23wifi: iwlwifi: mvm: fix netif csum flagsJohannes Berg
We shouldn't advertise arbitrary checksum flags since we had to remove support for it due to broken hardware. Fixes: ec18e7d4d20d ("wifi: iwlwifi: mvm: use old checksum for Bz A-step") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20231017115047.e37327f1a129.Iaee86b00db4db791cd90adaf15384b8c87d2ad49@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-10-23wifi: iwlwifi: mvm: remove set_tim callback for MLD opsJohannes Berg
In new firmware, we don't need this any more and it won't be called any more by mac80211, since powersave handling is all done by firmware. Remove it from the MLD ops. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20231017115047.1a1ded96ffc2.Ie49d3004acdd6299fb84346c76b2b2b2f195196b@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-10-23wifi: iwlwifi: api: fix center_freq label in PHY diagramJohannes Berg
Somehow I managed to put the EHT line in the wrong place and also didn't indent the center_freq label correctly. Fix it. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20231017115047.08ac3cf524c0.I538f424e1ab30f73b0af8381224f377893e15526@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-10-23wifi: iwlwifi: support link id in SESSION_PROTECTION_NOTIFMiri Korenblit
FW is introducing an API change in which link ID will be used for session protection notif. Add support for it. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20231017115047.4c59b149086e.I74fe93a6337f4ec9d1bd6f791d315411ac5b40da@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-10-23wifi: iwlwifi: support link_id in SESSION_PROTECTION cmdMiri Korenblit
FW is introducing an API change in which link ID will be used for session protection cmd. Add support for it. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20231017115047.a3cb29ed0617.I85b8a85b0d9186d3dd4d704254e46775b0ccf7de@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-10-23wifi: iwlwifi: make time_events MLO awareMiri Korenblit
As session protection API is moving to be per link instead of per mac, move the time events to be per link too. Since there is only one concurrent time event per mac, it feels unnecessary to have the time_event as a member of iwl_mvm_link_info. (That way we will have to iterate over all links each time we want to clear a time event, and also we will need mac80211 to tell us the link id when mgd_tx_complete() is called.) So leave this as a member of iwl_mvm_vif, but add the link id to the time_event structure. The link id in time_event will only be maintained and used for: 1. When SESSION_PROTECTION_CMD is supported (before it, we don't have MLO) 2. For time_events of types SESSION_PROTECT_CONF_ASSOC, SESSION_PROTECT_CONF_P2P_DEVICE_DISCOV, and SESSION_PROTECT_CONF_P2P_GO_NEGOTIATION (not for aux roc/ Hot Spot time_events). For P2P, non-MLO connections, and pre-MLD API, deflink id, meaning 0, will be used Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20231017115047.21496bcacb18.I79d037325b4fae4c12a22d9477e53fc9c537ad46@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>