summaryrefslogtreecommitdiff
path: root/drivers/crypto/caam/qi.c
AgeCommit message (Collapse)Author
2013-06-07crypto: caam - Implement QI driver context updateVakul Garg
On a crypto transform, a setkey() operation can be performed multiple times e.g. when keys are changed. These requires updation of shared descriptor in caam_qi driver. The shared descriptor in case of QI driver is maintained inside driver context and it is prefixed with pre-header. When shared descriptor is updated by the driver application, it needs to be copied again into driver context and pre-header should also be updated. With this patch, the caam_qi driver provides new api caam_drv_ctx_update(). The caam_qi driver application has been updated to call this api when setkey() operation changes shared descriptor. Change-Id: Ice6065ac9461e2d7af2e19a8a8c6d2ad8b5394b8 Signed-off-by: Vakul Garg <vakul@freescale.com> Reviewed-on: http://git.am.freescale.net:8181/2847 Reviewed-by: Varvara Andrei-B21317 <andrei.varvara@freescale.com> Reviewed-by: Fleming Andrew-AFLEMING <AFLEMING@freescale.com> Tested-by: Fleming Andrew-AFLEMING <AFLEMING@freescale.com>
2013-06-03crypto: caam/qi - return 0 for success in alloc_cgrsHaiying Wang
Otherwise, unexpected cgrid releases and cgr delete will happen, which leads to cgr leaking issue later. Signed-off-by: Haiying Wang <Haiying.Wang@freescale.com> Change-Id: I468653655bcd4c9aa2528ea99d25b13b2d664223 Reviewed-on: http://git.am.freescale.net:8181/2824 Reviewed-by: Garg Vakul-B16394 <vakul@freescale.com> Reviewed-by: Fleming Andrew-AFLEMING <AFLEMING@freescale.com> Tested-by: Fleming Andrew-AFLEMING <AFLEMING@freescale.com>
2013-05-29crypto: caam - Fixed memory leak in QI driverVakul Garg
The function caam_drv_ctx_rel() did not release the memory allocated for driver context. Added kfree() for cleanup. Change-Id: If44af08f4be6992f428414ac83c029a79e4de6c6 Signed-off-by: Vakul Garg <vakul@freescale.com> Reviewed-on: http://git.am.freescale.net:8181/2733 Tested-by: Review Code-CDREVIEW <CDREVIEW@freescale.com> Reviewed-by: Geanta Neag Horia Ioan-B05471 <horia.geanta@freescale.com> Reviewed-by: Fleming Andrew-AFLEMING <AFLEMING@freescale.com> Tested-by: Fleming Andrew-AFLEMING <AFLEMING@freescale.com>
2013-05-21crypto: caam - Restore cpus allowed mask at driver load/unloadBogdan Hamciuc
The CAAM code has to briefly alter the cpus allowed mask when initializing/destroying CGRs. However, it would not restore the previous mask, thus leaving the task scheduler with only one available CPU. Restore the cpus allowed mask that the driver's initialization/tear-down routines find before operating on CGRs. Signed-off-by: Bogdan Hamciuc <bogdan.hamciuc@freescale.com> Change-Id: Iabde013d232deda9fbced224a9edc34e8a09f32d Reviewed-on: http://git.am.freescale.net:8181/2631 Reviewed-by: Fleming Andrew-AFLEMING <AFLEMING@freescale.com> Tested-by: Fleming Andrew-AFLEMING <AFLEMING@freescale.com>
2013-05-14crypto: caam - Adding backend driver for CAAM queue interfaceVakul Garg
CAAM supports two interfaces for crypto job submission. These are job ring based and QMAN based interfaces. QMAN based interfaces are present of DPAA enabled platforms. This patch adds a platform device for accessing the caam's queue interface. The requests are submitted to caam using one frame queue per cryptographic context. Each crypto context has one shared descriptor. This shared descriptor is attached to frame queue associated with corresponding driver context using context_a. The driver hides the mechanics of FQ creation, initialisation from its applications. Each cryptographic context needs to be associated with driver context which houses the FQ to be used to transport the job to SEC. The driver provides apis for: (a) Context creation (b) Job submission (c) Context deletion (d) Checking if path to SEC or from SEC is congested The driver supports affining its context to a particular CPU. This means that any responses from the SEC for the context in question would arrive at the given CPU. This helps in implementing one cpu per pkt round trip in ipsec application. The driver processes the caam respones under NAPI contexts. NAPI contexts are instantiated only on cores with affined portals since only cores having their own portal can receive responses from DQRR. The responses from CAAM for all cryptographic contexts ride on a fixed set of FQs. We use one response FQ per portal owning core. The response FQ is configured in each core's and thus portal's dedicated channel. This gives the flexibility to direct the caam's responses for a crypto context on a given core. Change-Id: Id9661caae0ecda933e35eef40fb0b25013365397 Signed-off-by: Vakul Garg <vakul@freescale.com> Change-Id: I79819af83d57c64acb4a76213452ce912cba0273 Reviewed-on: http://git.am.freescale.net:8181/2075 Reviewed-by: Geanta Neag Horia Ioan-B05471 <horia.geanta@freescale.com> Reviewed-by: Fleming Andrew-AFLEMING <AFLEMING@freescale.com> Tested-by: Fleming Andrew-AFLEMING <AFLEMING@freescale.com>