On 20/05/07 04:15, Herbert Xu wrote:
On Sat, May 19, 2007 at 08:28:17PM +0100, Simon Arlott wrote:
It should be a bool that doesn't select anything, the AES and SHA modules
will select CRYPTO_ALGAPI. It could also depend on MVIAC3_2 || MVIA_C7
instead of X86_32.
Having it as a tristate means
On 20/05/07 04:15, Herbert Xu wrote:
On Sat, May 19, 2007 at 08:28:17PM +0100, Simon Arlott wrote:
It should be a bool that doesn't select anything, the AES and SHA modules
will select CRYPTO_ALGAPI. It could also depend on MVIAC3_2 || MVIA_C7
instead of X86_32.
Having it as a tristate means
On Sat, May 19, 2007 at 08:28:17PM +0100, Simon Arlott wrote:
>
> It should be a bool that doesn't select anything, the AES and SHA modules
> will select CRYPTO_ALGAPI. It could also depend on MVIAC3_2 || MVIA_C7
> instead of X86_32.
Having it as a tristate means that we don't have to
On Sat, May 19, 2007 at 08:28:17PM +0100, Simon Arlott wrote:
> > BTW, I noticed that this prevented CRYPTO_ALGAPI from being marked as m
> > since it was selected by CRYPTO_DEV_PADLOCK. So I'm turning it into a
> > tristate again.
>
> It should be a bool that doesn't select anything, the
On 18/05/07 07:45, Herbert Xu wrote:
On Sun, Apr 29, 2007 at 09:01:10AM +0100, Simon Arlott wrote:
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
On Sat, May 19, 2007 at 08:28:17PM +0100, Simon Arlott wrote:
BTW, I noticed that this prevented CRYPTO_ALGAPI from being marked as m
since it was selected by CRYPTO_DEV_PADLOCK. So I'm turning it into a
tristate again.
It should be a bool that doesn't select anything, the AES and
On Sat, May 19, 2007 at 08:28:17PM +0100, Simon Arlott wrote:
It should be a bool that doesn't select anything, the AES and SHA modules
will select CRYPTO_ALGAPI. It could also depend on MVIAC3_2 || MVIA_C7
instead of X86_32.
Having it as a tristate means that we don't have to duplicate
On Sun, Apr 29, 2007 at 09:01:10AM +0100, Simon Arlott wrote:
> 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
On Sun, Apr 29, 2007 at 09:01:10AM +0100, Simon Arlott wrote:
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
On Sun, Apr 29, 2007 at 09:01:10AM +0100, Simon Arlott wrote:
>
> Well that's mostly the point - it shouldn't get compiled in - ever,
> but it also has other modules depending on it in Kconfig that
> shouldn't need to be modules.
Patch applied. Thanks!
--
Visit Openswan at
On Sun, Apr 29, 2007 at 09:01:10AM +0100, Simon Arlott wrote:
Well that's mostly the point - it shouldn't get compiled in - ever,
but it also has other modules depending on it in Kconfig that
shouldn't need to be modules.
Patch applied. Thanks!
--
Visit Openswan at
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
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
13 matches
Mail list logo
