All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nathan Chancellor <nathan@kernel.org>
To: Jim Cromie <jim.cromie@gmail.com>
Cc: jbaron@akamai.com, daniel.vetter@ffwll.ch,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	amd-gfx@lists.freedesktop.org,
	intel-gvt-dev@lists.freedesktop.org,
	intel-gfx@lists.freedesktop.org, jani.nikula@intel.com,
	ville.syrjala@linux.intel.com, seanpaul@chromium.org,
	robdclark@gmail.com, gregkh@linuxfoundation.org,
	Luc Van Oostenryck <luc.vanoostenryck@gmail.com>,
	Nick Desaulniers <ndesaulniers@google.com>,
	Tom Rix <trix@redhat.com>,
	linux-sparse@vger.kernel.org, llvm@lists.linux.dev
Subject: Re: [PATCH v4 18/21] compiler.h: RFC - s/__LINE__/__COUNTER__/ in __UNIQUE_ID fallback
Date: Thu, 13 Jul 2023 10:19:01 -0700	[thread overview]
Message-ID: <20230713171901.GA4036397@dev-arch.thelio-3990X> (raw)
In-Reply-To: <20230713163626.31338-19-jim.cromie@gmail.com>

Hi Jim

On Thu, Jul 13, 2023 at 10:36:23AM -0600, Jim Cromie wrote:
> We currently have 3 defns for __UNIQUE_ID(); gcc and clang are using
> __COUNTER__ for real uniqueness, 3rd just uses __LINE__, which should
> fail on this (and harder to avoid situations):
> 
>   DECLARE_FOO(); DECLARE_FOO();
> 
> Its 2023, can we haz a no-fallback __UNIQUE_ID ?

Yeah, I fail to see how this fallback definition can actually be used
after commit 95207db8166a ("Remove Intel compiler support"); even before
that, it would be pretty unlikely since icc usage has not been visible
for a long time. The kernel only officially supports clang or GCC now,
so the definitions of __UNIQUE_ID() in include/linux/compiler-clang.h
and include/linux/compiler-gcc.h should always be used because of the
include in include/linux/compiler_types.h, right?

I think the correct clean up is to just hoist the definition of
__UNIQUE_ID() out of the individual compiler headers into the common one
here but...

> NOTE:
> 
> This also changes __UNIQUE_ID_ to _kaUID_.  Ive been getting
> lkp-reports of collisions on names which should be unique; this
> shouldnt happen on gcc & clang, but does on some older ones, on some
> platforms, on some allyes & rand-configs.  Like this:
> 
> mips64-linux-ld:
> drivers/gpu/drm/display/drm_dp_helper.o:(__dyndbg_class_users+0x0):
> multiple definition of `__UNIQUE_ID_ddebug_class_user405';
> drivers/gpu/drm/drm_gem_shmem_helper.o:(__dyndbg_class_users+0x0):
> first defined here

This problem cannot be addressed with this patch given the above
information, no? Seems like that might mean that __COUNTER__ has issues
in earlier compilers?

Cheers,
Nathan

> Like above, the collision reports appear to always be 3-digit
> counters, which look like line-numbers.  Changing to _kaUID_ in this
> defn should make it more obvious (in *.i file) when a fallback has
> happened.  To be clear, I havent seen it yet.  Nor have I seen the
> multiple-defn problem above since adding this patch.
> 
> Lets see what lkp-robot says about this.
> 
> CC: Luc Van Oostenryck <luc.vanoostenryck@gmail.com> (maintainer:SPARSE CHECKER)
> CC: Nathan Chancellor <nathan@kernel.org> (supporter:CLANG/LLVM BUILD SUPPORT)
> CC: Nick Desaulniers <ndesaulniers@google.com> (supporter:CLANG/LLVM BUILD SUPPORT)
> CC: Tom Rix <trix@redhat.com> (reviewer:CLANG/LLVM BUILD SUPPORT)
> CC: linux-sparse@vger.kernel.org (open list:SPARSE CHECKER)
> CC: linux-kernel@vger.kernel.org (open list)
> CC: llvm@lists.linux.dev (open list:CLANG/LLVM BUILD SUPPORT)
> Signed-off-by: Jim Cromie <jim.cromie@gmail.com>
> ---
>  include/linux/compiler.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/compiler.h b/include/linux/compiler.h
> index d7779a18b24f..677d6c47cd9e 100644
> --- a/include/linux/compiler.h
> +++ b/include/linux/compiler.h
> @@ -177,9 +177,9 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int val,
>  	__asm__ ("" : "=r" (var) : "0" (var))
>  #endif
>  
> -/* Not-quite-unique ID. */
> +/* JFTI: to fix Not-quite-unique ID */
>  #ifndef __UNIQUE_ID
> -# define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __LINE__)
> +# define __UNIQUE_ID(prefix) __PASTE(__PASTE(_kaUID_, prefix), __COUNTER__)
>  #endif
>  
>  /**
> -- 
> 2.41.0
> 

WARNING: multiple messages have this Message-ID (diff)
From: Nathan Chancellor <nathan@kernel.org>
To: Jim Cromie <jim.cromie@gmail.com>
Cc: Tom Rix <trix@redhat.com>,
	jani.nikula@intel.com, daniel.vetter@ffwll.ch,
	intel-gfx@lists.freedesktop.org, llvm@lists.linux.dev,
	Nick Desaulniers <ndesaulniers@google.com>,
	linux-kernel@vger.kernel.org, amd-gfx@lists.freedesktop.org,
	jbaron@akamai.com, linux-sparse@vger.kernel.org,
	seanpaul@chromium.org, dri-devel@lists.freedesktop.org,
	gregkh@linuxfoundation.org,
	Luc Van Oostenryck <luc.vanoostenryck@gmail.com>,
	intel-gvt-dev@lists.freedesktop.org
Subject: Re: [PATCH v4 18/21] compiler.h: RFC - s/__LINE__/__COUNTER__/ in __UNIQUE_ID fallback
Date: Thu, 13 Jul 2023 10:19:01 -0700	[thread overview]
Message-ID: <20230713171901.GA4036397@dev-arch.thelio-3990X> (raw)
In-Reply-To: <20230713163626.31338-19-jim.cromie@gmail.com>

Hi Jim

On Thu, Jul 13, 2023 at 10:36:23AM -0600, Jim Cromie wrote:
> We currently have 3 defns for __UNIQUE_ID(); gcc and clang are using
> __COUNTER__ for real uniqueness, 3rd just uses __LINE__, which should
> fail on this (and harder to avoid situations):
> 
>   DECLARE_FOO(); DECLARE_FOO();
> 
> Its 2023, can we haz a no-fallback __UNIQUE_ID ?

Yeah, I fail to see how this fallback definition can actually be used
after commit 95207db8166a ("Remove Intel compiler support"); even before
that, it would be pretty unlikely since icc usage has not been visible
for a long time. The kernel only officially supports clang or GCC now,
so the definitions of __UNIQUE_ID() in include/linux/compiler-clang.h
and include/linux/compiler-gcc.h should always be used because of the
include in include/linux/compiler_types.h, right?

I think the correct clean up is to just hoist the definition of
__UNIQUE_ID() out of the individual compiler headers into the common one
here but...

> NOTE:
> 
> This also changes __UNIQUE_ID_ to _kaUID_.  Ive been getting
> lkp-reports of collisions on names which should be unique; this
> shouldnt happen on gcc & clang, but does on some older ones, on some
> platforms, on some allyes & rand-configs.  Like this:
> 
> mips64-linux-ld:
> drivers/gpu/drm/display/drm_dp_helper.o:(__dyndbg_class_users+0x0):
> multiple definition of `__UNIQUE_ID_ddebug_class_user405';
> drivers/gpu/drm/drm_gem_shmem_helper.o:(__dyndbg_class_users+0x0):
> first defined here

This problem cannot be addressed with this patch given the above
information, no? Seems like that might mean that __COUNTER__ has issues
in earlier compilers?

Cheers,
Nathan

> Like above, the collision reports appear to always be 3-digit
> counters, which look like line-numbers.  Changing to _kaUID_ in this
> defn should make it more obvious (in *.i file) when a fallback has
> happened.  To be clear, I havent seen it yet.  Nor have I seen the
> multiple-defn problem above since adding this patch.
> 
> Lets see what lkp-robot says about this.
> 
> CC: Luc Van Oostenryck <luc.vanoostenryck@gmail.com> (maintainer:SPARSE CHECKER)
> CC: Nathan Chancellor <nathan@kernel.org> (supporter:CLANG/LLVM BUILD SUPPORT)
> CC: Nick Desaulniers <ndesaulniers@google.com> (supporter:CLANG/LLVM BUILD SUPPORT)
> CC: Tom Rix <trix@redhat.com> (reviewer:CLANG/LLVM BUILD SUPPORT)
> CC: linux-sparse@vger.kernel.org (open list:SPARSE CHECKER)
> CC: linux-kernel@vger.kernel.org (open list)
> CC: llvm@lists.linux.dev (open list:CLANG/LLVM BUILD SUPPORT)
> Signed-off-by: Jim Cromie <jim.cromie@gmail.com>
> ---
>  include/linux/compiler.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/compiler.h b/include/linux/compiler.h
> index d7779a18b24f..677d6c47cd9e 100644
> --- a/include/linux/compiler.h
> +++ b/include/linux/compiler.h
> @@ -177,9 +177,9 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int val,
>  	__asm__ ("" : "=r" (var) : "0" (var))
>  #endif
>  
> -/* Not-quite-unique ID. */
> +/* JFTI: to fix Not-quite-unique ID */
>  #ifndef __UNIQUE_ID
> -# define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __LINE__)
> +# define __UNIQUE_ID(prefix) __PASTE(__PASTE(_kaUID_, prefix), __COUNTER__)
>  #endif
>  
>  /**
> -- 
> 2.41.0
> 

WARNING: multiple messages have this Message-ID (diff)
From: Nathan Chancellor <nathan@kernel.org>
To: Jim Cromie <jim.cromie@gmail.com>
Cc: Tom Rix <trix@redhat.com>,
	jani.nikula@intel.com, daniel.vetter@ffwll.ch,
	intel-gfx@lists.freedesktop.org, llvm@lists.linux.dev,
	Nick Desaulniers <ndesaulniers@google.com>,
	linux-kernel@vger.kernel.org, amd-gfx@lists.freedesktop.org,
	jbaron@akamai.com, linux-sparse@vger.kernel.org,
	seanpaul@chromium.org, dri-devel@lists.freedesktop.org,
	gregkh@linuxfoundation.org,
	Luc Van Oostenryck <luc.vanoostenryck@gmail.com>,
	intel-gvt-dev@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH v4 18/21] compiler.h: RFC - s/__LINE__/__COUNTER__/ in __UNIQUE_ID fallback
Date: Thu, 13 Jul 2023 10:19:01 -0700	[thread overview]
Message-ID: <20230713171901.GA4036397@dev-arch.thelio-3990X> (raw)
In-Reply-To: <20230713163626.31338-19-jim.cromie@gmail.com>

Hi Jim

On Thu, Jul 13, 2023 at 10:36:23AM -0600, Jim Cromie wrote:
> We currently have 3 defns for __UNIQUE_ID(); gcc and clang are using
> __COUNTER__ for real uniqueness, 3rd just uses __LINE__, which should
> fail on this (and harder to avoid situations):
> 
>   DECLARE_FOO(); DECLARE_FOO();
> 
> Its 2023, can we haz a no-fallback __UNIQUE_ID ?

Yeah, I fail to see how this fallback definition can actually be used
after commit 95207db8166a ("Remove Intel compiler support"); even before
that, it would be pretty unlikely since icc usage has not been visible
for a long time. The kernel only officially supports clang or GCC now,
so the definitions of __UNIQUE_ID() in include/linux/compiler-clang.h
and include/linux/compiler-gcc.h should always be used because of the
include in include/linux/compiler_types.h, right?

I think the correct clean up is to just hoist the definition of
__UNIQUE_ID() out of the individual compiler headers into the common one
here but...

> NOTE:
> 
> This also changes __UNIQUE_ID_ to _kaUID_.  Ive been getting
> lkp-reports of collisions on names which should be unique; this
> shouldnt happen on gcc & clang, but does on some older ones, on some
> platforms, on some allyes & rand-configs.  Like this:
> 
> mips64-linux-ld:
> drivers/gpu/drm/display/drm_dp_helper.o:(__dyndbg_class_users+0x0):
> multiple definition of `__UNIQUE_ID_ddebug_class_user405';
> drivers/gpu/drm/drm_gem_shmem_helper.o:(__dyndbg_class_users+0x0):
> first defined here

This problem cannot be addressed with this patch given the above
information, no? Seems like that might mean that __COUNTER__ has issues
in earlier compilers?

Cheers,
Nathan

> Like above, the collision reports appear to always be 3-digit
> counters, which look like line-numbers.  Changing to _kaUID_ in this
> defn should make it more obvious (in *.i file) when a fallback has
> happened.  To be clear, I havent seen it yet.  Nor have I seen the
> multiple-defn problem above since adding this patch.
> 
> Lets see what lkp-robot says about this.
> 
> CC: Luc Van Oostenryck <luc.vanoostenryck@gmail.com> (maintainer:SPARSE CHECKER)
> CC: Nathan Chancellor <nathan@kernel.org> (supporter:CLANG/LLVM BUILD SUPPORT)
> CC: Nick Desaulniers <ndesaulniers@google.com> (supporter:CLANG/LLVM BUILD SUPPORT)
> CC: Tom Rix <trix@redhat.com> (reviewer:CLANG/LLVM BUILD SUPPORT)
> CC: linux-sparse@vger.kernel.org (open list:SPARSE CHECKER)
> CC: linux-kernel@vger.kernel.org (open list)
> CC: llvm@lists.linux.dev (open list:CLANG/LLVM BUILD SUPPORT)
> Signed-off-by: Jim Cromie <jim.cromie@gmail.com>
> ---
>  include/linux/compiler.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/compiler.h b/include/linux/compiler.h
> index d7779a18b24f..677d6c47cd9e 100644
> --- a/include/linux/compiler.h
> +++ b/include/linux/compiler.h
> @@ -177,9 +177,9 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int val,
>  	__asm__ ("" : "=r" (var) : "0" (var))
>  #endif
>  
> -/* Not-quite-unique ID. */
> +/* JFTI: to fix Not-quite-unique ID */
>  #ifndef __UNIQUE_ID
> -# define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __LINE__)
> +# define __UNIQUE_ID(prefix) __PASTE(__PASTE(_kaUID_, prefix), __COUNTER__)
>  #endif
>  
>  /**
> -- 
> 2.41.0
> 

WARNING: multiple messages have this Message-ID (diff)
From: Nathan Chancellor <nathan@kernel.org>
To: Jim Cromie <jim.cromie@gmail.com>
Cc: robdclark@gmail.com, Tom Rix <trix@redhat.com>,
	jani.nikula@intel.com, daniel.vetter@ffwll.ch,
	intel-gfx@lists.freedesktop.org, llvm@lists.linux.dev,
	Nick Desaulniers <ndesaulniers@google.com>,
	linux-kernel@vger.kernel.org, amd-gfx@lists.freedesktop.org,
	jbaron@akamai.com, linux-sparse@vger.kernel.org,
	seanpaul@chromium.org, dri-devel@lists.freedesktop.org,
	gregkh@linuxfoundation.org,
	Luc Van Oostenryck <luc.vanoostenryck@gmail.com>,
	intel-gvt-dev@lists.freedesktop.org,
	ville.syrjala@linux.intel.com
Subject: Re: [PATCH v4 18/21] compiler.h: RFC - s/__LINE__/__COUNTER__/ in __UNIQUE_ID fallback
Date: Thu, 13 Jul 2023 10:19:01 -0700	[thread overview]
Message-ID: <20230713171901.GA4036397@dev-arch.thelio-3990X> (raw)
In-Reply-To: <20230713163626.31338-19-jim.cromie@gmail.com>

Hi Jim

On Thu, Jul 13, 2023 at 10:36:23AM -0600, Jim Cromie wrote:
> We currently have 3 defns for __UNIQUE_ID(); gcc and clang are using
> __COUNTER__ for real uniqueness, 3rd just uses __LINE__, which should
> fail on this (and harder to avoid situations):
> 
>   DECLARE_FOO(); DECLARE_FOO();
> 
> Its 2023, can we haz a no-fallback __UNIQUE_ID ?

Yeah, I fail to see how this fallback definition can actually be used
after commit 95207db8166a ("Remove Intel compiler support"); even before
that, it would be pretty unlikely since icc usage has not been visible
for a long time. The kernel only officially supports clang or GCC now,
so the definitions of __UNIQUE_ID() in include/linux/compiler-clang.h
and include/linux/compiler-gcc.h should always be used because of the
include in include/linux/compiler_types.h, right?

I think the correct clean up is to just hoist the definition of
__UNIQUE_ID() out of the individual compiler headers into the common one
here but...

> NOTE:
> 
> This also changes __UNIQUE_ID_ to _kaUID_.  Ive been getting
> lkp-reports of collisions on names which should be unique; this
> shouldnt happen on gcc & clang, but does on some older ones, on some
> platforms, on some allyes & rand-configs.  Like this:
> 
> mips64-linux-ld:
> drivers/gpu/drm/display/drm_dp_helper.o:(__dyndbg_class_users+0x0):
> multiple definition of `__UNIQUE_ID_ddebug_class_user405';
> drivers/gpu/drm/drm_gem_shmem_helper.o:(__dyndbg_class_users+0x0):
> first defined here

This problem cannot be addressed with this patch given the above
information, no? Seems like that might mean that __COUNTER__ has issues
in earlier compilers?

Cheers,
Nathan

> Like above, the collision reports appear to always be 3-digit
> counters, which look like line-numbers.  Changing to _kaUID_ in this
> defn should make it more obvious (in *.i file) when a fallback has
> happened.  To be clear, I havent seen it yet.  Nor have I seen the
> multiple-defn problem above since adding this patch.
> 
> Lets see what lkp-robot says about this.
> 
> CC: Luc Van Oostenryck <luc.vanoostenryck@gmail.com> (maintainer:SPARSE CHECKER)
> CC: Nathan Chancellor <nathan@kernel.org> (supporter:CLANG/LLVM BUILD SUPPORT)
> CC: Nick Desaulniers <ndesaulniers@google.com> (supporter:CLANG/LLVM BUILD SUPPORT)
> CC: Tom Rix <trix@redhat.com> (reviewer:CLANG/LLVM BUILD SUPPORT)
> CC: linux-sparse@vger.kernel.org (open list:SPARSE CHECKER)
> CC: linux-kernel@vger.kernel.org (open list)
> CC: llvm@lists.linux.dev (open list:CLANG/LLVM BUILD SUPPORT)
> Signed-off-by: Jim Cromie <jim.cromie@gmail.com>
> ---
>  include/linux/compiler.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/compiler.h b/include/linux/compiler.h
> index d7779a18b24f..677d6c47cd9e 100644
> --- a/include/linux/compiler.h
> +++ b/include/linux/compiler.h
> @@ -177,9 +177,9 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int val,
>  	__asm__ ("" : "=r" (var) : "0" (var))
>  #endif
>  
> -/* Not-quite-unique ID. */
> +/* JFTI: to fix Not-quite-unique ID */
>  #ifndef __UNIQUE_ID
> -# define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __LINE__)
> +# define __UNIQUE_ID(prefix) __PASTE(__PASTE(_kaUID_, prefix), __COUNTER__)
>  #endif
>  
>  /**
> -- 
> 2.41.0
> 

  reply	other threads:[~2023-07-13 17:19 UTC|newest]

Thread overview: 110+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-13 16:36 [PATCH v4 00/21] fix DRM_USE_DYNAMIC_DEBUG regression Jim Cromie
2023-07-13 16:36 ` Jim Cromie
2023-07-13 16:36 ` Jim Cromie
2023-07-13 16:36 ` [Intel-gfx] " Jim Cromie
2023-07-13 16:36 ` [PATCH v4 01/21] drm: use correct ccflags-y syntax Jim Cromie
2023-07-13 16:36   ` Jim Cromie
2023-07-13 16:36   ` Jim Cromie
2023-07-13 16:36   ` [Intel-gfx] " Jim Cromie
2023-07-13 16:36 ` [PATCH v4 02/21] test-dyndbg: fixup CLASSMAP usage error Jim Cromie
2023-07-13 16:36   ` Jim Cromie
2023-07-13 16:36   ` Jim Cromie
2023-07-13 16:36   ` [Intel-gfx] " Jim Cromie
2023-07-13 16:36 ` [Intel-gfx] [PATCH v4 03/21] dyndbg: make ddebug_class_param union members same size Jim Cromie
2023-07-13 16:36   ` Jim Cromie
2023-07-13 16:36   ` Jim Cromie
2023-07-13 16:36   ` Jim Cromie
2023-07-13 16:36 ` [Intel-gfx] [PATCH v4 04/21] dyndbg: replace classmap list with a vector Jim Cromie
2023-07-13 16:36   ` Jim Cromie
2023-07-13 16:36   ` Jim Cromie
2023-07-13 16:36   ` Jim Cromie
2023-07-13 16:36 ` [PATCH v4 05/21] dyndbg: ddebug_apply_class_bitmap - add module arg, select on it Jim Cromie
2023-07-13 16:36   ` Jim Cromie
2023-07-13 16:36   ` [Intel-gfx] " Jim Cromie
2023-07-13 16:36   ` Jim Cromie
2023-07-13 16:36 ` [PATCH v4 06/21] dyndbg: split param_set_dyndbg_classes to module/wrapper fns Jim Cromie
2023-07-13 16:36   ` [Intel-gfx] " Jim Cromie
2023-07-13 16:36   ` Jim Cromie
2023-07-13 16:36   ` Jim Cromie
2023-07-13 16:36 ` [PATCH v4 07/21] dyndbg: drop NUM_TYPE_ARRAY Jim Cromie
2023-07-13 16:36   ` [Intel-gfx] " Jim Cromie
2023-07-13 16:36   ` Jim Cromie
2023-07-13 16:36   ` Jim Cromie
2023-07-13 16:36 ` [PATCH v4 08/21] dyndbg: reduce verbose/debug clutter Jim Cromie
2023-07-13 16:36   ` Jim Cromie
2023-07-13 16:36   ` [Intel-gfx] " Jim Cromie
2023-07-13 16:36   ` Jim Cromie
2023-07-13 16:36 ` [PATCH v4 09/21] dyndbg: silence debugs with no-change updates Jim Cromie
2023-07-13 16:36   ` Jim Cromie
2023-07-13 16:36   ` [Intel-gfx] " Jim Cromie
2023-07-13 16:36   ` Jim Cromie
2023-07-13 16:36 ` [PATCH v4 10/21] dyndbg: tighten ddebug_class_name() 1st arg type Jim Cromie
2023-07-13 16:36   ` Jim Cromie
2023-07-13 16:36   ` Jim Cromie
2023-07-13 16:36   ` [Intel-gfx] " Jim Cromie
2023-07-13 16:36 ` [PATCH v4 11/21] dyndbg: tighten fn-sig of ddebug_apply_class_bitmap Jim Cromie
2023-07-13 16:36   ` Jim Cromie
2023-07-13 16:36   ` Jim Cromie
2023-07-13 16:36   ` [Intel-gfx] " Jim Cromie
2023-07-13 16:36 ` [PATCH v4 12/21] dyndbg-API: remove DD_CLASS_TYPE_(DISJOINT|LEVEL)_NAMES and code Jim Cromie
2023-07-13 16:36   ` Jim Cromie
2023-07-13 16:36   ` Jim Cromie
2023-07-13 16:36   ` [Intel-gfx] " Jim Cromie
2023-07-13 16:36 ` [PATCH v4 13/21] dyndbg-API: fix DECLARE_DYNDBG_CLASSMAP & CONFIG_DRM_USE_DYNAMIC_DEBUG Jim Cromie
2023-07-13 16:36   ` Jim Cromie
2023-07-13 16:36   ` Jim Cromie
2023-07-13 16:36   ` [Intel-gfx] " Jim Cromie
2023-07-13 16:36 ` [PATCH v4 14/21] dyndbg: refactor ddebug_classparam_clamp_input Jim Cromie
2023-07-13 16:36   ` Jim Cromie
2023-07-13 16:36   ` Jim Cromie
2023-07-13 16:36   ` [Intel-gfx] " Jim Cromie
2023-07-13 16:36 ` [PATCH v4 15/21] dyndbg-API: promote DYNDBG_CLASSMAP_PARAM to API Jim Cromie
2023-07-13 16:36   ` Jim Cromie
2023-07-13 16:36   ` Jim Cromie
2023-07-13 16:36   ` [Intel-gfx] " Jim Cromie
2023-07-13 16:36 ` [PATCH v4 16/21] dyndbg-test: make it build with just CONFIG_DYNAMIC_DEBUG_CORE Jim Cromie
2023-07-13 16:36   ` Jim Cromie
2023-07-13 16:36   ` Jim Cromie
2023-07-13 16:36   ` [Intel-gfx] " Jim Cromie
2023-07-13 16:36 ` [PATCH v4 17/21] drm: restore CONFIG_DRM_USE_DYNAMIC_DEBUG un-BROKEN Jim Cromie
2023-07-13 16:36   ` Jim Cromie
2023-07-13 16:36   ` Jim Cromie
2023-07-13 16:36   ` [Intel-gfx] " Jim Cromie
2023-07-13 16:36 ` [PATCH v4 18/21] compiler.h: RFC - s/__LINE__/__COUNTER__/ in __UNIQUE_ID fallback Jim Cromie
2023-07-13 16:36   ` Jim Cromie
2023-07-13 16:36   ` [Intel-gfx] " Jim Cromie
2023-07-13 16:36   ` Jim Cromie
2023-07-13 17:19   ` Nathan Chancellor [this message]
2023-07-13 17:19     ` Nathan Chancellor
2023-07-13 17:19     ` [Intel-gfx] " Nathan Chancellor
2023-07-13 17:19     ` Nathan Chancellor
2023-07-13 16:36 ` [PATCH v4 19/21] drm-drivers: DRM_CLASSMAP_USE in 2nd batch of drivers, helpers Jim Cromie
2023-07-13 16:36   ` Jim Cromie
2023-07-13 16:36   ` Jim Cromie
2023-07-13 16:36   ` [Intel-gfx] " Jim Cromie
2023-07-13 16:36 ` [PATCH v4 20/21] config TEST_DYNAMIC_DEBUG default m Jim Cromie
2023-07-13 16:36   ` Jim Cromie
2023-07-13 16:36   ` Jim Cromie
2023-07-13 16:36   ` [Intel-gfx] " Jim Cromie
2023-07-13 19:04   ` Randy Dunlap
2023-07-13 19:04     ` Randy Dunlap
2023-07-13 19:04     ` Randy Dunlap
2023-07-13 19:04     ` [Intel-gfx] " Randy Dunlap
2023-07-14 17:26     ` jim.cromie
2023-07-14 17:26       ` jim.cromie
2023-07-14 17:26       ` [Intel-gfx] " jim.cromie
2023-07-14 17:26       ` jim.cromie
2023-07-13 16:36 ` [PATCH v4 21/21] dyndbg-doc: add classmap info to howto Jim Cromie
2023-07-13 16:36   ` Jim Cromie
2023-07-13 16:36   ` Jim Cromie
2023-07-13 16:36   ` [Intel-gfx] " Jim Cromie
2023-07-13 19:13   ` Randy Dunlap
2023-07-13 19:13     ` Randy Dunlap
2023-07-13 19:13     ` [Intel-gfx] " Randy Dunlap
2023-07-13 19:13     ` Randy Dunlap
2023-07-14 17:34     ` jim.cromie
2023-07-14 17:34       ` jim.cromie
2023-07-14 17:34       ` [Intel-gfx] " jim.cromie
2023-07-14 17:34       ` jim.cromie
2023-07-13 20:10 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for fix DRM_USE_DYNAMIC_DEBUG regression (rev2) Patchwork
2023-07-13 20:10 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork

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=20230713171901.GA4036397@dev-arch.thelio-3990X \
    --to=nathan@kernel.org \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-gvt-dev@lists.freedesktop.org \
    --cc=jani.nikula@intel.com \
    --cc=jbaron@akamai.com \
    --cc=jim.cromie@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sparse@vger.kernel.org \
    --cc=llvm@lists.linux.dev \
    --cc=luc.vanoostenryck@gmail.com \
    --cc=ndesaulniers@google.com \
    --cc=robdclark@gmail.com \
    --cc=seanpaul@chromium.org \
    --cc=trix@redhat.com \
    --cc=ville.syrjala@linux.intel.com \
    /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: link
Be 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.