core:driver implementation NXP CAAM Driver by cneveux · Pull Request #2962 · OP-TEE/optee_os

cneveux · 2019-04-23T09:24:27Z

Add the NXP CAAM drivers:
- Random generator (instantiation and random generation)
- Hash

Add a generic cryptographic driver interface connecting
TEE Crypto generic APIs to HW driver interface

cneveux · 2019-04-23T09:36:41Z

I submitted this patch to integrate the Crypto HASH done by NXP CAAM HW module. The current implementation of the Crypto operation is not fully filling our expectation. Could see the comment of the commit?

jenswi-linaro · 2019-04-23T13:12:06Z

Hi @cneveux,

Thanks for this pull request. To better understand what's needed I'll need to ask a few questions and probably also propose different solutions.

We would like to be able:

Select at runtime a SW algorithm or HW algorithm

Each time crypto_hash_alloc_ctx() is called or during boot after the driver has been initialized?
If each time crypto_hash_alloc_ctx() is called which criteria are used to tell if SW or HW is to be used, how will long used contexts be handled?

Select at compile time the best SW Library algorithm

That's already possible today for some definition of best. In our case it's preference of mbedtls or libtomcrypt which is the criterion. I assume that libtomcrypt generally gives better performance, but you could prefer mbedtls for other reasons. For instance company policy or plain trust.

cneveux · 2019-04-23T13:44:46Z

Hi @cneveux,

Thanks for this pull request. To better understand what's needed I'll need to ask a few questions and probably also propose different solutions.

We would like to be able:

Select at runtime a SW algorithm or HW algorithm

Each time crypto_hash_alloc_ctx() is called or during boot after the driver has been initialized?
If each time crypto_hash_alloc_ctx() is called which criteria are used to tell if SW or HW is to be used, how will long used contexts be handled?

During HW Driver installation, the HW capacity is stored in the driver operation (max_hash) and function of this value, the Hash is computed by HW or SW. This is need in our case because CAAM Hash Limit is not the same function of the CAAM Module version.

We don't want to be only focus on the HASH, we will have the same runtime selection for other Crypto Alloc (e.g. AES CCM/GCM/XTS/CTS, ...) Function of the CAAM version some mode are not supported.

Other point, when we will perform the crypto performance testing, we may need to add more criteria than the HW support. For example, we may prefer to do operation by SW because of the data size to be handled.

Typically, when the amount of data is small, using HW is overloading the system with cache maintenance and buffer re-allocation to be cache line aligned (add memory copy too). In this case, doing the operation by SW is faster.
Cache alignment is need when HW DMA are used in write operation, the SW buffer in which we have to write must be cache aligned (start address and size of the buffer) to ensure that a cache invalidate is not affecting data around. If you refer to Linux, this is the role of the DMA memory allocator to do this. In OPTEE this feature is not supported as far as I know.

Select at compile time the best SW Library algorithm

That's already possible today for some definition of best. In our case it's preference of mbedtls or libtomcrypt which is the criterion. I assume that libtomcrypt generally gives better performance, but you could prefer mbedtls for other reasons. For instance company policy or plain trust.

Are we able to mix the Tomcrypt and mbedTLS? I mean, can I select the HASH384 with tomcrypt and HASH512 with mbedTLS? In fact the alloc_ctx should be upper to the tomcrypt or mbedTLS. May be having weak function.

In our vision, is to let end user (product manufacturer) to decide if he want to limit the runtime flexibility or not.

This could be benefict for every OPTEE customer.
(remember the libimxcrypt we shared in the past, it was done in this direction)

jenswi-linaro · 2019-04-23T14:40:35Z

During HW Driver installation, the HW capacity is stored in the driver operation (max_hash) and function of this value, the Hash is computed by HW or SW. This is need in our case because CAAM Hash Limit is not the same function of the CAAM Module version.

How about adding a call to drvcrypt_hash_alloc_ctx() at the beginning of crypto_hash_alloc_ctx() (in core/crypto/crypto.c) where we'll return directly if it succeeded and only fall back on the switch (algo) on failure?

This would mean that crypto_{md5,sha1,sha224,sha256,sha384,sha512}_alloc_ctx() are supposed to be the fallback software implementation, regardless of which crypto library is providing.

We don't want to be only focus on the HASH, we will have the same runtime selection for other Crypto Alloc (e.g. AES CCM/GCM/XTS/CTS, ...) Function of the CAAM version some mode are not supported.

Let's find something we can agree on for hashes first. I agree that it could be an advantage to reuse the pattern, but I guess it also depends on the pattern.

Other point, when we will perform the crypto performance testing, we may need to add more criteria than the HW support. For example, we may prefer to do operation by SW because of the data size to be handled.

Typically, when the amount of data is small, using HW is overloading the system with cache maintenance and buffer re-allocation to be cache line aligned (add memory copy too). In this case, doing the operation by SW is faster.
Cache alignment is need when HW DMA are used in write operation, the SW buffer in which we have to write must be cache aligned (start address and size of the buffer) to ensure that a cache invalidate is not affecting data around. If you refer to Linux, this is the role of the DMA memory allocator to do this. In OPTEE this feature is not supported as far as I know.

The current API can't handle this. Is this something that can wait?

Are we able to mix the Tomcrypt and mbedTLS? I mean, can I select the HASH384 with tomcrypt and HASH512 with mbedTLS? In fact the alloc_ctx should be upper to the tomcrypt or mbedTLS. May be having weak function.

Not mixing freely, but that could be achieved with more flags.

In our vision, is to let end user (product manufacturer) to decide if he want to limit the runtime flexibility or not.

Sure, we'll accept patches. They should preferably be independent of this PR, I'm trying to limit the scope of this PR.

MrVan · 2019-05-06T01:53:03Z

 $(call force,CFG_MX6,y)
 $(call force,CFG_MX6ULL,y)
 $(call force,CFG_TEE_CORE_NB_CORE,1)
+$(call force,CFG_NXP_CAAM,n)


"NXP" -> "IMX"? or this driver will also support LS chips?

Yes this driver will support LS chips also.

@MrVan ,
yes the driver will support LS devices as well.

MrVan · 2019-05-06T01:56:25Z

 else ifneq (,$(filter $(PLATFORM_FLAVOR),$(mx7-flavorlist)))
 $(call force,CFG_MX7,y)
 CFG_TEE_CORE_NB_CORE ?= 2
+CFG_WITH_HAB ?= y


Please at least explain this macro some where, and why default set to y

MrVan · 2019-05-06T01:56:42Z

 $(call force,CFG_MX6,y)
 $(call force,CFG_MX6S,y)
 $(call force,CFG_TEE_CORE_NB_CORE,1)
+$(call force,CFG_NXP_CAAM,n)


MrVan · 2019-05-06T01:56:50Z


 CFG_PL310_LOCKED ?= y
 CFG_ENABLE_SCTLR_RR ?= y
+CFG_WITH_HAB ?= y


MrVan · 2019-05-06T01:59:39Z

+
+# Almost all platforms include CAAM HW Modules, except the
+# one force to be disabled
+CFG_NXP_CAAM ?= y


Will this break the image booting using vendor/upstream uboot + vendor/upstream linux? Or please share some public doc somewhere to use the image built out with this "y"

this has not been removed. @MrVan, is it ok?

MrVan · 2019-05-06T02:00:03Z

+CFG_NXP_CAAM ?= y
+
+ifeq ($(CFG_NXP_CAAM),y)
+# currently disable the use of CAAM in OP-TEE


Please add a comment about why "currently disable ..." and "TODO:"

added explanation

MrVan · 2019-05-06T02:02:38Z

+#
+ifeq ($(CFG_CRYPTO_DRIVER), y)
+#
+# Define this variable ifthe system is able to manage the


Typo "ifthe"

MrVan · 2019-05-06T02:05:34Z

+#include "hal_cfg.h"
+#include "hal_clk.h"
+#include "hal_ctrl.h"
+


Please sort the header

MrVan · 2019-05-06T02:05:51Z

+#include "hal_clk.h"
+#include "hal_ctrl.h"
+
+#define CTRL_DEBUG


Prefer a CFG option

rework debug trace in the driver to select the traces function of build CFG_CAAM_DBG 32 bits word

Emantor · 2019-05-06T06:26:04Z

How do you propose to solve the problem of the linux clock driver turning of the clocks to the CAAM if it is used within OP-TEE but not enabled in the Linux kernel?
The Linux kernel will turn of the CAAM clocks even if they are enabled during the CAAM initialization done by OP-TEE, since there is no consumer visible to the clock framework.

MrVan · 2019-05-06T06:46:04Z

@Emantor If caam clk disabled by Linux, accessing it in OP-TEE, OP-TEE will crash, secure data will not be leaked. So does clk really matters here?

Emantor · 2019-05-06T06:51:29Z

Yes, you won't leak data, but your OP-TEE and thus your device is not usable as well.
Since the CAAM clks are disabled your transaction is stuck on the bus and your device is hard locked until the watchdog stikes.

MrVan · 2019-05-06T07:08:02Z

Yes, you won't leak data, but your OP-TEE and thus your device is not usable as well.
Since the CAAM clks are disabled your transaction is stuck on the bus and your device is hard locked until the watchdog stikes.

There is no good method to avoid CCM module being hacked in Linux side, unless protect CCM in secure world, but this requires redesign Linux side clock driver...
Not sure whether other silicon vendors has such issue and how.

sdininno · 2019-05-06T08:52:21Z

How do you propose to solve the problem of the linux clock driver turning of the clocks to the CAAM if it is used within OP-TEE but not enabled in the Linux kernel?
The Linux kernel will turn of the CAAM clocks even if they are enabled during the CAAM initialization done by OP-TEE, since there is no consumer visible to the clock framework.

Currently, as @MrVan stated, the clk will not be managed by Linux. Off course as you have stated rightfuly it is subject to a DoS attack. Unfortunatly , the TEE is not design fot that. it rather guarantees data integrity, not cpu availability.
having said that, our plan is also to move clock control to TEE (at least for i.MX6Q/DL, but could expand to all the 6 and 7 as well) and to expose an interface to Linux. we do have patches for that but are not ready yet for integration.

sdininno · 2019-05-06T08:59:58Z

Hello @jenswi-linaro ,

How about adding a call to drvcrypt_hash_alloc_ctx() at the beginning of crypto_hash_alloc_ctx() (in core/crypto/crypto.c) where we'll return directly if it succeeded and only fall back on the switch (algo) on failure?

This is good alternative, we will look at this option.
just to let you know that @cneveux will not be working on this for some time, but i will try to continue this work.

Emantor · 2019-07-02T06:21:16Z

+
+#ifdef CFG_DT_MODIFY
+	/* Ensure that CAAM Control is secure-status enabled */
+	if (dt_set_secure_status(fdt, node)) {


dt_set_secure_status does not exist in this patch set nor in the OP-TEE master.

Correct. This is why it's built only if the CFG_DT_MODIFY is define. This will require a specific patch to add this function. Do you agree to keep it for now while a new patch is submitterd?

Either remove this function or add the implementation, this is up to you. However I think most of the dt modification functions contained in the HAL are general enough to be included in the OP-TEE core files instead of the CAAM hal.

cneveux · 2019-07-02T06:36:22Z

Hello @jenswi-linaro

I reworked the patch to add the function drvcrypt_hash_alloc_ctx() at the beginning of crypto_hash_alloc_ctx().
I removed the crypto SW wrapper from the original PR.

dmcilvaney · 2019-07-16T22:07:22Z

Hi @cneveux , @MrVan,

Is an implementation of tee_otp_get_hw_unique_key() and tee_otp_get_die_id() based on the OTPMK outside the scope of this pull request, or something you would consider including? We would love to get your implmementation from Code Aurora

We have an implementation we have been using here which uses the CAAM to generate them, but ideally we would like to move completely to an upstream implementation rather than maintaining our partial CAAM driver.

cneveux · 2019-08-12T09:29:07Z

@jenswi-linaro, @etienne-lms, @jforissier

Can I ask you if there is more comments on this PR? Do you approved it?

Thanks and Regards,

Cedric

jenswi-linaro · 2019-08-12T09:51:33Z

@cneveux, I'm not done yet I was just taking a break since @etienne-lms was bombarding you with comments. I'll resume again.

By the way, often there's no notification when a PR is just force pushed, a comment is needed to to make sure that it's noticed.

cneveux · 2019-08-12T09:57:54Z

@cneveux, I'm not done yet I was just taking a break since @etienne-lms was bombarding you with comments. I'll resume again.

By the way, often there's no notification when a PR is just force pushed, a comment is needed to to make sure that it's noticed.

@jenswi-linaro
Ok, thanks. As I'll be in vacation from Aug, 15th to Aug, 26th, I'll certainly not have time to review and submit a new patch before leaving.

jenswi-linaro · 2019-08-12T10:01:58Z

@cneveux, thanks for letting me know. I hope you'll have a good vacation. I'll make sure there's some comments waiting for you when you're back. :-)

jenswi-linaro

Comments for the commit "core: driver: generic resources for crypto device driver"

jenswi-linaro · 2019-08-20T06:27:10Z

+	struct crypto_hash *hash_src = to_hash_ctx(src_ctx);
+	struct crypto_hash *hash_dst = to_hash_ctx(dst_ctx);
+
+	if (hash_src->op)


hash_src->op->copy_state isn't checked, does that mean that all the other functions are optional but this is mandatory?

my mistake I missed it

jenswi-linaro · 2019-08-20T06:28:36Z

+	struct crypto_hash *hash = to_hash_ctx(ctx);
+
+	/* Check the parameters */
+	if (hash->op) {


I'd prefer to write this as:

if (hash->op && hash->op->free_ctx)

Do we really need to check these pointers? Aren't they required to be valid and we're just sanity checking here? If it's just sanity check I think an assert() would be more appropriate.

The free operation in the driver is not mandatory. Hence the check of the pointer is needed to call the driver function.

jenswi-linaro · 2019-08-20T06:29:12Z

+static TEE_Result hash_init(struct crypto_hash_ctx *ctx)
+{
+	TEE_Result ret = TEE_ERROR_NOT_IMPLEMENTED;
+


Empty line not needed, same in hash_update() and hash_final() below.

jenswi-linaro · 2019-08-20T06:32:45Z

+	struct crypto_hash *hash = to_hash_ctx(ctx);
+
+	/* Check the parameters */
+	if ((!data) && (len != 0))


It's a matter of taste, but I would've written this as

if (!data && len)

All the extra () are redundant, and the ones around !data disturbingly so.

ok, I'll fix it

jenswi-linaro · 2019-08-20T06:34:20Z

+	struct crypto_hash *hash = to_hash_ctx(ctx);
+
+	/* Check the parameters */
+	if ((!digest) || (!len))


Please drop the extra () so this becomes

if (!digest || !len)

jenswi-linaro · 2019-08-20T06:40:28Z

+	TEE_Result (*update)(void *ctx, const uint8_t *data, size_t len);
+	/* Finalize the hashing operation */
+	TEE_Result (*final)(void *ctx, uint8_t *digest, size_t len);
+


Empty line not needed.

jenswi-linaro · 2019-08-20T07:01:02Z

+#include <drvcrypt.h>
+#include <initcall.h>
+#include <trace.h>
+


I'm not sure the interface implemented in this file is needed. It only seems safe to call during early boot, before exiting to normal world the first time. Type safety is lost. The caller of drvcrypt_getmod() must know the type of the point it gets. All this could be replaced by:

const struct drvcrypt_hash *drvcrypt_hash_ops; const struct drvcrypt_mac *drvcrypt_mac_ops; const struct drvcrypt_cipher *drvcrypt_cipher_ops; ...

with retained type safety. Perhaps I'm missing something.

If you think it's important to keep this, do so. Once all the PRs are merged we can evaluate this again.

This interface is to register to HW Driver module in the crypt_algo array. The registration is done during the HW Driver initialization function of the HW capabilities. To be generic and to prevent optional compilation per device type, we read HW registers to know if CAAM support or not the algorithm to register. If not, we keep NULL in the crypt_algo and so the HW driver is not called.
For sure you can not see to need with the HASH but for other operation it will be usefull

jenswi-linaro · 2019-08-20T07:11:01Z

+/*
+ * Copyright 2018-2019 NXP
+ *
+ * Brief   This driver interfaces TEE Internal API by implementing


"TEE Internal API" is an unfortunate wording as that's something different for us who have worked a bit with the GP APIs.

ok I'll reword it.

jenswi-linaro · 2019-08-20T07:11:29Z

+ */
+struct crypto_hash {
+	struct crypto_hash_ctx hash_ctx; /* Crypto Hash API context */
+


Empty line not needed.

jenswi-linaro · 2019-08-20T07:44:39Z

+ * Format the HASH context to keep the reference to the
+ * operation driver
+ */
+struct crypto_hash {


Is this wrapper layer really needed? Is anything missing with struct crypto_hash_ctx which is stopping drivers/crypto/caam/hash/caam_hash.c from implementing a struct crypto_hash_ctx instead? Am I missing something?

For sure, now it's no more needed as we reworked everything and removed the original checks. I can remove it but for the next crypto driver, I'll have the same structure and to be compliant I would prefer to keep this method. Now if you think that it will add complexity and overhead I can rework it to remove the struct drvcrypt_hash.
Please let me know.

What do you mean by the next crypto driver? Compliant with what, in which context?

If it's only here for historical reasons I'd rather see it removed since it adds another level of indirection and makes it harder to follow the code.

I mean the implementation for the Symmetric, Asymmetric and key derivation using the HW driver. There is the same wrapping operation structure used to reformat the crypto_xxx parameters in a data structure.
Anyway, for the Hash I'll remove it and we will see after for the others.

I added a new commit (last one in the list) to the PR implementing this change. I'll squashed files after review and acceptance

jenswi-linaro

Some comments for the commit "core: driver: implementation NXP CAAM Driver"

jenswi-linaro · 2019-08-20T08:13:28Z

+/* Return lower 32 bits of physical address */
+#define PHYS_ADDR_LO(phys_addr) (uint32_t)(((uint64_t)phys_addr) & UINT32_MAX)
+
+uint32_t desc_get_len(uint32_t *desc)


This is a global symbol. I'd prefer if all global symbols had a common prefix, caam_ seems natural.
I think that in a driver it's more important to stick to a common prefix or two than in other places. This is not a big problem in OP-TEE currently, but as more and more drivers are added it could at least get confusing.

I see your point. I'll add the prefix

jenswi-linaro · 2019-08-20T10:21:59Z

+static uint32_t do_jr_dequeue(uint32_t waitJobIds)
+{
+	uint32_t retJobId = 0;
+


Empty line not needed.

jenswi-linaro · 2019-08-20T10:45:36Z

+#ifndef __CAAM_HAL_CLK_H__
+#define __CAAM_HAL_CLK_H__
+
+#include <stdlib.h>


Including <types_ext.h> would be a better choice.

jenswi-linaro · 2019-08-20T10:45:57Z

+#ifndef __CAAM_HAL_CTRL_H__
+#define __CAAM_HAL_CTRL_H__
+
+#include <utee_defines.h>


Including <types_ext.h> would be a better choice.

jenswi-linaro · 2019-08-20T10:50:07Z

+ *
+ * @time  Time in microsecond
+ */
+void caam_udelay(uint32_t time)


How about using udelay() instead?

udelay() currently uses the core internal timer, which is not available on Cortex-A9 cores, i.e. i.MX6Q.

Aha, missed that. Perhaps the platform should be able to override udelay(). Because this implementation doesn't seem very suitable for generic code.

As this is specific to NXP CAAM driver I prefer to not change it and it will be reviewed later when we will finish the NXP i.MX implementation support for all device type (MX6/7/8).

jenswi-linaro · 2019-08-20T12:44:14Z

There's quite a few cases of camel case in especially the commit "core: driver: implementation NXP CAAM Driver". enum CAAM_Status is acceptable, at least to me, but the rest should preferably be fixed.

jenswi-linaro · 2019-08-21T08:59:56Z

There's quite a few new checkpatch warnings now that checkpatch is run with --strict.

Add functions sev() and wfe() to implememt assembly instructions WFE/SEV. Signed-off-by: Cedric Neveux <[email protected]> Reviewed-by: Jens Wiklander <[email protected]> Reviewed-by: Etienne Carriere <[email protected]>

Add registers to handle CAAM clocks Signed-off-by: Cedric Neveux <[email protected]> Acked-by: Jens Wiklander <[email protected]>

Add DT functions: dt_get_irq() get the interrupt number of a node dt_disable_status() disable the 'status' field of node's prop dt_enable_secure_status() set 'secure-status' field of node's prop and disable the 'status' field in the same time Signed-off-by: Cedric Neveux <[email protected]> Acked-by: Jens Wiklander <[email protected]>

This change moves the DT pack operation at the end of the generic boot, in release_external_dt(). This change allows any driver or initialization function to change the DT and get its content repacked before DT is accessed by another boot agent. Signed-off-by: Cedric Neveux <[email protected]> Acked-by: Jens Wiklander <[email protected]> Reviewed-by: Etienne Carriere <[email protected]>

Add 32 and 64 bits little endian put/get functions Signed-off-by: Cedric Neveux <[email protected]> Reviewed-by: Etienne Carriere <[email protected]>

Add the read_ctr_el0 function in the arm64.h file Signed-off-by: Cedric Neveux <[email protected]> Reviewed-by: Jens Wiklander <[email protected]>

Add a generic cryptographic driver interface connecting TEE Crypto generic APIs to HW driver interface The Generic Crypto Driver interface in the core/driver/crypto/crypto_api is implemented to be able to use a HW driver. Signed-off-by: Cedric Neveux <[email protected]>

Add the NXP CAAM drivers: - Random generator (instantiation and random generation) - Hash Signed-off-by: Cedric Neveux <[email protected]>

Remove the drvcrypt_hash ops structure to implement the crypto_hash_ctx operations into the specific HASH HW driver implementation. Signed-off-by: Cedric Neveux <[email protected]>

etienne-lms

comments for "core: driver: generic resources for crypto device driver".

etienne-lms · 2019-08-27T12:30:54Z

+{
+	struct crypto_hash *hash = to_hash_ctx(ctx);
+
+	/* Check the parameters */


can remove this comment

etienne-lms · 2019-08-27T12:31:43Z

+ * Copy Software Hashing Context
+ *
+ * @src_ctx  Reference the API context source
+ * @dst_ctx  [out] Reference the API context destination


swap lines (effective args ordering)

etienne-lms · 2019-08-27T12:32:12Z

+	TEE_Result ret = TEE_ERROR_NOT_IMPLEMENTED;
+	struct crypto_hash *hash = to_hash_ctx(ctx);
+
+	/* Check the parameters */


remove comment
same for all /* Check the parameters */ in this file.

etienne-lms · 2019-08-27T12:33:56Z

+ * Finalize the Hash operation
+ *
+ * @ctx     Reference the API context
+ * @len     Digest buffer length


swap the 2 last lines.

etienne-lms · 2019-08-27T12:35:45Z

+ * @algo  Algorithm
+ * @id    [out] Hash Algorithm internal ID
+ */
+static struct drvcrypt_hash *do_check_algo(uint32_t algo, uint8_t *id)


suggest to move this below line 178, right above drvcrypt_hash_alloc_ctx().

etienne-lms · 2019-08-27T12:41:28Z

+/*
+ * Cryptographic module registration
+ *
+ * @algo_id  Crypto index in the array


could suggest a more agnostic way (I.e. "ID of the registered crypto algorithm")

etienne-lms · 2019-08-27T12:45:20Z

+ * Crypto Library Hash driver operations
+ */
+struct drvcrypt_hash {
+	/* Allocates of the Software context */


s/of the/the/

Some suggested rephrasing:
"Allocate operation context"
"Free operation context"
"Initialize operation context"
"Update operation context"
"Finalize operation context"
"Copy operation context"
...or maybe even no inline comment.

etienne-lms · 2019-08-27T12:47:25Z

 			   struct crypto_hash_ctx *src_ctx);
 };

+#ifdef CFG_CRYPTO_DRIVER


Should be CFG_CRYPTO_DRV_HASH?

etienne-lms · 2019-08-27T12:55:44Z

+/*
+ * Cryptographic buffer type
+ */
+struct drvcrypt_buf {


unused. remove.

etienne-lms · 2019-08-27T13:00:27Z

+	if (hash->op && hash->op->alloc_ctx)
+		ret = hash->op->alloc_ctx(&hash->ctx, hash_id);
+
+	if (ret != TEE_SUCCESS) {


If module has no alloc_ctx handler, this will fail with TEE_ERROR_NOT_IMPLEMENTED.
Could default init ret = TEE_SUCCESS;, or change a bit the code.

etienne-lms · 2019-08-27T13:16:54Z

@cneveux, I suggest you create a P-R for the preliminary changes (all already reviewed) so that they can be merged:

core: arm64 Add sev/wfe inline function …
plat-imx: Add CRM registers mapping …
core: add DT function to read/modify DT …
core: kernel: move DT pack at the end of boot …
core: io: add {get/put}_le{32/64}() …
core: arm64: add read_ctr_el0 function …

Also minor comment regarding commit "core: driver: generic resources for crypto device driver ":
(core/drivers/crypto/crypto_api/)drvcrypt_init.c could be renamed drvcrypt.c.

jenswi-linaro · 2019-08-27T13:19:45Z

@cneveux, I suggest you create a P-R for the preliminary changes (all already reviewed) so that they can be merged...

And for the commits left perhaps also a new PR because it's quite slow to browse this PR now.

cneveux · 2019-08-28T06:26:50Z

@etienne-lms, @jenswi-linaro,

As suggested, created a PR #3222 with:

core: arm64 Add sev/wfe inline function …
plat-imx: Add CRM registers mapping …
core: add DT function to read/modify DT …
core: kernel: move DT pack at the end of boot …
core: io: add {get/put}_le{32/64}() …
core: arm64: add read_ctr_el0 function …

etienne-lms · 2019-08-28T07:56:36Z

Thanks @cneveux.
When updating the drvcrypt serie, please straight squash
fixup "core: driver: Remove drvcrypt_hash ops"
and ~~fixup~~ "core: driver: generic resources for crypto device driver"
as you suggested.
(edited)

sahilnxp mentioned this pull request May 5, 2019

Master+imx caam fix #2986

Merged

MrVan reviewed May 6, 2019

View reviewed changes

cneveux force-pushed the feature/patch_caam_hash branch from 42fbdf6 to ff16e81 Compare July 2, 2019 06:15

Emantor reviewed Jul 2, 2019

View reviewed changes

cneveux force-pushed the feature/patch_caam_hash branch 2 times, most recently from 9bf6bf4 to 6f9b125 Compare July 2, 2019 06:25

cneveux force-pushed the feature/patch_caam_hash branch 3 times, most recently from 1a69871 to cbf4c86 Compare July 5, 2019 14:57

cneveux force-pushed the feature/patch_caam_hash branch from cbf4c86 to 7e044b4 Compare July 10, 2019 12:07

cneveux force-pushed the feature/patch_caam_hash branch from 9777694 to 1425ada Compare August 13, 2019 08:32

jenswi-linaro reviewed Aug 20, 2019

View reviewed changes

cneveux added 7 commits August 27, 2019 09:35

core: arm64 Add sev/wfe inline function

8ea26c3

Add functions sev() and wfe() to implememt assembly instructions WFE/SEV. Signed-off-by: Cedric Neveux <[email protected]> Reviewed-by: Jens Wiklander <[email protected]> Reviewed-by: Etienne Carriere <[email protected]>

plat-imx: Add CRM registers mapping

394e5a0

Add registers to handle CAAM clocks Signed-off-by: Cedric Neveux <[email protected]> Acked-by: Jens Wiklander <[email protected]>

core: io: add {get/put}_le{32/64}()

d93bbdc

Add 32 and 64 bits little endian put/get functions Signed-off-by: Cedric Neveux <[email protected]> Reviewed-by: Etienne Carriere <[email protected]>

core: arm64: add read_ctr_el0 function

e35057a

Add the read_ctr_el0 function in the arm64.h file Signed-off-by: Cedric Neveux <[email protected]> Reviewed-by: Jens Wiklander <[email protected]>

cneveux force-pushed the feature/patch_caam_hash branch 4 times, most recently from 1327263 to 2095bff Compare August 27, 2019 10:43

cneveux added 2 commits August 27, 2019 12:44

core: driver: implementation NXP CAAM Driver

968341e

Add the NXP CAAM drivers: - Random generator (instantiation and random generation) - Hash Signed-off-by: Cedric Neveux <[email protected]>

core: driver: Remove drvcrypt_hash ops

2095bff

Remove the drvcrypt_hash ops structure to implement the crypto_hash_ctx operations into the specific HASH HW driver implementation. Signed-off-by: Cedric Neveux <[email protected]>

etienne-lms reviewed Aug 27, 2019

View reviewed changes

cneveux closed this Aug 28, 2019

jockebech mentioned this pull request Oct 7, 2019

Update CHANGELOG for 3.7.0 #3309

Merged

cneveux deleted the feature/patch_caam_hash branch October 13, 2020 12:57

Conversation

cneveux commented Apr 23, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cneveux commented Apr 23, 2019

Uh oh!

jenswi-linaro commented Apr 23, 2019

Uh oh!

cneveux commented Apr 23, 2019

Uh oh!

jenswi-linaro commented Apr 23, 2019

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

MrVan May 6, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Emantor commented May 6, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

MrVan commented May 6, 2019

Uh oh!

Emantor commented May 6, 2019

Uh oh!

MrVan commented May 6, 2019

Uh oh!

sdininno commented May 6, 2019

Uh oh!

sdininno commented May 6, 2019

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cneveux commented Jul 2, 2019

Uh oh!

dmcilvaney commented Jul 16, 2019

Uh oh!

cneveux commented Aug 12, 2019

Uh oh!

jenswi-linaro commented Aug 12, 2019

Uh oh!

cneveux commented Aug 12, 2019

Uh oh!

jenswi-linaro commented Aug 12, 2019

Uh oh!

jenswi-linaro left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cneveux commented Apr 23, 2019 •

edited

Loading

MrVan May 6, 2019 •

edited

Loading

Emantor commented May 6, 2019 •

edited

Loading