Hi,
> From: Horia Geanta <horia.gea...@nxp.com>
> Sent: Friday, April 11, 2025 2:29 PM
>
> 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.
>
I have sent a new patch with a hotfix for that: "[PATCH] crypto: fsl - Add
cache flush after job descriptor swap".
I could only test on LS1046A though, please review if I missed something.
BR,
Pawel.
> Regards,
> Horia
