summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-03-25cpupower-idle-info.1: fix short option namesRoberto Ricci
The cpupower-idle-info(1) man page describes '-f' as the short form of the '--silent' option and '-e' as the short form of the '--proc' option. But they are not correct: $ cpupower idle-info -f idle-info: invalid option -- 'f' invalid or unknown argument $ cpupower idle-info -e idle-info: invalid option -- 'e' invalid or unknown argument The short form of '--silent' is actually '-s' and the short form of '--proc' is actually '-o': cpuidle-info.c: {"silent", no_argument, NULL, 's'}, {"proc", no_argument, NULL, 'o'}, Signed-off-by: Roberto Ricci <io@r-ricci.it> Link: https://lore.kernel.org/r/20260324223921.14317-2-io@r-ricci.it Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2026-03-25Bluetooth: btusb: clamp SCO altsetting table indicesPengpeng Hou
btusb_work() maps the number of active SCO links to USB alternate settings through a three-entry lookup table when CVSD traffic uses transparent voice settings. The lookup currently indexes alts[] with data->sco_num - 1 without first constraining sco_num to the number of available table entries. While the table only defines alternate settings for up to three SCO links, data->sco_num comes from hci_conn_num() and is used directly. Cap the lookup to the last table entry before indexing it so the driver keeps selecting the highest supported alternate setting without reading past alts[]. Fixes: baac6276c0a9 ("Bluetooth: btusb: handle mSBC audio over USB Endpoints") Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-03-25Bluetooth: L2CAP: Fix ERTM re-init and zero pdu_len infinite loopHyunwoo Kim
l2cap_config_req() processes CONFIG_REQ for channels in BT_CONNECTED state to support L2CAP reconfiguration (e.g. MTU changes). However, since both CONF_INPUT_DONE and CONF_OUTPUT_DONE are already set from the initial configuration, the reconfiguration path falls through to l2cap_ertm_init(), which re-initializes tx_q, srej_q, srej_list, and retrans_list without freeing the previous allocations and sets chan->sdu to NULL without freeing the existing skb. This leaks all previously allocated ERTM resources. Additionally, l2cap_parse_conf_req() does not validate the minimum value of remote_mps derived from the RFC max_pdu_size option. A zero value propagates to l2cap_segment_sdu() where pdu_len becomes zero, causing the while loop to never terminate since len is never decremented, exhausting all available memory. Fix the double-init by skipping l2cap_ertm_init() and l2cap_chan_ready() when the channel is already in BT_CONNECTED state, while still allowing the reconfiguration parameters to be updated through l2cap_parse_conf_req(). Also add a pdu_len zero check in l2cap_segment_sdu() as a safeguard. Fixes: 96298f640104 ("Bluetooth: L2CAP: handle l2cap config request during open state") Signed-off-by: Hyunwoo Kim <imv4bel@gmail.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-03-25Bluetooth: L2CAP: Fix deadlock in l2cap_conn_del()Hyunwoo Kim
l2cap_conn_del() calls cancel_delayed_work_sync() for both info_timer and id_addr_timer while holding conn->lock. However, the work functions l2cap_info_timeout() and l2cap_conn_update_id_addr() both acquire conn->lock, creating a potential AB-BA deadlock if the work is already executing when l2cap_conn_del() takes the lock. Move the work cancellations before acquiring conn->lock and use disable_delayed_work_sync() to additionally prevent the works from being rearmed after cancellation, consistent with the pattern used in hci_conn_del(). Fixes: ab4eedb790ca ("Bluetooth: L2CAP: Fix corrupted list in hci_chan_del") Signed-off-by: Hyunwoo Kim <imv4bel@gmail.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-03-25Bluetooth: btintel: serialize btintel_hw_error() with hci_req_sync_lockCen Zhang
btintel_hw_error() issues two __hci_cmd_sync() calls (HCI_OP_RESET and Intel exception-info retrieval) without holding hci_req_sync_lock(). This lets it race against hci_dev_do_close() -> btintel_shutdown_combined(), which also runs __hci_cmd_sync() under the same lock. When both paths manipulate hdev->req_status/req_rsp concurrently, the close path may free the response skb first, and the still-running hw_error path hits a slab-use-after-free in kfree_skb(). Wrap the whole recovery sequence in hci_req_sync_lock/unlock so it is serialized with every other synchronous HCI command issuer. Below is the data race report and the kasan report: BUG: data-race in __hci_cmd_sync_sk / btintel_shutdown_combined read of hdev->req_rsp at net/bluetooth/hci_sync.c:199 by task kworker/u17:1/83: __hci_cmd_sync_sk+0x12f2/0x1c30 net/bluetooth/hci_sync.c:200 __hci_cmd_sync+0x55/0x80 net/bluetooth/hci_sync.c:223 btintel_hw_error+0x114/0x670 drivers/bluetooth/btintel.c:254 hci_error_reset+0x348/0xa30 net/bluetooth/hci_core.c:1030 write/free by task ioctl/22580: btintel_shutdown_combined+0xd0/0x360 drivers/bluetooth/btintel.c:3648 hci_dev_close_sync+0x9ae/0x2c10 net/bluetooth/hci_sync.c:5246 hci_dev_do_close+0x232/0x460 net/bluetooth/hci_core.c:526 BUG: KASAN: slab-use-after-free in sk_skb_reason_drop+0x43/0x380 net/core/skbuff.c:1202 Read of size 4 at addr ffff888144a738dc by task kworker/u17:1/83: __hci_cmd_sync_sk+0x12f2/0x1c30 net/bluetooth/hci_sync.c:200 __hci_cmd_sync+0x55/0x80 net/bluetooth/hci_sync.c:223 btintel_hw_error+0x186/0x670 drivers/bluetooth/btintel.c:260 Fixes: 973bb97e5aee ("Bluetooth: btintel: Add generic function for handling hardware errors") Signed-off-by: Cen Zhang <zzzccc427@gmail.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-03-25Bluetooth: L2CAP: Fix send LE flow credits in ACL linkZhang Chen
When the L2CAP channel mode is L2CAP_MODE_ERTM/L2CAP_MODE_STREAMING, l2cap_publish_rx_avail will be called and le flow credits will be sent in l2cap_chan_rx_avail, even though the link type is ACL. The logs in question as follows: > ACL Data RX: Handle 129 flags 0x02 dlen 12 L2CAP: Unknown (0x16) ident 4 len 4 40 00 ed 05 < ACL Data TX: Handle 129 flags 0x00 dlen 10 L2CAP: Command Reject (0x01) ident 4 len 2 Reason: Command not understood (0x0000) Bluetooth: Unknown BR/EDR signaling command 0x16 Bluetooth: Wrong link type (-22) Fixes: ce60b9231b66 ("Bluetooth: compute LE flow credits based on recvbuf space") Signed-off-by: Zhang Chen <zhangchen01@kylinos.cn> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-03-25docs: allow long links to wrap per character to prevent page overflowRito Rhymes
Some documentation pages contain long link text without natural break points, which can force page-wide horizontal scroll overflow on small screens. Use overflow-wrap: anywhere for anchor text in the docs stylesheet so links can wrap per character as a fallback when normal word boundaries are unavailable. Examples: https://docs.kernel.org/6.15/firmware-guide/acpi/non-d0-probe.html https://docs.kernel.org/6.15/arch/x86/earlyprintk.html Signed-off-by: Rito Rhymes <rito@ritovision.com> Assisted-by: Codex:GPT-5.4 Tested-by: Randy Dunlap <rdunlap@infradead.org> Acked-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Message-ID: <20260323152428.30483-1-rito@ritovision.com>
2026-03-25docs: allow long table reference links to wrap and prevent overflowRito Rhymes
Some documentation pages contain docutils tables with reference links that use long unbroken strings. Those strings can expand the table width beyond the content column and cause page-wide horizontal overflow. Allow reference links in docutils tables in the main document body to wrap when needed so the table stays within the content column and does not break page layout. Examples: https://docs.kernel.org/6.15/arch/openrisc/openrisc_port.html https://docs.kernel.org/6.15/filesystems/ext2.html Signed-off-by: Rito Rhymes <rito@ritovision.com> Assisted-by: Codex:GPT-5.4 Tested-by: Randy Dunlap <rdunlap@infradead.org> Acked-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Message-ID: <20260323152428.30483-2-rito@ritovision.com>
2026-03-25docs: contain horizontal overflow in C API descriptionsRito Rhymes
Some documentation pages contain long C API signatures that can exceed the content width and cause page-wide horizontal scroll overflow. Apply contained horizontal scrolling to C API description blocks and keep their signature rows on one line. This preserves signature formatting while preventing them from breaking page layout. Contained horizontal scrolling is preferred over wrapping here because code fidelity is the priority. These blocks are intended to remain representative of the code itself. Wrapping distorts spacing and line structure, which affects fidelity, creates misleading renderings, and reduces readability. Examples: https://docs.kernel.org/6.15/driver-api/regulator.html https://docs.kernel.org/6.15/userspace-api/fwctl/fwctl-cxl.html Signed-off-by: Rito Rhymes <rito@ritovision.com> Assisted-by: Codex:GPT-5.4 Tested-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Message-ID: <20260323153342.33447-1-rito@ritovision.com>
2026-03-25docs: allow inline literals in paragraphs to wrap to prevent overflowRito Rhymes
Some documentation pages contain long inline literals in paragraph text that can force page-wide horizontal scroll overflow and break layout on smaller screens. Override the default `span.pre` white-space behavior for inline literals and use `overflow-wrap: anywhere` so they can wrap when needed. For code used as part of a paragraph, wrapping is appropriate because it is stylistically part of the surrounding text. Code blocks, by contrast, are meant to preserve formatting fidelity and are better served by contained horizontal scrolling. Examples: https://docs.kernel.org/6.15/userspace-api/futex2.html https://docs.kernel.org/6.15/security/IMA-templates.html Signed-off-by: Rito Rhymes <rito@ritovision.com> Assisted-by: Codex:GPT-5.4 Tested-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Message-ID: <20260323151401.27415-1-rito@ritovision.com>
2026-03-25smp: Improve smp_call_function_single() CSD-lock diagnosticsPaul E. McKenney
Both smp_call_function() and smp_call_function_single() use per-CPU call_single_data_t variable to hold the infamous CSD lock. However, while smp_call_function() acquires the destination CPU's CSD lock, smp_call_function_single() instead uses the source CPU's CSD lock. (These are two separate sets of CSD locks, cfd_data and csd_data, respectively.) This otherwise inexplicable pair of choices is explained by their respective queueing properties. If smp_call_function() where to use the sending CPU's CSD lock, that would serialize the destination CPUs' IPI handlers and result in long smp_call_function() latencies, especially on systems with large numbers of CPUs. For its part, if smp_call_function_single() were to use the (single) destination CPU's CSD lock, this would similarly serialize in the case where many CPUs are sending IPIs to a single "victim" CPU. Plus it would result in higher levels of memory contention. Except that if there is no NMI-based stack tracing on a weakly ordered system where remote unsynchronized stack traces are especially unreliable, the improved debugging beats the improved queueing. This improved queueing only matters if a bunch of CPUs are calling smp_call_function_single() concurrently for a single "victim" CPU, which is not the common case. Therefore, make smp_call_function_single() use the destination CPU's csd_data instance in kernels built with CONFIG_CSD_LOCK_WAIT_DEBUG=y where csdlock_debug_enabled is also set. Otherwise, continue to use the source CPU's csd_data. Signed-off-by: Paul E. McKenney <paulmck@kernel.org> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://patch.msgid.link/25c2eb97-77c8-49a5-80ac-efe78dea272c@paulmck-laptop
2026-03-25smp: Get this_cpu once in smp_call_functionShrikanth Hegde
smp_call_function_single() and smp_call_function_many_cond() disable preemption and cache the CPU number via get_cpu(). Use this cached value throughout the function instead of invoking smp_processor_id() again. [ tglx: Make the copy&pasta'ed change log match the patch ] Signed-off-by: Shrikanth Hegde <sshegde@linux.ibm.com> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Reviewed-by: Mukesh Kumar Chaurasiya (IBM) <mkchauras@gmail.com> Link: https://patch.msgid.link/20260323193630.640311-4-sshegde@linux.ibm.com
2026-03-25smp: Add missing kernel-doc commentsRandy Dunlap
Add missing kernel-doc comments and rearrange the order of others to prevent all kernel-doc warnings. - add function Returns: sections or format existing comments as kernel-doc - add missing function parameter comments - use "/**" for smp_call_function_any() and on_each_cpu_cond_mask() - correct the commented function name for on_each_cpu_cond_mask() - use correct format for function short descriptions - add all kernel-doc comments for smp_call_on_cpu() - remove kernel-doc comments for raw_smp_processor_id() since there is no prototype for it here (other than !SMP) - in smp.h, rearrange some lines so that the kernel-doc comments for smp_processor_id() are immediately before the macro (to prevent kernel-doc warnings) - remove "Returns" from smp_call_function() since it doesn't return a value Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260310061726.1153764-1-rdunlap@infradead.org
2026-03-25fscrypt: use AES library for v1 key derivationEric Biggers
Convert the implementation of the v1 (original / deprecated) fscrypt per-file key derivation algorithm to use the AES library instead of an "ecb(aes)" crypto_skcipher. This is much simpler. While the AES library doesn't support AES-ECB directly yet, we can still simply call aes_encrypt() in a loop. While that doesn't explicitly parallelize the AES encryptions, it doesn't really matter in this case, where a new key is used each time and only 16 to 64 bytes are encrypted. In fact, a quick benchmark (AMD Ryzen 9 9950X) shows that this commit actually greatly improves performance, from ~7000 cycles per key derived to ~1500. The times don't differ much between 32 bytes and 64 bytes either, so clearly the bottleneck is API stuff and key expansion. Granted, performance of the v1 key derivation is no longer very relevant: most users have moved onto v2 encryption policies. The v2 key derivation uses HKDF-SHA512 (which is ~3500 cycles on the same CPU). Still, it's nice that the simpler solution is much faster as well. Compatibility verified with xfstests generic/548. Link: https://lore.kernel.org/r/20260321075338.99809-1-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2026-03-25PCI: mediatek-gen3: Integrate new pwrctrl APIChen-Yu Tsai
With the new PCI pwrctrl API and PCI slot binding and power drivers, we now have a way to describe and power up WiFi/BT adapters connected through a PCIe or M.2 slot, or populated onto the mainboard itself. The latter case has the adapter layout or design copied verbatim, replacing the slot with direct connections. Integrate the PCI pwrctrl API into the PCIe driver, so that power is properly enabled before PCIe link training is done, allowing the card to successfully be detected. Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20260324052002.4072430-8-wenst@chromium.org
2026-03-25PCI: mediatek-gen3: Disable device if further setup failsChen-Yu Tsai
If further setup fails after the device is powered on and link training succeeds, we want to place the device back in a quiescence state to avoid unintended activity and save power. This also helps with power state tracking and balancing once pwrctrl API is integrated. Power down the device in the error paths of mtk_pcie_startup_port() and mtk_pcie_probe(). Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20260324052002.4072430-7-wenst@chromium.org
2026-03-25PCI: mediatek-gen3: Split out device power helpersChen-Yu Tsai
In preparation for adding full power on/off control with the pwrctrl API, split out the existing code that only partially deals with device power sequencing into separate helper functions. The existing code only handles PERST#. This is purely moving code around, and brings no functional changes. Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> [mani: moved the 'err' variable to next commit] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20260324052002.4072430-6-wenst@chromium.org
2026-03-25PCI: mediatek-gen3: Add error path for resume driver callbacksChen-Yu Tsai
The resume callback currently does teardown in the conditional block directly. This is going to get ugly when the pwrctrl calls are added. Move the teardown to a proper error cleanup path. Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20260324052002.4072430-5-wenst@chromium.org
2026-03-25PCI: mediatek-gen3: Move controller setup steps before PERST# controlChen-Yu Tsai
Setting up the translation windows and enabling MSI involve only the controller, not the link or any downstream device. These can be done before the device is enabled. Move these steps before the existing PERST# control and waiting for the link to come up. This provides a cleaner separation of controller vs device setup. This also allows the later commits that split out PERST# control and add device power control to have cleaner teardown. This change only moves code. No functional change is expected. Suggested-by: Bjorn Helgaas <helgaas@kernel.org> Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://patch.msgid.link/20260324052002.4072430-4-wenst@chromium.org
2026-03-25PCI: mediatek-gen3: Move mtk_pcie_setup_irq() out of mtk_pcie_setup()Chen-Yu Tsai
mtk_pcie_setup_irq() sets up the IRQ domains for PCI INTx and MSI, and chains them to the controller's interrupt. It doesn't touch the PCIe controller itself. Move mtk_pcie_setup_irq() out of mtk_pcie_setup(), do it earlier so there's nothing to clean up if it fails, and add an error message if it does fail. Reorder mtk_pcie_irq_teardown() in the remove callback to follow. Also create an error path in the probe function. Suggested-by: Bjorn Helgaas <helgaas@kernel.org> Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://patch.msgid.link/20260324052002.4072430-3-wenst@chromium.org
2026-03-25PCI: mediatek-gen3: Clean up mtk_pcie_parse_port() with dev_err_probe()Chen-Yu Tsai
mtk_pcie_parse_port() in the pcie-mediatek-gen driver has a bunch of if (err) { dev_err(dev, "error message\n"); return err; # or goto } patterns. Simplify these with dev_err_probe(). The system also gains proper deferred probe messages that can be seen in: /sys/kernel/debug/devices_deferred Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20260324052002.4072430-2-wenst@chromium.org
2026-03-25accel/amdxdna: Add per-process BO memory usage query supportMax Zhen
Add support for querying per-process buffer object (BO) memory usage through the amdxdna GET_ARRAY UAPI. Introduce a new query type, DRM_AMDXDNA_BO_USAGE, along with struct amdxdna_drm_bo_usage to report BO memory usage statistics, including heap, total, and internal usage. Track BO memory usage on a per-client basis by maintaining counters in GEM open/close and heap allocation/free paths. This ensures the reported statistics reflect the current memory footprint of each process. Wire the new query into the GET_ARRAY implementation to expose the usage information to userspace. Link: https://github.com/amd/xdna-driver/commit/0546f2aaadbdacf1c3556410ecd71622044cd916 Signed-off-by: Max Zhen <max.zhen@amd.com> Reviewed-by: Lizhi Hou <lizhi.hou@amd.com> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Lizhi Hou <lizhi.hou@amd.com> Link: https://patch.msgid.link/20260324163159.2425461-1-lizhi.hou@amd.com
2026-03-25docs: driver-api: fix 6 spelling typos in Documentation/driver-apiTomás Pando
Fix minor spelling mistakes in the driver-api documentation. These changes improve readability in ACPI, CXL, DMA and PCI docs. Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Tomás Pando <tovictakamine@gmail.com> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Message-ID: <20260324163604.5710-1-tovictakamine@gmail.com>
2026-03-25PCI/VGA: Pass errors from pci_set_vga_state() upSimon Richter
pci_set_vga_state() returns an error code, which so far has been ignored by the only caller, __vga_tryget(), so forward it to the caller. As the return type of __vga_tryget() is a pointer, wrap the error in ERR_PTR(). Signed-off-by: Simon Richter <Simon.Richter@hogyros.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20260307173538.763188-3-Simon.Richter@hogyros.de
2026-03-25PCI/VGA: Pass vga_get_uninterruptible() errors to userspaceSimon Richter
If VGA routing cannot be established, vga_get_uninterruptible() returns an error and does not increment the lock count. Return the error to the caller. Return before incrementing uc->io_cnt/mem_cnt so vga_arb_release() won't call vga_put() when userspace closes the handle. Signed-off-by: Simon Richter <Simon.Richter@hogyros.de> [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20260307173538.763188-2-Simon.Richter@hogyros.de
2026-03-25arm64: mm: __ptep_set_access_flags must hint correct TTLRyan Roberts
It has been reported that since commit 752a0d1d483e9 ("arm64: mm: Provide level hint for flush_tlb_page()"), the arm64 check_hugetlb_options selftest has been locking up while running "Check child hugetlb memory with private mapping, sync error mode and mmap memory". This is due to hugetlb (and THP) helpers casting their PMD/PUD entries to PTE and calling __ptep_set_access_flags(), which issues a __flush_tlb_page(). Now that this is hinted for level 3, in this case, the TLB entry does not get evicted and we end up in a spurious fault loop. Fix this by creating a __ptep_set_access_flags_anysz() function which takes the pgsize of the entry. It can then add the appropriate hint. The "_anysz" approach is the established pattern for problems of this class. Reported-by: Aishwarya TCV <Aishwarya.TCV@arm.com> Fixes: 752a0d1d483e ("arm64: mm: Provide level hint for flush_tlb_page()") Signed-off-by: Ryan Roberts <ryan.roberts@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2026-03-25platform: int3472: Drop redundant initialisation to 0 and NULLSakari Ailus
A few fields in structs containing regulator initialisation data for Dell laptops are initialised to 0 and NULL. Drop the explicit initialisation as redundant. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-03-25platform: int3472: Add MSI prestige board dataAntti Laakso
Define regulators and gpio for ov5675 in MSI Prestige 14 AI EVO+ laptop. Signed-off-by: Antti Laakso <antti.laakso@linux.intel.com> Acked-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com> [Sakari Ailus: Drop redundant initialisation to 0 and NULL.] Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-03-25gpio: tps68470: Add i2c daisy chain supportAntti Laakso
The tps68470 daisy chain make use of gpio 1 and 2. When in use, these gpios must be configured as inputs without pull-up. Signed-off-by: Antti Laakso <antti.laakso@linux.intel.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-03-25platform: int3472: Add gpio software nodeAntti Laakso
The tps68470 supports i2c daisy chain, which need to be configured by gpio-tps68470 driver. Add daisy chain information to software node. Signed-off-by: Antti Laakso <antti.laakso@linux.intel.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Acked-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-03-25media: i2c: ov5675: Wait for endpointAntti Laakso
Defer probe if endpoint is not yet available. And do it before acquiring clock, gpio and regulators. Signed-off-by: Antti Laakso <antti.laakso@linux.intel.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-03-25media: staging: imx: configure src_mux in csi_startMichael Tretter
After media_pipeline_start() was called, the media graph is assumed to be validated. It won't be validated again if a second stream starts. The imx-media-csi driver, however, changes hardware configuration in the link_validate() callback. This can result in started streams with misconfigured hardware. In the concrete example, the ipu2_csi1 is driven by a parallel video input. After the media pipeline has been started with this configuration, a second stream is configured to use ipu1_csi0 with MIPI-CSI input from imx6-mipi-csi2. This may require the reconfiguration of ipu1_csi0 with ipu_set_csi_src_mux(). Since the media pipeline is already running, link_validate won't be called, and the ipu1_csi0 won't be reconfigured. The resulting video is broken, because the ipu1_csi0 is misconfigured, but no error is reported. Move ipu_set_csi_src_mux from csi_link_validate to csi_start to ensure that input to ipu1_csi0 is configured correctly when starting the stream. This is a local reconfiguration in ipu1_csi0 and is possible while the media pipeline is running. Since csi_start() is called with priv->lock already locked, csi_set_src() must not lock priv->lock again. Thus, the mutex_lock() is dropped. Signed-off-by: Michael Tretter <m.tretter@pengutronix.de> Fixes: 4a34ec8e470c ("[media] media: imx: Add CSI subdev driver") Cc: stable@vger.kernel.org Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-03-25media: staging: imx: request mbus_config in csi_startMichael Tretter
Request the upstream mbus_config in csi_start, which starts the stream, instead of caching it in link_validate. This allows to get rid of the mbus_cfg field in the struct csi_priv and avoids state in the driver. Fixes: 4a34ec8e470c ("[media] media: imx: Add CSI subdev driver") Cc: stable@vger.kernel.org Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Michael Tretter <m.tretter@pengutronix.de> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-03-25media: staging: imx: fix code style issuesvivek yadav
Applied checkpatch.pl recommendations: - corrected whitespace - fixed line length - adjusted indentation Signed-off-by: vivek yadav <y9.vivek@gmail.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-03-25media: staging: imx: Remove unnecessary braces from if statementAyush Kumar
Adhering to Linux kernel coding style guidelines (Chapter 3: Indentation). Signed-off-by: Ayush Kumar <ayushkr0s@gmail.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-03-25arm64: dts: renesas: beacon-renesom: Remove LVDS PanelAdam Ford
The LVDS Panel was never shipped from Beacon, and there are device tree errors, so rather than trying to fix them, remove it instead. Signed-off-by: Adam Ford <aford173@gmail.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20260325162735.24467-1-aford173@gmail.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2026-03-25ARM: dts: r9a06g032: Add #address-cells to the GIC nodeHerve Codina (Schneider Electric)
When checking dts involving the r9a06g032.dtsi file, the following kind of warnings are reported: Missing property '#address-cells' in node xxx, using 0 as fallback Indeed, #address-cells is not present in the GIC interrupt controller node. Fix it adding the missing property. Value '0' is correct because: 1. GIC interrupt controller does not have children, 2. interrupt-map property in PCI node and in IRQ mux node consists of several components and the component related to "parent unit address", which size is defined by '#address-cells' of the node pointed to by the interrupt-parent component, is not used (=0) No functional change. Signed-off-by: Herve Codina (Schneider Electric) <herve.codina@bootlin.com> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20260325095718.388157-1-herve.codina@bootlin.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2026-03-25arm64: dts: renesas: r9a09g056: Remove wdt{0,2,3} nodesFabrizio Castro
The Renesas RZ/V2N SoC (a.k.a. r9a09g056) comes with 4 CA55 cores and 1 CM33 core. While the user manual doesn't explicitly specify which cores should have access to particular watchdogs, it turns out that (similarly to the Renesas RZ/V2H(P)) it only makes sense for Linux to use WDT1. Remove DT nodes wdt{0,2,3} from the RZ/V2N SoC specific dtsi to make it compliant with the original design intent. This change is harmless as there are no users for the nodes being stripped out of this device tree. Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20260324225239.19136-2-fabrizio.castro.jz@renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2026-03-25arm64: dts: renesas: sparrow-hawk: Add overlay for Olimex MIPI-HDMI adapterScott Murray
Add a DT overlay to bind the Olimex MIPI-HDMI dual-lane DSI-to-HDMI adapter on the Retronix R-Car V4H Sparrow Hawk board. Current device link is at https://www.olimex.com/Products/IoT/ESP32-P4/MIPI-HDMI/open-source-hardware Signed-off-by: Scott Murray <scott.murray@konsulko.com> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20260320025328.509003-1-marek.vasut+renesas@mailbox.org Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2026-03-25arm64: dts: renesas: r9a09g047e57-smarc: Enable PCIeJohn Madieu
The RZ Smarc Carrier-II board has PCIe slots mounted on it. Enable PCIe support. Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20260318085119.44717-5-john.madieu.xa@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2026-03-25arm64: dts: renesas: r9a09g047e57-smarc-som: Add PCIe reference clockJohn Madieu
The RZ/G3E SMARC SoM has a fixed 100 MHz reference clock generator for PCIe. Model it as a fixed-clock and assign it to the PCIe port. Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com> Tested-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> # RZ/V2N EVK Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20260318085119.44717-4-john.madieu.xa@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2026-03-25arm64: dts: renesas: r9a09g047: Add PCIe nodeJohn Madieu
The RZ/G3E SoC family features an x2 PCIe IP. Add the PCIe node. Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com> Tested-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> # RZ/V2N EVK Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20260318085119.44717-3-john.madieu.xa@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2026-03-25arm64: dts: renesas: Fix KSZ9131 PHY bogus txdv-skew-psec propertiesMarek Vasut
The KSZ9131 schema does not document the "txdv-skew-psec" property, neither does the kernel driver support this property. It does however document and support the "txen-skew-psec" property. Fix what is likely a copy-paste error from the matching "rxdv-skew-psec" property, use the "txen-skew-psec" property instead of the "txdv-skew-psec" property. Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Tested-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20260313164008.40933-5-marek.vasut+renesas@mailbox.org Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2026-03-25arm64: dts: renesas: Drop KSZ9131 PHY C22 compatible stringsMarek Vasut
The Microchip KSZ9131 PHY schema indicates that the compatible string "ethernet-phy-id0022.1640" must not be followed by any other compatible string. Drop trailing "ethernet-phy-ieee802.3-c22" to match the schema. Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20260313164008.40933-4-marek.vasut+renesas@mailbox.org Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2026-03-25arm64: dts: renesas: Drop RTL8211F PHY C22 compatible stringsMarek Vasut
The Realtek RTL8211F PHY schema indicates that the compatible string "ethernet-phy-id001c.c916" must not be followed by any other compatible string. Drop trailing "ethernet-phy-ieee802.3-c22" to match the schema. Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20260313164008.40933-3-marek.vasut+renesas@mailbox.org Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2026-03-25arm64: dts: renesas: Drop RTL8211E PHY C22 compatible stringsMarek Vasut
The Realtek RTL8211E PHY schema indicates that the compatible string "ethernet-phy-id001c.c915" must not be followed by any other compatible string. Drop trailing "ethernet-phy-ieee802.3-c22" to match the schema. Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20260313164008.40933-2-marek.vasut+renesas@mailbox.org Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2026-03-25PCI: hv: Set default NUMA node to 0 for devices without affinity infoLong Li
When hv_pci_assign_numa_node() processes a device that does not have HV_PCI_DEVICE_FLAG_NUMA_AFFINITY set or has an out-of-range virtual_numa_node, the device NUMA node is left unset. On x86_64, the uninitialized default happens to be 0, but on ARM64 it is NUMA_NO_NODE (-1). Tests show that when no NUMA information is available from the Hyper-V host, devices perform best when assigned to node 0. With NUMA_NO_NODE the kernel may spread work across NUMA nodes, which degrades performance on Hyper-V, particularly for high-throughput devices like MANA. Always set the device NUMA node to 0 before the conditional NUMA affinity check, so that devices get a performant default when the host provides no NUMA information, and behavior is consistent on both x86_64 and ARM64. Fixes: 999dd956d838 ("PCI: hv: Add support for protocol 1.3 and support PCI_BUS_RELATIONS2") Signed-off-by: Long Li <longli@microsoft.com> Reviewed-by: Michael Kelley <mhklinux@outlook.com> Signed-off-by: Wei Liu <wei.liu@kernel.org>
2026-03-25arm64: dts: renesas: sparrow-hawk: Add overlay for WaveShare Display 13.3"Marek Vasut
Add a DT overlay to bind the WaveShare 13.3inch 1920x1080 DSI Capacitive Touch Display on the Retronix R-Car V4H Sparrow Hawk board. Current device link is at https://www.waveshare.com/13.3inch-dsi-lcd.htm Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20260117005028.126361-2-marek.vasut+renesas@mailbox.org Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2026-03-25clk: renesas: r9a09g056: Remove entries for WDT{0,2,3}Fabrizio Castro
The Renesas RZ/V2N SoC (a.k.a. r9a09g056) comes with 4 watchdogs. As it turns out, it only makes sense for Linux to have access to WDT1. Remove the clock and reset entries for WDT{0,2,3} to prevent interfering with the CM33 core. This change is harmless as only WDT1 is currently used in Linux, there are no users for the WDT{0,2,3} IPs. Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20260324225239.19136-3-fabrizio.castro.jz@renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2026-03-25clk: renesas: r9a06g032: Enable watchdog reset sourcesHerve Codina (Schneider Electric)
The watchdog timeout is signaled using an interrupt and, on this interrupt, a software initiated reset is performed. This software initiated reset performs, in the end, a hardware system reset using SWRST_REQ of RSTCTRL register. The watchdog itself is able to control directly the hardware system reset without any operation done by the interrupt handler. This feature allows the watchdog to not depend on the software to reset the system when a watchdog timeout occurs. Indeed, when the watchdog timeout occurs, the watchdog requests a system reset using its own hardware dedicated line but this reset source is disabled at the reset controller level. To benefit of this feature and be robust against software issues, enable watchdogs reset sources. Suggested-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Herve Codina (Schneider Electric) <herve.codina@bootlin.com> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20260324120435.243641-2-herve.codina@bootlin.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>