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 mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by smtp.lore.kernel.org (Postfix) with ESMTP id C0DE5C433F5 for ; Tue, 25 Jan 2022 12:10:41 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 4257B49DE3; Tue, 25 Jan 2022 07:10:41 -0500 (EST) X-Virus-Scanned: at lists.cs.columbia.edu Authentication-Results: mm01.cs.columbia.edu (amavisd-new); dkim=softfail (fail, message has been altered) header.i=@kernel.org Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DU4wfuHTVzuA; Tue, 25 Jan 2022 07:10:40 -0500 (EST) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 1D23849E29; Tue, 25 Jan 2022 07:10:40 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 62EBC411BD for ; Tue, 25 Jan 2022 07:10:39 -0500 (EST) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nikpn6rNQUJo for ; Tue, 25 Jan 2022 07:10:38 -0500 (EST) Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 0B57240D26 for ; Tue, 25 Jan 2022 07:10:37 -0500 (EST) 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 ams.source.kernel.org (Postfix) with ESMTPS id 7EEBAB817C3; Tue, 25 Jan 2022 12:10:36 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1743FC340E0; Tue, 25 Jan 2022 12:10:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1643112635; bh=sFg/+U854evqBj7SymFtSzOukK5/ylDdAyC4Ajtv1Ss=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=OoIFIZjGdycI02z5vlSS7jd6GZPA2U7gNxY6w8PFRVRbbFoZ378iaQbjHuH6+DHMM xtW88bSmai1VVg6YLlrx1uFCATucVq989h/gpId1NkXZ9JX6wxKm16ZDM4Gp+Ndh4r vu/4KTpEKDIpkCWh0owUJ2Z78q0YwOMjXb94x/vLbdsAJO/KSC0l2Txns2jYZIbh7i a8sbOrM8nc6fZu6JXrOWRcfk5RdT7BbmOvt60fPvIIYhgycd7M7L3UHaQnHxL6trfY hnvJEVzV0Cee8kTSXV9Uihjq1htiR5YOYmU8LK8S/F3tY8P2GEvzKnFDGnrpNwWzLz y6vRxSGUvNryg== Date: Tue, 25 Jan 2022 12:10:28 +0000 From: Mark Brown To: Suzuki K Poulose Subject: Re: [PATCH v8 01/38] arm64: cpufeature: Always specify and use a field width for capabilities Message-ID: References: <20220125001114.193425-1-broonie@kernel.org> <20220125001114.193425-2-broonie@kernel.org> MIME-Version: 1.0 In-Reply-To: X-Cookie: The second best policy is dishonesty. Cc: Marc Zyngier , Basant Kumar Dwivedi , Will Deacon , Luis Machado , Szabolcs Nagy , Catalin Marinas , Alan Hayward , linux-arm-kernel@lists.infradead.org, linux-kselftest@vger.kernel.org, Shuah Khan , Shuah Khan , kvmarm@lists.cs.columbia.edu, Salil Akerkar X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8705914020106766531==" Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu --===============8705914020106766531== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="XS5KfZPoqAQVB4C2" Content-Disposition: inline --XS5KfZPoqAQVB4C2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Jan 25, 2022 at 10:57:47AM +0000, Suzuki K Poulose wrote: > On 25/01/2022 00:10, Mark Brown wrote: > > + int val = cpuid_feature_extract_field_width(reg, entry->field_pos, > > + entry->field_width, > > + entry->sign); > Could we do something like : > + int val = cpuid_feature_extract_field_width(reg, entry->field_pos, > entry->field_width ? : 4, > .. > ); > and leave the existing structures as they are ? Obviously we *could* (ideally without the ternery operator) but having the implicit default like that makes me nervous that it's too easy to just forget to fill it in and get the wrong default. > And that could avoid these changes too. We could add : > #define HWCAP_CPUID_MATCH_WIDTH(...) > when/if we need one, which sets the width. I'd originally had a completely separate set of definitions for single bit fields but Catlain wanted to get everything in one. I'm not sure I see a huge advantage in sharing the match function and not also sharing the macro TBH. --XS5KfZPoqAQVB4C2 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmHv6LQACgkQJNaLcl1U h9BmCAf+OOGqr40J+iVV3HqoKIEq1uCYDDSkIElqZkeLGdKgbG70Z9c65SRPpb3n WgHwZRgAt4j99AtorLwbLUSHx/KFVG12+72Iwr5j6iexT4NW/64DPRJgUIbzXItk tVXRVOcBS6geqopHOvKny9vYbEcuU/RsibVkMQYTytUo9S76Bwh/AuxxoN3EqZn0 Bjk9O2bqPnU8Wfy4usdFRBO8B8FhCCPlgzSr4/lCKIAp2ZlEYo7zzlNP+y5x3Y7W CwVHXSgCWwTOcWT5isvt/d9NRU/yp6woiVq4x1ly59mUrWNklyjUb3rNBP7v1Qyh sa0teR+x43Dw6/Ym9mL6L5+57HtAUg== =yrcl -----END PGP SIGNATURE----- --XS5KfZPoqAQVB4C2-- --===============8705914020106766531== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm --===============8705914020106766531==-- 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 8A950C433F5 for ; Tue, 25 Jan 2022 12:11:54 +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-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=Z1mvH819nGZ9XJ5+gQtDKT1fe1uYX4+439LfxRtnq8Q=; b=xLVJqhDLMaycy/bLb6QzU/yGCS VmH4VpZlXC7CB+d9ITeC3ALEHic7B67jGzOSFpt2+NLDMgRukED9wpPWaELvvdFSvaaSb5APJZCej zrsR3JBTAYSSstkFAuSRlt3/jS+RToFRNnbeP0OyrTKUCTP9DmIcrGG97uw/cl3FrTcdJ0goyS52P yHY9qd2eS+ifGrnyDrmpng/zyT1YqOw2K9Jqx0e9rM0PAWulPtr1MEUkp5pg8TV6/RearFjY++AJF bojCcUa+NnBeyf2ka/NNEA5P+yn7nG94VTWh/Qor8iDtgU2m0emmlWRXYFpiWOg9HcvyXkDid34pX IOWzHU8g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nCKen-007jZg-1D; Tue, 25 Jan 2022 12:10:41 +0000 Received: from ams.source.kernel.org ([2604:1380:4601:e00::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nCKej-007jYC-Sx for linux-arm-kernel@lists.infradead.org; Tue, 25 Jan 2022 12:10:39 +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 ams.source.kernel.org (Postfix) with ESMTPS id 7EEBAB817C3; Tue, 25 Jan 2022 12:10:36 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1743FC340E0; Tue, 25 Jan 2022 12:10:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1643112635; bh=sFg/+U854evqBj7SymFtSzOukK5/ylDdAyC4Ajtv1Ss=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=OoIFIZjGdycI02z5vlSS7jd6GZPA2U7gNxY6w8PFRVRbbFoZ378iaQbjHuH6+DHMM xtW88bSmai1VVg6YLlrx1uFCATucVq989h/gpId1NkXZ9JX6wxKm16ZDM4Gp+Ndh4r vu/4KTpEKDIpkCWh0owUJ2Z78q0YwOMjXb94x/vLbdsAJO/KSC0l2Txns2jYZIbh7i a8sbOrM8nc6fZu6JXrOWRcfk5RdT7BbmOvt60fPvIIYhgycd7M7L3UHaQnHxL6trfY hnvJEVzV0Cee8kTSXV9Uihjq1htiR5YOYmU8LK8S/F3tY8P2GEvzKnFDGnrpNwWzLz y6vRxSGUvNryg== Date: Tue, 25 Jan 2022 12:10:28 +0000 From: Mark Brown To: Suzuki K Poulose Cc: Catalin Marinas , Will Deacon , Marc Zyngier , Shuah Khan , Shuah Khan , Alan Hayward , Luis Machado , Salil Akerkar , Basant Kumar Dwivedi , Szabolcs Nagy , James Morse , Alexandru Elisei , linux-arm-kernel@lists.infradead.org, linux-kselftest@vger.kernel.org, kvmarm@lists.cs.columbia.edu Subject: Re: [PATCH v8 01/38] arm64: cpufeature: Always specify and use a field width for capabilities Message-ID: References: <20220125001114.193425-1-broonie@kernel.org> <20220125001114.193425-2-broonie@kernel.org> MIME-Version: 1.0 In-Reply-To: X-Cookie: The second best policy is dishonesty. X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220125_041038_108077_083E96F6 X-CRM114-Status: GOOD ( 16.14 ) 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="===============3042022322687512999==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============3042022322687512999== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="XS5KfZPoqAQVB4C2" Content-Disposition: inline --XS5KfZPoqAQVB4C2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Jan 25, 2022 at 10:57:47AM +0000, Suzuki K Poulose wrote: > On 25/01/2022 00:10, Mark Brown wrote: > > + int val = cpuid_feature_extract_field_width(reg, entry->field_pos, > > + entry->field_width, > > + entry->sign); > Could we do something like : > + int val = cpuid_feature_extract_field_width(reg, entry->field_pos, > entry->field_width ? : 4, > .. > ); > and leave the existing structures as they are ? Obviously we *could* (ideally without the ternery operator) but having the implicit default like that makes me nervous that it's too easy to just forget to fill it in and get the wrong default. > And that could avoid these changes too. We could add : > #define HWCAP_CPUID_MATCH_WIDTH(...) > when/if we need one, which sets the width. I'd originally had a completely separate set of definitions for single bit fields but Catlain wanted to get everything in one. I'm not sure I see a huge advantage in sharing the match function and not also sharing the macro TBH. --XS5KfZPoqAQVB4C2 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmHv6LQACgkQJNaLcl1U h9BmCAf+OOGqr40J+iVV3HqoKIEq1uCYDDSkIElqZkeLGdKgbG70Z9c65SRPpb3n WgHwZRgAt4j99AtorLwbLUSHx/KFVG12+72Iwr5j6iexT4NW/64DPRJgUIbzXItk tVXRVOcBS6geqopHOvKny9vYbEcuU/RsibVkMQYTytUo9S76Bwh/AuxxoN3EqZn0 Bjk9O2bqPnU8Wfy4usdFRBO8B8FhCCPlgzSr4/lCKIAp2ZlEYo7zzlNP+y5x3Y7W CwVHXSgCWwTOcWT5isvt/d9NRU/yp6woiVq4x1ly59mUrWNklyjUb3rNBP7v1Qyh sa0teR+x43Dw6/Ym9mL6L5+57HtAUg== =yrcl -----END PGP SIGNATURE----- --XS5KfZPoqAQVB4C2-- --===============3042022322687512999== 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 --===============3042022322687512999==-- 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 99A68C433F5 for ; Tue, 25 Jan 2022 12:14:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230064AbiAYMNv (ORCPT ); Tue, 25 Jan 2022 07:13:51 -0500 Received: from dfw.source.kernel.org ([139.178.84.217]:58728 "EHLO dfw.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1444194AbiAYMKo (ORCPT ); Tue, 25 Jan 2022 07:10:44 -0500 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 D3AC261147 for ; Tue, 25 Jan 2022 12:10:35 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1743FC340E0; Tue, 25 Jan 2022 12:10:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1643112635; bh=sFg/+U854evqBj7SymFtSzOukK5/ylDdAyC4Ajtv1Ss=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=OoIFIZjGdycI02z5vlSS7jd6GZPA2U7gNxY6w8PFRVRbbFoZ378iaQbjHuH6+DHMM xtW88bSmai1VVg6YLlrx1uFCATucVq989h/gpId1NkXZ9JX6wxKm16ZDM4Gp+Ndh4r vu/4KTpEKDIpkCWh0owUJ2Z78q0YwOMjXb94x/vLbdsAJO/KSC0l2Txns2jYZIbh7i a8sbOrM8nc6fZu6JXrOWRcfk5RdT7BbmOvt60fPvIIYhgycd7M7L3UHaQnHxL6trfY hnvJEVzV0Cee8kTSXV9Uihjq1htiR5YOYmU8LK8S/F3tY8P2GEvzKnFDGnrpNwWzLz y6vRxSGUvNryg== Date: Tue, 25 Jan 2022 12:10:28 +0000 From: Mark Brown To: Suzuki K Poulose Cc: Catalin Marinas , Will Deacon , Marc Zyngier , Shuah Khan , Shuah Khan , Alan Hayward , Luis Machado , Salil Akerkar , Basant Kumar Dwivedi , Szabolcs Nagy , James Morse , Alexandru Elisei , linux-arm-kernel@lists.infradead.org, linux-kselftest@vger.kernel.org, kvmarm@lists.cs.columbia.edu Subject: Re: [PATCH v8 01/38] arm64: cpufeature: Always specify and use a field width for capabilities Message-ID: References: <20220125001114.193425-1-broonie@kernel.org> <20220125001114.193425-2-broonie@kernel.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="XS5KfZPoqAQVB4C2" Content-Disposition: inline In-Reply-To: X-Cookie: The second best policy is dishonesty. Precedence: bulk List-ID: X-Mailing-List: linux-kselftest@vger.kernel.org --XS5KfZPoqAQVB4C2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Jan 25, 2022 at 10:57:47AM +0000, Suzuki K Poulose wrote: > On 25/01/2022 00:10, Mark Brown wrote: > > + int val = cpuid_feature_extract_field_width(reg, entry->field_pos, > > + entry->field_width, > > + entry->sign); > Could we do something like : > + int val = cpuid_feature_extract_field_width(reg, entry->field_pos, > entry->field_width ? : 4, > .. > ); > and leave the existing structures as they are ? Obviously we *could* (ideally without the ternery operator) but having the implicit default like that makes me nervous that it's too easy to just forget to fill it in and get the wrong default. > And that could avoid these changes too. We could add : > #define HWCAP_CPUID_MATCH_WIDTH(...) > when/if we need one, which sets the width. I'd originally had a completely separate set of definitions for single bit fields but Catlain wanted to get everything in one. I'm not sure I see a huge advantage in sharing the match function and not also sharing the macro TBH. --XS5KfZPoqAQVB4C2 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmHv6LQACgkQJNaLcl1U h9BmCAf+OOGqr40J+iVV3HqoKIEq1uCYDDSkIElqZkeLGdKgbG70Z9c65SRPpb3n WgHwZRgAt4j99AtorLwbLUSHx/KFVG12+72Iwr5j6iexT4NW/64DPRJgUIbzXItk tVXRVOcBS6geqopHOvKny9vYbEcuU/RsibVkMQYTytUo9S76Bwh/AuxxoN3EqZn0 Bjk9O2bqPnU8Wfy4usdFRBO8B8FhCCPlgzSr4/lCKIAp2ZlEYo7zzlNP+y5x3Y7W CwVHXSgCWwTOcWT5isvt/d9NRU/yp6woiVq4x1ly59mUrWNklyjUb3rNBP7v1Qyh sa0teR+x43Dw6/Ym9mL6L5+57HtAUg== =yrcl -----END PGP SIGNATURE----- --XS5KfZPoqAQVB4C2--