Re: [EXT] [PATCH v9 3/7] crypto: caam - determine whether CAAM supports blob encap/decap

[Michael Walle]

Am 2022-05-11 12:28, schrieb Horia Geantă:

> > > > > For non-E variants, it might happen that Blob protocol is enabled,
> > > > > but
> > > > > number of AES CHA are zero.
> > > > > If the output of below expression is > 0, then only blob_present
> > > > > should be marked present or true.
> > > > > For era > 10, you handled. But for era < 10, please add the below
> > > > > code.
> > > >
> > > > Are there any CAAMs which can be just enabled partially for era < 
> > > > 10?
> > > > I didn't found anything. To me it looks like the non-export 
> > > > controlled
> > > > CAAM is only available for era >= 10. For era < 10, the CAAM is 
> > > > either
> > > > fully featured there or it is not available at all and thus the node
> > > > is removed in the bootloader (at least that is the case for
> > > > layerscape).
> > > Qouting from our previous discussion in U-boot:
> > > https://patchwork.ozlabs.org/project/uboot/patch/20200602150904.1997-1-michael@xxxxxxxx/#2457448
> > >
> > > "
> > > Based on previous (NXP-internal) discussions, non-E crypto module is:
> > > -fully disabled on: LS1021A (ARMv7), LS1043A, LS1088A, LS2088A
> > > (and their personalities)
> > > -partially [*] disabled on: LS1012A, LS1028A, LS1046A, LX2160A
> > > (and their personalities)
> > > "
> > >
> > > From the partially disabled list, LS1028A and LX2160A have CAAM Era 
> > > 10,
> > > while LS1012A and LS1046A integrate CAAM Era 8.
> >
> > Thanks for clarification. Do you know it that is a layerscape feature?
> > I had a look at the imx8mn which have a era 9 and it doesn't have the
> > PKHA_VERSION register which indicates the partially disabled PKHA
> > block. Thus I concluded that there is no partially disabled feature
> > on era < 10.
> Unfortunately when moving from Era 9 to Era 10, the register map
> is not 100% backwards-compatible.
> This is why you're not seeing PKHA_VERSION register for i.MX8MN.
>
> For Era >= 10, the CHA version and CHA number fields are conveniently 
> found
> found in the same *_VERSION register, e.g. PKHA_VID and PKHA_NUM are 
> both
> located in PKHA_VERSION.
>
> For Era < 10, these fields are scattered:
> CHAVID_LS[PKVID]
> CHANUM_LS[PKNUM]

Ok, but there is only the number of instances. I couldn't find a
similar bit to the PKHA_VERSION[PKHA_MISC[7]] bit, which indicates
PKHA decryption/encryption capability is disabled. That seems to
be only for era >= 10, right? That was what caused my confusion,
because until now I was under the impression that non-E variants
will always have that bit.

Rereading your comment, you don't mention PKHA at all. So for
era <10 if you blow the EXPORT_CONTROL fuse, you'll have zero
in any *NUM except for MDNUM, RNGNUM and CRCNUM. Is that correct?

In that case, I agree, we should also check CHANUM_LS[AESNUM] for
era < 10.

-michael