aboutsummaryrefslogtreecommitdiff
path: root/arch/x86/platform
AgeCommit message (Collapse)AuthorFilesLines
2014-10-03x86/efi: Clear EFI_RUNTIME_SERVICES if failing to enter virtual modeDave Young1-1/+5
If enter virtual mode failed due to some reason other than the efi call the EFI_RUNTIME_SERVICES bit in efi.flags should be cleared thus users of efi runtime services can check the bit and handle the case instead of assume efi runtime is ok. Per Matt, if efi call SetVirtualAddressMap fails we will be not sure it's safe to make any assumptions about the state of the system. So kernel panics instead of clears EFI_RUNTIME_SERVICES bit. Signed-off-by: Dave Young <[email protected]> Signed-off-by: Matt Fleming <[email protected]>
2014-10-03efi: Add kernel param efi=noruntimeDave Young1-2/+2
noefi kernel param means actually disabling efi runtime, Per suggestion from Leif Lindholm efi=noruntime should be better. But since noefi is already used in X86 thus just adding another param efi=noruntime for same purpose. Signed-off-by: Dave Young <[email protected]> Signed-off-by: Matt Fleming <[email protected]>
2014-10-03lib: Add a generic cmdline parse function parse_option_strDave Young1-20/+2
There should be a generic function to parse params like a=b,c Adding parse_option_str in lib/cmdline.c which will return true if there's specified option set in the params. Also updated efi=old_map parsing code to use the new function Signed-off-by: Dave Young <[email protected]> Signed-off-by: Matt Fleming <[email protected]>
2014-10-03efi: Move noefi early param code out of x86 arch codeDave Young1-9/+1
noefi param can be used for arches other than X86 later, thus move it out of x86 platform code. Signed-off-by: Dave Young <[email protected]> Signed-off-by: Matt Fleming <[email protected]>
2014-10-03efi-bgrt: Add error handling; inform the user when ignoring the BGRTJosh Triplett1-6/+30
Gracefully handle failures to allocate memory for the image, which might be arbitrarily large. efi_bgrt_init can fail in various ways as well, usually because the BIOS-provided BGRT structure does not match expectations. Add appropriate error messages rather than failing silently. Reported-by: Srihari Vijayaraghavan <[email protected]> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=81321 Signed-off-by: Josh Triplett <[email protected]> Signed-off-by: Matt Fleming <[email protected]>
2014-10-03efi: Add efi= parameter parsing to the EFI boot stubMatt Fleming1-2/+17
We need a way to customize the behaviour of the EFI boot stub, in particular, we need a way to disable the "chunking" workaround, used when reading files from the EFI System Partition. One of my machines doesn't cope well when reading files in 1MB chunks to a buffer above the 4GB mark - it appears that the "chunking" bug workaround triggers another firmware bug. This was only discovered with commit 4bf7111f5016 ("x86/efi: Support initrd loaded above 4G"), and that commit is perfectly valid. The symptom I observed was a corrupt initrd rather than any kind of crash. efi= is now used to specify EFI parameters in two very different execution environments, the EFI boot stub and during kernel boot. There is also a slight performance optimization by enabling efi=nochunk, but that's offset by the fact that you're more likely to run into firmware issues, at least on x86. This is the rationale behind leaving the workaround enabled by default. Also provide some documentation for EFI_READ_CHUNK_SIZE and why we're using the current value of 1MB. Tested-by: Ard Biesheuvel <[email protected]> Cc: Roy Franz <[email protected]> Cc: Maarten Lankhorst <[email protected]> Cc: Leif Lindholm <[email protected]> Cc: Borislav Petkov <[email protected]> Signed-off-by: Matt Fleming <[email protected]>
2014-08-26uv: Replace __get_cpu_varChristoph Lameter1-20/+20
Use __this_cpu_read instead. Cc: Hedi Berriche <[email protected]> Cc: Mike Travis <[email protected]> Cc: Dimitri Sivanich <[email protected]> Signed-off-by: Christoph Lameter <[email protected]> Signed-off-by: Tejun Heo <[email protected]>
2014-08-26x86: Replace __get_cpu_var usesChristoph Lameter1-1/+1
__get_cpu_var() is used for multiple purposes in the kernel source. One of them is address calculation via the form &__get_cpu_var(x). This calculates the address for the instance of the percpu variable of the current processor based on an offset. Other use cases are for storing and retrieving data from the current processors percpu area. __get_cpu_var() can be used as an lvalue when writing data or on the right side of an assignment. __get_cpu_var() is defined as : #define __get_cpu_var(var) (*this_cpu_ptr(&(var))) __get_cpu_var() always only does an address determination. However, store and retrieve operations could use a segment prefix (or global register on other platforms) to avoid the address calculation. this_cpu_write() and this_cpu_read() can directly take an offset into a percpu area and use optimized assembly code to read and write per cpu variables. This patch converts __get_cpu_var into either an explicit address calculation using this_cpu_ptr() or into a use of this_cpu operations that use the offset. Thereby address calculations are avoided and less registers are used when code is generated. Transformations done to __get_cpu_var() 1. Determine the address of the percpu instance of the current processor. DEFINE_PER_CPU(int, y); int *x = &__get_cpu_var(y); Converts to int *x = this_cpu_ptr(&y); 2. Same as #1 but this time an array structure is involved. DEFINE_PER_CPU(int, y[20]); int *x = __get_cpu_var(y); Converts to int *x = this_cpu_ptr(y); 3. Retrieve the content of the current processors instance of a per cpu variable. DEFINE_PER_CPU(int, y); int x = __get_cpu_var(y) Converts to int x = __this_cpu_read(y); 4. Retrieve the content of a percpu struct DEFINE_PER_CPU(struct mystruct, y); struct mystruct x = __get_cpu_var(y); Converts to memcpy(&x, this_cpu_ptr(&y), sizeof(x)); 5. Assignment to a per cpu variable DEFINE_PER_CPU(int, y) __get_cpu_var(y) = x; Converts to __this_cpu_write(y, x); 6. Increment/Decrement etc of a per cpu variable DEFINE_PER_CPU(int, y); __get_cpu_var(y)++ Converts to __this_cpu_inc(y) Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Acked-by: H. Peter Anvin <[email protected]> Acked-by: Ingo Molnar <[email protected]> Signed-off-by: Christoph Lameter <[email protected]> Signed-off-by: Tejun Heo <[email protected]>
2014-08-13Merge branch 'x86-apic-for-linus' of ↵Linus Torvalds4-57/+42
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86/apic updates from Thomas Gleixner: "This is a major overhaul to the x86 apic subsystem consisting of the following parts: - Remove obsolete APIC driver abstractions (David Rientjes) - Use the irqdomain facilities to dynamically allocate IRQs for IOAPICs. This is a prerequisite to enable IOAPIC hotplug support, and it also frees up wasted vectors (Jiang Liu) - Misc fixlets. Despite the hickup in Ingos previous pull request - caused by the missing fixup for the suspend/resume issue reported by Borislav - I strongly recommend that this update finds its way into 3.17. Some history for you: This is preparatory work for physical IOAPIC hotplug. The first attempt to support this was done by Yinghai and I shot it down because it just added another layer of obscurity and complexity to the already existing mess without tackling the underlying shortcomings of the current implementation. After quite some on- and offlist discussions, I requested that the design of this functionality must use generic infrastructure, i.e. irq domains, which provide all the mechanisms to dynamically map linux interrupt numbers to physical interrupts. Jiang picked up the idea and did a great job of consolidating the existing interfaces to manage the x86 (IOAPIC) interrupt system by utilizing irq domains. The testing in tip, Linux-next and inside of Intel on various machines did not unearth any oddities until Borislav exposed it to one of his oddball machines. The issue was resolved quickly, but unfortunately the fix fell through the cracks and did not hit the tip tree before Ingo sent the pull request. Not entirely Ingos fault, I also assumed that the fix was already merged when Ingo asked me whether he could send it. Nevertheless this work has a proper design, has undergone several rounds of review and the final fallout after applying it to tip and integrating it into Linux-next has been more than moderate. It's the ground work not only for IOAPIC hotplug, it will also allow us to move the lowlevel vector allocation into the irqdomain hierarchy, which will benefit other architectures as well. Patches are posted already, but they are on hold for two weeks, see below. I really appreciate the competence and responsiveness Jiang has shown in course of this endavour. So I'm sure that any fallout of this will be addressed in a timely manner. FYI, I'm vanishing for 2 weeks into my annual kids summer camp kitchen duty^Wvacation, while you folks are drooling at KS/LinuxCon :) But HPA will have a look at the hopefully zero fallout until I'm back" * 'x86-apic-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (53 commits) x86, irq, PCI: Keep IRQ assignment for PCI devices during suspend/hibernation x86/apic/vsmp: Make is_vsmp_box() static x86, apic: Remove enable_apic_mode callback x86, apic: Remove setup_portio_remap callback x86, apic: Remove multi_timer_check callback x86, apic: Replace noop_check_apicid_used x86, apic: Remove check_apicid_present callback x86, apic: Remove mps_oem_check callback x86, apic: Remove smp_callin_clear_local_apic callback x86, apic: Replace trampoline physical addresses with defaults x86, apic: Remove x86_32_numa_cpu_node callback x86: intel-mid: Use the new io_apic interfaces x86, vsmp: Remove is_vsmp_box() from apic_is_clustered_box() x86, irq: Clean up irqdomain transition code x86, irq, devicetree: Release IOAPIC pin when PCI device is disabled x86, irq, SFI: Release IOAPIC pin when PCI device is disabled x86, irq, mpparse: Release IOAPIC pin when PCI device is disabled x86, irq, ACPI: Release IOAPIC pin when PCI device is disabled x86, irq: Introduce helper functions to release IOAPIC pin x86, irq: Simplify the way to handle ISA IRQ ...
2014-08-08arch/x86: replace strict_strto callsDaniel Walter1-1/+1
Replace obsolete strict_strto calls with appropriate kstrto calls Signed-off-by: Daniel Walter <[email protected]> Acked-by: Borislav Petkov <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: "H. Peter Anvin" <[email protected]> Cc: Thomas Gleixner <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2014-08-04Merge branch 'x86-uv-for-linus' of ↵Linus Torvalds1-31/+38
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 UV TLB update from Ingo Molnar: "UV TLB shootdown logic updates for version of the UV architecture" * 'x86-uv-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/uv: Update the UV3 TLB shootdown logic
2014-08-04Merge branch 'x86-platform-for-linus' of ↵Linus Torvalds1-41/+53
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 platform updates from Ingo Molnar: "The main changes in this cycle are: - Intel SOC driver updates, by Aubrey Li. - TS5500 platform updates, by Vivien Didelot" * 'x86-platform-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/pmc_atom: Silence shift wrapping warnings in pmc_sleep_tmr_show() x86/pmc_atom: Expose PMC device state and platform sleep state x86/pmc_atom: Eisable a few S0ix wake up events for S0ix residency x86/platform: New Intel Atom SOC power management controller driver x86/platform/ts5500: Add support for TS-5400 boards x86/platform/ts5500: Add a 'name' sysfs attribute x86/platform/ts5500: Use the DEVICE_ATTR_RO() macro
2014-07-18arch/x86: Remove efi_set_rtc_mmss()Daniel Kiper1-36/+0
efi_set_rtc_mmss() is never used to set RTC due to bugs found on many EFI platforms. It is set directly by mach_set_rtc_mmss(). Hence, remove unused efi_set_rtc_mmss() function. Signed-off-by: Daniel Kiper <[email protected]> Signed-off-by: Matt Fleming <[email protected]>
2014-07-18arch/x86: Remove redundant set_bit(EFI_MEMMAP) callDaniel Kiper1-2/+0
Remove redundant set_bit(EFI_MEMMAP, &efi.flags) call. It is executed earlier in efi_memmap_init(). Signed-off-by: Daniel Kiper <[email protected]> Signed-off-by: Matt Fleming <[email protected]>
2014-07-18arch/x86: Remove redundant set_bit(EFI_SYSTEM_TABLES) callDaniel Kiper1-2/+0
Remove redundant set_bit(EFI_SYSTEM_TABLES, &efi.flags) call. It is executed earlier in efi_systab_init(). Signed-off-by: Daniel Kiper <[email protected]> Signed-off-by: Matt Fleming <[email protected]>
2014-07-18efi: Introduce EFI_PARAVIRT flagDaniel Kiper1-6/+25
Introduce EFI_PARAVIRT flag. If it is set then kernel runs on EFI platform but it has not direct control on EFI stuff like EFI runtime, tables, structures, etc. If not this means that Linux Kernel has direct access to EFI infrastructure and everything runs as usual. This functionality is used in Xen dom0 because hypervisor has full control on EFI stuff and all calls from dom0 to EFI must be requested via special hypercall which in turn executes relevant EFI code in behalf of dom0. Signed-off-by: Daniel Kiper <[email protected]> Signed-off-by: Matt Fleming <[email protected]>
2014-07-18arch/x86: Do not access EFI memory map if it is not availableDaniel Kiper1-0/+3
Do not access EFI memory map if it is not available. At least Xen dom0 EFI implementation does not have an access to it. Signed-off-by: Daniel Kiper <[email protected]> Signed-off-by: Matt Fleming <[email protected]>
2014-07-18efi: Use early_mem*() instead of early_io*()Daniel Kiper1-14/+14
Use early_mem*() instead of early_io*() because all mapped EFI regions are memory (usually RAM but they could also be ROM, EPROM, EEPROM, flash, etc.) not I/O regions. Additionally, I/O family calls do not work correctly under Xen in our case. early_ioremap() skips the PFN to MFN conversion when building the PTE. Using it for memory will attempt to map the wrong machine frame. However, all artificial EFI structures created under Xen live in dom0 memory and should be mapped/unmapped using early_mem*() family calls which map domain memory. Signed-off-by: Daniel Kiper <[email protected]> Cc: Leif Lindholm <[email protected]> Cc: Mark Salter <[email protected]> Signed-off-by: Matt Fleming <[email protected]>
2014-07-18x86/reboot: Add EFI reboot quirk for ACPI Hardware Reduced flagMatt Fleming1-0/+23
It appears that the BayTrail-T class of hardware requires EFI in order to powerdown and reboot and no other reliable method exists. This quirk is generally applicable to all hardware that has the ACPI Hardware Reduced bit set, since usually ACPI would be the preferred method. Cc: Len Brown <[email protected]> Cc: Mark Salter <[email protected]> Cc: "Rafael J. Wysocki" <[email protected]> Signed-off-by: Matt Fleming <[email protected]>
2014-07-16x86/platform/ts5500: Add support for TS-5400 boardsVivien Didelot1-8/+13
This patch extends the TS-5500 platform driver to support the similar Technologic Systems TS-5400 Single Board Computer: http://wiki.embeddedarm.com/wiki/TS-5400 Signed-off-by: Vivien Didelot <[email protected]> Acked-by: Thomas Gleixner <[email protected]> Cc: Savoir-faire Linux Inc. <[email protected]> Link: http://lkml.kernel.org/r/1404860269-11837-4-git-send-email-vivien.didelot@savoirfairelinux.com Signed-off-by: Ingo Molnar <[email protected]>
2014-07-16x86/platform/ts5500: Add a 'name' sysfs attributeVivien Didelot1-5/+18
Add a new "name" attribute to the TS5500 sysfs group, to clarify which supported board model it is. Signed-off-by: Vivien Didelot <[email protected]> Acked-by: Thomas Gleixner <[email protected]> Cc: Savoir-faire Linux Inc. <[email protected]> Link: http://lkml.kernel.org/r/1404860269-11837-3-git-send-email-vivien.didelot@savoirfairelinux.com Signed-off-by: Ingo Molnar <[email protected]>
2014-07-16x86/platform/ts5500: Use the DEVICE_ATTR_RO() macroVivien Didelot1-28/+22
Use the DEVICE_ATTR_RO() helper macro to simplify the declaration of read-only sysfs attributes in the TS5500 code.. Signed-off-by: Vivien Didelot <[email protected]> Acked-by: Thomas Gleixner <[email protected]> Cc: Savoir-faire Linux Inc. <[email protected]> Link: http://lkml.kernel.org/r/1404860269-11837-2-git-send-email-vivien.didelot@savoirfairelinux.com Signed-off-by: Ingo Molnar <[email protected]>
2014-07-14x86: intel-mid: Use the new io_apic interfacesJiang Liu1-16/+6
Commit 9f354b0252b8 "x86, irq: Clean up unused IOAPIC interface" kills interface io_apic_set_pci_routing(), so change arch/x86/platform/ intel-mid/device_libs/platform_wdt.c to use new interfaces. Due to hardware resource restriction, this patch only passes compilation without functional tests. Signed-off-by: Jiang Liu <[email protected]> Acked-by: David Cohen <[email protected]> Cc: Tony Luck <[email protected]> Cc: Tang Feng <[email protected]> Cc: Yinghai Lu <[email protected]> Cc: H. Peter Anvin <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Tony Luck <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Thomas Gleixner <[email protected]>
2014-07-07efi/x86: Move UEFI Runtime Services wrappers to generic codeArd Biesheuvel1-142/+2
In order for other archs (such as arm64) to be able to reuse the virtual mode function call wrappers, move them to drivers/firmware/efi/runtime-wrappers.c. Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Matt Fleming <[email protected]>
2014-06-21x86, irq, SFI: Use common irqdomain map interface to program IOAPIC pinsJiang Liu2-34/+28
Refine SFI to use common irqdomain map interface to program IOAPIC pins, so we can unify the callsite to progam IOAPIC pins. Signed-off-by: Jiang Liu <[email protected]> Cc: Konrad Rzeszutek Wilk <[email protected]> Cc: Tony Luck <[email protected]> Cc: Joerg Roedel <[email protected]> Cc: Paul Gortmaker <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: H. Peter Anvin <[email protected]> Cc: [email protected] Cc: Benjamin Herrenschmidt <[email protected]> Cc: Grant Likely <[email protected]> Cc: Rafael J. Wysocki <[email protected]> Cc: Bjorn Helgaas <[email protected]> Cc: Randy Dunlap <[email protected]> Cc: Yinghai Lu <[email protected]> Cc: Len Brown <[email protected]> Cc: David Cohen <[email protected]> Cc: Kuppuswamy Sathyanarayanan <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Thomas Gleixner <[email protected]>
2014-06-21x86, SFI, irq: Provide basic irqdomain supportJiang Liu2-1/+9
Enhance SFI to provide basic support of irqdomain with identity mapping between GSIs and IRQs. Some Intel MID platforms assumes identity mapping between GSI and IRQ, so we can't dynamically allocate IRQ number on demand. Signed-off-by: Jiang Liu <[email protected]> Cc: Konrad Rzeszutek Wilk <[email protected]> Cc: Tony Luck <[email protected]> Cc: Joerg Roedel <[email protected]> Cc: Paul Gortmaker <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: H. Peter Anvin <[email protected]> Cc: [email protected] Cc: Benjamin Herrenschmidt <[email protected]> Cc: Grant Likely <[email protected]> Cc: Rafael J. Wysocki <[email protected]> Cc: Bjorn Helgaas <[email protected]> Cc: Randy Dunlap <[email protected]> Cc: Yinghai Lu <[email protected]> Cc: Len Brown <[email protected]> Cc: David Cohen <[email protected]> Cc: Kuppuswamy Sathyanarayanan <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Thomas Gleixner <[email protected]>
2014-06-21x86, irq: Enhance mp_register_ioapic() to support irqdomainJiang Liu1-1/+1
Enhance function mp_register_ioapic() to support irqdomain. When registering IOAPIC, caller may provide callbacks and parameters for creating irqdomain. The IOAPIC core will create irqdomain later if caller has passed in corresponding parameters. Signed-off-by: Jiang Liu <[email protected]> Cc: Konrad Rzeszutek Wilk <[email protected]> Cc: Tony Luck <[email protected]> Cc: Joerg Roedel <[email protected]> Cc: Paul Gortmaker <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: [email protected] Cc: Benjamin Herrenschmidt <[email protected]> Cc: Grant Likely <[email protected]> Cc: Rafael J. Wysocki <[email protected]> Cc: Bjorn Helgaas <[email protected]> Cc: Randy Dunlap <[email protected]> Cc: Yinghai Lu <[email protected]> Cc: Len Brown <[email protected]> Cc: Pavel Machek <[email protected]> Cc: Rob Herring <[email protected]> Cc: Michal Simek <[email protected]> Cc: Tony Lindgren <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Thomas Gleixner <[email protected]>
2014-06-21x86: ce4100, irq: Do not set legacy_pic to null_legacy_picJiang Liu1-2/+0
Intel CE4100 platforms has i8259 legacy interrupt controllers, so don't set legacy_pic to null_legacy_pic in late booting stage because we need legacy_pic to mask i8259 pins when enabling IOAPIC pins for safety. Signed-off-by: Jiang Liu <[email protected]> Cc: Konrad Rzeszutek Wilk <[email protected]> Cc: Tony Luck <[email protected]> Cc: Joerg Roedel <[email protected]> Cc: Paul Gortmaker <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Benjamin Herrenschmidt <[email protected]> Cc: Grant Likely <[email protected]> Cc: Rafael J. Wysocki <[email protected]> Cc: Bjorn Helgaas <[email protected]> Cc: Randy Dunlap <[email protected]> Cc: Yinghai Lu <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Thomas Gleixner <[email protected]>
2014-06-21x86: ce4100, irq: Make CE4100 depend on CONFIG_X86_IO_APICJiang Liu1-7/+2
Intel CE4100 platforms need IOAPIC support becasue some devices are always connected to the second IOAPIC, so make CONFIG_CE depends on CONFIG_X86_IO_APIC. Signed-off-by: Jiang Liu <[email protected]> Cc: Konrad Rzeszutek Wilk <[email protected]> Cc: Tony Luck <[email protected]> Cc: Joerg Roedel <[email protected]> Cc: Paul Gortmaker <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Benjamin Herrenschmidt <[email protected]> Cc: Grant Likely <[email protected]> Cc: Rafael J. Wysocki <[email protected]> Cc: Bjorn Helgaas <[email protected]> Cc: Randy Dunlap <[email protected]> Cc: Yinghai Lu <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Thomas Gleixner <[email protected]>
2014-06-19x86/efi: Use early_memunmap() to squelch sparse errorsMatt Fleming1-2/+2
The kbuild reports the following sparse errors, >> arch/x86/platform/efi/quirks.c:242:23: sparse: incorrect type in >> argument 1 (different address spaces) arch/x86/platform/efi/quirks.c:242:23: expected void [noderef] <asn:2>*addr arch/x86/platform/efi/quirks.c:242:23: got void *[assigned] tablep >> arch/x86/platform/efi/quirks.c:245:23: sparse: incorrect type in >> argument 1 (different address spaces) arch/x86/platform/efi/quirks.c:245:23: expected void [noderef] <asn:2>*addr arch/x86/platform/efi/quirks.c:245:23: got struct efi_setup_data *[assigned] data Dave Young had made previous attempts to convert the early_iounmap() calls to early_memunmap() but ran into merge conflicts with commit 9e5c33d7aeee ("mm: create generic early_ioremap() support"). Now that we've got that commit in place we can switch to using early_memunmap() since we're already using early_memremap() in efi_reuse_config(). Cc: Dave Young <[email protected]> Cc: Saurabh Tangri <[email protected]> Signed-off-by: Matt Fleming <[email protected]>
2014-06-19x86/efi: Move all workarounds to a separate file quirks.cSaurabh Tangri3-236/+270
Currently, it's difficult to find all the workarounds that are applied when running on EFI, because they're littered throughout various code paths. This change moves all of them into a separate file with the hope that it will be come the single location for all our well documented quirks. Signed-off-by: Saurabh Tangri <[email protected]> Signed-off-by: Matt Fleming <[email protected]>
2014-06-10x86: intel-mid: add watchdog platform code for MerrifieldDavid Cohen2-0/+73
This patch adds platform code for Intel Merrifield. Since the watchdog is not part of SFI table, we have no other option but to manually register watchdog's platform device (argh!). Signed-off-by: David Cohen <[email protected]> Reviewed-by: Guenter Roeck <[email protected]> Signed-off-by: Wim Van Sebroeck <[email protected]>
2014-06-08Merge branch 'next' (accumulated 3.16 merge window patches) into masterLinus Torvalds5-112/+31
Now that 3.15 is released, this merges the 'next' branch into 'master', bringing us to the normal situation where my 'master' branch is the merge window. * accumulated work in next: (6809 commits) ufs: sb mutex merge + mutex_destroy powerpc: update comments for generic idle conversion cris: update comments for generic idle conversion idle: remove cpu_idle() forward declarations nbd: zero from and len fields in NBD_CMD_DISCONNECT. mm: convert some level-less printks to pr_* MAINTAINERS: adi-buildroot-devel is moderated MAINTAINERS: add linux-api for review of API/ABI changes mm/kmemleak-test.c: use pr_fmt for logging fs/dlm/debug_fs.c: replace seq_printf by seq_puts fs/dlm/lockspace.c: convert simple_str to kstr fs/dlm/config.c: convert simple_str to kstr mm: mark remap_file_pages() syscall as deprecated mm: memcontrol: remove unnecessary memcg argument from soft limit functions mm: memcontrol: clean up memcg zoneinfo lookup mm/memblock.c: call kmemleak directly from memblock_(alloc|free) mm/mempool.c: update the kmemleak stack trace for mempool allocations lib/radix-tree.c: update the kmemleak stack trace for radix tree allocations mm: introduce kmemleak_update_trace() mm/kmemleak.c: use %u to print ->checksum ...
2014-06-05Merge tag 'efi-urgent' into x86/urgentH. Peter Anvin1-0/+3
* Fix earlyprintk=efi,keep support by switching to an ioremap() mapping of the framebuffer when early_ioremap() is no longer available and dropping __init from functions that may be invoked after free_initmem() - Dave Young * We shouldn't be exporting the EFI runtime map in sysfs if not using the new 1:1 EFI mapping code since in that case the mappings are not static across a kexec reboot - Dave Young Signed-off-by: H. Peter Anvin <[email protected]>
2014-06-05Merge branch 'x86-efi-for-linus' of ↵Linus Torvalds3-105/+26
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip into next Pull x86 EFI updates from Peter Anvin: "A collection of EFI changes. The perhaps most important one is to fully save and restore the FPU state around each invocation of EFI runtime, and to not choke on non-ASCII characters in the boot stub" * 'x86-efi-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: efivars: Add compatibility code for compat tasks efivars: Refactor sanity checking code into separate function efivars: Stop passing a struct argument to efivar_validate() efivars: Check size of user object efivars: Use local variables instead of a pointer dereference x86/efi: Save and restore FPU context around efi_calls (i386) x86/efi: Save and restore FPU context around efi_calls (x86_64) x86/efi: Implement a __efi_call_virt macro x86, fpu: Extend the use of static_cpu_has_safe x86/efi: Delete most of the efi_call* macros efi: x86: Handle arbitrary Unicode characters efi: Add get_dram_base() helper function efi: Add shared printk wrapper for consistent prefixing efi: create memory map iteration helper efi: efi-stub-helper cleanup
2014-06-05x86/uv: Update the UV3 TLB shootdown logicCliff Wickman1-31/+38
Update of TLB shootdown code for UV3. Kernel function native_flush_tlb_others() calls uv_flush_tlb_others() on UV to invalidate tlb page definitions on remote cpus. The UV systems have a hardware 'broadcast assist unit' which can be used to broadcast shootdown messages to all cpu's of selected nodes. The behavior of the BAU has changed only slightly with UV3: - UV3 is recognized with is_uv3_hub(). - UV2 functions and structures (uv2_xxx) are in most cases simply renamed to uv2_3_xxx. - Some UV2 error workarounds are not needed for UV3. (see uv_bau_message_interrupt and enable_timeouts) Signed-off-by: Cliff Wickman <[email protected]> Link: http://lkml.kernel.org/r/[email protected] [ Removed a few linebreak uglies. ] Signed-off-by: Ingo Molnar <[email protected]>
2014-06-04Merge branch 'akpm' (patchbomb from Andrew) into nextLinus Torvalds1-1/+1
Merge misc updates from Andrew Morton: - a few fixes for 3.16. Cc'ed to stable so they'll get there somehow. - various misc fixes and cleanups - most of the ocfs2 queue. Review is slow... - most of MM. The MM queue is pretty huge this time, but not much in the way of feature work. - some tweaks under kernel/ - printk maintenance work - updates to lib/ - checkpatch updates - tweaks to init/ * emailed patches from Andrew Morton <[email protected]>: (276 commits) fs/autofs4/dev-ioctl.c: add __init to autofs_dev_ioctl_init fs/ncpfs/getopt.c: replace simple_strtoul by kstrtoul init/main.c: remove an ifdef kthreads: kill CLONE_KERNEL, change kernel_thread(kernel_init) to avoid CLONE_SIGHAND init/main.c: add initcall_blacklist kernel parameter init/main.c: don't use pr_debug() fs/binfmt_flat.c: make old_reloc() static fs/binfmt_elf.c: fix bool assignements fs/efs: convert printk(KERN_DEBUG to pr_debug fs/efs: add pr_fmt / use __func__ fs/efs: convert printk to pr_foo() scripts/checkpatch.pl: device_initcall is not the only __initcall substitute checkpatch: check stable email address checkpatch: warn on unnecessary void function return statements checkpatch: prefer kstrto<foo> to sscanf(buf, "%<lhuidx>", &bar); checkpatch: add warning for kmalloc/kzalloc with multiply checkpatch: warn on #defines ending in semicolon checkpatch: make --strict a default for files in drivers/net and net/ checkpatch: always warn on missing blank line after variable declaration block checkpatch: fix wildcard DT compatible string checking ...
2014-06-04kernel/printk: use symbolic defines for console loglevelsBorislav Petkov1-1/+1
... instead of naked numbers. Stuff in sysrq.c used to set it to 8 which is supposed to mean above default level so set it to DEBUG instead as we're terminating/killing all tasks and we want to be verbose there. Also, correct the check in x86_64_start_kernel which should be >= as we're clearly issuing the string there for all debug levels, not only the magical 10. Signed-off-by: Borislav Petkov <[email protected]> Acked-by: Kees Cook <[email protected]> Acked-by: Randy Dunlap <[email protected]> Cc: Joe Perches <[email protected]> Cc: Valdis Kletnieks <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2014-06-02x86/efi: Do not export efi runtime map in case old mapDave Young1-0/+3
For ioremapped efi memory aka old_map the virt addresses are not persistant across kexec reboot. kexec-tools will read the runtime maps from sysfs then pass them to 2nd kernel and assuming kexec efi boot is ok. This will cause kexec boot failure. To address this issue do not export runtime maps in case efi old_map so userspace can use no efi boot instead. Signed-off-by: Dave Young <[email protected]> Acked-by: Borislav Petkov <[email protected]> Acked-by: Vivek Goyal <[email protected]> Signed-off-by: Matt Fleming <[email protected]>
2014-05-16x86: uv: Use irq_alloc/free_hwirq()Thomas Gleixner1-6/+4
No functional change. The request to allocate the irq above NR_IRQS_LEGACY is completely pointless as the implementation enforces that the dynamic allocations are above the GSI interrupts, which includes the legacy PIT irqs. This does not replace the requirement to move x86 to irq domains, but it limits the mess to some degree. Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-by: Grant Likely <[email protected]> Cc: Tony Luck <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: [email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Thomas Gleixner <[email protected]>
2014-05-05asmlinkage, x86: Add explicit __visible to arch/x86/*Andi Kleen1-1/+1
As requested by Linus add explicit __visible to the asmlinkage users. This marks all functions visible to assembler. Tree sweep for arch/x86/* Signed-off-by: Andi Kleen <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: H. Peter Anvin <[email protected]>
2014-05-04Merge tag 'efi-urgent' of ↵Ingo Molnar1-19/+64
git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi into x86/urgent Pull EFI fix from Matt Fleming: " * Fix earlyprintk=efi,keep support by switching to an ioremap() mapping of the framebuffer when early_ioremap() is no longer available and dropping __init from functions that may be invoked after free_initmem() - Dave Young " Signed-off-by: Ingo Molnar <[email protected]>
2014-05-03x86/efi: earlyprintk=efi,keep fixDave Young1-19/+64
earlyprintk=efi,keep will cause kernel hangs while freeing initmem like below: VFS: Mounted root (ext4 filesystem) readonly on device 254:2. devtmpfs: mounted Freeing unused kernel memory: 880K (ffffffff817d4000 - ffffffff818b0000) It is caused by efi earlyprintk use __init function which will be freed later. Such as early_efi_write is marked as __init, also it will use early_ioremap which is init function as well. To fix this issue, I added early initcall early_efi_map_fb which maps the whole efi fb for later use. OTOH, adding a wrapper function early_efi_map which calls early_ioremap before ioremap is available. With this patch applied efi boot ok with earlyprintk=efi,keep console=efi Signed-off-by: Dave Young <[email protected]> Signed-off-by: Matt Fleming <[email protected]>
2014-05-02x86/efi: earlyprintk=efi,keep fixDave Young1-19/+64
earlyprintk=efi,keep will cause kernel hangs while freeing initmem like below: VFS: Mounted root (ext4 filesystem) readonly on device 254:2. devtmpfs: mounted Freeing unused kernel memory: 880K (ffffffff817d4000 - ffffffff818b0000) It is caused by efi earlyprintk use __init function which will be freed later. Such as early_efi_write is marked as __init, also it will use early_ioremap which is init function as well. To fix this issue, I added early initcall early_efi_map_fb which maps the whole efi fb for later use. OTOH, adding a wrapper function early_efi_map which calls early_ioremap before ioremap is available. With this patch applied efi boot ok with earlyprintk=efi,keep console=efi Signed-off-by: Dave Young <[email protected]> Signed-off-by: Matt Fleming <[email protected]>
2014-04-17x86/efi: Implement a __efi_call_virt macroRicardo Neri1-2/+2
For i386, all the EFI system runtime services functions return efi_status_t except efi_reset_system_system. Therefore, not all functions can be covered by the same macro in case the macro needs to do more than calling the function (i.e., return a value). The purpose of the __efi_call_virt macro is to be used when no return value is expected. For x86_64, this macro would not be needed as all the runtime services return u64. However, the same code is used for both x86_64 and i386. Thus, the macro __efi_call_virt is also defined to not break compilation. Signed-off-by: Ricardo Neri <[email protected]> Cc: Borislav Petkov <[email protected]> Signed-off-by: Matt Fleming <[email protected]>
2014-04-17x86/efi: Delete most of the efi_call* macrosMatt Fleming3-105/+26
We really only need one phys and one virt function call, and then only one assembly function to make firmware calls. Since we are not using the C type system anyway, we're not really losing much by deleting the macros apart from no longer having a check that we are passing the correct number of parameters. The lack of duplicated code seems like a worthwhile trade-off. Cc: Ricardo Neri <[email protected]> Cc: Borislav Petkov <[email protected]> Signed-off-by: Matt Fleming <[email protected]>
2014-04-02Merge branch 'x86-nuke-platforms-for-linus' of ↵Linus Torvalds3-610/+0
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 old platform removal from Peter Anvin: "This patchset removes support for several completely obsolete platforms, where the maintainers either have completely vanished or acked the removal. For some of them it is questionable if there even exists functional specimens of the hardware" Geert Uytterhoeven apparently thought this was a April Fool's pull request ;) * 'x86-nuke-platforms-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86, platforms: Remove NUMAQ x86, platforms: Remove SGI Visual Workstation x86, apic: Remove support for IBM Summit/EXA chipset x86, apic: Remove support for ia32-based Unisys ES7000
2014-03-31Merge branch 'x86-asmlinkage-for-linus' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 LTO changes from Peter Anvin: "More infrastructure work in preparation for link-time optimization (LTO). Most of these changes is to make sure symbols accessed from assembly code are properly marked as visible so the linker doesn't remove them. My understanding is that the changes to support LTO are still not upstream in binutils, but are on the way there. This patchset should conclude the x86-specific changes, and remaining patches to actually enable LTO will be fed through the Kbuild tree (other than keeping up with changes to the x86 code base, of course), although not necessarily in this merge window" * 'x86-asmlinkage-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (25 commits) Kbuild, lto: Handle basic LTO in modpost Kbuild, lto: Disable LTO for asm-offsets.c Kbuild, lto: Add a gcc-ld script to let run gcc as ld Kbuild, lto: add ld-version and ld-ifversion macros Kbuild, lto: Drop .number postfixes in modpost Kbuild, lto, workaround: Don't warn for initcall_reference in modpost lto: Disable LTO for sys_ni lto: Handle LTO common symbols in module loader lto, workaround: Add workaround for initcall reordering lto: Make asmlinkage __visible x86, lto: Disable LTO for the x86 VDSO initconst, x86: Fix initconst mistake in ts5500 code initconst: Fix initconst mistake in dcdbas asmlinkage: Make trace_hardirqs_on/off_caller visible asmlinkage, x86: Fix 32bit memcpy for LTO asmlinkage Make __stack_chk_failed and memcmp visible asmlinkage: Mark rwsem functions that can be called from assembler asmlinkage asmlinkage: Make main_extable_sort_needed visible asmlinkage, mutex: Mark __visible asmlinkage: Make trace_hardirq visible ...
2014-03-17x86/efi: Restore 'attr' argument to query_variable_info()Matt Fleming1-1/+1
In the thunk patches the 'attr' argument was dropped to query_variable_info(). Restore it otherwise the firmware will return EFI_INVALID_PARAMETER. Signed-off-by: Matt Fleming <[email protected]>
2014-03-17x86/efi: Rip out phys_efi_get_time()Matt Fleming1-29/+0
Dan reported that phys_efi_get_time() is doing kmalloc(..., GFP_KERNEL) under a spinlock which is very clearly a bug. Since phys_efi_get_time() has no users let's just delete it instead of trying to fix it. Note that since there are no users of phys_efi_get_time(), it is not possible to actually trigger a GFP_KERNEL alloc under the spinlock. Reported-by: Dan Carpenter <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: H. Peter Anvin <[email protected]> Cc: Nathan Zimmer <[email protected]> Cc: Matthew Garrett <[email protected]> Cc: Jan Beulich <[email protected]> Signed-off-by: Matt Fleming <[email protected]>