Arm TrustZone CryptoCell 700 is a family of cryptographic hardware
accelerators. It is supported by a long lived series of out of tree
drivers, which I am now in the process of unifying and upstreaming.
This is the first drop, supporting the new CryptoCell 712 REE.
The code still needs some cleanup before maturing to a proper
upstream driver, which I am in the process of doing. However,
as discussion of some of the capabilities of the hardware and
its application to some dm-crypt and dm-verity features recently
took place I though it is better to do this in the open via the
staging tree.
A Git repository based off of Linux 4.11-rc7 is available at
https://github.com/gby/linux.git branch ccree.
Signed-off-by: Gilad Ben-Yossef <gilad-6S/[email protected]>
CC: Binoy Jayan <[email protected]>
CC: Ofir Drang <[email protected]>
Gilad Ben-Yossef (4):
staging: add ccree crypto driver
staging: ccree: add TODO list
staging: ccree: add devicetree bindings
MAINTAINERS: add Gilad BY as maintainer for ccree
.../devicetree/bindings/crypto/arm-cryptocell.txt | 23 +
MAINTAINERS | 8 +
drivers/staging/Kconfig | 2 +
drivers/staging/Makefile | 2 +-
drivers/staging/ccree/Kconfig | 52 +
drivers/staging/ccree/Makefile | 3 +
drivers/staging/ccree/TODO | 27 +
drivers/staging/ccree/bsp.h | 21 +
drivers/staging/ccree/cc_bitops.h | 62 +
drivers/staging/ccree/cc_crypto_ctx.h | 299 +++
drivers/staging/ccree/cc_hal.h | 35 +
drivers/staging/ccree/cc_hw_queue_defs.h | 603 +++++
drivers/staging/ccree/cc_lli_defs.h | 57 +
drivers/staging/ccree/cc_pal_log.h | 188 ++
drivers/staging/ccree/cc_pal_log_plat.h | 33 +
drivers/staging/ccree/cc_pal_types.h | 97 +
drivers/staging/ccree/cc_pal_types_plat.h | 29 +
drivers/staging/ccree/cc_regs.h | 106 +
drivers/staging/ccree/dx_crys_kernel.h | 180 ++
drivers/staging/ccree/dx_env.h | 224 ++
drivers/staging/ccree/dx_host.h | 155 ++
drivers/staging/ccree/dx_reg_base_host.h | 34 +
drivers/staging/ccree/dx_reg_common.h | 26 +
drivers/staging/ccree/hash_defs.h | 78 +
drivers/staging/ccree/hw_queue_defs_plat.h | 43 +
drivers/staging/ccree/ssi_aead.c | 2832 ++++++++++++++++++++
drivers/staging/ccree/ssi_aead.h | 120 +
drivers/staging/ccree/ssi_buffer_mgr.c | 1876 +++++++++++++
drivers/staging/ccree/ssi_buffer_mgr.h | 105 +
drivers/staging/ccree/ssi_cipher.c | 1503 +++++++++++
drivers/staging/ccree/ssi_cipher.h | 89 +
drivers/staging/ccree/ssi_config.h | 61 +
drivers/staging/ccree/ssi_driver.c | 557 ++++
drivers/staging/ccree/ssi_driver.h | 228 ++
drivers/staging/ccree/ssi_fips.c | 65 +
drivers/staging/ccree/ssi_fips.h | 70 +
drivers/staging/ccree/ssi_fips_data.h | 315 +++
drivers/staging/ccree/ssi_fips_ext.c | 96 +
drivers/staging/ccree/ssi_fips_ll.c | 1681 ++++++++++++
drivers/staging/ccree/ssi_fips_local.c | 369 +++
drivers/staging/ccree/ssi_fips_local.h | 77 +
drivers/staging/ccree/ssi_hash.c | 2751 +++++++++++++++++++
drivers/staging/ccree/ssi_hash.h | 101 +
drivers/staging/ccree/ssi_ivgen.c | 301 +++
drivers/staging/ccree/ssi_ivgen.h | 72 +
drivers/staging/ccree/ssi_pm.c | 150 ++
drivers/staging/ccree/ssi_pm.h | 46 +
drivers/staging/ccree/ssi_pm_ext.c | 60 +
drivers/staging/ccree/ssi_pm_ext.h | 33 +
drivers/staging/ccree/ssi_request_mgr.c | 713 +++++
drivers/staging/ccree/ssi_request_mgr.h | 60 +
drivers/staging/ccree/ssi_sram_mgr.c | 138 +
drivers/staging/ccree/ssi_sram_mgr.h | 80 +
drivers/staging/ccree/ssi_sysfs.c | 440 +++
drivers/staging/ccree/ssi_sysfs.h | 54 +
55 files changed, 17429 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/crypto/arm-cryptocell.txt
create mode 100644 drivers/staging/ccree/Kconfig
create mode 100644 drivers/staging/ccree/Makefile
create mode 100644 drivers/staging/ccree/TODO
create mode 100644 drivers/staging/ccree/bsp.h
create mode 100644 drivers/staging/ccree/cc_bitops.h
create mode 100644 drivers/staging/ccree/cc_crypto_ctx.h
create mode 100644 drivers/staging/ccree/cc_hal.h
create mode 100644 drivers/staging/ccree/cc_hw_queue_defs.h
create mode 100644 drivers/staging/ccree/cc_lli_defs.h
create mode 100644 drivers/staging/ccree/cc_pal_log.h
create mode 100644 drivers/staging/ccree/cc_pal_log_plat.h
create mode 100644 drivers/staging/ccree/cc_pal_types.h
create mode 100644 drivers/staging/ccree/cc_pal_types_plat.h
create mode 100644 drivers/staging/ccree/cc_regs.h
create mode 100644 drivers/staging/ccree/dx_crys_kernel.h
create mode 100644 drivers/staging/ccree/dx_env.h
create mode 100644 drivers/staging/ccree/dx_host.h
create mode 100644 drivers/staging/ccree/dx_reg_base_host.h
create mode 100644 drivers/staging/ccree/dx_reg_common.h
create mode 100644 drivers/staging/ccree/hash_defs.h
create mode 100644 drivers/staging/ccree/hw_queue_defs_plat.h
create mode 100644 drivers/staging/ccree/ssi_aead.c
create mode 100644 drivers/staging/ccree/ssi_aead.h
create mode 100644 drivers/staging/ccree/ssi_buffer_mgr.c
create mode 100644 drivers/staging/ccree/ssi_buffer_mgr.h
create mode 100644 drivers/staging/ccree/ssi_cipher.c
create mode 100644 drivers/staging/ccree/ssi_cipher.h
create mode 100644 drivers/staging/ccree/ssi_config.h
create mode 100644 drivers/staging/ccree/ssi_driver.c
create mode 100644 drivers/staging/ccree/ssi_driver.h
create mode 100644 drivers/staging/ccree/ssi_fips.c
create mode 100644 drivers/staging/ccree/ssi_fips.h
create mode 100644 drivers/staging/ccree/ssi_fips_data.h
create mode 100644 drivers/staging/ccree/ssi_fips_ext.c
create mode 100644 drivers/staging/ccree/ssi_fips_ll.c
create mode 100644 drivers/staging/ccree/ssi_fips_local.c
create mode 100644 drivers/staging/ccree/ssi_fips_local.h
create mode 100644 drivers/staging/ccree/ssi_hash.c
create mode 100644 drivers/staging/ccree/ssi_hash.h
create mode 100644 drivers/staging/ccree/ssi_ivgen.c
create mode 100644 drivers/staging/ccree/ssi_ivgen.h
create mode 100644 drivers/staging/ccree/ssi_pm.c
create mode 100644 drivers/staging/ccree/ssi_pm.h
create mode 100644 drivers/staging/ccree/ssi_pm_ext.c
create mode 100644 drivers/staging/ccree/ssi_pm_ext.h
create mode 100644 drivers/staging/ccree/ssi_request_mgr.c
create mode 100644 drivers/staging/ccree/ssi_request_mgr.h
create mode 100644 drivers/staging/ccree/ssi_sram_mgr.c
create mode 100644 drivers/staging/ccree/ssi_sram_mgr.h
create mode 100644 drivers/staging/ccree/ssi_sysfs.c
create mode 100644 drivers/staging/ccree/ssi_sysfs.h
--
2.1.4
Hi,
On Tue, Apr 18, 2017 at 05:07:50PM +0300, Gilad Ben-Yossef wrote:
> Arm TrustZone CryptoCell 700 is a family of cryptographic hardware
> accelerators. It is supported by a long lived series of out of tree
> drivers, which I am now in the process of unifying and upstreaming.
> This is the first drop, supporting the new CryptoCell 712 REE.
>
> The code still needs some cleanup before maturing to a proper
> upstream driver, which I am in the process of doing. However,
> as discussion of some of the capabilities of the hardware and
> its application to some dm-crypt and dm-verity features recently
> took place I though it is better to do this in the open via the
> staging tree.
>
> A Git repository based off of Linux 4.11-rc7 is available at
> https://github.com/gby/linux.git branch ccree.
>
> Signed-off-by: Gilad Ben-Yossef <[email protected]>
> CC: Binoy Jayan <[email protected]>
> CC: Ofir Drang <[email protected]>
>
> Gilad Ben-Yossef (4):
> staging: add ccree crypto driver
> staging: ccree: add TODO list
> staging: ccree: add devicetree bindings
> MAINTAINERS: add Gilad BY as maintainer for ccree
>
> .../devicetree/bindings/crypto/arm-cryptocell.txt | 23 +
I'm interested in looking at the DT binding, but for some reason I've
only recevied the cover letter so far.
Are my mail servers being particularly slow today, or has something gone
wrong with the Cc list for the remaining patches?
Thanks,
Mark.
Hi Mark,
On Tue, Apr 18, 2017 at 6:13 PM, Mark Rutland <[email protected]> wrote:
> Hi,
>
> On Tue, Apr 18, 2017 at 05:07:50PM +0300, Gilad Ben-Yossef wrote:
>> Arm TrustZone CryptoCell 700 is a family of cryptographic hardware
>> accelerators. It is supported by a long lived series of out of tree
>> drivers, which I am now in the process of unifying and upstreaming.
>> This is the first drop, supporting the new CryptoCell 712 REE.
>>
>> The code still needs some cleanup before maturing to a proper
>> upstream driver, which I am in the process of doing. However,
>> as discussion of some of the capabilities of the hardware and
>> its application to some dm-crypt and dm-verity features recently
>> took place I though it is better to do this in the open via the
>> staging tree.
>>
>> A Git repository based off of Linux 4.11-rc7 is available at
>> https://github.com/gby/linux.git branch ccree.
>>
>> Signed-off-by: Gilad Ben-Yossef <gilad-6S/[email protected]>
>> CC: Binoy Jayan <[email protected]>
>> CC: Ofir Drang <[email protected]>
>>
>> Gilad Ben-Yossef (4):
>> staging: add ccree crypto driver
>> staging: ccree: add TODO list
>> staging: ccree: add devicetree bindings
>> MAINTAINERS: add Gilad BY as maintainer for ccree
>>
>> .../devicetree/bindings/crypto/arm-cryptocell.txt | 23 +
>
> I'm interested in looking at the DT binding, but for some reason I've
> only recevied the cover letter so far.
>
> Are my mail servers being particularly slow today, or has something gone
> wrong with the Cc list for the remaining patches?
>
Thanks a bunch for the willingness to review this.
My apologies for not communicating this clearly enough - Since it is
an pre-existing driver it is rather big.
I did not want to inflict a 600K patch on the mailing list so opted to
provide a git repo instead, as stated in the
email.
The patch in question is here:
https://github.com/gby/linux/commit/12d92e0bc19aa9bbd891cdab765eaaeabe0b6967
Do let me know if you prefer that I will send at least the smaller
patch file via email in the normal fashion.
Many thanks,
Gilad
--
Gilad Ben-Yossef
Chief Coffee Drinker
"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
-- Jean-Baptiste Queru
On Tue, Apr 18, 2017 at 05:07:50PM +0300, Gilad Ben-Yossef wrote:
> Arm TrustZone CryptoCell 700 is a family of cryptographic hardware
> accelerators. It is supported by a long lived series of out of tree
> drivers, which I am now in the process of unifying and upstreaming.
> This is the first drop, supporting the new CryptoCell 712 REE.
>
> The code still needs some cleanup before maturing to a proper
> upstream driver, which I am in the process of doing. However,
> as discussion of some of the capabilities of the hardware and
> its application to some dm-crypt and dm-verity features recently
> took place I though it is better to do this in the open via the
> staging tree.
>
> A Git repository based off of Linux 4.11-rc7 is available at
> https://github.com/gby/linux.git branch ccree.
>
> Signed-off-by: Gilad Ben-Yossef <gilad-6S/[email protected]>
> CC: Binoy Jayan <[email protected]>
> CC: Ofir Drang <[email protected]>
>
> Gilad Ben-Yossef (4):
> staging: add ccree crypto driver
> staging: ccree: add TODO list
> staging: ccree: add devicetree bindings
> MAINTAINERS: add Gilad BY as maintainer for ccree
We can't do much without a real patch, sorry. Digging in random git
trees doesn't work :(
I can't take this as-is, I need patches.
thanks,
greg k-h
On Tue, Apr 18, 2017 at 06:29:22PM +0300, Gilad Ben-Yossef wrote:
> On Tue, Apr 18, 2017 at 6:13 PM, Mark Rutland <[email protected]> wrote:
> > On Tue, Apr 18, 2017 at 05:07:50PM +0300, Gilad Ben-Yossef wrote:
> >> Arm TrustZone CryptoCell 700 is a family of cryptographic hardware
> >> accelerators. It is supported by a long lived series of out of tree
> >> drivers, which I am now in the process of unifying and upstreaming.
> >> This is the first drop, supporting the new CryptoCell 712 REE.
> >>
> >> The code still needs some cleanup before maturing to a proper
> >> upstream driver, which I am in the process of doing. However,
> >> as discussion of some of the capabilities of the hardware and
> >> its application to some dm-crypt and dm-verity features recently
> >> took place I though it is better to do this in the open via the
> >> staging tree.
> >>
> >> A Git repository based off of Linux 4.11-rc7 is available at
> >> https://github.com/gby/linux.git branch ccree.
> >>
> >> Signed-off-by: Gilad Ben-Yossef <gilad-6S/[email protected]>
> >> CC: Binoy Jayan <[email protected]>
> >> CC: Ofir Drang <[email protected]>
> >>
> >> Gilad Ben-Yossef (4):
> >> staging: add ccree crypto driver
> >> staging: ccree: add TODO list
> >> staging: ccree: add devicetree bindings
> >> MAINTAINERS: add Gilad BY as maintainer for ccree
> >>
> >> .../devicetree/bindings/crypto/arm-cryptocell.txt | 23 +
> >
> > I'm interested in looking at the DT binding, but for some reason I've
> > only recevied the cover letter so far.
> >
> > Are my mail servers being particularly slow today, or has something gone
> > wrong with the Cc list for the remaining patches?
> >
>
> Thanks a bunch for the willingness to review this.
>
> My apologies for not communicating this clearly enough - Since it is
> an pre-existing driver it is rather big.
> I did not want to inflict a 600K patch on the mailing list so opted to
> provide a git repo instead, as stated in the
> email.
Should this have been a [GIT PULL], then?
I was confused by the [PATCH 0/4].
> The patch in question is here:
> https://github.com/gby/linux/commit/12d92e0bc19aa9bbd891cdab765eaaeabe0b6967
>
> Do let me know if you prefer that I will send at least the smaller
> patch file via email in the normal fashion.
Sending patches is the usual way to have things reviewed. Linking to an
external site doesn't fit with the workflows of everyone.
If you wish to have patches reviewed, please send them as patches in the
usual fashion.
I will note that on the patch you linked, the compatible string is far
too vague, per common conventions. Per your description above, that
should be something like "arm,cryptocell-712-ree" (and each variant
should have its own string).
I don't have documentation to hand to attempt to review the rest.
I would appreciate if you could ensure that the DT binding was reviewed
as part of the staging TODOs. That needs to follow the usual DT review
process of sending patches to the list. Until that has occurred, it
shouldn't be in Documentation/devicetree/.
Thanks,
Mark.
On Tue, Apr 18, 2017 at 6:39 PM, Greg Kroah-Hartman
<[email protected]> wrote:
> On Tue, Apr 18, 2017 at 05:07:50PM +0300, Gilad Ben-Yossef wrote:
>> Arm TrustZone CryptoCell 700 is a family of cryptographic hardware
>> accelerators. It is supported by a long lived series of out of tree
>> drivers, which I am now in the process of unifying and upstreaming.
>> This is the first drop, supporting the new CryptoCell 712 REE.
>>
>> The code still needs some cleanup before maturing to a proper
>> upstream driver, which I am in the process of doing. However,
>> as discussion of some of the capabilities of the hardware and
>> its application to some dm-crypt and dm-verity features recently
>> took place I though it is better to do this in the open via the
>> staging tree.
>>
>> A Git repository based off of Linux 4.11-rc7 is available at
>> https://github.com/gby/linux.git branch ccree.
>>
>> Signed-off-by: Gilad Ben-Yossef <[email protected]>
>> CC: Binoy Jayan <[email protected]>
>> CC: Ofir Drang <[email protected]>
>>
>> Gilad Ben-Yossef (4):
>> staging: add ccree crypto driver
>> staging: ccree: add TODO list
>> staging: ccree: add devicetree bindings
>> MAINTAINERS: add Gilad BY as maintainer for ccree
>
> We can't do much without a real patch, sorry. Digging in random git
> trees doesn't work :(
>
> I can't take this as-is, I need patches.
Got it.
I'll break the driver to a series of patches and post them .
Thanks for the feedback.
Gilad
--
Gilad Ben-Yossef
Chief Coffee Drinker
"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
-- Jean-Baptiste Queru
On Tue, Apr 18, 2017 at 6:43 PM, Mark Rutland <[email protected]> wrote:
...
>> >>
>> >> The code still needs some cleanup before maturing to a proper
>> >> upstream driver, which I am in the process of doing. However,
>> >> as discussion of some of the capabilities of the hardware and
>> >> its application to some dm-crypt and dm-verity features recently
>> >> took place I though it is better to do this in the open via the
>> >> staging tree.
>> >>
>> >> A Git repository based off of Linux 4.11-rc7 is available at
>> >> https://github.com/gby/linux.git branch ccree.
>> >>
...
>> >> .../devicetree/bindings/crypto/arm-cryptocell.txt | 23 +
>> >
>> > I'm interested in looking at the DT binding, but for some reason I've
>> > only recevied the cover letter so far.
>> >
>> > Are my mail servers being particularly slow today, or has something gone
>> > wrong with the Cc list for the remaining patches?
>> >
>>
>> Thanks a bunch for the willingness to review this.
>>
>> My apologies for not communicating this clearly enough - Since it is
>> an pre-existing driver it is rather big.
>> I did not want to inflict a 600K patch on the mailing list so opted to
>> provide a git repo instead, as stated in the
>> email.
>
> Should this have been a [GIT PULL], then?
>
> I was confused by the [PATCH 0/4].
Yes, it should have. Sorry about that.
>
>> The patch in question is here:
>> https://github.com/gby/linux/commit/12d92e0bc19aa9bbd891cdab765eaaeabe0b6967
>>
>> Do let me know if you prefer that I will send at least the smaller
>> patch file via email in the normal fashion.
>
> Sending patches is the usual way to have things reviewed. Linking to an
> external site doesn't fit with the workflows of everyone.
>
> If you wish to have patches reviewed, please send them as patches in the
> usual fashion.
Thanks for the feedback.
I will break the driver up and post patches in the normal fashion.
>
> I will note that on the patch you linked, the compatible string is far
> too vague, per common conventions. Per your description above, that
> should be something like "arm,cryptocell-712-ree" (and each variant
> should have its own string).
Got it. Will change.
Thanks for the review even in this unconventional form :-) !
>
> I don't have documentation to hand to attempt to review the rest.
>
> I would appreciate if you could ensure that the DT binding was reviewed
> as part of the staging TODOs. That needs to follow the usual DT review
> process of sending patches to the list. Until that has occurred, it
> shouldn't be in Documentation/devicetree/.
Of course, will do.
Thanks,
Gilad
>
> Thanks,
> Mark.
--
Gilad Ben-Yossef
Chief Coffee Drinker
"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
-- Jean-Baptiste Queru