summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2025-07-11cxl/core: Using cxl_resource_contains_addr() to check address availabilityLi Ming3-6/+6
Helper function cxl_resource_contains_addr() can be used to check if a resource range contains an input address. Use it to replace all code that checks whether a resource range contains a DPA/HPA/SPA. Signed-off-by: Li Ming <ming.li@zohomail.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Reviewed-by: Alison Schofield <alison.schofield@intel.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Link: https://patch.msgid.link/20250711032357.127355-4-ming.li@zohomail.com Signed-off-by: Dave Jiang <dave.jiang@intel.com>
2025-07-11cxl/edac: Fix wrong dpa checking for PPR operationLi Ming1-1/+4
Per Table 8-143. "Get Partition Info Output Payload" in CXL r3.2 section 8.2.10.9.2.1 "Get Partition Info(Opcode 4100h)", DPA 0 is a valid address of a CXL device. However, cxl_do_ppr() considers it as an invalid address, so that user will get an -EINVAL when user calls the sysfs interface of the edac driver to trigger a Post Package Repair(PPR) operation for DPA 0 on a CXL device. The correct implementation should be checking if the input DPA is in the DPA range of the CXL device. Fixes: be9b359e056a ("cxl/edac: Add CXL memory device soft PPR control feature") Signed-off-by: Li Ming <ming.li@zohomail.com> Tested-by: Shiju Jose <shiju.jose@huawei.com> Reviewed-by: Shiju Jose <shiju.jose@huawei.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Reviewed-by: Alison Schofield <alison.schofield@intel.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Link: https://patch.msgid.link/20250711032357.127355-3-ming.li@zohomail.com Signed-off-by: Dave Jiang <dave.jiang@intel.com>
2025-07-11cxl/core: Introduce a new helper cxl_resource_contains_addr()Li Ming2-0/+8
In CXL subsystem, many functions need to check an address availability by checking if the resource range contains the address. Providing a new helper function cxl_resource_contains_addr() to check if the resource range contains the input address. Suggested-by: Alison Schofield <alison.schofield@intel.com> Signed-off-by: Li Ming <ming.li@zohomail.com> Tested-by: Shiju Jose <shiju.jose@huawei.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Reviewed-by: Alison Schofield <alison.schofield@intel.com> Link: https://patch.msgid.link/20250711032357.127355-2-ming.li@zohomail.com Signed-off-by: Dave Jiang <dave.jiang@intel.com>
2025-07-11wifi: ath12k: support average ack rssi in station dumpSivashankari Madhavan4-4/+18
Currently, the ACK RSSI value is not shown in station dump. Enable WMI resource flag for ACK RSSI in WMI INIT command to add ACK RSSI value in management TX completion event from WMI. Update ACK RSSI value obtained in management and data frame completion path to ieee80211_tx_info. Also advertise NL80211_EXT_FEATURE_ACK_SIGNAL_SUPPORT flag during hardware register to mac80211 layer so that ACK RSSI is added to station dump message. Example output : Station aa:bb:cc:dd:ee:ff (on wlp88s0) inactive time: 46584 ms rx bytes: 955 rx packets: 10 tx bytes: 769 tx packets: 6 tx retries: 81 tx failed: 0 rx drop misc: 0 signal: -39 dBm signal avg: -40 dBm tx bitrate: 6.0 MBit/s tx duration: 1185 us rx bitrate: 309.7 MBit/s 40MHz HE-MCS 6 HE-NSS 2 HE-GI 0 HE-DCM 0 rx duration: 0 us last ack signal:-41 dBm avg ack signal: -40 dBm authorized: yes authenticated: yes ....... Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: Sivashankari Madhavan <quic_sivamadh@quicinc.com> Signed-off-by: Sowmiya Sree Elavalagan <quic_ssreeela@quicinc.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250709133554.622463-1-quic_ssreeela@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-07-11Merge tag 'pm-6.16-rc6' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull power management fix from Rafael Wysocki: "Fix a coding mistake in a previous fix related to system suspend and hibernation merged recently" * tag 'pm-6.16-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: PM: sleep: Call pm_restore_gfp_mask() after dpm_resume()
2025-07-11platform/x86: dell-lis3lv02d: Add Precision 3551Jan-Niklas Burfeind1-0/+1
This marks 0x29 as accelerometer address on Dell Precision 3551. I followed previous works of Paul Menzel and Hans de Goede to verify it: $ cd /sys/bus/pci/drivers/i801_smbus/0000\:00\:1f.4 $ ls -d i2c-? i2c-0 $ sudo modprobe i2c-dev $ sudo i2cdetect 0 WARNING! This program can confuse your I2C bus, cause data loss and worse! I will probe file /dev/i2c-0. I will probe address range 0x08-0x77. Continue? [Y/n] Y 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: 08 -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- 29 -- -- -- -- -- -- 30: 30 -- -- -- -- 35 UU UU -- -- -- -- -- -- -- -- 40: -- -- -- -- 44 -- -- -- -- -- -- -- -- -- -- -- 50: UU -- 52 -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- $ echo lis3lv02d 0x29 > sudo tee /sys/bus/i2c/devices/i2c-0/new_device lis3lv02d 0x29 $ sudo dmesg [ 0.000000] Linux version 6.12.28 (nixbld@localhost) (gcc (GCC) 14.2.1 20250322, GNU ld (GNU Binutils) 2.44) #1-NixOS SMP PREEMPT_DYNAMIC Fri May 9 07:50:53 UTC 2025 [...] [ 0.000000] DMI: Dell Inc. Precision 3551/07YHW8, BIOS 1.18.0 10/03/2022 [...] [ 3749.077624] lis3lv02d_i2c 0-0029: supply Vdd not found, using dummy regulator [ 3749.077732] lis3lv02d_i2c 0-0029: supply Vdd_IO not found, using dummy regulator [ 3749.098674] lis3lv02d: 8 bits 3DC sensor found [ 3749.182480] input: ST LIS3LV02DL Accelerometer as /devices/platform/lis3lv02d/input/input28 [ 3749.182899] i2c i2c-0: new_device: Instantiated device lis3lv02d at 0x29 Signed-off-by: Jan-Niklas Burfeind <kernel@aiyionpri.me> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Link: https://lore.kernel.org/r/20250710190919.37842-1-kernel@aiyionpri.me Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-07-11platform/x86: alieneware-wmi-wmax: Add AWCC support to more laptopsKurt Borja1-0/+16
Add support to Alienware Area-51m and Alienware m15 R5. Signed-off-by: Kurt Borja <kuurtb@gmail.com> Link: https://lore.kernel.org/r/20250710-m15_r5-v1-1-2c6ad44e5987@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-07-11platform/x86: Fix initialization order for firmware_attributes_classTorsten Hilbrich1-1/+2
The think-lmi driver uses the firwmare_attributes_class. But this class is registered after think-lmi, causing the "think-lmi" directory in "/sys/class/firmware-attributes" to be missing when the driver is compiled as builtin. Fixes: 55922403807a ("platform/x86: think-lmi: Directly use firmware_attributes_class") Signed-off-by: Torsten Hilbrich <torsten.hilbrich@secunet.com> Link: https://lore.kernel.org/r/7dce5f7f-c348-4350-ac53-d14a8e1e8034@secunet.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-07-11platform: arm64: huawei-gaokun-ec: fix OF node leakJohan Hovold1-0/+2
Make sure to drop the OF node reference taken when creating the Gaokun auxiliary devices when the devices are later released. Fixes: 7636f090d02e ("platform: arm64: add Huawei Matebook E Go EC driver") Cc: Pengyu Luo <mitltlatltl@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Pengyu Luo <mitltlatltl@gmail.com> Link: https://lore.kernel.org/r/20250708085358.15657-1-johan@kernel.org Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-07-11platform/x86: lenovo: gamezone needs "other mode"Arnd Bergmann1-0/+1
Registering the "other mode" notifier fails if that is disabled: x86_64-linux-ld: drivers/platform/x86/lenovo/wmi-gamezone.o: in function `lwmi_gz_probe': wmi-gamezone.c:(.text+0x336): undefined reference to `devm_lwmi_om_register_notifier' This could be fixed by adding a stub helper, but a Kconfig 'select' seems simpler here. Fixes: 22024ac5366f ("platform/x86: Add Lenovo Gamezone WMI Driver") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20250709151734.1268435-1-arnd@kernel.org [ij: retained the other selects as wmi-gamezone is using them directly.] Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-07-11drm/xe/migrate: fix copy direction in access_memoryMatthew Auld1-1/+1
After we do the modification on the host side, ensure we write the result back to VRAM and not the other way around, otherwise the modification will be lost if treated like a read. Fixes: 270172f64b11 ("drm/xe: Update xe_ttm_access_memory to use GPU for non-visible access") Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250710134128.800756-2-matthew.auld@intel.com
2025-07-11wifi: iwlwifi: add support for accepting raw DSM tables by firmwarePagadala Yesu Anjaneyulu6-16/+63
Firmware would assert on undefined bits in DSM-originated DWs. With this change, Firmware introduces a fail-safe mechanism and removes the assert behavior. This ensures robustness when handling raw DSM table data. Signed-off-by: Pagadala Yesu Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250710212632.eee871df03c9.I2be2eaa16437e84aa1be0c6c95ec334034ce7e50@changeid
2025-07-11wifi: iwlwifi: pcie: don't WARN on bad firmware inputJohannes Berg1-6/+5
Don't WARN, which results in a useless backtrace, but just use IWL_FW_CHECK() instead. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250710212632.4aedc0979beb.I3bd4d4296c7245261651603708456b7c67f55539@changeid
2025-07-11wifi: iwlwifi: mld: don't remove all keys in mcast rekeyMiri Korenblit3-73/+53
In the current code, if there was a rekey, we remove all the existing keys from mac80211, then re-add the ones that the FW sent with ieee80211_gtk_rekey_add, (newer FW will send also the existing GTKs/BIGTKs) and then update the sequence number. Instead of removing and re-adding the existing keys for no good reason, we can just update the sequence of all keys, also of the ones that are going to be replaced, and update again after the replace. This change is required because ieee80211_gtk_rekey_add is going to be changed to lookup the cipher from the old key instead of receiving it as an argument, and for this it will need the old key(s), so we can't remove all keys. Note that with this change, in case that a key that existed before wowlan is replaced, mac80211 will now call the driver to remove the old key and add the new one (as opposed the previous behaviour, in which the key was removed by the driver itself). Of course we don't want to run the set_key callbacks in this case, so just return early. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250710212632.f0b5e19f77f5.I958f4926f168cdad6d4d7720ebde2f5e812b297d@changeid
2025-07-11wifi: iwlwifi: mvm: don't remove all keys in mcast rekeyMiri Korenblit2-38/+34
In the current code, if there was a rekey, we remove all the existing keys from mac80211, then re-add the ones that the FW sent with ieee80211_gtk_rekey_add, (newer FW will send also the existing GTKs/BIGTKs) and then update the sequence number. Instead of removing and re-adding the existing keys for no good reason, we can just update the sequence of all keys, also of the ones that are going to be replaced, and update again after the replace. This change is required because ieee80211_gtk_rekey_add is going to be changed to lookup the cipher from the old key instead of receiving it as an argument, and for this it will need the old key(s), so we can't remove all keys. Note that with this change, in case that a key that existed before wowlan is replaced, mac80211 will now call the driver to remove the old key and add the new one (as opposed the previous behaviour, in which the key was removed by the driver itself). Of course we don't want to run the set_key callbacks in this case, so just return early. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250710212632.10091484e38e.I45daf089189f606f3879ca4538fb46303d761710@changeid
2025-07-11wifi: iwlwifi: mvm: always set the key idx in gtk_seqMiri Korenblit1-11/+6
For older APIs, gtk_seq[0].key_id will be set to -1, while other code assumes that it will always be a valid gtk key idx. Since the FW does provide the idx for those APIs, simply set it. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250710212632.2a5a5e4d7b19.Ib795751119070495c0c95526cd36bd7f87594f56@changeid
2025-07-11wifi: iwlwifi: mvm: set gtk id also in older FWsMiri Korenblit1-0/+2
We use gtk[i].id, but it is not even set in older FW APIs (iwl_wowlan_status_v6 and iwl_wowlan_status_v7). Set it also in older FWs. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250710212632.e91e49590414.I27d2fdbed1c54aee59929fa11ec169f07e159406@changeid
2025-07-11wifi: iwlwifi: fix HE/EHT capabilitiesJohannes Berg1-63/+15
The default capabilities were set to much more than the hardware currently is intended to support, and then masked off for only the GL MAC type. However, this was due to some miscommunication and is incorrect, it should've been masked off for all current and planned MACs/RFs. Instead of doing this removing and adding of capabilities, simply list the ones that currently apply to all devices. If this changes for a new device type we can change the code, but at least the driver won't erroneously advertise some capabilities that aren't actually implemented in hardware. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250710212632.69b9dac7d906.I7885499bc80453d5a84285ec927f5e89f9adfb21@changeid
2025-07-11wifi: iwlwifi: add iwl_trans_is_dead() APIRotem Kerem5-4/+9
Add iwl_trans_is_dead() function to be called by the op modes instead of directly checking the trans status bits. This hides the trans internal implementation details from callers. Signed-off-by: Rotem Kerem <rotem.kerem@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250710212632.cd89d8013261.I214b7ffbabc393593fb57831d61d1a9ffa318a1e@changeid
2025-07-11wifi: iwlwifi: add iwl_trans_device_enabled() APIRotem Kerem4-4/+9
add iwl_trans_device_enabled() function to be called by the op modes instead of directly checking the trans status bits. This hides the trans internal implementation details. Signed-off-by: Rotem Kerem <rotem.kerem@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250710212632.bb957ba9e130.I6ab825caf41308fb0f7aa1c266f50457fd0c496e@changeid
2025-07-11wifi: iwlwifi: add suppress_cmd_error_once() APIRotem Kerem3-2/+7
Add iwl_trans_suppress_cmd_error_once() function to be called by the op modes instead of directly checking the trans status bits. This hides the trans internal implementation details from callers. Signed-off-by: Rotem Kerem <rotem.kerem@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250710212632.e061ae241fd3.Ie2043c4e237196ebcfe195006d3d76371de48a55@changeid
2025-07-11wifi: iwlwifi: mld: restrict puncturing disable to FMJohannes Berg1-5/+9
Later RFs will always do puncturing, regardless of BIOS configuration, and earlier RFs aren't supported in MLD. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250710212632.6fa9c44964c1.I46a4cd744a769ec2ac3c8f9a04882140449394b8@changeid
2025-07-11wifi: iwlwifi: mvm: remove regulatory puncturing setupJohannes Berg3-9/+0
We don't have puncturing before EHT, and EHT devices aren't supported in iwlmvm, so remove the regulatory puncturing setup code. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250710212632.b2a28a99725b.I72ba276cb705c02cea8f68e27ef3935d5120cfee@changeid
2025-07-11wifi: iwlwifi: mld: update expected range response notification versionAvraham Stern1-1/+1
The last version for the range response notification is 10. Update the expected version accordingly. Signed-off-by: Avraham Stern <avraham.stern@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250710212632.377d24e29ac6.I44119a4e793bba35b46e1d35e2c378ce6f901bfd@changeid
2025-07-11wifi: iwlwifi: mld: update the P2P device mac before starting the GOAvraham Stern1-7/+17
When a GO is started, the P2P device mac is updated to indicate that frames for the P2P device mac should be filtered in while the GO is active. However, this configuration is done after the GO is already started so it doesn't take effect. Fix it by updating the P2P device mac before adding the broadcast station, which actually starts the GO. Signed-off-by: Avraham Stern <avraham.stern@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250710212632.463a0ad545f9.I85a25484d787b65f6a27e794285911e319df0b2d@changeid
2025-07-11wifi: iwlwifi: mld: fix scan request validationAvraham Stern1-1/+1
The scan request validation function uses bitwise and instead of logical and. Fix it. Signed-off-by: Avraham Stern <avraham.stern@intel.com> Reviewed-by: Daniel Gabay <daniel.gabay@intel.com> Reviewed-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250710212632.ec7d665f56a4.I416816b491fafa5d3efdf0a4be78356eedf2bd95@changeid
2025-07-11platform/x86/intel/pmt/discovery: fix format string warningArnd Bergmann1-1/+1
When -Wformat-security is enabled, this new code triggers it: drivers/platform/x86/intel/pmt/discovery.c: In function 'pmt_features_discovery': drivers/platform/x86/intel/pmt/discovery.c:505:36: error: format not a string literal and no format arguments [-Werror=format-security] 505 | pmt_feature_names[feature->id]); Fixes: d9a078809356 ("platform/x86/intel/pmt: Add PMT Discovery driver") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20250711072718.2748415-1-arnd@kernel.org Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-07-11memory: tegra: Add Tegra264 MC and EMC supportSumit Gupta7-6/+395
Add support to enable Memory Controller (MC) and External Memory Controller (EMC) drivers for Tegra264. The nodes for MC and EMC are mostly the same as Tegra234 but differ in number of channels and interrupt numbers. The patch also adds the bandwidth manager definitions required for Tegra264 and uses them to populate the memory client table. All of these are needed to properly enable memory interconnect (ICC) support. Signed-off-by: Sumit Gupta <sumitg@nvidia.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20250709222147.3758356-3-thierry.reding@gmail.com Signed-off-by: Thierry Reding <treding@nvidia.com>
2025-07-11wifi: ath12k: Fix packets received in WBM error ring with REO LUT enabledNithyanantham Paramasivam1-1/+2
Currently, packets are being received into the WBM error ring when REO queue lookup is enabled, resulting in degraded RX performance. The issue arises because the REO queue LUT TID memory reference is set to zero-it's being assigned before the memory is allocated. Fix this by assigning the REO queue TID memory reference in the LUT immediately after memory allocation to ensure correct packet processing. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Reported-by: Tanguy Serrat <tanguy@squaremind.io> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220282 Fixes: 3b9cbce6fdd3 ("wifi: ath12k: alloc REO queue per station") Signed-off-by: Nithyanantham Paramasivam <nithyanantham.paramasivam@oss.qualcomm.com> Reviewed-by: Baochen Qiang <quic_bqiang@quicinc.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250710011754.559817-1-nithyanantham.paramasivam@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-07-11bnxt_en: Set DMA unmap len correctly for XDP_REDIRECTSomnath Kotur1-1/+1
When transmitting an XDP_REDIRECT packet, call dma_unmap_len_set() with the proper length instead of 0. This bug triggers this warning on a system with IOMMU enabled: WARNING: CPU: 36 PID: 0 at drivers/iommu/dma-iommu.c:842 __iommu_dma_unmap+0x159/0x170 RIP: 0010:__iommu_dma_unmap+0x159/0x170 Code: a8 00 00 00 00 48 c7 45 b0 00 00 00 00 48 c7 45 c8 00 00 00 00 48 c7 45 a0 ff ff ff ff 4c 89 45 b8 4c 89 45 c0 e9 77 ff ff ff <0f> 0b e9 60 ff ff ff e8 8b bf 6a 00 66 66 2e 0f 1f 84 00 00 00 00 RSP: 0018:ff22d31181150c88 EFLAGS: 00010206 RAX: 0000000000002000 RBX: 00000000e13a0000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ff22d31181150cf0 R08: ff22d31181150ca8 R09: 0000000000000000 R10: 0000000000000000 R11: ff22d311d36c9d80 R12: 0000000000001000 R13: ff13544d10645010 R14: ff22d31181150c90 R15: ff13544d0b2bac00 FS: 0000000000000000(0000) GS:ff13550908a00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005be909dacff8 CR3: 0008000173408003 CR4: 0000000000f71ef0 PKRU: 55555554 Call Trace: <IRQ> ? show_regs+0x6d/0x80 ? __warn+0x89/0x160 ? __iommu_dma_unmap+0x159/0x170 ? report_bug+0x17e/0x1b0 ? handle_bug+0x46/0x90 ? exc_invalid_op+0x18/0x80 ? asm_exc_invalid_op+0x1b/0x20 ? __iommu_dma_unmap+0x159/0x170 ? __iommu_dma_unmap+0xb3/0x170 iommu_dma_unmap_page+0x4f/0x100 dma_unmap_page_attrs+0x52/0x220 ? srso_alias_return_thunk+0x5/0xfbef5 ? xdp_return_frame+0x2e/0xd0 bnxt_tx_int_xdp+0xdf/0x440 [bnxt_en] __bnxt_poll_work_done+0x81/0x1e0 [bnxt_en] bnxt_poll+0xd3/0x1e0 [bnxt_en] Fixes: f18c2b77b2e4 ("bnxt_en: optimized XDP_REDIRECT support") Signed-off-by: Somnath Kotur <somnath.kotur@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Link: https://patch.msgid.link/20250710213938.1959625-4-michael.chan@broadcom.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-11bnxt_en: Flush FW trace before copying to the coredumpShruti Parab1-7/+11
bnxt_fill_drv_seg_record() calls bnxt_dbg_hwrm_log_buffer_flush() to flush the FW trace buffer. This needs to be done before we call bnxt_copy_ctx_mem() to copy the trace data. Without this fix, the coredump may not contain all the FW traces. Fixes: 3c2179e66355 ("bnxt_en: Add FW trace coredump segments to the coredump") Reviewed-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com> Signed-off-by: Shruti Parab <shruti.parab@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Link: https://patch.msgid.link/20250710213938.1959625-3-michael.chan@broadcom.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-11bnxt_en: Fix DCB ETS validationShravya KN1-0/+2
In bnxt_ets_validate(), the code incorrectly loops over all possible traffic classes to check and add the ETS settings. Fix it to loop over the configured traffic classes only. The unconfigured traffic classes will default to TSA_ETS with 0 bandwidth. Looping over these unconfigured traffic classes may cause the validation to fail and trigger this error message: "rejecting ETS config starving a TC\n" The .ieee_setets() will then fail. Fixes: 7df4ae9fe855 ("bnxt_en: Implement DCBNL to support host-based DCBX.") Reviewed-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Signed-off-by: Shravya KN <shravya.k-n@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Link: https://patch.msgid.link/20250710213938.1959625-2-michael.chan@broadcom.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-11net: ll_temac: Fix missing tx_pending check in ethtools_set_ringparam()Alok Tiwari1-1/+1
The function ll_temac_ethtools_set_ringparam() incorrectly checked rx_pending twice, once correctly for RX and once mistakenly in place of tx_pending. This caused tx_pending to be left unchecked against TX_BD_NUM_MAX. As a result, invalid TX ring sizes may have been accepted or valid ones wrongly rejected based on the RX limit, leading to potential misconfiguration or unexpected results. This patch corrects the condition to properly validate tx_pending. Fixes: f7b261bfc35e ("net: ll_temac: Make RX/TX ring sizes configurable") Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com> Link: https://patch.msgid.link/20250710180621.2383000-1-alok.a.tiwari@oracle.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-11net/mlx5e: Add new prio for promiscuous modeJianbo Liu3-7/+17
An optimization for promiscuous mode adds a high-priority steering table with a single catch-all rule to steer all traffic directly to the TTC table. However, a gap exists between the creation of this table and the insertion of the catch-all rule. Packets arriving in this brief window would miss as no rule was inserted yet, unnecessarily incrementing the 'rx_steer_missed_packets' counter and dropped. This patch resolves the issue by introducing a new prio for this table, placing it between MLX5E_TC_PRIO and MLX5E_NIC_PRIO. By doing so, packets arriving during the window now fall through to the next prio (at MLX5E_NIC_PRIO) instead of being dropped. Fixes: 1c46d7409f30 ("net/mlx5e: Optimize promiscuous mode") Signed-off-by: Jianbo Liu <jianbol@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/1752155624-24095-4-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-11net/mlx5e: Fix race between DIM disable and net_dim()Carolina Jubran1-2/+2
There's a race between disabling DIM and NAPI callbacks using the dim pointer on the RQ or SQ. If NAPI checks the DIM state bit and sees it still set, it assumes `rq->dim` or `sq->dim` is valid. But if DIM gets disabled right after that check, the pointer might already be set to NULL, leading to a NULL pointer dereference in net_dim(). Fix this by calling `synchronize_net()` before freeing the DIM context. This ensures all in-progress NAPI callbacks are finished before the pointer is cleared. Kernel log: BUG: kernel NULL pointer dereference, address: 0000000000000000 ... RIP: 0010:net_dim+0x23/0x190 ... Call Trace: <TASK> ? __die+0x20/0x60 ? page_fault_oops+0x150/0x3e0 ? common_interrupt+0xf/0xa0 ? sysvec_call_function_single+0xb/0x90 ? exc_page_fault+0x74/0x130 ? asm_exc_page_fault+0x22/0x30 ? net_dim+0x23/0x190 ? mlx5e_poll_ico_cq+0x41/0x6f0 [mlx5_core] ? sysvec_apic_timer_interrupt+0xb/0x90 mlx5e_handle_rx_dim+0x92/0xd0 [mlx5_core] mlx5e_napi_poll+0x2cd/0xac0 [mlx5_core] ? mlx5e_poll_ico_cq+0xe5/0x6f0 [mlx5_core] busy_poll_stop+0xa2/0x200 ? mlx5e_napi_poll+0x1d9/0xac0 [mlx5_core] ? mlx5e_trigger_irq+0x130/0x130 [mlx5_core] __napi_busy_loop+0x345/0x3b0 ? sysvec_call_function_single+0xb/0x90 ? asm_sysvec_call_function_single+0x16/0x20 ? sysvec_apic_timer_interrupt+0xb/0x90 ? pcpu_free_area+0x1e4/0x2e0 napi_busy_loop+0x11/0x20 xsk_recvmsg+0x10c/0x130 sock_recvmsg+0x44/0x70 __sys_recvfrom+0xbc/0x130 ? __schedule+0x398/0x890 __x64_sys_recvfrom+0x20/0x30 do_syscall_64+0x4c/0x100 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ... ---[ end trace 0000000000000000 ]--- ... ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]--- Fixes: 445a25f6e1a2 ("net/mlx5e: Support updating coalescing configuration without resetting channels") Signed-off-by: Carolina Jubran <cjubran@nvidia.com> Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/1752155624-24095-3-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-11net/mlx5: Reset bw_share field when changing a node's parentCarolina Jubran1-0/+1
When changing a node's parent, its scheduling element is destroyed and re-created with bw_share 0. However, the node's bw_share field was not updated accordingly. Set the node's bw_share to 0 after re-creation to keep the software state in sync with the firmware configuration. Fixes: 9c7bbf4c3304 ("net/mlx5: Add support for setting parent of nodes") Signed-off-by: Carolina Jubran <cjubran@nvidia.com> Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/1752155624-24095-2-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-11iommufd/selftest: Add coverage for IOMMUFD_CMD_HW_QUEUE_ALLOCNicolin Chen2-0/+100
Some simple tests for IOMMUFD_CMD_HW_QUEUE_ALLOC infrastructure covering the new iommufd_hw_queue_depend/undepend() helpers. Link: https://patch.msgid.link/r/e8a194d187d7ef445f43e4a3c04fb39472050afd.1752126748.git.nicolinc@nvidia.com Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> Reviewed-by: Pranjal Shrivastava <praan@google.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2025-07-11iommufd/driver: Add iommufd_hw_queue_depend/undepend() helpersNicolin Chen1-0/+28
NVIDIA Virtual Command Queue is one of the iommufd users exposing vIOMMU features to user space VMs. Its hardware has a strict rule when mapping and unmapping multiple global CMDQVs to/from a VM-owned VINTF, requiring mappings in ascending order and unmappings in descending order. The tegra241-cmdqv driver can apply the rule for a mapping in the LVCMDQ allocation handler. However, it can't do the same for an unmapping since user space could start random destroy calls breaking the rule, while the destroy op in the driver level can't reject a destroy call as it returns void. Add iommufd_hw_queue_depend/undepend for-driver helpers, allowing LVCMDQ allocator to refcount_inc() a sibling LVCMDQ object and LVCMDQ destroyer to refcount_dec(), so that iommufd core will help block a random destroy call that breaks the rule. This is a bit of compromise, because a driver might end up with abusing the API that deadlocks the objects. So restrict the API to a dependency between two driver-allocated objects of the same type, as iommufd would unlikely build any core-level dependency in this case. And encourage to use the macro version that currently supports the HW QUEUE objects only. Link: https://patch.msgid.link/r/2735c32e759c82f2e6c87cb32134eaf09b7589b5.1752126748.git.nicolinc@nvidia.com Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by: Pranjal Shrivastava <praan@google.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2025-07-11iommufd/viommu: Add IOMMUFD_CMD_HW_QUEUE_ALLOC ioctlNicolin Chen3-0/+188
Introduce a new IOMMUFD_CMD_HW_QUEUE_ALLOC ioctl for user space to allocate a HW QUEUE object for a vIOMMU specific HW-accelerated queue, e.g.: - NVIDIA's Virtual Command Queue - AMD vIOMMU's Command Buffer, Event Log Buffers, and PPR Log Buffers Since this is introduced with NVIDIA's VCMDQs that access the guest memory in the physical address space, add an iommufd_hw_queue_alloc_phys() helper that will create an access object to the queue memory in the IOAS, to avoid the mappings of the guest memory from being unmapped, during the life cycle of the HW queue object. AMD's HW will need an hw_queue_init op that is mutually exclusive with the hw_queue_init_phys op, and their case will bypass the access part, i.e. no iommufd_hw_queue_alloc_phys() call. Link: https://patch.msgid.link/r/dab4ace747deb46c1fe70a5c663307f46990ae56.1752126748.git.nicolinc@nvidia.com Reviewed-by: Pranjal Shrivastava <praan@google.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2025-07-11iommufd/viommu: Add driver-defined vDEVICE supportNicolin Chen2-13/+25
NVIDIA VCMDQ driver will have a driver-defined vDEVICE structure and do some HW configurations with that. To allow IOMMU drivers to define their own vDEVICE structures, move the struct iommufd_vdevice to the public header and provide a pair of viommu ops, similar to get_viommu_size and viommu_init. Doing this, however, creates a new window between the vDEVICE allocation and its driver-level initialization, during which an abort could happen but it can't invoke a driver destroy function from the struct viommu_ops since the driver structure isn't initialized yet. vIOMMU object doesn't have this problem, since its destroy op is set via the viommu_ops by the driver viommu_init function. Thus, vDEVICE should do something similar: add a destroy function pointer inside the struct iommufd_vdevice instead of the struct iommufd_viommu_ops. Note that there is unlikely a use case for a type dependent vDEVICE, so a static vdevice_size is probably enough for the near term instead of a get_vdevice_size function op. Link: https://patch.msgid.link/r/1e751c01da7863c669314d8e27fdb89eabcf5605.1752126748.git.nicolinc@nvidia.com Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Pranjal Shrivastava <praan@google.com> Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by: Vasant Hegde <vasant.hegde@amd.com> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2025-07-11iommufd/access: Bypass access->ops->unmap for internal useNicolin Chen4-10/+33
The access object has been used externally by VFIO mdev devices, allowing them to pin/unpin physical pages (via needs_pin_pages). Meanwhile, a racy unmap can occur in this case, so these devices usually implement an unmap handler, invoked by iommufd_access_notify_unmap(). The new HW queue object will need the same pin/unpin feature, although it (unlike the mdev case) wants to reject any unmap attempt, during its life cycle. Instead, it would not implement an unmap handler. Thus, bypass any access->ops->unmap access call when the access is marked as internal. Also, an area being pinned by an internal access should reject any unmap request. This cannot be done inside iommufd_access_notify_unmap() as it's a per-iopt action. Add a "num_locks" counter in the struct iopt_area, set that in iopt_area_add_access() when the caller is an internal access. Link: https://patch.msgid.link/r/6df9a43febf79c0379091ec59747276ce9d2493b.1752126748.git.nicolinc@nvidia.com Suggested-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Pranjal Shrivastava <praan@google.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2025-07-11nvme-pci: don't allocate dma_vec for IOVA mappingsChristoph Hellwig1-2/+2
Not only do IOVA mappings no need the separate dma_vec tracking, it also won't free it and thus leak the allocations. Fixes: b8b7570a7ec8 ("nvme-pci: fix dma unmapping when using PRPs and not using the IOVA mapping") Reported-by: Klara Modin <klarasmodin@gmail.com> Signed-off-by: Christoph Hellwig <hch@lst.de> Tested-by: Klara Modin <klarasmodin@gmail.com> Link: https://lore.kernel.org/r/20250711112250.633269-1-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-07-11firmware: tegra: bpmp: Fix build failure for tegra264-only configArnd Bergmann2-6/+1
The definition of tegra186_bpmp_ops was not updated in sync with the use in bpmp.c: drivers/firmware/tegra/bpmp.c:856:17: error: 'tegra186_bpmp_ops' undeclared here (not in a function); did you mean 'tegra_bpmp_ops'? 856 | .ops = &tegra186_bpmp_ops, aarch64-linux-ld: drivers/firmware/tegra/bpmp.o:(.rodata+0x2f0): undefined reference to `tegra186_bpmp_ops' Update the Makefile as needed. There is really no need to hide the declaration based on the configuration, so just expose it unconditionally so it never has to be updated again for the next SoC. Fixes: 94bce2cf7cf6 ("firmware: tegra: bpmp: Add support on Tegra264") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20250711082409.1398497-1-arnd@kernel.org Signed-off-by: Thierry Reding <treding@nvidia.com>
2025-07-11Merge tag 'drm-misc-fixes-2025-07-10' of ↵Simona Vetter12-59/+108
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes drm-misc-fixes for v6.16-rc6 or final: - Fix nouveau fail on debugfs errors. - Magic 50 ms to fix nouveau suspend. - Call rust destructor on drm device release. - Fix DMA api error handling in tegra/nvdec. - Fix PVR device reset. - Habanalabs maintainer update. - Small memory leak fix when nouveau acpi init fails. - Do not attempt to bind to any PCI device with AGP capability. - Make FB's acquire handles on backing object, same as i915/xe already does. - Fix race in drm_gem_handle_create_tail. Signed-off-by: Simona Vetter <simona.vetter@ffwll.ch> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/e522cdc7-1787-48f2-97e5-0f94783970ab@linux.intel.com
2025-07-11PCI: hv: Switch to msi_create_parent_irq_domain()Nam Cao2-28/+84
Move away from the legacy MSI domain setup, switch to use msi_create_parent_irq_domain(). While doing the conversion, I noticed that hv_compose_msi_msg() is doing more than it is supposed to (composing message). This function also allocates and populates struct tran_int_desc, which should be done in hv_pcie_domain_alloc() instead. It works, but it is not the correct design. However, I have no hardware to test such change, therefore I leave a TODO note. Acked-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Nam Cao <namcao@linutronix.de> Reviewed-by: Michael Kelley <mhklinux@outlook.com> Tested-by: Michael Kelley <mhklinux@outlook.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2025-07-11Merge tag 'aspeed-6.16-fixes-0' of ↵Arnd Bergmann1-1/+12
https://git.kernel.org/pub/scm/linux/kernel/git/bmc/linux into arm/fixes ASPEED SoC driver fixes for 6.16 Address concerns in the ASPEED LPC snoop driver identified in the first two patches of the cleanup series at [1]. [1]: https://lore.kernel.org/all/20250616-aspeed-lpc-snoop-fixes-v2-0-3cdd59c934d3@codeconstruct.com.au/ * tag 'aspeed-6.16-fixes-0' of https://git.kernel.org/pub/scm/linux/kernel/git/bmc/linux: soc: aspeed: lpc-snoop: Don't disable channels that aren't enabled soc: aspeed: lpc-snoop: Cleanup resources in stack-order Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2025-07-11gpio: rcar: Convert to DEFINE_SIMPLE_DEV_PM_OPS()Geert Uytterhoeven1-4/+3
Convert the Renesas R-Car GPIO driver from SIMPLE_DEV_PM_OPS() to DEFINE_SIMPLE_DEV_PM_OPS() and pm_sleep_ptr(). This lets us drop the check for CONFIG_PM_SLEEP, and reduces kernel size in case CONFIG_PM or CONFIG_PM_SLEEP is disabled, while increasing build coverage. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Link: https://lore.kernel.org/r/e201140426daacaa799d73e2f76bfd96b6f5718f.1752086619.git.geert+renesas@glider.be Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-07-11can: m_can: m_can_handle_lost_msg(): downgrade msg lost in rx message to ↵Sean Nyekjaer1-1/+1
debug level Downgrade the "msg lost in rx" message to debug level, to prevent flooding the kernel log with error messages. Fixes: e0d1f4816f2a ("can: m_can: add Bosch M_CAN controller support") Reviewed-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Signed-off-by: Sean Nyekjaer <sean@geanix.com> Link: https://patch.msgid.link/20250711-mcan_ratelimit-v3-1-7413e8e21b84@geanix.com [mkl: enhance commit message] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-07-11can: rcar_canfd: Drop unused macrosBiju Das1-93/+0
Drop unused macros from the rcar_canfd.c. Reported-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Closes: https://lore.kernel.org/all/7ff93ff9-f578-4be2-bdc6-5b09eab64fe6@wanadoo.fr/ Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Link: https://patch.msgid.link/20250702120539.98490-1-biju.das.jz@bp.renesas.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-07-11Merge back earlier changes related to system suspend and hibernationRafael J. Wysocki4-56/+155
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-21 17:37:42 +0300