[PATCH] drm/vmwgfx: Don't use UTS_RELEASE directly

[PATCH] drm/vmwgfx: Don't use UTS_RELEASE directly

[Uwe Kleine-König (The Capable Hub)]

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 vmwgfx_drv.o.

Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
---
Hello,

an alternative way to address this is to drop the kernel version string
completely. But I'm not sure how redundant this really is so I chose the
init_utsname() approach.

Best regards
Uwe

 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 0f101aedb49a..12f5f288ae15 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -24,7 +24,6 @@
 #include <drm/drm_sysfs.h>
 #include <drm/ttm/ttm_range_manager.h>
 #include <drm/ttm/ttm_placement.h>
-#include <generated/utsrelease.h>
 
 #ifdef CONFIG_X86
 #include <asm/hypervisor.h>
@@ -35,6 +34,7 @@
 #include <linux/dma-mapping.h>
 #include <linux/module.h>
 #include <linux/pci.h>
+#include <linux/utsname.h>
 #include <linux/version.h>
 #include <linux/vmalloc.h>
 
@@ -1115,7 +1115,7 @@ static int vmw_driver_load(struct vmw_private *dev_priv, u32 pci_id)
 	vmw_print_sm_type(dev_priv);
 	vmw_host_printf("vmwgfx: Module Version: %d.%d.%d (kernel: %s)",
 			VMWGFX_DRIVER_MAJOR, VMWGFX_DRIVER_MINOR,
-			VMWGFX_DRIVER_PATCHLEVEL, UTS_RELEASE);
+			VMWGFX_DRIVER_PATCHLEVEL, init_utsname()->release);
 	vmw_write_driver_id(dev_priv);
 
 	dev_priv->pm_nb.notifier_call = vmwgfx_pm_notifier;

base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
-- 
2.47.3

Re: [PATCH] drm/vmwgfx: Don't use UTS_RELEASE directly

[Uwe Kleine-König (The Capable Hub)]

[-- Attachment #1: Type: text/plain, Size: 941 bytes --]

Hello,

On Mon, May 04, 2026 at 09:34:20AM +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 vmwgfx_drv.o.
> 
> Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
> ---
> Hello,
> 
> an alternative way to address this is to drop the kernel version string
> completely. But I'm not sure how redundant this really is so I chose the
> init_utsname() approach.

any feedback on this patch? Ideally something like "I applied it for
7.2-rc1, thanks!" :-D

Best regards
Uwe

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH] drm/vmwgfx: Don't use UTS_RELEASE directly

[Maaz Mombasawala]

On 5/4/26 12:34 AM, 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 vmwgfx_drv.o.
> 
> Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
> ---
> Hello,
> 
> an alternative way to address this is to drop the kernel version string
> completely. But I'm not sure how redundant this really is so I chose the
> init_utsname() approach.
> 
> Best regards
> Uwe
> 
>  drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> index 0f101aedb49a..12f5f288ae15 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> @@ -24,7 +24,6 @@
>  #include <drm/drm_sysfs.h>
>  #include <drm/ttm/ttm_range_manager.h>
>  #include <drm/ttm/ttm_placement.h>
> -#include <generated/utsrelease.h>
>  
>  #ifdef CONFIG_X86
>  #include <asm/hypervisor.h>
> @@ -35,6 +34,7 @@
>  #include <linux/dma-mapping.h>
>  #include <linux/module.h>
>  #include <linux/pci.h>
> +#include <linux/utsname.h>
>  #include <linux/version.h>
>  #include <linux/vmalloc.h>
>  
> @@ -1115,7 +1115,7 @@ static int vmw_driver_load(struct vmw_private *dev_priv, u32 pci_id)
>  	vmw_print_sm_type(dev_priv);
>  	vmw_host_printf("vmwgfx: Module Version: %d.%d.%d (kernel: %s)",
>  			VMWGFX_DRIVER_MAJOR, VMWGFX_DRIVER_MINOR,
> -			VMWGFX_DRIVER_PATCHLEVEL, UTS_RELEASE);
> +			VMWGFX_DRIVER_PATCHLEVEL, init_utsname()->release);
>  	vmw_write_driver_id(dev_priv);
>  
>  	dev_priv->pm_nb.notifier_call = vmwgfx_pm_notifier;
> 
> base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731

LGTM!

Reviewed-by: Maaz Mombasawala <maaz.mombasawala@broadcom.com>

Sorry for missing this patch earlier. Unfortunately our maintainer Zack
is out for two weeks so we'll merge this patch at that time.

-- 
Maaz Mombasawala <maaz.mombasawala@broadcom.com>

Re: [PATCH] drm/vmwgfx: Don't use UTS_RELEASE directly

[Uwe Kleine-König (The Capable Hub)]

[-- Attachment #1: Type: text/plain, Size: 389 bytes --]

Hello Maaz,

On Wed, Jun 10, 2026 at 03:04:07PM -0700, Maaz Mombasawala wrote:
> Reviewed-by: Maaz Mombasawala <maaz.mombasawala@broadcom.com>
> 
> Sorry for missing this patch earlier. Unfortunately our maintainer Zack
> is out for two weeks so we'll merge this patch at that time.

You're saying I can expect this patch to land in next around end of
June?

Best regards
Uwe

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]