All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jim Cromie <jim.cromie@gmail.com>
To: 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
Cc: jani.nikula@intel.com, ville.syrjala@linux.intel.com,
	seanpaul@chromium.org, robdclark@gmail.com,
	gregkh@linuxfoundation.org, Jim Cromie <jim.cromie@gmail.com>,
	Luc Van Oostenryck <luc.vanoostenryck@gmail.com>,
	Nathan Chancellor <nathan@kernel.org>,
	Nick Desaulniers <ndesaulniers@google.com>,
	Tom Rix <trix@redhat.com>,
	linux-sparse@vger.kernel.org, llvm@lists.linux.dev
Subject: [PATCH v4 18/21] compiler.h: RFC - s/__LINE__/__COUNTER__/ in __UNIQUE_ID fallback
Date: Thu, 13 Jul 2023 10:36:23 -0600	[thread overview]
Message-ID: <20230713163626.31338-19-jim.cromie@gmail.com> (raw)
In-Reply-To: <20230713163626.31338-1-jim.cromie@gmail.com>

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 ?

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

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: Jim Cromie <jim.cromie@gmail.com>
To: 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
Cc: jani.nikula@intel.com, gregkh@linuxfoundation.org,
	llvm@lists.linux.dev, Nick Desaulniers <ndesaulniers@google.com>,
	linux-sparse@vger.kernel.org,
	Nathan Chancellor <nathan@kernel.org>,
	seanpaul@chromium.org,
	Luc Van Oostenryck <luc.vanoostenryck@gmail.com>,
	Tom Rix <trix@redhat.com>
Subject: [PATCH v4 18/21] compiler.h: RFC - s/__LINE__/__COUNTER__/ in __UNIQUE_ID fallback
Date: Thu, 13 Jul 2023 10:36:23 -0600	[thread overview]
Message-ID: <20230713163626.31338-19-jim.cromie@gmail.com> (raw)
In-Reply-To: <20230713163626.31338-1-jim.cromie@gmail.com>

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 ?

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

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: Jim Cromie <jim.cromie@gmail.com>
To: 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
Cc: jani.nikula@intel.com, gregkh@linuxfoundation.org,
	llvm@lists.linux.dev, Nick Desaulniers <ndesaulniers@google.com>,
	linux-sparse@vger.kernel.org,
	Nathan Chancellor <nathan@kernel.org>,
	Jim Cromie <jim.cromie@gmail.com>,
	seanpaul@chromium.org,
	Luc Van Oostenryck <luc.vanoostenryck@gmail.com>,
	Tom Rix <trix@redhat.com>
Subject: [Intel-gfx] [PATCH v4 18/21] compiler.h: RFC - s/__LINE__/__COUNTER__/ in __UNIQUE_ID fallback
Date: Thu, 13 Jul 2023 10:36:23 -0600	[thread overview]
Message-ID: <20230713163626.31338-19-jim.cromie@gmail.com> (raw)
In-Reply-To: <20230713163626.31338-1-jim.cromie@gmail.com>

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 ?

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

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: Jim Cromie <jim.cromie@gmail.com>
To: 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
Cc: jani.nikula@intel.com, gregkh@linuxfoundation.org,
	llvm@lists.linux.dev, Nick Desaulniers <ndesaulniers@google.com>,
	linux-sparse@vger.kernel.org,
	Nathan Chancellor <nathan@kernel.org>,
	Jim Cromie <jim.cromie@gmail.com>,
	robdclark@gmail.com, seanpaul@chromium.org,
	Luc Van Oostenryck <luc.vanoostenryck@gmail.com>,
	Tom Rix <trix@redhat.com>,
	ville.syrjala@linux.intel.com
Subject: [PATCH v4 18/21] compiler.h: RFC - s/__LINE__/__COUNTER__/ in __UNIQUE_ID fallback
Date: Thu, 13 Jul 2023 10:36:23 -0600	[thread overview]
Message-ID: <20230713163626.31338-19-jim.cromie@gmail.com> (raw)
In-Reply-To: <20230713163626.31338-1-jim.cromie@gmail.com>

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 ?

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

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


  parent reply	other threads:[~2023-07-13 16:37 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 ` Jim Cromie [this message]
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   ` [Intel-gfx] " Jim Cromie
2023-07-13 16:36   ` Jim Cromie
2023-07-13 17:19   ` Nathan Chancellor
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=20230713163626.31338-19-jim.cromie@gmail.com \
    --to=jim.cromie@gmail.com \
    --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=linux-kernel@vger.kernel.org \
    --cc=linux-sparse@vger.kernel.org \
    --cc=llvm@lists.linux.dev \
    --cc=luc.vanoostenryck@gmail.com \
    --cc=nathan@kernel.org \
    --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.