forked from Minki/linux
51b44fc811
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 <boris.brezillon@free-electrons.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> |
||
|---|---|---|
| .. | ||
| amd-ccp.txt | ||
| atmel-crypto.txt | ||
| fsl-dcp.txt | ||
| fsl-imx-sahara.txt | ||
| fsl-sec2.txt | ||
| fsl-sec4.txt | ||
| fsl-sec6.txt | ||
| img-hash.txt | ||
| mv_cesa.txt | ||
| omap-aes.txt | ||
| omap-des.txt | ||
| omap-sham.txt | ||
| picochip-spacc.txt | ||
| qcom-qce.txt | ||
| samsung-sss.txt | ||