[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())
drm_dev_unplug();
else
drm_dev_unregister();
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
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
More information about the dri-devel
mailing list