summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2026-06-04dmaengine: sh: rz-dmac: Use virt-dma APIs for channel descriptor processingClaudiu Beznea
The driver used a mix of virt-dma APIs and driver specific logic to process descriptors. It maintained three internal queues: ld_free, ld_queue, and ld_active as follows: - ld_free: stores the descriptors pre-allocated at probe time - ld_queue: stores descriptors after they are taken from ld_free and prepared. At the same time, vchan_tx_prep() queues them to vc->desc_allocated. The vc->desc_allocated list is then checked in rz_dmac_issue_pending() and rz_dmac_irq_handler_thread() before starting a new transfer via rz_dmac_xfer_desc(). In turn, rz_dmac_xfer_desc() grabs the next descriptor from vc->desc_issued and submits it for transfer - ld_active: stores the descriptors currently being transferred The interrupt handler moved a completed descriptor to ld_free before invoking its completion callback. Once returned to ld_free, the descriptor can be reused to prepare a new transfer. In theory, this means the descriptor could be re-prepared before its completion callback is called. Commit fully back the driver by the virt-dma APIs. With this, only ld_free need to be kept to track how many free descriptors are available. This is now done as follows: - the prepare stage removes the first descriptor from the ld_free and prepares it - the completion calls for it vc->desc_free() (rz_dmac_virt_desc_free()) which re-adds the descriptor at the end of ld_free With this, the critical areas in prepare callbacks were minimized to only getting the descriptor from the ld_free list. Introduce struct rz_dmac_chan::desc to keep track of the currently transferred descriptor. It is cleared in rz_dmac_terminate_all(), referenced from rz_dmac_issue_pending() to determine whether a new transfer can be started, and from rz_dmac_irq_handler_thread() once a descriptor has completed. Finally, the rz_dmac_device_synchronize() was updated with vchan_synchronize() call to ensure the terminated descriptor is freed and the tasklet is killed. With this, residue computation is also simplified, as it can now be handled entirely through the virt-dma APIs. The spin_lock/unlock operations from rz_dmac_irq_handler_thread() were replaced by guard as the final code after rework is simpler this way. As subsequent commits will set the Link End bit on the last descriptor of a transfer, rz_dmac_enable_hw() is also adjusted as part of the full conversion to virt-dma APIs. It no longer checks the channel enable status itself; instead, its callers verify whether the channel is enabled and whether the previous transfer has completed before starting a new one. Tested-by: John Madieu <john.madieu.xa@bp.renesas.com> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/20260526084710.3491480-10-claudiu.beznea@kernel.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-04dmaengine: sh: rz-dmac: Add helper to check if the channel is pausedClaudiu Beznea
Add the rz_dmac_chan_is_paused() helper to check if the channel is paused. This helper will be reused in subsequent patches. Reviewed-by: Frank Li <Frank.Li@nxp.com> Tested-by: John Madieu <john.madieu.xa@bp.renesas.com> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/20260526084710.3491480-9-claudiu.beznea@kernel.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-04dmaengine: sh: rz-dmac: Add helper to check if the channel is enabledClaudiu Beznea
Add the rz_dmac_chan_is_enabled() helper to check if a channel is enabled. This helper will be reused in subsequent patches. Reviewed-by: Frank Li <Frank.Li@nxp.com> Tested-by: John Madieu <john.madieu.xa@bp.renesas.com> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/20260526084710.3491480-8-claudiu.beznea@kernel.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-04dmaengine: sh: rz-dmac: Save the start LM descriptorClaudiu Beznea
Save the start LM descriptor to avoid starting from the beginning of the channel's LM descriptor list in rz_dmac_calculate_residue_bytes_in_vd(). This avoids unnecessary iterations. Tested-by: John Madieu <john.madieu.xa@bp.renesas.com> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/20260526084710.3491480-7-claudiu.beznea@kernel.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-04dmaengine: sh: rz-dmac: Add helper to compute the lmdesc addressClaudiu Beznea
Add a the rz_dmac_lmdesc_addr() helper function to compute the lmdesc address, to make the code easier to understand. The helper will be used in subsequent patches. Reviewed-by: Frank Li <Frank.Li@nxp.com> Tested-by: John Madieu <john.madieu.xa@bp.renesas.com> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/20260526084710.3491480-6-claudiu.beznea@kernel.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-04dmaengine: sh: rz-dmac: Use rz_dmac_disable_hw()Claudiu Beznea
Use rz_dmac_disable_hw() instead of open coding it. This unifies the code and prepares it for the addition of suspend to RAM and cyclic DMA. The rz_dmac_disable_hw() from rz_dmac_chan_probe() was moved after vchan_init() as it initializes the channel->vc.chan.device used in rz_dmac_disable_hw(). Reviewed-by: Frank Li <Frank.Li@nxp.com> Tested-by: John Madieu <john.madieu.xa@bp.renesas.com> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/20260526084710.3491480-5-claudiu.beznea@kernel.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-04dmaengine: sh: rz-dmac: Use list_first_entry_or_null()Claudiu Beznea
Use list_first_entry_or_null() instead of open-coding it with a list_empty() check and list_first_entry(). This simplifies the code. Reviewed-by: Frank Li <Frank.Li@nxp.com> Tested-by: John Madieu <john.madieu.xa@bp.renesas.com> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/20260526084710.3491480-4-claudiu.beznea@kernel.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-04dmaengine: sh: rz-dmac: Fix incorrect NULL check for list_first_entry()Claudiu Beznea
list_first_entry() does not return NULL when the list is empty, making the existing NULL check invalid. Use list_first_entry_or_null() instead. Fixes: 21323b118c16 ("dmaengine: sh: rz-dmac: Add device_tx_status() callback") Cc: stable@vger.kernel.org Tested-by: John Madieu <john.madieu.xa@bp.renesas.com> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/20260526084710.3491480-3-claudiu.beznea@kernel.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-04dmaengine: sh: rz-dmac: Move interrupt request after everything is set upClaudiu Beznea
Once the interrupt is requested, the interrupt handler may run immediately. Since the IRQ handler can access channel->ch_base, which is initialized only after requesting the IRQ, this may lead to invalid memory access. Likewise, the IRQ thread may access uninitialized data (the ld_free, ld_queue, and ld_active lists), which may also lead to issues. Request the interrupts only after everything is set up. To keep the error path simpler, use dmam_alloc_coherent() instead of dma_alloc_coherent(). Fixes: 5000d37042a6 ("dmaengine: sh: Add DMAC driver for RZ/G2L SoC") Cc: stable@vger.kernel.org Reviewed-by: Frank Li <Frank.Li@nxp.com> Tested-by: John Madieu <john.madieu.xa@bp.renesas.com> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/20260526084710.3491480-2-claudiu.beznea@kernel.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-04PCI: qcom: Initialize DWC MSI lock for firmware-managed ECAM hostsYadu M G
A lockdep warning is observed during boot on a Qcom firmware-managed platform: INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. ... Call trace: register_lock_class+0x128/0x4d8 __lock_acquire+0x110/0x1db0 lock_acquire+0x278/0x3d8 _raw_spin_lock_irq+0x6c/0xc0 dw_pcie_irq_domain_alloc+0x48/0x190 irq_domain_alloc_irqs_parent+0x2c/0x48 msi_domain_alloc+0x90/0x160 ... dw_pcie_irq_domain_alloc() takes pp->lock while allocating MSI interrupts. pp->lock is normally initialized by dw_pcie_host_init(), but Qcom firmware-managed hosts use the ECAM init path instead: pci_host_common_ecam_create() pci_ecam_create() qcom_pcie_ecam_host_init() dw_pcie_msi_host_init() dw_pcie_allocate_domains() That path constructs a fresh struct dw_pcie_rp and calls dw_pcie_msi_host_init() directly, without going through dw_pcie_host_init(). As a result, pp->lock was not initialized, which triggers the warning. Initialize pp->lock in qcom_pcie_ecam_host_init() before registering the MSI domains so the firmware-managed ECAM path matches the normal DWC host initialization sequence. Fixes: 7d944c0f1469 ("PCI: qcom: Add support for Qualcomm SA8255p based PCIe Root Complex") Signed-off-by: Yadu M G <yadu.mg@oss.qualcomm.com> [mani: added fixes tag and CCed stable] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Cc: stable@kernel.org Link: https://patch.msgid.link/20260604122418.727274-1-yadu.mg@oss.qualcomm.com
2026-06-04power: supply: Add support for Surface RT battery and chargerJonas Schwöbel
Add support for Embedded Controller found in the Microsoft Surface RT and used to monitor battery cell and charger input status and properties. Controller works both for UEFI and APX booting. [wmjb: added POWER_SUPPLY_PROP_CHARGE_NOW support] Signed-off-by: Jethro Bull <jethrob@hotmail.com> Signed-off-by: Jonas Schwöbel <jonasschwoebel@yahoo.de> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com> Link: https://patch.msgid.link/20260507134608.76222-3-clamor95@gmail.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2026-06-04drm/v3d: Fix global performance monitor reference countingMaíra Canal
In the SET_GLOBAL ioctl, v3d_perfmon_find() bumps the reference count on the perfmon it returns, but v3d_perfmon_set_global_ioctl() and v3d_perfmon_delete() fail to release that reference on several paths: 1. v3d_perfmon_set_global_ioctl() leaks the reference on its error paths. 2. CLEAR_GLOBAL leaks both the find reference and the reference previously stashed in v3d->global_perfmon by the SET_GLOBAL ioctl that configured it. 3. Destroying a perfmon that is the current global perfmon leaks the reference stashed by the SET_GLOBAL ioctl. Release each of these references explicitly. Cc: stable@vger.kernel.org Fixes: c6eabbab359c ("drm/v3d: Add DRM_IOCTL_V3D_PERFMON_SET_GLOBAL") Reviewed-by: Iago Toral Quiroga <itoral@igalia.com> Link: https://patch.msgid.link/20260531-v3d-perfmon-lifetime-v2-1-60ed4485a203@igalia.com Signed-off-by: Maíra Canal <mcanal@igalia.com>
2026-06-04Merge drm/drm-next into drm-xe-nextThomas Hellström
Backmerging to bring in a build error fix to drm-xe-next. Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2026-06-04gpio: remove obsolete UAF FIXMEs from lookup pathsMarco Scardovi (scardracs)
The ACPI and swnode GPIO lookup backends both temporarily grab a reference to the gpio_device, resolve the descriptor, and then drop the reference before returning the descriptor to the caller. They carry FIXME comments warning that the descriptor is being returned without its backing device reference. However, the gpiod_find_and_request() core functionally prevents any use-after-free window by wrapping the entire lookup operation inside the gpio_devices_srcu read lock. The lookup functions are correct to drop their references since the caller (gpiod_request) will subsequently take its own permanent module and device references safely. Remove these obsolete FIXMEs to prevent misleading future subsystem developers. Assisted-by: Antigravity:gemini-3.5-flash Signed-off-by: Marco Scardovi <scardracs@disroot.org> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20260524162708.62949-3-scardracs@disroot.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-06-04gpio: core: fix const-correctness of gpio_chip_guardMarco Scardovi (scardracs)
The DEFINE_CLASS macro for gpio_chip_guard currently expects a non-const struct gpio_desc pointer. This prevents the guard from being used cleanly in fast paths that receive a const descriptor, forcing developers to fall back to open-coding the SRCU locks. Update the macro to accept a const struct gpio_desc pointer. This is valid because the actual targeted gpio_device pointer assignment does not drop const qualifiers on the target structure. Convert the open-coded SRCU locks in gpiod_get_raw_value_commit() and gpiod_to_irq() to use the guard, removing their legacy FIXME comments. Assisted-by: Antigravity:gemini-3.5-flash Signed-off-by: Marco Scardovi <scardracs@disroot.org> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20260524162708.62949-2-scardracs@disroot.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-06-04drm/xe/multi_queue: skip submit when primary queue is suspendedNiranjana Vishwanathapura
Return early in submit path when the multi-queue primary exec queue is suspended to avoid submitting while suspended. v2: Remove idle_skip_suspend fix as that feature is being reverted here https://patchwork.freedesktop.org/series/167262/ Fixes: bc5775c59258 ("drm/xe/multi_queue: Add GuC interface for multi queue support") Cc: stable@vger.kernel.org # v7.0+ Assisted-by: GitHub-Copilot:claude-sonnet-4.6 Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Link: https://patch.msgid.link/20260603233946.863663-2-niranjana.vishwanathapura@intel.com (cherry picked from commit b7fb55cc3364ca128cfff9d50649ffd4327cd01e) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-06-04drm/xe: Clear pending_disable before signaling suspend fenceTangudu Tilak Tirumalesh
In the schedule-disable done path for suspend, we signal the suspend fence before clearing pending_disable. That wakeup can let suspend_wait complete and resume be queued immediately. The resume path may then reach enable_scheduling() while pending_disable is still set and hit the !exec_queue_pending_disable(q) assertion. Fix this by clearing pending_disable before signaling the suspend fence, so any resumed transition observes a consistent state. Fixes: 87651f31ae4e ("drm/xe/guc_submit: fix race around suspend_pending") Cc: stable@vger.kernel.org # v7.0+ Signed-off-by: Tangudu Tilak Tirumalesh <tilak.tirumalesh.tangudu@intel.com> Reviewed-by: Thomas Hellstrom <thomas.hellstrom@linux.intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patch.msgid.link/20260603065217.3131066-3-tilak.tirumalesh.tangudu@intel.com (cherry picked from commit 4b1ae138b0e103d753773956a84eebc2edbf62c4) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-06-04Revert "drm/xe: Skip exec queue schedule toggle if queue is idle during suspend"Tangudu Tilak Tirumalesh
This reverts commit 8533051ce92015e9cc6f75e0d52119b9d91610b6. The idle-skip optimization bypasses GuC suspend, so the GPU may not perform the context switch that flushes TLB entries for invalidated userptr VMAs. In LR/preempt-fence VM mode, this can lead to missed TLB invalidation and page faults during userptr invalidation tests. Restore unconditional schedule toggling on suspend so the context-switch TLB flush is always performed. This optimization will be reintroduced with a fix that does not skip suspend in LR/preempt-fence VM mode. Fixes: 8533051ce920 ("drm/xe: Skip exec queue schedule toggle if queue is idle during suspend") Cc: stable@vger.kernel.org # v7.0+ Suggested-by: Thomas Hellstrom <thomas.hellstrom@linux.intel.com> Signed-off-by: Tangudu Tilak Tirumalesh <tilak.tirumalesh.tangudu@intel.com> Reviewed-by: Thomas Hellstrom <thomas.hellstrom@linux.intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patch.msgid.link/20260603065217.3131066-2-tilak.tirumalesh.tangudu@intel.com (cherry picked from commit 6a1e7934d9a6cf46aecae00a99c2603d1295e170) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-06-04Merge tag 'iwlwifi-next-2026-06-03' of ↵Johannes Berg
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next Miri Korenblit says: ==================== wifi: iwlwifi-next : updates - 2026-06-03 This pull request contains iwlwifi features and cleanups. Notably: - Bump max core version for BZ/SC/DR to 106. - Add KUnit tests for link grading, RSSI adjustment, and beacon handling; - Drop core101 support and remove TLC config v4/v5 compatibility code. - Fixes: Fix PCIe write pointer detection Fix STEP_URM register address Remove unneeded WoWLAN warning reduce NIC wakeups during dump. Revert MODULE_FIRMWARE relocation change ==================== Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-04Merge tag 'ath-next-20260602' of ↵Johannes Berg
git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath Jeff Johnson says: ================== ath.git patches for v7.2 (PR #3) In ath12k, add driver support for WDS mode. In ath11k and ath12k, a number of cleanups and minor bug fixes. ================== Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-04wifi: wlcore: enable the right set of ciphersAndreas Kemnade
The firmware version number check for IGTK introduced in commit c34dbc5900b0 ("wifi: wlcore: Add support for IGTK key") lets the amount of ciphers decrease on every boot of a too old firmware and that is practically happening. It also does not take into account other chips than the wl18xx. On some wl128x, the following can be observed when connecting via nm to a common ap: [ 484.113311] wlcore: WARNING could not set keys [ 484.117828] wlcore: ERROR Could not add or replace key [ 484.123016] wlan0: failed to set key (5, ff:ff:ff:ff:ff:ff) to hardware (-5) [ 484.123046] wlcore: Hardware recovery in progress. FW ver: Rev 7.3.10.0.142 [ 484.139923] wlcore: pc: 0x0, hint_sts: 0x00000048 count: 1 [ 484.145721] wlcore: down [ 484.148986] ieee80211 phy0: Hardware restart was requested [ 484.610473] wlcore: firmware booted (Rev 7.3.10.0.142) [ 484.633758] wlcore: Association completed. [ 484.690490] wlcore: ERROR command execute failure 14 [ 484.690490] ------------[ cut here ]------------ [ 484.700195] WARNING: drivers/net/wireless/ti/wlcore/main.c:872 at wl12xx_queue_recovery_work+0x64/0x74 [wlcore], CPU#0: kworker/0:0/892 This repeats endlessly. Always disable IGTK on wl12xx and fix the decrementing mess. Fixes: c34dbc5900b0 ("wifi: wlcore: Add support for IGTK key") Signed-off-by: Andreas Kemnade <andreas@kemnade.info> Link: https://patch.msgid.link/20260604103316.377251-1-andreas@kemnade.info Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-04ipmi: si: Use platform_get_irq_optional() to retrieve interruptRosen Penev
Use platform_get_irq_optional() to retrieve the interrupt resource instead of directly parsing and mapping the OF node via irq_of_parse_and_map(). This is the standard pattern for platform devices. irq_of_parse_and_map() requires ire_dispose_mapping(), which is missing. Assisted-by: Antigravity:Gemini-3.5-Flash Signed-off-by: Rosen Penev <rosenp@gmail.com> Message-ID: <20260603192511.6869-1-rosenp@gmail.com> [Handle a negative return from platform_get_irq_optional() to mean no interrupt is assigned.] Signed-off-by: Corey Minyard <corey@minyard.net>
2026-06-04drm/{i915, xe}: move more stuff to __intel_display_driver_pm_suspend()Jani Nikula
The calls leading up to __intel_display_driver_pm_suspend() are surrounded by near identical display calls. Move the calls inside __intel_display_driver_pm_suspend() to clean up and deduplicate. There's a slight functional change in that intel_display_driver_pm_suspend() returns early for !HAS_DISPLAY(). Assume this is what we want, and there are no cases where display engine is present but all pipes have been fused off. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/fdca3720537b6b79a754a83811d07b97d47e0db0.1780389001.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-06-04drm/xe/display: use intel_display_driver_pm_shutdown()Jani Nikula
Replace direct intel_display_driver_pm_suspend() and additional calls with intel_display_driver_shutdown(). This switches to use drm_atomic_helper_shutdown() instead of drm_atomic_helper_suspend(), which is the more appropriate thing to do anyway. Not calling intel_display_driver_pm_suspend() from the xe shutdown path unblocks further follow-up changes. There's a slight functional change in that intel_display_driver_shutdown() returns early for !HAS_DISPLAY(). Assume this is what we want, and there are no cases where display engine is present but all pipes have been fused off. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/e6783c063f8c0d4a2b413e550165896a3d977585.1780389001.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-06-04drm/i915/display: deduplicate suspend and shutdown a bitJani Nikula
intel_display_driver_shutdown() and intel_display_driver_pm_suspend() are quite similar. Abstract a shared function to call from both. This is intentionally just the first non-functional step. More gradual changes will follow. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/4d32548f99655650a9e53f3d33b8359998a00e6d.1780389001.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-06-04drm/i915: add intel_display_driver_shutdown()Jani Nikula
Add intel_display_driver_shutdown() to be called from the struct pci_driver .shutdown path. Initially, only migrate i915, as there are some subtle differences with xe that will be addressed later. Pick up as much as we can at this point without making major functional changes. There's a slight functional change in that intel_display_driver_shutdown() returns early for !HAS_DISPLAY(). Assume this is what we want, and there are no cases where display engine is present but all pipes have been fused off. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/b6a3ed62d11b4b4999611e9b34c0bd1c531c1069.1780389001.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-06-04drm/{i915,xe}: add intel_display_driver_shutdown_late()Jani Nikula
Add new function intel_display_driver_shutdown_late() to be called "later" in the struct pci_driver .shutdown hook. There's a slight functional change in that intel_display_driver_shutdown_late() returns early for !HAS_DISPLAY(). Assume this is what we want, and there are no cases where display engine is present but all pipes have been fused off. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/d200966191a3845e6b9586d20884e285670734d1.1780389001.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-06-04drm/{i915, xe}: add intel_display_driver_pm_{suspend_late, resume_early}()Jani Nikula
Add new functions intel_display_driver_pm_suspend_late() and intel_display_driver_pm_resume_early(), to be called from the corresponding struct dev_pm_ops hooks. There's a slight functional change for !HAS_DISPLAY() in that the new functions return early. Assume this is what we want, and there are no cases where display engine is present but all pipes have been fused off. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/a429a0ea7ac8e97a98c26ffe5be5db934267ec8d.1780389001.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-06-04drm/{i915, xe}: move more calls inside intel_display_driver_pm_resume()Jani Nikula
The intel_display_driver_pm_resume() calls are surrounded by near identical display calls. Move the calls inside intel_display_driver_pm_resume(). There's a slight functional change in that intel_display_driver_pm_resume() returns early for !HAS_DISPLAY(). Assume this is what we want, and there are no cases where display engine is present but all pipes have been fused off. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/2cb01e10de88e6436c54643acbcef2afd3188a58.1780389001.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-06-04drm/{i915, xe}: move more calls inside intel_display_driver_pm_suspend()Jani Nikula
The intel_display_driver_pm_suspend() calls are surrounded by near identical display calls. Move the calls inside intel_display_driver_pm_suspend(). There's a slight functional change in that intel_display_driver_pm_suspend() returns early for !HAS_DISPLAY(). Assume this is what we want, and there are no cases where display engine is present but all pipes have been fused off. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/82cfac0b966a8a82c8cf85e6b7b050223b7d5e33.1780389001.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-06-04drm/xe/display: relocate the xe_display_pm_runtime_*() functionsJani Nikula
Keep the xe_display_pm_runtime_*() functions together, in suspend/suspend_late/resume order. Also relocate the dependent d3cold functions near usage in the runtime pm functions. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Link: https://patch.msgid.link/3e7de41c1a27ef250eb9c35c4858120bc9846301.1780389001.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-06-04drm/xe/display: relocate the xe_display_shutdown*() functionsJani Nikula
Group the xe_display_shutdown() and xe_display_shutdown_late() functions together, away from the pm hooks. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Link: https://patch.msgid.link/ca79ec22c7d8961bc82debf2ccc9ece4d1c7c906.1780389001.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-06-04drm/xe/display: rename xe_display_pm_shutdown*() to xe_display_shutdown*()Jani Nikula
The shutdown functions get called from the struct pci_driver .shutdown hook, not through the struct dev_pm_ops hooks. Name accordingly, dropping the "pm" from the name, even if shutdown has a lot of similarities with suspend. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/8d5b5aa92cff77a99b3687c231a50ec576d6f37e.1780389001.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-06-04drm/i915/display: add "pm" to intel_display_driver_{suspend, resume}() namesJani Nikula
Start naming the functions that are supposed to be called from the struct dem_pm_ops hooks with intel_display_driver_pm_*() to distinguish them better from the rest. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/b4dd07b6375752900f583d56eda16a1c2a0b1e49.1780389001.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-06-04spi: cadence-xspi: Support 32bit and 64bit slave dma interfaceJisheng Zhang
The cdns xspi controller slave dma interface may support wider data width. Wider I/O width can benefit performance. We can know the width by checking the CTRL_FEATURES_REG's DMA_DATA_WIDTH bit, 0 means 32bit 1 means 64bit. A simple test with QSPI nor flash on one arm64 platform: Use 8bit slave dma data width (now): # dd if=/dev/mtdblock0 of=/dev/null bs=8192 count=1000 1000+0 records in 1000+0 records out 8192000 bytes (7.8MB) copied, 1.368735 seconds, 5.7MB/s Use 32bit slave dma data width: # dd if=/dev/mtdblock0 of=/dev/null bs=8192 count=1000 1000+0 records in 1000+0 records out 8192000 bytes (7.8MB) copied, 1.088787 seconds, 7.2MB/s Improved by 26.3%! Use 64bit slave dma data width: # dd if=/dev/mtdblock0 of=/dev/null bs=8192 count=1000 1000+0 records in 1000+0 records out 8192000 bytes (7.8MB) copied, 0.831104 seconds, 9.4MB/s Improved by 64.9%! Signed-off-by: Jisheng Zhang <jszhang@kernel.org> Link: https://patch.msgid.link/20260602235825.28614-1-jszhang@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2026-06-04net: bonding: fix NULL pointer dereference in bond_do_ioctl()ZhaoJinming
In bond_do_ioctl(), slave_dev is obtained via __dev_get_by_name() which can return NULL if the requested interface name does not exist. However, the subsequent slave_dbg() call is placed before the NULL check: slave_dev = __dev_get_by_name(net, ifr->ifr_slave); slave_dbg(bond_dev, slave_dev, "slave_dev=%p:\n", slave_dev); //here if (!slave_dev) return -ENODEV; The slave_dbg() macro expands to netdev_dbg(bond_dev, "(slave %s): " fmt, (slave_dev)->name, ...) which unconditionally dereferences slave_dev->name before the NULL check is performed. This results in a NULL pointer dereference kernel oops when a user calls bonding ioctl (e.g. SIOCBONDENSLAVE, SIOCBONDRELEASE, etc.) with a non-existent slave interface name. This is reachable from userspace via the bonding ioctl interface with CAP_NET_ADMIN capability, making it a potential local denial-of-service vector. Fix by moving the slave_dbg() call after the NULL check. Fixes: e2a7420df2e0 ("bonding/main: convert to using slave printk macros") Cc: stable@vger.kernel.org # v5.2+ Signed-off-by: ZhaoJinming <zhaojinming@uniontech.com> Link: https://patch.msgid.link/20260601085649.4029067-1-zhaojinming@uniontech.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-06-04ptp: Switch to ktime_get_snapshot_id() for pre/post timestampsThomas Gleixner
To prepare for a new PTP IOCTL, which exposes the raw counter value along with the requested system time snapshot, switch the pre/post time stamp sampling over to use ktime_get_snapshot_id() and fix up all usage sites. No functional change intended. The ptp_vmclock conversion was simplified by David Woodhouse. Signed-off-by: Thomas Gleixner <tglx@kernel.org> Tested-by: David Woodhouse <dwmw@amazon.co.uk> Tested-by: Arthur Kiyanovski <akiyano@amazon.com> Reviewed-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Acked-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Link: https://patch.msgid.link/20260529195558.149589566@kernel.org
2026-06-04wifi: iwlwifi: Use system_device_crosststamp::sys_systimeThomas Gleixner
sys_systime is an alias for sys_realtime. The latter will be removed so switch the code over to the new naming scheme. No functional change. Signed-off-by: Thomas Gleixner <tglx@kernel.org> Tested-by: Arthur Kiyanovski <akiyano@amazon.com> Reviewed-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20260529195557.946612509@kernel.org
2026-06-04ptp: Use system_device_crosststamp::sys_systimeThomas Gleixner
.. to prepare for cross timestamps with variable clock IDs. No functional change. Signed-off-by: Thomas Gleixner <tglx@kernel.org> Tested-by: David Woodhouse <dwmw@amazon.co.uk> Tested-by: Arthur Kiyanovski <akiyano@amazon.com> Reviewed-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20260529195557.897808371@kernel.org
2026-06-04virtio_rtc: Use provided clock ID for history snapshotThomas Gleixner
The PTP core indicates in system_device_crosststamp::clock_id the clock ID for which the system time stamp should be taken. That allows to utilize hardware timestamps with e.g. AUX clocks. Use ktime_get_snapshot_id() and hand the provided clock ID in. No functional change. Signed-off-by: Thomas Gleixner <tglx@kernel.org> Tested-by: Arthur Kiyanovski <akiyano@amazon.com> Reviewed-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Link: https://patch.msgid.link/20260529195557.744271454@kernel.org
2026-06-04net/mlx5: Use provided clock ID for history snapshotThomas Gleixner
The PTP core indicates in system_device_crosststamp::clock_id the clock ID for which the system time stamp should be taken. That allows to utilize hardware timestamps with e.g. AUX clocks. Use ktime_get_snapshot_id() and hand the provided clock ID in. No functional change. Signed-off-by: Thomas Gleixner <tglx@kernel.org> Tested-by: Arthur Kiyanovski <akiyano@amazon.com> Reviewed-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20260529195557.689836531@kernel.org
2026-06-04igc: Use provided clock ID for history snapshotThomas Gleixner
The PTP core indicates in system_device_crosststamp::clock_id the clock ID for which the system time stamp should be taken. That allows to utilize hardware timestamps with e.g. AUX clocks. Save the provided clock ID and use it in igc_phc_get_syncdevicetime() for taking the history snapshot. No functional change. Signed-off-by: Thomas Gleixner <tglx@kernel.org> Tested-by: Arthur Kiyanovski <akiyano@amazon.com> Reviewed-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20260529195557.637381831@kernel.org
2026-06-04ice/ptp: Use provided clock ID for history snapshotThomas Gleixner
The PTP core indicates in system_device_crosststamp::clock_id the clock ID for which then system time stamp should be taken. That allows to utilize hardware timestamps with e.g. AUX clocks. Save the provided clock ID and use it in ice_capture_crosststamp() for taking the history snapshot. No functional change. Signed-off-by: Thomas Gleixner <tglx@kernel.org> Tested-by: Arthur Kiyanovski <akiyano@amazon.com> Reviewed-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20260529195557.587226681@kernel.org
2026-06-04wifi: iwlwifi: Adopt PTP cross timestamps to core changesThomas Gleixner
iwlwifi only supports CLOCK_REALTIME timestamps and provides an incomplete result without system counter values etc. It also zeros struct system_device_crosststamp, which is already zeroed in the core and initialized with the clock ID. Remove the zeroing and reject any request for a clock ID other than REALTIME. Signed-off-by: Thomas Gleixner <tglx@kernel.org> Tested-by: Arthur Kiyanovski <akiyano@amazon.com> Reviewed-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20260529195557.535447186@kernel.org
2026-06-04timekeeping: Add CLOCK ID to system_device_crosststampThomas Gleixner
The normal capture for system/device cross timestamps is CLOCK_REALTIME, but that's meaningless for AUX clocks. Add a clock_id field to struct system_device_crosststamp and initialize it with CLOCK_REALTIME at the two places which prepare for cross timestamps. After the related code has been cleaned up, the core code will honor the clock_id field when calculating the system time from the system counter snapshot. No functional change. Signed-off-by: Thomas Gleixner <tglx@kernel.org> Tested-by: David Woodhouse <dwmw@amazon.co.uk> Tested-by: Arthur Kiyanovski <akiyano@amazon.com> Reviewed-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20260529195557.482153523@kernel.org
2026-06-04ptp: ptp_vmclock: Convert to ktime_get_snapshot_id()Thomas Gleixner
ktime_get_snapshot() is replaced by ktime_get_snapshot_id() which allows to request a particular CLOCK ID to be captured along with the clocksource counter. Convert vmclock over and use the new system_time_snapshot::systime field, which holds the system timestamp selected by the CLOCK ID argument. No functional change intended. Signed-off-by: Thomas Gleixner <tglx@kernel.org> Tested-by: David Woodhouse <dwmw@amazon.co.uk> Tested-by: Arthur Kiyanovski <akiyano@amazon.com> Reviewed-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20260529195557.281425262@kernel.org
2026-06-04nvme: export controller reconnect event count via sysfsNilay Shroff
When an NVMe-oF link goes down, the driver attempts to recover the connection by repeatedly reconnecting to the remote controller at configured intervals. A maximum number of reconnect attempts is also configured, after which recovery stops and the controller is removed if the connection cannot be re-established. The driver maintains a counter, nr_reconnects, which is incremented on each reconnect attempt. However if in case the reconnect is successful then this counter reset to zero. Moreover, currently, this counter is only reported via kernel log messages and is not exposed to userspace. Since dmesg is a circular buffer, this information may be lost over time. So introduce a new accumulator which accumulates nr_reconnect attempts and also expose this accumulator per-fabric ctrl via a new sysfs attribute reconnect_count, under diag attribute grroup to provide persistent visibility into the number of reconnect attempts made by the host. This information can help users diagnose unstable links or connectivity issues. Furthermore, this sysfs attribute is also writable so user may reset it to zero, if needed. The reconnect_count can also be consumed by monitoring tools such as nvme-top to improve controller-level observability. Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com> Signed-off-by: Nilay Shroff <nilay@linux.ibm.com> Signed-off-by: Keith Busch <kbusch@kernel.org>
2026-06-04nvme: export controller reset event count via sysfsNilay Shroff
The NVMe controller transitions into the RESETTING state during error recovery, link instability, firmware activation, or when a reset is explicitly triggered by the user. Expose a per-ctrl sysfs attribute reset_count, under diag attribute group to provide visibility into these RESETTING state transitions. Observing the frequency of reset events can help users identify issues such as PCIe errors or unstable fabric links. This counter is also writable thus allowing user to reset its value, if needed. This counter can also be consumed by monitoring tools such as nvme-top to improve controller-level observability. Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com> Signed-off-by: Nilay Shroff <nilay@linux.ibm.com> Signed-off-by: Keith Busch <kbusch@kernel.org>
2026-06-04nvme: export I/O failure count when no path is available via sysfsNilay Shroff
When I/O is submitted to the NVMe namespace head and no available path can handle the request, the driver fails the I/O immediately. Currently, such failures are only reported via kernel log messages, which may be lost over time since dmesg is a circular buffer. Add a new ns-head sysfs counter io_fail_no_available_path_count, under diag attribute group to expose the number of I/Os that failed due to the absence of an available path. This provides persistent visibility into path-related I/O failures and can help users diagnose the cause of I/O errors. This counter is also writable and so user may reset its value, if needed. This counter can also be consumed by monitoring tools such as nvme-top. Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com> Signed-off-by: Nilay Shroff <nilay@linux.ibm.com> Signed-off-by: Keith Busch <kbusch@kernel.org>
2026-06-04nvme: export I/O requeue count when no path is usable via sysfsNilay Shroff
When the NVMe namespace head determines that there is no currently available path to handle I/O (for example, while a controller is resetting/connecting or due to a transient link failure), incoming I/Os are added to the requeue list. Currently, there is no visibility into how many I/Os have been requeued in this situation. Add a new ns-head sysfs counter io_requeue_no_usable_path_count, under diag attribute group to expose the number of I/Os that were requeued due to the absence of an available path. This counter is also writable thus allowing user to reset it, if needed. This statistic can help users understand I/O slowdowns or stalls caused by temporary path unavailability, and can be consumed by monitoring tools such as nvme-top for real-time observability. Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com> Signed-off-by: Nilay Shroff <nilay@linux.ibm.com> Signed-off-by: Keith Busch <kbusch@kernel.org>