summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2025-10-13drm/amd/ras: Add mp1 v13_0 ras functionsYiPeng Chai
Add mp1 v13_0 ras functions. Signed-off-by: YiPeng Chai <YiPeng.Chai@amd.com> Reviewed-by: Tao Zhou <tao.zhou1@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-13drm/amdgpu: fix hung reset queue array memory allocationJonathan Kim
By design the MES will return an array result that is twice the number of hung doorbells it can report. i.e. if up k reported doorbells are supported, then the second half of the array, also of length k, holds the HQD information (type/queue/pipe) where queue 1 corresponds to index 0 and k, queue 2 corresponds to index 1 and k + 1 etc ... The driver will use the HDQ info to target queue/pipe reset for hardware scheduled user compute queues. Signed-off-by: Jonathan Kim <jonathan.kim@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-13drm/amd/ras: Add aca common ras functionsYiPeng Chai
Add aca common ras functions: 1. Aca hw init/fini. 2. Get ecc count of each ras block. 3. Update query ecc count from mp1. 4. Clear ras block ecc count. V3: Update the calling function. Signed-off-by: YiPeng Chai <YiPeng.Chai@amd.com> Reviewed-by: Tao Zhou <tao.zhou1@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-13drm/amdgpu: fix initialization of doorbell array for detect and hangJonathan Kim
Initialized doorbells should be set to invalid rather than 0 to prevent driver from over counting hung doorbells since it checks against the invalid value to begin with. Signed-off-by: Jonathan Kim <jonathan.kim@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-13drm/amd/ras: Add ras aca parser v1.0YiPeng Chai
Add ras aca parser v1.0. Signed-off-by: YiPeng Chai <YiPeng.Chai@amd.com> Reviewed-by: Tao Zhou <tao.zhou1@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-13drm/amdgpu: clean up amdgpu hmm range functionsSunil Khatri
Clean up the amdgpu hmm range functions for clearer definition of each. a. Split amdgpu_ttm_tt_get_user_pages_done into two: 1. amdgpu_hmm_range_valid: To check if the user pages are valid and update seq num 2. amdgpu_hmm_range_free: Clean up the hmm range and pfn memory. b. amdgpu_ttm_tt_get_user_pages_done and amdgpu_ttm_tt_discard_user_pages are similar function so remove discard and directly use amdgpu_hmm_range_free to clean up the hmm range and pfn memory. Suggested-by: Christian König <christian.koenig@amd.com> Signed-off-by: Sunil Khatri <sunil.khatri@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-13drm/amdgpu: use user provided hmm_range buffer in amdgpu_ttm_tt_get_user_pagesSunil Khatri
update the amdgpu_ttm_tt_get_user_pages and all dependent function along with it callers to use a user allocated hmm_range buffer instead hmm layer allocates the buffer. This is a need to get hmm_range pointers easily accessible without accessing the bo and that is a requirement for the userqueue to lock the userptrs effectively. Signed-off-by: Sunil Khatri <sunil.khatri@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-13drm/amdgpu: fix gfx12 mes packet status return checkJonathan Kim
GFX12 MES uses low 32 bits of status return for success (1 or 0) and high bits for debug information if low bits are 0. GFX11 MES doesn't do this so checking full 64-bit status return for 1 or 0 is still valid. Signed-off-by: Jonathan Kim <jonathan.kim@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2025-10-13drm/amdgpu: Fix NULL pointer dereference in VRAM logic for APU devicesJesse.Zhang
Previously, APU platforms (and other scenarios with uninitialized VRAM managers) triggered a NULL pointer dereference in `ttm_resource_manager_usage()`. The root cause is not that the `struct ttm_resource_manager *man` pointer itself is NULL, but that `man->bdev` (the backing device pointer within the manager) remains uninitialized (NULL) on APUs—since APUs lack dedicated VRAM and do not fully set up VRAM manager structures. When `ttm_resource_manager_usage()` attempts to acquire `man->bdev->lru_lock`, it dereferences the NULL `man->bdev`, leading to a kernel OOPS. 1. **amdgpu_cs.c**: Extend the existing bandwidth control check in `amdgpu_cs_get_threshold_for_moves()` to include a check for `ttm_resource_manager_used()`. If the manager is not used (uninitialized `bdev`), return 0 for migration thresholds immediately—skipping VRAM-specific logic that would trigger the NULL dereference. 2. **amdgpu_kms.c**: Update the `AMDGPU_INFO_VRAM_USAGE` ioctl and memory info reporting to use a conditional: if the manager is used, return the real VRAM usage; otherwise, return 0. This avoids accessing `man->bdev` when it is NULL. 3. **amdgpu_virt.c**: Modify the vf2pf (virtual function to physical function) data write path. Use `ttm_resource_manager_used()` to check validity: if the manager is usable, calculate `fb_usage` from VRAM usage; otherwise, set `fb_usage` to 0 (APUs have no discrete framebuffer to report). This approach is more robust than APU-specific checks because it: - Works for all scenarios where the VRAM manager is uninitialized (not just APUs), - Aligns with TTM's design by using its native helper function, - Preserves correct behavior for discrete GPUs (which have fully initialized `man->bdev` and pass the `ttm_resource_manager_used()` check). v4: use ttm_resource_manager_used(&adev->mman.vram_mgr.manager) instead of checking the adev->gmc.is_app_apu flag (Christian) Reviewed-by: Christian König <christian.koenig@amd.com> Suggested-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-13drm/amdgpu: hide VRAM sysfs attributes on GPUs without VRAMChristian König
Otherwise accessing them can cause a crash. Signed-off-by: Christian König <christian.koenig@amd.com> Tested-by: Mangesh Gadre <Mangesh.Gadre@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-13drm/amdgpu: fix bit shift logicSathishkumar S
BIT_ULL(n) sets nth bit, remove explicit shift and set the position Fixes: a7a411e24626 ("drm/amdgpu: fix shift-out-of-bounds in amdgpu_debugfs_jpeg_sched_mask_set") Signed-off-by: Sathishkumar S <sathishkumar.sundararaju@amd.com> Reviewed-by: Leo Liu <leo.liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-13drm/amd/powerplay: Fix CIK shutdown temperatureTimur Kristóf
Remove extra multiplication. CIK GPUs such as Hawaii appear to use PP_TABLE_V0 in which case the shutdown temperature is hardcoded in smu7_init_dpm_defaults and is already multiplied by 1000. The value was mistakenly multiplied another time by smu7_get_thermal_temperature_range. Fixes: 4ba082572a42 ("drm/amd/powerplay: export the thermal ranges of VI asics (V2)") Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/1676 Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-13drm/amdgpu: use atomic functions with memory barriers for vm fault infoGui-Dong Han
The atomic variable vm_fault_info_updated is used to synchronize access to adev->gmc.vm_fault_info between the interrupt handler and get_vm_fault_info(). The default atomic functions like atomic_set() and atomic_read() do not provide memory barriers. This allows for CPU instruction reordering, meaning the memory accesses to vm_fault_info and the vm_fault_info_updated flag are not guaranteed to occur in the intended order. This creates a race condition that can lead to inconsistent or stale data being used. The previous implementation, which used an explicit mb(), was incomplete and inefficient. It failed to account for all potential CPU reorderings, such as the access of vm_fault_info being reordered before the atomic_read of the flag. This approach is also more verbose and less performant than using the proper atomic functions with acquire/release semantics. Fix this by switching to atomic_set_release() and atomic_read_acquire(). These functions provide the necessary acquire and release semantics, which act as memory barriers to ensure the correct order of operations. It is also more efficient and idiomatic than using explicit full memory barriers. Fixes: b97dfa27ef3a ("drm/amdgpu: save vm fault information for amdkfd") Cc: stable@vger.kernel.org Signed-off-by: Gui-Dong Han <hanguidong02@gmail.com> Signed-off-by: Felix Kuehling <felix.kuehling@amd.com> Reviewed-by: Felix Kuehling <felix.kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-13drm/amdgpu: set an error on all fences from a bad contextAlex Deucher
When we backup ring contents to reemit after a queue reset, we don't backup ring contents from the bad context. When we signal the fences, we should set an error on those fences as well. v2: misc cleanups v3: add locking for fence error, fix comment (Christian) v4: fix wrap around, locking (Christian) Fixes: 77cc0da39c7c ("drm/amdgpu: track ring state associated with a fence") Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-13drm/amdgpu: handle wrap around in reemit handlingAlex Deucher
Compare the sequence numbers directly. Fixes: 77cc0da39c7c ("drm/amdgpu: track ring state associated with a fence") Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-13drm/amdgpu: fix handling of harvesting for ip_discovery firmwareAlex Deucher
Chips which use the IP discovery firmware loaded by the driver reported incorrect harvesting information in the ip discovery table in sysfs because the driver only uses the ip discovery firmware for populating sysfs and not for direct parsing for the driver itself as such, the fields that are used to print the harvesting info in sysfs report incorrect data for some IPs. Populate the relevant fields for this case as well. Fixes: 514678da56da ("drm/amdgpu/discovery: fix fw based ip discovery") Acked-by: Tom St Denis <tom.stdenis@amd.com> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-13drm/amdgpu: block CE CS if not explicitely allowed by module optionChristian König
The Constant Engine found on gfx6-gfx10 HW has been a notorious source of problems. RADV never used it in the first place, radeonsi only used it for a few releases around 2017 for gfx6-gfx9 before dropping support for it as well. While investigating another problem I just recently found that submitting to the CE seems to be completely broken on gfx9 for quite a while. Since nobody complained about that problem it most likely means that nobody is using any of the affected radeonsi versions on current Linux kernels any more. So to potentially phase out the support for the CE and eliminate another source of problems block submitting CE IBs unless it is enabled again using a debug flag. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Timur Kristóf <timur.kristof@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-13drm/amdgpu: remove two invalid BUG_ON()sChristian König
Those can be triggered trivially by userspace. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Timur Kristóf <timur.kristof@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-13drm/amd: Disable ASPM on SITimur Kristóf
Enabling ASPM causes randoms hangs on Tahiti and Oland on Zen4. It's unclear if this is a platform-specific or GPU-specific issue. Disable ASPM on SI for the time being. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-13drm/amd/pm: Disable MCLK switching on SI at high pixel clocksTimur Kristóf
On various SI GPUs, a flickering can be observed near the bottom edge of the screen when using a single 4K 60Hz monitor over DP. Disabling MCLK switching works around this problem. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-13Revert "drm/amd/display: Only restore backlight after amdgpu_dm_init or ↵Matthew Schwartz
dm_resume" This fix regressed the original issue that commit 7875afafba84 ("drm/amd/display: Fix brightness level not retained over reboot") solved, so revert it until a different approach to solve the regression that it caused with AMD_PRIVATE_COLOR is found. Fixes: a490c8d77d50 ("drm/amd/display: Only restore backlight after amdgpu_dm_init or dm_resume") Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4620 Cc: stable@vger.kernel.org Signed-off-by: Matthew Schwartz <matthew.schwartz@linux.dev> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-10-13drm/i915/fb: Fix the set_tiling vs. addfb race, againVille Syrjälä
intel_frontbuffer_get() is what locks out subsequent set_tiling changes to the bo. Thus the fence vs. modifier check must be done after intel_frontbuffer_get(), or else a concurrent set_tiling ioctl might sneak in and change the fence after the check has been done. Close the race again. See commit dd689287b977 ("drm/i915: Prevent concurrent tiling/framebuffer modifications") for the previous instance. v2: Reorder intel_user_framebuffer_destroy() to match the unwind (Jani) Cc: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Fixes: 10690b8a49bc ("drm/i915/display: Add intel_fb_bo_framebuffer_fini") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20251003145734.7634-3-ville.syrjala@linux.intel.com (cherry picked from commit 1d1e4ded216017f8febd91332ee337f0e0e79285) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-10-13drm/i915/frontbuffer: Move bo refcounting intel_frontbuffer_{get,release}()Ville Syrjälä
Currently xe's intel_frontbuffer implementation forgets to hold a reference on the bo. This makes the entire thing extremely fragile as the cleanup order now depends on bo references held by other things (namely intel_fb_bo_framebuffer_fini()). Move the bo refcounting to intel_frontbuffer_{get,release}() so that both i915 and xe do this the same way. I first tried to fix this by having xe do the refcounting from its intel_bo_set_frontbuffer() implementation (which is what i915 does currently), but turns out xe's drm_gem_object_free() can sleep and thus drm_gem_object_put() isn't safe to call while we hold fb_tracking.lock. Fixes: 10690b8a49bc ("drm/i915/display: Add intel_fb_bo_framebuffer_fini") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20251003145734.7634-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit eb4d490729a5fd8dc5a76d334f8d01fec7c14bbe) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-10-13drm/i915/guc: Skip communication warning on reset in progressZhanjun Dong
GuC IRQ and tasklet handler receive just single G2H message, and let other messages to be received from next tasklet. During this chained tasklet process, if reset process started, communication will be disabled. Skip warning for this condition. Fixes: 65dd4ed0f4e1 ("drm/i915/guc: Don't receive all G2H messages in irq handler") Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/15018 Signed-off-by: Zhanjun Dong <zhanjun.dong@intel.com> Reviewed-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://lore.kernel.org/r/20250929152904.269776-1-zhanjun.dong@intel.com (cherry picked from commit 604b5ee4a653a70979ce689dbd6a5d942eb016bf) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-10-13drm/xe/guc: Check GuC running state before deregistering exec queueShuicheng Lin
In normal operation, a registered exec queue is disabled and deregistered through the GuC, and freed only after the GuC confirms completion. However, if the driver is forced to unbind while the exec queue is still running, the user may call exec_destroy() after the GuC has already been stopped and CT communication disabled. In this case, the driver cannot receive a response from the GuC, preventing proper cleanup of exec queue resources. Fix this by directly releasing the resources when GuC is not running. Here is the failure dmesg log: " [ 468.089581] ---[ end trace 0000000000000000 ]--- [ 468.089608] pci 0000:03:00.0: [drm] *ERROR* GT0: GUC ID manager unclean (1/65535) [ 468.090558] pci 0000:03:00.0: [drm] GT0: total 65535 [ 468.090562] pci 0000:03:00.0: [drm] GT0: used 1 [ 468.090564] pci 0000:03:00.0: [drm] GT0: range 1..1 (1) [ 468.092716] ------------[ cut here ]------------ [ 468.092719] WARNING: CPU: 14 PID: 4775 at drivers/gpu/drm/xe/xe_ttm_vram_mgr.c:298 ttm_vram_mgr_fini+0xf8/0x130 [xe] " v2: use xe_uc_fw_is_running() instead of xe_guc_ct_enabled(). As CT may go down and come back during VF migration. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: stable@vger.kernel.org Cc: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20251010172529.2967639-2-shuicheng.lin@intel.com
2025-10-13accel/qaic: Add support to export dmabuf fdPranjal Ramajor Asha Kanojiya
Add support to export BO as DMABUF to enable userspace to reuse buffers and reduce number of copy. Signed-off-by: Pranjal Ramajor Asha Kanojiya <quic_pkanojiy@quicinc.com> Signed-off-by: Youssef Samir <youssef.abdulrahman@oss.qualcomm.com> Reviewed-by: Jeff Hugo <jeff.hugo@oss.qualcomm.com> Signed-off-by: Jeff Hugo <jeff.hugo@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251007053853.193608-1-youssef.abdulrahman@oss.qualcomm.com
2025-10-13Input: goodix - remove setting of RST pin to inputMartyn Welch
The reset line is being set to input on non-ACPI devices apparently to save power. This isn't being done on ACPI devices as it's been found that some ACPI devices don't have a pull-up resistor fitted. This can also be the case for non-ACPI devices, resulting in: [ 941.672207] Goodix-TS 1-0014: Error reading 10 bytes from 0x814e: -110 [ 942.696168] Goodix-TS 1-0014: Error reading 10 bytes from 0x814e: -110 [ 945.832208] Goodix-TS 1-0014: Error reading 10 bytes from 0x814e: -110 This behaviour appears to have been initialing introduced in ec6e1b4082d9. This doesn't seem to be based on information in either the GT911 or GT9271 datasheets cited as sources of information for this change. Thus it seems likely that it is based on functionality in the Android driver which it also lists. This behaviour may be viable in very specific instances where the hardware is well known, but seems unwise in the upstream kernel where such hardware requirements can't be guaranteed. Remove this over optimisation to improve reliability on non-ACPI devices. Signed-off-by: Martyn Welch <martyn.welch@collabora.com> Reviewed-by: Hans de Goede <hansg@kernel.org> Link: https://lore.kernel.org/r/20251009134138.686215-1-martyn.welch@collabora.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2025-10-13soc: apple: sart: drop device reference after lookupJohan Hovold
Holding a reference to a device does not prevent its driver data from going away so there is no point in keeping the reference after looking up the sart device. Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Neal Gompa <neal@gompa.dev> Signed-off-by: Sven Peter <sven@kernel.org>
2025-10-13soc: apple: mailbox: fix device leak on lookupJohan Hovold
Make sure to drop the reference taken to the mbox platform device when looking up its driver data. Note that holding a reference to a device does not prevent its driver data from going away so there is no point in keeping the reference. Fixes: 6e1457fcad3f ("soc: apple: mailbox: Add ASC/M3 mailbox driver") Cc: stable@vger.kernel.org # 6.8 Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Neal Gompa <neal@gompa.dev> Signed-off-by: Sven Peter <sven@kernel.org>
2025-10-13Input: goodix - add support for ACPI ID GDIX1003Hans de Goede
Some newer devices use an ACPI hardware ID of GDIX1003 for their Goodix touchscreen controller, instead of GDIX1001 / GDIX1002. Add GDIX1003 to the goodix_acpi_match[] table. Reported-by: Weikang Guo <guoweikang.kernel@gmail.com> Closes: https://lore.kernel.org/linux-input/20250225024409.1467040-1-guoweikang.kernel@gmail.com/ Tested-by: Weikang Guo <guoweikang.kernel@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20251013121022.44333-1-hansg@kernel.org Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2025-10-13gpio: grgpio: call request_irq after incrementing the reference countAlex Tran
Remove extraneous dropping of the lock just to call 'request_irq' and locking again afterwards. Increment reference count before calling 'request_irq'. Rollback reference count if 'request_irq' fails. Suggested-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Signed-off-by: Alex Tran <alex.t.tran@gmail.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-10-13EDAC/versalnet: Fix off by one in handle_error()Dan Carpenter
The priv->mci[] array has NUM_CONTROLLERS so this > comparison needs to be >= to prevent an out of bounds access. Fixes: d5fe2fec6c40 ("EDAC: Add a driver for the AMD Versal NET DDR controller") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Yazen Ghannam <yazen.ghannam@amd.com>
2025-10-13drm/xe/i2c: Wire up reset/postinstall for I2C IRQRaag Jadav
I2C IRQ needs to be routed to SGUnit or PUnit for the devices that support it. Wire up reset/postinstall handles for I2C IRQ to take care of this. Signed-off-by: Raag Jadav <raag.jadav@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20251011123509.3233213-3-raag.jadav@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-10-13drm/xe/i2c: Introduce xe_i2c_irq_present()Raag Jadav
In preparation of wider usecases which require checking for I2C IRQ presence, introduce xe_i2c_irq_present() helper. Signed-off-by: Raag Jadav <raag.jadav@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20251011123509.3233213-2-raag.jadav@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-10-13drm/xe: Sort include files alphabetically.Arun Abhishek Chowhan
Sort the include lines alphabetically, no impact on code behavior. Signed-off-by: Arun Abhishek Chowhan <arun.abhishek.chowhan@intel.com> Reviewed-by: Nitin Gote <nitin.r.gote@intel.com> Link: https://lore.kernel.org/r/20251013095914.3742505-1-arun.abhishek.chowhan@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-10-13firewire: core: handle device quirk of MOTU Audio ExpressTakashi Sakamoto
A commit 3a93d082bacf ("ALSA: firewire-motu: add support for MOTU Audio Express") describes a quirk of MOTU Audio Express. The device returns acknowledge packet with 0x10 as the pending state of any types of asynchronous request transaction. It is completely out of specification. This commit implements handling for that device-specific quirk. The quirk is detected after reading the root directory of configuration ROM. When processing the acknowledge code in 1394 OHCI AT context event handler, firewire-ohci module seeks the device instance of destination node by traversing device hierarchy. If the device has the quirk, the acknowledge code is replaced with the standard code. The 1394 OHCI AT context events occur for outgoing asynchronous request packets. The device traversal is safe since no new request initiators exist after the fw_card_instance has been invalidated. Link: https://lore.kernel.org/r/20251013140311.97159-3-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
2025-10-13firewire: core: detect device quirk when reading configuration ROMTakashi Sakamoto
Every time the bus manager runs, the cached configuration ROM content of the IRM device is investigated to detect device-specific quirks. This detection can be performed in advance when reading the configuration ROM. This commit adds device quirk flags to the fw_device structure, and initializes them after reading the bus information block of the configuration ROM. The quirk flags are immutable once the configuration ROM has been read. Although they are likely accessed concurrently only by the bus manager, this commit ensures safe access by preventing torn writes and reads using the WRITE_ONCE()/READ_ONCE() macros. Link: https://lore.kernel.org/r/20251013140311.97159-2-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
2025-10-13pinctrl: Demote subsystem banner messageLinus Walleij
There is no reason to print any "hello world" from pin control unless (maybe) if we are debugging. Drop the banner. Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2025-10-13spi: cadence-quadspi: Fix pm_runtime unbalance on dma EPROBE_DEFERMattijs Korpershoek
In csqspi_probe(), when cqspi_request_mmap_dma() returns -EPROBE_DEFER, we handle the error by jumping to probe_setup_failed. In that label, we call pm_runtime_disable(), even if we never called pm_runtime_enable() before. Because of this, the driver cannot probe: [ 2.690018] cadence-qspi 47040000.spi: No Rx DMA available [ 2.699735] spi-nor spi0.0: resume failed with -13 [ 2.699741] spi-nor: probe of spi0.0 failed with error -13 Only call pm_runtime_disable() if it was enabled by adding a new label to handle cqspi_request_mmap_dma() failures. Fixes: b07f349d1864 ("spi: spi-cadence-quadspi: Fix pm runtime unbalance") Signed-off-by: Mattijs Korpershoek <mkorpershoek@kernel.org> Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://patch.msgid.link/20251009-cadence-quadspi-fix-pm-runtime-v2-1-8bdfefc43902@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2025-10-13spi: spi-nxp-fspi: limit the clock rate for different sample clock source ↵Haibo Chen
selection For different sample clock source selection, the max frequency flexspi supported are different. For mode 0, max frequency is 66MHz. For mode 3, the max frequency is 166MHz. Refer to 3.9.9 FlexSPI timing parameters on page 65. https://www.nxp.com/docs/en/data-sheet/IMX8MNCEC.pdf Though flexspi maybe still work under higher frequency, but can't guarantee the stability. IC suggest to add this limitation on all SoCs which contain flexspi. Fixes: c07f27032317 ("spi: spi-nxp-fspi: add the support for sample data from DQS pad") Signed-off-by: Haibo Chen <haibo.chen@nxp.com> Link: https://patch.msgid.link/20250922-fspi-fix-v1-3-ff4315359d31@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-10-13spi: spi-nxp-fspi: add extra delay after dll lockedHan Xu
Due to the erratum ERR050272, the DLL lock status register STS2 [xREFLOCK, xSLVLOCK] bit may indicate DLL is locked before DLL is actually locked. Add an extra 4us delay as a workaround. refer to ERR050272, on Page 20. https://www.nxp.com/docs/en/errata/IMX8_1N94W.pdf Fixes: 99d822b3adc4 ("spi: spi-nxp-fspi: use DLL calibration when clock rate > 100MHz") Signed-off-by: Han Xu <han.xu@nxp.com> Signed-off-by: Haibo Chen <haibo.chen@nxp.com> Link: https://patch.msgid.link/20250922-fspi-fix-v1-2-ff4315359d31@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-10-13spi: spi-nxp-fspi: re-config the clock rate when operation require new clock ↵Haibo Chen
rate Current operation contain the max_freq, so new coming operation may use new clock rate, need to re-config the clock rate to match the requirement. Fixes: 26851cf65ffc ("spi: nxp-fspi: Support per spi-mem operation frequency switches") Signed-off-by: Haibo Chen <haibo.chen@nxp.com> Link: https://patch.msgid.link/20250922-fspi-fix-v1-1-ff4315359d31@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-10-13spi: Merge up v6.18-rc1Mark Brown
Ensure my CI has a sensible baseline.
2025-10-13rpmb: move rpmb_frame struct and constants to common headerBean Huo
Move struct rpmb_frame and RPMB operation constants from MMC block driver to include/linux/rpmb.h for reuse across different RPMB implementations (UFS, NVMe, etc.). Signed-off-by: Bean Huo <beanhuo@micron.com> Reviewed-by: Avri Altman <avri.altman@sandisk.com> Acked-by: Jens Wiklander <jens.wiklander@linaro.org> Reviewed-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2025-10-13pinctrl: mediatek: mt8189: align register base names to dt-bindings onesLouis-Alexis Eyraud
The mt8189-pinctrl driver requires to probe that a device tree uses in the device node the same names than mt8189_pinctrl_register_base_names array. But they are not matching the required ones in the "mediatek,mt8189-pinctrl" dt-bindings, leading to possible dtbs check issues. The mt8189_pinctrl_register_base_names entry order is also different. So, align all mt8189_pinctrl_register_base_names entry names and order on dt-bindings. Fixes: a3fe1324c3c5 ("pinctrl: mediatek: Add pinctrl driver for mt8189") Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2025-10-13pinctrl: mediatek: mt8196: align register base names to dt-bindings onesLouis-Alexis Eyraud
The mt8196-pinctrl driver requires to probe that a device tree uses in the device node the same names than mt8196_pinctrl_register_base_names array. But they are not matching the required ones in the "mediatek,mt8196-pinctrl" dt-bindings, leading to possible dtbs check issues. So, align all mt8196_pinctrl_register_base_names entries on dt-bindings ones. Fixes: f7a29377c253 ("pinctrl: mediatek: Add pinctrl driver on mt8196") Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2025-10-13spi: offload: Add offset parameterAxel Haslam
Add an offset parameter that can be passed in the periodic trigger. This is useful for example when ADC drivers implement a separate periodic signal to trigger conversion and need offload to read the result with some delay. While at it, add some documentation to offload periodic trigger parameters. Reviewed-by: David Lechner <dlechner@baylibre.com> Signed-off-by: Axel Haslam <ahaslam@baylibre.com> Signed-off-by: Marcelo Schmitt <marcelo.schmitt@analog.com> Link: https://patch.msgid.link/cd315e95c0bd8523f00e91c400abcd6a418e5924.1759760519.git.marcelo.schmitt@analog.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-10-13spi: aspeed: Only map necessary address window regionChin-Ting Kuo
Previously, the driver mapped the entire SPI address decoding region during probe. On systems with small flash or limited memory, this could lead to excessive memory usage or allocation failures. This patch changes the strategy to initially map a small address window for SPI flash device probing. After determining each chip select's flash size, the driver unmaps the temporary region and remaps only the required address window accordingly. Signed-off-by: Chin-Ting Kuo <chin-ting_kuo@aspeedtech.com> Link: https://patch.msgid.link/20251001112605.1130723-7-chin-ting_kuo@aspeedtech.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-10-13spi: aspeed: Add per-platform adjust_window callback for decoding rangeChin-Ting Kuo
Different ASPEED SoCs have specific limitations on SPI address decoding, such as total range size, minimum window size per CS, and alignment requirements. The original adjustment logic only handles simple cases and could fail in more complex setups found in advanced board designs, e.g., small flash on CS0 and large flash on CS1, or when the total physical flash size exceeds the decoding range supported by the SPI controller. This patch introduces a per-platform adjust_window callback to handle these constraints properly. Each platform defines its own logic to adjust decoding ranges, trim excess size, and ensure alignment. If trimming is required, the affected CS will fall back to user mode access to ensure the entire flash remains accessible from the MTD layer. Signed-off-by: Chin-Ting Kuo <chin-ting_kuo@aspeedtech.com> Link: https://patch.msgid.link/20251001112605.1130723-6-chin-ting_kuo@aspeedtech.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-10-13spi: aspeed: Centralize address decoding region managementChin-Ting Kuo
The original approach to handling address decoding overlaps was to trim the next region directly. If the next CS's decoding range was fully overlapped by the current one, it would be forcibly closed by trimming its size to zero. This could lead expected behavior, especially on the platform with multiple flashes layout. To solve improper trimming problem, this patch collects the required address decoding size at each stage, then, (re-)arragne address decoding region to each CS centrally with knowing the total AHB decoding size. If a segment register cannot be updated (e.g. due to bootloader write protection), the original value is kept to avoid breaking access and an error is reported if the total decoding size of all CS exceeds the total AHB decoding size. Signed-off-by: Chin-Ting Kuo <chin-ting_kuo@aspeedtech.com> Link: https://patch.msgid.link/20251001112605.1130723-5-chin-ting_kuo@aspeedtech.com Signed-off-by: Mark Brown <broonie@kernel.org>
generated by cgit v1.2.3 (git 2.25.1) at 2026-09-13 22:59:51 +0000