diff options
| author | Jani Nikula <jani.nikula@intel.com> | 2022-01-20 11:48:56 +0200 |
|---|---|---|
| committer | Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2022-04-08 13:57:56 +0200 |
| commit | e2f679add74fe0dc032f64b6b6d3c1e99615d6e2 (patch) | |
| tree | f137aac170242e61e45d6cd151ce3f79ac1716f1 /include | |
| parent | f6d1fd0abaacce95fdccfc19fc2175d8d9b37bfb (diff) | |
| download | linux-stable-e2f679add74fe0dc032f64b6b6d3c1e99615d6e2.tar.gz linux-stable-e2f679add74fe0dc032f64b6b6d3c1e99615d6e2.tar.bz2 linux-stable-e2f679add74fe0dc032f64b6b6d3c1e99615d6e2.zip | |
drm/locking: fix drm_modeset_acquire_ctx kernel-doc
[ Upstream commit 6f043b5969a4d6d385ca429388ded37e30e0d179 ]
The stack_depot member was added without kernel-doc, leading to below
warning. Fix it.
./include/drm/drm_modeset_lock.h:74: warning: Function parameter or
member 'stack_depot' not described in 'drm_modeset_acquire_ctx'
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Fixes: cd06ab2fd48f ("drm/locking: add backtrace for locking contended locks without backoff")
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Tested-by: Stephen Rothwell <sfr@canb.auug.org.au>
Link: https://patchwork.freedesktop.org/patch/msgid/20220120094856.3004147-1-jani.nikula@intel.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Diffstat (limited to 'include')
| -rw-r--r-- | include/drm/drm_modeset_lock.h | 1 |
1 files changed, 1 insertions, 0 deletions
diff --git a/include/drm/drm_modeset_lock.h b/include/drm/drm_modeset_lock.h index b84693fbd2b5..ec4f543c3d95 100644 --- a/include/drm/drm_modeset_lock.h +++ b/include/drm/drm_modeset_lock.h @@ -34,6 +34,7 @@ struct drm_modeset_lock; * struct drm_modeset_acquire_ctx - locking context (see ww_acquire_ctx) * @ww_ctx: base acquire ctx * @contended: used internally for -EDEADLK handling + * @stack_depot: used internally for contention debugging * @locked: list of held locks * @trylock_only: trylock mode used in atomic contexts/panic notifiers * @interruptible: whether interruptible locking should be used. |