drivers/gpu/drm/amd/amdgpu/amdgpu_dev_coredump.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
UTS_RELEASE evaluates to a static string and changes quite easily (e.g.
uncommitted changes in the source tree or new commits). So when checking
if a patch introduces changes to the resulting binary each usage of
UTS_RELEASE is source of annoyance.
Instead of using UTS_RELEASE directly use init_utsname()->release which
evaluates to the same string but with that a change of UTS_RELEASE
doesn't affect amdgpu_dev_coredump.o.
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_dev_coredump.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dev_coredump.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_dev_coredump.c
index d386bc775d03..20ae2bd4617a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dev_coredump.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dev_coredump.c
@@ -22,8 +22,8 @@
*
*/
-#include <generated/utsrelease.h>
#include <linux/devcoredump.h>
+#include <linux/utsname.h>
#include "amdgpu_dev_coredump.h"
#include "atom.h"
@@ -236,7 +236,7 @@ amdgpu_devcoredump_format(char *buffer, size_t count, struct amdgpu_coredump_inf
drm_printf(&p, "**** AMDGPU Device Coredump ****\n");
drm_printf(&p, "version: " AMDGPU_COREDUMP_VERSION "\n");
- drm_printf(&p, "kernel: " UTS_RELEASE "\n");
+ drm_printf(&p, "kernel: %s\n", init_utsname()->release);
drm_printf(&p, "module: " KBUILD_MODNAME "\n");
drm_printf(&p, "time: %ptSp\n", &coredump->reset_time);
base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
--
2.47.3
Hello, On Tue, Apr 28, 2026 at 04:47:03PM +0200, Uwe Kleine-König (The Capable Hub) wrote: > UTS_RELEASE evaluates to a static string and changes quite easily (e.g. > uncommitted changes in the source tree or new commits). So when checking > if a patch introduces changes to the resulting binary each usage of > UTS_RELEASE is source of annoyance. > > Instead of using UTS_RELEASE directly use init_utsname()->release which > evaluates to the same string but with that a change of UTS_RELEASE > doesn't affect amdgpu_dev_coredump.o. > > Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> Is this patch still on someone's radar? Best regards Uwe
On 6/9/26 10:32, Uwe Kleine-König (The Capable Hub) wrote: > Hello, > > On Tue, Apr 28, 2026 at 04:47:03PM +0200, Uwe Kleine-König (The Capable Hub) wrote: >> UTS_RELEASE evaluates to a static string and changes quite easily (e.g. >> uncommitted changes in the source tree or new commits). So when checking >> if a patch introduces changes to the resulting binary each usage of >> UTS_RELEASE is source of annoyance. >> >> Instead of using UTS_RELEASE directly use init_utsname()->release which >> evaluates to the same string but with that a change of UTS_RELEASE >> doesn't affect amdgpu_dev_coredump.o. >> >> Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> > > Is this patch still on someone's radar? > > Best regards > Uwe Sorry it looks like it got missed. Thanks for pinging. I'll pick it up.
© 2016 - 2026 Red Hat, Inc.