[PATCH 0/6] RFC Support hot device unplug in amdgpu

Daniel Vetter daniel at ffwll.ch
Mon May 11 12:21:57 UTC 2020

On Mon, May 11, 2020 at 1:43 PM Lukas Wunner <lukas at wunner.de> wrote:
> On Mon, May 11, 2020 at 11:54:33AM +0200, Daniel Vetter wrote:
> > - One unfortunate thing with drm_dev_unplug is that the driver core is
> >   very opinionated and doesn't tell you whether it's a hotunplug or a
> >   driver unload. In the former case trying to shut down hw just wastes
> >   time (and might hit driver bugs), in the latter case driver engineers
> >   very much expect everything to be shut down.
> You can get that information at the PCI bus level with
> pci_dev_is_disconnected().  The flag queried by this function is set
> upon hot removal.  Be aware however that the device is guaranteed to
> be unreachable if the function returns true, but the converse is NOT
> guaranteed, i.e. the function may return false even though the device
> has just gone away.
> Those somewhat difficult semantics are one of the reasons why some
> people are skeptical of the function's merits (notably Greg KH).
> See this LWN article for more information:
> https://lwn.net/Articles/767885/
> (scroll down to the "Surprise removal" section)
> I've suggested to Greg a few years back that we should have a flag
> at the device level to indicate whether it's gone, not just at the bus
> level.  That way the property could be expressed regardless of the bus
> used.  It would facilitate the feature you're missing, that the driver
> core tells you whether it's a surprise removal or not.  Unfortunately
> Greg rejected the idea.

Ok, so at least for pci devices you could do something like

if (pci_dev_is_disconnected())

In the ->remove callback and both users and developers should be
happy. I guess for other drivers like usb/spi just yanking the cable
for driver hacking is good enough - loss of power should also reset
the device :-)
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

More information about the dri-devel mailing list