From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 162EAFF885E for ; Mon, 27 Apr 2026 12:26:19 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id A072710E718; Mon, 27 Apr 2026 12:26:18 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.b="MkFSIKvo"; dkim-atps=neutral Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.9]) by gabe.freedesktop.org (Postfix) with ESMTPS id A538B10E718 for ; Mon, 27 Apr 2026 12:26:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1777292778; x=1808828778; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=0FKt8RCiTt5a+evEzJOGiCMxem7WZCj6OYsv8jUTcHU=; b=MkFSIKvoVv0RdIs3Z7pQnRY8cidIlY9KX4lzqwNO4pnx1vd0ar57tmVK FI0/m2PTI8eDVOn1Bk9AeL2wwY0RYrxv+wHNLd27Sq4hfGeYsBe3KZt0D gQWWY1kDATbvh53vg4PFpBg7j3no7cDK6K/odkagJ6w7eTIYCoJItxxna 9XcE9dNqo3rkmE3KYWKcJ51/UKdU3p+iFBKQ1eSO4FxDwtsIay2dMKy/4 omFlSKtR6RUDLpIrwcUa5Ht4KX4cgTWj6YgGN2LljbFyEGWNtwIkX0vZa c0EZSnKVMCdJyDrQdcbiS56DuZ7R/MXC/9xzCmB/9FpTdSS4cEQLOML18 g==; X-CSE-ConnectionGUID: lYC0q+scSVOHkelztoqbxQ== X-CSE-MsgGUID: O88u/0FaQl2Um7T9QqM/Mg== X-IronPort-AV: E=McAfee;i="6800,10657,11768"; a="88871144" X-IronPort-AV: E=Sophos;i="6.23,202,1770624000"; d="scan'208";a="88871144" Received: from fmviesa001.fm.intel.com ([10.60.135.141]) by fmvoesa103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Apr 2026 05:26:17 -0700 X-CSE-ConnectionGUID: C2ty3r+nRMiaN9Qnni0Ldg== X-CSE-MsgGUID: Gzn2fBBNTNeyEbDqM0bNNQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.23,202,1770624000"; d="scan'208";a="257149086" Received: from fpallare-mobl4.ger.corp.intel.com (HELO localhost) ([10.245.244.53]) by smtpauth.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Apr 2026 05:26:15 -0700 From: Jani Nikula To: Sebastian Brzezinka , intel-gfx@lists.freedesktop.org Cc: Sebastian Brzezinka , andi.shyti@linux.intel.com, krzysztof.karas@intel.com Subject: Re: [PATCH] drm/i915: replace fetch_and_zero() with kernel xchg() In-Reply-To: <75ba7e77fe28617f027ae49a620df8b580cd1000.1777291964.git.sebastian.brzezinka@intel.com> Organization: Intel Finland Oy - BIC 0357606-4 - c/o Alberga Business Park, 6 krs Bertel Jungin Aukio 5, 02600 Espoo, Finland References: <75ba7e77fe28617f027ae49a620df8b580cd1000.1777291964.git.sebastian.brzezinka@intel.com> Date: Mon, 27 Apr 2026 15:26:13 +0300 Message-ID: <7d18b591154516efd9be14c643bd576678b616bc@intel.com> MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Mon, 27 Apr 2026, Sebastian Brzezinka wrote: > The i915 local fetch_and_zero() macro is a non-atomic > fetch-and-zero operation defined in i915_utils.h and duplicated in > display/intel_display_utils.h. Its functionality is equivalent to the > kernel-provided xchg(). While I dislike having the local fetch_and_zero() macro around, the usage does not need to be atomic, and there's no need to switch to the atomic xchg() at all. Using atomic xchg() gives the wrong impression to the reader that the atomicity matters when it doesn't. So that's a no for this patch. There's been a few attempts at fixing this in the past, one I found was [1]. [1] https://lore.kernel.org/r/20221209154843.4162814-1-andrzej.hajda@intel.com > Replace fetch_and_zero() with the kernel provided xchg(), and > remove the now unused macro definitions from both i915_utils.h and > display/intel_display_utils.h. > > Reviewed-by: Krzysztof Karas Where did this happen? Was there a v1? Is this v2? BR, Jani. -- Jani Nikula, Intel