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 D8EA7EB64DC for ; Wed, 28 Jun 2023 17:24:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231829AbjF1RYz (ORCPT ); Wed, 28 Jun 2023 13:24:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43656 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230215AbjF1RYr (ORCPT ); Wed, 28 Jun 2023 13:24:47 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C8CBB1FCD for ; Wed, 28 Jun 2023 10:24:46 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 5D11161407 for ; Wed, 28 Jun 2023 17:24:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 773F0C433C8; Wed, 28 Jun 2023 17:24:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1687973085; bh=Sop1yazDMV/lbh0CwxeOMS0e7MThVMtbfcxDvIY6Dh8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=dSRecRJtf1nhaszbsN0TCBX6rcEJD8lDqlCiZxK/c+rNQ5KqgAJzo/BFob79E2NCR RPurYxvyLHoGAN3GKmHY/cG/kuVpKmHsgw+HB1vrajaXVNV9V3hJMhqMQe/HXNAIUT 0dUNCPXrc7fkEtgtMhZgAb6TE12IWDijpbqG3ShvsQP2YRjknXqaUSD/7EFuw+ulY6 nP9ktEvzTdO0W+IZi/fsKBuXKo5XRcB7WzBG0XK/FjJL3b04sF23QKfJFl8OeeDlLu KvyqV+f21g6KzVBcwmV6xKUqPAfGze5q6t4oX0S3NHZRoVxRGW7ta6JTuVTOs5aE2K 8js1ra+oT9WgA== Date: Wed, 28 Jun 2023 18:24:40 +0100 From: Conor Dooley To: Evan Green Cc: Conor Dooley , Samuel Ortiz , Paul Walmsley , Palmer Dabbelt , Albert Ou , linux-riscv@lists.infradead.org, "Hongren (Zenithal) Zheng" , linux@rivosinc.com, Andrew Jones , Heiko Stuebner , Anup Patel , linux-kernel@vger.kernel.org, Guo Ren , Atish Patra , =?iso-8859-1?Q?Bj=F6rn_T=F6pel?= , Jiatai He Subject: Re: [PATCH 1/3] RISC-V: add Bitmanip/Scalar Crypto parsing from DT Message-ID: <20230628-dragonish-lullaby-b44d2df09d66@spud> References: <20230627143747.1599218-1-sameo@rivosinc.com> <20230627143747.1599218-2-sameo@rivosinc.com> <20230627-debating-twelve-da2c1ed60948@spud> <20230628-unfeeling-tavern-edd4f58396fa@wendy> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Nk2liGfu8KoG29TY" Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --Nk2liGfu8KoG29TY Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 28, 2023 at 10:18:34AM -0700, Evan Green wrote: > On Wed, Jun 28, 2023 at 4:10=E2=80=AFAM Conor Dooley wrote: > > > > On Wed, Jun 28, 2023 at 12:01:11PM +0200, Samuel Ortiz wrote: > > > On Tue, Jun 27, 2023 at 07:48:15PM +0100, Conor Dooley wrote: > > > > On Tue, Jun 27, 2023 at 11:14:30AM -0700, Evan Green wrote: > > > > > On Tue, Jun 27, 2023 at 7:38=E2=80=AFAM Samuel Ortiz wrote: > > > > > > > It would be nice to consolidate the ones together that search for= a > > > > > single string and set multiple bits, though I don't have any super > > > > > elegant ideas for how off the top of my head. > > > > > > > > I've got a refactor of this code in progress, dropping all of these > > > > copy-paste in place of a loop. It certainly looks more elegant than > > > > this, but it will fall over a bit for these "one string matches many > > > > extensions" cases. See here: > > > > https://patchwork.kernel.org/project/linux-riscv/patch/20230626-thi= eving-jockstrap-d35d20b535c5@wendy/ > > > > My immediate thought is to add another element to riscv_isa_ext_dat= a, > > > > that contains "parent" extensions to check for. Should be fairly do= able, > > > > I'll whip something up on top of that... > > > > > > Nice, and thanks for the review. > > > > > Should I wait for your refactor to be merged before pushing this one? > > > > I don't know. I think that you should continue on with your series here, > > and whichever goes in second gets rebased on top of the other. > > I don't think it makes material difference to review of this patchset as > > to whether you rebase on top of what I'm working on, so I wouldn't > > bother until it gets merged. > > > > Rather hacky, had less time than expected this morning: > > https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux.git/commit/= ?h=3Driscv-extensions-strings-supersets > > Clearly there's issues with looping to RISCV_ISA_MAX_SUPERSETS & I just > > repurposed Zicsr for the sake of testing something in the time I had. > > > > Evan, at a high level, does that look more elegant to you, or have I ma= de > > things worse? > > >=20 > I see what you're going for at least. It's unfortunate that when > someone bumps up RISCV_ISA_MAX_SUPERSETS it squares the whole array. > Another way to go might be to define the elements in a separate array, > like: >=20 > unsigned int riscv_zks_exts[] =3D { > RISCV_ISA_EXT_ZBKB, > RISCV_ISA_EXT_ZBKC, > .... > }; >=20 > then the macro entry looks like: >=20 > SET_ISA_EXT_MAP_MULTI("zks", riscv_zks_exts), >=20 > where the SET_ISA_EXT_MAP_MULTI() could use ARRAY_SIZE() to stash both > the pointer to the array and the number of elements. Yup, I like the sound of that. I like the variadic stuff as it'd not require defining a bunch of sub-arrays of supersets. I guess if it grows too badly, we can just dump it off into another file or w/e. --Nk2liGfu8KoG29TY Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRh246EGq/8RLhDjO14tDGHoIJi0gUCZJxs2AAKCRB4tDGHoIJi 0hyeAPoCJou4iW+SwgKBQCp5o/rvu8bFFnG2SdAC26nA3X5ifAD8Cev8fwX4Y1Qg 5T7g/LvQlXnVSz10udi5To5hLiisfQM= =dznn -----END PGP SIGNATURE----- --Nk2liGfu8KoG29TY--