From: Namhyung Kim <namhyung@kernel.org> To: Peter Zijlstra <peterz@infradead.org>, Ingo Molnar <mingo@kernel.org>, Will Deacon <will@kernel.org>, Waiman Long <longman@redhat.com>, Boqun Feng <boqun.feng@gmail.com> Cc: LKML <linux-kernel@vger.kernel.org>, Thomas Gleixner <tglx@linutronix.de>, Steven Rostedt <rostedt@goodmis.org>, Byungchul Park <byungchul.park@lge.com>, "Paul E. McKenney" <paul.mckenney@linaro.org>, Mathieu Desnoyers <mathieu.desnoyers@efficios.com>, Radoslaw Burny <rburny@google.com>, Jani Nikula <jani.nikula@linux.intel.com>, Joonas Lahtinen <joonas.lahtinen@linux.intel.com>, Rodrigo Vivi <rodrigo.vivi@intel.com>, Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>, intel-gfx@lists.freedesktop.org Subject: [PATCH 05/12] drm/i915: Protect lockdep functions with #ifdef Date: Tue, 8 Feb 2022 10:42:01 -0800 [thread overview] Message-ID: <20220208184208.79303-6-namhyung@kernel.org> (raw) In-Reply-To: <20220208184208.79303-1-namhyung@kernel.org> With upcoming lock tracepoints config, it'd define some of lockdep functions without enabling CONFIG_LOCKDEP actually. The existing code assumes those functions will be removed by the preprocessor but it's not the case anymore. Let's protect the code with #ifdef's explicitly. Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: intel-gfx@lists.freedesktop.org Signed-off-by: Namhyung Kim <namhyung@kernel.org> --- drivers/gpu/drm/i915/intel_wakeref.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_wakeref.c b/drivers/gpu/drm/i915/intel_wakeref.c index dfd87d082218..6e4b8d036283 100644 --- a/drivers/gpu/drm/i915/intel_wakeref.c +++ b/drivers/gpu/drm/i915/intel_wakeref.c @@ -106,8 +106,11 @@ void __intel_wakeref_init(struct intel_wakeref *wf, wf->wakeref = 0; INIT_DELAYED_WORK(&wf->work, __intel_wakeref_put_work); + +#ifdef CONFIG_LOCKDEP lockdep_init_map(&wf->work.work.lockdep_map, "wakeref.work", &key->work, 0); +#endif } int intel_wakeref_wait_for_idle(struct intel_wakeref *wf) -- 2.35.0.263.gb82422642f-goog
WARNING: multiple messages have this Message-ID (diff)
From: Namhyung Kim <namhyung@kernel.org> To: Peter Zijlstra <peterz@infradead.org>, Ingo Molnar <mingo@kernel.org>, Will Deacon <will@kernel.org>, Waiman Long <longman@redhat.com>, Boqun Feng <boqun.feng@gmail.com> Cc: intel-gfx@lists.freedesktop.org, LKML <linux-kernel@vger.kernel.org>, Steven Rostedt <rostedt@goodmis.org>, Radoslaw Burny <rburny@google.com>, Byungchul Park <byungchul.park@lge.com>, "Paul E. McKenney" <paul.mckenney@linaro.org>, Mathieu Desnoyers <mathieu.desnoyers@efficios.com>, Thomas Gleixner <tglx@linutronix.de> Subject: [Intel-gfx] [PATCH 05/12] drm/i915: Protect lockdep functions with #ifdef Date: Tue, 8 Feb 2022 10:42:01 -0800 [thread overview] Message-ID: <20220208184208.79303-6-namhyung@kernel.org> (raw) In-Reply-To: <20220208184208.79303-1-namhyung@kernel.org> With upcoming lock tracepoints config, it'd define some of lockdep functions without enabling CONFIG_LOCKDEP actually. The existing code assumes those functions will be removed by the preprocessor but it's not the case anymore. Let's protect the code with #ifdef's explicitly. Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: intel-gfx@lists.freedesktop.org Signed-off-by: Namhyung Kim <namhyung@kernel.org> --- drivers/gpu/drm/i915/intel_wakeref.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_wakeref.c b/drivers/gpu/drm/i915/intel_wakeref.c index dfd87d082218..6e4b8d036283 100644 --- a/drivers/gpu/drm/i915/intel_wakeref.c +++ b/drivers/gpu/drm/i915/intel_wakeref.c @@ -106,8 +106,11 @@ void __intel_wakeref_init(struct intel_wakeref *wf, wf->wakeref = 0; INIT_DELAYED_WORK(&wf->work, __intel_wakeref_put_work); + +#ifdef CONFIG_LOCKDEP lockdep_init_map(&wf->work.work.lockdep_map, "wakeref.work", &key->work, 0); +#endif } int intel_wakeref_wait_for_idle(struct intel_wakeref *wf) -- 2.35.0.263.gb82422642f-goog
next prev parent reply other threads:[~2022-02-08 18:42 UTC|newest] Thread overview: 109+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-02-08 18:41 [RFC 00/12] locking: Separate lock tracepoints from lockdep/lock_stat (v1) Namhyung Kim 2022-02-08 18:41 ` Namhyung Kim 2022-02-08 18:41 ` [Intel-gfx] " Namhyung Kim 2022-02-08 18:41 ` [PATCH 01/12] locking: Pass correct outer wait type info Namhyung Kim 2022-02-08 18:41 ` [PATCH 02/12] cgroup: rstat: Make cgroup_rstat_cpu_lock name readable Namhyung Kim 2022-02-08 18:41 ` Namhyung Kim 2022-02-08 18:46 ` Tejun Heo 2022-02-08 19:16 ` Namhyung Kim 2022-02-08 19:16 ` Namhyung Kim 2022-02-08 23:51 ` Namhyung Kim 2022-02-08 23:51 ` Namhyung Kim 2022-02-08 18:41 ` [PATCH 03/12] timer: Protect lockdep functions with #ifdef Namhyung Kim 2022-02-08 19:36 ` Steven Rostedt 2022-02-08 20:29 ` Namhyung Kim 2022-02-08 21:19 ` Steven Rostedt 2022-02-08 18:42 ` [PATCH 04/12] workqueue: " Namhyung Kim 2022-02-08 18:48 ` Tejun Heo 2022-02-08 19:17 ` Namhyung Kim 2022-02-08 19:38 ` Steven Rostedt 2022-02-08 18:42 ` Namhyung Kim [this message] 2022-02-08 18:42 ` [Intel-gfx] [PATCH 05/12] drm/i915: " Namhyung Kim 2022-02-08 18:51 ` Jani Nikula 2022-02-08 18:51 ` [Intel-gfx] " Jani Nikula 2022-02-08 19:22 ` Namhyung Kim 2022-02-08 19:22 ` [Intel-gfx] " Namhyung Kim 2022-02-09 13:49 ` Jani Nikula 2022-02-09 13:49 ` [Intel-gfx] " Jani Nikula 2022-02-09 16:27 ` Steven Rostedt 2022-02-09 16:27 ` [Intel-gfx] " Steven Rostedt 2022-02-09 19:28 ` Namhyung Kim 2022-02-09 19:28 ` [Intel-gfx] " Namhyung Kim 2022-02-08 18:42 ` [PATCH 06/12] btrfs: change lockdep class size check using ks->names Namhyung Kim 2022-02-08 19:03 ` David Sterba 2022-02-08 18:42 ` [PATCH 07/12] locking: Introduce CONFIG_LOCK_INFO Namhyung Kim 2022-02-08 18:42 ` [PATCH 08/12] locking/mutex: Init name properly w/ CONFIG_LOCK_INFO Namhyung Kim 2022-02-08 18:42 ` [PATCH 09/12] locking: Add more static lockdep init macros Namhyung Kim 2022-02-08 18:42 ` [PATCH 10/12] locking: Add CONFIG_LOCK_TRACEPOINTS option Namhyung Kim 2022-02-08 18:42 ` [PATCH 11/12] locking/mutex: Revive fast functions for CONFIG_LOCK_TRACEPOINTS Namhyung Kim 2022-02-09 8:40 ` Peter Zijlstra 2022-02-09 20:15 ` Namhyung Kim 2022-02-08 18:42 ` [PATCH 12/12] locking: Move lock_acquired() from the fast path Namhyung Kim 2022-02-08 19:14 ` [RFC 00/12] locking: Separate lock tracepoints from lockdep/lock_stat (v1) Namhyung Kim 2022-02-08 19:14 ` Namhyung Kim 2022-02-08 19:14 ` [Intel-gfx] " Namhyung Kim 2022-02-09 9:09 ` Peter Zijlstra 2022-02-09 9:09 ` Peter Zijlstra 2022-02-09 9:09 ` Peter Zijlstra 2022-02-09 18:19 ` [Intel-gfx] " Waiman Long 2022-02-09 18:19 ` Waiman Long 2022-02-09 18:19 ` Waiman Long 2022-02-09 18:29 ` Mathieu Desnoyers 2022-02-09 18:29 ` Mathieu Desnoyers 2022-02-09 18:29 ` [Intel-gfx] " Mathieu Desnoyers 2022-02-09 19:02 ` Waiman Long 2022-02-09 19:02 ` Waiman Long 2022-02-09 19:02 ` Waiman Long 2022-02-09 19:17 ` Mathieu Desnoyers 2022-02-09 19:17 ` Mathieu Desnoyers 2022-02-09 19:17 ` [Intel-gfx] " Mathieu Desnoyers 2022-02-09 19:37 ` Waiman Long 2022-02-09 19:37 ` Waiman Long 2022-02-09 19:37 ` Waiman Long 2022-02-09 19:22 ` [Intel-gfx] " Namhyung Kim 2022-02-09 19:22 ` Namhyung Kim 2022-02-09 19:22 ` Namhyung Kim 2022-02-09 19:28 ` Mathieu Desnoyers 2022-02-09 19:28 ` Mathieu Desnoyers 2022-02-09 19:28 ` [Intel-gfx] " Mathieu Desnoyers 2022-02-09 19:45 ` Namhyung Kim 2022-02-09 19:45 ` Namhyung Kim 2022-02-09 19:45 ` [Intel-gfx] " Namhyung Kim 2022-02-09 19:56 ` Mathieu Desnoyers 2022-02-09 19:56 ` Mathieu Desnoyers 2022-02-09 19:56 ` [Intel-gfx] " Mathieu Desnoyers 2022-02-09 20:17 ` Waiman Long 2022-02-09 20:17 ` Waiman Long 2022-02-09 20:17 ` [Intel-gfx] " Waiman Long 2022-02-10 0:27 ` Namhyung Kim 2022-02-10 0:27 ` Namhyung Kim 2022-02-10 0:27 ` Namhyung Kim 2022-02-10 2:12 ` Waiman Long 2022-02-10 2:12 ` Waiman Long 2022-02-10 2:12 ` [Intel-gfx] " Waiman Long 2022-02-10 9:33 ` Peter Zijlstra 2022-02-10 9:33 ` Peter Zijlstra 2022-02-10 9:33 ` [Intel-gfx] " Peter Zijlstra 2022-02-10 0:32 ` Namhyung Kim 2022-02-10 0:32 ` Namhyung Kim 2022-02-10 0:32 ` Namhyung Kim 2022-02-10 9:13 ` Peter Zijlstra 2022-02-10 9:13 ` Peter Zijlstra 2022-02-10 9:13 ` [Intel-gfx] " Peter Zijlstra 2022-02-10 19:14 ` Paul E. McKenney 2022-02-10 19:14 ` Paul E. McKenney 2022-02-10 19:27 ` Waiman Long 2022-02-10 19:27 ` Waiman Long 2022-02-10 19:27 ` [Intel-gfx] " Waiman Long 2022-02-10 20:10 ` Paul E. McKenney 2022-02-10 20:10 ` Paul E. McKenney 2022-02-11 5:57 ` Namhyung Kim 2022-02-11 5:57 ` Namhyung Kim 2022-02-11 5:57 ` [Intel-gfx] " Namhyung Kim 2022-02-11 5:55 ` Namhyung Kim 2022-02-11 5:55 ` Namhyung Kim 2022-02-11 5:55 ` [Intel-gfx] " Namhyung Kim 2022-02-11 10:39 ` Peter Zijlstra 2022-02-11 10:39 ` Peter Zijlstra 2022-02-11 10:39 ` [Intel-gfx] " Peter Zijlstra 2022-02-08 19:43 [Intel-gfx] [RFC RESEND 00/12] locking: Separate lock tracepoints from lockdep/lock_stat (v1.1) Namhyung Kim 2022-02-08 19:43 ` [PATCH 05/12] drm/i915: Protect lockdep functions with #ifdef Namhyung Kim
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20220208184208.79303-6-namhyung@kernel.org \ --to=namhyung@kernel.org \ --cc=boqun.feng@gmail.com \ --cc=byungchul.park@lge.com \ --cc=intel-gfx@lists.freedesktop.org \ --cc=jani.nikula@linux.intel.com \ --cc=joonas.lahtinen@linux.intel.com \ --cc=linux-kernel@vger.kernel.org \ --cc=longman@redhat.com \ --cc=mathieu.desnoyers@efficios.com \ --cc=mingo@kernel.org \ --cc=paul.mckenney@linaro.org \ --cc=peterz@infradead.org \ --cc=rburny@google.com \ --cc=rodrigo.vivi@intel.com \ --cc=rostedt@goodmis.org \ --cc=tglx@linutronix.de \ --cc=tvrtko.ursulin@linux.intel.com \ --cc=will@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.