On Tue, Jul 23, 2013 at 11:06:10PM +0200, Torsten Kaiser wrote:
> load_microcode_amd() (and the helper it is using) should not have an
> cpu parameter. The microcode loading is not depending on the CPU it is
> executed and all the loaded patches will end up in a global list for all
> CPUs anyway.
> The change from cpu to x86family in load_microcode_amd() now allows to drop
> the code messing with cpu_data(cpu) from collect_cpu_info_amd_early(), which
> is wrong anyway because at that point the per-cpu cpu_info is not yet setup.
> And these values would later be overwritten by smp_store_boot_cpu_info() /
> smp_store_cpu_info().
>
> Fold the rest of collect_cpu_info_amd_early() into load_ucode_amd_ap(),
> because its
> only used at one place and without the cpuinfo_x86 accesses it was not much
> left.
>
> Signed-off-by: Torsten Kaiser <just.for.l...@googlemail.com>
Btw, this patch is the one that fixes the boot issue on your box, correct?
If so, please put a minimal version of it in the next patch set you're
sending right after
[PATCH v2] x86, AMD: Make cpu_has_amd_erratum() use the correct struct
cpuinfo_x86
[PATCH 1/5] x86, AMD: fix error path in apply_microcode_amd()
So that all fixes can go in now.
Basically, we need the fixes to be first in the patchset so that they
can be applied straight to tip:urgent.
The cleanups/improvements you're doing afterwards could wait then for
the next merge window.
Thanks a lot!
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
