almost everything stays the same, we need just to use the extended registers
on the bit variant.
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/crypto/Kconfig |2 +-
drivers/crypto/padlock-aes.c | 13 +
2 files changed, 14 insertions(+), 1 deletions(-)
diff --git a
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
---
arch/x86/Kconfig.cpu | 17 +
a
* 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
>fun
* Sebastian Andrzej Siewior 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 during the merge:
> - the
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 pi
