On Fri, Oct 19, 2018 at 05:11:37PM -0700, Andi Kleen wrote: > From: Andi Kleen <[email protected]> > > The Intel ucode revision space is unsigned. Inside Intel there are special
s/ucode/microcode/g > microcodes that have the highest bit set, and they are considered to have s/microcodes/microcode revisions/g > a higher revision than any microcodes that don't have this bit set. > > The function comparing the microcodes in the Linux driver compares > u32 with int, which ends up being signed extended to long on 64bit > systems. This results in these highest bit set microcodes not loading > because their revision appears negative and smaller than the > existing microcode. > > Change the comparison to unsigned. With that the loading works > as expected. > > Signed-off-by: Andi Kleen <[email protected]> > --- > arch/x86/kernel/cpu/microcode/intel.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/x86/kernel/cpu/microcode/intel.c > b/arch/x86/kernel/cpu/microcode/intel.c > index 16936a24795c..e95cebdd5993 100644 > --- a/arch/x86/kernel/cpu/microcode/intel.c > +++ b/arch/x86/kernel/cpu/microcode/intel.c > @@ -93,7 +93,7 @@ static int find_matching_signature(void *mc, unsigned int > csig, int cpf) > /* > * Returns 1 if update has been found, 0 otherwise. > */ > -static int has_newer_microcode(void *mc, unsigned int csig, int cpf, int > new_rev) > +static int has_newer_microcode(void *mc, unsigned int csig, int cpf, > unsigned new_rev) I'm gonna let you run checkpatch yourself to find out what the problem here is. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
