linux.git/drivers/gpu/drm/xe/xe_devcoredump.c, branch master

drm/xe: Don't use UTS_RELEASE directly

2026-04-28T20:20:33+00:00

UTS_RELEASE evaluates to a static string and changes quite easily (e.g. uncommitted changes in the source tree or new commits). So when checking if a patch introduces changes to the resulting binary each usage of UTS_RELEASE is source of annoyance. Instead of using UTS_RELEASE directly use init_utsname()->release which evaluates to the same string but with that a change of UTS_RELEASE doesn't affect xe_devcoredump.o. Signed-off-by: Uwe Kleine-König (The Capable Hub) Reviewed-by: Jani Nikula Acked-by: José Roberto de Souza Link: https://patch.msgid.link/20260428102527.189593-2-u.kleine-koenig@baylibre.com Signed-off-by: Rodrigo Vivi

drm/xe: Fix null pointer dereference in devcoredump cleanup

2026-04-22T20:52:18+00:00

In xe_devcoredump_snapshot_free(), ss->gt may be NULL when the snapshot was never fully populated (e.g., when cleanup is triggered without a prior capture). Guard the xe_guc_capture_put_matched_nodes() call with IS_ERR_OR_NULL() to prevent a null dereference. In xe_devcoredump_free(), the deferred work is only queued when a coredump is captured, so guard cancel_work_sync() with a check on coredump->captured. Signed-off-by: Zhanjun Dong Reviewed-by: Vinay Belgaumkar Signed-off-by: Vinay Belgaumkar Link: https://patch.msgid.link/20260326181017.2060209-1-zhanjun.dong@intel.com

drm/xe: replace use of system_unbound_wq with system_dfl_wq

2026-02-03T00:18:09+00:00

This patch continues the effort to refactor workqueue APIs, which has begun with the changes introducing new workqueues and a new alloc_workqueue flag: commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq") commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag") The point of the refactoring is to eventually alter the default behavior of workqueues to become unbound by default so that their workload placement is optimized by the scheduler. Before that to happen, workqueue users must be converted to the better named new workqueues with no intended behaviour changes: system_wq -> system_percpu_wq system_unbound_wq -> system_dfl_wq This way the old obsolete workqueues (system_wq, system_unbound_wq) can be removed in the future. Link: https://lore.kernel.org/all/20250221112003.1dSuoGyc@linutronix.de/ Suggested-by: Tejun Heo Signed-off-by: Marco Crivellari Reviewed-by: Rodrigo Vivi Link: https://patch.msgid.link/20260202103756.62138-2-marco.crivellari@suse.com Signed-off-by: Rodrigo Vivi

drm/xe: Cleanup unused header includes

2026-01-15T15:05:04+00:00

clangd reports many "unused header" warnings throughout the Xe driver. Start working to clean this up by removing unnecessary includes in our .c files and/or replacing them with explicit includes of other headers that were previously being included indirectly. By far the most common offender here was unnecessary inclusion of xe_gt.h. That likely originates from the early days of xe.ko when xe_mmio did not exist and all register accesses, including those unrelated to GTs, were done with GT functions. There's still a lot of additional #include cleanup that can be done in the headers themselves; that will come as a followup series. v2: - Squash the 79-patch series down to a single patch. (MattB) Reviewed-by: Matthew Brost Link: https://patch.msgid.link/20260115032803.4067824-2-matthew.d.roper@intel.com Signed-off-by: Matt Roper

Merge drm/drm-next into drm-xe-next

2025-12-19T10:51:22+00:00

Backmerging to bring in 6.19-rc1. An important upstream bugfix and to help unblock PTL CI. Signed-off-by: Thomas Hellström

drm/xe/devcoredump: Use scope-based cleanup

2025-11-19T19:58:57+00:00

Use scope-based cleanup for forcewake and runtime PM in the devcoredump code. This eliminates some goto-based error handling and slightly simplifies other functions. v2: - Move the forcewake acquisition slightly higher in devcoredump_snapshot() so that we maintain an easy-to-understand LIFO cleanup order. (Gustavo) Cc: Gustavo Sousa Reviewed-by: Gustavo Sousa Link: https://patch.msgid.link/20251118164338.3572146-41-matthew.d.roper@intel.com Signed-off-by: Matt Roper

drm/xe: Switch to use %ptSp

2025-11-19T11:26:06+00:00

Use %ptSp instead of open coded variants to print content of struct timespec64 in human readable format. Acked-by: Lucas De Marchi Signed-off-by: Andy Shevchenko Link: https://patch.msgid.link/20251113150217.3030010-9-andriy.shevchenko@linux.intel.com Signed-off-by: Petr Mladek

drm/xe: Release runtime pm for error path of xe_devcoredump_read()

2025-07-08T22:11:37+00:00

xe_pm_runtime_put() is missed to be called for the error path in xe_devcoredump_read(). Add function description comments for xe_devcoredump_read() to help understand it. v2: more detail function comments and refine goto logic (Matt) Fixes: c4a2e5f865b7 ("drm/xe: Add devcoredump chunking") Cc: stable@vger.kernel.org Reviewed-by: Matthew Brost Signed-off-by: Shuicheng Lin Signed-off-by: Matthew Brost Link: https://lore.kernel.org/r/20250707004911.3502904-6-shuicheng.lin@intel.com

drm/xe: Remove unused code in devcoredump_snapshot()

2025-07-08T22:11:36+00:00

The deleted code is no longer needed because patch "drm/xe/guc: Plumb GuC-capture into dev coredump" has removed the related usage code. Remove the code to tidy up the function. v2: s/bacause/because Reviewed-by: Zhanjun Dong Reviewed-by: Matthew Brost Cc: Rodrigo Vivi Signed-off-by: Shuicheng Lin Signed-off-by: Matthew Brost Link: https://lore.kernel.org/r/20250707004911.3502904-5-shuicheng.lin@intel.com

drm/xe: fix devcoredump chunk alignmnent calculation

2025-05-01T15:48:56+00:00

The device core dumps are copied in 1.5GB chunks, which leads to a link-time error on 32-bit builds because of the 64-bit division not getting trivially turned into mask and shift operations: ERROR: modpost: "__moddi3" [drivers/gpu/drm/xe/xe.ko] undefined! On top of this, I noticed that the ALIGN_DOWN() usage here cannot work because that is only defined for power-of-two alignments. Change ALIGN_DOWN into an explicit div_u64_rem() that avoids the link error and hopefully produces the right results. Doing a 1.5GB kvmalloc() does seem a bit suspicious as well, e.g. this will clearly fail on any 32-bit platform and is also likely to run out of memory on 64-bit systems under memory pressure, so using a much smaller power-of-two chunk size might be a good idea instead. v2: - Always call div_u64_rem (Matt) Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202504251238.JsNgFeFc-lkp@intel.com/ Fixes: c4a2e5f865b7 ("drm/xe: Add devcoredump chunking") Signed-off-by: Arnd Bergmann Signed-off-by: Matthew Brost Reviewed-by: Rodrigo Vivi Link: https://lore.kernel.org/r/20250501012545.1045247-1-matthew.brost@intel.com Signed-off-by: Rodrigo Vivi