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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 D9182C433EF for ; Wed, 29 Jun 2022 13:57:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=PJjzVOycqXjONPal4dKL/VShVxwvH7zqY8F4h9PKQlE=; b=4xPdOXms9txg3r O/bLwD5BdYaKt5Bazc8BnsoM8oXSrfSqALbNoKTN4Z0BrOQyMqYvL7az2z+aq4KA0BLO3z1RwpTzU 0XIP5qd+4GXwBwV9zr1jSzDzEjSxXFSvUD4j5XepbaUsTEeppEFjAULEfm5K+Y1y74k7WyXD/1F8H 0Nyf5B7ppSS5LAoLImJmk1S5OjMxo28k+nT205nr9bCtZEOMGTLCftRrzZqAVb7ocHXk/6QQaDcQJ 3dGlnaqf00yaHNdyums3FOB+60ELVl4v0Rhd3u+0V8TpvknQQuVFUi4icZVNwJyBT6HfgC+065+xE p1e8Kd/1YK0JQUxowRwg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1o6YAn-00CLON-W1; Wed, 29 Jun 2022 13:56:06 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1o6YAj-00CLNl-Tx for linux-arm-kernel@lists.infradead.org; Wed, 29 Jun 2022 13:56:03 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 28C5561904; Wed, 29 Jun 2022 13:56:01 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2039EC34114; Wed, 29 Jun 2022 13:55:58 +0000 (UTC) Date: Wed, 29 Jun 2022 14:55:55 +0100 From: Catalin Marinas To: Szabolcs Nagy Cc: Mark Brown , Will Deacon , Eric Biederman , Kees Cook , Suzuki K Poulose , linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v2 1/4] arm64/cpufeature: Store elf_hwcaps as an array rather than unsigned long Message-ID: References: <20220620125451.653507-1-broonie@kernel.org> <20220620125451.653507-2-broonie@kernel.org> <20220628142124.GB24116@willie-the-truck> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220629_065602_044384_C2EE0913 X-CRM114-Status: GOOD ( 24.70 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Jun 29, 2022 at 11:01:43AM +0100, Szabolcs Nagy wrote: > The 06/28/2022 16:06, Mark Brown wrote: > > On Tue, Jun 28, 2022 at 03:21:25PM +0100, Will Deacon wrote: > > > On Mon, Jun 20, 2022 at 01:54:48PM +0100, Mark Brown wrote: > > > > +/* Note that bits 62 and 63 of each AT_HWCAP are reserved */ > > > > > Can you expand a bit on this comment, please? It's not clear who has > > > reserved those bits (e.g. kernel or userspace) and why having two bit > > > reserved means we are limited to 32 instead of 62 bits. > > > > It's also not clear to me why they're reserved, I didn't manage to dig > > far enough into the history to figure that out - I believe it's a glibc > > thing, or at least something glibc now expects. Indeed I can't > > immediately dig up the specific reference now. Szabolcs? > > only the top two bits of AT_HWCAP are reserved for glibc. > (bits of AT_HWCAP2 are not reserved.) > > we did the 32bit limit because of ilp32 and i requested to > keep following that. > > there is no precedent for using more than 32bit AT_HWCAP nor > precedent for using AT_HWCAP3. [...] > - start using top bits of AT_HWCAP2 but not of AT_HWCAP. > (this is the least amount of work for now) That's a bit more appealing to me in the short term, though we may still end up with AT_HWCAP3 at some point. Is anyone still thinking seriously about ILP32? -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel