lwn.git/arch/x86/kernel/microcode_amd.c, branch docs-5.3

x86, microcode: Move to a proper location

2014-01-13T19:00:12+00:00

We've grown a bunch of microcode loader files all prefixed with "microcode_". They should be under cpu/ because this is strictly CPU-related functionality so do that and drop the prefix since they're in their own directory now which gives that prefix. :) While at it, drop MICROCODE_INTEL_LIB config item and stash the functionality under CONFIG_MICROCODE_INTEL as it was its only user. Signed-off-by: Borislav Petkov Tested-by: Aravind Gopalakrishnan

x86, microcode, AMD: Fix early ucode loading

2014-01-13T18:59:38+00:00

The original idea to use the microcode cache for the APs doesn't pan out because we do memory allocation there very early and with IRQs disabled and we don't want to involve GFP_ATOMIC allocations. Not if it can be helped. Thus, extend the caching of the BSP patch approach to the APs and iterate over the ucode in the initrd instead of using the cache. We still save the relevant patches to it but later, right before we jettison the initrd. While at it, fix early ucode loading on 32-bit too. Signed-off-by: Borislav Petkov Tested-by: Aravind Gopalakrishnan

x86/microcode/amd: Tone down printk(), don't treat a missing firmware file as an error

2013-11-12T21:03:49+00:00

Do it the same way as done in microcode_intel.c: use pr_debug() for missing firmware files. There seem to be CPUs out there for which no microcode update has been submitted to kernel-firmware repo yet resulting in scary sounding error messages in dmesg: microcode: failed to load file amd-ucode/microcode_amd_fam16h.bin Signed-off-by: Thomas Renninger Acked-by: Borislav Petkov Cc: Link: http://lkml.kernel.org/r/1384274383-43510-1-git-send-email-trenn@suse.de Signed-off-by: Ingo Molnar

x86/microcode/AMD: Fix patch level reporting for family 15h

2013-09-27T07:29:27+00:00

On AMD family 14h, applying microcode patch on the a core (core0) would also affect the other core (core1) in the same compute unit. The driver would skip applying the patch on core1, but it still need to update kernel structures to reflect the proper patch level. The current logic is not updating the struct ucode_cpu_info.cpu_sig.rev of the skipped core. This causes the /sys/devices/system/cpu/cpu1/microcode/version to report incorrect patch level as shown below: $ grep . cpu?/microcode/version cpu0/microcode/version:0x600063d cpu1/microcode/version:0x6000626 cpu2/microcode/version:0x600063d cpu3/microcode/version:0x6000626 cpu4/microcode/version:0x600063d Signed-off-by: Suravee Suthikulpanit Acked-by: Borislav Petkov Cc: Cc: Cc: Link: http://lkml.kernel.org/r/1285806432-1995-1-git-send-email-suravee.suthikulpanit@amd.com Signed-off-by: Ingo Molnar

x86, microcode, AMD: Fix early microcode loading

2013-08-12T16:32:45+00:00

load_microcode_amd() (and the helper it is using) should not have an cpu parameter. The microcode loading does not depend on the CPU wrt the patches loaded since they 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 (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 [ Fengguang: build fix ] Signed-off-by: Fengguang Wu [ Boris: adapt it to current tree. ] Signed-off-by: Borislav Petkov

x86, amd, microcode: Fix error path in apply_microcode_amd()

2013-07-31T15:37:14+00:00

Return -1 (like Intels apply_microcode) when the loading fails, also do not set the active microcode level on failure. Signed-off-by: Torsten Kaiser Link: http://lkml.kernel.org/r/20130723225823.2e4e7588@googlemail.com Acked-by: Borislav Petkov Signed-off-by: H. Peter Anvin

x86, microcode, amd: Early microcode patch loading support for AMD

2013-05-31T03:19:25+00:00

Add early microcode patch loading support for AMD. Signed-off-by: Jacob Shin Link: http://lkml.kernel.org/r/1369940959-2077-5-git-send-email-jacob.shin@amd.com Signed-off-by: H. Peter Anvin Cc: Fenghua Yu

x86, microcode, amd: Refactor functions to prepare for early loading

2013-05-31T03:19:25+00:00

In preparation work for early loading, refactor some common functions that will be shared, and move some struct defines to a common header file. Signed-off-by: Jacob Shin Link: http://lkml.kernel.org/r/1369940959-2077-4-git-send-email-jacob.shin@amd.com Signed-off-by: H. Peter Anvin Cc: Fenghua Yu

x86, microcode, AMD: Add support for family 16h processors

2012-11-21T06:23:28+00:00

Add valid patch size for family 16h processors. [ hpa: promoting to urgent/stable since it is hw enabling and trivial ] Signed-off-by: Boris Ostrovsky Acked-by: Andreas Herrmann Link: http://lkml.kernel.org/r/1353004910-2204-1-git-send-email-boris.ostrovsky@amd.com Signed-off-by: H. Peter Anvin Cc:

x86, microcode_amd: Change email addresses, MAINTAINERS entry

2012-10-30T09:05:52+00:00

Signed-off-by: Andreas Herrmann Cc: lm-sensors@lm-sensors.org Cc: oprofile-list@lists.sf.net Cc: Stephane Eranian Cc: Robert Richter Cc: Borislav Petkov Cc: Jorg Roedel Cc: Rafael J. Wysocki Cc: Jean Delvare Cc: Guenter Roeck Link: http://lkml.kernel.org/r/20121029175138.GC5024@tweety Signed-off-by: Ingo Molnar