From 67a50ae0edd92bca49bca94820cf3011237f6e59 Mon Sep 17 00:00:00 2001 From: Raag Jadav Date: Thu, 5 Mar 2026 18:36:47 +0530 Subject: [PATCH] drm/doc: Update documentation for 'none' recovery method MIME-Version: 1.0 Content-Type: text/plain; charset=utf8 Content-Transfer-Encoding: 8bit Expand 'none' recovery method for wedged event to include debug cases where driver wants to hint "no recovery" without resetting the device from driver context. Signed-off-by: Raag Jadav Reviewed-by: Rodrigo Vivi Reviewed-by: Christian König Signed-off-by: Matthew Brost Link: https://patch.msgid.link/20260305130720.3685754-2-raag.jadav@intel.com --- Documentation/gpu/drm-uapi.rst | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst index d98428a592f1f..579e87cb9ff75 100644 --- a/Documentation/gpu/drm-uapi.rst +++ b/Documentation/gpu/drm-uapi.rst @@ -438,14 +438,14 @@ following expectations. unknown consumer policy =============== ======================================== -The only exception to this is ``WEDGED=none``, which signifies that the device -was temporarily 'wedged' at some point but was recovered from driver context -using device specific methods like reset. No explicit recovery is expected from -the consumer in this case, but it can still take additional steps like gathering -telemetry information (devcoredump, syslog). This is useful because the first -hang is usually the most critical one which can result in consequential hangs or -complete wedging. - +No Recovery +----------- + +Here ``WEDGED=none`` signifies that no recovery is expected from the consumer +but it can still try to gather telemetry information (devcoredump, syslog) for +debug purpose in order to root cause the hang. This is useful because the first +hang is usually the most critical one which can result in consequential hangs +or complete wedging. Vendor Specific Recovery ------------------------ -- 2.47.3