| Age | Commit message (Collapse) | Author |
|
amdxdna_cmd_submit() calls xdna->dev_info->ops->cmd_submit()
unconditionally, but only aie2_dev_ops defines that callback.
aie4_vf_ops (the AIE4 SR-IOV virtual function) does not, so a user
AMDXDNA_EXEC_CMD ioctl on an AIE4 device reaches a NULL function-pointer
call and oopses the kernel. AIE4 submits work through a mapped user queue
and doorbell, not this ioctl path.
Reject the submission early with -EOPNOTSUPP when the device provides no
cmd_submit op, so the shared EXEC ioctl is a clean no-op on such devices.
Fixes: aac243092b70 ("accel/amdxdna: Add command execution")
Cc: stable@vger.kernel.org
Found by 0sec automated security-research tooling (https://0sec.ai).
Assisted-by: 0sec:claude-opus-4-8
Signed-off-by: Doruk Tan Ozturk <doruk@0sec.ai>
Reviewed-by: Lizhi Hou <lizhi.hou@amd.com>
Signed-off-by: Lizhi Hou <lizhi.hou@amd.com>
Link: https://patch.msgid.link/20260713173030.87541-3-doruk@0sec.ai
|
|
amdxdna_drm_submit_execbuf() passes the user-supplied command BO handle
straight into amdxdna_cmd_submit() with drv_cmd == NULL. When the handle
is AMDXDNA_INVALID_BO_HANDLE (0), the block that fetches job->cmd_bo is
skipped, leaving it NULL, and no check rejects it on the user path (the
!job->cmd_bo guard lives inside the != INVALID branch).
The job is then armed and pushed to the DRM scheduler.
aie2_sched_job_run() takes the drv_cmd == NULL path and calls
amdxdna_cmd_set_state(job->cmd_bo) -> amdxdna_gem_vmap(NULL) ->
to_gobj(NULL)->dev, a NULL pointer dereference in the drm_sched worker.
A process with access to the accel node on a system with a probed AMD NPU
can trigger a kernel oops with a single AMDXDNA_EXEC_CMD ioctl
(cmd_handles = 0).
Only internal driver commands (SYNC_DEBUG_BO / ATTACH_DEBUG_BO)
legitimately pass AMDXDNA_INVALID_BO_HANDLE, and they always set drv_cmd.
Reject the invalid handle for user submissions (drv_cmd == NULL) at the
submit choke point so every user path is covered.
Fixes: aac243092b70 ("accel/amdxdna: Add command execution")
Cc: stable@vger.kernel.org
Found by 0sec automated security-research tooling (https://0sec.ai).
Assisted-by: 0sec:claude-opus-4-8
Signed-off-by: Doruk Tan Ozturk <doruk@0sec.ai>
Reviewed-by: Lizhi Hou <lizhi.hou@amd.com>
Signed-off-by: Lizhi Hou <lizhi.hou@amd.com>
Link: https://patch.msgid.link/20260713173030.87541-2-doruk@0sec.ai
|
|
Address some comments from Jonathan that were missed in the merged
series. Fix line wrapping in fsdev_dax_recovery_write() and
fsdev_dax_zero_page_range() signatures.
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Reviewed-by: Alison Schofield <alison.schofield@intel.com>
Signed-off-by: John Groves <john@groves.net>
Link: https://patch.msgid.link/0100019ecc09f607-b558c192-72fc-4c2d-9f64-3b82796e7dd4-000000@email.amazonses.com
Signed-off-by: Alison Schofield <alison.schofield@intel.com>
|
|
Clear holder_ops before holder_data so that a concurrent fs_dax_get()
cannot have its newly installed holder_ops overwritten. cmpxchg()
provides release ordering on weakly-ordered architectures, ensuring the
WRITE_ONCE(holder_ops, NULL) store is visible to any CPU that observes
the holder_data release.
Add a WARN_ON() that fires only when the cmpxchg observes a non-NULL
value that is not @holder, i.e. fs_put_dax() called by something that
is not the current holder. That is an API contract violation; the
WARN_ON() does not prevent the damage but makes the bug visible.
A NULL cmpxchg result is deliberately tolerated: kill_dax() clears
holder_data while a holder is still attached when a device is removed
out from under a mounted filesystem (after delivering MF_MEM_PRE_REMOVE).
The holder's subsequent fs_put_dax() - e.g. xfs_free_buftarg() after a
forced shutdown - then legitimately finds holder_data already NULL, so
warning on that case would turn supported device removal into a splat
(or a panic with panic_on_warn).
Also add a kerneldoc comment documenting that fs_put_dax() must only
be called by the current holder.
Fixes: eec38f5d86d27 ("dax: Add fs_dax_get() func to prepare dax for fs-dax usage")
Signed-off-by: John Groves <john@groves.net>
Reviewed-by: Alison Schofield <alison.schofield@intel.com>
Link: https://patch.msgid.link/0100019ecc09dcab-2f4aa175-0b84-4b36-9e54-ebff302ebb0a-000000@email.amazonses.com
Signed-off-by: Alison Schofield <alison.schofield@intel.com>
|
|
dax_holder_notify_failure() reads dax_dev->holder_ops twice without
READ_ONCE() -- once for the NULL check and once for the indirect
notify_failure() call. A concurrent fs_put_dax() can clear holder_ops
between the two reads, so the check can observe a non-NULL pointer while
the call dereferences NULL. (kill_dax() also clears holder_ops, but only
after synchronize_srcu(), so it cannot race a reader that is inside
dax_read_lock(); fs_put_dax() does no such synchronization.)
Fetch holder_ops once into a local with READ_ONCE() so the NULL check and
the indirect call observe the same value.
Fixes: 8012b86608552 ("dax: introduce holder for dax_device")
Suggested-by: Richard Cheng <icheng@nvidia.com>
Reviewed-by: Richard Cheng <icheng@nvidia.com>
Signed-off-by: John Groves <john@groves.net>
Link: https://patch.msgid.link/0100019ecc09bb56-5ecc9c6b-35ba-44f8-b112-921b01b34478-000000@email.amazonses.com
Signed-off-by: Alison Schofield <alison.schofield@intel.com>
|
|
Convert the WARN_ON to a fatal error when pgmap_phys > phys. This
condition means the remapped region starts after the device's data
region, which is an impossible state. Previously the probe continued
with data_offset=0, leaving virt_addr silently misaligned. Now probe
returns -EINVAL with a diagnostic message.
Fixes: 759455848df0b ("dax: Save the kva from memremap")
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Reviewed-by: Alison Schofield <alison.schofield@intel.com>
Reviewed-by: Pankaj Gupta <pankaj.gupta@amd.com>
Signed-off-by: John Groves <john@groves.net>
Link: https://patch.msgid.link/0100019ecc0999fa-97574544-8b6b-46cf-9f33-423abdbeee7f-000000@email.amazonses.com
Signed-off-by: Alison Schofield <alison.schofield@intel.com>
|
|
Use __va(phys) instead of virt_addr + linear_offset for the kaddr
return in __fsdev_dax_direct_access(). The previous code added a
device-linear byte offset to virt_addr (which is __va of ranges[0]),
but for multi-range devices with physical gaps between ranges, this
linear arithmetic crosses the gap and produces a wrong kernel virtual
address. Using __va(phys) where phys comes from dax_pgoff_to_phys()
is correct for any range layout because the direct map translates
each physical address independently.
This leaves dev_dax->virt_addr write-only, so remove the field
(suggested by Dave Jiang).
Fixes: 759455848df0b ("dax: Save the kva from memremap")
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Reviewed-by: Alison Schofield <alison.schofield@intel.com>
Signed-off-by: John Groves <john@groves.net>
Link: https://patch.msgid.link/0100019ecc096de8-8bc254a7-d2cc-44b6-82b1-1394fda8bb41-000000@email.amazonses.com
Signed-off-by: Alison Schofield <alison.schofield@intel.com>
|
|
fsdev_dax_probe() sets pgmap->ops = &fsdev_pagemap_ops and
pgmap->owner = dev_dax, but nothing ever clears them. For a dynamic
device the pgmap is devm-allocated and freed on unbind, so this is
harmless. For a static device the pgmap is the shared, long-lived one
owned by the dax bus (kill_dev_dax() only NULLs dev_dax->pgmap for the
non-static case), and device.c's probe sets only pgmap->type, never
clearing ops/owner.
So after fsdev unbinds a static device the stale fsdev_pagemap_ops
survives on the shared pgmap. If the device is then rebound to
device_dax (MEMORY_DEVICE_GENERIC, which installs no ->memory_failure),
or the fsdev_dax module is unloaded, a subsequent memory_failure on that
pgmap dispatches through the stale -- and possibly freed -- handler.
Register a devm action that clears pgmap->ops and pgmap->owner on unbind,
symmetric with setting them at probe, so the pgmap carries no fsdev state
once fsdev is detached.
Suggested-by: Richard Cheng <icheng@nvidia.com>
Fixes: d5406bd458b0a ("dax: add fsdev.c driver for fs-dax on character dax")
Signed-off-by: John Groves <john@groves.net>
Reviewed-by: Richard Cheng <icheng@nvidia.com>
Link: https://patch.msgid.link/0100019ecc094b6e-fc163bde-0396-4a33-909f-fb88e740be27-000000@email.amazonses.com
Signed-off-by: Alison Schofield <alison.schofield@intel.com>
|
|
After the dynamic path set dev_dax->pgmap, any later probe failure left
dev_dax->pgmap dangling: devres frees the devm_kzalloc'd pgmap on probe
failure, and subsequent probe attempts would hit the "dynamic-dax with
pre-populated page map" check and fail permanently.
Factor pgmap acquisition out into fsdev_acquire_pgmap(), and defer the
dev_dax->pgmap assignment until probe can no longer fail. A failed probe
now never publishes the pointer at all, so there is nothing to unwind.
This also matches kill_dev_dax(), which already clears the dynamic pgmap
pointer on unbind: dev_dax->pgmap is now non-NULL only while the pgmap
is actually valid.
Refactor suggested by Dave Jiang.
Fixes: d5406bd458b0a ("dax: add fsdev.c driver for fs-dax on character dax")
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: John Groves <john@groves.net>
Link: https://patch.msgid.link/0100019ecc092ca1-ffc7a5fd-1252-4be5-882c-fd5efdc102a9-000000@email.amazonses.com
Signed-off-by: Alison Schofield <alison.schofield@intel.com>
|
|
Clear pgmap->vmemmap_shift for static DAX devices. When rebinding a static
device from device_dax (which may set vmemmap_shift based on alignment) to
fsdev_dax, the stale vmemmap_shift persists on the shared pgmap. Explicitly
zero it before devm_memremap_pages() so the vmemmap is built for order-0
folios as fsdev requires.
Fixes: d5406bd458b0a ("dax: add fsdev.c driver for fs-dax on character dax")
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Reviewed-by: Alison Schofield <alison.schofield@intel.com>
Signed-off-by: John Groves <john@groves.net>
Link: https://patch.msgid.link/0100019ecc090eea-7c46f51e-5393-402c-850d-78059bb6d343-000000@email.amazonses.com
Signed-off-by: Alison Schofield <alison.schofield@intel.com>
|
|
Fix memory_failure offset calculation for multi-range devices. The old
code subtracted ranges[0].range.start from the faulting PFN's physical
address, which produces an incorrect (inflated) logical offset when the
PFN falls in ranges[1] or beyond due to physical gaps between ranges.
Add fsdev_pfn_to_offset() to walk the range list and compute the correct
device-linear byte offset relative to ranges[0].start (the device data
start) -- the base the holder (xfs, famfs) maps from -- for both static
and dynamic devices.
V5 walked the pagemap's immutable pgmap->ranges[] instead, to avoid
reading the mutable dev_dax->ranges[] from this callback. That had a
different problem: it regressed static devices, where pgmap->ranges[0].start
can sit data_offset below the data start, so the reported offset came out
data_offset too high and the holder would act on the wrong blocks. For
dynamic devices the two arrays are identical, so pgmap->ranges[] only ever
helped the dynamic case while breaking the static one. Walk
dev_dax->ranges[] instead. (Richard Cheng spotted the static regression.)
Reading dev_dax->ranges[] here may race a concurrent krealloc() of the
range array via sysfs (mapping_store(), under dax_region_rwsem, which
this ->memory_failure callback does not hold). That exposure is
pre-existing -- the original single-range code read dev_dax->ranges[0]
locklessly as well -- so this patch does not make it worse; a proper fix
(locking or snapshotting) belongs in a separate change.
Fixes: d5406bd458b0a ("dax: add fsdev.c driver for fs-dax on character dax")
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Reviewed-by: Alison Schofield <alison.schofield@intel.com>
Signed-off-by: John Groves <john@groves.net>
Reviewed-by: Richard Cheng <icheng@nvidia.com>
Link: https://patch.msgid.link/0100019ecc08d74f-ec0d09b8-11e9-4e5b-af48-8c6d382af486-000000@email.amazonses.com
Signed-off-by: Alison Schofield <alison.schofield@intel.com>
|
|
The comment in dax_folio_reset_order() claims that DAX maintains an
invariant where folio->share != 0 only when folio->mapping == NULL,
implying folio->share is zero whenever mapping is non-NULL. This is
misleading because folio->share and folio->index are a union -- for
non-shared folios with mapping != NULL, reading folio->share returns
the file page offset (folio->index), which is typically non-zero.
Reword the comment to accurately describe the union aliasing: the
assignment clears whichever interpretation of the union word is active
(index for non-shared folios, share for shared folios), which is correct
because the folio is being released in either case.
No functional change -- the code was already correct, only the
justification was wrong.
Fixes: 59eb73b98ae0b ("dax: Factor out dax_folio_reset_order() helper")
Reviewed-by: Jonathan Cameron <jic23@kernel.org>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Reviewed-by: Alison Schofield <alison.schofield@intel.com>
Signed-off-by: John Groves <john@groves.net>
Link: https://patch.msgid.link/0100019ecc08b8cd-4ee80eeb-1341-4f67-8478-7298129440e9-000000@email.amazonses.com
Signed-off-by: Alison Schofield <alison.schofield@intel.com>
|
|
The BTT info block's nfree field, the number of reserve free blocks, is
read from the medium without validation. btt_freelist_init() and
btt_rtt_init() size the per-lane freelist[] and rtt[] arrays by nfree,
but the I/O path indexes them by the lane from nd_region_acquire_lane(),
which is bounded by nd_region->num_lanes (ND_MAX_LANES), not by nfree.
A crafted or foreign arena whose nfree is below the lane count makes
freelist[lane]/rtt[lane] run past the allocation: an out-of-bounds write.
btt.rst documents the nlanes = min(nfree, num_cpus) invariant, which the
code does not currently honor: num_lanes is ND_MAX_LANES regardless of
nfree. Reject an arena whose nfree is below num_lanes at discovery,
before the per-lane arrays are allocated, enforcing that invariant.
Fixes: 5212e11fde4d ("nd_btt: atomic sector updates")
Cc: stable@vger.kernel.org
Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me>
Reviewed-by: Alison Schofield <alison.schofield@intel.com>
Tested-by: Alison Schofield <alison.schofield@intel.com>
Link: https://patch.msgid.link/20260620-b4-disp-88b2514b-v1-1-3834e707d232@proton.me
Signed-off-by: Alison Schofield <alison.schofield@intel.com>
|
|
For a v1.2+ index, __nd_label_validate() computes the label size as
1 << (7 + nsindex[i]->labelsize), where labelsize is a u8 read from
the label storage medium. A value of 25 or more makes the shift count
reach or exceed the width of int -- undefined behavior -- and 24 already
shifts into the sign bit. Only 0 (128-byte) and 1 (256-byte) are valid.
Reject a labelsize above 1 before the shift. The result was rejected by
the following size comparison anyway, so this only removes the undefined
shift on a crafted or corrupted medium; conforming labels are unaffected.
Fixes: 564e871aa66f ("libnvdimm, label: add v1.2 nvdimm label definitions")
Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me>
Reviewed-by: Alison Schofield <alison.schofield@intel.com>
Link: https://patch.msgid.link/20260624-b4-disp-d8279485-v3-2-cdb6cab28b41@proton.me
Signed-off-by: Alison Schofield <alison.schofield@intel.com>
|
|
The on-media namespace index field nslot is a u32 read from the DIMM
label storage area. __nd_label_validate() bounds it against the config
area size, but sizeof_namespace_label() returns unsigned, so the product
nslot * label_size is evaluated in 32-bit and wraps modulo 2^32 before
the comparison. A crafted nslot passes the bound and is then used as the
loop trip count in nd_label_data_init(), whose memset() walks off the end
of the config_size buffer: an out-of-bounds write.
The field is not trusted -- it comes from the medium, or from userspace
via ND_CMD_SET_CONFIG_DATA. Evaluate the product in 64-bit so the bound
check is exact; conforming labels are unaffected.
The check was safe when introduced by commit 4a826c83db4e ("libnvdimm:
namespace indices: read and validate"): it multiplied by sizeof(struct
nd_namespace_label), a size_t, so on a 64-bit build the product did not
wrap. Commit 564e871aa66f ("libnvdimm, label: add v1.2 nvdimm label
definitions") narrowed it to 32 bits when the label size became a runtime
value read via sizeof_namespace_label().
Fixes: 564e871aa66f ("libnvdimm, label: add v1.2 nvdimm label definitions")
Cc: stable@vger.kernel.org
Reviewed-by: Alison Schofield <alison.schofield@intel.com>
Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me>
Link: https://patch.msgid.link/20260624-b4-disp-d8279485-v3-1-cdb6cab28b41@proton.me
Signed-off-by: Alison Schofield <alison.schofield@intel.com>
|
|
vfree() safely handles NULL pointers, so the explicit NULL check
before calling vfree() is unnecessary.
This issue was reported by ifnullfree.cocci.
Signed-off-by: Mohammad Shahid <mdshahid03@gmail.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Link: https://patch.msgid.link/20260703135513.75840-1-mdshahid03@gmail.com
Signed-off-by: Alison Schofield <alison.schofield@intel.com>
|
|
UMC error injection on MI300 series is dispatched by the RAS TA using
the injection method; only the "coherent" methods are address based,
the single-shot/persistent/ac-parity ones ignore the address.
The debugfs control path validated the injection address against the
bad page list for every UMC injection. On uniras (SMU v13+) devices the
address is now validated by the ras_mgr inject handler, so the legacy
debugfs bad page check only runs on the legacy RAS path; other ASICs
keep injecting by address.
In the ras_mgr handler an injection is treated as non address-based only
when userspace passes the U64_MAX sentinel address and the method is a
non-address method. In that case the address is cleared to 0 and the bad
page / range validation is skipped; otherwise the injection address is
validated as before.
Signed-off-by: Stanley.Yang <Stanley.Yang@amd.com>
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
drop debug_enable_ras_aca debug mask flag
Signed-off-by: Ce Sun <cesun102@amd.com>
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
avoid sysfs node creation faults when performing NPS mode switching
Signed-off-by: Ce Sun <cesun102@amd.com>
Reviewed-by: Tao Zhou <tao.zhou1@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
amdgpu_dm_connector_atomic_check() checks whether the old or new
connector state returned by the atomic helpers is NULL before using
those pointers.
However, new_con_state is already dereferenced while initializing crtc,
before the NULL check is reached. If
drm_atomic_get_new_connector_state() returns NULL, the function can
dereference the NULL pointer before the WARN_ON() check can handle it.
Declare crtc first and initialize it only after the NULL check has
succeeded.
Fixes: 1e5e8d672fec ("drm/amd/display: Avoid a NULL pointer dereference")
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://patch.msgid.link/20260708072751.724400-1-lgs201920130244@gmail.com
(ML: adjust for movement to amdgpu_dm_connector.c)
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
total_cwsr_size was computed in 32-bit before being used as a BO/SVM
allocation size.
With large ctx_save_restore_area_size and debug_memory_size
multiplied by the XCC count, the product can wrap,
yielding an undersized CWSR save area that firmware later overruns.
Promote total_cwsr_size to u64 and use check_add_overflow()/
check_mul_overflow() in both kfd_queue_acquire_buffers() and
kfd_queue_release_buffers().
Signed-off-by: Yongqiang Sun <Yongqiang.Sun@amd.com>
Reviewed-by: Philip Yang <philip.yang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[WHAT]
Add KUnit coverage for dm_helpers_read_mccs_caps and
dm_helpers_mccs_vcp_set, including the DP/HDMI/legacy-PCON selection,
the i2c VCP request and set packets and the retry-failure paths.
Assisted-by: Copilot:Claude-Opus-4.8
Reviewed-by: Bhawanpreet Lakha <bhawanpreet.lakha@amd.com>
Signed-off-by: Alex Hung <alex.hung@amd.com>
Signed-off-by: George Zhang <george.zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[WHAT]
Add KUnit coverage for dm_helpers_submit_i2c,
dm_helper_dmub_aux_transfer_sync, the empty stub helpers, the MST
null-connector early returns, dm_helpers_dmub_outbox_interrupt_control,
dm_helpers_mst_enable_stream_features and
dm_helpers_enable_periodic_detection.
Assisted-by: Copilot:Claude-Opus-4.8
Reviewed-by: Bhawanpreet Lakha <bhawanpreet.lakha@amd.com>
Signed-off-by: Alex Hung <alex.hung@amd.com>
Signed-off-by: George Zhang <george.zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[WHAT]
Add KUnit coverage for dm_helpers_dp_mst_start_top_mgr and
dm_helpers_dp_mst_stop_top_mgr, dm_helpers_dp_write_hblank_reduction,
get_dsc_max_slices, dm_helpers_init_panel_settings,
dm_helpers_override_panel_settings and
fill_dc_mst_payload_table_from_drm.
Assisted-by: Copilot:Claude-Opus-4.8
Reviewed-by: Bhawanpreet Lakha <bhawanpreet.lakha@amd.com>
Signed-off-by: Alex Hung <alex.hung@amd.com>
Signed-off-by: George Zhang <george.zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[WHAT]
Add KUnit coverage for DTN logging, DPCD read/write, fused IO and the
Synaptics DSC workaround helpers execute_synaptics_rc_command,
apply_synaptics_fifo_reset_wa,
write_dsc_enable_synaptics_non_virtual_dpcd_mst and
dm_helpers_dp_write_dsc_enable.
Assisted-by: Copilot:Claude-Opus-4.8
Reviewed-by: Bhawanpreet Lakha <bhawanpreet.lakha@amd.com>
Signed-off-by: Alex Hung <alex.hung@amd.com>
Signed-off-by: George Zhang <george.zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[WHAT]
Add KUnit coverage for the EDID parsing helpers edid_extract_panel_id,
apply_edid_quirks and dm_helpers_parse_edid_caps, together with the
ACPI/VBIOS EDID readers dm_helpers_probe_acpi_edid,
dm_helpers_read_acpi_edid and dm_helpers_read_vbios_hardcoded_edid.
Assisted-by: Copilot:Claude-Opus-4.8
Reviewed-by: Bhawanpreet Lakha <bhawanpreet.lakha@amd.com>
Signed-off-by: Alex Hung <alex.hung@amd.com>
Signed-off-by: George Zhang <george.zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[Why]
dm_crtc_get_cursor_mode() only re-evaluates the required cursor mode
(native vs overlay) when a top plane changes its scale, pixel format,
enable state, or zpos/color pipeline. It does not re-evaluate when a
plane changes only its destination rectangle (crtc_x, crtc_y, crtc_w,
crtc_h) at a constant scale. A pure move/resize can create or remove a
hole under the cursor, which changes whether the native cursor is valid.
When a primary plane shrinks and no longer covers the cursor region, the
cursor mode stays NATIVE and the cursor is not rendered over the
uncovered area, so it becomes invisible there. This is caught by
igt@amdgpu/amd_cursor_overlay@non-full, where the test CRC was a constant
black value across all cursor positions instead of tracking the
reference.
[How]
In the per-plane loop of dm_crtc_get_cursor_mode(), set
consider_mode_change when any of crtc_x, crtc_y, crtc_w or crtc_h differs
between the old and new plane state, so a plane move/resize forces
re-evaluation of the cursor mode. The driver then correctly promotes the
cursor to OVERLAY mode when the primary stops covering the cursor region.
Reviewed-by: ChiaHsuan (Tom) Chung <chiahsuan.chung@amd.com>
Signed-off-by: James Lin <PingLei.Lin@amd.com>
Signed-off-by: George Zhang <george.zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[why]
correct a sequence issue by switching to dcn35's dccg sequence:
to make sure select dtbclk src first before programming hdmistream_clk_en.
Reviewed-by: Leo Chen <leo.chen@amd.com>
Signed-off-by: Charlene Liu <Charlene.Liu@amd.com>
Signed-off-by: George Zhang <george.zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[Why & How]
Cleanup for future refactors.
Reviewed-by: Wenjing Liu <wenjing.liu@amd.com>
Signed-off-by: Dominik Kaszewski <dominik.kaszewski@amd.com>
Signed-off-by: George Zhang <george.zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[why]
The IGT test igt@amdgpu/amd_mall@static-screen always fails on DCN 4.0.1
because debugfs reports "mall enabled: no" even when MALL is
actually active. This is because the DCN 4.0.1 hubbub function table is
missing the .get_mall_en callback, so capabilities_show() always sees
mall_in_use as false.
[how]
Reuse hubbub32_get_mall_en() for DCN 4.0.1 since the DCHUBBUB_ARB_MALL_CNTL
register layout is identical to DCN 3.2:
- Register the DCHUBBUB_ARB_MALL_CNTL register offset in dcn401_resource.h
- Add MALL_PREFETCH_COMPLETE and MALL_IN_USE mask/shift definitions in
dcn401_hubbub.h
- Wire up .get_mall_en = hubbub32_get_mall_en in hubbub4_01_funcs
Reviewed-by: ChiaHsuan (Tom) Chung <chiahsuan.chung@amd.com>
Signed-off-by: James Lin <PingLei.Lin@amd.com>
Signed-off-by: George Zhang <george.zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[why]
These registers are needed by our existing code.
[how]
Add the missing register defines to dcn42b_resource.c.
Remove DCN42B variant of HP_DP_STREAM_ENC_REG_LIST_RI as it is now the
same as the DCN42B one, when these registers are included.
Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
Signed-off-by: Matthew Stewart <Matthew.Stewart2@amd.com>
Signed-off-by: George Zhang <george.zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[why]
need to add null pointer access check
Reviewed-by: Gabe Teeger <gabe.teeger@amd.com>
Signed-off-by: Charlene Liu <Charlene.Liu@amd.com>
Signed-off-by: George Zhang <george.zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Add KUnit coverage for the following ISM functions:
- dm_ism_next_state(): state transitions for running, busy,
hysteresis-wait, optimized-idle, and aborted states
- dm_ism_get_sso_delay(): null stream, zero frames, 1080p60 3-frame,
and 4k60 1-frame calculations
- dm_ism_get_idle_allow_delay(): null stream, zero filter/entry/delay
frames, short-idle filtering, wrap-around, old history cutoff,
mixed durations, and entry count exceeding history size
- amdgpu_dm_ism_init(): initial state setup
- amdgpu_dm_ism_fini(): cleanup after init
- dm_ism_set_last_idle_ts(): timestamp update
- dm_ism_insert_record(): basic insert and wrap-around
- dm_ism_trigger_event(): valid and invalid transitions
Assisted-by: Copilot:Claude-Opus-4.8
Reviewed-by: Bhawanpreet Lakha <bhawanpreet.lakha@amd.com>
Signed-off-by: Alex Hung <alex.hung@amd.com>
Signed-off-by: George Zhang <george.zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
entries.
[why]
The matching entry was disabled but still copied during compaction, so a
removed pipe could survive and overwrite a valid entry, leaving num_wb_info
wrong.
[how]
Skip every entry matching dwb_pipe_inst and compact only survivors. Covered
by test_dc_stream_writeback_drc_and_remove.And added new test cases for coverage.
Reviewed-by: Ilya Bakoulin <ilya.bakoulin@amd.com>
Signed-off-by: Bhuvanachandra Pinninti <BhuvanaChandra.Pinninti@amd.com>
Signed-off-by: George Zhang <george.zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Change memclk table to match dcfclk size to avoid fine grained mapping
in dml2.1
Reviewed-by: Charlene Liu <charlene.liu@amd.com>
Signed-off-by: Dmytro Laktyushkin <dmytro.laktyushkin@amd.com>
Signed-off-by: George Zhang <george.zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[Why]
DML has been updated to use per-DPM derates when provided but per-DPM de-rates have not been finalized.
Need to validate to see what values should be stored in the bounding box.
[How]
Add debug options to set custom derates per DPM (starting at DPM0) and their values
Each entry in the custom derate expects the derates to be stored in the following format:
bits 0-7: dram_derate_percent_pixel
bits 8-15: fclk_derate_percent
bits 16-23: dcfclk_derate_percent
bits 24-31 are unused.
e.g. Using the value 0x414020 will set the following derates for DPM0
DPM0: 0x20, 0x40, 0x41 for dram, fclk, and dcfclk respectively
Note that global derate value will be used if the per-DPM derate is 0.
Reviewed-by: Dillon Varone <dillon.varone@amd.com>
Signed-off-by: Austin Zheng <Austin.Zheng@amd.com>
Signed-off-by: George Zhang <george.zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[Why]
The CACP enablement on Linux added panel-type detection and CACP
capability logic that was not covered by KUnit tests.
[How]
Export amdgpu_dm_set_panel_type() and amdgpu_dm_update_cacp_caps() for
KUnit via STATIC_IFN_KUNIT/EXPORT_IF_KUNIT and add unit tests covering:
- amdgpu_dm_update_cacp_caps(): IP version gating (including the 3.1.6
exclusion), eDP/LVDS signal handling, non-eDP signals, and OLED vs LCD
panel types.
- amdgpu_dm_set_panel_type(): VSDB OLED/MINILED, DPCD oled/miniled bits,
the DID path (OLED and LCD), the vendor luminance heuristic, and the
LCD default.
Update the should_create_sysfs backlight tests to reflect the new
OLED/CACP behavior (OLED with/without CACP and LCD eDP panels).
Assisted-by: Copilot:Claude-Opus-4.8
Reviewed-by: Alex Hung <alex.hung@amd.com>
Signed-off-by: Chenyu Chen <chen-yu.chen@amd.com>
Signed-off-by: George Zhang <george.zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[Why]
In amdgpu_dm_set_panel_type() the DID fallback branch tested and wrote
link->panel_type, while the rest of the function tracked the result in
the local variable panel_type. The final assignment unconditionally
overwrites link->panel_type from panel_type, so the value derived from
DID was always discarded, making the DID branch dead code.
[How]
Use the local panel_type variable in the DID fallback branch so that the
DID result participates in the source priority (VSDB -> DPCD -> DID ->
vendor luminance heuristic -> LCD default) and is preserved by the final
assignment.
Assisted-by: Copilot:Claude-Opus-4.8
Reviewed-by: Alex Hung <alex.hung@amd.com>
Signed-off-by: Chenyu Chen <chen-yu.chen@amd.com>
Signed-off-by: George Zhang <george.zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[Why]
stream->sink is optional and can be null, so should always be checked
before dereference. Additionally, most of its usage in DPMS sequences
is for stream->sink->link, which can be replaced with stream->link,
as the two should always be the same.
[How]
* Replace stream->sink->link in DPMS on/off
* Add assert to USB4 BW allocation where sink is required
* Avoid inconsistencies in resource access, e.g. don't repeat
stream->link after it was already saved to a local variable
* Pull out effective VPG calculation to helper getter
* Formatting fixes
Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: Dominik Kaszewski <dominik.kaszewski@amd.com>
Signed-off-by: George Zhang <george.zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[why]
The IGT test kms_plane_alpha_blend@coverage-vs-premult-vs-constant
failed on DCN with ODM 2:1 combine enabled. The test compares the CRC
of a coverage-blended plane against a premultiplied-blended plane and
expects them to be identical. With ODM combine the whole-frame CRC
mismatched (left segment matched, right segment differed).
Root cause: dc_stream_set_dither_option() iterated the pipe_ctx array
and broke out at the first pipe matching the stream (the OTG master /
OPP instance 0), then programmed bit-depth reduction (dither) on that
single OPP only. Under ODM combine there is more than one OPP head, so
the secondary ODM segment (OPP instance 1) was never reprogrammed. When
CRC capture requested dither off, only the left OPP got updated while
the right OPP kept its previous dither setting, producing a different
CRC for the right segment and thus a whole-frame CRC mismatch.
[how]
Use resource_get_otg_master_for_stream() and
resource_get_opp_heads_for_otg_master() to retrieve every OPP head of
the stream, then loop over all of them and call
transform_set_pixel_storage_depth() and opp_program_bit_depth_reduction()
on each. This keeps all OPP heads in sync under ODM combine, so dither is
applied (or cleared) identically across every segment and the CRCs match.
Reviewed-by: Wayne Lin <wayne.lin@amd.com>
Signed-off-by: James Lin <PingLei.Lin@amd.com>
Signed-off-by: George Zhang <george.zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
apply_dsc_policy_for_stream() decides whether Display Stream Compression
(DSC) should be enabled for a display stream based on display
capabilities, link bandwidth and user overrides.
Smatch reports that apply_dsc_policy_for_stream() dereferences
aconnector->dc_link before checking whether it is NULL.
Add an early NULL check for aconnector->dc_link before the first
dereference and remove the later redundant NULL check in the HDMI_FRL
path.
Fixes: 0e967e086e75 ("drm/amd/display: Extract connector and encoder code to amdgpu_dm_connector")
Reported-by: Dan Carpenter <error27@gmail.com>
Cc: Roman Li <roman.li@amd.com>
Cc: Alex Hung <alex.hung@amd.com>
Cc: Tom Chung <chiahsuan.chung@amd.com>
Cc: Aurabindo Pillai <aurabindo.pillai@amd.com>
Reviewed-by: George Zhang <george.zhang@amd.com>
Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[why]
Need special handling for passive HDMI dongles with I2C over AUX.
Reviewed-by: Aurabindo Pillai <Aurabindo.Pillai@amd.com>
Signed-off-by: Matthew Stewart <Matthew.Stewart2@amd.com>
Signed-off-by: George Zhang <george.zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[Why & How]
Port seamless boot fix from DCN42 to DCN42B and enable zstate
support for DCN42B.
Reviewed-by: Ovidiu (Ovi) Bunea <ovidiu.bunea@amd.com>
Signed-off-by: Gabe Teeger <gabe.teeger@amd.com>
Signed-off-by: Matthew Stewart <matthew.stewart2@amd.com>
Signed-off-by: George Zhang <george.zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[why]
DCN42B is missing some register masks, which are causing errors in dmesg.
[how]
Make DCN42B reuse the DCN42 register lists, and add the missing defines manually.
Fixes: 64142f9d51af ("drm/amd/display: Fix DCN42 null registers & register masks")
Reviewed-by: Ovidiu (Ovi) Bunea <ovidiu.bunea@amd.com>
Signed-off-by: Matthew Stewart <Matthew.Stewart2@amd.com>
Signed-off-by: George Zhang <george.zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
[Why]
DCN4 variant had IPS completely disabled via ips_support =
false and dc->config.disable_ips = DMUB_IPS_DISABLE_ALL.
Enabling IPS for D3 allows DMUB to manage idle power savings
when the display subsystem is inactive, reducing platform
power without affecting active display operation.
[How]
In DCN4 variant resource construct:
- Set dc->caps.ips_support = true
- Remove dc->config.disable_ips = DMUB_IPS_DISABLE_ALL override
This enables DMUB to dynamically manage IPS entry/exit during
D3 power state transitions. Also enable zstate by default.
Reviewed-by: Ovidiu (Ovi) Bunea <ovidiu.bunea@amd.com>
Signed-off-by: Gabe Teeger <gabe.teeger@amd.com>
Signed-off-by: Matthew Stewart <matthew.stewart2@amd.com>
Signed-off-by: George Zhang <george.zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
If gfx sysfs init fails, we may leak the ip dump
allocations.
Reviewed-by: Mukul Joshi <mukul.joshi@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
If gfx sysfs init fails, we may leak the ip dump
allocations.
Reviewed-by: Mukul Joshi <mukul.joshi@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
If gfx sysfs init fails, we may leak the ip dump
allocations.
Reviewed-by: Mukul Joshi <mukul.joshi@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
If gfx sysfs init fails, we may leak the ip dump
allocations.
Reviewed-by: Mukul Joshi <mukul.joshi@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Add support for dumping IP register state.
v2: fixes suggested by Mukul
Reviewed-by: Mukul Joshi <mukul.joshi@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|