commit 4f5368b5
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Fri Jun 14 08:17:23 2019 +0200

    drm/kms: Catch mode_object lifetime errors

uncovered a bit a mess in dp drivers. Most drivers (from a quick look,
all except i915) register all the dp stuff in their init code, which
is too early. With CONFIG_DRM_DP_AUX_CHARDEV this will blow up,
because drm_dp_aux_register tries to add a child to a device in sysfs
(the connector) which doesn't even exist yet.

No one seems to have cared thus far. But with the above change I also
moved the setting of dev->registered after the ->load callback, in an
attempt to keep old drivers from hitting any WARN_ON backtraces. But
that moved radeon.ko from the "working, by accident" to "now also
broken" category.

Since this is a huge mess I figured a revert would be simplest. But
this check has already caught issues in i915:

commit 1b9bd096
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Tue Aug 20 19:16:57 2019 +0300

    drm/i915: Do not create a new max_bpc prop for MST connectors

Hence I'd like to retain it. Fix the radeon regression by moving the
setting of dev->registered back to were it was, and stop the
backtraces with an explicit check for dev->driver->load.

Everyone else will stay as broken with CONFIG_DRM_DP_AUX_CHARDEV. The
next patch will improve the kerneldoc and add a todo entry for this.

Fixes: 4f5368b5 ("drm/kms: Catch mode_object lifetime errors")
Cc: Sean Paul <sean@poorly.run>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reported-by: NMichel Dänzer <michel@daenzer.net>
Reviewed-by: NMichel Dänzer <mdaenzer@redhat.com>
Tested-by: NMichel Dänzer <mdaenzer@redhat.com>
Cc: Michel Dänzer <michel@daenzer.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190917120936.7501-1-daniel.vetter@ffwll.ch

This improves Sphinx output in two ways:

- It avoids an unmatched single-quote ('), about which Sphinx complained:

    Documentation/gpu/drm-internals.rst:298:
    WARNING: Could not lex literal_block as "c". Highlighting skipped.

  An alternative approach would be to replace "can't" with a word that
  doesn't have a single-quote.

- It lets Sphinx format the comments in italics and grey, making the
  code slightly easier to read.
Signed-off-by: NJonathan Neuschäfer <j.neuschaefer@gmx.net>
Acked-by: Daniel Vetter <daniel@ffwll.ch> [via irc]
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190808163629.14280-1-j.neuschaefer@gmx.net

Only dynamic mode objects, i.e. those which are refcounted and have a free
callback, can be added while the overall drm_device is visible to
userspace. All others must be added before drm_dev_register and
removed after drm_dev_unregister.

Small issue around drivers still using the load/unload callbacks, we
need to make sure we set dev->registered so that load/unload code in
these callbacks doesn't trigger false warnings. Only a small
adjustement in drm_dev_register was needed.

Motivated by some irc discussions about object ids of dynamic objects
like blobs become invalid, and me going on a bit an audit spree.
Reviewed-by: NSean Paul <sean@poorly.run>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190614061723.1173-1-daniel.vetter@ffwll.ch

When calling debugfs functions, there is no need to ever check the
return value.  The function can work or not, but the code logic should
never do something different based on this.

Because there is no need to check these functions, a number of local
functions can be made to return void to simplify things as nothing can
fail.

Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <maxime.ripard@bootlin.com>
Cc: Sean Paul <sean@poorly.run>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20190613133439.GA6715@kroah.com

The use of the drmP.h header file is deprecated.
Remove use from all files in drm/*
so people do not look there and follow a bad example.

Build tested allyesconfig,allmodconfig on x86, arm etc.
Including alpha that is as always more challenging than
the rest.
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Acked-by: NDaniel Vetter <daniel@ffwll.ch>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <maxime.ripard@bootlin.com>
Cc: Sean Paul <sean@poorly.run>
Cc: David Airlie <airlied@linux.ie>
Link: https://patchwork.freedesktop.org/patch/msgid/20190526173535.32701-8-sam@ravnborg.org

Convert the drm filesystem to the new internal mount API as the old
one will be obsoleted and removed.  This allows greater flexibility in
communication of mount parameters between userspace, the VFS and the
filesystem.

See Documentation/filesystems/mount_api.txt for more information.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
cc: David Airlie <airlied@linux.ie>
cc: dri-devel@lists.freedesktop.org
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

Once upon a time we used to set ->d_name of e.g. pipefs root
so that d_path() on pipes would work.  These days it's
completely pointless - dentries of pipes are not even connected
to pipefs root.  However, mount_pseudo() had set the root
dentry name (passed as the second argument) and callers
kept inventing names to pass to it.  Including those that
didn't *have* any non-root dentries to start with...

All of that had been pointless for about 8 years now; it's
time to get rid of that cargo-culting...
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

defaults will do just fine.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

This introduces drm_legacy_misc.c as a place for some misc legacy code,
eventually I want to give the option to remove this from the build.
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This allows them to be removed later.
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This makes it easier to clean this up later.
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Commit f06ddb53 ("BackMerge v5.1-rc5 into drm-next") incorrectly
resolved a merge conflict related to a patch having been merged twice:
- commit 3f04e0a6 ("drm: Fix drm_release() and device unplug")
  introduced as a standalone fix via drm-fixes branch,
- commit 1ee57d4d ("drm: Fix drm_release() and device unplug")
  applied as patch 1/2 of a series on drm-next branch.
That incorrect resolution of the conflict effectively reverted a change
introduced to drivers/gpu/drm/drm_drv.c by patch 2/2 of that series -
commit ba3bf37e ("drm/drv: drm_dev_unplug(): Move out drm_dev_put()
call").  Fix it.

Fixes: f06ddb53 ("BackMerge v5.1-rc5 into drm-next")
Signed-off-by: NJanusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190417133232.16232-1-janusz.krzysztofik@linux.intel.com

If userspace has open fd(s) when drm_dev_unplug() is run, it will result
in drm_dev_unregister() being called twice. First in drm_dev_unplug() and
then later in drm_release() through the call to drm_put_dev().

Since userspace already holds a ref on drm_device through the drm_minor,
it's not necessary to add extra ref counting based on no open file
handles. Instead just drm_dev_put() unconditionally in drm_dev_unplug().

We now have this:
- Userpace holds a ref on drm_device as long as there's open fd(s)
- The driver holds a ref on drm_device as long as it's bound to the
  struct device

When both sides are done with drm_device, it is released.
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Reviewed-by: NOleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NSean Paul <sean@poorly.run>
Signed-off-by: NDave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190208140103.28919-2-noralf@tronnes.org

Add driver example that shows how devm_drm_dev_init() can be used.

v2: Expand docs (Sam, Daniel)
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: NGerd Hoffmann <kraxel@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190225144232.20761-4-noralf@tronnes.org

This adds a resource managed (devres) version of drm_dev_init().

v2: Remove devm_drm_dev_register() since we can't touch hw in devm
    release functions and drivers want to disable hw on driver module
    unload (Daniel Vetter, Greg KH)

Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Greg KH <gregkh@linuxfoundation.org>
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Acked-by: NGerd Hoffmann <kraxel@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190225144232.20761-3-noralf@tronnes.org

This makes it safe to access drm_device->dev after the parent device has
been removed/unplugged.
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Reviewed-by: NGerd Hoffmann <kraxel@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190225144232.20761-2-noralf@tronnes.org

This makes it possible to use drm_dev_unplug() with the upcoming
devm_drm_dev_init() which will do drm_dev_put() in its release callback.

Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: David (ChunMing) Zhou <David1.Zhou@amd.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Sean Paul <sean@poorly.run>
Cc: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Acked-by: NOleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20190208140103.28919-3-noralf@tronnes.org

If userspace has open fd(s) when drm_dev_unplug() is run, it will result
in drm_dev_unregister() being called twice. First in drm_dev_unplug() and
then later in drm_release() through the call to drm_put_dev().

Since userspace already holds a ref on drm_device through the drm_minor,
it's not necessary to add extra ref counting based on no open file
handles. Instead just drm_dev_put() unconditionally in drm_dev_unplug().

We now have this:
- Userpace holds a ref on drm_device as long as there's open fd(s)
- The driver holds a ref on drm_device as long as it's bound to the
  struct device

When both sides are done with drm_device, it is released.
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Reviewed-by: NOleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NSean Paul <sean@poorly.run>
Link: https://patchwork.freedesktop.org/patch/msgid/20190208140103.28919-2-noralf@tronnes.org

Now that component has docs it's worth spending a few words and
hyperlinks on recommended best practices in drm.

v2: Add another item that component shouldn't be preferred over
drm_bridge/panel and similar subsystems already providing specialized
support for specific components (Laurent). Also convert to bullet
list.

Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Russell King - ARM Linux admin <linux@armlinux.org.uk>
Reviewed-by: NMaxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190212164615.13370-1-daniel.vetter@ffwll.ch

Just a bit of drive-by reading:
- drm_dev_set_unique() is really the exception, make that clear.
- drm_dev_init() is the recomended approach.
Reviewed-by: NSam Ravnborg <sam@ravnborg.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190111164048.29067-1-daniel.vetter@ffwll.ch

Remove drm_crtc_internal.h which is included more than once
Signed-off-by: NBrajeswar Ghosh <brajeswar.linux@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20181224143636.GA3237@hp-pavilion-15-notebook-pc-brajeswar

There are no more places where this (deprecated) function is being used
from, thus it can now be removed.
Signed-off-by: NFernando Ramos <greenfoo@gluegarage.com>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20181115221634.22715-5-greenfoo@gluegarage.com

The content of drm_global.{c,h} is obsolete.

v2: rebase on dropping TTM functionality
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NJunwei Zhang <Jerry.Zhang@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Previous commit removed the only reason why we were allowing NULL as
a parent device. With that resolved, we can enforce nobody else does
that mistake.

With that we can drop the ugly drm_dev_set_unique workaround.

v2: rebase, silence checkpatch "== NULL" warning

Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Deepak Sharma <deepak.sharma@amd.com>
Signed-off-by: NEmil Velikov <emil.velikov@collabora.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20181023163550.15211-2-emil.l.velikov@gmail.com

We wish to control certain driver_features flags on a per-device basis
while still sharing a single drm_driver instance across all the
devices. To that end introduce device.driver_features. By default
it will be set to ~0 to not impose any limits beyond
driver.driver_features. Drivers can then clear specific flags
in the per-device bitmask to limit the capabilities of the device.

An alternative approach would be to copy the driver_features from
the driver into the device in drm_dev_init(), however that would
require verifying that no driver is currently changing
driver.driver_features after drm_dev_init(). Hence the ~0 apporach
was easier.

Ideally we'd also make drm_driver const but there is plenty of code
left that wants to mutate it (eg. various vfunc assignments). We'll
need to fix all that up before we can make it const.

And while at it fix up the type of the feature flag passed to
drm_core_check_feature().

v2: Streamline the && vs. & (Chris)
    s/int/u32/ in drm_core_check_feature() args

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180913131622.17690-1-ville.syrjala@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NMichel Dänzer <michel.daenzer@amd.com>

This is something we've needed for a very long time now, as it makes
debugging issues with faulty MST hubs along with debugging issues
regarding us interfacing with hubs correctly vastly easier to debug.
Currently this can actually be done if you trace the i2c devices for DP
using ftrace but that's significantly less useful for a couple of
reasons:

- Tracing the i2c devices through ftrace means all of the traces are
  going to contain a lot of "garbage" output that we're sending over the
  i2c line. Most of this garbage comes from retrying transactions, DRM's
  helper library adding extra transactions to work around bad hubs, etc.
- Having a user set up ftrace so that they can provide debugging
  information is a lot more difficult then being able to say "just boot
  with drm.debug=0x100"
- We can potentially expand upon this tracing in the future to print
  debugging information in regards to other DP transactions like MST
  sideband transactions

This is inspired by a patch Rob Clark sent to do this a long time back.
Neither of us could find the patch however, so we both assumed it would
probably just be easier to rewrite it anyway.

Cc: Rob Clark <robdclark@gmail.com>
Signed-off-by: NLyude Paul <lyude@redhat.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180716154432.13433-1-lyude@redhat.com

This the beginning of an API for in-kernel clients.
First out is a way to get a framebuffer backed by a dumb buffer.

Only GEM drivers are supported.
The original idea of using an exported dma-buf was dropped because it
also creates an anonomous file descriptor which doesn't work when the
buffer is created from a kernel thread. The easy way out is to use
drm_driver.gem_prime_vmap to get the virtual address, which requires a
GEM object. This excludes the vmwgfx driver which is the only non-GEM
driver apart from the legacy ones. A solution for vmwgfx will have to be
worked out later if it wants to support the client API which it probably
will when we have a bootsplash client.
Suggested-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180703160354.59955-2-noralf@tronnes.org

When unplugging a hotpluggable DRM device we first unregister it
with drm_dev_unregister and then set drm_device.unplugged flag which
is used to mark device critical sections with drm_dev_enter()/
drm_dev_exit() preventing access to device resources that are not
available after the device is gone.
But drm_dev_unregister may lead to hotplug uevent(s) fired to
user-space on card and/or connector removal, thus making it possible
for user-space to try accessing a disconnected device.

Fix this by first making sure device is properly marked as
disconnected and only then unregister it.

Fixes: bee330f3 ("drm: Use srcu to protect drm_device.unplugged")
Signed-off-by: NOleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Reported-by: NAndrii Chepurnyi <andrii_chepurnyi@epam.com>
Cc: "Noralf Trønnes" <noralf@tronnes.org>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180522141304.18646-1-andr2000@gmail.com

This patch matches the sysfs name used in the unlinking with the
linking function. Otherwise, remove_compat_control_link() fails to remove
sysfs created by create_compat_control_link() in drm_dev_register().

Fixes: 6449b088 ("drm: Add fake controlD* symlinks for backwards
compat")
Cc: Dave Airlie <airlied@gmail.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Emil Velikov <emil.l.velikov@gmail.com>
Cc: David Herrmann <dh.herrmann@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Gustavo Padovan <gustavo@padovan.org>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: David Airlie <airlied@linux.ie>
Cc: dri-devel@lists.freedesktop.org
Cc: <stable@vger.kernel.org> # v4.10+
Signed-off-by: NHaneen Mohammed <hamohammed.sa@gmail.com>
[seanpaul added Fixes and Cc tags]
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20180511041542.GA4253@haneen-vb

With the ioctl and driver prep done, we can remove everything else.
Reviewed-by: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Cc: Gustavo Padovan <gustavo@padovan.org>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: David Airlie <airlied@linux.ie>
Link: https://patchwork.freedesktop.org/patch/msgid/20180420065159.4531-4-daniel.vetter@ffwll.ch

Use srcu to protect drm_device.unplugged in a race free manner.
Drivers can use drm_dev_enter()/drm_dev_exit() to protect and mark
sections preventing access to device resources that are not available
after the device is gone.
Suggested-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Signed-off-by: NOleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Reviewed-by: NOleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Tested-by: NOleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Cc: intel-gfx@lists.freedesktop.org
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/1522222715-11814-1-git-send-email-andr2000@gmail.com

The Parfait (version 2.1.0) static code analysis tool found the
following NULL pointer dereference problem.

- drivers/gpu/drm/drm_drv.c
Any calls to drm_minor_get_slot() could result in the return of a NULL
pointer when an invalid DRM device type is encountered.  The
return of NULL was removed with BUG() from drm_minor_get_slot().
Signed-off-by: NJoe Moriarty <joe.moriarty@oracle.com>
Reviewed-by: NSteven Sistare <steven.sistare@oracle.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180220191157.100960-3-joe.moriarty@oracle.com

Separate out lease debugging from the core.
Signed-off-by: NKeith Packard <keithp@keithp.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This patch extract DRM_* debug macros from drmP.h to drm_print.h and
move printing related functions used by these macros from drm_drv.[hc]
to drm_print.[hc].
Signed-off-by: NHaneen Mohammed <hamohammed.sa@gmail.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/4020bc7c5ffad2af516919f78bb837c7f366b82b.1508297716.git.hamohammed.sa@gmail.com

Reference counting functions in the kernel typically use get/put suffixes. For
maintaining coding style consistency, introduce drm_dev_{get/put} functions. All
callers of drm_dev_ref() API have been converted in this patch and hence it has
been dropped while the drm_dev_unref() API with non-trivial number of users
remains for compatibility.

The semantic patch scripts/coccinelle/api/drm-get-put.cocci has been updated
with the new helper for conversion of drm_dev_unref() to drm_dev_put()
Signed-off-by: NAishwarya Pant <aishpant@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/6babda56134035a98220d5d37a4fd4048df214ce.1506413698.git.aishpant@gmail.com

Use drm_dev_unregister to unregister the interfaces, which also allows
us to simplify the open_count == 0 case.
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170802115604.12734-5-daniel.vetter@ffwll.ch

The only thing modern drivers are supposed to do in lastclose is
restore the fb emulation state. Which is entirely optional, and
there's really no reason to do that. So restrict it to legacy drivers
(where the driver cleanup essentially happens in lastclose).

This will also allow us to share the unregister function with
drm_dev_unplug().

Quoting my reply to Alex on dri-devel:
On Thu, Aug 3, 2017 at 1:17 AM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> On Wed, Aug 2, 2017 at 10:50 PM, Alex Deucher <alexdeucher@gmail.com> wrote:
>> On Wed, Aug 2, 2017 at 7:56 AM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>>> The only thing modern drivers are supposed to do in lastclose is
>>> restore the fb emulation state. Which is entirely optional, and
>>> there's really no reason to do that. So restrict it to legacy drivers
>>> (where the driver cleanup essentially happens in lastclose).
>>
>> vga_switcheroo_process_delayed_switch() gets called in lastclose.
>> Won't that need to get moved elsewhere for this to work?
>
> Hm right, I forgot the lazy way to do runtime pm by keeping the device
> alive as long as anyone has an open fd for it ... This shouldn't be a
> problem, since you need to unregister from vgaswitcheroo anyway on
> unload. Maybe that blows up, I'll check the code and augment the patch
> as needed.

So I think there's 3 cases:
- Trying to unload the module. You can't do that while anyone has the
fd still open, so lastclose is guaranteeed to run.
- Forcefully unbinding the driver through sysfs. Not any better, since
the can_switch stuff checks for the open count, and so will delay the
delayed switch no matter what.
- Actual hotremoval: a) not implemented since none of the drivers
taking part in vgaswitcheroo correctly unplug the drm device and b)
you can't hotremove a chip from a laptop.

v2: Extend commit message with m-l discussion.
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170802115604.12734-4-daniel.vetter@ffwll.ch

While at it, also ocd and give them a consistent drm_dev_ prefix, like
the other device instance functionality. Plus move the functions into
the right places.
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170802115604.12734-3-daniel.vetter@ffwll.ch

If the DRM core fails to init for whatever reason, ensure that
no driver ever calls drm_dev_register().

This is best done at drm_dev_init() as it covers drivers that call
drm_dev_alloc() as well as drivers that prefer to embed struct
drm_device into their own device struct and call drm_dev_init()
themselves.

In my case I had so many dynamic device majors used that the major
number for DRM (226) was stolen, causing DRM core init to fail after
failing to register a chrdev, and ultimately calling debugfs_remove()
on drm_debugfs_root in drm_core_exit().

After drm core failed to init, VGEM was still calling drm_dev_register(),
ultimately leading to drm_debugfs_init(), with drm_debugfs_root passed
as the root for the new debugfs dir at debugfs_create_dir().

This led to a kernel panic once we were either derefencing root->d_inode
while it was NULL or calling root->d_inode->i_op->lookup() while it was
NULL in debugfs at inode_lock() or lookup_*().
Signed-off-by: NAlexandru Moise <00moses.alexander00@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170708214352.GA27205@gmail.com

commit a39be606 ("drm: Do a full device unregister when unplugging")
causes backtraces like this one when unplugging an usb drm device while
it is in use:

usb 2-3: USB disconnect, device number 25
------------[ cut here ]------------
WARNING: CPU: 0 PID: 242 at drivers/gpu/drm/drm_mode_config.c:424
   drm_mode_config_cleanup+0x220/0x280 [drm]
...
RIP: 0010:drm_mode_config_cleanup+0x220/0x280 [drm]
...
Call Trace:
 gm12u320_modeset_cleanup+0xe/0x10 [gm12u320]
 gm12u320_driver_unload+0x35/0x70 [gm12u320]
 drm_dev_unregister+0x3c/0xe0 [drm]
 drm_unplug_dev+0x12/0x60 [drm]
 gm12u320_usb_disconnect+0x36/0x40 [gm12u320]
 usb_unbind_interface+0x72/0x280
 device_release_driver_internal+0x158/0x210
 device_release_driver+0x12/0x20
 bus_remove_device+0x104/0x180
 device_del+0x1d2/0x350
 usb_disable_device+0x9f/0x270
 usb_disconnect+0xc6/0x260
...
[drm:drm_mode_config_cleanup [drm]] *ERROR* connector Unknown-1 leaked!
------------[ cut here ]------------
WARNING: CPU: 0 PID: 242 at drivers/gpu/drm/drm_mode_config.c:458
   drm_mode_config_cleanup+0x268/0x280 [drm]
...
<same Call Trace>
---[ end trace 80df975dae439ed6 ]---
general protection fault: 0000 [#1] SMP
...
Call Trace:
 ? __switch_to+0x225/0x450
 drm_mode_rmfb_work_fn+0x55/0x70 [drm]
 process_one_work+0x193/0x3c0
 worker_thread+0x4a/0x3a0
...
RIP: drm_framebuffer_remove+0x62/0x3f0 [drm] RSP: ffffb776c39dfd98
---[ end trace 80df975dae439ed7 ]---

After which the system is unusable this is caused by drm_dev_unregister
getting called immediately on unplug, which calls the drivers unload
function which calls drm_mode_config_cleanup which removes the framebuffer
object while userspace is still holding a reference to it.

Reverting commit a39be606 ("drm: Do a full device unregister
when unplugging") leads to the following oops on unplug instead,
when userspace closes the last fd referencing the drm_dev:

sysfs group 'power' not found for kobject 'card1-Unknown-1'
------------[ cut here ]------------
WARNING: CPU: 0 PID: 2459 at fs/sysfs/group.c:237
   sysfs_remove_group+0x80/0x90
...
RIP: 0010:sysfs_remove_group+0x80/0x90
...
Call Trace:
 dpm_sysfs_remove+0x57/0x60
 device_del+0xfd/0x350
 device_unregister+0x1a/0x60
 drm_sysfs_connector_remove+0x39/0x50 [drm]
 drm_connector_unregister+0x5a/0x70 [drm]
 drm_connector_unregister_all+0x45/0xa0 [drm]
 drm_modeset_unregister_all+0x12/0x30 [drm]
 drm_dev_unregister+0xca/0xe0 [drm]
 drm_put_dev+0x32/0x60 [drm]
 drm_release+0x2f3/0x380 [drm]
 __fput+0xdf/0x1e0
...
---[ end trace ecfb91ac85688bbe ]---
BUG: unable to handle kernel NULL pointer dereference at 00000000000000a8
IP: down_write+0x1f/0x40
...
Call Trace:
 debugfs_remove_recursive+0x55/0x1b0
 drm_debugfs_connector_remove+0x21/0x40 [drm]
 drm_connector_unregister+0x62/0x70 [drm]
 drm_connector_unregister_all+0x45/0xa0 [drm]
 drm_modeset_unregister_all+0x12/0x30 [drm]
 drm_dev_unregister+0xca/0xe0 [drm]
 drm_put_dev+0x32/0x60 [drm]
 drm_release+0x2f3/0x380 [drm]
 __fput+0xdf/0x1e0
...
---[ end trace ecfb91ac85688bbf ]---

This is caused by the revert moving back to drm_unplug_dev calling
drm_minor_unregister which does:

        device_del(minor->kdev);
        dev_set_drvdata(minor->kdev, NULL); /* safety belt */
        drm_debugfs_cleanup(minor);

Causing the sysfs entries to already be removed even though we still
have references to them in e.g. drm_connector.

Note we must call drm_minor_unregister to notify userspace of the unplug
of the device, so calling drm_dev_unregister is not completely wrong the
problem is that drm_dev_unregister does too much.

This commit fixes drm_unplug_dev by not only reverting
commit a39be606 ("drm: Do a full device unregister when unplugging")
but by also adding a call to drm_modeset_unregister_all before the
drm_minor_unregister calls to make sure all sysfs entries are removed
before calling device_del(minor->kdev) thereby also fixing the second
set of oopses caused by just reverting the commit.

Fixes: a39be606 ("drm: Do a full device unregister when unplugging")
Cc: stable@vger.kernel.org
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jeffy <jeffy.chen@rock-chips.com>
Cc: Marco Diego Aurélio Mesquita <marcodiegomesquita@gmail.com>
Reported-by: NMarco Diego Aurélio Mesquita <marcodiegomesquita@gmail.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20170601115430.4113-1-hdegoede@redhat.com