From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.19]) (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 5C92D3F8EDA for ; Tue, 26 May 2026 13:56:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.19 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779803787; cv=none; b=PSJrtJ9HwEX+8QL9CUBrlvW6g+EUJ3srdRxCVUz7hUxKBa1EhMIodi9Gn9tFDOnCJQIH0C9Lk7wgEVZynROESocxT55nfRCT042jOt6VvlTpGDTelesX2MI6uFe3nNTuXTwWaoWOcJsvRcEdgL4OMUuqHESLBXY/0W3jSopf36U= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779803787; c=relaxed/simple; bh=2Ekqwm9mVpnB2bnyQisrcjZYlInf4jdq0wIB8D1lHwk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=kH/4Rr830odLsG1sCI7mrqRXG3rnMn5uRzJszSuuvQZcmheXqXpJ+/EFYmXQW30rXCHIyrI1fRl3Nbg6SRJWWEEXWmQqifmNiJHwbfzOJk3CPUBMKYoJDJjPrORhNkXXLhzjhMCqSG33E+pIytF6kF9ma4KJ6e0kZ1zkMgTwSnA= 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=LicYWkxB; arc=none smtp.client-ip=192.198.163.19 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="LicYWkxB" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1779803785; x=1811339785; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=2Ekqwm9mVpnB2bnyQisrcjZYlInf4jdq0wIB8D1lHwk=; b=LicYWkxBzeZ0x6P8YYiWyoeDIORh3KgZgpu0fGRL2lljoyFIde4aidcK T6T7hiPa1CQ1NWOtuidkBVxPdeE6teiRRWLOyq3eZJ2AOpQqc2pi2DI2g AWHw3N9aWSX7kWcJynTDc4gNzQdDSbLqya8/KRcxcrGk37fiPdnUHjZxO xjsrp5YU4OXGi7VzYhontB0P6BP+cwXc7xJzrUHmQbi71534XN3pU0QQf S5mHdVHMRWHLxy6JUql7Knttfb9h/86PiZyD1WMfB588p8F/IfBdX81jg HSSDqkNFXainP8rGlHSxdSRyyqzfKi7qDxOdv98Qx/Vjn/uRXkY21oyxi Q==; X-CSE-ConnectionGUID: 1y2D5JmRQDyHYJpbuAkHgg== X-CSE-MsgGUID: 7AasUdzGSPGG+ZyqoL7pgQ== X-IronPort-AV: E=McAfee;i="6800,10657,11797"; a="79650662" X-IronPort-AV: E=Sophos;i="6.24,169,1774335600"; d="scan'208";a="79650662" Received: from orviesa010.jf.intel.com ([10.64.159.150]) by fmvoesa113.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 May 2026 06:56:23 -0700 X-CSE-ConnectionGUID: /leugFaVRaCTur2SPn5wNg== X-CSE-MsgGUID: ssZRfAjSTYu9A6X5x0VHdw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.24,169,1774335600"; d="scan'208";a="241080157" Received: from egrumbac-mobl6.ger.corp.intel.com (HELO localhost) ([10.245.244.104]) by orviesa010-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 May 2026 06:56:17 -0700 From: Jani Nikula To: Nicolas Frattaroli , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , Andrzej Hajda , Neil Armstrong , Robert Foss , Laurent Pinchart , Jonas Karlman , Jernej Skrabec , Luca Ceresoli , Daniel Stone Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, kernel@collabora.com Subject: Re: [PATCH v3 4/4] drm/scdc-helper: Implement parsing and printing HDMI 2.1 fields In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - c/o Alberga Business Park, 6 krs Bertel Jungin Aukio 5, 02600 Espoo, Finland References: <20260526-scdc-link-health-v3-0-59e4a4aaead1@collabora.com> <20260526-scdc-link-health-v3-4-59e4a4aaead1@collabora.com> Date: Tue, 26 May 2026 16:56:14 +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 On Tue, 26 May 2026, Nicolas Frattaroli wrote: > On Tuesday, 26 May 2026 12:52:31 Central European Summer Time Jani Nikula wrote: >> On Tue, 26 May 2026, Nicolas Frattaroli wrote: >> > +static __pure const char *drm_scdc_frl_rate_str(enum drm_scdc_frl_rate rate) >> >> There are a total of only 71 __pure usages in the kernel. Is this >> helpful for a static function where the compiler can figure it out by >> itself? > > For the compiler, no. For the programmer, maybe. It's basically > documentation that foo(x) remains the same for a specific x, so > that having 3 calls with the same parameter in some scope is not > actually 3 separate function calls, but just retrieving a value > without manually saving it into a stack variable. A compiler can > infer that in this case, but a programmer that has their LSP show > them the function signature on hover will immediately know what's > going on without having to look at the implementation. > > I have a habit of slapping it onto any function that is pure just > because, but if you'd rather have me drop it then I can do that. > I'm aware that slapping attributes onto function signatures can > make them a bit noisy to read. I'm not dead set on this. But my observation, in general, is that setting an example is something to be done with care. People try to do the right thing, and cargo cult. And then you find out it's all over the place. So IMO the question is not so much, "is it a good thing here", but rather, "is this what we want for all pure functions". BR, Jani. -- Jani Nikula, Intel