On Mon, Apr 20, 2009 at 06:09:31PM -0400, Chuck Ebbert wrote:
#1 is in 2.6.30-rc now but I don't see #2 pending anywhere.
Thanks for the reminder. I've now added it to cryptodev.
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} herb...@gondor.apana.org.au
Home Page:
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
* 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
