From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f46.google.com (mail-qv1-f46.google.com [209.85.219.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4416B2BEC52 for ; Fri, 17 Oct 2025 16:37:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.46 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1760719035; cv=none; b=caqecDaa3Y98jQ5pnA1DBJbOBi1955F2PUaFmsmq7N4dyrKeXloyMYILbspUedn2jLxUgAFBeBDOgy7Dv2U3PiQlKD3I/WV4LLKxaQsbIw2o45Oh+ywKk+kzdhKVUwjN68/MsA5uILKBO1YGEsILT89JExI7ie3uhgje7ZUbgns= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1760719035; c=relaxed/simple; bh=K5dh/21yz367t5636zz5BS+SRG5wCokC8YohqZIkQhQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Y53yz5ejN7gPoZ2w0JOCiBLwpJXZwktPj4bG83qDAPpkXCUM6EWrKRru49ZvtMn2IZ0GRcOqyuH+xowLJ7Bwd6ayFTr92JS+MRwdw+mUwDAZ3MrWccpPQOL3cYbYO1Z38gOu3fADkKdB3UxMmpmzoyXFX0BHhLTnF2CuNvt3mQ4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=gBrR57zW; arc=none smtp.client-ip=209.85.219.46 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="gBrR57zW" Received: by mail-qv1-f46.google.com with SMTP id 6a1803df08f44-78ea15d3489so25435876d6.3 for ; Fri, 17 Oct 2025 09:37:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1760719032; x=1761323832; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=lZqTIsgME323ZkO31yyQWUQxJPAMGciP0ot1SYinmXM=; b=gBrR57zWpXm2w/7blqiasX6rmV7vMOXlvxZj17ty4WRF2XnRnvCdJtbZv+TCRnKfEx dJRlYjhECXVkQ9Q1HIXqpT24ZGQzQyQsiU9ADp3KCRFJ3G7mv1AiaubTgOpTRR3QJiZ3 nL5TZx6sR9W1Vxti398bZwYcjYqIqFXg7IwscFtEsLL6pqzhaQpJbypNsFnFKem58Lnt vDxezsCzssRFdXkEHo2TWlwIp5pluD9Qrl4KdwvuiuR/eE1k/nRL5SkfuLiqgxJrKVTe CXGLcSwa1vOVG6qTZzmTOJQt6xSCdBQTV/aXP+AmQChG2FjRoFtd4Y80fXd9rDh0uUM7 a6Ew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1760719032; x=1761323832; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=lZqTIsgME323ZkO31yyQWUQxJPAMGciP0ot1SYinmXM=; b=lXRvVsVnGHM5mYmkQy49gqKLKzYyEKhNwoXQHR6ooX8kUxXKsSHabsy0wVOnaJS1/R yo+5PPNWTNyryeKEhOEQMy4RbqHfEgxgNokZ8OVrYIuIAm6VtIma6yVWO0ynUSywi+y9 /RVsMcvnLbGJVeV2w3tXlpEv/+i5UponQxXiTIJhSe6XVsZ8ZYtwAHFX0awhNSNmpa69 hhi/61LxV1VINYdCP5u82l4uvsZm1/knTTVijovqKMmFHl1+KyZjnvZm2KnyypsI17x8 2WR39hi9RoLSUCiRG+ir5k0KUHIfibc9IdmyWXdUMx6ANy1ZjsW9OInODKESAgf4Z/DL 9Xfw== X-Forwarded-Encrypted: i=1; AJvYcCWzlOQgWomnnNd4HDhFMefcM9npE52ZgY5ULCaA6FVKih4XHVUYx+Kfo6k2P3Vrner/8VV5e2CzOZ8=@vger.kernel.org X-Gm-Message-State: AOJu0YxB2ZJLjJ+Vc1eodd0wuRzp3kmF4Z5omf1CcJWV26Wvli14w2O7 B31h5S2pL4v54ZzEqLfe6lY1UfOXuMZlWY/NH3QRIVuyEzRGPFWCCQbh X-Gm-Gg: ASbGnctSJ2z6i2gY6PMeubylKCFGzV0xcby0uIMhr5c1DxMLh3PFXXL/ANanjVLrIcB gjQy//gP8gP4lzkAoSJU8QosLQV8o0JGdQoVsAxBiRJpiiy8oCRl3JeFXcKSGnMv59fLZNna46C FF9zm1a7uUODHkfR3HzuGF8hzHtn/4HSMhhwoEFhWL/txYj+ygjuQ/CWOWOihRHtMxTt85Gp6Fz roSdAed/FncbAeAoDlmggpCljrVU+w8J+HNJpDF9wMwYAobjLZkUGNbmJotgZw7xxU+FfZ2Ory1 asoOPFEwYfXYwt4Cih0+TZoZ5iRfcciIL0GfISrxsoyLBxswrbcwcT1mQCWX+kx09dR6sLwlw/P Dd+5lWlk39HXfqmVMYVLg+M0KE/3bLLaWtrLFp7Nm/PheozuZQAFcDFzSfgxsdj2gr/EUp4DIzM 2YAEV1j0U= X-Google-Smtp-Source: AGHT+IEBLNSjsT2f6SbTw5aTPGakjHLdlQrL5hue+DxfPG8mzc3zrpMssrggDkT+31HrLygOdkrpIg== X-Received: by 2002:ad4:594b:0:b0:87c:2920:5730 with SMTP id 6a1803df08f44-87c29205b08mr24398926d6.40.1760719031704; Fri, 17 Oct 2025 09:37:11 -0700 (PDT) Received: from localhost ([12.22.141.131]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-87d02d91324sm1575686d6.65.2025.10.17.09.37.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 17 Oct 2025 09:37:11 -0700 (PDT) Date: Fri, 17 Oct 2025 12:37:09 -0400 From: Yury Norov To: Geert Uytterhoeven Cc: Michael Turquette , Stephen Boyd , Nicolas Ferre , Alexandre Belloni , Claudiu Beznea , Giovanni Cabiddu , Herbert Xu , David Miller , Linus Walleij , Bartosz Golaszewski , Joel Stanley , Andrew Jeffery , Crt Mori , Jonathan Cameron , Lars-Peter Clausen , Jacky Huang , Shan-Chun Hung , Rasmus Villemoes , Jaroslav Kysela , Takashi Iwai , Johannes Berg , Jakub Kicinski , Alex Elder , David Laight , Vincent Mailhol , Jason Baron , Borislav Petkov , Tony Luck , Michael Hennerich , Kim Seer Paller , David Lechner , Nuno =?iso-8859-1?Q?S=E1?= , Andy Shevchenko , Richard Genoud , Cosmin Tanislav , Biju Das , Jianping Shen , linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-renesas-soc@vger.kernel.org, linux-crypto@vger.kernel.org, linux-edac@vger.kernel.org, qat-linux@intel.com, linux-gpio@vger.kernel.org, linux-aspeed@lists.ozlabs.org, linux-iio@vger.kernel.org, linux-sound@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v4 1/4] bitfield: Drop underscores from macro parameters Message-ID: References: <792d176149bc4ffde2a7b78062388dc2466c23ca.1760696560.git.geert+renesas@glider.be> Precedence: bulk X-Mailing-List: linux-clk@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <792d176149bc4ffde2a7b78062388dc2466c23ca.1760696560.git.geert+renesas@glider.be> On Fri, Oct 17, 2025 at 12:54:09PM +0200, Geert Uytterhoeven wrote: > There is no need to prefix macro parameters with underscores. > Remove the underscores. > > Suggested-by: David Laight > Signed-off-by: Geert Uytterhoeven > --- > v4: > - Update recently introduced FIELD_MODIFY() macro, > > v3: > - New. > --- > include/linux/bitfield.h | 106 +++++++++++++++++++-------------------- > 1 file changed, 53 insertions(+), 53 deletions(-) > > diff --git a/include/linux/bitfield.h b/include/linux/bitfield.h > index 5355f8f806a97974..7ff817bdae19b468 100644 > --- a/include/linux/bitfield.h > +++ b/include/linux/bitfield.h > @@ -60,68 +60,68 @@ > > #define __bf_cast_unsigned(type, x) ((__unsigned_scalar_typeof(type))(x)) > > -#define __BF_FIELD_CHECK(_mask, _reg, _val, _pfx) \ > +#define __BF_FIELD_CHECK(mask, reg, val, pfx) \ > ({ \ > - BUILD_BUG_ON_MSG(!__builtin_constant_p(_mask), \ > - _pfx "mask is not constant"); \ > - BUILD_BUG_ON_MSG((_mask) == 0, _pfx "mask is zero"); \ > - BUILD_BUG_ON_MSG(__builtin_constant_p(_val) ? \ > - ~((_mask) >> __bf_shf(_mask)) & \ > - (0 + (_val)) : 0, \ > - _pfx "value too large for the field"); \ > - BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) > \ > - __bf_cast_unsigned(_reg, ~0ull), \ > - _pfx "type of reg too small for mask"); \ > - __BUILD_BUG_ON_NOT_POWER_OF_2((_mask) + \ > - (1ULL << __bf_shf(_mask))); \ > + BUILD_BUG_ON_MSG(!__builtin_constant_p(mask), \ > + pfx "mask is not constant"); \ > + BUILD_BUG_ON_MSG((mask) == 0, pfx "mask is zero"); \ > + BUILD_BUG_ON_MSG(__builtin_constant_p(val) ? \ > + ~((mask) >> __bf_shf(mask)) & \ > + (0 + (val)) : 0, \ > + pfx "value too large for the field"); \ > + BUILD_BUG_ON_MSG(__bf_cast_unsigned(mask, mask) > \ > + __bf_cast_unsigned(reg, ~0ull), \ > + pfx "type of reg too small for mask"); \ > + __BUILD_BUG_ON_NOT_POWER_OF_2((mask) + \ > + (1ULL << __bf_shf(mask))); \ > }) Hi Geert, Thanks for the series! I agree that underscored parameters are excessive. But fixing them has a side effect of wiping the history, which is a bad thing. I would prefer to save a history over following a rule that seemingly is not written down. Let's keep this untouched for now, and if there will be a need to move the code, we can drop underscores as well. Meanwhile you (and David) can propose a corresponding rule in coding-style.rst and a checkpatch warning. That way we at least will stop merging a new code of that style. Thanks, Yury