On 4/9/2025 7:46 PM, Horia Geanta wrote:
> On 4/9/2025 9:19 AM, Gaurav Jain wrote:
>> Hi Pawel
>>
>>> From: Paweł Kochanowski <pkochanow...@sii.pl>
>>>
>> 5. The loop in
>>> caam_rng_read is called second time, this time the `priv->desc` contain
>>> swapped
>>> data.
>>>
>>> Interesting thing is that the job still succeeds and that some data are
>>> present in
>>> the buffers, but maybe swapped descriptor can also be a valid one?
>> I agree that the descriptor should be reinitialized for each RNG job.
> I would advise against this, considering what I said above.
> Handling endianness should be done only once.
>
Btw, looks like there's another issue.
jr_enqueue() (drivers/crypto/fsl/jr.c) is touching the descriptor:
for (i = 0; i < length; i++) {
desc_word = desc_addr[i];
sec_out32((uint32_t *)&desc_addr[i], desc_word);
}
however there's no cache flush after that.
This would affect platforms where CAAM is not HW-coherent.
LS1046A has a coherent CAAM, so we're not hitting the bug in this case.
Regards,
Horia
