[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20231128201228.GE1148@sol.localdomain>
Date: Tue, 28 Nov 2023 12:12:28 -0800
From: Eric Biggers <ebiggers@...nel.org>
To: Conor Dooley <conor@...nel.org>
Cc: Jerry Shih <jerry.shih@...ive.com>, paul.walmsley@...ive.com,
palmer@...belt.com, aou@...s.berkeley.edu,
herbert@...dor.apana.org.au, davem@...emloft.net,
conor.dooley@...rochip.com, ardb@...nel.org, heiko@...ech.de,
phoebe.chen@...ive.com, hongrong.hsu@...ive.com,
linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org,
linux-crypto@...r.kernel.org
Subject: Re: [PATCH v2 04/13] RISC-V: crypto: add Zvkned accelerated AES
implementation
On Tue, Nov 28, 2023 at 05:54:49PM +0000, Conor Dooley wrote:
> > +static inline bool check_aes_ext(void)
> > +{
> > + return riscv_isa_extension_available(NULL, ZVKNED) &&
> > + riscv_vector_vlen() >= 128;
> > +}
>
> I'm not keen on this construct, where you are checking vlen greater than
> 128 and the presence of Zvkned without checking for the presence of V
> itself. Can you use "has_vector()" in any places where you depend on the
> presence of vector please?
Shouldn't both of those things imply vector support already?
> Also, there are potentially a lot of places in this drivers where you
> can replace "riscv_isa_extension_available()" with
> "riscv_has_extension_likely()". The latter is optimised with
> alternatives, so in places that are going to be evaluated frequently it
> may be beneficial for you.
These extension checks are only executed in module_init functions, so they're
not performance critical.
- Eric
Powered by blists - more mailing lists