kernel/git/next/linux-next.git/drivers/crypto/mv_cesa.c, branch master

crypto: marvell - Remove the old mv_cesa driver

2017-11-03T13:53:30+00:00

All defconfigs selecting the old driver have been patched to select the new one instead. We can now remove the old driver along with the allhwsupports module parameter in the new driver that was used to check whether the new driver was allowed to take control of the CESA engine or not. Signed-off-by: Boris Brezillon Signed-off-by: Herbert Xu

crypto: Use PTR_ERR_ZERO

2017-09-22T09:43:27+00:00

Use PTR_ERROR_ZERO rather than if(IS_ERR(...)) + PTR_ERR. Build successfully. Signed-off-by: Himanshu Jha Signed-off-by: Herbert Xu

crypto: mv_cesa - Use IPAD/OPAD constant

2017-05-23T04:52:08+00:00

This patch simply replace all occurrence of HMAC IPAD/OPAD value by their define. Signed-off-by: Corentin Labbe Signed-off-by: Herbert Xu

Crypto: mv_cesa - Switch to using managed resources

2016-11-13T09:45:01+00:00

Switch to resource-managed function devm_kzalloc instead of kzalloc and remove unneeded kfree Also, remove kfree in probe function and remove function, mv_remove as it is now has nothing to do. The Coccinelle semantic patch used to make this change is as follows: // @platform@ identifier p, probefn, removefn; @@ struct platform_driver p = { .probe = probefn, .remove = removefn, }; @prb@ identifier platform.probefn, pdev; expression e, e1, e2; @@ probefn(struct platform_device *pdev, ...) { <+... - e = kzalloc(e1, e2) + e = devm_kzalloc(&pdev->dev, e1, e2) ... ?-kfree(e); ...+> } @rem depends on prb@ identifier platform.removefn; expression prb.e; @@ removefn(...) { <... - kfree(e); ...> } // Signed-off-by: Nadim Almas Signed-off-by: Herbert Xu

crypto: mv_cesa - remove NO_IRQ reference

2016-09-07T13:08:32+00:00

Drivers should not use NO_IRQ, as we are trying to get rid of that. In this case, the call to irq_of_parse_and_map() is both wrong (as it returns '0' on failure, not NO_IRQ) and unnecessary (as platform_get_irq() does the same thing) This removes the call to irq_of_parse_and_map() and checks for the error code correctly. Signed-off-by: Arnd Bergmann Acked-by: Boris Brezillon Signed-off-by: Herbert Xu

crypto: marvell/cesa - another fix up for of_get_named_gen_pool() rename

2015-07-03T18:37:02+00:00

Signed-off-by: Stephen Rothwell Signed-off-by: Linus Torvalds

crypto: mv_cesa - explicitly define kirkwood and dove compatible strings

2015-06-19T14:18:02+00:00

We are about to add a new driver to support new features like using the TDMA engine to offload the CPU. Orion, Dove and Kirkwood platforms are already using the mv_cesa driver, but Orion SoCs do not embed the TDMA engine, which means we will have to differentiate them if we want to get TDMA support on Dove and Kirkwood. In the other hand, the migration from the old driver to the new one is not something all people are willing to do without first auditing the new driver. Hence we have to support the new compatible in the mv_cesa driver so that new platforms with updated DTs can still attach their crypto engine device to this driver. Signed-off-by: Boris Brezillon Signed-off-by: Herbert Xu

crypto: mv_cesa - use gen_pool to reserve the SRAM memory region

2015-06-19T14:18:02+00:00

The mv_cesa driver currently expects the SRAM memory region to be passed as a platform device resource. This approach implies two drawbacks: - the DT representation is wrong - the only one that can access the SRAM is the crypto engine The last point is particularly annoying in some cases: for example on armada 370, a small region of the crypto SRAM is used to implement the cpuidle, which means you would not be able to enable both cpuidle and the CESA driver. To address that problem, we explicitly define the SRAM device in the DT and then reference the sram node from the crypto engine node. Also note that the old way of retrieving the SRAM memory region is still supported, or in other words, backward compatibility is preserved. Signed-off-by: Boris Brezillon Signed-off-by: Herbert Xu

crypto: mv_cesa - request registers memory region

2015-05-25T10:41:27+00:00

The mv_cesa driver does not request the CESA registers memory region. Since we're about to add a new CESA driver, we need to make sure only one of these drivers probe the CESA device, and requesting the registers memory region is a good way to achieve that. Signed-off-by: Boris Brezillon Signed-off-by: Herbert Xu

crypto: mv_cesa - ensure backlog is initialised

2015-04-21T01:14:38+00:00

backlog is not initialised so in the case where cpg->eng_st != ENGINE_IDLE it is never initialised and hence which could lead to an illegal memory dereference in the statement: backlog->complete(backlog, -EINPROGRESS); Discovered with cppcheck static analsys: [drivers/crypto/mv_cesa.c:616]: (error) Uninitialized variable: backlog Signed-off-by: Colin Ian King Signed-off-by: Herbert Xu