summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2025-07-23wifi: brcmsmac: Use str_true_false() helperLiu Song1-9/+10
Remove hard-coded strings by using the str_true_false() helper function. Signed-off-by: Liu Song <liu.song13@zte.com.cn> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>> Link: https://patch.msgid.link/20250723173004776P6QSjcW7NrlpGYLTFM-yP@zte.com.cn Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-23wifi: brcmfmac: fix EXTSAE WPA3 connection failure due to AUTH TX failureTing-Ying Li2-21/+35
For WPA3-SAE Connection in EXTSAE mode, the userspace daemon is allowed to generate the SAE Auth frames. The driver uses the "mgmt_frame" FW IOVAR to transmit this MGMT frame. Before sending the IOVAR, the Driver is incorrectly treating the channel number read from the FW as a frequency value and again attempts to convert this into a channel number using ieee80211_frequency_to_channel(). This added an invalid channel number as part of the IOVAR request to the FW And some FW which strictly expects a valid channel would return BAD_CHAN error, while failing to transmit the driver requested SAE Auth MGMT frame. Fix this in the CYW vendor specific MGMT TX cfg80211 ops handler, by not treating the channel number read from the FW as frequency value and skip the attempt to convert it again into a channel number. Also fix this in the generic MGMT TX cfg80211 ops handler. Fixes: c2ff8cad6423 ("brcm80211: make mgmt_tx in brcmfmac accept a NULL channel") Fixes: 66f909308a7c ("wifi: brcmfmac: cyw: support external SAE authentication in station mode") Signed-off-by: Ting-Ying Li <tingying.li@cypress.com> Signed-off-by: Gokul Sivakumar <gokulkumar.sivakumar@infineon.com> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>> Link: https://patch.msgid.link/20250723105918.5229-1-gokulkumar.sivakumar@infineon.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-23wifi: brcm80211: Remove yet more unused functionsDr. David Alan Gilbert3-136/+0
This is a subset of unused functions in bcrmsmac phy_cmn.c, They're unused since the original 2010 commit a9533e7ea3c4 ("Staging: Add initial release of brcm80211 - Broadcom 802.11n wireless LAN driver.") Remove them. Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>> Link: https://patch.msgid.link/20250626140812.56700-4-linux@treblig.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-23wifi: brcm80211: Remove more unused functionsDr. David Alan Gilbert2-198/+0
This is a subset of unused functions in bcrmsmac phy_cmn.c, They're unused since the original 2010 commit a9533e7ea3c4 ("Staging: Add initial release of brcm80211 - Broadcom 802.11n wireless LAN driver.") Remove them. Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>> Link: https://patch.msgid.link/20250626140812.56700-3-linux@treblig.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-23wifi: brcm80211: Remove unused functionsDr. David Alan Gilbert4-166/+0
This is a subset of unused functions in bcrmsmac phy_cmn.c, They're unused since the original 2010 commit a9533e7ea3c4 ("Staging: Add initial release of brcm80211 - Broadcom 802.11n wireless LAN driver.") Remove them. Then remove two more functions in phy_n.c that were only used by the ones just removed. Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>> Link: https://patch.msgid.link/20250626140812.56700-2-linux@treblig.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-23spi: spi-qpic-snand: simplify bad block marker duplicationGabor Juhos1-4/+10
Due to the expectations of the SPINAND code, the driver duplicates the bad block markers during raw OOB reads. It has been implemented by using two if statements, and due to the opposite conditions one of conditional codepaths always runs. Since the effect of both codepaths is the same, remove the if statements and use a single line solution instead. Also add a note about why the duplication is required. No functional changes intended. Signed-off-by: Gabor Juhos <j4g8y7@gmail.com> Link: https://patch.msgid.link/20250711-qpic-snand-simplify-bbm-copy-v1-1-dd2608325f72@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-07-23spi: spi-qpic-snand: don't hardcode ECC stepsGabor Juhos1-1/+1
NAND devices with different page sizes requires different number of ECC steps, yet the qcom_spi_ecc_init_ctx_pipelined() function sets 4 steps in 'ecc_cfg' unconditionally. The correct number of the steps is calculated earlier in the function already, so use that instead of the hardcoded value. Fixes: 7304d1909080 ("spi: spi-qpic: add driver for QCOM SPI NAND flash Interface") Signed-off-by: Gabor Juhos <j4g8y7@gmail.com> Link: https://patch.msgid.link/20250723-qpic-snand-fix-steps-v1-1-d800695dde4c@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-07-23iommu/vt-d: Fix UAF on sva unbind with pending IOPFsLu Baolu1-1/+1
Commit 17fce9d2336d ("iommu/vt-d: Put iopf enablement in domain attach path") disables IOPF on device by removing the device from its IOMMU's IOPF queue when the last IOPF-capable domain is detached from the device. Unfortunately, it did this in a wrong place where there are still pending IOPFs. As a result, a use-after-free error is potentially triggered and eventually a kernel panic with a kernel trace similar to the following: refcount_t: underflow; use-after-free. WARNING: CPU: 3 PID: 313 at lib/refcount.c:28 refcount_warn_saturate+0xd8/0xe0 Workqueue: iopf_queue/dmar0-iopfq iommu_sva_handle_iopf Call Trace: <TASK> iopf_free_group+0xe/0x20 process_one_work+0x197/0x3d0 worker_thread+0x23a/0x350 ? rescuer_thread+0x4a0/0x4a0 kthread+0xf8/0x230 ? finish_task_switch.isra.0+0x81/0x260 ? kthreads_online_cpu+0x110/0x110 ? kthreads_online_cpu+0x110/0x110 ret_from_fork+0x13b/0x170 ? kthreads_online_cpu+0x110/0x110 ret_from_fork_asm+0x11/0x20 </TASK> ---[ end trace 0000000000000000 ]--- The intel_pasid_tear_down_entry() function is responsible for blocking hardware from generating new page faults and flushing all in-flight ones. Therefore, moving iopf_for_domain_remove() after this function should resolve this. Fixes: 17fce9d2336d ("iommu/vt-d: Put iopf enablement in domain attach path") Reported-by: Ethan Milon <ethan.milon@eviden.com> Closes: https://lore.kernel.org/r/e8b37f3e-8539-40d4-8993-43a1f3ffe5aa@eviden.com Suggested-by: Ethan Milon <ethan.milon@eviden.com> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Link: https://lore.kernel.org/r/20250723072045.1853328-1-baolu.lu@linux.intel.com Signed-off-by: Will Deacon <will@kernel.org>
2025-07-23pinctrl: mediatek: Add pinctrl driver for mt8189Cathy Xu4-0/+4165
Add pinctrl driver support for MediaTek Soc mt8189. Signed-off-by: Cathy Xu <ot_cathy.xu@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/20250711094513.17073-4-ot_cathy.xu@mediatek.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2025-07-23pinctrl: aspeed-g6: Add PCIe RC PERST pin groupJacky Chou1-1/+11
The PCIe RC PERST uses SSPRST# as PERST# and enable this pin to output. Signed-off-by: Jacky Chou <jacky_chou@aspeedtech.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/20250715034320.2553837-8-jacky_chou@aspeedtech.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2025-07-23xen/netfront: Fix TX response spurious interruptsAnthoine Bourgeois1-5/+0
We found at Vates that there are lot of spurious interrupts when benchmarking the xen-net PV driver frontend. This issue appeared with a patch that addresses security issue XSA-391 (b27d47950e48 "xen/netfront: harden netfront against event channel storms"). On an iperf benchmark, spurious interrupts can represent up to 50% of the interrupts. Spurious interrupts are interrupts that are rised for nothing, there is no work to do. This appends because the function that handles the interrupts ("xennet_tx_buf_gc") is also called at the end of the request path to garbage collect the responses received during the transmission load. The request path is doing the work that the interrupt handler should have done otherwise. This is particurary true when there is more than one vcpu and get worse linearly with the number of vcpu/queue. Moreover, this problem is amplifyed by the penalty imposed by a spurious interrupt. When an interrupt is found spurious the interrupt chip will delay the EOI to slowdown the backend. This delay will allow more responses to be handled by the request path and then there will be more chance the next interrupt will not find any work to do, creating a new spurious interrupt. This causes performance issue. The solution here is to remove the calls from the request path and let the interrupt handler do the processing of the responses. This approch removes most of the spurious interrupts (<0.05%) and also has the benefit of freeing up cycles in the request path, allowing it to process more work, which improves performance compared to masking the spurious interrupt one way or another. This optimization changes a part of the code that is present since the net frontend driver was upstreamed. There is no similar pattern in the other xen PV drivers. Since the first commit of xen-netfront is a blob that doesn't explain all the design choices I can only guess why this specific mecanism was here. This could have been introduce to compensate a slow backend at the time (maybe the backend was fixed or optimize later) or a small queue. In 18 years, both frontend and backend gain lot of features and optimizations that could have obsolete the feature of reaping completions from the TX path. Some vif throughput performance figures from a 8 vCPUs, 4GB of RAM HVM guest(s): Without this patch on the : vm -> dom0: 4.5Gb/s vm -> vm: 7.0Gb/s Without XSA-391 patch (revert of b27d47950e48): vm -> dom0: 8.3Gb/s vm -> vm: 8.7Gb/s With XSA-391 and this patch: vm -> dom0: 11.5Gb/s vm -> vm: 12.6Gb/s v2: - add revewed and tested by tags - resend with the maintainers in the recipients list v3: - remove Fixes tag but keep the commit ref in the explanation - add a paragraph on why this code was here Signed-off-by: Anthoine Bourgeois <anthoine.bourgeois@vates.tech> Reviewed-by: Juergen Gross <jgross@suse.com> Tested-by: Elliott Mitchell <ehem+xen@m5p.com> Signed-off-by: Juergen Gross <jgross@suse.com> Message-ID: <20250721093316.23560-1-anthoine.bourgeois@vates.tech>
2025-07-23wifi: iwlwifi: Revert "wifi: iwlwifi: remove support of several ↵Miri Korenblit2-10/+30
iwl_ppag_table_cmd versions" It turns out that version 6 is still needed. This change will be brought back once the FW that supports version 6 will no longer be supported. This reverts commit 24bc49d158c7 ("wifi: iwlwifi: remove support of several iwl_ppag_table_cmd versions") Link: https://patch.msgid.link/20250723064515.2084903-2-miriam.rachel.korenblit@intel.com Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2025-07-23wifi: iwlwifi: check validity of the FW API rangeMiri Korenblit1-0/+28
We assume that iwl_mac_cfg and iwl_rf_cfg instances has either both ucode_api_min and ucode_api_max set, or neither. Validate this assumption with a Kunit test. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250723094230.66502f3f4345.I661f347d3bb29994d8b2ec1d3f31f3383422d68a@changeid
2025-07-23wifi: iwlwifi: don't export symbols that we shouldn'tMiri Korenblit2-22/+0
Functions that are not called from the opmodes shouldn't be exported. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250723094230.97b80d0d00b3.Ib8abe63c9b25ef1e4ae1bc167cb23fe34bb3682a@changeid
2025-07-23wifi: iwlwifi: mld: use spec link id and not FW link idMiri Korenblit1-3/+5
In missed beacon handling, we compare the FW link id to the bss_param_ch_cnt_link_id, which is a spec link id. Fix it. Reviewed-by: Somashekhar Puttagangaiah <somashekhar.puttagangaiah@intel.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250723094230.2104f8cac836.I25ed77c2b87bde82a9153e2aa26e09b8a42f6ee3@changeid
2025-07-23wifi: iwlwifi: mld: decode EOF bit for AMPDUsBenjamin Berg1-0/+9
Only the EOF bit handling for single frames was ported to the MLD driver. The code to handle AMPDUs correctly was forgotten. Add it back so that the bit is reported in the radiotap headers again. Fixes: d1e879ec600f ("wifi: iwlwifi: add iwlmld sub-driver") Signed-off-by: Benjamin Berg <benjamin.berg@intel.com> Reviewed-by: Daniel Gabay <daniel.gabay@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250723094230.195be86372d5.I4db4abf348f7b6dfc75f869770dd77655a204bc7@changeid
2025-07-23wifi: iwlwifi: Remove support for rx OMI bandwidth reductionMiri Korenblit9-496/+4
This feature turns out to have an issue: it can take up to 8 seconds to detect high throughput scenarios and to leave RX OMI bandwidth reduction. This leads to throughput degradation. Until the issues are fixed, remove the RX OMI implementation. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250723094230.a9ccfe210516.Ic87bc7709a6761f593e88f1488a41442c68c1686@changeid
2025-07-23wifi: iwlwifi: stop supporting iwl_omi_send_status_notif ver 1Miri Korenblit3-36/+14
This version doesn't provide the sta id, so we need to look it up - assuming that no other sta exists, since one of the conditions of entering OMI is not having P2P/TDLS. But when we leave OMI, because of the P2P/TDLS activation, the P2P/TDLS sta can already exist while we receive the notification from the FW. This causes an error log which is incorrect. Since OMI is only supported in SC, which is not shipped yet, no one will use a FW with the old version. Remove support for it. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250723094230.b716b9cebaa7.I2a1cc4be441dbbb5566a9a3d2d330d956ff3ed38@changeid
2025-07-23wifi: iwlwifi: remove SC2F firmware supportMiri Korenblit2-7/+2
The only difference between SC2 and SC2F is that they use a different FSEQ image. The firmware of SC2 implements the logic of selecting the right FSEQ image to load, so there is no need for SC2F firmware image. Stop loading it, and load SC2 image instead. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250723094230.bf0ec63e49a9.Iffa0a982f90a179566d85c60ccd3dbfc50e293ef@changeid
2025-07-23wifi: iwlwifi: mvm: Remove NAN supportIlan Peer5-18/+1
NAN is not officially supported on any of the MVM devices so there is no need to maintain it. Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250723094230.b327adbf35c0.I0357e383ab5df72d8b87e0dee10609a6946865b6@changeid
2025-07-23wifi: iwlwifi: mld: avoid outdated reorder buffer head_snAvraham Stern1-0/+5
If no frames are received on a queue for a while, the reorder buffer head_sn may be an old one. When the next frame that is received on that queue and buffered is a subframe of an AMSDU but not the last subframe, it will not update the buffer's head_sn. When the frame release notification arrives, it will not release the buffered frame because it will look like the notification's NSSN is lower than the buffer's head_sn (because of a wraparound). Fix it by updating the head_sn when the first frame is buffered. Signed-off-by: Avraham Stern <avraham.stern@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250723094230.e1f62a9a603c.I7b57a481122074b1f40d39cd31db2e5262668eb2@changeid
2025-07-23wifi: iwlwifi: mvm: avoid outdated reorder buffer head_snAvraham Stern1-0/+5
If no frames are received on a queue for a while, the reorder buffer head_sn may be an old one. When the next frame that is received on that queue and buffered is a subframe of an AMSDU but not the last subframe, it will not update the buffer's head_sn. When the frame release notification arrives, it will not release the buffered frame because it will look like the notification's NSSN is lower than the buffer's head_sn (because of a wraparound). Fix it by updating the head_sn when the first frame is buffered. Signed-off-by: Avraham Stern <avraham.stern@intel.com> Reviewed-by: Daniel Gabay <daniel.gabay@intel.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250723094230.795ec0cb8817.I9ec9a3508e7935e8d1833ea3e086066fdefee644@changeid
2025-07-23wifi: iwlwifi: disable certain features for fips_enabledJohannes Berg3-9/+43
When fips_enabled is set, keys will not be given to the hardware by mac80211 since the hardware isn't certified. In this case, various features cannot work correctly as the firmware needs to handle frames, but it then cannot since no keys are available. Disable features: - WoWLAN since no keys etc. - MFP since some frames need to be handled in firmware - EHT/6GHz since MFP is required Also restrict A-MSDU size since A-MSDUs cannot be split up by hardware and thus need to fit into the RX buffers in one piece. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250723094230.329fade58a27.I0be27dd329643cc5fdf79a8c8b8f6d2e6fb5c175@changeid
2025-07-23wifi: iwlwifi: mld: support channel survey collection for ACS scansBenjamin Berg6-1/+210
The firmware is able to collect channel statistics when doing passive scans. Enable the flag when doing a passive scan on an AP interface and collect the survey information. Signed-off-by: Benjamin Berg <benjamin.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250723094230.a659ef1b1fd8.I24a9a0383327c231f36be170968bc7bac801f9f2@changeid
2025-07-23wifi: iwlwifi: mld: disable RX aggregation if requestedMiri Korenblit1-0/+4
The user can request to disable RX aggregations via the module parameter enable_11n. Honor this request and reject addba. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250723094230.40746586ade7.Ibf5877df76ea2f1eee614166b3194843fd9898cd@changeid
2025-07-23wifi: rt2x00: soc: modernize probeRosen Penev1-105/+82
Remove a bunch of static memory management functions and simplify with devm. Also move allocation before ieee80211_alloc_hw to get rid of goto statements and clarify the error handling a bit more. Signed-off-by: Rosen Penev <rosenp@gmail.com> Acked-by: Stanislaw Gruszka <stf_xl@wp.pl> Reviewed-by: Sergio Paracuellos <sergio.paracuellos@gmail.com> Link: https://patch.msgid.link/20250722212856.11343-6-rosenp@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-23wifi: rt2800: move 2x00soc to 2800socRosen Penev5-187/+118
This driver was written with multiple SOC platforms in mind. However since Ralink was aquired by Mediatek, it only effectively got used by older platforms. As such, we can slim down the driver slightly by moving all of rt2x00soc to rt2800soc in order to benefit from inlining. Signed-off-by: Rosen Penev <rosenp@gmail.com> Acked-by: Stanislaw Gruszka <stf_xl@wp.pl> Reviewed-by: Sergio Paracuellos <sergio.paracuellos@gmail.com> Link: https://patch.msgid.link/20250722212856.11343-5-rosenp@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-23wifi: rt2800soc: allow loading from OFRosen Penev2-1/+8
Add a single binding to help the already present dts files load the driver. More are possible but there doesn't seem to be a significant difference between them to justify this. Use wifi name per dtschema requirements. Added OF dependency to SOC CONFIG as adding of_match_table without OF being present makes no sense. Signed-off-by: Rosen Penev <rosenp@gmail.com> Reviewed-by: Sergio Paracuellos <sergio.paracuellos@gmail.com> Acked-by: Stanislaw Gruszka <stf_xl@wp.pl> Link: https://patch.msgid.link/20250722212856.11343-4-rosenp@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-23wifi: rt2x00: remove mod_name from platform_driverRosen Penev1-1/+0
mod_name is a legacy debugging feature with no real modern use. An analysis of the underlying MIPS setup code reveals it to also be unused. Signed-off-by: Rosen Penev <rosenp@gmail.com> Reviewed-by: Sergio Paracuellos <sergio.paracuellos@gmail.com> Acked-by: Stanislaw Gruszka <stf_xl@wp.pl> Link: https://patch.msgid.link/20250722212856.11343-3-rosenp@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-23wifi: rt2x00: add COMPILE_TESTRosen Penev1-1/+1
While this driver is for a specific arch, there is nothing preventing it from being compiled on other platforms. Allows the various bots to test compilation and complain if a patch is bad. Signed-off-by: Rosen Penev <rosenp@gmail.com> Acked-by: Stanislaw Gruszka <stf_xl@wp.pl> Reviewed-by: Sergio Paracuellos <sergio.paracuellos@gmail.com> Link: https://patch.msgid.link/20250722212856.11343-2-rosenp@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-23wifi: brcmfmac: cyw: Fix __counted_by to be LE variantKees Cook1-1/+1
In brcmf_cyw_mgmt_tx() the "len" counter of the struct brcmf_mf_params_le::data flexible array is stored as little-endian via cpu_to_le16() so the __counted_by_le() variant must be used: struct brcmf_mf_params_le *mf_params; ... mf_params_len = offsetof(struct brcmf_mf_params_le, data) + (len - DOT11_MGMT_HDR_LEN); mf_params = kzalloc(mf_params_len, GFP_KERNEL); ... mf_params->len = cpu_to_le16(len - DOT11_MGMT_HDR_LEN); Fixes: 66f909308a7c ("wifi: brcmfmac: cyw: support external SAE authentication in station mode") Signed-off-by: Kees Cook <kees@kernel.org> Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>> Link: https://patch.msgid.link/20250721181810.work.575-kees@kernel.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-23pmdomain: qcom: rpmhpd: Add Glymur RPMh Power DomainsKamal Wadhwa1-0/+26
Add RPMh Power Domains support for the Glymur platform. Signed-off-by: Kamal Wadhwa <kamal.wadhwa@oss.qualcomm.com> Signed-off-by: Pankaj Patil <pankaj.patil@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Abel Vesa <abel.vesa@linaro.org> Link: https://lore.kernel.org/r/20250716152758.4079467-3-pankaj.patil@oss.qualcomm.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2025-07-23Input: sysrq: mv sysrq into drivers/tty/sysrq.cJoel Granados1-0/+41
Move both sysrq ctl_table and supported sysrq_sysctl_handler helper function into drivers/tty/sysrq.c. Replaced the __do_proc_dointvec in helper function with do_proc_dointvec_minmax as the former is local to kernel/sysctl.c. Here we use the minmax version of do_proc_dointvec because do_proc_dointvec is static and calling do_proc_dointvec_minmax with a NULL min and max is the same as calling do_proc_dointvec. This is part of a greater effort to move ctl tables into their respective subsystems which will reduce the merge conflicts in kernel/sysctl.c. Reviewed-by: Kees Cook <kees@kernel.org> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Joel Granados <joel.granados@kernel.org>
2025-07-23parisc/power: Move soft-power into power.cJoel Granados1-1/+19
Move the soft-power ctl table into parisc/power.c. As a consequence the pwrsw_enabled var is made static. This is part of a greater effort to move ctl tables into their respective subsystems which will reduce the merge conflicts in kernel/sysctl.c. Reviewed-by: Luis Chamberlain <mcgrof@kernel.org> Reviewed-by: Kees Cook <kees@kernel.org> Signed-off-by: Joel Granados <joel.granados@kernel.org>
2025-07-23gpio: cadence: Remove duplicated include in gpio-cadence.cYang Li1-1/+0
The header files linux/gpio/driver.h is included twice in gpio-cadence.c, so one inclusion of each can be removed. Reported-by: Abaci Robot <abaci@linux.alibaba.com> Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=22931 Signed-off-by: Yang Li <yang.lee@linux.alibaba.com> Link: https://lore.kernel.org/r/20250723064608.2178024-1-yang.lee@linux.alibaba.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-07-23RDMA/mana_ib: add support of multiple portsKonstantin Taranov3-57/+71
If the HW indicates support of multiple ports for rdma, create an IB device with a port per netdev in the ethernet mana driver. CM is only available on port 1, but RC QPs are supported on all ports. Signed-off-by: Konstantin Taranov <kotaranov@microsoft.com> Link: https://patch.msgid.link/1753174515-23634-1-git-send-email-kotaranov@linux.microsoft.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2025-07-23gpio: tps65219: Add support for TI TPS65214 PMICShree Ramamoorthy1-6/+86
Add support for the TI TPS65214 PMIC with the addition of an id_table, separate TPS65214 template_chip, and device-specific _change_direction functions. - Use platform_get_device_id() to assign dev-specific information. - Use different change_direction() functions since TPS65214's GPIO configuration bits are changeable during device operation through bit GPIO_CONFIG in GENERAL_CONFIG register. - Remove MODULE_ALIAS since it is now generated by MODULE_DEVICE_TABLE. Reviewed-by: Jonathan Cormier <jcormier@criticallink.com> Tested-by: Jonathan Cormier <jcormier@criticallink.com> Signed-off-by: Shree Ramamoorthy <s-ramamoorthy@ti.com> Link: https://lore.kernel.org/r/20250722181609.1541739-3-s-ramamoorthy@ti.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-07-23gpio: tps65219: Update _IDX & _OFFSET macro prefixShree Ramamoorthy1-10/+17
TPS65215 and TPS65219 are overlapping PMIC devices. While their regulator features differe, the GPIO features are the same. In the TPS65219 MFD driver, the 2 PMICs share the same "tps65219-gpio" compatible string to limit support for TPS65215 in this GPIO driver to comments. The TPS6521X_GPIO0_IDX and TPS6521X_GPIO0_OFFSET macro name prefixes are updated to indicate these macros apply to both PMICs. Reviewed-by: Roger Quadros <rogerq@kernel.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Jonathan Cormier <jcormier@criticallink.com> Signed-off-by: Shree Ramamoorthy <s-ramamoorthy@ti.com> Link: https://lore.kernel.org/r/20250722181609.1541739-2-s-ramamoorthy@ti.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-07-23RDMA/mlx5: Refactor optional counters steering codePatrisious Haddad4-62/+67
Currently there isn't a clear layer separation between the counters and the steering code, whereas the steering code is doing redundant access to the counter struct. Separate the fs.c and counters.c, where fs code won't access or be aware of counter structs but only the objects it needs. As a result, move mlx5_rdma_counter struct from the header file to be an internal struct for the counters file only. Signed-off-by: Patrisious Haddad <phaddad@nvidia.com> Reviewed-by: Edward Srouji <edwards@nvidia.com> Link: https://patch.msgid.link/9854d1fdb140e4a6552b7a2fd1a028cfe488a935.1753004208.git.leon@kernel.org Signed-off-by: Leon Romanovsky <leon@kernel.org>
2025-07-23RDMA/mlx5: Add DMAH support for reg_user_mr/reg_user_dmabuf_mrYishai Hadas4-20/+94
As part of this enhancement, allow the creation of an MKEY associated with a DMA handle. Additional notes: MKEYs with TPH (i.e. TLP Processing Hints) attributes are currently not UMR-capable unless explicitly enabled by firmware or hardware. Therefore, to maintain such MKEYs in the MR cache, the TPH fields have been added to the rb_key structure, with a dedicated hash bucket. The ability to bypass the kernel verbs flow and create an MKEY with TPH attributes using DEVX has been restricted. TPH must follow the standard InfiniBand flow, where a DMAH is created with the appropriate security checks and management mechanisms in place. DMA handles are currently not supported in conjunction with On-Demand Paging (ODP). Re-registration of memory regions originally created with TPH attributes is currently not supported. Signed-off-by: Yishai Hadas <yishaih@nvidia.com> Reviewed-by: Edward Srouji <edwards@nvidia.com> Link: https://patch.msgid.link/1c485651cf8417694ddebb80446c5093d5a791a9.1752752567.git.leon@kernel.org Signed-off-by: Leon Romanovsky <leon@kernel.org>
2025-07-23IB: Extend UVERBS_METHOD_REG_MR to get DMAHYishai Hadas34-20/+150
Extend UVERBS_METHOD_REG_MR to get DMAH and pass it to all drivers. It will be used in mlx5 driver as part of the next patch from the series. Signed-off-by: Yishai Hadas <yishaih@nvidia.com> Reviewed-by: Edward Srouji <edwards@nvidia.com> Link: https://patch.msgid.link/2ae1e628c0675db81f092cc00d3ad6fbf6139405.1752752567.git.leon@kernel.org Signed-off-by: Leon Romanovsky <leon@kernel.org>
2025-07-23RDMA/mlx5: Add DMAH object supportYishai Hadas4-0/+83
This patch introduces support for allocating and deallocating the DMAH object. Further details: ---------------- The DMAH API is exposed to upper layers only if the underlying device supports TPH. It uses the mlx5_core steering tag (ST) APIs to get a steering tag index based on the provided input. The obtained index is stored in the device-specific mlx5_dmah structure for future use. Upcoming patches in the series will integrate the allocated DMAH into the memory region (MR) registration process. Signed-off-by: Yishai Hadas <yishaih@nvidia.com> Reviewed-by: Edward Srouji <edwards@nvidia.com> Link: https://patch.msgid.link/778550776799d82edb4d05da249a1cff00160b50.1752752567.git.leon@kernel.org Signed-off-by: Leon Romanovsky <leon@kernel.org>
2025-07-23RDMA/core: Introduce a DMAH object and its alloc/free APIsYishai Hadas6-0/+153
Introduce a new DMA handle (DMAH) object along with its corresponding allocation and deallocation APIs. This DMAH object encapsulates attributes intended for use in DMA transactions. While its initial purpose is to support TPH functionality, it is designed to be extensible for future features such as DMA PCI multipath, PCI UIO configurations, PCI traffic class selection, and more. Further details: ---------------- We ensure that a caller requesting a DMA handle for a specific CPU ID is permitted to be scheduled on it. This prevent a potential security issue where a non privilege user may trigger DMA operations toward a CPU that it's not allowed to run on. We manage reference counting for the DMAH object and its consumers (e.g., memory regions) as will be detailed in subsequent patches in the series. Signed-off-by: Yishai Hadas <yishaih@nvidia.com> Reviewed-by: Edward Srouji <edwards@nvidia.com> Link: https://patch.msgid.link/2cad097e849597e49d6b61e6865dba878257f371.1752752567.git.leon@kernel.org Signed-off-by: Leon Romanovsky <leon@kernel.org>
2025-07-23IB/core: Add UVERBS_METHOD_REG_MR on the MR objectYishai Hadas1-1/+152
This new method enables us to use a single ioctl from user space which supports the below variants of reg_mr [1]. The method will be extended in the next patches from the series with an extra attribute to let us pass DMA handle to be used as part of the registration. [1] ibv_reg_mr(), ibv_reg_mr_iova(), ibv_reg_mr_iova2(), ibv_reg_dmabuf_mr(). Signed-off-by: Yishai Hadas <yishaih@nvidia.com> Reviewed-by: Edward Srouji <edwards@nvidia.com> Link: https://patch.msgid.link/5a3822ceef084efe967c9752e89c58d8250337c7.1752752567.git.leon@kernel.org Signed-off-by: Leon Romanovsky <leon@kernel.org>
2025-07-23RDMA support for DMA handleLeon Romanovsky6-10/+194
From Yishai: This patch series introduces a new DMA Handle (DMAH) object, along with corresponding APIs for its allocation and deallocation. The DMAH object encapsulates attributes relevant for DMA transactions. While initially intended to support TLP Processing Hints (TPH) [1], the design is extensible to accommodate future features such as PCI multipath for DMA, PCI UIO configurations, traffic class selection, and more. Additionally, we introduce a new ioctl method on the MR object: UVERBS_METHOD_REG_MR. This method consolidates multiple reg_mr variants under a single user-space ioctl interface, supporting: ibv_reg_mr(), ibv_reg_mr_iova(), ibv_reg_mr_iova2() and ibv_reg_dmabuf_mr(). It also enables passing a DMA handle as part of the registration process. Throughout the patch series, the following DMAH-related stuff can also be observed in the IB layer: - Association with a CPU ID and its memory type, for use with Steering Tags [2]. - Inclusion of Processing Hints (PH) data for TPH functionality [3]. - Enforces security by ensuring that only tasks allowed to run on a given CPU may request a DMA handle for it. - Reference counting for DMAH life cycle management and safe usage across memory regions. mlx5 driver implementation: -------------------------- The series includes implementation of the above functionality in the mlx5 driver. In mlx5_core: - Enables TPH over PCIe when both firmware and OS support it. - Manages Steering Tags and corresponding indices by writing tag values to the PCI configuration space. - Exposes APIs to upper layers (e.g., mlx5_ib) to enable the PCIe TPH functionality. In mlx5_ib: - Adds full support for DMAH operations. - Utilizes mlx5_core's Steering Tag APIs to derive tag indices from input. - Stores the resulting index in a mlx5_dmah structure for use during MKEY creation with a DMA handle. - Adds support for allowing MKEYs to be created in conjunction with DMA handles. Additional details are provided in the commit messages. [1] Background, from PCIe specification 6.2. TLP Processing Hints (TPH) -------------------------- TLP Processing Hints is an optional feature that provides hints in Request TLP headers to facilitate optimized processing of Requests that target Memory Space. These Processing Hints enable the system hardware (e.g., the Root Complex and/ or Endpoints) to optimize platform resources such as system and memory interconnect on a per TLP basis. Steering Tags are system-specific values used to identify a processing resource that a Requester explicitly targets. System software discovers and identifies TPH capabilities to determine the Steering Tag allocation for each Function that supports TPH [2] Steering Tags Functions that intend to target a TLP towards a specific processing resource such as a host processor or system cache hierarchy require topological information of the target cache (e.g., which host cache). Steering Tags are system-specific values that provide information about the host or cache structure in the system cache hierarchy. These values are used to associate processing elements within the platform with the processing of Requests. [3] Processing Hints The Requester provides hints to the Root Complex or other targets about the intended use of data and data structures by the host and/or device. The hints are provided by the Requester, which has knowledge of upcoming Request patterns, and which the Completer would not be able to deduce autonomously (with good accuracy) Yishai Signed-off-by: Leon Romanovsky <leon@kernel.org> * mlx5-next: net/mlx5: Add support for device steering tag net/mlx5: Expose IFC bits for TPH PCI/TPH: Expose pcie_tph_get_st_table_size() net/mlx5: Expose cable_length field in PFCC register net/mlx5: Add IFC bits and enums for buf_ownership net/mlx5: Add IFC bits to support RSS for IPSec offload net/mlx5: IFC updates for disabled host PF net/mlx5: Expose disciplined_fr_counter through HCA capabilities in mlx5_ifc
2025-07-23net/mlx5: Add support for device steering tagYishai Hadas4-0/+180
Background, from PCIe specification 6.2. TLP Processing Hints (TPH) -------------------------- TLP Processing Hints is an optional feature that provides hints in Request TLP headers to facilitate optimized processing of Requests that target Memory Space. These Processing Hints enable the system hardware (e.g., the Root Complex and/or Endpoints) to optimize platform resources such as system and memory interconnect on a per TLP basis. Steering Tags are system-specific values used to identify a processing resource that a Requester explicitly targets. System software discovers and identifies TPH capabilities to determine the Steering Tag allocation for each Function that supports TPH. This patch adds steering tag support for mlx5 based NICs by: - Enabling the TPH functionality over PCI if both FW and OS support it. - Managing steering tags and their matching steering indexes by writing a ST to an ST index over the PCI configuration space. - Exposing APIs to upper layers (e.g.,mlx5_ib) to allow usage of the PCI TPH infrastructure. Further details: - Upon probing of a device, the feature will be enabled based on both capability detection and OS support. - It will retrieve the appropriate ST for a given CPU ID and memory type using the pcie_tph_get_cpu_st() API. - It will track available ST indices according to the configuration space table size (expected to be 63 entries), reserving index 0 to indicate non-TPH use. - It will assign a free ST index with a ST using the pcie_tph_set_st_entry() API. - It will reuse the same index for identical (CPU ID + memory type) combinations by maintaining a reference count per entry. - It will expose APIs to upper layers (e.g., mlx5_ib) to allow usage of the PCI TPH infrastructure. - SF will use its parent PF stuff. Signed-off-by: Yishai Hadas <yishaih@nvidia.com> Link: https://patch.msgid.link/de1ae7398e9e34eacd8c10845683df44fc9e32f8.1752752567.git.leon@kernel.org Signed-off-by: Leon Romanovsky <leon@kernel.org>
2025-07-23PCI/TPH: Expose pcie_tph_get_st_table_size()Yishai Hadas1-5/+6
Expose pcie_tph_get_st_table_size() to be used by drivers as will be done in the next patch from the series. Signed-off-by: Yishai Hadas <yishaih@nvidia.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/9ae851e0ee42cc56d2a30276e116b65091030ceb.1752752567.git.leon@kernel.org Signed-off-by: Leon Romanovsky <leon@kernel.org>
2025-07-23platform/chrome: cros_ec_typec: Check ec platform device pointerTomasz Michalec1-1/+1
It is possible that parent device for cros_ec_typec device is already available, but ec pointer in parent driver data isn't populated yet. It may happen when cros_typec_probe is running in parallel with cros_ec_register. This leads to NULL pointer dereference when cros_typec_probe tries to get driver data from typec->ec->ec->dev. Check if typec->ec->ec is set before using it in cros_typec_probe. Signed-off-by: Tomasz Michalec <tmichalec@google.com> Link: https://lore.kernel.org/r/20250722132826.707087-1-tmichalec@google.com Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
2025-07-23platform/chrome: cros_ec: Unregister notifier in cros_ec_unregister()Tzung-Bi Shih1-0/+3
The blocking notifier is registered in cros_ec_register(); however, it isn't unregistered in cros_ec_unregister(). Fix it. Fixes: 42cd0ab476e2 ("platform/chrome: cros_ec: Query EC protocol version if EC transitions between RO/RW") Cc: stable@vger.kernel.org Reviewed-by: Benson Leung <bleung@chromium.org> Link: https://lore.kernel.org/r/20250722120513.234031-1-tzungbi@kernel.org Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
2025-07-23Merge tag 'linux-can-fixes-for-6.16-20250722' of ↵Jakub Kicinski2-3/+21
git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can Marc Kleine-Budde says: ==================== pull-request: can 2025-07-22 The patch is by me and fixes a potential NULL pointer deref in the CAN device driver infrastructure. It can be triggered from user space. * tag 'linux-can-fixes-for-6.16-20250722' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can: can: netlink: can_changelink(): fix NULL pointer deref of struct can_priv::do_set_mode ==================== Link: https://patch.msgid.link/20250722110059.3664104-1-mkl@pengutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2025-08-21 02:00:54 +0300