summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2026-07-21net: txgbe: fix heap overflow when reading module EEPROMChenguang Zhao
txgbe_read_eeprom_hostif() always copies round_up(length, 4) bytes into the caller buffer, which ethtool allocates with exactly 'length' bytes. A non-4-aligned length therefore causes an out-of-bounds write. Copy only the remaining bytes on the final dword instead. Signed-off-by: Chenguang Zhao <zhaochenguang@kylinos.cn> Reviewed-by: Jiawen Wu <jiawenwu@trustnetic.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Fixes: 9b97b6b5635b ("net: txgbe: support getting module EEPROM by page") Link: https://patch.msgid.link/20260713085111.1481884-1-chenguang.zhao@linux.dev Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21rtase: Workaround for TX hang caused by hardware packet parsingJustin Lai
The hardware performs packet parsing before packet transmission. Parsing incomplete IPv4, IPv6, TCP, or UDP headers may trigger a TX hang because the hardware parser expects additional protocol header data that is not present in the packet. The hardware performs additional PTP parsing on UDP packets identified by destination ports 319/320 at the expected UDP destination port offset. If such a packet has transport data smaller than RTASE_MIN_PAD_LEN, the hardware parser expects additional packet data and may trigger a TX hang. To avoid these hardware issues, the driver applies the following workarounds. Drop malformed packets that may trigger this hardware issue before transmission. For IPv4 non-initial fragments, the hardware does not check the fragment offset before parsing the expected transport header location. As a result, these packets are still subject to transport header parsing even though they do not contain a transport header. If the transport data is shorter than the minimum transport header required by the hardware parser, pad the transport data to the minimum transport header length required by the hardware parser. Packets that also match the hardware PTP parsing conditions continue to follow the corresponding workaround. For IPv6 fragmented packets, neither of the above hardware issues occurs because the hardware only continues packet parsing when the IPv6 Base Header Next Header field directly indicates UDP. Packets carrying a Fragment Header do not continue through the subsequent packet parsing stages. For packets identified for hardware PTP parsing, pad the transport data so it reaches RTASE_MIN_PAD_LEN before transmission. Fixes: d6e882b89fdf ("rtase: Implement .ndo_start_xmit function") Cc: stable@vger.kernel.org Signed-off-by: Justin Lai <justinlai0215@realtek.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260709103456.83789-1-justinlai0215@realtek.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21net: dsa: yt921x: Fix external port detectionChukun Pan
The YT921x switch has two MAC ports: 8 and 9. Currently, the driver only allows port 8 as an external port, while port 9 is not working: yt921x mdio-bus:1d: Wrong mode 23 on port 9 yt921x mdio-bus:1d: Failed to config port 9: -22 Update the external port detection logic to enable the external PHY connected to port 9. Cc: stable+noautosel@kernel.org # never worked Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn> Link: https://patch.msgid.link/20260710100000.3018614-1-amadeus@jmu.edu.cn Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21net: hibmcge: fix double-free of tx skb on DMA mapping failureXuanqiang Luo
If hbg_dma_map() fails, hbg_net_start_xmit() frees the skb, but buffer->skb is left pointing to it. ring->ntu is not advanced, so the buffer is not visible to the TX cleanup path. A subsequent transmit normally overwrites the buffer. However, if the interface is brought down first, hbg_ring_uninit() calls hbg_buffer_free(). It sees the stale pointer, attempts to unmap the failed mapping, and frees the skb again. Clear buffer->skb before freeing the skb in the error path, preventing hbg_buffer_free() from treating it as an outstanding TX buffer. Cc: stable+noautosel@kernel.org # untested fix to unlikely driver error path Signed-off-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn> Reviewed-by: Jijie Shao <shaojijie@huawei.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260710090527.58354-4-xuanqiang.luo@linux.dev Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21hinic3: fix use-after-free on DMA mapping failureXuanqiang Luo
If hinic3_tx_map_skb() fails in hinic3_send_one_skb(), the skb is freed, but tx_info->skb was set before the mapping attempt and is not cleared. The SQ producer index is rolled back, so later transmissions normally overwrite the entry. If the interface is brought down first, hinic3_free_txqs_res() calls free_all_tx_skbs(). It scans the entire tx_info array and finds the stale pointer. hinic3_tx_unmap_skb() then dereferences the freed skb in skb_shinfo(), before it is freed again. Set tx_info->skb and its WQEBB count only after DMA mapping succeeds, preventing the stale pointer from reaching free_all_tx_skbs(). Cc: stable+noautosel@kernel.org # untested fix to unlikely driver error path Signed-off-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn> Reviewed-by: Fan Gong <gongfan1@huawei.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260710090527.58354-3-xuanqiang.luo@linux.dev Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21bna: fix use-after-free on DMA mapping failureXuanqiang Luo
If dma_map_single() fails in bnad_start_xmit(), the skb is freed, but head_unmap->skb was set before the mapping attempt and is not cleared. The producer index is not advanced, so later transmissions normally overwrite the entry. However, if the interface is brought down first, bnad_txq_cleanup() scans the entire unmap queue, finds the stale pointer, and calls bnad_tx_buff_unmap() on it. That function dereferences the freed skb in skb_headlen(). Its zero nvecs count is decremented to -1, causing its while (nvecs) loop to repeatedly unmap entries around the TX ring and potentially hang cleanup. Set head_unmap->skb after the first DMA mapping succeeds. This prevents the stale entry from reaching bnad_tx_buff_unmap(). Cc: stable+noautosel@kernel.org # untested fix to unlikely error path Signed-off-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260710090527.58354-2-xuanqiang.luo@linux.dev Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21net: mvneta: bm: fix device reference leak on failed lookupJohan Hovold
Make sure to drop the reference taken to the buffer manager device when attempting to look up its driver data before the driver has been bound. Note that holding a reference to a device does not prevent its driver data from going away. Cc: stable+noautosel@kernel.org # untested fix to unlikely error path Cc: Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Harshitha Ramamurthy <hramamurthy@google.com> Link: https://patch.msgid.link/20260709082713.829446-1-johan@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21drm/i915/bw: Fix spelling mistake "threshod" -> "threshold"Colin Ian King
There is a spelling mistake in a drm_dbg_kms message. Fix it. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Link: https://patch.msgid.link/20260720161630.326016-1-colin.i.king@gmail.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-07-21geneve: ensure the skb is writable before fixing its headersAntoine Tenart
Make sure the IPv4/6 and UDP headers are writable before fixing them up in geneve_post_decap_hint. As skb_ensure_writable can reallocate the skb linear area, reload the GRO hint header pointer and only set the IPv4/6 header ones after the call. Fixes: fd0dd796576e ("geneve: use GRO hint option in the RX path") Reported-by: Sashiko <sashiko-bot@kernel.org> Closes: https://sashiko.dev/#/patchset/20260529144713.780938-1-atenart%40kernel.org Signed-off-by: Antoine Tenart <atenart@kernel.org> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260709125000.141092-1-atenart@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21Merge tag 'mm81x-driver-08-07-2026' of https://github.com/MorseMicro/linuxJohannes Berg
Lachlan Hodges says: ==================== Introduce mm81x driver for mm81x based chipsets plus associated SDIO ids. ==================== [list the full vendor directory in MAINTAINERS] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-07-21geneve: fix hint header definition wrt endiannessAntoine Tenart
Bitfields are packed differently depending on the endianness, take it into account in the GRO hint header definition. Fixes: e0a12cbf262b ("geneve: add GRO hint output path") Reported-by: Sashiko <sashiko-bot@kernel.org> Closes: https://sashiko.dev/#/patchset/20260529144713.780938-1-atenart%40kernel.org Signed-off-by: Antoine Tenart <atenart@kernel.org> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260709124801.140632-1-atenart@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21wifi: brcmfmac: set F2 blocksize to 256 for BCM43752LiangCheng Wang
The BCM43752 is not reliable with the default 512-byte SDIO function 2 block size: on an i.MX8MP board with an AMPAK AP6275S module at SDR104 / 200 MHz, an iperf TX stress test kills WLAN within seconds: mmc_submit_one: CMD53 sg block write failed -84 brcmf_sdio_dpc: failed backplane access over SDIO, halting operation Commit d2587c57ffd8 ("brcmfmac: add 43752 SDIO ids and initialization") set up the 43752 like the 4373 for the F2 watermark but missed the F2 block size, which the 4373 limits to 256 bytes. The vendor driver (bcmdhd) also programs a 256-byte F2 block size for this chip and runs the same hardware without errors. Group the 43752 with the 4373, matching the F2 watermark handling. With this change a 10-minute bidirectional iperf3 soak completes with zero SDIO errors at ~270 Mbit/s in each direction. Backporting note: kernels before v6.18 name this id SDIO_DEVICE_ID_BROADCOM_CYPRESS_43752, so on those trees the case label added by this patch must be adjusted to that name. Cherry-picking the rename commit 74e2ef72bd4b ("wifi: brcmfmac: fix 43752 SDIO FWVID incorrectly labelled as Cypress (CYW)") first is not a clean alternative: on trees before v6.17 its context collides with the 43751 additions, and trees before v6.2 lack the FWVID framework it touches. Fixes: d2587c57ffd8 ("brcmfmac: add 43752 SDIO ids and initialization") Cc: stable@vger.kernel.org # see patch description, needs adjustments for <= 6.17 Signed-off-by: LiangCheng Wang <zaq14760@gmail.com> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20260715-b43752-f2-blksz-v2-1-f9be49856050@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-07-21platform/x86: acer-wmi: reject missing gaming WMI resultsYousef Alhouseen
WMI_gaming_execute_u32_u64() returns success when firmware supplies no output object, leaving the caller output untouched. Gaming getters then inspect an uninitialized result value. When the caller requests an output value, return -ENOMSG if firmware supplies no object. Preserve a NULL output pointer as the supported way for callers to ignore the result. Fixes: 2d76708c2221 ("platform/x86: acer-wmi: use WMI calls for platform profile handling") Signed-off-by: Yousef Alhouseen <alhouseenyousef@gmail.com> Link: https://patch.msgid.link/20260701164208.8998-1-alhouseenyousef@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-21platform/x86/intel/pmc: initialize empty PMT read resultYousef Alhouseen
pmc_core_pmt_get_lpm_req() returns the last telemetry read status. When firmware exposes no enabled low-power modes, the loop does not run and the function returns an uninitialized stack value. Initialize the status to success so an empty mode set is handled deterministically. Signed-off-by: Yousef Alhouseen <alhouseenyousef@gmail.com> Reviewed-by: David E. Box <david.e.box@linux.intel.com> Link: https://patch.msgid.link/20260630105101.54016-1-alhouseenyousef@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-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>
generated by cgit v1.2.3 (git 2.39.1) at 2026-09-18 20:41:38 +0000