On Tue, Sep 10, 2019 at 12:50:04PM +0000, Pascal Van Leeuwen wrote: > > I'm allocating a fallback (AEAD) cipher to handle some corner cases > my HW cannot handle, but I noticed that the fallback itself is being > tested when I allocate it (or so it seems) and if the fallback itself > fails on some testvector, it is not replaced by an alternative while > such an alternative should be available. So I have to fail my entire > init because the fallback could not be allocated. This has nothing to do with fallbacks and it's just how template instantiation works. If the instantiation fails it will not try to construct another one. The point is that if your algorithm works then it should not fail the instantiation self-test. And if it does fail then it's a bug in the algorithm, not the API. > i.e. while requesting a fallback for rfc7539(chacha20, poly1305), it > attempts rfc7539(safexcel-chacha20,poly1305-simd), which fails, but > it could still fall back to e.g. rfc7539(chacha20-simd, poly1305-simd), > which should work. > > Actually, I really do not want the fallback to hit another algorithm > of my own driver. Is there some way to prevent that from happening? > (without actually referencing hard cra_driver_name's ...) I think if safexcel-chacha20 causes a failure when used with rfc7539 then it should just be fixed, or unexported. Cheers, -- Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
