> Else, what about ceding the processor ? Or at the very least reducing
> the thread priority for a bit ?
>
> Shouldn't we also enforce to always have a timeout ? IE. Something like
> 30s or so if nothing specified to avoid having the kernel just hard
> lock...
>
> In general I don't like that s
Hrm... I don't like that much:
> + if (op->timeout)
> + deadline = jiffies + msecs_to_jiffies(op->timeout);
> +
> + while (true) {
> + hret = plpar_hcall_norets(H_COP, op->flags,
> + vdev->resource_id,
> + op->
This adds the required platform data and calls to enable
the CRYP/HASH driver.
Acked-by: Linus Walleij
Signed-off-by: Andreas Westin
---
arch/arm/mach-ux500/board-mop500.c | 48
arch/arm/mach-ux500/board-u5500.c | 48
Resending, something seems to have gone wrong the first time.
Changed config to depend on correct ARCH, also removed an
unnecessary if statement check in the hash driver.
This adds a driver for the ST-Ericsson ux500 crypto hardware
module. It supports AES, DES and 3DES, the driver implements
supp
This adds the required platform data and calls to enable
the CRYP/HASH driver.
Acked-by: Linus Walleij
Signed-off-by: Andreas Westin
---
arch/arm/mach-ux500/board-mop500.c | 48
arch/arm/mach-ux500/board-u5500.c | 48
Changed config to depend on correct ARCH, also removed an
unnecessary if statement check in the hash driver.
This adds a driver for the ST-Ericsson ux500 crypto hardware
module. It supports AES, DES and 3DES, the driver implements
support for AES-ECB,CBC and CTR.
Patches are also available at: ht
