summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2026-04-08PCI: tegra194: Use DWC IP core versionManikanta Maddireddy
Tegra194 PCIe driver used custom version numbers to detect Tegra194 and Tegra234 IPs. With version detect logic added, version check results in mismatch warnings: tegra194-pcie 14100000.pcie: Versions don't match (0000562a != 3536322a) Use HW version numbers which match to PORT_LOGIC.PCIE_VERSION_OFF in Tegra194 driver to avoid these kernel warnings. Fixes: a54e19073718 ("PCI: tegra194: Add Tegra234 PCIe support") Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Vidya Sagar <vidyas@nvidia.com> Link: https://patch.msgid.link/20260324190755.1094879-12-mmaddireddy@nvidia.com
2026-04-08PCI: tegra194: Free up Endpoint resources during remove()Vidya Sagar
Free up the resources during remove() that were acquired by the DesignWare driver for the Endpoint mode during probe(). Fixes: bb617cbd8151 ("PCI: tegra194: Clean up the exit path for Endpoint mode") Signed-off-by: Vidya Sagar <vidyas@nvidia.com> Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Vidya Sagar <vidyas@nvidia.com> Link: https://patch.msgid.link/20260324190755.1094879-11-mmaddireddy@nvidia.com
2026-04-08PCI: tegra194: Allow system suspend when the Endpoint link is not upVidya Sagar
Host software initiates the L2 sequence. PCIe link is kept in L2 state during suspend. If Endpoint mode is enabled and the link is up, the software cannot proceed with suspend. However, when the PCIe Endpoint driver is probed, but the PCIe link is not up, Tegra can go into suspend state. So, allow system to suspend in this case. Fixes: de2bbf2b71bb ("PCI: tegra194: Don't allow suspend when Tegra PCIe is in EP mode") Signed-off-by: Vidya Sagar <vidyas@nvidia.com> Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Vidya Sagar <vidyas@nvidia.com> Link: https://patch.msgid.link/20260324190755.1094879-10-mmaddireddy@nvidia.com
2026-04-08PCI: tegra194: Set LTR message request before PCIe link up in Endpoint modeVidya Sagar
LTR message should be sent as soon as the Root Port enables LTR in the Endpoint mode. So set snoop and no-snoop LTR timing and LTR message request before the PCIe link comes up, so that the LTR message is sent upstream as soon as LTR is enabled. Without programming these values, the Endpoint would send latencies of 0 to the host, which will be inaccurate. Fixes: c57247f940e8 ("PCI: tegra: Add support for PCIe endpoint mode in Tegra194") Signed-off-by: Vidya Sagar <vidyas@nvidia.com> Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com> [mani: commit log] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Link: https://patch.msgid.link/20260324190755.1094879-9-mmaddireddy@nvidia.com
2026-04-08PCI: tegra194: Disable direct speed change for Endpoint modeVidya Sagar
Pre-silicon simulation showed the controller operating in Endpoint mode initiating link speed change after completing Secondary Bus Reset. Ideally, the Root Port or the Switch Downstream Port should initiate the link speed change post SBR, not the Endpoint. So, as per the hardware team recommendation, disable direct speed change for the Endpoint mode to prevent it from initiating speed change after the physical layer link is up at Gen1, leaving speed change ownership with the host. Fixes: c57247f940e8 ("PCI: tegra: Add support for PCIe endpoint mode in Tegra194") Signed-off-by: Vidya Sagar <vidyas@nvidia.com> Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com> [mani: commit log] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Vidya Sagar <vidyas@nvidia.com> Link: https://patch.msgid.link/20260324190755.1094879-8-mmaddireddy@nvidia.com
2026-04-08PCI: tegra194: Use devm_gpiod_get_optional() to parse "nvidia,refclk-select"Vidya Sagar
The GPIO DT property "nvidia,refclk-select", to select the PCIe reference clock is optional. Use devm_gpiod_get_optional() to get it. Fixes: c57247f940e8 ("PCI: tegra: Add support for PCIe endpoint mode in Tegra194") Signed-off-by: Vidya Sagar <vidyas@nvidia.com> Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Vidya Sagar <vidyas@nvidia.com> Link: https://patch.msgid.link/20260324190755.1094879-7-mmaddireddy@nvidia.com
2026-04-08PCI: tegra194: Disable PERST# IRQ only in Endpoint modeManikanta Maddireddy
The PERST# GPIO interrupt is only registered when the controller is operating in Endpoint mode. In Root Port mode, the PERST# GPIO is configured as an output to control downstream devices, and no interrupt is registered for it. Currently, tegra_pcie_dw_stop_link() unconditionally calls disable_irq() on pex_rst_irq, which causes issues in Root Port mode where this IRQ is not registered. Fix this by only disabling the PERST# IRQ when operating in Endpoint mode, where the interrupt is actually registered and used to detect PERST# assertion/deassertion from the host. Fixes: c57247f940e8 ("PCI: tegra: Add support for PCIe endpoint mode in Tegra194") Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Vidya Sagar <vidyas@nvidia.com> Link: https://patch.msgid.link/20260324190755.1094879-6-mmaddireddy@nvidia.com
2026-04-08PCI: tegra194: Don't force the device into the D0 state before L2Vidya Sagar
As per PCIe CEM r6.0, sec 2.3, the PCIe Endpoint device should be in D3cold to assert WAKE# pin. The previous workaround that forced downstream devices to D0 before taking the link to L2 cited PCIe r4.0, sec 5.2, "Link State Power Management"; however, that spec does not explicitly require putting the device into D0 and only indicates that power removal may be initiated without transitioning to D3hot. Remove the D0 workaround so that Endpoint devices can use wake functionality (WAKE# from D3). With some Endpoints the link may not enter L2 when they remain in D3, but the Root Port continues with the usual flow after PME timeout, so there is no functional issue. Fixes: 56e15a238d92 ("PCI: tegra: Add Tegra194 PCIe support") Signed-off-by: Vidya Sagar <vidyas@nvidia.com> Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Vidya Sagar <vidyas@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Link: https://patch.msgid.link/20260324190755.1094879-5-mmaddireddy@nvidia.com
2026-04-08PCI: tegra194: Disable LTSSM after transition to Detect on surprise link downManikanta Maddireddy
After the link reaches a Detect-related LTSSM state, disable LTSSM so it does not keep toggling between Polling and Detect. Do this by polling for the Detect state first, then clearing APPL_CTRL_LTSSM_EN in both tegra_pcie_dw_pme_turnoff() and pex_ep_event_pex_rst_assert(). Fixes: 56e15a238d92 ("PCI: tegra: Add Tegra194 PCIe support") Signed-off-by: Vidya Sagar <vidyas@nvidia.com> Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Link: https://patch.msgid.link/20260324190755.1094879-4-mmaddireddy@nvidia.com
2026-04-09Merge tag 'drm-rust-next-2026-04-06' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/rust/kernel into drm-next DRM Rust changes for v7.1-rc1 (2nd) Nova (Core): - Don't create intermediate (mutable) references to the whole command queue buffer, which is potential undefined behavior. - Add missing padding to the falcon firmware DMA buffer to prevent DMA transfers going out of range of the DMA buffer. - Actually set the default values in the bitfield Default implementation. - Use u32::from_le_bytes() instead of manual bit shifts to parse the PCI ROM header. - Fix a missing colon in the SEC2 boot debug message. Signed-off-by: Dave Airlie <airlied@redhat.com> From: "Danilo Krummrich" <dakr@kernel.org> Link: https://patch.msgid.link/DHN5GMSIBKO2.2AYOLXDU4X19S@kernel.org
2026-04-08Merge tag 'hid-for-linus-2026040801' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid Pull HID fixes from Jiri Kosina: - handling of new keycodes for contextual AI usages (Akshai Murari) - fix for UAF in hid-roccat (Benoît Sevens) - deduplication of error logging in amd_sfh (Maximilian Pezzullo) - various device-specific quirks and device ID additions (Even Xu, Lode Willems, Leo Vriska) * tag 'hid-for-linus-2026040801' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid: Input: add keycodes for contextual AI usages (HUTRR119) HID: Kysona: Add support for VXE Dragonfly R1 Pro HID: amd_sfh: don't log error when device discovery fails with -EOPNOTSUPP HID: quirks: add HID_QUIRK_ALWAYS_POLL for 8BitDo Pro 3 HID: roccat: fix use-after-free in roccat_report_event HID: Intel-thc-hid: Intel-quickspi: Add NVL Device IDs HID: Intel-thc-hid: Intel-quicki2c: Add NVL Device IDs
2026-04-08PCI: tegra194: Increase LTSSM poll time on surprise link downManikanta Maddireddy
On surprise link down, LTSSM state transits from L0 -> Recovery.RcvrLock -> Recovery.RcvrSpeed -> Gen1 Recovery.RcvrLock -> Detect. Recovery.RcvrLock and Recovery.RcvrSpeed transit times are 24 ms and 48 ms respectively, so the total time from L0 to Detect is ~96 ms. Increase the poll timeout to 120 ms to account for this. While at it, add LTSSM state defines for Detect-related states and use them in the poll condition. Use readl_poll_timeout() instead of readl_poll_timeout_atomic() in tegra_pcie_dw_pme_turnoff() since that path runs in non-atomic context. Fixes: 56e15a238d92 ("PCI: tegra: Add Tegra194 PCIe support") Signed-off-by: Vidya Sagar <vidyas@nvidia.com> Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Link: https://patch.msgid.link/20260324190755.1094879-3-mmaddireddy@nvidia.com
2026-04-08PCI: tegra194: Fix polling delay for L2 stateVidya Sagar
As per PCIe r7.0, sec 5.3.3.2.1, after sending PME_Turn_Off message, Root Port should wait for 1-10 msec for PME_TO_Ack message. Currently, driver is polling for 10 msec with 1 usec delay which is aggressive. Use existing macro PCIE_PME_TO_L2_TIMEOUT_US to poll for 10 msec with 1 msec delay. Since this function is used in non-atomic context only, use non-atomic poll function. Fixes: 56e15a238d92 ("PCI: tegra: Add Tegra194 PCIe support") Signed-off-by: Vidya Sagar <vidyas@nvidia.com> Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Link: https://patch.msgid.link/20260324190755.1094879-2-mmaddireddy@nvidia.com
2026-04-08bpf: Add fix for Trust Philips SPK6327 (145f:024b) modifier keysmuhammed Rishal
The Trust Philips SPK6327 keyboard (USB ID 145f:024b) has a broken HID descriptor on interface 1. Byte 101 is 0x00 (Input Array) but should be 0x02 (Input Variable), causing LCtrl, LAlt, Super, RAlt, RCtrl and RShift to all report as LShift on Linux. This BPF fix patches byte 101 at runtime fixing all affected modifier keys. Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/234 Signed-off-by: muhammed Rishal <muhammedrishal7777777@gmail.com> Signed-off-by: Benjamin Tissoires <bentiss@kernel.org> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-04-08HID: bpf: Add support for the Huion KeyDial K20 over bluetoothBenjamin Tissoires
When connected over bluetooth this device is just different enough that forcing it into the same source file as the USB connection doesn't gain us much benefit. So let's duplicate this. Code and tests originally produced by Claude code. Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/work_items/69 Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/201 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by: Benjamin Tissoires <bentiss@kernel.org> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-04-08HID: bpf: add a BPF to get the touchpad typeBenjamin Tissoires
Currently the kernel is scheduled to do this call by itself, but it requires a kernel v6.18 at least to have the INPUT_PROP set. For older kernels, we can try to query the property from a HID-BPF probe, and set a udev property based on that. This way we can provide the information to old kernels without modifying them. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com> Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/220 Signed-off-by: Benjamin Tissoires <bentiss@kernel.org> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-04-08hid: bpf: hid_bpf_helpers: add helper for having read/write udev propertiesBenjamin Tissoires
We want udev-hid-bpf to be able to set udev properties by printing them out after the BPF object has been loaded. This allows to make a query to the device, and set a udev prop based on the answer. Because the way udev works, the properties are cleared on bind/unbind, and we need a way to store them. After several attempts to keep the property alive without re-running the udev-hid-bpf tool to communicate with the device, it came out that HID-BPF maps are pinned in the bpffs and we can then query them. So the following would export a UDEV property in the bpffs: EXPORT_UDEV_PROP(HID_FOO, 32); SEC("syscall") int probe(struct hid_bpf_probe_args *ctx) { const char *foo = "foo"; UDEV_PROP_SPRINTF(HID_FOO, "%s", foo); return 0; } Then, we can debug it with a simple cat: sudo cat /sys/fs/bpf/hid/.../UDEV_PROP_HID_FOO 0: {['f','o','o',],} This way, the property is always accessible without talking to the device Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/220 Signed-off-by: Benjamin Tissoires <bentiss@kernel.org> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-04-08HID: bpf: handle injected report descriptor in HID-BPFBenjamin Tissoires
udev-hid-bpf is now capable of injecting the parsed report descriptor in the program. Provide the macros required for it. Sync up from udev-hid-bpf commits: bpf: inject the parsed report descriptor in HID_REPORT_DESCRIPTOR hid_bpf_helpers: provide iterator macros for walking the HID report descriptor hid_bpf_helpers: Add extract_bits function bpf: add hid_usages.h bpf: move the report descriptor structs into their own header Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/221 Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/228 Signed-off-by: Benjamin Tissoires <bentiss@kernel.org> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-04-08HID: bpf: add helper macros for LE/BE conversionPeter Hutterer
BPF has bpf_htons and friends but those only work with data in Big Endian format. HID is little endian so we need our own macros. Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/221 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by: Benjamin Tissoires <bentiss@kernel.org> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-04-08HID: bpf: hid_bpf_helpers: provide a cleanup functionsBenjamin Tissoires
Combination of 2 udev-hid-bpf commits: bpf: hid_bpf_helpers: provide a cleanup function for hid_bpf_release_context bpf: helpers: add guard(bpf_spin) macro Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/221 Signed-off-by: Benjamin Tissoires <bentiss@kernel.org> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-04-08HID: bpf: fix some signed vs unsigned compiler warningsPeter Hutterer
On udev-hid-bpf, we are now getting warnings here, shut them off. Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/227 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by: Benjamin Tissoires <bentiss@kernel.org> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-04-08selftests: pci_endpoint: Skip BAR subrange test on -ENOSPCChristian Bruel
In pci-epf-test.c, set the STATUS_NO_RESOURCE status bit if pci_epc_set_bar() returns -ENOSPC. This status bit is used to indicate that there are not enough inbound window resources to allocate the subrange. In pci_endpoint_test.c, return -ENOSPC instead of -EIO when STATUS_NO_RESOURCE is set. In pci_endpoint_test.c, skip the BAR subrange test if -ENOSPC, i.e., there are not enough inbound window resources to run the test. Signed-off-by: Christian Bruel <christian.bruel@foss.st.com> [mani: commit log] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> [bhelgaas: squash related commits] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Niklas Cassel <cassel@kernel.org> Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Koichiro Den <den@valinux.co.jp> Link: https://patch.msgid.link/20260407-skip-bar_subrange-tests-if-enospc-v4-1-6f2e65f2298c@foss.st.com Link: https://patch.msgid.link/20260407-skip-bar_subrange-tests-if-enospc-v4-2-6f2e65f2298c@foss.st.com Link: https://patch.msgid.link/20260407-skip-bar_subrange-tests-if-enospc-v4-3-6f2e65f2298c@foss.st.com
2026-04-08nvmet-tcp: remove redundant calls to nvmet_tcp_fatal_error()Maurizio Lombardi
Executing nvmet_tcp_fatal_error() is generally the responsibility of the caller (nvmet_tcp_try_recv); all other functions should just return the error code. Remove the nvmet_tcp_fatal_error() function, it's not needed anymore. Reviewed-by: Hannes Reinecke <hare@suse.de> Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com> Signed-off-by: Maurizio Lombardi <mlombard@redhat.com> Signed-off-by: Keith Busch <kbusch@kernel.org>
2026-04-08nvmet-tcp: propagate nvmet_tcp_build_pdu_iovec() errors to its callersMaurizio Lombardi
Currently, when nvmet_tcp_build_pdu_iovec() detects an out-of-bounds PDU length or offset, it triggers nvmet_tcp_fatal_error(cmd->queue) and returns early. However, because the function returns void, the callers are entirely unaware that a fatal error has occurred and that the cmd->recv_msg.msg_iter was left uninitialized. Callers such as nvmet_tcp_handle_h2c_data_pdu() proceed to blindly overwrite the queue state with queue->rcv_state = NVMET_TCP_RECV_DATA Consequently, the socket receiving loop may attempt to read incoming network data into the uninitialized iterator. Fix this by shifting the error handling responsibility to the callers. Fixes: 52a0a9854934 ("nvmet-tcp: add bounds checks in nvmet_tcp_build_pdu_iovec") Reviewed-by: Hannes Reinecke <hare@suse.de> Reviewed-by: Yunje Shin <ioerts@kookmin.ac.kr> Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com> Signed-off-by: Maurizio Lombardi <mlombard@redhat.com> Signed-off-by: Keith Busch <kbusch@kernel.org>
2026-04-08Input: uinput - take event lock when submitting FF request "event"Dmitry Torokhov
To avoid racing with FF playback events and corrupting device's event queue take event_lock spinlock when calling uinput_dev_event() when submitting a FF upload or erase "event". Tested-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com> Link: https://patch.msgid.link/adXkf6MWzlB8LA_s@google.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-04-08Input: ims-pcu - fix heap-buffer-overflow in ims_pcu_process_data()Seungjin Bae
The `ims_pcu_process_data()` processes incoming URB data byte by byte. However, it fails to check if the `read_pos` index exceeds IMS_PCU_BUF_SIZE. If a malicious USB device sends a packet larger than IMS_PCU_BUF_SIZE, `read_pos` will increment indefinitely. Moreover, since `read_pos` is located immediately after `read_buf`, the attacker can overwrite `read_pos` itself to arbitrarily control the index. This manipulated `read_pos` is subsequently used in `ims_pcu_handle_response()` to copy data into `cmd_buf`, leading to a heap buffer overflow. Specifically, an attacker can overwrite the `cmd_done.wait.head` located at offset 136 relative to `cmd_buf` in the `ims_pcu_handle_response()`. Consequently, when the driver calls `complete(&pcu->cmd_done)`, it triggers a control flow hijack by using the manipulated pointer. Fix this by adding a bounds check for `read_pos` before writing to `read_buf`. If the packet is too long, discard it, log a warning, and reset the parser state. Fixes: 628329d524743 ("Input: add IMS Passenger Control Unit driver") Co-developed-by: Sanghoon Choi <csh0052@gmail.com> Signed-off-by: Sanghoon Choi <csh0052@gmail.com> Signed-off-by: Seungjin Bae <eeodqql09@gmail.com> Link: https://patch.msgid.link/20251221211442.841549-2-eeodqql09@gmail.com [dtor: factor out resetting packet state, reset checksum as well] Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-04-08wifi: ath10k: Add device-tree quirk to skip host cap QMI requestsAmit Pundir
Some firmware versions do not support the host capability QMI request. Since this request occurs before firmware-N.bin and board-M.bin are loaded, the quirk cannot be expressed in the firmware itself. The root cause is unclear, but there appears to be a generation of firmware that lacks host capability support. Without this quirk, ath10k_qmi_host_cap_send_sync() returns QMI_ERR_MALFORMED_MSG_V01 before loading the firmware. This error is not fatal - Wi-Fi services still come up successfully if the request is simply skipped. Add a device-tree quirk to skip the host capability QMI request on devices whose firmware does not support it. For example, firmware build "QC_IMAGE_VERSION_STRING=WLAN.HL.2.0.c3-00257-QCAHLSWMTPLZ-1" on Xiaomi Poco F1 phone requires this quirk. Suggested-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Amit Pundir <amit.pundir@linaro.org> Tested-by: Paul Sajna <sajattack@postmarketos.org> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Acked-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: David Heidelberg <david@ixit.cz> Link: https://patch.msgid.link/20260407-skip-host-cam-qmi-req-v5-2-dfa8a05c6538@ixit.cz Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-04-08ACPI: AGDI: fix missing newline in error messageHaoyu Lu
Add the missing trailing newline to the dev_err() message printed when SDEI event registration fails. This keeps the error output as a properly terminated log line. Fixes: a2a591fb76e6 ("ACPI: AGDI: Add driver for Arm Generic Diagnostic Dump and Reset device") Reviewed-by: Ilkka Koskinen <ilkka@os.amperecomputing.com> Signed-off-by: Haoyu Lu <hechushiguitu666@gmail.com> Reviewed-by: Hanjun Guo <guohanjun@huawei.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2026-04-08nvme: enable PCI P2PDMA support for RDMA transportShivaji Kant
Enable BLK_FEAT_PCI_P2PDMA on the NVMe when the underlying RDMA controller supports it. Suggested-by: Pranjal Shrivastava <praan@google.com> Reviewed-by: Pranjal Shrivastava <praan@google.com> Reviewed-by: Henrique Carvalho <henrique.carvalho@suse.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Shivaji Kant <shivajikant@google.com> Signed-off-by: Keith Busch <kbusch@kernel.org>
2026-04-08nvmet: introduce new mdts configuration entryAurelien Aptel
Using this port configuration, one will be able to set the Maximum Data Transfer Size (MDTS) for any controller that will be associated to the configured port. The default value remains 0 (no limit). Signed-off-by: Max Gurtovoy <mgurtovoy@nvidia.com> Signed-off-by: Aurelien Aptel <aaptel@nvidia.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Keith Busch <kbusch@kernel.org>
2026-04-08nvme: add missing MODULE_ALIAS for fabrics transportsGeliang Tang
The generic fabrics layer uses request_module("nvme-%s", opts->transport) to auto-load transport modules. Currently, the nvme-tcp, nvme-rdma, and nvme-fc modules lack MODULE_ALIAS entries for these names, which prevents the kernel from automatically finding and loading them when requested. Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn> Signed-off-by: Keith Busch <kbusch@kernel.org>
2026-04-08spi: pl022: enable compile testingJohan Hovold
There seems to be nothing preventing this driver from being compile tested so enable that for wider build coverage. Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://patch.msgid.link/20260408084407.107416-1-johan@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2026-04-08Input: ct82c710 - remove driverDmitry Torokhov
This is a PS/2 mouse interface chip from Chips & Technologies that was used in TI TravelMate and Gateway Nomad laptops, which used 386 and 486 CPUs. With 486 support being removed from the kernel (and 386 support is long gone) it is time to retire this driver as well. Remove the driver. Link: https://patch.msgid.link/20240808172733.1194442-6-dmitry.torokhov@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-04-08Add Renesas RZ/G3L RSPI supportMark Brown
Biju <biju.das.au@gmail.com> says: This patch series adds binding and driver support for RSPI IP found on the RZ/G3L SoC. The RSPI is compatible with RZ/V2H RSPI, but has 2 clocks compared to 3 on RZ/V2H. Link: https://patch.msgid.link/20260408085418.18770-1-biju.das.jz@bp.renesas.com
2026-04-08spi: rzv2h-rspi: Add support for RZ/G3L (R9A08G046)Biju Das
Add support for RZ/G3L RSPI. The RZ/G3L variant requires only 2 clocks (pclk + tclk), unlike the RZ/V2H which needs 3. Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://patch.msgid.link/20260408085418.18770-3-biju.das.jz@bp.renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-04-08Input: mk712 - remove driverDmitry Torokhov
This touchscreen controller was used om Gateway AOL Connected Touchpad released in 2000 and, according to Wikipedia, removed from the market in October 2001 due to slow sales. It looks like it can still be bought on eBay for $1000 but I really doubt anyone will actually use it. Remove the driver. Link: https://patch.msgid.link/20240808172733.1194442-5-dmitry.torokhov@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-04-08Input: logibm - remove driverDmitry Torokhov
Bus mice use specialized bus interface implemented via an ISA add-in cards. They were superseded by PS/2 and later USB. Kconfig entry for the Logitech bus mice states that they "are rather rare these days". This statement was true in 2002 and is no less true in 2024. Remove the driver. Link: https://patch.msgid.link/20240808172733.1194442-3-dmitry.torokhov@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-04-08Input: inport - remove driverDmitry Torokhov
Inport (ATI XL and Microsoft) mice use specialized bus interface implemented via an ISA add-in card. Have been superseded by PS/2 and then USB, and are historical curiosity by now. Remove the driver. Link: https://patch.msgid.link/20240808172733.1194442-2-dmitry.torokhov@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-04-08Input: qt1070 - inline i2c_check_functionality checkThorsten Blum
Inline the i2c_check_functionality() check, since the function returns a boolean status rather than an error code. Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Link: https://patch.msgid.link/20260408141926.1181389-4-thorsten.blum@linux.dev Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-04-08Input: qt1050 - inline i2c_check_functionality checkThorsten Blum
Inline the i2c_check_functionality() check, since the function returns a boolean status rather than an error code. Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Link: https://patch.msgid.link/20260408141926.1181389-3-thorsten.blum@linux.dev Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-04-08firmware: efi: Never declare sysfb_primary_display on x86Thomas Zimmermann
The x86 architecture comes with its own instance of the global state variable sysfb_primary_display. Never declare it in the EFI subsystem. Fix the test for CONFIG_FIRMWARE_EDID accordingly. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: e65ca1646311 ("efi: export sysfb_primary_display for EDID") Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2026-04-08Merge tag 'md-7.1-20260407' of ↵Jens Axboe
git://git.kernel.org/pub/scm/linux/kernel/git/mdraid/linux into for-7.1/block Pull MD changes from Yu Kuai: "Bug Fixes: - avoid a sysfs deadlock when clearing array state (Yu Kuai) - validate raid5 journal payloads before reading metadata (Junrui Luo) - fall back to the correct bitmap operations after version mismatches (Yu Kuai) - serialize overlapping writes on writemostly raid1 disks (Xiao Ni) - wake raid456 reshape waiters before suspend (Yu Kuai) - prevent retry_aligned_read() from triggering soft lockups (Chia-Ming Chang) Improvements: - switch raid0 strip zone and devlist allocations to kvmalloc helpers (Gregory Price) - track clean unwritten stripes for proactive RAID5 parity building (Yu Kuai) - speed up initial llbitmap sync with write_zeroes_unmap support (Yu Kuai) Cleanups: - remove the unused static md workqueue definition (Abd-Alrhman Masalkhi)" * tag 'md-7.1-20260407' of git://git.kernel.org/pub/scm/linux/kernel/git/mdraid/linux: md/raid5: fix soft lockup in retry_aligned_read() md: wake raid456 reshape waiters before suspend md/raid1: serialize overlap io for writemostly disk md/md-llbitmap: optimize initial sync with write_zeroes_unmap support md/md-llbitmap: add CleanUnwritten state for RAID-5 proactive parity building md: add fallback to correct bitmap_ops on version mismatch md/raid5: validate payload size before accessing journal metadata md: remove unused static md_wq workqueue md/raid0: use kvzalloc/kvfree for strip_zone and devlist allocations md: fix array_state=clear sysfs deadlock
2026-04-08drm/i915/gt: fix refcount underflow in intel_engine_park_heartbeatSebastian Brzezinka
A use-after-free / refcount underflow is possible when the heartbeat worker and intel_engine_park_heartbeat() race to release the same engine->heartbeat.systole request. The heartbeat worker reads engine->heartbeat.systole and calls i915_request_put() on it when the request is complete, but clears the pointer in a separate, non-atomic step. Concurrently, a request retirement on another CPU can drop the engine wakeref to zero, triggering __engine_park() -> intel_engine_park_heartbeat(). If the heartbeat timer is pending at that point, cancel_delayed_work() returns true and intel_engine_park_heartbeat() reads the stale non-NULL systole pointer and calls i915_request_put() on it again, causing a refcount underflow: ``` <4> [487.221889] Workqueue: i915-unordered engine_retire [i915] <4> [487.222640] RIP: 0010:refcount_warn_saturate+0x68/0xb0 ... <4> [487.222707] Call Trace: <4> [487.222711] <TASK> <4> [487.222716] intel_engine_park_heartbeat.part.0+0x6f/0x80 [i915] <4> [487.223115] intel_engine_park_heartbeat+0x25/0x40 [i915] <4> [487.223566] __engine_park+0xb9/0x650 [i915] <4> [487.223973] ____intel_wakeref_put_last+0x2e/0xb0 [i915] <4> [487.224408] __intel_wakeref_put_last+0x72/0x90 [i915] <4> [487.224797] intel_context_exit_engine+0x7c/0x80 [i915] <4> [487.225238] intel_context_exit+0xf1/0x1b0 [i915] <4> [487.225695] i915_request_retire.part.0+0x1b9/0x530 [i915] <4> [487.226178] i915_request_retire+0x1c/0x40 [i915] <4> [487.226625] engine_retire+0x122/0x180 [i915] <4> [487.227037] process_one_work+0x239/0x760 <4> [487.227060] worker_thread+0x200/0x3f0 <4> [487.227068] ? __pfx_worker_thread+0x10/0x10 <4> [487.227075] kthread+0x10d/0x150 <4> [487.227083] ? __pfx_kthread+0x10/0x10 <4> [487.227092] ret_from_fork+0x3d4/0x480 <4> [487.227099] ? __pfx_kthread+0x10/0x10 <4> [487.227107] ret_from_fork_asm+0x1a/0x30 <4> [487.227141] </TASK> ``` Fix this by replacing the non-atomic pointer read + separate clear with xchg() in both racing paths. xchg() is a single indivisible hardware instruction that atomically reads the old pointer and writes NULL. This guarantees only one of the two concurrent callers obtains the non-NULL pointer and performs the put, the other gets NULL and skips it. Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/15880 Fixes: 058179e72e09 ("drm/i915/gt: Replace hangcheck by heartbeats") Cc: <stable@vger.kernel.org> # v5.5+ Signed-off-by: Sebastian Brzezinka <sebastian.brzezinka@intel.com> Reviewed-by: Krzysztof Karas <krzysztof.karas@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://lore.kernel.org/r/d4c1c14255688dd07cc8044973c4f032a8d1559e.1775038106.git.sebastian.brzezinka@intel.com (cherry picked from commit 13238dc0ee4f9ab8dafa2cca7295736191ae2f42) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2026-04-08Merge branch kvm-arm64/pkvm-protected-guest into kvmarm-master/nextMarc Zyngier
* kvm-arm64/pkvm-protected-guest: (41 commits) : . : pKVM support for protected guests, implementing the very long : awaited support for anonymous memory, as the elusive guestmem : has failed to deliver on its promises despite a multi-year : effort. Patches courtesy of Will Deacon. From the initial cover : letter: : : "[...] this patch series implements support for protected guest : memory with pKVM, where pages are unmapped from the host as they are : faulted into the guest and can be shared back from the guest using pKVM : hypercalls. Protected guests are created using a new machine type : identifier and can be booted to a shell using the kvmtool patches : available at [2], which finally means that we are able to test the pVM : logic in pKVM. Since this is an incremental step towards full isolation : from the host (for example, the CPU register state and DMA accesses are : not yet isolated), creating a pVM requires a developer Kconfig option to : be enabled in addition to booting with 'kvm-arm.mode=protected' and : results in a kernel taint." : . KVM: arm64: Don't hold 'vm_table_lock' across guest page reclaim KVM: arm64: Allow get_pkvm_hyp_vm() to take a reference to a dying VM KVM: arm64: Prevent teardown finalisation of referenced 'hyp_vm' drivers/virt: pkvm: Add Kconfig dependency on DMA_RESTRICTED_POOL KVM: arm64: Rename PKVM_PAGE_STATE_MASK KVM: arm64: Extend pKVM page ownership selftests to cover guest hvcs KVM: arm64: Extend pKVM page ownership selftests to cover forced reclaim KVM: arm64: Register 'selftest_vm' in the VM table KVM: arm64: Extend pKVM page ownership selftests to cover guest donation KVM: arm64: Add some initial documentation for pKVM KVM: arm64: Allow userspace to create protected VMs when pKVM is enabled KVM: arm64: Implement the MEM_UNSHARE hypercall for protected VMs KVM: arm64: Implement the MEM_SHARE hypercall for protected VMs KVM: arm64: Add hvc handler at EL2 for hypercalls from protected VMs KVM: arm64: Return -EFAULT from VCPU_RUN on access to a poisoned pte KVM: arm64: Reclaim faulting page from pKVM in spurious fault handler KVM: arm64: Introduce hypercall to force reclaim of a protected page KVM: arm64: Annotate guest donations with handle and gfn in host stage-2 KVM: arm64: Change 'pkvm_handle_t' to u16 KVM: arm64: Introduce host_stage2_set_owner_metadata_locked() ... Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-04-08Merge branch 'thermal-intel'Rafael J. Wysocki
Merge updates of Intel thermal drivers for 7.1: - Replace cpumask_weight() in intel_hfi_offline() with cpumask_empty() which is generally more efficient (Yury Norov) - Add support for reading DDR data rate from PCI config space on Nova Lake platforms to the int340x thermal driver (Srinivas Pandruvada) * thermal-intel: thermal: intel: hfi: use cpumask_empty() in intel_hfi_offline() thermal: intel: int340x: Read DDR data rate for Nova Lake
2026-04-08thermal: core: Suspend thermal zones later and resume them earlierRafael J. Wysocki
To avoid some undesirable interactions between thermal zone suspend and resume with user space that is running when those operations are carried out, move them closer to the suspend and resume of devices, respectively, by updating dpm_prepare() to carry out thermal zone suspend and dpm_complete() to start thermal zone resume (that will continue asynchronously). This also makes the code easier to follow by removing one, arguably redundant, level of indirection represented by the thermal PM notifier. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Armin Wolf <W_Armin@gmx.de> Link: https://patch.msgid.link/2036875.PYKUYFuaPT@rafael.j.wysocki
2026-04-08thermal: core: Allocate thermal_class staticallyRafael J. Wysocki
Define thermal_class as a static structure to simplify thermal_init() and to simplify thermal class availability checks that will need to be carried out during the suspend and resume of thermal zones after subsequent changes. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/10831981.nUPlyArG6x@rafael.j.wysocki
2026-04-08thermal: core: Adjust thermal_wq allocation flagsRafael J. Wysocki
The thermal workqueue doesn't need to be freezable or per-CPU, so drop WQ_FREEZABLE and WQ_PERCPU from the flags when allocating it. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> [ rjw: Subject rewrite ] Link: https://patch.msgid.link/3413335.44csPzL39Z@rafael.j.wysocki Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-04-08thermal: core: Drop redundant check from thermal_zone_device_update()Rafael J. Wysocki
Since __thermal_zone_device_update() checks if tz->state is TZ_STATE_READY and bails out immediately otherwise, it is not necessary to check the thermal_zone_is_present() return value in thermal_zone_device_update(). Namely, tz->state is equal to TZ_STATE_FLAG_INIT initially and that flag is only cleared in thermal_zone_init_complete() after adding tz to the list of thermal zones, and thermal_zone_exit() sets TZ_STATE_FLAG_EXIT in tz->state while removing tz from that list. Thus tz->state is not TZ_STATE_READY when tz is not in the list and the check mentioned above is redundant. Accordingly, drop the redundant thermal_zone_is_present() check from thermal_zone_device_update() and drop the former altogether because it has no more users. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/3406806.aeNJFYEL58@rafael.j.wysocki
2026-04-08thermal: core: Free thermal zone ID later during removalRafael J. Wysocki
The thermal zone removal ordering is different from the thermal zone registration rollback path ordering and the former is arguably problematic because freeing a thermal zone ID prematurely may cause it to be used during the registration of another thermal zone which may fail as a result. Prevent that from occurring by changing the thermal zone removal ordering to reflect the thermal zone registration rollback path ordering. Also more the ida_destroy() call from thermal_zone_device_unregister() to thermal_release() for consistency. Fixes: b31ef8285b19 ("thermal core: convert ID allocation to IDA") Cc: All applicable <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/5063934.GXAFRqVoOG@rafael.j.wysocki
generated by cgit v1.2.3 (git 2.25.1) at 2026-05-24 02:56:31 +0000