almost everything stays the same, we need just to use the extended registers
on the bit variant.
Signed-off-by: Sebastian Andrzej Siewior sebast...@breakpoint.cc
---
drivers/crypto/Kconfig |2 +-
drivers/crypto/padlock-aes.c | 13 +
2 files changed, 14 insertions(+), 1
To enable the padlock unit, two msr bits have to flipped. This is allready
done in the 32bit path and is missing in the other. Instead of copy paste
the code, I merged the 64bit part into the 32bit part. The things that
changed during the merge:
- the fixups from x86_64 (family 6, model = 15) were
there should be no difference, except
* the 64bit variant now also initializes the padlock unit.
* -c_early_init() is executed again from -c_init()
* the 64bit fixups made into 32bit path.
Signed-off-by: Sebastian Andrzej Siewior sebast...@breakpoint.cc
---
arch/x86/Kconfig.cpu |
* Ingo Molnar | 2009-03-14 12:47:32 [+0100]:
thanks, looks good. We can apply #1 to -tip just fine - but a
drivers/crypto/ change should go via the crypto tree. Can the
crypto tree apply #2 without having #1 right away? [i.e. will it
still build and boot fine - even though the padlock
* Sebastian Andrzej Siewior sebast...@breakpoint.cc wrote:
To enable the padlock unit, two msr bits have to flipped. This is allready
done in the 32bit path and is missing in the other. Instead of copy paste
the code, I merged the 64bit part into the 32bit part. The things that
changed
On Sat, Mar 14, 2009 at 12:53:07PM +0100, Sebastian Andrzej Siewior wrote:
Yep, it is fine.
#1 in, #2 not will not result in any difference to what we have now.
#2 in, #1 not will result in padlock not detected while loading the
module and -ENODEV.
Let's merge #1 right now and I'll pick up
