This reverts commit 118182e9d7d5afa0c7c10f568afb46ab78b462e9.
It's causing too much trouble when compile-testing for non-i915 folks.
Cc: Chris Wilson <[email protected]>
Cc: Jani Nikula <[email protected]>
Cc: Andrew Morton <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
---
drivers/gpu/drm/i915/Kconfig | 8 --------
drivers/gpu/drm/i915/Kconfig.debug | 5 -----
drivers/gpu/drm/i915/Makefile | 2 --
3 files changed, 15 deletions(-)
delete mode 100644 drivers/gpu/drm/i915/Kconfig.debug
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 5e3aa87e8f48..74acca9bcd9d 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -71,11 +71,3 @@ config DRM_I915_PRELIMINARY_HW_SUPPORT
option changes the default for that module option.
If in doubt, say "N".
-
-menu "DRM i915 Debugging"
-
-depends on DRM_I915
-
-source drivers/gpu/drm/i915/Kconfig.debug
-
-endmenu
diff --git a/drivers/gpu/drm/i915/Kconfig.debug b/drivers/gpu/drm/i915/Kconfig.debug
deleted file mode 100644
index 070a03527bc5..000000000000
--- a/drivers/gpu/drm/i915/Kconfig.debug
+++ /dev/null
@@ -1,5 +0,0 @@
-config DRM_I915_WERROR
- bool "Force GCC to throw an error instead of a warning when compiling"
- default n
- ---help---
- Add -Werror to the build flags for (and only for) i915.ko
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 93d99b744531..b7ddf48e1d75 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -2,8 +2,6 @@
# Makefile for the drm device driver. This driver provides support for the
# Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
-subdir-ccflags-$(CONFIG_DRM_I915_WERROR) := -Werror
-
# Please keep these build lists sorted!
# core driver code
--
2.1.4
On Tue, May 26, 2015 at 07:47:22AM +0200, Daniel Vetter wrote:
> This reverts commit 118182e9d7d5afa0c7c10f568afb46ab78b462e9.
>
> It's causing too much trouble when compile-testing for non-i915 folks.
What's the argument against using COMPILE_TEST as a proxy for detecting
all(yes|mod)config as in Damien's patch?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Tue, May 26, 2015 at 08:57:13AM +0100, Chris Wilson wrote:
> On Tue, May 26, 2015 at 07:47:22AM +0200, Daniel Vetter wrote:
> > This reverts commit 118182e9d7d5afa0c7c10f568afb46ab78b462e9.
> >
> > It's causing too much trouble when compile-testing for non-i915 folks.
>
> What's the argument against using COMPILE_TEST as a proxy for detecting
> all(yes|mod)config as in Damien's patch?
I also thought about random users bisecting who'll then also might trip
over this. Figure that overall the benefit isn't good enough given the
trouble this seems to have caused immediately. 0-day is pretty fast at
screaming around about new compiler warnings anyway, for the cases where I
miss them.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Tue, May 26, 2015 at 10:20:26AM +0200, Daniel Vetter wrote:
> On Tue, May 26, 2015 at 08:57:13AM +0100, Chris Wilson wrote:
> > On Tue, May 26, 2015 at 07:47:22AM +0200, Daniel Vetter wrote:
> > > This reverts commit 118182e9d7d5afa0c7c10f568afb46ab78b462e9.
> > >
> > > It's causing too much trouble when compile-testing for non-i915 folks.
> >
> > What's the argument against using COMPILE_TEST as a proxy for detecting
> > all(yes|mod)config as in Damien's patch?
>
> I also thought about random users bisecting who'll then also might trip
> over this. Figure that overall the benefit isn't good enough given the
> trouble this seems to have caused immediately. 0-day is pretty fast at
> screaming around about new compiler warnings anyway, for the cases where I
> miss them.
You haven't fixed the issue of breaking a bisect using allyesconfig
unless you modify history. Either way they need to do a couple of skips.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre