Re: [PATCH 0/3] Add support for qcrypto on shikra

[Bartosz Golaszewski]

On Thu, May 28, 2026 at 7:52 PM Eric Biggers <ebiggers@xxxxxxxxxx> wrote:
>
> On Thu, May 28, 2026 at 11:13:47AM -0400, Bartosz Golaszewski wrote:
> > On Thu, 28 May 2026 15:50:10 +0200, Dmitry Baryshkov
> > <dmitry.baryshkov@xxxxxxxxxxxxxxxx> said:
> > > On Thu, May 28, 2026 at 09:13:23AM -0400, Bartosz Golaszewski wrote:
> > >> On Thu, 28 May 2026 13:54:51 +0200, Kuldeep Singh
> > >> <kuldeep.singh@xxxxxxxxxxxxxxxx> said:
> > >> >>> +Bartosz, Gaurav, Neeraj
> > >>
> > >> I know about the self-tests etc., I will address them next.
> > >
> > > My 2c, the self-tests would be more important, as they are fixes. Doing
> > > the crypto in a wrong way is a bad idea...
> > >
> >
> > Then let that be "in parallel". :)
>
> The race conditions between Linux and other environments (modem, TEE,
> etc) are of course about correctness as well, even though the self-tests
> don't expose race condition bugs.  The self-tests have always just done
> a few serialized tests.  That's sufficient for CPU-based code, but not
> for offload drivers, which need to be stress-tested to find the
> concurrency bugs that occur during actual use.
>
> Is there a plan to improve the tests to do stress testing as well?
>

I'm not sure if we can easily implement linux-only tests using
multiple execution environments. I will look into it and come back
with an answer.

> It's kind of odd that they don't do that yet.  But it makes sense: the
> CPU-based code doesn't need it, while the offload driver authors have
> never cared enough about correctness and test coverage to add it.
>
> I still don't really see a path forward here, given the track record and
> poor performance numbers.  This approach just doesn't work.
>

Sorry but I'm not sure what your point is. What this series does is:
it documents the compatible for the crypto engine that very much *does
exist* on the SoC and describes how it's wired up as a real HW
component in devicetree. Whatever the state of the driver is, it's not
grounds for NAKing HW description. The IP *is* there, we're allowed to
describe it in DTS.

Qualcomm wants to use this IP and I will keep on improving it. I think
that - given the BAM locking series is at v19 now and has been
initially posted in 2023 - I've a proven track record of not
abandoning it. :)

I'm away next week but will look into self-tests the week after. This
series - once fixed - should go upstream independently.

Bart