- 21 9月, 2006 5 次提交
-
-
由 Herbert Xu 提交于
This patch adds block cipher algorithms for cbc(aes) and ecb(aes) for the PadLock device. Once all users to the old cipher type have been converted the old cbc/ecb PadLock operations will be removed. Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Michal Ludvig 提交于
Compile a helper module padlock.ko that will try to autoload all configured padlock algorithms. This also provides backward compatibility with the ancient times before padlock.ko was renamed to padlock-aes.ko Signed-off-by: NMichal Ludvig <michal@logix.cz> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Michal Ludvig 提交于
Support for SHA1 / SHA256 algorithms in VIA C7 processors. Signed-off-by: NMichal Ludvig <michal@logix.cz> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Michal Ludvig 提交于
Merge padlock-generic.c into padlock-aes.c and compile AES as a standalone module. We won't make a monolithic padlock.ko with all supported algorithms, instead we'll compile each driver into its own module. Signed-off-by: NMichal Ludvig <michal@logix.cz> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Herbert Xu 提交于
The crypto API is made up of the part facing users such as IPsec and the low-level part which is used by cryptographic entities such as algorithms. This patch splits out the latter so that the two APIs are more clearly delineated. As a bonus the low-level API can now be modularised if all algorithms are built as modules. Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
- 31 10月, 2005 1 次提交
-
-
由 Brian Gerst 提交于
Add CONFIG_X86_32 for i386. This allows selecting options that only apply to 32-bit systems. (X86 && !X86_64) becomes X86_32 (X86 || X86_64) becomes X86 Signed-off-by: NBrian Gerst <bgerst@didntduck.org> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 17 4月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
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!
-