* Sebastian Andrzej Siewior <sebastian@xxxxxxxxxxxxx> 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 fixups from x86_64 (family 6, model >= 15) were not present in 32bit > path but are now. They might be usefull if this CPU is booted in 32bit > mode. > - the fixups which are executed via ->c_early_init() are now executed > again via ->c_init(). This was done in the 64bit path and without this I > lost the constant_tsc flag. However, tsc is not useable due to > | [ 2.023006] Marking TSC unstable due to TSC halts in idle > | [ 2.500082] Clocksource tsc unstable (delta = -326436711 ns) > > The two patches are against the current tip tree. A version of > patch 1 against current -rc8 is available at [0]. 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 functionality might not be fully present on 32-bit? ] Then in 2.6.30 once both the x86 tree and the crypto tree are merged we'll have both changes combined. Does that sound good? Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
