Re: [PATCH 1/4] drm: Add a firmware flash method to device wedged uevent

[Rodrigo Vivi <rodrigo.vivi@intel.com>]

On Thu, Jun 05, 2025 at 04:54:24PM +0530, Riana Tauro wrote:
> 
> Hi Raag
> 
> On 6/4/2025 4:13 PM, Raag Jadav wrote:
> > On Tue, Jun 03, 2025 at 01:43:57PM +0530, Riana Tauro wrote:
> > > A device is declared wedged when it is non-recoverable from
> > > the driver context. Some firmware errors can also cause
> > > the device to enter this state and the only method to recover
> > > from this would be to do a firmware flash
> > > 
> > > Signed-off-by: Riana Tauro <riana.tauro@intel.com>
> > > ---
> > >   Documentation/gpu/drm-uapi.rst | 6 +++---
> > >   drivers/gpu/drm/drm_drv.c      | 2 ++
> > >   include/drm/drm_device.h       | 1 +
> > >   3 files changed, 6 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
> > > index 4863a4deb0ee..524224afb09f 100644
> > > --- a/Documentation/gpu/drm-uapi.rst
> > > +++ b/Documentation/gpu/drm-uapi.rst
> > > @@ -422,9 +422,8 @@ Current implementation defines three recovery methods, out of which, drivers
> > >   can use any one, multiple or none. Method(s) of choice will be sent in the
> > >   uevent environment as ``WEDGED=<method1>[,..,<methodN>]`` in order of less to
> > >   more side-effects. If driver is unsure about recovery or method is unknown
> > > -(like soft/hard system reboot, firmware flashing, physical device replacement
> > > -or any other procedure which can't be attempted on the fly), ``WEDGED=unknown``
> > > -will be sent instead.
> > > +(like soft/hard system reboot, physical device replacement or any other procedure
> > > +which can't be attempted on the fly), ``WEDGED=unknown`` will be sent instead.
> > >   Userspace consumers can parse this event and attempt recovery as per the
> > >   following expectations.
> > > @@ -435,6 +434,7 @@ following expectations.
> > >       none            optional telemetry collection
> > >       rebind          unbind + bind driver
> > >       bus-reset       unbind + bus reset/re-enumeration + bind
> > > +    firmware-flash  unbind + firmware flash + bind
> > 
> > Can you guarantee this to be generic for all drivers?
> 
> 
> Firmware flash as a method was mentioned as unknown in the document. So if
> there is an error that requires firmware flash to recover, mentioning this
> as recovery method should be okay
> 
> Wanted to get some comments on unbind/bind. If this is not required will
> remove it.

Yeap, probably better to remove the unbind/bind and keep this generic.
Even in some of our cases we should need to unbind + config-survivability + rebind + flash firmware + unbind + delete configfs + bind.

> 
> Adding reviewers for inputs
> 
> Thanks
> Riana
> 
> 
> > 
> > Raag
>