- 09 12月, 2013 1 次提交
-
-
由 Takashi Iwai 提交于
Use the new helper, request_firmware_direct(), for avoiding the lengthy timeout of non-existing firmware loads. Especially the Intel microcode driver suffers from this problem because each CPU triggers the f/w loading, thus it ends up taking (literally) hours with many cores. Tested-by: NPrarit Bhargava <prarit@redhat.com> Acked-by: NBorislav Petkov <bp@suse.de> Signed-off-by: NTakashi Iwai <tiwai@suse.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 13 11月, 2013 1 次提交
-
-
由 Thomas Renninger 提交于
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: NThomas Renninger <trenn@suse.de> Acked-by: NBorislav Petkov <bp@suse.de> Cc: <stable@kernel.org> Link: http://lkml.kernel.org/r/1384274383-43510-1-git-send-email-trenn@suse.deSigned-off-by: NIngo Molnar <mingo@kernel.org>
-
- 27 9月, 2013 1 次提交
-
-
由 Suravee Suthikulpanit 提交于
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: NSuravee Suthikulpanit <suravee.suthikulpanit@amd.com> Acked-by: NBorislav Petkov <bp@suse.de> Cc: <bp@alien8.de> Cc: <jacob.w.shin@gmail.com> Cc: <herrmann.der.user@googlemail.com> Link: http://lkml.kernel.org/r/1285806432-1995-1-git-send-email-suravee.suthikulpanit@amd.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
-
- 13 8月, 2013 1 次提交
-
-
由 Torsten Kaiser 提交于
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: NTorsten Kaiser <just.for.lkml@googlemail.com> [ Fengguang: build fix ] Signed-off-by: NFengguang Wu <fengguang.wu@intel.com> [ Boris: adapt it to current tree. ] Signed-off-by: NBorislav Petkov <bp@suse.de>
-
- 31 7月, 2013 1 次提交
-
-
由 Torsten Kaiser 提交于
Return -1 (like Intels apply_microcode) when the loading fails, also do not set the active microcode level on failure. Signed-off-by: NTorsten Kaiser <just.for.lkml@googlemail.com> Link: http://lkml.kernel.org/r/20130723225823.2e4e7588@googlemail.comAcked-by: NBorislav Petkov <bp@suse.de> Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
-
- 31 5月, 2013 2 次提交
-
-
由 Jacob Shin 提交于
Add early microcode patch loading support for AMD. Signed-off-by: NJacob Shin <jacob.shin@amd.com> Link: http://lkml.kernel.org/r/1369940959-2077-5-git-send-email-jacob.shin@amd.comSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com> Cc: Fenghua Yu <fenghua.yu@intel.com>
-
由 Jacob Shin 提交于
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: NJacob Shin <jacob.shin@amd.com> Link: http://lkml.kernel.org/r/1369940959-2077-4-git-send-email-jacob.shin@amd.comSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com> Cc: Fenghua Yu <fenghua.yu@intel.com>
-
- 21 11月, 2012 1 次提交
-
-
由 Boris Ostrovsky 提交于
Add valid patch size for family 16h processors. [ hpa: promoting to urgent/stable since it is hw enabling and trivial ] Signed-off-by: NBoris Ostrovsky <boris.ostrovsky@amd.com> Acked-by: NAndreas Herrmann <herrmann.der.user@googlemail.com> Link: http://lkml.kernel.org/r/1353004910-2204-1-git-send-email-boris.ostrovsky@amd.comSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com> Cc: <stable@vger.kernel.org>
-
- 30 10月, 2012 1 次提交
-
-
由 Andreas Herrmann 提交于
Signed-off-by: NAndreas Herrmann <herrmann.der.user@googlemail.com> Cc: lm-sensors@lm-sensors.org Cc: oprofile-list@lists.sf.net Cc: Stephane Eranian <eranian@google.com> Cc: Robert Richter <rric@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Jorg Roedel <joro@8bytes.org> Cc: Rafael J. Wysocki <rjw@sisk.pl> Cc: Jean Delvare <khali@linux-fr.org> Cc: Guenter Roeck <linux@roeck-us.net> Link: http://lkml.kernel.org/r/20121029175138.GC5024@tweetySigned-off-by: NIngo Molnar <mingo@kernel.org>
-
- 20 9月, 2012 1 次提交
-
-
由 Dan Carpenter 提交于
list_for_each_entry_reverse() dereferences the iterator, but we already freed it. I don't see a reason that this has to be done in reverse order so change it to use list_for_each_entry_safe(). Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>
-
- 23 8月, 2012 8 次提交
-
-
由 Borislav Petkov 提交于
Limit the access to userspace only on the BSP where we load the container, verify the patches in it and put them in the patch cache. Then, at application time, we lookup the correct patch in the cache and use it. When we need to reload the userspace container, we do that over the reload interface: echo 1 > /sys/devices/system/cpu/microcode/reload which reloads (a possibly newer) container from userspace and applies then the newest patches from there. Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com> Link: http://lkml.kernel.org/r/1344361461-10076-13-git-send-email-bp@amd64.orgSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>
-
由 Borislav Petkov 提交于
This is a trivial cache which collects all ucode patches for the current family of CPUs on the system. If a newer patch appears due to the container file being updated in userspace, we replace our cached version with the new one. Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com> Link: http://lkml.kernel.org/r/1344361461-10076-12-git-send-email-bp@amd64.orgSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>
-
由 Borislav Petkov 提交于
We search the equivalence table using the CPUID(1) signature of the CPU in order to get the equivalence ID of the patch which we need to apply. Add a function which does the reverse - it will be needed in later patches. While at it, pull the other equiv table function up in the file so that it can be used by other functionality without forward declarations. Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com> Link: http://lkml.kernel.org/r/1344361461-10076-11-git-send-email-bp@amd64.orgSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>
-
由 Borislav Petkov 提交于
This is done in preparation for teaching the ucode driver to either load a new ucode patches container from userspace or use an already cached version. No functionality change in this patch. Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com> Link: http://lkml.kernel.org/r/1344361461-10076-10-git-send-email-bp@amd64.orgSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>
-
由 Borislav Petkov 提交于
Read the CPUID(1).EAX leaf at the correct cpu and use it to search the equivalence table for matching microcode patch. No functionality change. Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com> Link: http://lkml.kernel.org/r/1344361461-10076-9-git-send-email-bp@amd64.orgSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>
-
由 Borislav Petkov 提交于
Make sure we're actually applying a microcode patch to a core which really needs it. This brings only a very very very minor slowdown on F10: 0.032218828 sec vs 0.056010626 sec with this patch. And small speedup on F15: 0.487089449 sec vs 0.180551162 sec (from perf output). Also, fixup comments while at it. Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com> Link: http://lkml.kernel.org/r/1344361461-10076-8-git-send-email-bp@amd64.orgSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>
-
由 Borislav Petkov 提交于
get_ucode_data was a trivial memcpy wrapper. Remove it so as not to obfuscate code unnecessarily with no obvious gain. No functional change. Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com> Link: http://lkml.kernel.org/r/1344361461-10076-7-git-send-email-bp@amd64.orgSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>
-
由 Andreas Herrmann 提交于
This issue was recently observed on an AMD C-50 CPU where a patch of maximum size was applied. Commit be62adb4 ("x86, microcode, AMD: Simplify ucode verification") added current_size in get_matching_microcode(). This is calculated as size of the ucode patch + 8 (ie. size of the header). Later this is compared against the maximum possible ucode patch size for a CPU family. And of course this fails if the patch has already maximum size. Cc: <stable@vger.kernel.org> [3.3+] Signed-off-by: NAndreas Herrmann <andreas.herrmann3@amd.com> Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com> Link: http://lkml.kernel.org/r/1344361461-10076-1-git-send-email-bp@amd64.orgSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>
-
- 13 4月, 2012 1 次提交
-
-
由 Andreas Herrmann 提交于
Exit early when there's no support for a particular CPU family. Also, fixup the "no support for this CPU vendor" to be issued only when the driver is attempted to be loaded on an unsupported vendor. Cc: stable@vger.kernel.org Cc: Tigran Aivazian <tigran@aivazian.fsnet.co.uk> Signed-off-by: NAndreas Herrmann <andreas.herrmann3@amd.com> Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Link: http://lkml.kernel.org/r/20120411163849.GE4794@alberich.amd.com [Boris: add a commit msg because Andreas is lazy] Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>
-
- 07 2月, 2012 1 次提交
-
-
由 Prarit Bhargava 提交于
AMD processors will never support /dev/cpu/microcode updating so just silently fail instead of printing out a warning for every cpu. Signed-off-by: NPrarit Bhargava <prarit@redhat.com> Cc: Borislav Petkov <borislav.petkov@amd.com> Link: http://lkml.kernel.org/r/1328552935-965-1-git-send-email-prarit@redhat.comSigned-off-by: NIngo Molnar <mingo@elte.hu>
-
- 26 1月, 2012 1 次提交
-
-
由 Andreas Herrmann 提交于
We've decided to provide CPU family specific container files (starting with CPU family 15h). E.g. for family 15h we have to load microcode_amd_fam15h.bin instead of microcode_amd.bin Rationale is that starting with family 15h patch size is larger than 2KB which was hard coded as maximum patch size in various microcode loaders (not just Linux). Container files which include patches larger than 2KB cause different kinds of trouble with such old patch loaders. Thus we have to ensure that the default container file provides only patches with size less than 2KB. Signed-off-by: NAndreas Herrmann <andreas.herrmann3@amd.com> Cc: Borislav Petkov <borislav.petkov@amd.com> Cc: <stable@kernel.org> Link: http://lkml.kernel.org/r/20120120164412.GD24508@alberich.amd.com [ documented the naming convention and tidied the code a bit. ] Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 14 12月, 2011 5 次提交
-
-
由 Borislav Petkov 提交于
Add Andreas and me as current maintainers. Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>
-
由 Borislav Petkov 提交于
Once we've found and validated the ucode patch for the current CPU, there's no need to iterate over the remaining patches in the binary image. Exit then and save us a bunch of cycles. Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>
-
由 Borislav Petkov 提交于
Basically, what we did until now is take out a chunk of the firmware image, vmalloc space for it and inspect it before application. And repeat. This patch changes all that so that we look at each ucode patch from the firmware image, check it for sanity and copy it to local buffer for application only once and if it passes all checks. Thus, vmalloc-ing for each piece is gone, we can do proper size checking only of the patch which is destined for the CPU of the current machine instead of each single patch, which is clearly wrong. Oh yeah, simplify and cleanup the code while at it, along with adding comments as to what actually happens. Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>
-
由 Borislav Petkov 提交于
Add a simple 4K page which gets allocated on driver init and freed on driver exit instead of vmalloc'ing small buffers for each ucode patch. Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>
-
由 Borislav Petkov 提交于
This will be used to do cleanup work before the driver exits. Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>
-
- 19 10月, 2011 1 次提交
-
-
由 Borislav Petkov 提交于
Enable microcode revision output for AMD after 506ed6b5 ("x86, intel: Output microcode revision in /proc/cpuinfo") did it for Intel. Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>
-
- 16 6月, 2011 1 次提交
-
-
由 Borislav Petkov 提交于
The ucode size check has to take the section header size into account too when sanity checking the section length. Shorten and clarify define names, while at it. Caught-by: NBen Hutchings <ben@decadent.org.uk> Link: http://lkml.kernel.org/r/1302752223.5282.674.camel@localhostSigned-off-by: NBorislav Petkov <borislav.petkov@amd.com>
-
- 15 6月, 2011 1 次提交
-
-
由 Borislav Petkov 提交于
Both the equivalence table and the microcode patch types are u32. Access them properly through the buf-ptr. Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>
-
- 20 2月, 2011 1 次提交
-
-
由 Dan Carpenter 提交于
install_equiv_cpu_table() returns type int. It uses negative error codes so using an unsigned type breaks the error handling. Signed-off-by: NDan Carpenter <error27@gmail.com> Acked-by: NBorislav Petkov <borislav.petkov@amd.com> Cc: open list:AMD MICROCODE UPD... <amd64-microcode@amd64.org> Cc: Andreas Herrmann <andreas.herrmann3@amd.com> LKML-Reference: <20110218091716.GA4384@bicker> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 10 2月, 2011 1 次提交
-
-
由 Borislav Petkov 提交于
The different families have a different max size for the ucode patch, adjust size checking to the family we're running on. Also, do not vzalloc the max size of the ucode but only the actual size that is passed on from the firmware loader. Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>
-
- 09 2月, 2011 5 次提交
-
-
由 Borislav Petkov 提交于
Unify pr_* to use pr_fmt, shorten messages, correct type formatting. Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com> Acked-by: NAndreas Herrmann <Andreas.Herrmann3@amd.com>
-
由 Borislav Petkov 提交于
collect_cpu_info_amd() clears its csig arg but this is done in the microcode_core's collect_cpu_info() by clearing the embedding struct ucode_cpu_info. Drop it. Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com> Acked-by: NAndreas Herrmann <Andreas.Herrmann3@amd.com>
-
由 Borislav Petkov 提交于
Do not copy the section header but look at it directly through the pointer. Also, make it return a ptr to a ucode header directly thus dropping a bunch of unneeded casts. Finally, simplify generic_load_microcode(), while at it. Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com> Acked-by: NAndreas Herrmann <Andreas.Herrmann3@amd.com>
-
由 Borislav Petkov 提交于
There's no need to memcpy the ucode header in order to look at it only in this function - use the original buffer instead. Also, fix return type semantics by returning a negative value on error and a positive otherwise. Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com> Acked-by: NAndreas Herrmann <Andreas.Herrmann3@amd.com>
-
由 Borislav Petkov 提交于
When the ucode magic is wrong, for whatever reason, we don't release the loaded firmware binary and its related resources. Make sure we do. Also, fix function naming to fit this driver's convention and shorten variable names. Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com> Acked-by: NAndreas Herrmann <Andreas.Herrmann3@amd.com>
-
- 10 11月, 2010 3 次提交
-
-
由 Borislav Petkov 提交于
get_ucode_data is a memcpy() wrapper which always returns 0. Move it into the header and make it an inline. Remove all code checking its return value and turn it into a void. There should be no functionality change resulting from this patch. Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>
-
由 Jesper Juhl 提交于
We don't have to do memset() ourselves after vmalloc() when we have vzalloc(), so change that in arch/x86/kernel/microcode_amd.c::get_next_ucode(). Signed-off-by: NJesper Juhl <jj@chaosbits.net> Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>
-
由 Jesper Juhl 提交于
The [vk][cmz]alloc(_node) family of functions return void pointers which it's completely unnecessary/pointless to cast to other pointer types since that happens implicitly. This patch removes such casts from arch/x86. Signed-off-by: NJesper Juhl <jj@chaosbits.net> Cc: trivial@kernel.org Cc: amd64-microcode@amd64.org Cc: Andreas Herrmann <andreas.herrmann3@amd.com> LKML-Reference: <alpine.LNX.2.00.1011082310220.23697@swampdragon.chaosbits.net> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 23 1月, 2010 1 次提交
-
-
由 Andreas Herrmann 提交于
Commit d1c84f79 leads to a regression when microcode_amd.c is compiled into the kernel. It causes a big boot delay because the firmware is not available. See http://marc.info/?l=linux-kernel&m=126267290920060 It also renders the reload sysfs attribute useless. Fixing this is too intrusive for an -rc5 kernel. Thus I'd like to restore the microcode loading behaviour of kernel 2.6.32. CC: Gene Heskett <gene.heskett@verizon.net> Signed-off-by: NAndreas Herrmann <andreas.herrmann3@amd.com> LKML-Reference: <20100122203456.GB13792@alberich.amd.com> Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
-