From nobody Sun Feb 8 08:22:39 2026 Received: from mailtransmit04.runbox.com (mailtransmit04.runbox.com [185.226.149.37]) (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 AD2244DB561 for ; Wed, 21 Jan 2026 14:58:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.226.149.37 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769007501; cv=none; b=a5KpELkSRDmkCUccH3HSlo/T8dRxS8/3spa5x+voB4f0MjuBPk3i397uNJKogKOhdzE40Hc/xVWz+Hh8xYUMNU8bKI+Xn0fWXIB046RLt/D3xWqtTSyga2pCKA+x9/PwSvfqvkLyowWVgK2xufNsGQIaLg8jd4LDW5ZjT5eXGsg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769007501; c=relaxed/simple; bh=OuoX9rZ0eSyjPgtxw+7n9VkSoFoOdOkSZxjyKEbJrlc=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=aekE5H2x0If/l3ww41YOTcLUQg8zTojEDIs6aveYKunqhIzzWtPSZOeDxOa5NsQWZDAa1YH0QPRlFnoqJq+Oq4nJBkYuengw8jZmNW+ere82I+zLH7X0W2ThV6i+nKLcQn+dEfJ9iiCoRhwpL5LigTjOe2lRcAvAE589ogx2Le8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=runbox.com; dkim=pass (2048-bit key) header.d=runbox.com header.i=@runbox.com header.b=HNAKmRJA; arc=none smtp.client-ip=185.226.149.37 Authentication-Results: smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=runbox.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=runbox.com header.i=@runbox.com header.b="HNAKmRJA" Received: from mailtransmit02.runbox ([10.9.9.162] helo=aibo.runbox.com) by mailtransmit04.runbox.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1viZet-008XFR-Th; Wed, 21 Jan 2026 15:58:11 +0100 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=runbox.com; s=selector2; h=Content-Transfer-Encoding:MIME-Version:References:In-Reply-To :Message-Id:Date:Subject:Cc:To:From; bh=/ToXfeXh3OPuvD0iNKmVcu+YVeCSv/mDVOYNbMhE++U=; b=HNAKmRJAX0l0p8ILIbUcsRcn7m PHCbvFoW1SX91LbL+trQBUEQdshO58/rQ6TvPnLbUCz8mFhxEJPonSM0uj9gTeUWpcO43FIMsusj3 6YNSn6t1o2MwV7vQ4aEMOyMs9HB5PC7plzImRnYAmLB25+4qX6GVUzInGb+Ov/ep+SZO+CYFYFOUM qUnaLsCL6bCn0MWLtivbqF6QmfciRMkktsFFz+bzEo6HQBSTwn3jYGXRTBAmNswjE3rVtwhvOf50D txbqmIToXte4S5sQmitgsmZ5hzAZF68aPCzPvh7cjVdz5O/at3v8DSjAtLpoN5C9huqS/DMk0lr8i MTQfFeCw==; Received: from [10.9.9.72] (helo=submission01.runbox) by mailtransmit02.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1viZet-0001tU-Aq; Wed, 21 Jan 2026 15:58:11 +0100 Received: by submission01.runbox with esmtpsa [Authenticated ID (1493616)] (TLS1.2:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.93) id 1viZeZ-00GH6h-79; Wed, 21 Jan 2026 15:57:51 +0100 From: david.laight.linux@gmail.com To: Nathan Chancellor , Greg Kroah-Hartman , Thomas Gleixner , Peter Zijlstra , Ingo Molnar , Mathieu Desnoyers , Arnd Bergmann , linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, Yury Norov , Lucas De Marchi , Jani Nikula , Vincent Mailhol , Andy Shevchenko , Kees Cook , Andrew Morton Cc: David Laight Subject: [PATCH next 12/14] bits: move the defitions of BIT() and BIT_ULL() back to linux/bits.h Date: Wed, 21 Jan 2026 14:57:29 +0000 Message-Id: <20260121145731.3623-13-david.laight.linux@gmail.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20260121145731.3623-1-david.laight.linux@gmail.com> References: <20260121145731.3623-1-david.laight.linux@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: David Laight The definition of BIT() was moved from linux/bits.h to vdso/bits.h to isolate the vdso from 'normal' kernel headers. BIT_ULL() was then moved to be defined in the same place for consistency. Since then linux/bits.h had gained BIT_Unn() and it really makes sense for BIT() and BIT_ULL() to be defined in the same place. Move BIT_ULL() and make code that include both headers use the definition of BIT() from linux/bits.h Add BIT_U128() for completness. This lets BIT() pick up the extra compile time checks for W=3D[1c] builds that detect errors like: long foo(void) { int x =3D 64; return BIT(x); } For which clang (silently) just generates a 'return' instruction. Note that nothing the the x86-64 build relies on the definition in vdso/bits.h, linux/bits.h is always included. Signed-off-by: David Laight --- include/linux/bits.h | 7 ++++++- include/vdso/bits.h | 2 +- 2 files changed, 7 insertions(+), 2 deletions(-) diff --git a/include/linux/bits.h b/include/linux/bits.h index 0f559038981d..3dd32b9eef35 100644 --- a/include/linux/bits.h +++ b/include/linux/bits.h @@ -2,7 +2,6 @@ #ifndef __LINUX_BITS_H #define __LINUX_BITS_H =20 -#include #include =20 #define BIT_MASK(nr) (UL(1) << ((nr) % BITS_PER_LONG)) @@ -89,10 +88,16 @@ int BIT_INPUT_CHECK_FAIL(void) __compiletime_error("Bit= number out of range"); ((unsigned int)BIT_INPUT_CHECK(+(nr), BITS_PER_TYPE(type)) + ((type)1 << = (nr))) #endif /* defined(__ASSEMBLY__) */ =20 +/* Prefer this definition of BIT() to the one in vdso/bits.h */ +#undef BIT +#define __VDSO_BITS_H +#define BIT(nr) BIT_TYPE(unsigned long, nr) +#define BIT_ULL(nr) BIT_TYPE(unsigned long long, nr) #define BIT_U8(nr) BIT_TYPE(u8, nr) #define BIT_U16(nr) BIT_TYPE(u16, nr) #define BIT_U32(nr) BIT_TYPE(u32, nr) #define BIT_U64(nr) BIT_TYPE(u64, nr) +#define BIT_U128(nr) BIT_TYPE(u128, nr) =20 #if defined(__ASSEMBLY__) =20 diff --git a/include/vdso/bits.h b/include/vdso/bits.h index 388b212088ea..a6ac1e6b637c 100644 --- a/include/vdso/bits.h +++ b/include/vdso/bits.h @@ -4,7 +4,7 @@ =20 #include =20 +/* Most code picks up BIT() from linux/bits.h */ #define BIT(nr) (UL(1) << (nr)) -#define BIT_ULL(nr) (ULL(1) << (nr)) =20 #endif /* __VDSO_BITS_H */ --=20 2.39.5