From mboxrd@z Thu Jan 1 00:00:00 1970 From: Geert Uytterhoeven Subject: Re: [PATCH 3/3] arm64: dts: renesas: r8a7795: add ccree binding Date: Thu, 17 May 2018 15:49:52 +0200 Message-ID: References: <1526387370-17142-1-git-send-email-gilad@benyossef.com> <1526387370-17142-4-git-send-email-gilad@benyossef.com> <20180516074333.i2672u435ymwffk3@verge.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Cc: Simon Horman , Magnus Damm , Rob Herring , Mark Rutland , Catalin Marinas , Will Deacon , Geert Uytterhoeven , Michael Turquette , Stephen Boyd , Herbert Xu , "David S. Miller" , Ofir Drang , Linux-Renesas , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Linux ARM , Linux Kernel Mailing List , linux-clk , L To: Gilad Ben-Yossef Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-crypto.vger.kernel.org Hi Gilad, On Thu, May 17, 2018 at 3:41 PM, Gilad Ben-Yossef wrote: > On Thu, May 17, 2018 at 4:35 PM, Geert Uytterhoeven > wrote: >> On Thu, May 17, 2018 at 3:09 PM, Gilad Ben-Yossef wrote: >>> On Thu, May 17, 2018 at 1:16 PM, Geert Uytterhoeven >>> 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@linux-m68k.org 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752171AbeEQNt6 (ORCPT ); Thu, 17 May 2018 09:49:58 -0400 Received: from mail-vk0-f66.google.com ([209.85.213.66]:42852 "EHLO mail-vk0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751017AbeEQNty (ORCPT ); Thu, 17 May 2018 09:49:54 -0400 X-Google-Smtp-Source: AB8JxZoIB+KfMmzuhSif2UuUX1VHdflAPYEUuFy4b5W7t6kiZSTL1yCqUxEqA4DZtPiPFxiVcNA1LAPdVUUMgBVJv5g= MIME-Version: 1.0 In-Reply-To: References: <1526387370-17142-1-git-send-email-gilad@benyossef.com> <1526387370-17142-4-git-send-email-gilad@benyossef.com> <20180516074333.i2672u435ymwffk3@verge.net.au> From: Geert Uytterhoeven Date: Thu, 17 May 2018 15:49:52 +0200 X-Google-Sender-Auth: L30zOuMJk6RV8X2hBTg1xlldfM4 Message-ID: Subject: Re: [PATCH 3/3] arm64: dts: renesas: r8a7795: add ccree binding To: Gilad Ben-Yossef Cc: Simon Horman , Magnus Damm , Rob Herring , Mark Rutland , Catalin Marinas , Will Deacon , Geert Uytterhoeven , Michael Turquette , Stephen Boyd , Herbert Xu , "David S. Miller" , Ofir Drang , Linux-Renesas , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Linux ARM , Linux Kernel Mailing List , linux-clk , Linux Crypto Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Gilad, On Thu, May 17, 2018 at 3:41 PM, Gilad Ben-Yossef wrote: > On Thu, May 17, 2018 at 4:35 PM, Geert Uytterhoeven > wrote: >> On Thu, May 17, 2018 at 3:09 PM, Gilad Ben-Yossef wrote: >>> On Thu, May 17, 2018 at 1:16 PM, Geert Uytterhoeven >>> 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@linux-m68k.org 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Geert Uytterhoeven Subject: Re: [PATCH 3/3] arm64: dts: renesas: r8a7795: add ccree binding Date: Thu, 17 May 2018 15:49:52 +0200 Message-ID: References: <1526387370-17142-1-git-send-email-gilad@benyossef.com> <1526387370-17142-4-git-send-email-gilad@benyossef.com> <20180516074333.i2672u435ymwffk3@verge.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Gilad Ben-Yossef Cc: Simon Horman , Magnus Damm , Rob Herring , Mark Rutland , Catalin Marinas , Will Deacon , Geert Uytterhoeven , Michael Turquette , Stephen Boyd , Herbert Xu , "David S. Miller" , Ofir Drang , Linux-Renesas , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Linux ARM , Linux Kernel Mailing List , linux-clk L List-Id: devicetree@vger.kernel.org Hi Gilad, On Thu, May 17, 2018 at 3:41 PM, Gilad Ben-Yossef wrote: > On Thu, May 17, 2018 at 4:35 PM, Geert Uytterhoeven > wrote: >> On Thu, May 17, 2018 at 3:09 PM, Gilad Ben-Yossef wrote: >>> On Thu, May 17, 2018 at 1:16 PM, Geert Uytterhoeven >>> 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@linux-m68k.org 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: geert@linux-m68k.org (Geert Uytterhoeven) Date: Thu, 17 May 2018 15:49:52 +0200 Subject: [PATCH 3/3] arm64: dts: renesas: r8a7795: add ccree binding In-Reply-To: References: <1526387370-17142-1-git-send-email-gilad@benyossef.com> <1526387370-17142-4-git-send-email-gilad@benyossef.com> <20180516074333.i2672u435ymwffk3@verge.net.au> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Gilad, On Thu, May 17, 2018 at 3:41 PM, Gilad Ben-Yossef wrote: > On Thu, May 17, 2018 at 4:35 PM, Geert Uytterhoeven > wrote: >> On Thu, May 17, 2018 at 3:09 PM, Gilad Ben-Yossef wrote: >>> On Thu, May 17, 2018 at 1:16 PM, Geert Uytterhoeven >>> 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 at linux-m68k.org 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