aboutsummaryrefslogtreecommitdiffstats
path: root/crypto/scatterwalk.h
Commit message (Collapse)AuthorAgeFilesLines
* [SG] Update crypto/ to sg helpersJens Axboe2007-10-221-3/+3
| | | | Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
* crypto: don't pollute the global namespace with sg_next()Jens Axboe2007-10-161-1/+1
| | | | | | | It's a subsystem function, prefix it as such. Acked-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
* [CRYPTO] scatterwalk: Add scatterwalk_map_and_copyHerbert Xu2007-10-101-0/+3
| | | | | | | | | This patch adds the function scatterwalk_map_and_copy which reads or writes a chunk of data from a scatterlist at a given offset. It will be used by authenc which would read/write the authentication data at the end of the cipher/plain text. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* [CRYPTO] digest: Added user API for new hash typeHerbert Xu2006-09-211-3/+1
| | | | | | | | | | | | | | | | | The existing digest user interface is inadequate for support asynchronous operations. For one it doesn't return a value to indicate success or failure, nor does it take a per-operation descriptor which is essential for the issuing of requests while other requests are still outstanding. This patch is the first in a series of steps to remodel the interface for asynchronous operations. For the ease of transition the new interface will be known as "hash" while the old one will remain as "digest". This patch also changes sg_next to allow chaining. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* [CRYPTO] scatterwalk: Prepare for block ciphersHerbert Xu2006-09-211-19/+29
| | | | | | | | | | | | | | | | | | | | | This patch prepares the scatterwalk code for use by the new block cipher type. Firstly it halves the size of scatter_walk on 32-bit platforms. This is important as we allocate at least two of these objects on the stack for each block cipher operation. It also exports the symbols since the block cipher code can be built as a module. Finally there is a hack in scatterwalk_unmap that relies on progress being made. Unfortunately, for hardware crypto we can't guarantee progress to be made since the hardware can fail. So this also gets rid of the hack by not advancing the address returned by scatterwalk_map. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* [CRYPTO] Add alignmask for low-level cipher implementationsHerbert Xu2005-07-061-0/+6
| | | | | | | | | | | | | | | | | | | The VIA Padlock device requires the input and output buffers to be aligned on 16-byte boundaries. This patch adds the alignmask attribute for low-level cipher implementations to indicate their alignment requirements. The mid-level crypt() function will copy the input/output buffers if they are not aligned correctly before they are passed to the low-level implementation. Strictly speaking, some of the software implementations require the buffers to be aligned on 4-byte boundaries as they do 32-bit loads. However, it is not clear whether it is better to copy the buffers or pay the penalty for unaligned loads/stores. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
* [CRYPTO] Add plumbing for multi-block operationsHerbert Xu2005-07-061-3/+3
| | | | | | | | | | | | | | | | | | The VIA Padlock device is able to perform much better when multiple blocks are fed to it at once. As this device offers an exceptional throughput rate it is worthwhile to optimise the infrastructure specifically for it. We shift the existing page-sized fast path down to the CBC/ECB functions. We can then replace the CBC/ECB functions with functions provided by the underlying algorithm that performs the multi-block operations. As a side-effect this improves the performance of large cipher operations for all existing algorithm implementations. I've measured the gain to be around 5% for 3DES and 15% for AES. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
* Linux-2.6.12-rc2Linus Torvalds2005-04-161-0/+63
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!