On Mon, 2018-02-05 at 08:45 +0000, Horia Geantă wrote:
> On 2/2/2018 2:54 PM, Auer, Lukas wrote:
> > On Fri, 2018-02-02 at 11:20 +0000, Bryan O'Donoghue wrote:
> > > On 01/02/18 12:16, Horia Geantă wrote:
> > > > If the loop cannot exit based on value of "ret" != -EAGAIN,
> > > > then it
> > > > means
> > > > caam_probe() will eventually fail due to ret == -EAGAIN:
> > > > if (ret) {
> > > > dev_err(dev, "failed to instantiate RNG");
> > > > goto caam_remove;
> > > > }
> > >
> > > For me it's an endless loop applying the first two
> > >
> > > https://patchwork.ozlabs.org/patch/866460/
> > > https://patchwork.ozlabs.org/patch/866462/
> > >
> > > but not this one
> > >
> > > https://patchwork.ozlabs.org/patch/865890/
> > >
>
> [snip]
> >
> > I think the problem lies in the instantiate_rng() function. If the
> > driver is unable to acquire DEC0 it'll return -ENODEV. This should
> > terminate the while loop in the probe function. However, the return
> > value is never checked and is instead overwritten with -EAGAIN,
> > causing
> > the endless loop.
> >
> > This problem only occurs if u-boot instantiates only one of the
> > state
> > handles (ent_delay doesn't get incremented) and the kernel runs in
> > non-
> > secure mode (DEC0 can't get acquired). Instantiating all state
> > handles
> > in u-boot therefore fixes this problem. In addition, the return
> > value
> > in instantiate_rng() should be handled correctly by including
> >
> > if (ret)
> > break;
> >
> > right after "ret = run_descriptor_deco0(ctrldev, desc, &status);".
> >
>
> Indeed, the error path is incorrect and should be fixed as you
> mentioned.
> I will send a patch replacing this one.
> Note that this fixes only the error path, meaning caam_probe() won't
> go into an
> endless loop and instead will return -ENODEV, due to being unable to
> acquire
> control of DECO0.
>
> There are still a few hurdles to cross for CAAM to work in a TZ
> environment.
>
> For e.g. could you please check / confirm whether DECO0MIDR (DECO0
> MID registers
> @0xA0, @0xA4) are set such that Linux kernel is allowed to r/w DECO0-
> related
> registers?
>
> Thanks,
> Horia
On my board DECO0 MID ms is set to 0x8001, which I believe (going by
the structure of the other MID registers, since some of the bits are
only marked as reserved) is a MID of 1 (A7 cores) in secure mode.
Changing this to 0x9 for a MID of 1 in non-secure mode still fails the
DEC0 acquisition step in the probe call.
So unfortunately I am not sure what / if other steps are required to
use the CAAM in non-secure mode. Running a quick test with openssl
speed (using CAAM with cryptodev), it at least seems to be working.
Thanks,
Lukas
