Received-SPF: pass (google.com: domain of linux-kernel+bounces-174252-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Date: Thu, 9 May 2024 08:48:09 +0100
From: Conor Dooley <conor.dooley@microchip.com>
To: Andy Chiu <andy.chiu@sifive.com>
CC: Conor Dooley <conor@kernel.org>, Eric Biggers <ebiggers@kernel.org>, Paul
 Walmsley <paul.walmsley@sifive.com>, Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>, Heiko Stuebner <heiko@sntech.de>, Guo Ren
	<guoren@kernel.org>, Rob Herring <robh@kernel.org>, Krzysztof Kozlowski
	<krzysztof.kozlowski+dt@linaro.org>, Jonathan Corbet <corbet@lwn.net>, Evan
 Green <evan@rivosinc.com>, =?iso-8859-1?Q?Cl=E9ment_L=E9ger?=
	<cleger@rivosinc.com>, Shuah Khan <shuah@kernel.org>,
	<linux-riscv@lists.infradead.org>, <linux-kernel@vger.kernel.org>, Palmer
 Dabbelt <palmer@rivosinc.com>, Vincent Chen <vincent.chen@sifive.com>,
	Greentime Hu <greentime.hu@sifive.com>, <devicetree@vger.kernel.org>,
	<linux-doc@vger.kernel.org>, <linux-kselftest@vger.kernel.org>, Joel Granados
	<j.granados@samsung.com>, Jerry Shih <jerry.shih@sifive.com>
Subject: Re: [PATCH v4 7/9] riscv: vector: adjust minimum Vector requirement
 to ZVE32X
Message-ID: <20240509-mandatory-monsieur-dfa4d7881fa9@wendy>
References: <20240412-zve-detection-v4-0-e0c45bb6b253@sifive.com>
 <20240412-zve-detection-v4-7-e0c45bb6b253@sifive.com>
 <20240418-brook-chili-4d3e61d1a55c@wendy>
 <20240418155256.GA2410@sol.localdomain>
 <20240418-ultimatum-yam-11de4b063b83@spud>
 <20240418173203.GA1081@sol.localdomain>
 <20240418173946.GB1081@sol.localdomain>
 <20240418-sterling-sanding-d59c3b0a2aaa@spud>
 <CABgGipU74TA3KgCH4pPuRefbnYt3q6RKcQwfyspenisEtY6eqw@mail.gmail.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="ILfmNxMoEmQr18uK"
Content-Disposition: inline
In-Reply-To: <CABgGipU74TA3KgCH4pPuRefbnYt3q6RKcQwfyspenisEtY6eqw@mail.gmail.com>

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

On Thu, May 09, 2024 at 02:56:30PM +0800, Andy Chiu wrote:
> Hi Conor,
>=20
> Should we check if "v" presents for vector crypto extensions in
> riscv_isa_extension_check()? We are not checking this for now. So a
> kernel compiled with RISCV_ISA_V still has a problem if its isa-string
> includes any of vector crypto ("zvbb, zvkg, etc") but not "v".


Yeah, one of the things I took away from this discussion is that we need
to improve the implementation of both the methods we have at the moment
for drivers etc to check if extensions are present and usable.
In general, I don't think checks like that are "safe" to do in
riscv_isa_extension_check(), because the dependencies may not all have
been resolved when we probe an extension (Clement's current Zca etc
series improves the situation though by only calling the checks after
we probe all extensions).

The simple V cases are all fine though - the DT binding and ACPI rules
for compatible strings all mandate that single-letter extensions must
come before multi-letter ones. For riscv,isa-extensions we control the
probe ordering and probe V before any multi-letter stuff. Additionally,
we should make it a requirement for V to be present if things that
depend on it are.

That said, is it permitted by the specs to have any of the extensions
you mention without the full V extension, but with one of the cut-down
variants you mention here? If not, I'd be more interested in figuring
out the non-extension dependencies: whether or not the kernel itself
supports vector and if the kernel has opted to disable vector due to
detecting that harts have mismatching vector lengths.

TL;DR: I think we should add some checks in riscv_isa_extension_check().

Thanks,
Conor.


--ILfmNxMoEmQr18uK
Content-Type: application/pgp-signature; name="signature.asc"

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

iHUEABYIAB0WIQRh246EGq/8RLhDjO14tDGHoIJi0gUCZjx/qQAKCRB4tDGHoIJi
0nmVAP9L+cHjupn5RAFkHpZYc5Cnnq2E5GdciRokz+M5dfaZiwEA9ymnxi2cQa7X
f5iK/7u9QwmQNblOabpPI5z1wq28rAo=
=dW2A
-----END PGP SIGNATURE-----

--ILfmNxMoEmQr18uK--