Re: [PATCH 3/3] arm64: dts: renesas: r8a7795: add ccree binding

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Gilad,

On Thu, May 17, 2018 at 3:41 PM, Gilad Ben-Yossef <gilad@xxxxxxxxxxxxx> wrote:
> On Thu, May 17, 2018 at 4:35 PM, Geert Uytterhoeven
> <geert@xxxxxxxxxxxxxx> wrote:
>> On Thu, May 17, 2018 at 3:09 PM, Gilad Ben-Yossef <gilad@xxxxxxxxxxxxx> wrote:
>>> On Thu, May 17, 2018 at 1:16 PM, Geert Uytterhoeven
>>> <geert@xxxxxxxxxxxxxx> wrote:
>>>> However, even with your clock patch, the signature checking fails for me,
>>>> on both R-Car H3 ES1.0 and ES2.0.
>>>> Does this need changes to the ARM Trusted Firmware, to allow Linux to
>>>> access the public SCEG module?
>>>
>>> Well, this is actually something different. If you look you will
>>> notice that my patch was part of a 3 part patch series,
>>> the first of which disabled this test.
>>
>> Sorry, I had completely forgotten about the first patch from the series.
>> With that applied, it continues:
>>
>>         ccree e6601000.crypto: ARM CryptoCell 630P Driver: HW version
>> 0x00000000, Driver version 4.0
>>         ccree e6601000.crypto: Cache params previous: 0x00000777
>>         ccree e6601000.crypto: Cache params current: 0x00000000
>> (expect: 0x00000000)
>>         alg: No test for cts1(cbc(aes)) (cts1-cbc-aes-ccree)
>>         alg: No test for authenc(xcbc(aes),cbc(aes))
>> (authenc-xcbc-aes-cbc-aes-ccree)
>>         alg: No test for authenc(xcbc(aes),rfc3686(ctr(aes)))
>> (authenc-xcbc-aes-rfc3686-ctr-aes-ccree)
>>         ccree e6601000.crypto: ARM ccree device initialized
>>
>> Is HW version 0x00000000 expected?
>
> It's related to the problem with reading the wrong register I've
> mentioned before.

OK.

>>> If you take all the 3 patches, it will work.
>>
>> is there an easy way to test proper operation?
>
> The lines of the form "  alg: No test for cts1(cbc(aes))
> (cts1-cbc-aes-ccree)" indicates
> you have the Crypto API testmgr enable (or rather not disabled would
> be more accurate) so every
> cryptographic algorithm except those specified in these messages was
> tested with test
> vectors from crypto/testmgr.c upon registration. If you don't seen
> failure warnings, it works.

OK.

> You can also check /proc/crypto for all the algorithm with ccree
> listed as their driver and check
> that their test passed.

OK, in that case everything works as expected, on both R-Car H3 ES1.0 and
ES2.0.

Thanks!

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux