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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 24537EED617 for ; Thu, 12 Sep 2024 16:45:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5FFD16B0088; Thu, 12 Sep 2024 12:45:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5AFA46B008C; Thu, 12 Sep 2024 12:45:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 49DD46B0092; Thu, 12 Sep 2024 12:45:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 2CD016B0088 for ; Thu, 12 Sep 2024 12:45:53 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id CDC9FA0DFA for ; Thu, 12 Sep 2024 16:45:52 +0000 (UTC) X-FDA: 82556662944.15.6AD1BCA Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf22.hostedemail.com (Postfix) with ESMTP id 43405C0008 for ; Thu, 12 Sep 2024 16:45:51 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none); spf=pass (imf22.hostedemail.com: domain of cmarinas@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=cmarinas@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1726159522; a=rsa-sha256; cv=none; b=OmDilN3fUefi4GqFoUASvZwG4oEgA4C+/JQ32DPU+qyRE9m64SlqWAwM4gMBR7m7ojrXRR R+EOR35GHIvsn6VobqqMGBE6/cyTeo9RAbSraaSi3rTyuPY7QV7xm6GKaalWggZfGusb3a dusSTmx276SZa8C1AQzKX/El1TSZwFA= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none); spf=pass (imf22.hostedemail.com: domain of cmarinas@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=cmarinas@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1726159522; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=0kEV0Ve7mtIlsAq5pc8sTk15tgCKmadZdKhf3dRxllc=; b=a/OUjlqv2CB7z4RD8fU7O9blU57M8uj7dvTJ+YyiX+3gsHDWAGhfCIClhKe9Jg/C2ZGZhC axi6yT/prJrcf85JtBohlQv56ftr5HVIpgKOoeyks36n+dJe15yyVATjvN/rn5JeNVAVjl i+zrECKW0G6buz8qrLgRk23S6f1xuHw= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id DBA29A43DAE; Thu, 12 Sep 2024 16:45:42 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9C998C4CEC3; Thu, 12 Sep 2024 16:45:47 +0000 (UTC) Date: Thu, 12 Sep 2024 17:45:45 +0100 From: Catalin Marinas To: Mark Brown Cc: Alexander Viro , Christian Brauner , Jan Kara , Eric Biederman , Kees Cook , Will Deacon , Jonathan Corbet , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Yury Khrustalev , Wilco Dijkstra , linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org Subject: Re: [PATCH RFC 0/2] arm64: Add infrastructure for use of AT_HWCAP3 Message-ID: References: <20240906-arm64-elf-hwcap3-v1-0-8df1a5e63508@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240906-arm64-elf-hwcap3-v1-0-8df1a5e63508@kernel.org> X-Rspam-User: X-Rspamd-Queue-Id: 43405C0008 X-Rspamd-Server: rspam01 X-Stat-Signature: wmmoabtudes6ojorhie8sygn7rwxj5dg X-HE-Tag: 1726159551-284638 X-HE-Meta: U2FsdGVkX19gQ5Lsg86/s7Rg1nB8SOFJ57BOEW2YFVO4YtFcS6cwzManqSoH1q6Ykacxp9FR3EzXbN8jlf38+Z3U0HeQovnw1zmt96MqcqGtCVC1yjLoSvxOB35zYwya3+etSWW20hNW5JOh/LFYbdlDTN8FOc52O7Rbv/OU3Kb9frUW/ugB/dZ5SrcTVrQ/ey/8QkQ7S8tf0c4PUSKrsUrMFaZtK9SvBuVCiY7tDTQhTiN3bJqdfZHFJjsdqLLpBpArxcw+ds1krWL1riTx05GlnHEg+F8RD6ZsrNAfdNIyMFrWwXCnevtLKSgdsmc9tiBZfjtxCHzmmAdO0JJ4WlD+MuNnzTtbEoNoqq6i4nEPKsFLTJ7H2l8LRkLmOgPpMEAFcc1jS7EN4mcLSBe/k8n+p/4CmaZkxIFRqUWARnlLi0AJf8iiNRoChLHU3v/xnxRXZ60CRPxDUwe9ylfp3HRNHjlLghUcQmJvOLoMjnWXsOtyVXvN0ILpR+gi1kjEruVrI9ucXqBDcUiloyljFXlpfiMK67icEhgW/X3yy/LGL5HrA5Znemmn/HXYNhxHjBRxI+jHqTwuTUsfDpdV1Nox3SNGxZ2pJZ3Zb6A6KaZUzwuzPiq/dS4Gse7+3Nop8gtA12vH6wxW2FpkYVqj01/FXH9WIuv31Xni/6Nh7GiI0F+MSHXQHAKr+NGV1r7Op0TnRZuH86h1r0YIeNNPBqgEKMs5amVNoRD6TV1R42uyx6h3IjevCbAS+5XKnhvBr13X6C3dKeDFdYe7Q4eTDdlbFvSsGVQXfwBHvwVzg7mLgVk4IvBin3KC/Q2qufZmIsqNgLj0H23X1qvsLXoXQ7JiTIGEEz3ZcL38zmLOsMq9G8b2hBF+1KEy2nlEXKltTSz8uUS5CAos4nkhn6pFmLTgeSsdYOrRS1X+tGU3BUuL+4yt2LeZYQ4jQvTC9ZAA6NI/+RLtAPxNP8OKLbG KmM6QEda 21UEgA06MG8dMUV0lAc6tE+jCUrv9TFN5Bjf3dfexNhyrxhprJNe58IhxepUeJ0jG6gd4nQr8hSCAOtbTRY4UDkVXKe2F+ime9aOs2NY2o2O1c/s85oBJYjnsqa8YlFSSPs7/JrSAs/3AhKQr85orP9Wrrrm4u2liugoUobJBt/8z1ZO344SKNfL+nLxCeipVIpscF8LjldN7IzELMELnw8V+uIjOg9TQoNSScgyt10ZzR+OuZmGcgqXW/bD8Fc19zfVadHmXjXGBuEmlXXfbRwZZ9/39SXNXLtnjfBLEoQj34PF6MXCYgzYwpkxmSiAjji3PNmIJLeNX9h+84DguiKDp2uAmyn3BpuoRJHjPLZg2q+4lg80DTEqs1Dqa2DC5SJN2yv8ghfXk/9k= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Fri, Sep 06, 2024 at 12:05:23AM +0100, Mark Brown wrote: > Since arm64 has now used all of AT_HWCAP2 it needs to either start using > AT_HWCAP3 (which was recently added for PowerPC) or start allocating > bits 32..61 of AT_HWCAP first. Those are documented in elf_hwcaps.rst > as unused and in uapi/asm/hwcap.h as unallocated for potential use by > libc, glibc does currently use bits 62 and 63. This series has the code > for enabling AT_HWCAP3 as a reference. > > We will at some point need to bite this bullet but we need to decide if > it's now or later. Given that we used the high bits of AT_HWCAP2 first > and AT_HWCAP3 is already defined it feels like that might be people's > preference, in order to minimise churn in serieses adding new HWCAPs > it'd be good to get consensus if that's the case or not. Since the arm64 ABI documents that only bits 62 and 63 from AT_HWCAP are reserved for glibc, I think we should start using the remaining 30 bits of AT_HWCAP first before going for AT_HWCAP3. I'm sure we'll go through them quickly enough, so these two patches will have to be merged at some point. We'll need an Ack from the (arm64) glibc people on the GCS patch series if we are going for bits 32+ in AT_HWCAP. -- Catalin