From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1DF7438A701 for ; Tue, 28 Apr 2026 11:09:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.11 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777374578; cv=none; b=c7G5dF5EmvZzlr/gZYzjLlENWPKFR1liX/tdKC2JdN2uSfeEQOuosPFJSrgCfH0BIzByepHgdCYM6Ern7HboXUqKqVBXbd3mfHYjRj3NFaRmSAZ1B1uckrcfnr4nnkSJ5bwrsaHfSWvyTbb02HHHDSIby8fT3gpQPclhJA8tO9U= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777374578; c=relaxed/simple; bh=ay2Te7p98W7UWUNyjbMMPjBv35QX/kzz4x6ZOlnWI4w=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=XHoUo44sAhQy1VcMulsFXD/00wdw6dBDSqGy4D9P3xJSjtcE9uvAuG3hhhWIgzMunxZ4ahts9qzJNV7D7ctB+xSg9yZ7DgZACv6QZ8ggSwHX30yVQ8bIPcjURkbSaqZ2kd1xSBCptuOhigEEPB9p++JurYLx9gidnXKnA2UO/xA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=kg9dypeb; arc=none smtp.client-ip=198.175.65.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="kg9dypeb" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1777374577; x=1808910577; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version:content-transfer-encoding; bh=ay2Te7p98W7UWUNyjbMMPjBv35QX/kzz4x6ZOlnWI4w=; b=kg9dypebTOyvOSQEz1SO68H68FKAM8z3JUisZ5QvTsMj+UNIe1WgmNue NdYHciVScfNyffQa74LqR/ZYVOKFLw1qCIdFyddzuL8PEviGvJVZSizyL xm+3JGgHK6R3+ZiP//O8hoWrM4a8LeDNqf5wpRxQRXzYNxxkG+fuLLfXK JNAWWkg3eSvlT3hgCFZDC8aT1pNInQRovUubV53lwnjV4mKL6X0s/8Z/G YbvSlrutSVnqiY7JzNLeg8K1Q08qxMXABMSfIki/7uecJDBMfBgZ80io7 OHkhb6COmAgqC7yC61Sppm8WdyeVwQLuc37z+Mc6m1pqk1I8eY694Vk7N A==; X-CSE-ConnectionGUID: SPeITdF0R4S6si87NIvKpQ== X-CSE-MsgGUID: wC7JZOECRJ2FOZ3YDIunxQ== X-IronPort-AV: E=McAfee;i="6800,10657,11769"; a="88589728" X-IronPort-AV: E=Sophos;i="6.23,204,1770624000"; d="scan'208";a="88589728" Received: from fmviesa006.fm.intel.com ([10.60.135.146]) by orvoesa103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Apr 2026 04:09:36 -0700 X-CSE-ConnectionGUID: LD4maPvmRnS0+qHIb+3GGw== X-CSE-MsgGUID: EcKwJ/HIS2eJtbt13SgYdw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.23,204,1770624000"; d="scan'208";a="229358230" Received: from ettammin-mobl2.ger.corp.intel.com (HELO localhost) ([10.245.244.208]) by fmviesa006-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Apr 2026 04:09:33 -0700 From: Jani Nikula To: =?utf-8?Q?Uwe_Kleine-K=C3=B6nig_=28The_Capable_Hub=29?= , Matthew Brost , Thomas =?utf-8?Q?Hellstr=C3=B6m?= , Rodrigo Vivi Cc: David Airlie , Simona Vetter , intel-xe@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] drm/xe: Don't use UTS_RELEASE directly In-Reply-To: <20260428102527.189593-2-u.kleine-koenig@baylibre.com> Organization: Intel Finland Oy - BIC 0357606-4 - c/o Alberga Business Park, 6 krs Bertel Jungin Aukio 5, 02600 Espoo, Finland References: <20260428102527.189593-2-u.kleine-koenig@baylibre.com> Date: Tue, 28 Apr 2026 14:09:31 +0300 Message-ID: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Tue, 28 Apr 2026, Uwe Kleine-K=C3=B6nig (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 xe_devcoredump.o. > > Signed-off-by: Uwe Kleine-K=C3=B6nig (The Capable Hub) Reviewed-by: Jani Nikula > --- > Hello, > > (implicit) v1 of this patch is available at=20 > https://lore.kernel.org/20260427160902.1126027-2-u.kleine-koenig%40baylib= re.com. > > The only changes since then is that instead of dropping the kernel line, > init_utsname()->release is used, which is nearly what Jani Nikula > suggested. Almost the same, but better. ;) I wonder if most UTS_RELEASE uses in the kernel should be changed the same way? BR, Jani. > > Best regards > Uwe > > drivers/gpu/drm/xe/xe_devcoredump.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/xe/xe_devcoredump.c b/drivers/gpu/drm/xe/xe_= devcoredump.c > index 558a1a9841a0..07c7c89240d8 100644 > --- a/drivers/gpu/drm/xe/xe_devcoredump.c > +++ b/drivers/gpu/drm/xe/xe_devcoredump.c > @@ -8,7 +8,7 @@ >=20=20 > #include > #include > -#include > +#include >=20=20 > #include >=20=20 > @@ -101,7 +101,7 @@ static ssize_t __xe_devcoredump_read(char *buffer, ss= ize_t count, >=20=20 > drm_puts(&p, "**** Xe Device Coredump ****\n"); > drm_printf(&p, "Reason: %s\n", ss->reason); > - drm_puts(&p, "kernel: " UTS_RELEASE "\n"); > + drm_printf(&p, "kernel: %s\n", init_utsname()->release); > drm_puts(&p, "module: " KBUILD_MODNAME "\n"); >=20=20 > ts =3D ktime_to_timespec64(ss->snapshot_time); > > base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731 --=20 Jani Nikula, Intel