On 7/9/2022 4:48 pm, Antoine Tenart wrote:
> Quoting Peter Harliman Liem (2022-09-07 08:46:32)
>> On 6/9/2022 10:05 pm, Antoine Tenart wrote:
>>>> CRYPTO_AES is needed for aes-related algo (e.g.
>>>> safexcel-gcm-aes, safexcel-xcbc-aes, safexcel-cmac-aes).
>>>> Without it, we observe failures when allocating transform
>>>> for those algo.
>>>>
>>>> Fixes: 363a90c2d517 ("crypto: safexcel/aes - switch to library version of key expansion routine")
>>>
>>> The above commit explicitly switched crypto drivers to use the AES
>>> library instead of the generic AES cipher one, which seems like a good
>>> move. What are the issues you're encountering and why the AES lib makes
>>> the driver to fail?
>>
>> If I load the kernel module (CONFIG_CRYPTO_MANAGER_DISABLE_TESTS is not
>> set), I am getting failure messages below.
>> IMHO this happens because some functions in the driver still rely on
>> generic AES cipher (e.g. refer to safexcel_aead_gcm_cra_init() or
>> safexcel_xcbcmac_cra_init()), therefore CONFIG_CRYPTO_AES is still needed.
>
> That's possible, and the right fix might be what you proposed. I think
> it would be nice to understand what is failing and where, so we have a
> good argument for restoring the AES dependency (or not).
>
>> Maybe the alternative is to switch all of them to use AES lib instead?
>> Let me know if you prefer this.
>
> If the AES lib can be used instead of the AES generic implementation
> that would be great yes. If that's possible, depending on what is
> actually failing, yes please go for this solution. Otherwise restoring
> the AES dependency with a good explanation should work.
I have replaced this commit in v3 with the change to AES lib instead.
Thanks!
