[PATCH] drm/mm: fix duplicate 'const' declaration specifier

[PATCH] drm/mm: fix duplicate 'const' declaration specifier

[Nick Desaulniers]

Found with -Wduplicate-decl-specifier, a relatively new compiler flag in
GCC7, and Clang.

list_for_each_entry() eventually calls container_of(), which marks the
loop variable as const.  The first argument to list_for_each_entry() is
a type, which should not already be marked const, otherwise the loop
variable is marked const twice.

While this particular call site does not modify the loop variable,
trying to do so would already result in a compile time failure, so we
can remove the current const. Other call sites do not mark the loop
variable const.

Signed-off-by: Nick Desaulniers <nick.desaulniers@gmail.com>
---
 include/drm/drm_mm.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/drm/drm_mm.h b/include/drm/drm_mm.h
index 49b292e98fec..6716af9290c9 100644
--- a/include/drm/drm_mm.h
+++ b/include/drm/drm_mm.h
@@ -281,7 +281,7 @@ static inline u64 drm_mm_hole_node_start(const struct drm_mm_node *hole_node)
 	return __drm_mm_hole_node_start(hole_node);
 }
 
-static inline u64 __drm_mm_hole_node_end(const struct drm_mm_node *hole_node)
+static inline u64 __drm_mm_hole_node_end(struct drm_mm_node *hole_node)
 {
 	return list_next_entry(hole_node, node_list)->start;
 }
@@ -297,7 +297,7 @@ static inline u64 __drm_mm_hole_node_end(const struct drm_mm_node *hole_node)
  * Returns:
  * End of the subsequent hole.
  */
-static inline u64 drm_mm_hole_node_end(const struct drm_mm_node *hole_node)
+static inline u64 drm_mm_hole_node_end(struct drm_mm_node *hole_node)
 {
 	return __drm_mm_hole_node_end(hole_node);
 }
-- 
2.11.0

Re: [PATCH] drm/mm: fix duplicate 'const' declaration specifier

[Nick Desaulniers]

ah seems like there's more of these:

drivers/gpu/drm/drm_mm.c:922

surprised compiling drivers/gpu/drm/drm_mm.o did not catch this the
first time...

Re: [PATCH] drm/mm: fix duplicate 'const' declaration specifier

[Nick Desaulniers]

Please disregard this patch.  I think I may have found a bug in Clang,
or at least an incompatibility with GCC 7.1.

Clang bug: https://bugs.llvm.org/show_bug.cgi?id=32985