Hi Raag, Em 28/11/2024 12:37, Raag Jadav escreveu:
Introduce device wedged event, which notifies userspace of 'wedged' (hanged/unusable) state of the DRM device through a uevent. This is useful especially in cases where the device is no longer operating as expected and has become unrecoverable from driver context. Purpose of this implementation is to provide drivers a generic way to recover with the help of userspace intervention without taking any drastic measures in the driver. A 'wedged' device is basically a dead device that needs attention. The uevent is the notification that is sent to userspace along with a hint about what could possibly be attempted to recover the device and bring it back to usable state. Different drivers may have different ideas of a 'wedged' device depending on their hardware implementation, and hence the vendor agnostic nature of the event. It is up to the drivers to decide when they see the need for device recovery and how they want to recover from the available methods.
Thank you for your work. Do you think you can add the optional PID parameter, as the PID of the app that caused the reset? For SteamOS use case it has been proved to be useful to kill the fault app as well. If the reset was caused by a kthread, no PID can be provided hence it's an optional parameter.