summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAge
* x86/efi: Mark initialization code as suchMathias Krause2014-10-03
| | | | | | | | | | | | | | | | | | | | | | The 32 bit and 64 bit implementations differ in their __init annotations for some functions referenced from the common EFI code. Namely, the 32 bit variant is missing some of the __init annotations the 64 bit variant has. To solve the colliding annotations, mark the corresponding functions in efi_32.c as initialization code, too -- as it is such. Actually, quite a few more functions are only used during initialization and therefore can be marked __init. They are therefore annotated, too. Also add the __init annotation to the prototypes in the efi.h header so users of those functions will see it's meant as initialization code only. This patch also fixes the "prelog" typo. ("prologue" / "epilogue" might be more appropriate but this is C code after all, not an opera! :D) Signed-off-by: Mathias Krause <minipli@googlemail.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
* x86/efi: Update comment regarding required phys mapped EFI servicesMathias Krause2014-10-03
| | | | | | | | | Commit 3f4a7836e331 ("x86/efi: Rip out phys_efi_get_time()") left set_virtual_address_map as the only runtime service needed with a phys mapping but missed to update the preceding comment. Fix that. Signed-off-by: Mathias Krause <minipli@googlemail.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
* x86/efi: Unexport add_efi_memmap variableMathias Krause2014-10-03
| | | | | | | | | | | | | This variable was accidentally exported, even though it's only used in this compilation unit and only during initialization. Remove the bogus export, make the variable static instead and mark it as __initdata. Fixes: 200001eb140e ("x86 boot: only pick up additional EFI memmap...") Cc: Paul Jackson <pj@sgi.com> Signed-off-by: Mathias Krause <minipli@googlemail.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
* x86/efi: Remove unused efi_call* macrosMathias Krause2014-10-03
| | | | | | | | | | Complement commit 62fa6e69a436 ("x86/efi: Delete most of the efi_call* macros") and delete the stub macros for the !CONFIG_EFI case, too. In fact, there are no EFI calls in this case so we don't need a dummy for efi_call() even. Signed-off-by: Mathias Krause <minipli@googlemail.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
* efi: Resolve some shadow warningsMark Rustad2014-10-03
| | | | | | | | | | | | | | | | | | | | | | | It is a really bad idea to declare variables or parameters that have the same name as common types. It is valid C, but it gets surprising if a macro expansion attempts to declare an inner local with that type. Change the local names to eliminate the hazard. Change s16 => str16, s8 => str8. This resolves warnings seen when using W=2 during make, for instance: drivers/firmware/efi/vars.c: In function ‘dup_variable_bug’: drivers/firmware/efi/vars.c:324:44: warning: declaration of ‘s16’ shadows a global declaration [-Wshadow] static void dup_variable_bug(efi_char16_t *s16, efi_guid_t *vendor_guid, drivers/firmware/efi/vars.c:328:8: warning: declaration of ‘s8’ shadows a global declaration [-Wshadow] char *s8; Signed-off-by: Mark Rustad <mark.d.rustad@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
* arm64: efi: Format EFI memory type & attrs with efi_md_typeattr_format()Laszlo Ersek2014-10-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | An example log excerpt demonstrating the change: Before the patch: > Processing EFI memory map: > 0x000040000000-0x000040000fff [Loader Data] > 0x000040001000-0x00004007ffff [Conventional Memory] > 0x000040080000-0x00004072afff [Loader Data] > 0x00004072b000-0x00005fdfffff [Conventional Memory] > 0x00005fe00000-0x00005fe0ffff [Loader Data] > 0x00005fe10000-0x0000964e8fff [Conventional Memory] > 0x0000964e9000-0x0000964e9fff [Loader Data] > 0x0000964ea000-0x000096c52fff [Loader Code] > 0x000096c53000-0x00009709dfff [Boot Code]* > 0x00009709e000-0x0000970b3fff [Runtime Code]* > 0x0000970b4000-0x0000970f4fff [Runtime Data]* > 0x0000970f5000-0x000097117fff [Runtime Code]* > 0x000097118000-0x000097199fff [Runtime Data]* > 0x00009719a000-0x0000971dffff [Runtime Code]* > 0x0000971e0000-0x0000997f8fff [Conventional Memory] > 0x0000997f9000-0x0000998f1fff [Boot Data]* > 0x0000998f2000-0x0000999eafff [Conventional Memory] > 0x0000999eb000-0x00009af09fff [Boot Data]* > 0x00009af0a000-0x00009af21fff [Conventional Memory] > 0x00009af22000-0x00009af46fff [Boot Data]* > 0x00009af47000-0x00009af5bfff [Conventional Memory] > 0x00009af5c000-0x00009afe1fff [Boot Data]* > 0x00009afe2000-0x00009afe2fff [Conventional Memory] > 0x00009afe3000-0x00009c01ffff [Boot Data]* > 0x00009c020000-0x00009efbffff [Conventional Memory] > 0x00009efc0000-0x00009f14efff [Boot Code]* > 0x00009f14f000-0x00009f162fff [Runtime Code]* > 0x00009f163000-0x00009f194fff [Runtime Data]* > 0x00009f195000-0x00009f197fff [Boot Data]* > 0x00009f198000-0x00009f198fff [Runtime Data]* > 0x00009f199000-0x00009f1acfff [Conventional Memory] > 0x00009f1ad000-0x00009f1affff [Boot Data]* > 0x00009f1b0000-0x00009f1b0fff [Runtime Data]* > 0x00009f1b1000-0x00009fffffff [Boot Data]* > 0x000004000000-0x000007ffffff [Memory Mapped I/O] > 0x000009010000-0x000009010fff [Memory Mapped I/O] After the patch: > Processing EFI memory map: > 0x000040000000-0x000040000fff [Loader Data | | | | | |WB|WT|WC|UC] > 0x000040001000-0x00004007ffff [Conventional Memory| | | | | |WB|WT|WC|UC] > 0x000040080000-0x00004072afff [Loader Data | | | | | |WB|WT|WC|UC] > 0x00004072b000-0x00005fdfffff [Conventional Memory| | | | | |WB|WT|WC|UC] > 0x00005fe00000-0x00005fe0ffff [Loader Data | | | | | |WB|WT|WC|UC] > 0x00005fe10000-0x0000964e8fff [Conventional Memory| | | | | |WB|WT|WC|UC] > 0x0000964e9000-0x0000964e9fff [Loader Data | | | | | |WB|WT|WC|UC] > 0x0000964ea000-0x000096c52fff [Loader Code | | | | | |WB|WT|WC|UC] > 0x000096c53000-0x00009709dfff [Boot Code | | | | | |WB|WT|WC|UC]* > 0x00009709e000-0x0000970b3fff [Runtime Code |RUN| | | | |WB|WT|WC|UC]* > 0x0000970b4000-0x0000970f4fff [Runtime Data |RUN| | | | |WB|WT|WC|UC]* > 0x0000970f5000-0x000097117fff [Runtime Code |RUN| | | | |WB|WT|WC|UC]* > 0x000097118000-0x000097199fff [Runtime Data |RUN| | | | |WB|WT|WC|UC]* > 0x00009719a000-0x0000971dffff [Runtime Code |RUN| | | | |WB|WT|WC|UC]* > 0x0000971e0000-0x0000997f8fff [Conventional Memory| | | | | |WB|WT|WC|UC] > 0x0000997f9000-0x0000998f1fff [Boot Data | | | | | |WB|WT|WC|UC]* > 0x0000998f2000-0x0000999eafff [Conventional Memory| | | | | |WB|WT|WC|UC] > 0x0000999eb000-0x00009af09fff [Boot Data | | | | | |WB|WT|WC|UC]* > 0x00009af0a000-0x00009af21fff [Conventional Memory| | | | | |WB|WT|WC|UC] > 0x00009af22000-0x00009af46fff [Boot Data | | | | | |WB|WT|WC|UC]* > 0x00009af47000-0x00009af5bfff [Conventional Memory| | | | | |WB|WT|WC|UC] > 0x00009af5c000-0x00009afe1fff [Boot Data | | | | | |WB|WT|WC|UC]* > 0x00009afe2000-0x00009afe2fff [Conventional Memory| | | | | |WB|WT|WC|UC] > 0x00009afe3000-0x00009c01ffff [Boot Data | | | | | |WB|WT|WC|UC]* > 0x00009c020000-0x00009efbffff [Conventional Memory| | | | | |WB|WT|WC|UC] > 0x00009efc0000-0x00009f14efff [Boot Code | | | | | |WB|WT|WC|UC]* > 0x00009f14f000-0x00009f162fff [Runtime Code |RUN| | | | |WB|WT|WC|UC]* > 0x00009f163000-0x00009f194fff [Runtime Data |RUN| | | | |WB|WT|WC|UC]* > 0x00009f195000-0x00009f197fff [Boot Data | | | | | |WB|WT|WC|UC]* > 0x00009f198000-0x00009f198fff [Runtime Data |RUN| | | | |WB|WT|WC|UC]* > 0x00009f199000-0x00009f1acfff [Conventional Memory| | | | | |WB|WT|WC|UC] > 0x00009f1ad000-0x00009f1affff [Boot Data | | | | | |WB|WT|WC|UC]* > 0x00009f1b0000-0x00009f1b0fff [Runtime Data |RUN| | | | |WB|WT|WC|UC]* > 0x00009f1b1000-0x00009fffffff [Boot Data | | | | | |WB|WT|WC|UC]* > 0x000004000000-0x000007ffffff [Memory Mapped I/O |RUN| | | | | | | |UC] > 0x000009010000-0x000009010fff [Memory Mapped I/O |RUN| | | | | | | |UC] The attribute bitmap is now displayed, in decoded form. Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
* ia64: efi: Format EFI memory type & attrs with efi_md_typeattr_format()Laszlo Ersek2014-10-03
| | | | | | | | | | The effects of the patch on the i64 memory map log are similar to those visible in the previous (x86) patch: the type enum and the attribute bitmap are decoded. Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
* x86: efi: Format EFI memory type & attrs with efi_md_typeattr_format()Laszlo Ersek2014-10-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | An example log excerpt demonstrating the change: Before the patch: > efi: mem00: type=7, attr=0xf, range=[0x0000000000000000-0x000000000009f000) (0MB) > efi: mem01: type=2, attr=0xf, range=[0x000000000009f000-0x00000000000a0000) (0MB) > efi: mem02: type=7, attr=0xf, range=[0x0000000000100000-0x0000000000400000) (3MB) > efi: mem03: type=2, attr=0xf, range=[0x0000000000400000-0x0000000000800000) (4MB) > efi: mem04: type=10, attr=0xf, range=[0x0000000000800000-0x0000000000808000) (0MB) > efi: mem05: type=7, attr=0xf, range=[0x0000000000808000-0x0000000000810000) (0MB) > efi: mem06: type=10, attr=0xf, range=[0x0000000000810000-0x0000000000900000) (0MB) > efi: mem07: type=4, attr=0xf, range=[0x0000000000900000-0x0000000001100000) (8MB) > efi: mem08: type=7, attr=0xf, range=[0x0000000001100000-0x0000000001400000) (3MB) > efi: mem09: type=2, attr=0xf, range=[0x0000000001400000-0x0000000002613000) (18MB) > efi: mem10: type=7, attr=0xf, range=[0x0000000002613000-0x0000000004000000) (25MB) > efi: mem11: type=4, attr=0xf, range=[0x0000000004000000-0x0000000004020000) (0MB) > efi: mem12: type=7, attr=0xf, range=[0x0000000004020000-0x00000000068ea000) (40MB) > efi: mem13: type=2, attr=0xf, range=[0x00000000068ea000-0x00000000068f0000) (0MB) > efi: mem14: type=3, attr=0xf, range=[0x00000000068f0000-0x0000000006c7b000) (3MB) > efi: mem15: type=6, attr=0x800000000000000f, range=[0x0000000006c7b000-0x0000000006c7d000) (0MB) > efi: mem16: type=5, attr=0x800000000000000f, range=[0x0000000006c7d000-0x0000000006c85000) (0MB) > efi: mem17: type=6, attr=0x800000000000000f, range=[0x0000000006c85000-0x0000000006c87000) (0MB) > efi: mem18: type=3, attr=0xf, range=[0x0000000006c87000-0x0000000006ca3000) (0MB) > efi: mem19: type=6, attr=0x800000000000000f, range=[0x0000000006ca3000-0x0000000006ca6000) (0MB) > efi: mem20: type=10, attr=0xf, range=[0x0000000006ca6000-0x0000000006cc6000) (0MB) > efi: mem21: type=6, attr=0x800000000000000f, range=[0x0000000006cc6000-0x0000000006d95000) (0MB) > efi: mem22: type=5, attr=0x800000000000000f, range=[0x0000000006d95000-0x0000000006e22000) (0MB) > efi: mem23: type=7, attr=0xf, range=[0x0000000006e22000-0x0000000007165000) (3MB) > efi: mem24: type=4, attr=0xf, range=[0x0000000007165000-0x0000000007d22000) (11MB) > efi: mem25: type=7, attr=0xf, range=[0x0000000007d22000-0x0000000007d25000) (0MB) > efi: mem26: type=3, attr=0xf, range=[0x0000000007d25000-0x0000000007ea2000) (1MB) > efi: mem27: type=5, attr=0x800000000000000f, range=[0x0000000007ea2000-0x0000000007ed2000) (0MB) > efi: mem28: type=6, attr=0x800000000000000f, range=[0x0000000007ed2000-0x0000000007ef6000) (0MB) > efi: mem29: type=7, attr=0xf, range=[0x0000000007ef6000-0x0000000007f00000) (0MB) > efi: mem30: type=9, attr=0xf, range=[0x0000000007f00000-0x0000000007f02000) (0MB) > efi: mem31: type=10, attr=0xf, range=[0x0000000007f02000-0x0000000007f06000) (0MB) > efi: mem32: type=4, attr=0xf, range=[0x0000000007f06000-0x0000000007fd0000) (0MB) > efi: mem33: type=6, attr=0x800000000000000f, range=[0x0000000007fd0000-0x0000000007ff0000) (0MB) > efi: mem34: type=7, attr=0xf, range=[0x0000000007ff0000-0x0000000008000000) (0MB) After the patch: > efi: mem00: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x0000000000000000-0x000000000009f000) (0MB) > efi: mem01: [Loader Data | | | | | |WB|WT|WC|UC] range=[0x000000000009f000-0x00000000000a0000) (0MB) > efi: mem02: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x0000000000100000-0x0000000000400000) (3MB) > efi: mem03: [Loader Data | | | | | |WB|WT|WC|UC] range=[0x0000000000400000-0x0000000000800000) (4MB) > efi: mem04: [ACPI Memory NVS | | | | | |WB|WT|WC|UC] range=[0x0000000000800000-0x0000000000808000) (0MB) > efi: mem05: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x0000000000808000-0x0000000000810000) (0MB) > efi: mem06: [ACPI Memory NVS | | | | | |WB|WT|WC|UC] range=[0x0000000000810000-0x0000000000900000) (0MB) > efi: mem07: [Boot Data | | | | | |WB|WT|WC|UC] range=[0x0000000000900000-0x0000000001100000) (8MB) > efi: mem08: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x0000000001100000-0x0000000001400000) (3MB) > efi: mem09: [Loader Data | | | | | |WB|WT|WC|UC] range=[0x0000000001400000-0x0000000002613000) (18MB) > efi: mem10: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x0000000002613000-0x0000000004000000) (25MB) > efi: mem11: [Boot Data | | | | | |WB|WT|WC|UC] range=[0x0000000004000000-0x0000000004020000) (0MB) > efi: mem12: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x0000000004020000-0x00000000068ea000) (40MB) > efi: mem13: [Loader Data | | | | | |WB|WT|WC|UC] range=[0x00000000068ea000-0x00000000068f0000) (0MB) > efi: mem14: [Boot Code | | | | | |WB|WT|WC|UC] range=[0x00000000068f0000-0x0000000006c7b000) (3MB) > efi: mem15: [Runtime Data |RUN| | | | |WB|WT|WC|UC] range=[0x0000000006c7b000-0x0000000006c7d000) (0MB) > efi: mem16: [Runtime Code |RUN| | | | |WB|WT|WC|UC] range=[0x0000000006c7d000-0x0000000006c85000) (0MB) > efi: mem17: [Runtime Data |RUN| | | | |WB|WT|WC|UC] range=[0x0000000006c85000-0x0000000006c87000) (0MB) > efi: mem18: [Boot Code | | | | | |WB|WT|WC|UC] range=[0x0000000006c87000-0x0000000006ca3000) (0MB) > efi: mem19: [Runtime Data |RUN| | | | |WB|WT|WC|UC] range=[0x0000000006ca3000-0x0000000006ca6000) (0MB) > efi: mem20: [ACPI Memory NVS | | | | | |WB|WT|WC|UC] range=[0x0000000006ca6000-0x0000000006cc6000) (0MB) > efi: mem21: [Runtime Data |RUN| | | | |WB|WT|WC|UC] range=[0x0000000006cc6000-0x0000000006d95000) (0MB) > efi: mem22: [Runtime Code |RUN| | | | |WB|WT|WC|UC] range=[0x0000000006d95000-0x0000000006e22000) (0MB) > efi: mem23: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x0000000006e22000-0x0000000007165000) (3MB) > efi: mem24: [Boot Data | | | | | |WB|WT|WC|UC] range=[0x0000000007165000-0x0000000007d22000) (11MB) > efi: mem25: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x0000000007d22000-0x0000000007d25000) (0MB) > efi: mem26: [Boot Code | | | | | |WB|WT|WC|UC] range=[0x0000000007d25000-0x0000000007ea2000) (1MB) > efi: mem27: [Runtime Code |RUN| | | | |WB|WT|WC|UC] range=[0x0000000007ea2000-0x0000000007ed2000) (0MB) > efi: mem28: [Runtime Data |RUN| | | | |WB|WT|WC|UC] range=[0x0000000007ed2000-0x0000000007ef6000) (0MB) > efi: mem29: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x0000000007ef6000-0x0000000007f00000) (0MB) > efi: mem30: [ACPI Reclaim Memory| | | | | |WB|WT|WC|UC] range=[0x0000000007f00000-0x0000000007f02000) (0MB) > efi: mem31: [ACPI Memory NVS | | | | | |WB|WT|WC|UC] range=[0x0000000007f02000-0x0000000007f06000) (0MB) > efi: mem32: [Boot Data | | | | | |WB|WT|WC|UC] range=[0x0000000007f06000-0x0000000007fd0000) (0MB) > efi: mem33: [Runtime Data |RUN| | | | |WB|WT|WC|UC] range=[0x0000000007fd0000-0x0000000007ff0000) (0MB) > efi: mem34: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x0000000007ff0000-0x0000000008000000) (0MB) Both the type enum and the attribute bitmap are decoded, with the additional benefit that the memory ranges line up as well. Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
* efi: Introduce efi_md_typeattr_format()Laszlo Ersek2014-10-03
| | | | | | | | | | | | | | | | | | | | | | | At the moment, there are three architectures debug-printing the EFI memory map at initialization: x86, ia64, and arm64. They all use different format strings, plus the EFI memory type and the EFI memory attributes are similarly hard to decode for a human reader. Introduce a helper __init function that formats the memory type and the memory attributes in a unified way, to a user-provided character buffer. The array "memory_type_name" is copied from the arm64 code, temporarily duplicating it. The (otherwise optional) braces around each string literal in the initializer list are dropped in order to match the kernel coding style more closely. The element size is tightened from 32 to 20 bytes (maximum actual string length + 1) so that we can derive the field width from the element size. Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> [ Dropped useless 'register' keyword, which compiler will ignore ] Signed-off-by: Matt Fleming <matt.fleming@intel.com>
* efi: Add macro for EFI_MEMORY_UCE memory attributeLaszlo Ersek2014-10-03
| | | | | | | | | | | | | Add the following macro from the UEFI spec, for completeness: EFI_MEMORY_UCE Memory cacheability attribute: The memory region supports being configured as not cacheable, exported, and supports the "fetch and add" semaphore mechanism. Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
* x86/efi: Clear EFI_RUNTIME_SERVICES if failing to enter virtual modeDave Young2014-10-03
| | | | | | | | | | | | | | 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 <dyoung@redhat.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
* arm64/efi: Do not enter virtual mode if booting with efi=noruntime or noefiDave Young2014-10-03
| | | | | | | | | | | | In case efi runtime disabled via noefi kernel cmdline arm64_enter_virtual_mode should error out. At the same time move early_memunmap(memmap.map, mapsize) to the beginning of the function or it will leak early mem. Signed-off-by: Dave Young <dyoung@redhat.com> Reviewed-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
* arm64/efi: uefi_init error handling fixDave Young2014-10-03
| | | | | | | | | | | There's one early memmap leak in uefi_init error path, fix it and slightly tune the error handling code. Signed-off-by: Dave Young <dyoung@redhat.com> Acked-by: Mark Salter <msalter@redhat.com> Reported-by: Will Deacon <will.deacon@arm.com> Acked-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
* efi: Add kernel param efi=noruntimeDave Young2014-10-03
| | | | | | | | | | 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 <dyoung@redhat.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
* lib: Add a generic cmdline parse function parse_option_strDave Young2014-10-03
| | | | | | | | | | | 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 <dyoung@redhat.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
* efi: Move noefi early param code out of x86 arch codeDave Young2014-10-03
| | | | | | | | noefi param can be used for arches other than X86 later, thus move it out of x86 platform code. Signed-off-by: Dave Young <dyoung@redhat.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
* efi-bgrt: Add error handling; inform the user when ignoring the BGRTJosh Triplett2014-10-03
| | | | | | | | | | | | | | 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 <linux.bug.reporting@gmail.com> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=81321 Signed-off-by: Josh Triplett <josh@joshtriplett.org> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
* efi: Add efi= parameter parsing to the EFI boot stubMatt Fleming2014-10-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <ard.biesheuvel@linaro.org> Cc: Roy Franz <roy.franz@linaro.org> Cc: Maarten Lankhorst <m.b.lankhorst@gmail.com> Cc: Leif Lindholm <leif.lindholm@linaro.org> Cc: Borislav Petkov <bp@suse.de> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
* efi: Implement mandatory locking for UEFI Runtime ServicesArd Biesheuvel2014-10-03
| | | | | | | | | | | | | | | | | | | | | According to section 7.1 of the UEFI spec, Runtime Services are not fully reentrant, and there are particular combinations of calls that need to be serialized. Use a spinlock to serialize all Runtime Services with respect to all others, even if this is more than strictly needed. We've managed to get away without requiring a runtime services lock until now because most of the interactions with EFI involve EFI variables, and those operations are already serialised with __efivars->lock. Some of the assumptions underlying the decision whether locks are needed or not (e.g., SetVariable() against ResetSystem()) may not apply universally to all [new] architectures that implement UEFI. Rather than try to reason our way out of this, let's just implement at least what the spec requires in terms of locking. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
* Linux 3.17-rc1Linus Torvalds2014-08-16
|
* Merge branch 'for_linus' of git://cavan.codon.org.uk/platform-drivers-x86Linus Torvalds2014-08-16
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull x86 platform driver updates from Matthew Garrett: "A moderate number of changes, but nothing awfully significant. A lot of const cleanups, some reworking and additions to the rfkill quirks in the asus driver, a new driver for generating falling laptop events on Toshibas and some misc fixes. Maybe vendors have stopped inventing things" * 'for_linus' of git://cavan.codon.org.uk/platform-drivers-x86: (41 commits) platform/x86: Enable build support for toshiba_haps Documentation: Add file about toshiba_haps module platform/x86: Toshiba HDD Active Protection Sensor asus-nb-wmi: Add wapf4 quirk for the U32U alienware-wmi: make hdmi_mux enabled on case-by-case basis ideapad-laptop: Constify DMI table and other r/o variables asus-nb-wmi.c: Rename x401u quirk to wapf4 compal-laptop: correct invalid hwmon name toshiba_acpi: Add Qosmio X75-A to the alt keymap dmi list toshiba_acpi: Add extra check to backlight code Fix log message about future removal of interface ideapad-laptop: Disable touchpad interface on Yoga models asus-nb-wmi: Add wapf4 quirk for the X550CC intel_ips: Make ips_mcp_limits variables static thinkpad_acpi: Mark volume_alsa_control_{vol,mute} as __initdata fujitsu-laptop: Mark fujitsu_dmi_table[] DMI table as __initconst hp-wmi: Add missing __init annotations to initialization code hp_accel: Constify ACPI and DMI tables fujitsu-tablet: Mark DMI callbacks as __init code dell-laptop: Mark dell_quirks[] DMI table as __initconst ...
| * platform/x86: Enable build support for toshiba_hapsAzael Avalos2014-08-16
| | | | | | | | | | | | | | | | Makefile and Kconfig build support patch for the newly introduced kernel module toshiba_haps. Signed-off-by: Azael Avalos <coproscefalo@gmail.com> Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
| * Documentation: Add file about toshiba_haps moduleAzael Avalos2014-08-16
| | | | | | | | | | | | | | | | This patch provides information about the Toshiba HDD Active Protection Sensor driver module toshiba_haps. Signed-off-by: Azael Avalos <coproscefalo@gmail.com> Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
| * platform/x86: Toshiba HDD Active Protection SensorAzael Avalos2014-08-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This driver adds support for the built-in accelereometer found on recent Toshiba laptops with HID TOS620A. This driver receives ACPI notify events 0x80 when the sensor detects a sudden move or a harsh vibration, as well as an ACPI notify event 0x81 whenever the movement or vibration has been stabilized. Also provides sysfs entries to get/set the desired protection level and reseting the HDD protection interface. Signed-off-by: Azael Avalos <coproscefalo@gmail.com> Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
| * asus-nb-wmi: Add wapf4 quirk for the U32UHans de Goede2014-08-16
| | | | | | | | | | | | | | | | As reported here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1173681 the U32U needs wapf=4 too. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
| * alienware-wmi: make hdmi_mux enabled on case-by-case basisMario Limonciello2014-08-16
| | | | | | | | | | | | | | | | Not all HW supporting WMAX method will support the HDMI mux feature. Explicitly quirk the HW that does support it. Signed-off-by: Mario Limonciello <mario_limonciello@dell.com> Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
| * ideapad-laptop: Constify DMI table and other r/o variablesMathias Krause2014-08-16
| | | | | | | | | | | | | | | | | | | | Constify the rfkill_blacklist[] DMI table, the ideapad_rfk_data[] table and the ideapad_attribute_group attribute group. There's no need to have them writeable during runtime. Signed-off-by: Mathias Krause <minipli@googlemail.com> Cc: Ike Panhc <ike.pan@canonical.com> Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
| * asus-nb-wmi.c: Rename x401u quirk to wapf4Hans de Goede2014-08-16
| | | | | | | | | | | | | | | | | | The actual x401u does not use the so named x401u quirk but the x55u quirk. All that the x401u quirk does it setting wapf to 4, so rename it to wapf4 to stop the confusion. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
| * compal-laptop: correct invalid hwmon nameRoald Frederickx2014-08-16
| | | | | | | | | | | | | | | | | | Change the name of the hwmon interface from "compal-laptop" to "compal". A dash is an invalid character for a hwmon name and caused the call to hwmon_device_register_with_groups() to fail. Signed-off-by: Roald Frederickx <roald.frederickx@gmail.com> Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
| * toshiba_acpi: Add Qosmio X75-A to the alt keymap dmi listAzael Avalos2014-08-16
| | | | | | | | | | | | | | | | | | | | | | The Toshiba Qosmio X75-A series models also come with the new keymap layout. This patch adds this model to the alt_keymap_dmi list, along with an extra key found on these models. Signed-off-by: Azael Avalos <coproscefalo@gmail.com> Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
| * toshiba_acpi: Add extra check to backlight codeAzael Avalos2014-08-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some Toshiba models (most notably Qosmios) come with an incomplete backlight method where the AML code doesn't check for write or read commands and always returns HCI_SUCCESS and the actual brightness (and in some cases the max brightness), thus allowing the backlight interface to be registered without write support. This patch changes the set_lcd_brightness function, checking the returned values for values greater than zero to avoid registering a broken backlight interface. Signed-off-by: Azael Avalos <coproscefalo@gmail.com> Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
| * Fix log message about future removal of interfaceMartin Kepplinger2014-08-16
| | | | | | | | | | | | | | If this is going away, it won't be in 2012. Signed-off-by: Martin Kepplinger <martink@posteo.de> Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
| * ideapad-laptop: Disable touchpad interface on Yoga modelsHans de Goede2014-08-16
| | | | | | | | | | | | | | | | Yoga models don't offer touchpad ctrl through the ideapad interface, causing ideapad_sync_touchpad_state to send wrong touchpad enable/disable events. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
| * asus-nb-wmi: Add wapf4 quirk for the X550CCHans de Goede2014-08-16
| | | | | | | | | | | | | | | | As reported here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1173681 the X550CC needs wapf=4 too. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
| * intel_ips: Make ips_mcp_limits variables staticMathias Krause2014-08-16
| | | | | | | | | | | | | | | | These variables don't need to be visible outside of this compilation unit, make them static. Signed-off-by: Mathias Krause <minipli@googlemail.com> Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
| * thinkpad_acpi: Mark volume_alsa_control_{vol,mute} as __initdataMathias Krause2014-08-16
| | | | | | | | | | | | | | | | | | | | Mark volume_alsa_control_vol and volume_alsa_control_mute as __initdata, as snd_ctl_new1() will copy the relevant parts, so there is no need to keep the master copies around after initialization. Signed-off-by: Mathias Krause <minipli@googlemail.com> Cc: Henrique de Moraes Holschuh <ibm-acpi@hmh.eng.br> Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
| * fujitsu-laptop: Mark fujitsu_dmi_table[] DMI table as __initconstMathias Krause2014-08-16
| | | | | | | | | | | | | | | | | | | | The DMI table is only ever used during initialization. Mark it as __initconst so its memory can be released afterwards -- roughly 1.5 kB. In turn, the callback functions can be marked with __init, too. Signed-off-by: Mathias Krause <minipli@googlemail.com> Cc: Jonathan Woithe <jwoithe@just42.net> Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
| * hp-wmi: Add missing __init annotations to initialization codeMathias Krause2014-08-16
| | | | | | | | | | | | | | | | These functions are only called from other initialization routines, so can be marked __init, too. Signed-off-by: Mathias Krause <minipli@googlemail.com> Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
| * hp_accel: Constify ACPI and DMI tablesMathias Krause2014-08-16
| | | | | | | | | | | | | | | | | | Constify the lis3lv02d_device_ids[] ACPI and the lis3lv02d_dmi_ids[] DMI tables. There's no need to have them writeable during runtime. Signed-off-by: Mathias Krause <minipli@googlemail.com> Cc: Eric Piel <eric.piel@tremplin-utc.net> Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
| * fujitsu-tablet: Mark DMI callbacks as __init codeMathias Krause2014-08-16
| | | | | | | | | | | | | | | | | | The DMI table is already marked as __initconst, so can be the callback functions as they're only used in that context. Signed-off-by: Mathias Krause <minipli@googlemail.com> Cc: Robert Gerlach <khnz@gmx.de> Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
| * dell-laptop: Mark dell_quirks[] DMI table as __initconstMathias Krause2014-08-16
| | | | | | | | | | | | | | | | | | | | | | | | | | The dell_quirks[] DMI table is only ever used during initialization. Mark it as __initconst so its memory can be released afterwards -- roughly 5.7 kB. In turn, the callback function can be marked with __init, too. Also the touchpad_led_init() function can be marked __init as it's only referenced from dell_init() -- an __init function. Signed-off-by: Mathias Krause <minipli@googlemail.com> Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
| * eeepc-wmi: Constify asus_quirks[] DMI tableMathias Krause2014-08-16
| | | | | | | | | | | | | | | | | | Constify the asus_quirks[] DMI table. There's no need to have it writeable during runtime. Signed-off-by: Mathias Krause <minipli@googlemail.com> Cc: Corentin Chary <corentin.chary@gmail.com> Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
| * acer-wmi: Mark init data and code as suchMathias Krause2014-08-16
| | | | | | | | | | | | | | | | | | | | | | | | | | Quite a lot of code and data of acer-wmi.c is only ever used during initialization. Mark those accordingly -- and constify, where appropriate -- so the memory can be released afterwards. All in all those changes move ~10 kB of code and data to the .init sections, marking them for release after initialization has finished. Signed-off-by: Mathias Krause <minipli@googlemail.com> Cc: "Lee, Chun-Yi" <jlee@suse.com> Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
| * asus-nb-wmi: Constify asus_quirks[] DMI tableMathias Krause2014-08-16
| | | | | | | | | | | | | | | | | | Constify the asus_quirks[] DMI table. There's no need to have it writeable during runtime. Signed-off-by: Mathias Krause <minipli@googlemail.com> Cc: Corentin Chary <corentin.chary@gmail.com> Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
| * alienware-wmi: Mark DMI table as __initconstMathias Krause2014-08-16
| | | | | | | | | | | | | | | | | | The DMI table is only ever used during initialization. Mark it as __initconst so its memory can be released appropriately. In turn, the callback function can be marked with __init, too. Signed-off-by: Mathias Krause <minipli@googlemail.com> Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
| * acer-wmi: Hide acer_{suspend,resume} for !CONFIG_PM_SLEEPMathias Krause2014-08-16
| | | | | | | | | | | | | | | | | | | | | | | | Encapsulate acer_suspend() and acer_resume with #ifdef CONFIG_PM_SLEEP to get rid of the following warnings: ../acer-wmi.c:2046:12: warning: ‘acer_suspend’ defined but not used [-Wunused-function] ../acer-wmi.c:2068:12: warning: ‘acer_resume’ defined but not used [-Wunused-function] Signed-off-by: Mathias Krause <minipli@googlemail.com> Cc: "Lee, Chun-Yi" <jlee@suse.com> Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
| * acer-wmi: Mark acer_wmi_keymap[] as __initconstMathias Krause2014-08-16
| | | | | | | | | | | | | | | | | | sparse_keymap_setup() will make a copy of the keymap, so we can release the master copy after initialization. Signed-off-by: Mathias Krause <minipli@googlemail.com> Cc: "Lee, Chun-Yi" <jlee@suse.com> Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
| * MAINTAINERS: Update git URL for x86 platform driversMathias Krause2014-08-16
| | | | | | | | | | | | | | | | The repo on kernel.org is no longer available but has a replacement at cavan.codon.org.uk. Signed-off-by: Mathias Krause <minipli@googlemail.com> Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
| * WMI: Remove unnecessary null testHimangi Saraogi2014-08-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch removes the null test on block. block is initialized at the beginning of the function to &wblock->gblock. Since wblock is dereferenced prior to the null test, wblock must be a valid pointer, and &wblock->gblock cannot be null. The following Coccinelle script is used for detecting the change: @r@ expression e,f; identifier g,y; statement S1,S2; @@ *e = &f->g <+... f->y ...+> *if (e != NULL || ...) S1 else S2 Signed-off-by: Himangi Saraogi <himangi774@gmail.com> Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
| * drivers/platform/x86/thinkpad_acpi.c: don't test unsigned int for negativityAndrey Utkin2014-08-16
| | | | | | | | | | | | | | Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=80231 Reported-by: David Binderman <dcb314@hotmail.com> Signed-off-by: Andrey Utkin <andrey.krieger.utkin@gmail.com> Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
generated by cgit v1.2.3 (git 2.25.1) at 2026-05-06 16:42:48 +0000