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 X-Spam-Level: X-Spam-Status: No, score=-8.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5CB54C4338F for ; Thu, 29 Jul 2021 11:22:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3AA0F60F02 for ; Thu, 29 Jul 2021 11:22:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234595AbhG2LWb (ORCPT ); Thu, 29 Jul 2021 07:22:31 -0400 Received: from mail.kernel.org ([198.145.29.99]:45678 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231834AbhG2LWb (ORCPT ); Thu, 29 Jul 2021 07:22:31 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id CD06E60E9B; Thu, 29 Jul 2021 11:22:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1627557748; bh=FcuFb6wlftgSlWoSTOwAzofJHtrPrqyxkS6xE1qzB18=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=rgFR7CinLkyo9QZHPWgXRDYxvxgVlAX5ZnAvM7+uaERbBP/+0Nk8CrssxnHdA1GVO VwPzF8ohmc5WNK1lLDaKooQnEdekJwXFyMN1B8QSl9xIYqaJWYWbsm0LG+ECjFSexT fmpj4eHip0n/RahaZGTGviOFozrfTG5L9bm3NBReepiczNueyxMnBaKz3+QKlTA7gm ojQqLoPoSVIxJ5YzUDIwAJepzu+yzqBxunjI8tHt7tqmLRRF+fDjmuF3Cj8jzhE/+F cR5eG5G8O4FmTuMjLzYWeWJpSxXLwiauihbz2jf3/irj+s0XRPlTQarJRXvAAWwzcP +1Pzq+//TjnDw== Date: Thu, 29 Jul 2021 12:22:17 +0100 From: Mark Brown To: Dave Martin Cc: Catalin Marinas , Will Deacon , Shuah Khan , linux-arm-kernel@lists.infradead.org, linux-kselftest@vger.kernel.org Subject: Re: [PATCH v2 1/4] kselftest/arm64: Provide a helper binary and "library" for SVE RDVL Message-ID: <20210729112217.GK4670@sirena.org.uk> References: <20210728163318.51492-1-broonie@kernel.org> <20210728163318.51492-2-broonie@kernel.org> <20210729095222.GH1724@arm.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="J3rqiH0DIeiRD2zz" Content-Disposition: inline In-Reply-To: <20210729095222.GH1724@arm.com> X-Cookie: Vini, vidi, Linux! User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kselftest@vger.kernel.org --J3rqiH0DIeiRD2zz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Jul 29, 2021 at 10:52:24AM +0100, Dave Martin wrote: > On Wed, Jul 28, 2021 at 05:33:15PM +0100, Mark Brown wrote: > > + return 0; > For consistency with the changes in vec-syscfg, we could use > EXIT_SUCCESS here. 0 and EXIT_SUCCESS are defined as equivalent (though they need not be equal!) and 0 is much more idiomatic. > Although it's hard to see what could go wrong I/O-wise that doesn't > involve vec-syscfg itself having gone wrong, it's probably good > practice to do the final error check: > if (ferror(stdout) || fclose(stdout)) > return EXIT_FAILURE; > return EXIT_SUCCESS; > (In reality, people rarely seem to bother with this, so I'm not going > to lose sleep if we don't do it...) Yeah, I think this is one of those raising more questions than it answers kind of things. > > +.globl rdvl_sve > Should we stick a > .type rdvl_sve, @function > here? This may avoid surprises with future toolchain behaviours. > Probably doesn't matter, but I have bad memories of Thumb-2... > Lacking this annotation is widespread though, as well as being de facto > standard before awkward architectures came along. Yeah, it doesn't seem to be in the slightest bit idiomatic for the arm64 asm code the kernel has. I don't know if you think it's worth adding that to SYM_FUNC_START now we have it though? > If the selftests have access to the ENTRY() macro we could use that, but > I'm guessing that isn't exported for userspace. We don't use that any more anyway, it's SYM_FUNC_START() and friends not that those are outside the kernel either. We will have to do something like that if anyone starts building userspace with BTI though (or I might just shove a BTI C in there unconditionally, I'm sure we'll cope with the overhead on older systems). --J3rqiH0DIeiRD2zz Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmECj2gACgkQJNaLcl1U h9A90wf/V5EUCOkVbK4/Pt1Gkd/v98yXPokeJTn6vhVPDVSOBo6QH2mv/LUQfRID mPJ3b4UXdi39JUOefgfn+4MZjQzPcZJUO3TI5Osny2BXPWj5Ii5L6aV75iOEInyg Dc6eY/Anr/KVQcnETSmKJXrS2ZNOY6H8ZDkQmz6mW0NPBoNL5h0rnEF4FTJhDnSw LrvmSLlNeqEVGF1f5OiH+AOR9uZNr9+6msOVoR1cqT/JZjVuZzAXHG9EUju4Krdl wdiAOagB0dPN/xq9mbyu6AgCqZQF3VCR4/C0VYeqNwXYjXwobrXGRaclQFC7y/Kk QqINh0AbZJYVbKT/0f2FIrGlO547QA== =xtv7 -----END PGP SIGNATURE----- --J3rqiH0DIeiRD2zz-- 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 X-Spam-Level: X-Spam-Status: No, score=-6.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 05C15C4338F for ; Thu, 29 Jul 2021 11:24:32 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id BC16560E9B for ; Thu, 29 Jul 2021 11:24:31 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org BC16560E9B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: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-Transfer-Encoding:Content-ID:Content-Description:Resent-Date :Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=ldpHl0XvcTIHsTOREVp76FBxEAKapPmZYvDGikZidhA=; b=ASHBFOfmE9ExHyQWTpGYHVyuiY c0OMKWz9GZTeg1Zy009xm2RiDnUY4k2uRVYSqLegNvtNvWJKbQaiJlWXAZ3HnsVF6YjbgCZ78jeFl ePCq7MnMWb8L+emfC/kftD35SsaNPYy8FrtYzYyWzFS960Owpv4HH/Q4T3yygWOamk3UB/UF7Gcg4 Yhjf9U2KHWZKaa0mP/uCtB3fdQXQaIcwhIhSAfXPjhx+7q4FdhEbQpbuquNMjdJ3FU6Zp5+BKOBBd z2Z+3mR7mewWGVY9WMtvlDcqdeLNxBTqPZKK0fssxdRzLkdRx9LQXOQZcX9qaqDokATs8XVltGiqD CfDXogdQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1m947U-003yS6-IA; Thu, 29 Jul 2021 11:22:32 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1m947R-003yRe-32 for linux-arm-kernel@lists.infradead.org; Thu, 29 Jul 2021 11:22:30 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id CD06E60E9B; Thu, 29 Jul 2021 11:22:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1627557748; bh=FcuFb6wlftgSlWoSTOwAzofJHtrPrqyxkS6xE1qzB18=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=rgFR7CinLkyo9QZHPWgXRDYxvxgVlAX5ZnAvM7+uaERbBP/+0Nk8CrssxnHdA1GVO VwPzF8ohmc5WNK1lLDaKooQnEdekJwXFyMN1B8QSl9xIYqaJWYWbsm0LG+ECjFSexT fmpj4eHip0n/RahaZGTGviOFozrfTG5L9bm3NBReepiczNueyxMnBaKz3+QKlTA7gm ojQqLoPoSVIxJ5YzUDIwAJepzu+yzqBxunjI8tHt7tqmLRRF+fDjmuF3Cj8jzhE/+F cR5eG5G8O4FmTuMjLzYWeWJpSxXLwiauihbz2jf3/irj+s0XRPlTQarJRXvAAWwzcP +1Pzq+//TjnDw== Date: Thu, 29 Jul 2021 12:22:17 +0100 From: Mark Brown To: Dave Martin Cc: Catalin Marinas , Will Deacon , Shuah Khan , linux-arm-kernel@lists.infradead.org, linux-kselftest@vger.kernel.org Subject: Re: [PATCH v2 1/4] kselftest/arm64: Provide a helper binary and "library" for SVE RDVL Message-ID: <20210729112217.GK4670@sirena.org.uk> References: <20210728163318.51492-1-broonie@kernel.org> <20210728163318.51492-2-broonie@kernel.org> <20210729095222.GH1724@arm.com> MIME-Version: 1.0 In-Reply-To: <20210729095222.GH1724@arm.com> X-Cookie: Vini, vidi, Linux! User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210729_042229_210404_70ED4C94 X-CRM114-Status: GOOD ( 24.11 ) 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: multipart/mixed; boundary="===============2599017560238909211==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============2599017560238909211== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="J3rqiH0DIeiRD2zz" Content-Disposition: inline --J3rqiH0DIeiRD2zz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Jul 29, 2021 at 10:52:24AM +0100, Dave Martin wrote: > On Wed, Jul 28, 2021 at 05:33:15PM +0100, Mark Brown wrote: > > + return 0; > For consistency with the changes in vec-syscfg, we could use > EXIT_SUCCESS here. 0 and EXIT_SUCCESS are defined as equivalent (though they need not be equal!) and 0 is much more idiomatic. > Although it's hard to see what could go wrong I/O-wise that doesn't > involve vec-syscfg itself having gone wrong, it's probably good > practice to do the final error check: > if (ferror(stdout) || fclose(stdout)) > return EXIT_FAILURE; > return EXIT_SUCCESS; > (In reality, people rarely seem to bother with this, so I'm not going > to lose sleep if we don't do it...) Yeah, I think this is one of those raising more questions than it answers kind of things. > > +.globl rdvl_sve > Should we stick a > .type rdvl_sve, @function > here? This may avoid surprises with future toolchain behaviours. > Probably doesn't matter, but I have bad memories of Thumb-2... > Lacking this annotation is widespread though, as well as being de facto > standard before awkward architectures came along. Yeah, it doesn't seem to be in the slightest bit idiomatic for the arm64 asm code the kernel has. I don't know if you think it's worth adding that to SYM_FUNC_START now we have it though? > If the selftests have access to the ENTRY() macro we could use that, but > I'm guessing that isn't exported for userspace. We don't use that any more anyway, it's SYM_FUNC_START() and friends not that those are outside the kernel either. We will have to do something like that if anyone starts building userspace with BTI though (or I might just shove a BTI C in there unconditionally, I'm sure we'll cope with the overhead on older systems). --J3rqiH0DIeiRD2zz Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmECj2gACgkQJNaLcl1U h9A90wf/V5EUCOkVbK4/Pt1Gkd/v98yXPokeJTn6vhVPDVSOBo6QH2mv/LUQfRID mPJ3b4UXdi39JUOefgfn+4MZjQzPcZJUO3TI5Osny2BXPWj5Ii5L6aV75iOEInyg Dc6eY/Anr/KVQcnETSmKJXrS2ZNOY6H8ZDkQmz6mW0NPBoNL5h0rnEF4FTJhDnSw LrvmSLlNeqEVGF1f5OiH+AOR9uZNr9+6msOVoR1cqT/JZjVuZzAXHG9EUju4Krdl wdiAOagB0dPN/xq9mbyu6AgCqZQF3VCR4/C0VYeqNwXYjXwobrXGRaclQFC7y/Kk QqINh0AbZJYVbKT/0f2FIrGlO547QA== =xtv7 -----END PGP SIGNATURE----- --J3rqiH0DIeiRD2zz-- --===============2599017560238909211== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel --===============2599017560238909211==--