[<prev] [next>] [day] [month] [year] [list]
Message-Id: <20171207141413.2008240-1-arnd@arndb.de>
Date: Thu, 7 Dec 2017 15:14:00 +0100
From: Arnd Bergmann <arnd@...db.de>
To: Jani Nikula <jani.nikula@...ux.intel.com>,
Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>,
Rodrigo Vivi <rodrigo.vivi@...el.com>,
David Airlie <airlied@...ux.ie>
Cc: Arnd Bergmann <arnd@...db.de>,
Chris Wilson <chris@...is-wilson.co.uk>,
Tvrtko Ursulin <tvrtko.ursulin@...el.com>,
Mika Kuoppala <mika.kuoppala@...el.com>,
Ville Syrjälä
<ville.syrjala@...ux.intel.com>, intel-gfx@...ts.freedesktop.org,
dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Subject: [PATCH] drm/i915: add FTRACE dependency for DRM_I915_TRACE_GEM
The new trace option gratuitously added a 'select TRACING' statement,
which now causes build failures in other code that assumed tracepoints
were only available with FTRACE:
ERROR: "__tracepoint_ucsi_command" [drivers/usb/typec/ucsi/typec_ucsi.ko] undefined!
ERROR: "__tracepoint_ucsi_register_port" [drivers/usb/typec/ucsi/typec_ucsi.ko] undefined!
ERROR: "__tracepoint_ucsi_notify" [drivers/usb/typec/ucsi/typec_ucsi.ko] undefined!
ERROR: "__tracepoint_ucsi_reset_ppm" [drivers/usb/typec/ucsi/typec_ucsi.ko] undefined!
ERROR: "__tracepoint_ucsi_run_command" [drivers/usb/typec/ucsi/typec_ucsi.ko] undefined!
drivers/usb/dwc3/gadget.o: In function `__dwc3_prepare_one_trb':
gadget.c:(.text+0x1c5): undefined reference to `__tracepoint_dwc3_prepare_trb'
drivers/usb/dwc3/gadget.o: In function `__dwc3_cleanup_done_trbs':
gadget.c:(.text+0x3f0): undefined reference to `__tracepoint_dwc3_complete_trb'
drivers/usb/dwc3/gadget.o: In function `dwc3_gadget_ep_free_request':
gadget.c:(.text+0x666): undefined reference to `__tracepoint_dwc3_free_request'
This adds an explicit FTRACE dependency here, to ensure this is already
the case. This matches what the other drivers have that select TRACING.
Generally speaking, there is a bigger problem with CONFIG_DRM_I915_DEBUG
though, it selects several other partially related symbols (DEBUGFS,
I2C_CHARDEV, PREEMPT_COUNT, X86_MSR, etc that are each user-visible and
that other symbols in turn depend on. This can easily lead to circular
dependencies and should be avoided. I tried turning those all into
'depends on', which is normally a good strategy, but that seems to
completely defeat the intention of CONFIG_DRM_I915_DEBUG. It might
be better to just remove this completely, possibly replace it with a
Kconfig fragment.
Fixes: bccd3b831185 ("drm/i915: Use trace_printk to provide a death rattle for GEM")
Signed-off-by: Arnd Bergmann <arnd@...db.de>
---
drivers/gpu/drm/i915/Kconfig.debug | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/Kconfig.debug b/drivers/gpu/drm/i915/Kconfig.debug
index fa36491495b1..1a1b9732f657 100644
--- a/drivers/gpu/drm/i915/Kconfig.debug
+++ b/drivers/gpu/drm/i915/Kconfig.debug
@@ -18,6 +18,7 @@ config DRM_I915_WERROR
config DRM_I915_DEBUG
bool "Enable additional driver debugging"
depends on DRM_I915
+ depends on FTRACE # for DRM_I915_TRACE_GEM
select DEBUG_FS
select PREEMPT_COUNT
select I2C_CHARDEV
@@ -53,6 +54,7 @@ config DRM_I915_DEBUG_GEM
config DRM_I915_TRACE_GEM
bool "Insert extra ftrace output from the GEM internals"
+ depends on FTRACE
select TRACING
default n
help
--
2.9.0
Powered by blists - more mailing lists