- 09 5月, 2007 1 次提交
-
-
由 David Sterba 提交于
Fix several typos in help text in Kconfig* files. Signed-off-by: NDavid Sterba <dave@jikos.cz> Signed-off-by: NAdrian Bunk <bunk@stusta.de>
-
- 02 5月, 2007 1 次提交
-
-
由 Simon Arlott 提交于
When this is compiled in it is run too early to do anything useful: [ 6.052000] padlock: No VIA PadLock drivers have been loaded. [ 6.052000] padlock: Using VIA PadLock ACE for AES algorithm. [ 6.052000] padlock: Using VIA PadLock ACE for SHA1/SHA256 algorithms. When it's a module it isn't doing anything special, the same functionality can be provided in userspace by "probeall padlock padlock-aes padlock-sha" in modules.conf if it is required. Signed-off-by: NSimon Arlott <simon@fire.lp0.eu> Cc: Michal Ludvig <michal@logix.cz> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
- 06 2月, 2007 1 次提交
-
-
由 Jan Glauber 提交于
Starting with the z9 the CPU Cryptographic Assist Facility comes with an integrated Pseudo Random Number Generator. The generator creates random numbers by an algorithm similar to the ANSI X9.17 standard. The pseudo-random numbers can be accessed via a character device driver node called /dev/prandom. Similar to /dev/urandom any amount of bytes can be read from the device without blocking. Signed-off-by: NJan Glauber <jan.glauber@de.ibm.com> Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
-
- 11 12月, 2006 1 次提交
-
-
由 Randy Dunlap 提交于
This driver seems to be for a PCI device. drivers/crypto/geode-aes.c:384: warning: implicit declaration of function 'pci_release_regions' drivers/crypto/geode-aes.c:397: warning: implicit declaration of function 'pci_request_regions' Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com> Acked-by: NJordan Crouse <jordan.crouse@amd.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 07 12月, 2006 1 次提交
-
-
由 Jordan Crouse 提交于
Add a driver to support the AES hardware on the Geode LX processor. Signed-off-by: NJordan Crouse <jordan.crouse@amd.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
- 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!
-