From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D49984C6E; Fri, 12 Apr 2024 20:40:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712954411; cv=none; b=FzdFYwFmS+ZmytNAXiie5m5+ue6L4298jshGTESZYBTLrssNKMvLJe4wjvKdvgNlSi5fxYcrApQScvKEm5MR0PW8MwkSXSWUnb8URvkeqNN0QWwXl1TRXReGqadWhDeoSzKvBmYt+gdK+m3GpVUd6JuI+K6W1/3xHQ8Insa+tmU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712954411; c=relaxed/simple; bh=Wgrizvi5A+bU/saW/WglETWFAcMfROK+Fq7L/emRDFU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=CcYVG/75OavGpFKPpIZoBuVzm6AwVS76y5jlOkOpMjjeKVC3f1gTkvGkokZ5VHjU5YBm4WrpLxVZcAtR/RENQWiSmjmyhLQ1srEd0au2AFXo/gHfq58bggDwpMC3AGgOnPCMBHbnQdel8QmQCrwk4gUtMtXrqDKC22xhZaot0wQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=DLrZrrOE; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="DLrZrrOE" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9F638C113CC; Fri, 12 Apr 2024 20:40:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1712954410; bh=Wgrizvi5A+bU/saW/WglETWFAcMfROK+Fq7L/emRDFU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=DLrZrrOErntm7dx7brDVgtbc8YFE2ZWlhntzOKdzavzwbiPxdU4SxE5N0s99Lv7nF 8v8rtZVaBDWLs2oX+WlaoolC6mQtDz3xrrt+8xqMRhypWjiJkT1lwLEYj7FzFUR57Z IBmXiSjqFroWZ8UpPhH0TOiv485z8A6gHEzoxvpwyLb5qHAP6frHZmj3Rm4YznYeQq TU+oWLs44WYtvFqwjIXj6y7khsPUAazL+HE/zPLZo9mqLjCvhjzzhXMpNemVImfRlq /0BApQnILlJ+SoD9dCK7n5cP3xfmyXobojk7lVgDwwuLKCZdOPB4oeheH2wz5vnDqo mOuxra2m04tsg== Date: Fri, 12 Apr 2024 21:40:03 +0100 From: Conor Dooley To: Charlie Jenkins Cc: Conor Dooley , Rob Herring , Krzysztof Kozlowski , Paul Walmsley , Palmer Dabbelt , Albert Ou , Guo Ren , Conor Dooley , Chen-Yu Tsai , Jernej Skrabec , Samuel Holland , Evan Green , =?iso-8859-1?Q?Cl=E9ment_L=E9ger?= , Jonathan Corbet , Shuah Khan , linux-riscv@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Palmer Dabbelt , linux-arm-kernel@lists.infradead.org, linux-sunxi@lists.linux.dev, linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org Subject: Re: [PATCH 08/19] riscv: Introduce vendor variants of extension helpers Message-ID: <20240412-drab-french-55d8ff2c8cfa@spud> References: <20240411-dev-charlie-support_thead_vector_6_9-v1-0-4af9815ec746@rivosinc.com> <20240411-dev-charlie-support_thead_vector_6_9-v1-8-4af9815ec746@rivosinc.com> <20240412-dwarf-shower-5a7300fcd283@wendy> Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="aP1C8yQRrFgLdfM0" Content-Disposition: inline In-Reply-To: --aP1C8yQRrFgLdfM0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 12, 2024 at 10:43:02AM -0700, Charlie Jenkins wrote: > On Fri, Apr 12, 2024 at 12:49:57PM +0100, Conor Dooley wrote: > > On Thu, Apr 11, 2024 at 09:11:14PM -0700, Charlie Jenkins wrote: > > > Create vendor variants of the existing extension helpers. If the > > > existing functions were instead modified to support vendor extensions= , a > > > branch based on the ext value being greater than > > > RISCV_ISA_VENDOR_EXT_BASE would have to be introduced. This additional > > > branch would have an unnecessary performance impact. > > >=20 > > > Signed-off-by: Charlie Jenkins > >=20 > > I've not looked at the "main" patch in the series that adds all of the > > probing and structures for representing this info yet beyond a cursory > > glance, but it feels like we're duplicating a bunch of infrastructure > > here before it is necessary. The IDs are all internal to Linux, so I'd > > rather we kept everything in the same structure until we have more than > > a handful of vendor extensions. With this patch (and the theadpmu stuff) > > we will have three vendor extensions which feels like a drop in the > > bucket compared to the standard ones. >=20 > It is not duplicating infrastructure. If we merge this into the existing > infrastructure, we would be littering if (ext > RISCV_ISA_VENDOR_EXT_BASE) > in __riscv_isa_extension_available. This is particularily important > exactly because we have so few vendor extensions currently so this check > would be irrelevant in the vast majority of cases. That's only because of your implementation. The existing vendor extension works fine without this littering. That's another thing actually, you forgot to convert over the user we already have :) > It is also unecessary to push off the refactoring until we have some > "sufficient" amount of vendor extensions to deem changing the > infrastructure when I already have the patch available here. This does > not introduce any extra overhead to existing functions and will be able > to support vendors into the future. Yeah, maybe that's true but this was my gut reaction before reading the other patch in detail (which I've still yet to do). --aP1C8yQRrFgLdfM0 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRh246EGq/8RLhDjO14tDGHoIJi0gUCZhmcIwAKCRB4tDGHoIJi 0mfZAP4qEWVgp1JuIP38Uolxn+eUBjm/iYTlV1+a2fJsENNWWgD/eG4awqACrOj8 2zrdJWUXuGon9BtRXw8OxMYkhWD0JAU= =y7fd -----END PGP SIGNATURE----- --aP1C8yQRrFgLdfM0--