Received-SPF: pass (google.com: domain of linux-kernel+bounces-160674-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Date: Fri, 26 Apr 2024 21:37:33 +0100
From: Conor Dooley <conor@kernel.org>
To: Charlie Jenkins <charlie@rivosinc.com>
Cc: Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>, Guo Ren <guoren@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>, Chen-Yu Tsai <wens@csie.org>,
	Jernej Skrabec <jernej.skrabec@gmail.com>,
	Samuel Holland <samuel@sholland.org>,
	Conor Dooley <conor.dooley@microchip.com>,
	Evan Green <evan@rivosinc.com>,
	=?iso-8859-1?Q?Cl=E9ment_L=E9ger?= <cleger@rivosinc.com>,
	Jonathan Corbet <corbet@lwn.net>, Shuah Khan <shuah@kernel.org>,
	linux-riscv@lists.infradead.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, Palmer Dabbelt <palmer@rivosinc.com>,
	linux-arm-kernel@lists.infradead.org, linux-sunxi@lists.linux.dev,
	linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org
Subject: Re: [PATCH v3 08/17] riscv: Introduce vendor variants of extension
 helpers
Message-ID: <20240426-suitable-unsheathe-0c5f5851c891@spud>
References: <20240420-dev-charlie-support_thead_vector_6_9-v3-0-67cff4271d1d@rivosinc.com>
 <20240420-dev-charlie-support_thead_vector_6_9-v3-8-67cff4271d1d@rivosinc.com>
 <20240426-myself-crowbar-99dc0a080cd9@spud>
 <ZiwIBmlaDbYdmv8f@ghost>
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="X64VCS2z8liAY+RZ"
Content-Disposition: inline
In-Reply-To: <ZiwIBmlaDbYdmv8f@ghost>


--X64VCS2z8liAY+RZ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Apr 26, 2024 at 01:01:10PM -0700, Charlie Jenkins wrote:
> On Fri, Apr 26, 2024 at 05:19:59PM +0100, Conor Dooley wrote:
> > On Sat, Apr 20, 2024 at 06:04:40PM -0700, Charlie Jenkins wrote:
> > > @@ -163,6 +164,8 @@ void thead_errata_patch_func(struct alt_entry *be=
gin, struct alt_entry *end,
> > >  	for (alt =3D begin; alt < end; alt++) {
> > >  		if (alt->vendor_id !=3D THEAD_VENDOR_ID)
> > >  			continue;
> > > +		if (alt->patch_id >=3D RISCV_VENDOR_EXT_ALTERNATIVES_BASE)
> > > +			continue;
> >=20
> > >  		if (alt->patch_id >=3D ERRATA_THEAD_NUMBER)
> >=20
> > This number is 2, how does the patching actually work for vendor stuff
> > when the base is always greater than 2?
> >=20
>=20
> Patching is handled through the patcher at the end of cpufeature.c. The
> vendor_id field is set in the alternatives for errata and now also for
> vendor extensions. The vendor extension patching is all handled
> generically.
>=20
> This is distinguished by the patch_id being greater than
> RISCV_VENDOR_EXT_ALTERNATIVES_BASE, which should leave way more than
> enough room for errata ids. Since the code already checks if the
> patch_id is greater than the errata number, I can drop the
> "if (alt->patch_id >=3D RISCV_VENDOR_EXT_ALTERNATIVES_BASE)" check.

Ah, ye, I was being dumb - I was somehow thinking that you were using
the errata patch function to patch this, which obviously wouldn't be a
good design. If that had been the case, you'd never patch anything, but
you patch the extensions using the cpufeature patch function so it all
works out.

If anything, I guess there could be an assert here somewhere that
enforces ERRATA_VENDOR_NUMBER < VENDOR_EXT_BASE.

--X64VCS2z8liAY+RZ
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQRh246EGq/8RLhDjO14tDGHoIJi0gUCZiwQjQAKCRB4tDGHoIJi
0tMXAQC2Jy5XWBM1FWNAjh7ocF5y/z1Sjb/6AbsEoZ39m4Y8AAEA+Z85d2KbMCvL
2c+qY4x+XGFCBD5ZSMejeXfez3/DvAs=
=XikS
-----END PGP SIGNATURE-----

--X64VCS2z8liAY+RZ--