summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2026-07-21platform/x86: uniwill-laptop: Add Avell A60 MUV supportWerner Sembach
Add support for the Avell A60 MUV based on information from tuxedo-drivers, formerly known as tuxedo-keyboard: https://github.com/tuxedocomputers/tuxedo-keyboard/pull/91 Signed-off-by: Werner Sembach <wse@tuxedocomputers.com> Link: https://patch.msgid.link/20260708211950.568799-2-wse@tuxedocomputers.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-07-21platform/x86: uniwill-laptop: Add 2 new feature defines for TUXEDO devicesWerner Sembach
Add 2 of the new feature defines, UNIWILL_FEATURE_AC_AUTO_BOOT and UNIWILL_FEATURE_USB_POWERSHARE, to TUXEDO devices where applicable. Signed-off-by: Werner Sembach <wse@tuxedocomputers.com> Link: https://patch.msgid.link/20260708211950.568799-1-wse@tuxedocomputers.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-07-21wifi: mac80211_hwsim: clear PMSR request state on abortZhao Li
mac80211_hwsim saves the in-flight cfg80211 PMSR request and its wdev in data->pmsr_request / data->pmsr_request_wdev when a measurement starts, and clears them only when it reports completion. mac80211_hwsim_abort_pmsr() never cleared that saved state. cfg80211 owns the request and frees it once the abort callback returns (cfg80211_pmsr_process_abort() calls rdev_abort_pmsr() then kfree(req)), so after an abort data->pmsr_request dangles. A later hwsim PMSR report then dereferences the freed request in hwsim_pmsr_report_nl() and completes it; a use-after-free. Clear data->pmsr_request and data->pmsr_request_wdev once the abort matches the active request. Move the wmediumd/virtio notification check below the clear so the saved state is dropped even when no notification is sent. Assisted-by: Codex:gpt-5 Assisted-by: Claude:opus-4.8 Signed-off-by: Zhao Li <enderaoelyther@gmail.com> Link: https://patch.msgid.link/20260708195911.84365-2-enderaoelyther@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-07-21wifi: mac80211_hwsim: authenticate PMSR report sendersZhao Li
hwsim_pmsr_report_nl() looks up the radio by HWSIM_ATTR_ADDR_TRANSMITTER and, when data->pmsr_request is set, parses the reported peer results, hands them to cfg80211_pmsr_report(), then unconditionally clears data->pmsr_request and calls cfg80211_pmsr_complete() to end the measurement. Unlike the sibling wmediumd data-path handlers hwsim_tx_info_frame_received_nl() and hwsim_cloned_frame_received_nl(), which check the sending socket's netgroup against data->netgroup and its portid against data->wmediumd, this handler did not check the sender at all, and its genl op carries no GENL_UNS_ADMIN_PERM flag. In non-virtio (wmediumd) mode any process in the netns that can reach the hwsim generic netlink family could therefore send a report. The transmitter address is not secret, so such a process could inject spoofed ranging results for another radio's in-flight request and, because the handler always completes the measurement, terminate a ranging operation owned by the real wmediumd session. Reject reports whose sender does not match the registered wmediumd instance, mirroring the sibling handlers: in non-virtio mode require the sending socket's netgroup to equal data->netgroup and info->snd_portid to equal data->wmediumd before touching the request state. Assisted-by: Codex:gpt-5 Assisted-by: Claude:opus-4.8 Signed-off-by: Zhao Li <enderaoelyther@gmail.com> Link: https://patch.msgid.link/20260708195911.84365-3-enderaoelyther@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-07-21PCI: vmd: Handle BUS_RESTRICT_CFG value 3 for Arrow Lake-HXAli Alaei
On Intel Arrow Lake-HX systems (e.g. Core Ultra 9 275HX on Acer Predator PH16-73), the VMD controller reports BUS_RESTRICT_CFG = 3 in the VMCONFIG register. The existing switch statement only handled values 0, 1, and 2, causing vmd_get_bus_number_start() to return -ENODEV and aborting the entire VMD probe. This leaves NVMe drives behind the VMD controller invisible to the kernel. Hardware registers (VMCAP/VMCONFIG at offsets 0x40/0x44): VMD 0000:00:0e.0 (8086:ad0b): VMCAP=0x000f, VMCONFIG=0x03b8 BUS_RESTRICT_CFG(0x03b8) = (0x03b8 >> 8) & 0x3 = 3 Add cfg=3 as a fallthrough to cfg=2, setting busn_start=224, which is the correct bus number base for this hardware. Also add a PCI_POSSIBLE_ERROR() guard after reading VMCONFIG: a failed config space read returns 0xFFFF, and BUS_RESTRICT_CFG(0xFFFF) = 3, so without this guard a removed or errored device would falsely match the new case 3 instead of being caught as an error. Reported-by: Lin Mohan <linmhwork@outlook.com> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221137 # Arrow-Lake-S Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221136 # Arrow-Lake-S Signed-off-by: Ali Alaei <ali.alaei.tabatabaei@gmail.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20260628143450.92492-1-ali.alaei.tabatabaei@gmail.com
2026-07-21PCI: Add ACS quirk for Pericom PI7C9X2G608 switches [12d8:2608]Tim Harvey
The Pericom PI7C9X2G608 6-port Gen2 PCIe switch is also affected by the PI7C9X2G errata per the errata document: E2: ACS P2P Request Redirect Is Not Functional Apply the same quirk to this PCI ID as well to apply the workaround required if using ACS. Fixes: acd61ffb2f16 ("PCI: Add ACS quirk for Pericom PI7C9X2G switches") Signed-off-by: Tim Harvey <tharvey@gateworks.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260720215718.2139510-1-tharvey@gateworks.com
2026-07-21rndis_host: add overflow check in rndis_rx_fixup()Griffin Kroah-Hartman
Add an overflow check to ensure that data_offset + data_len + 8 does not wrap, which would enable an OOB read of the USB data buffer. Cc: Andrew Lunn <andrew+netdev@lunn.ch> Cc: Shaoxu Liu <shaoxul@foxmail.com> Signed-off-by: Griffin Kroah-Hartman <griffin@kroah.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/2026070900-denim-brook-52d4@gregkh Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21amd-xgbe: fix MAC_AUTO_SW handling in CL37 ANPrashanth Kumar KR
MAC_AUTO_SW (VR_MII_DIG_CTRL1 bit 9) enables automatic XPCS speed mode switching after CL37 auto-negotiation and is only meaningful in SGMII MAC mode. The original code unconditionally set this bit on every call to xgbe_an37_set(), including when called from xgbe_an37_disable() with enable=false. This left MAC_AUTO_SW=1 after AN was disabled, causing the XPCS to autonomously switch speed from stale AN state during subsequent mode changes, breaking SGMII speed negotiation on 1G copper SFP modules. Patrick: This was breaking negotiation for all 1G SFP modules, not just copper modules. Fixes: 42fd432fe6d3 ("amd-xgbe: align CL37 AN sequence as per databook") Reported-by: Patrick Oppenlander <patrick.oppenlander@gmail.com> Link: https://lore.kernel.org/netdev/CAEg67GmFS0Q4oSZkz8zWdOzckSth9_vBPiOy6a7-d697C2w2Xg@mail.gmail.com Signed-off-by: Prashanth Kumar KR <PrashanthKumar.K.R@amd.com> Tested-by: Patrick Oppenlander <patrick.oppenlander@gmail.com> Link: https://patch.msgid.link/20260709095006.3683940-1-prashanthkumar.k.r@amd.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21drm: Send per-connector hotplug eventsNicolas Frattaroli
Try to send per-connector hotplug events as often as possible, rather than connector-less global hotplug events. This does result in more hotplug events if multiple connectors changed at the same time, but give userspace more actionable information. Since the hotplug event needs to be sent outside of the mode_config mutex to avoid a deadlock, the drm_client_dev_hotplug() call is split off from the drm_sysfs_(connector_)?hotplug_event calls. Co-developed-by: Marius Vlad <marius.vlad@collabora.com> Signed-off-by: Marius Vlad <marius.vlad@collabora.com> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Link: https://patch.msgid.link/20260526-hot-plug-passup-v10-2-f62351a9ea3e@collabora.com Signed-off-by: Daniel Stone <daniels@collabora.com>
2026-07-21drm/vmwgfx: Validate vmw_surface_metadata::array_sizeIan Forbes
This field comes from userspace and should be validated against specific limits depending on which Shader Model (SM) is available. Fixes: 504901dbb0b5 ("drm/vmwgfx: Refactor surface_define to use vmw_surface_metadata") Reported-by: Zero Day Initiative <zdi-disclosures@trendmicro.com> Cc: stable@vger.kernel.org Signed-off-by: Ian Forbes <ian.forbes@broadcom.com> Reviewed-by: Maaz Mombasawala <maaz.mombasawala@broadcom.com> Signed-off-by: Zack Rusin <zack.rusin@broadcom.com> Link: https://patch.msgid.link/20260623193314.506257-1-ian.forbes@broadcom.com
2026-07-21Merge tag 'hwmon-for-v7.2-rc5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging Pull hwmon fixes from Guenter Roeck: - asus-ec-sensors: Add missed handle for ENOMEM, fix EC read intervals, and fix looping over banks while reading from EC - occ: validate poll response sensor blocks - pmbus/max34440: Block unsupported VIN and IIN limit registers - nzxt-kraken3, nzxt-smart2: gigabyte_waterforce, corsair-cpro, corsair-psu: Stop device IO before calling hid_hw_stop * tag 'hwmon-for-v7.2-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging: hwmon: occ: validate poll response sensor blocks hwmon: (asus-ec-sensors) add missed handle for ENOMEM hwmon: (asus-ec-sensors) fix EC read intervals hwmon: (asus-ec-sensors) fix looping over banks while reading from EC hwmon: (pmbus/max34440) block unsupported VIN and IIN limit registers hwmon: (nzxt-kraken3) Stop device IO before calling hid_hw_stop hwmon: (nzxt-smart2) Stop device IO before calling hid_hw_stop hwmon: (gigabyte_waterforce) Stop device IO before calling hid_hw_stop hwmon: (corsair-cpro) Stop device IO before calling hid_hw_stop hwmon: (corsair-psu) Stop device IO before calling hid_hw_stop
2026-07-21net: phy: drop duplicated header include in mdio-deviceMaxime Chevallier
During a tree-wide gpio include cleanup, the linux/gpio.h include was replaced with linux/gpio/consumer.h. mdio-device.c was already including that header, resulting in a duplicated inclusion. Let's drop it. Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20260715201213.206180-1-maxime.chevallier@bootlin.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21platform/x86/amd/pmc: Add T14 Gen2 AMD (20XL) to s2idle quirk listYap Weei Choong
The ThinkPad T14 Gen 2 AMD was sold under two machine types, 20XK and 20XL, but only 20XK has been in the s2idle quirk list since the quirk was introduced in commit 455cd867b85b ("platform/x86: thinkpad_acpi: Add a s2idle resume quirk for a number of laptops"). On 20XL machines the firmware SMI handler therefore still runs on the NVMe D3->D0 transition when exiting suspend-to-idle. With IOMMU translation enabled (the default), this intermittently stalls resume for ~10.25 seconds: seven devices across three root ports (nvme, both xhci_hcd functions, xhci-pci-renesas, snd_hda_intel x2, snd_rn_pci_acp3x) block in pci_pm_resume_noirq and are released simultaneously, consistent with all cores being held in SMM. Add the missing 20XL machine type, mirroring the existing 20XK entry. This is the same class of omission fixed by commit 9a469c6dfab3 ("platform/x86: thinkpad_acpi: Add missing T14s Gen1 type to s2idle quirk list"). Verified on a ThinkPad T14 Gen 2a (type 20XLS41C00, BIOS R1MET62W 1.32, kernel 6.12.95): with this entry the quirk message appears at probe and a 14-hour suspend resumes in ~1s with no noirq stalls, where previously even short suspends could hit the ~10s delay. A further two-day soak (short naps and two ~14-hour suspends) showed every resume clean. Link: https://bugzilla.kernel.org/show_bug.cgi?id=221755 Signed-off-by: Yap Weei Choong <ywc8891@gmail.com> Tested-by: Yap Weei Choong <ywc8891@gmail.com> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Link: https://patch.msgid.link/20260717060744.1252065-2-ywc8891@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-07-21Revert "gtp: annotate PDP lookups under RTNL"Simon Horman
This reverts commit 0be5c3f0fbef3679f50f345b9237b8f9ea5de4e9. Commit 0be5c3f0fbef ("gtp: annotate PDP lookups under RTNL") added a lockdep_rtnl_is_held condition to hlist_for_each_rcu() loops to help insure that RTNL is held. Unfortunately, as pointed out by Pablo Neira Ayuso, the PDP context list is actually protected by the genetlink mutex. And so the condition is incorrect. Compile tested only. Link: https://lore.kernel.org/ak4NgOrro-4OZjz3@chamomile Signed-off-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260708-gtp-rtnl-v1-1-218091f171bc@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21ACPI: video: Use acpi_dev_get_pci_dev() instead of acpi_get_pci_dev()Rafael J. Wysocki
In acpi_video_bus_check() and find_video(), simply replace acpi_get_pci_dev() with acpi_dev_get_pci_dev() that can be used in both places because the ACPI device needed to do the lookup is available. In acpi_video_dev_register_backlight(), instead of doing a parent ACPI handle lookup based on the handle of an ACPI device that is already available, pass that ACPI device to acpi_dev_parent() which is much more straightforward and pass the return value of the latter directly to acpi_dev_get_pci_dev() to get the PCI device associated with it. That allows local variable acpi_parent to be eliminated. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/2047771.PYKUYFuaPT@rafael.j.wysocki
2026-07-21ACPI: video: Drop backlight parent device reference laterRafael J. Wysocki
Update acpi_video_dev_register_backlight() to put the parent device after registering the backlight class device under it instead of attempting to register the backlight class device under a parent that (theoretically) may be gone at that point. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/10885673.nUPlyArG6x@rafael.j.wysocki
2026-07-21ACPI: PCI: Introduce acpi_dev_get_pci_dev()Rafael J. Wysocki
Some acpi_get_pci_dev() callers already have a struct ACPI device for which they want to get the struct pci_dev pointer of the associated PCI device, so they don't need to look for one. For this reason, add acpi_dev_get_pci_dev() that will get a PCI device for a given ACPI one (if possible) and turn acpi_get_pci_dev() into a static inline helper passing the acpi_fetch_acpi_dev() return value directly to acpi_dev_get_pci_dev(). No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/3430928.44csPzL39Z@rafael.j.wysocki
2026-07-21ACPI: PCI: Use a mutex guard to simplify acpi_get_pci_dev()Rafael J. Wysocki
Use a mutex guard in acpi_get_pci_dev() for the physical_node_lock locking and drop local variable pci_dev that becomes redundant after that change. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://patch.msgid.link/3056272.e9J7NaK4W3@rafael.j.wysocki
2026-07-21ACPI: PCI: Clear driver_data on all paths that free the acpi_pci_rootChen Pei
acpi_pci_root_add() assigns the freshly allocated root to device->driver_data before dmar_device_add() and pci_acpi_scan_root(). Both failure paths reach the end: label where root is kfree()'d, but only the pci_acpi_scan_root() path clears driver_data first. When dmar_device_add() fails during a hot-add, root is freed while device->driver_data still points at it. The ACPI core does not clear driver_data on attach failure, so a later acpi_pci_find_root() call may dereference this dangling pointer. acpi_pci_root_remove() has the same problem: it frees root without clearing device->driver_data, leaving a dangling pointer behind after the root bridge is removed. Move the NULL assignment to the shared end: label so every error path in acpi_pci_root_add() clears driver_data before freeing root, and clear it in acpi_pci_root_remove() as well, so the object is never left reachable through driver_data after being freed. Fixes: db89b4f0dbab ("ACPI: catch calls of acpi_driver_data on pointer of wrong type") Reported-by: Sashiko AI review <sashiko-bot@kernel.org> Link: https://sashiko.dev/#/patchset/20260526025118.38935-1-cp0613@linux.alibaba.com Link: https://sashiko.dev/#/patchset/20260707121258.11640-1-cp0613@linux.alibaba.com Signed-off-by: Chen Pei <cp0613@linux.alibaba.com> Link: https://patch.msgid.link/20260715135048.3278-1-cp0613@linux.alibaba.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-07-21ACPI: processor: validate MADT IOAPIC entry boundsPengpeng Hou
The IOAPIC hotplug lookup parses both MADT and _MAT records directly. The MADT walk previously used a subtable's declared length to advance the cursor after only locating a generic header. The _MAT path likewise passed a generic header to the IOAPIC helper. Validate that a current record has a complete generic header, that its declared length is contained in the available record range, and that a typed IOAPIC record contains the full fixed IOAPIC body before reading its fields. Use the same relation for both MADT and _MAT provider paths. Fixes: ecf5636dcd59 ("ACPI: Add interfaces to parse IOAPIC ID for IOAPIC hotplug") Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> Link: https://patch.msgid.link/20260715083253.22831-1-pengpeng@iscas.ac.cn Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-07-21net/mlx5e: psp: Report PSP dev registration errorsCosmin Ratiu
mlx5e_psp_register() was forced to eat PSP dev registration errors as the caller was not propagating them. Change this so PSP dev registration failures get reported back to the caller instead. After the recent changes in the series, PSP dev registration failures will just leave some data structs in priv->psp (mostly counters), with no steering rules and no means to configure them. There's no point actively cleaning those up on failure, as they'll get removed during profile->cleanup. Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260707130858.969928-16-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21net/mlx5e: Return errors from profile->enableCosmin Ratiu
profile->enable is called before enabling an mlx5 netdevice and currently doesn't return errors. Code called from it has to either: 1. eat errors and keep going, leaving a netdevice initialized with missing functionality or 2. manually clean up things that other parts of the init flow might have set up. Option 1 might be useful in some cases for optional functionality but option 2 doesn't make for good design. Add a 3rd option for code which wants to propagate errors from profile->enable and fail netdev init. This change is a noop for now, the first 'user' of this option 3 will be in the next patch. Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260707130858.969928-15-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21net/mlx5e: psp: Make PSP steering config dynamicCosmin Ratiu
Only create PSP steering tables when PSP configuration is enabled on a PSP device. Previously, mlx5e_psp_set_config (== .set_config on the PSP device) did nothing. Steering was created and hooked up to incoming traffic at device initialization time, via mlx5e_init_nic_rx -> mlx5e_accel_init_rx -> mlx5_accel_psp_fs_init_rx_tables. Similarly, TX tables were created and hooked to egress traffic at mlx5e_init_nic_tx -> mlx5e_accel_init_tx -> mlx5_accel_psp_fs_init_tx_tables Doing this means both ingress and egress UDP packets go through the PSP steering tables, causing extra latency and overhead. A better solution is to let the incoming encrypted PSP packets get dropped by SW and not impose an overhead on all UDP packets which have to traverse the PSP steering rules when PSP isn't used. Additionally, upcoming changes to support HW-GRO need to reconfigure PSP steering dynamically and this patch is a necessary step in that direction. Two new functions are defined: - accel_psp_fs_create: Creates steering tables and connects RX UDP v4/v6 traffic to PSP RX tables. - accel_psp_fs_destroy: Disconnects incoming RX traffic from PSP steering and destroys steering tables. PSP steering cleanup, which happens independently from PSP device configuration, is unchanged. When the device is going away, steering tables are destroyed as well. The netdev lock is now used for proper synchronization between the new set_config flow and device steering init/cleanup. This will be important in future patches, when PSP will be able to reconfigure itself dynamically upon netdev feature changes. Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260707130858.969928-14-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21net/mlx5e: psp: Flatten steering structuresCosmin Ratiu
PSP steering code has two dynamically allocated structures to store RX and TX steering structs. Remove those and flatten out everything into the parent mlx5e_psp_fs. The tx_counter was moved out of the TX table as well, because the table doesn't own it, it outlives TX table destruction. All table creation/destruction now happens in accel_psp_fs_{rx,tx}_{create,destroy}. This will be used in subsequent patches to make PSP configuration dynamic. Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260707130858.969928-13-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21net/mlx5e: psp: Use a single rx_check tableCosmin Ratiu
PSP uses a check steering table per IP version, but the PSP rules are IP-version agnostic, so there's no point duplicating these in HW. This commit makes the rx check steering table independent of the IP version, with the final table added in the previous patch responsible for directing packets to the corresponding UDP TIRs (or the TTC table itself for non-UDP traffic). Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260707130858.969928-12-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21net/mlx5e: psp: Add an RX steering tableCosmin Ratiu
Successfully decrypted PSP traffic is currently forwarded to the UDP v4/v6 TTC default destination from its respective PSP rx_check table. In preparation for flattening out RX steering and for decapsulation support (which needs to handle non-UDP traffic as well), add an RX table which directs traffic to either the UDP v4/v6 default TTC destinations, or back to the TTC table itself for further processing. There can be no loops as non-UDP traffic will not go through PSP processing again. This is now used as a destination for successfully decrypted PSP packets. The rx_counter is also incremented there, freeing the rx_check rule for PSP_OK for atomic destination update in a future patch. Use this opportunity to separate RX flow table levels from IPsec, as reusing random IPsec ft levels as PSP isn't clear and now is a good opportunity to separate them. Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260707130858.969928-11-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21net/mlx5e: psp: Adjust rx_check FT size and use a drop_groupCosmin Ratiu
The rx_check ft was requesting max_fte == 2, but it created 4 entries. While this accidentally works, it's not accurate, so change that and use the correct number of entries. Also use an explicit drop_group for the last match(*) drop rule. Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260707130858.969928-10-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21net/mlx5e: psp: Rename and consolidate steering functionsCosmin Ratiu
There are multiple naming inconsistencies and the code is fragmented and hard to follow. For example, the PSP TX steering structure is named 'mlx5e_psp_tx', but its RX counterpart is 'mlx5e_accel_fs_psp' and its protocol instantiation 'mlx5e_accel_fs_psp_prot', neither of which make it clear they relate to RX. This commit renames things to be more consistent, realigns declarations to abide by the xmas tree rule, and merges some functions to reduce fragmentation. Renamed: mlx5e_accel_fs_psp -> mlx5e_psp_rx mlx5e_accel_fs_psp_prot -> mlx5e_psp_rx_decrypt_table fs_prot -> decrypt accel_psp -> rx_fs mlx5e_psp_rx_err -> mlx5e_psp_rx_check_table mlx5e_psp_tx -> mlx5e_psp_tx_table def_rule -> rule Also renamed many functions with names of the form accel_psp_fs_A_B_C_..._verb, with A->B->C->... following a general->specific hierarchy. Full list: accel_psp_fs_rx_err_destroy_ft -> accel_psp_fs_rx_check_ft_destroy accel_psp_fs_rx_err_create_ft -> accel_psp_fs_rx_check_ft_create accel_psp_fs_rx_fs_destroy -> accel_psp_fs_rx_decrypt_ft_destroy accel_psp_fs_rx_create_ft -> accel_psp_fs_rx_decrypt_ft_create accel_psp_fs_tx_create_ft_table -> accel_psp_fs_tx_ft_create accel_psp_fs_tx_destroy -> accel_psp_fs_tx_ft_destroy accel_psp_fs_{init,cleanup}_{rx,tx} -> accel_psp_fs_{rx,tx}_{init,cleanup} Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260707130858.969928-9-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21net/mlx5e: psp: Remove unused PSP syndrome copy actionCosmin Ratiu
The PSP error flow table copies the HW syndrome to metadata register B, but this value is never used in the RX path. Bad packets (auth fail, bad trailer) are dropped by HW via explicit drop rules before reaching software. Remove the syndrome copy action, the syndrome macro, and the dead syndrome check in the RX handler. Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260707130858.969928-8-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21net/mlx5e: psp: Factor out drop rule creation codeCosmin Ratiu
There are 3 rules added with the same structure. Factor out common code into a helper function to reduce duplication. Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260707130858.969928-7-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21net/mlx5e: psp: Use helpers for steering object manipulationCosmin Ratiu
Add helper functions for creating and destroying PSP steering objects to reduce code duplication. This will become more relevant in future patches which add more steering tables/groups/flows. One nice side-effect of this is that the cleanup functions become idempotent and can be used instead of long goto chains. This further simplifies the code. Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260707130858.969928-6-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21net/mlx5e: psp: Merge rx_err rule add/delete with ft create/deleteCosmin Ratiu
The rx_err table is different than the others, having separate functions to create the flow rules in addition to the flow table. Merge the add/delete rules functions with the ft create/delete functions for consistency. Noop change. Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260707130858.969928-5-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21net/mlx5e: psp: Remove unneeded ref counting for PSP steeringCosmin Ratiu
PSP steering uses reference counting for TX and RX steering tables, but there's only a single reference for each acquired and thus the reference counting is unnecessary. Remove it and consolidate functions to simplify the code. Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Link: https://patch.msgid.link/20260707130858.969928-4-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21net/mlx5e: psp: Remove PSP steering mutexesCosmin Ratiu
PSP steering uses three mutexes to serialize steering rule init/cleanup. But init/cleanup are already serialized with the higher level devlink lock (for both device init and esw mode changes), so there's no need for multiple additional mutexes. Remove them to make room for the new changes. Later in the series, the netdev lock will be used to serialize PSP steering changes from multiple sources, so don't bother adding assertions now only for them to be overwritten later. Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Link: https://patch.msgid.link/20260707130858.969928-3-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21net/mlx5e: psp: Rename the saved psp_dev to 'psd'Cosmin Ratiu
This is the canonical name used in the core, so try to be consistent. No-op change. Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Link: https://patch.msgid.link/20260707130858.969928-2-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21ACPI: EC: Avoid _REG disconnect on GPIO IRQ deferZhu Ling
EC event delivery uses either a GPE or, on ACPI reduced hardware platforms, a GpioInt resource. The GPE path does not have a provider lookup that can defer, but acpi_dev_gpio_irq_get() can return -EPROBE_DEFER for the GpioInt path. ec_install_handlers() currently installs the EC address space handler and executes _REG before looking up the GPIO IRQ. If the GPIO lookup then defers, acpi_ec_setup() tears the handlers down again. Removing the EC address space handler causes ACPICA to execute _REG for disconnect, so firmware may observe an EC OpRegion connected -> disconnected transition during one failed probe attempt. This is observable when the namespace EC reuses a boot EC that has already installed the EC address space handler. A deferred namespace EC probe can disconnect the already usable boot EC OpRegion until a later reprobe connects it again. AML that gates EC field accesses on _REG state can then return fallback values to other drivers during that window. Prepare the GPIOInt IRQ before publishing EC OpRegion availability to AML. This leaves the GPE path unchanged, keeps non-deferred GPIO lookup errors non-fatal as before, and still lets the existing acpi_ec_setup() error path clean up real handler installation failures. Fixes: f6484cadbcaf ("ACPI: EC: clean up handlers on probe failure in acpi_ec_setup()") Signed-off-by: Zhu Ling <zhuling2709@phytium.com.cn> [ rjw: Added an empty code line after a conditional ] Link: https://patch.msgid.link/20260715012556.12043-1-zhuling2709@phytium.com.cn Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-07-21platform/x86: thinkpad_acpi: Convert to use acpi_dev_is_video_device() helperAndy Shevchenko
Replace open coded variant of acpi_dev_is_video_device() helper. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://patch.msgid.link/20260714185915.865396-7-andriy.shevchenko@linux.intel.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-07-21PCI/VGA: Convert to use acpi_dev_is_video_device() helperAndy Shevchenko
Replace open coded variant of acpi_dev_is_video_device() helper. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20260714185915.865396-6-andriy.shevchenko@linux.intel.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-07-21i2c: acpi: Convert to use acpi_dev_is_video_device() helperAndy Shevchenko
Replace open coded variant of acpi_dev_is_video_device() helper. Acked-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20260714185915.865396-5-andriy.shevchenko@linux.intel.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-07-21ACPI: video: Convert to use acpi_dev_is_video_device() helperAndy Shevchenko
Replace open coded variant of acpi_dev_is_video_device() helper. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20260714185915.865396-4-andriy.shevchenko@linux.intel.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-07-21ACPI: scan: Convert to use acpi_dev_is_video_device() helperAndy Shevchenko
Replace open coded variant of acpi_dev_is_video_device() helper. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20260714185915.865396-3-andriy.shevchenko@linux.intel.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-07-21ACPI: utils: Introduce acpi_dev_is_video_device() helperAndy Shevchenko
There are a couple of users that open code functionality of matching a given handle against ACPI video device IDs. The current approach duplicates ID table along with the matching code. Consolidate it under the acpi_dev_is_video_device() helper's hood. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> [ rjw: Moved the static var declaration into the function body ] Link: https://patch.msgid.link/20260714185915.865396-2-andriy.shevchenko@linux.intel.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-07-21ACPI: battery: Sanitise model_number by dropping unprintable charactersKate Hsuan
The battery Embedded Controller (EC) may return the model name with trailing unprintable or non-ASCII characters. For example, on some systems: $ cat /sys/class/power_supply/BAT0/model_name LNV-5B10W51864�� If a non-ASCII or an unprintable character is found, it will be replaced with '\0' to ensure the model_number is a valid string. If left intact, the malformed string prevents udev rules and hwdb working correctly. Link: https://gitlab.freedesktop.org/upower/upower/-/work_items/345 Signed-off-by: Kate Hsuan <hpa@redhat.com> Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca> [ rjw: Subject tweak ] Link: https://patch.msgid.link/20260710125122.1621877-1-hpa@redhat.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-07-21pds_core: reject component parameter in legacy firmware updateNikhil P. Rao
The legacy firmware update path does not support per-component updates. If a user specifies a component parameter with devlink flash, reject the request with -EOPNOTSUPP rather than silently ignoring the component parameter and flashing the entire firmware image. Fixes: 49ce92fbee0b ("pds_core: add FW update feature to devlink") Signed-off-by: Nikhil P. Rao <nikhil.rao@amd.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260708163649.128620-1-nikhil.rao@amd.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-21RDMA/nldev: validate dynamic counter attribute lengthPengpeng Hou
RDMA_NLDEV_ATTR_STAT_HWCOUNTERS is a nested attribute whose children are consumed directly with nla_get_u32(). The top-level policy validates only the container, so it does not establish the fixed shape of each child. Require every child payload to be exactly one u32 before reading it. Fixes: 3c3c1f141639 ("RDMA/nldev: Allow optional-counter status configuration through RDMA netlink") Reviewed-by: Zhu Yanjun <yanjun.zhu@linux.dev> Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> Link: https://patch.msgid.link/20260720114918.70323-1-pengpeng@iscas.ac.cn Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-07-21USB: serial: option: add TDTECH MT5710-CNChukun Pan
Add support for the TDTECH MT5710-CN (5G redcap) module based on the Huawei HiSilicon Balong chip. T: Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=3466 ProdID=3301 Rev=ff.ff S: Manufacturer=TD Tech Ltd. S: Product=TDTECH MT571X S: SerialNumber=0123456789ABCDEF C:* #Ifs= 6 Cfg#= 1 Atr=c0 MxPwr= 0mA A: FirstIf#= 0 IfCount= 2 Cls=02(comm.) Sub=0d Prot=00 I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0d Prot=00 Driver=cdc_ncm E: Ad=82(I) Atr=03(Int.) MxPS= 16 Ivl=32ms I: If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=01 Driver=cdc_ncm I:* If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=01 Driver=cdc_ncm E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=06 Prot=13 Driver=option E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=06 Prot=12 Driver=option E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=06 Prot=1c Driver=option E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=06 Prot=14 Driver=option E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms Interface: ECM / NCM + DIAG + AT + SERIAL + GPS Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn> Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold <johan@kernel.org>
2026-07-21drm/vc4: Prevent shader BO mappings from becoming writableLinmao Li
vc4_gem_object_mmap() rejects a writable mapping of a validated shader BO, but leaves VM_MAYWRITE set. Userspace can map the BO read-only and then turn it writable with mprotect(). Validated shader BOs must stay read-only: the validator checks the instructions once and the GPU trusts them afterwards. A writable mapping lets userspace rewrite the code after validation, bypassing the validator. Clear VM_MAYWRITE on the read-only path so the mapping cannot be upgraded, as i915 already does for its read-only objects. Fixes: 463873d57014 ("drm/vc4: Add an API for creating GPU shaders in GEM BOs.") Cc: stable@vger.kernel.org Reported-by: Sashiko <sashiko-bot@kernel.org> Closes: https://lore.kernel.org/dri-devel/20260720085554.B0AF01F000E9@smtp.kernel.org/ Signed-off-by: Linmao Li <lilinmao@kylinos.cn> Link: https://patch.msgid.link/20260721011558.1672477-1-lilinmao@kylinos.cn Reviewed-by: Maíra Canal <mcanal@igalia.com> Signed-off-by: Maíra Canal <mcanal@igalia.com>
2026-07-21ACPI: FPDT: validate table and record lengthsPengpeng Hou
FPDT records are supplied by firmware and are walked through length fields stored in the table itself. Check the main-table entry length before reading an entry, check the mapped subtable length before remapping it, and check each record length before saving a typed record pointer for sysfs. This keeps malformed firmware records from being interpreted as complete resume, suspend, or boot records when the current item is shorter than the structure consumed by the driver. Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> Link: https://patch.msgid.link/20260706094141.82438-1-pengpeng@iscas.ac.cn Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-07-21ACPI: NVS: replace __get_free_page() with kmalloc()Mike Rapoport (Microsoft)
suspend_nvs_alloc() allocates shadow pages for saving and restoring ACPI Non-Volatile Storage regions across suspend/resume. These buffers can be allocated with kmalloc() as there's nothing special about them to go directly to the page allocator. kmalloc() provides a better API that does not require ugly casts and kfree() does not need to know the size of the freed object. Performance difference between kmalloc() and __get_free_pages() is not measurable as both allocators take an object/page from a per-CPU list for fast path allocations. For the slow path the performance is anyway determined by the amount of reclaim involved rather than by what allocator is used. Replace use of __get_free_page() with kmalloc() and free_page() with kfree(). Link: https://lore.kernel.org/all/635405e4-9423-4a25-a6e7-e03c8ea0bcbe@redhat.com Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Link: https://patch.msgid.link/20260630-b4-acpi-v1-1-a9f59c04d221@kernel.org Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-07-21Merge tag 'iwlwifi-fixes-2026-07-21' of ↵Johannes Berg
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next Miri Korenblit says: ==================== wifi: iwlwif: fixes - 2026-07-21 This PR contains quite a few fixes, mostly found by LLMs. Notably: - missing validation of TLVs length - missing validation on the revision of BIOS tables - missing validation of fw responses length - protect against double free of RX pointers - avoid double deregistration of the tzone core - validate fields in FW responses before using them - fix off-by-one in WLAN_EID_EXT_CAPABILITY parsing - Add missing support for UNII-9 ==================== Signed-off-by: Johannes Berg <johannes.berg@intel.com>