summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2020-05-19efi/libstub: Optimize for size instead of speedArvind Sankar
Reclaim the bloat from the addition of printf by optimizing the stub for size. With gcc 9, the text size of the stub is: ARCH before +printf -Os arm 35197 37889 34638 arm64 34883 38159 34479 i386 18571 21657 17025 x86_64 25677 29328 22144 Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20200518190716.751506-6-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-05-19efi/libstub: Add a basic printf implementationArvind Sankar
Copy vsprintf from arch/x86/boot/printf.c to get a simple printf implementation. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20200518190716.751506-5-nivedita@alum.mit.edu [ardb: add some missing braces in if...else clauses] Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-05-19efi/libstub: Buffer output of efi_putsArvind Sankar
Use a buffer to convert the string to UTF-16. This will reduce the number of firmware calls required to print the string from one per character to one per string in most cases. Cast the input char to unsigned char before converting to efi_char16_t to avoid sign-extension in case there are any non-ASCII characters in the input. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20200518190716.751506-4-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-05-19efi/libstub: Rename efi_[char16_]printk to efi_[char16_]putsArvind Sankar
These functions do not support formatting, unlike printk. Rename them to puts to make that clear. Move the implementations of these two functions next to each other. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20200518190716.751506-3-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-05-19efi/libstub: Include dependencies of efistub.hArvind Sankar
Add #include directives for include files that efistub.h depends on, instead of relying on them having been included by the C source files prior to efistub.h. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20200518190716.751506-2-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-05-06efi/libstub: Correct comment typosJoe Perches
Fix a couple typos in comments. Signed-off-by: Joe Perches <joe@perches.com> Link: https://lore.kernel.org/r/ec53e67b3ac928922807db3cb1585e911971dadc.1588273612.git.joe@perches.com Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-05-05efi/libstub: Make efi_printk() input argument const char*Ard Biesheuvel
To help the compiler figure out that efi_printk() will not modify the string it is given, make the input argument type const char*. While at it, simplify the implementation as well. Suggested-by: Joe Perches <joe@perches.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-05-05efi/libstub/x86: Work around LLVM ELF quirk build regressionArd Biesheuvel
When building the x86 EFI stub with Clang, the libstub Makefile rules that manipulate the ELF object files may throw an error like: STUBCPY drivers/firmware/efi/libstub/efi-stub-helper.stub.o strip: drivers/firmware/efi/libstub/efi-stub-helper.stub.o: Failed to find link section for section 10 objcopy: drivers/firmware/efi/libstub/efi-stub-helper.stub.o: Failed to find link section for section 10 This is the result of a LLVM feature [0] where symbol references are stored in a LLVM specific .llvm_addrsig section in a non-transparent way, causing generic ELF tools such as strip or objcopy to choke on them. So force the compiler not to emit these sections, by passing the appropriate command line option. [0] https://sourceware.org/bugzilla/show_bug.cgi?id=23817 Cc: Nick Desaulniers <ndesaulniers@google.com> Cc: Peter Collingbourne <pcc@google.com> Cc: Sami Tolvanen <samitolvanen@google.com> Reported-by: Arnd Bergmann <arnd@arndb.de> Suggested-by: Fangrui Song <maskray@google.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-05-05efi/libstub: Fix mixed mode boot issue after macro refactorArvind Sankar
Commit 22090f84bc3f ("efi/libstub: unify EFI call wrappers for non-x86") refactored the macros that are used to provide wrappers for mixed-mode calls on x86, allowing us to boot a 64-bit kernel on 32-bit firmware. Unfortunately, this broke mixed mode boot due to the fact that efi_is_native() is not a macro on x86. All of these macros should go together, so rather than testing each one to see if it is defined, condition the generic macro definitions on a new ARCH_HAS_EFISTUB_WRAPPERS, and remove the wrapper definitions on x86 as well if CONFIG_EFI_MIXED is not enabled. Fixes: 22090f84bc3f ("efi/libstub: unify EFI call wrappers for non-x86") Reported-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20200504150248.62482-1-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-05-01efi/libstub: Check return value of efi_parse_optionsArvind Sankar
efi_parse_options can fail if it is unable to allocate space for a copy of the command line. Check the return value to make sure it succeeded. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20200430182843.2510180-12-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-05-01efi/x86: Support builtin command lineArvind Sankar
Add support for the x86 CMDLINE_BOOL and CMDLINE_OVERRIDE configuration options. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20200430182843.2510180-11-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-05-01efi/libstub: Unify initrd loading across architecturesArvind Sankar
Factor out the initrd loading into a common function that can be called both from the generic efi-stub.c and the x86-specific x86-stub.c. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20200430182843.2510180-10-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-05-01efi/x86: Move command-line initrd loading to efi_mainArvind Sankar
Consolidate the initrd loading in efi_main. The command line options now need to be parsed only once. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20200430182843.2510180-9-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-05-01efi/libstub: Upgrade ignored dtb= argument message to errorArvind Sankar
Use efi_err if we ignore a command-line dtb= argument, so that it shows up even on a quiet boot. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20200430182843.2510180-8-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-05-01efi/tpm: Use efi_err for error messagesArvind Sankar
Use efi_err instead of bare efi_printk for error messages. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20200430182843.2510180-7-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-05-01efi/gop: Use efi_err for error messagesArvind Sankar
Use efi_err instead of bare efi_printk for error messages. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20200430182843.2510180-6-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-05-01efi/x86: Use efi_err for error messagesArvind Sankar
Use efi_err instead of bare efi_printk for error messages. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20200430182843.2510180-5-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-05-01efi/libstub: Move pr_efi/pr_efi_err into efi namespaceArvind Sankar
Rename pr_efi to efi_info and pr_efi_err to efi_err to make it more obvious that they are part of the EFI stub and not generic printk infra. Suggested-by: Joe Perches <joe@perches.com> Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20200430182843.2510180-4-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-05-01efi/libstub: Add a helper function to split 64-bit valuesArvind Sankar
In several places 64-bit values need to be split up into two 32-bit fields, in order to be backward-compatible with the old 32-bit ABIs. Instead of open-coding this, add a helper function to set a 64-bit value as two 32-bit fields. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20200430182843.2510180-3-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-05-01efi/x86: Use correct size for boot_paramsArvind Sankar
struct boot_params is only 4096 bytes, not 16384. Fix this by using sizeof(struct boot_params) instead of hardcoding the incorrect value. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20200430182843.2510180-2-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-04-25efi/libstub: Re-enable command line initrd loading for x86Ard Biesheuvel
Commit: cf6b83664895a5 ("efi/libstub: Make initrd file loader configurable") inadvertently disabled support on x86 for loading an initrd passed via the initrd= option on the kernel command line. Add X86 to the newly introduced Kconfig option's title and depends declarations, so it gets enabled by default, as before. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: linux-efi@vger.kernel.org
2020-04-25Merge tag 'efi-next' of ↵Ingo Molnar
git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi into efi/core Pull EFI changes for v5.8 from Ard Biesheuvel: "- preliminary changes for RISC-V - add support for setting the resolution on the EFI framebuffer - simplify kernel image loading for arm64 - Move .bss into .data via the linker script instead of relying on symbol annotations. - Get rid of __pure getters to access global variables - Clean up the config table matching arrays" Signed-off-by: Ingo Molnar <mingo@kernel.org>
2020-04-24efi: Move arch_tables check to callerArd Biesheuvel
Instead of making match_config_table() test its table_types pointer for NULL-ness, omit the call entirely if no arch_tables pointer was provided to efi_config_parse_tables(). Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-04-24efi: Clean up config table description arraysArd Biesheuvel
Increase legibility by adding whitespace to the efi_config_table_type_t arrays that describe which EFI config tables we look for when going over the firmware provided list. While at it, replace the 'name' char pointer with a char array, which is more space efficient on relocatable 64-bit kernels, as it avoids a 8 byte pointer and the associated relocation data (24 bytes when using RELA format) Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-04-24efi/libstub/x86: Avoid getter function for efi_is64Ard Biesheuvel
We no longer need to take special care when using global variables in the EFI stub, so switch to a simple symbol reference for efi_is64. Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-04-24efi/libstub: Drop __pure getters for EFI stub optionsArd Biesheuvel
The practice of using __pure getter functions to access global variables in the EFI stub dates back to the time when we had to carefully prevent GOT entries from being emitted, because we could not rely on the toolchain to do this for us. Today, we use the hidden visibility pragma for all EFI stub source files, which now all live in the same subdirectory, and we apply a sanity check on the objects, so we can get rid of these getter functions and simply refer to global data objects directly. So switch over the remaining boolean variables carrying options set on the kernel command line. Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-04-24efi/libstub: Drop __pure getter for efi_system_tableArd Biesheuvel
The practice of using __pure getter functions to access global variables in the EFI stub dates back to the time when we had to carefully prevent GOT entries from being emitted, because we could not rely on the toolchain to do this for us. Today, we use the hidden visibility pragma for all EFI stub source files, which now all live in the same subdirectory, and we apply a sanity check on the objects, so we can get rid of these getter functions and simply refer to global data objects directly. Start with efi_system_table(), and convert it into a global variable. While at it, make it a pointer-to-const, because we can. Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-04-24efi: Kill __efistub_globalArvind Sankar
Now that both arm and x86 are using the linker script to place the EFI stub's global variables in the correct section, remove __efistub_global. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20200416151227.3360778-4-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-04-24efi/x86: Remove __efistub_global and add relocation checkArvind Sankar
Instead of using __efistub_global to force variables into the .data section, leave them in the .bss but pull the EFI stub's .bss section into .data in the linker script for the compressed kernel. Add relocation checking for x86 as well to catch non-PC-relative relocations that require runtime processing, since the EFI stub does not do any runtime relocation processing. This will catch, for example, data relocations created by static initializers of pointers. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20200416151227.3360778-3-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-04-24efi/arm: Remove __efistub_global annotationArvind Sankar
Instead of using __efistub_global to force variables into the .data section, leave them in the .bss but pull the EFI stub's .bss section into .data in the linker script for the compressed kernel. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20200416151227.3360778-2-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-04-24efi/libstub: Move efi_relocate_kernel() into separate source fileArd Biesheuvel
Move efi_relocate_kernel() into a separate source file, so that it only gets pulled into builds for architectures that use it. Since efi_relocate_kernel() is the only user of efi_low_alloc(), let's move that over as well. Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-04-24efi/libstub/arm64: Switch to ordinary page allocator for kernel imageArd Biesheuvel
It is no longer necessary to locate the kernel as low as possible in physical memory, and so we can switch from efi_low_alloc() [which is a rather nasty concoction on top of GetMemoryMap()] to a new helper called efi_allocate_pages_aligned(), which simply rounds up the size to account for the alignment, and frees the misaligned pages again. So considering that the kernel can live anywhere in the physical address space, as long as its alignment requirements are met, let's switch to efi_allocate_pages_aligned() to allocate the pages. Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-04-24efi/libstub: Add API function to allocate aligned memoryArd Biesheuvel
Break out the code to create an aligned page allocation from mem.c and move it into a function efi_allocate_pages_aligned() in alignedmem.c. Update efi_allocate_pages() to invoke it unless the minimum alignment equals the EFI page size (4 KB), in which case the ordinary page allocator is sufficient. This way, efi_allocate_pages_aligned() will only be pulled into the build if it is actually being used (which will be on arm64 only in the immediate future) Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-04-23efi/libstub/arm64: Simplify randomized loading of kernel imageArd Biesheuvel
The KASLR code path in the arm64 version of the EFI stub incorporates some overly complicated logic to randomly allocate a region of the right alignment: there is no need to randomize the placement of the kernel modulo 2 MiB separately from the placement of the 2 MiB aligned allocation itself - we can simply follow the same logic used by the non-randomized placement, which is to allocate at the correct alignment, and only take TEXT_OFFSET into account if it is not a round multiple of the alignment. Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-04-23efi/libstub/arm64: Replace 'preferred' offset with alignment checkArd Biesheuvel
The notion of a 'preferred' load offset for the kernel dates back to the times when the kernel's primary mapping overlapped with the linear region, and memory below it could not be used at all. Today, the arm64 kernel does not really care where it is loaded in physical memory, as long as the alignment requirements are met, and so there is no point in unconditionally moving the kernel to a new location in memory at boot. Instead, we can - check for a KASLR seed, and randomly reallocate the kernel if one is provided - otherwise, check whether the alignment requirements are met for the current placement of the kernel, and just run it in place if they are - finally, do an ordinary page allocation and reallocate the kernel to a suitably aligned buffer anywhere in memory. By the same reasoning, there is no need to take TEXT_OFFSET into account if it is a round multiple of the minimum alignment, which is the usual case for relocatable kernels with TEXT_OFFSET randomization disabled. Otherwise, it suffices to use the relative misaligment of TEXT_OFFSET when reallocating the kernel. Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-04-23efi/libstub/random: Increase random alloc granularityArd Biesheuvel
The implementation of efi_random_alloc() arbitrarily truncates the provided random seed to 16 bits, which limits the granularity of the randomly chosen allocation offset in memory. This is currently only an issue if the size of physical memory exceeds 128 GB, but going forward, we will reduce the allocation alignment to 64 KB, and this means we need to increase the granularity to ensure that the random memory allocations are distributed evenly. We will need to switch to 64-bit arithmetic for the multiplication, but this does not result in 64-bit integer intrinsic calls on ARM or on i386. Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-04-23efi/libstub/random: Align allocate size to EFI_ALLOC_ALIGNArd Biesheuvel
The EFI stub uses a per-architecture #define for the minimum base and size alignment of page allocations, which is set to 4 KB for all architecures except arm64, which uses 64 KB, to ensure that allocations can always be (un)mapped efficiently, regardless of the page size used by the kernel proper, which could be a kexec'ee The API wrappers around page based allocations assume that this alignment is always taken into account, and so efi_free() will also round up its size argument to EFI_ALLOC_ALIGN. Currently, efi_random_alloc() does not honour this alignment for the allocated size, and so freeing such an allocation may result in unrelated memory to be freed, potentially leading to issues after boot. So let's round up size in efi_random_alloc() as well. Fixes: 2ddbfc81eac84a29 ("efi: stub: add implementation of efi_random_alloc()") Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-04-23efi/gop: Allow automatically choosing the best modeArvind Sankar
Add the ability to automatically pick the highest resolution video mode (defined as the product of vertical and horizontal resolution) by using a command-line argument of the form video=efifb:auto If there are multiple modes with the highest resolution, pick one with the highest color depth. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20200328160601.378299-2-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-04-23efi/gop: Allow specifying depth as well as resolutionArvind Sankar
Extend the video mode argument to handle an optional color depth specification of the form video=efifb:<xres>x<yres>[-(rgb|bgr|<bpp>)] Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20200320020028.1936003-14-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-04-23efi/gop: Allow specifying mode by <xres>x<yres>Arvind Sankar
Add the ability to choose a video mode using a command-line argument of the form video=efifb:<xres>x<yres> Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20200320020028.1936003-13-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-04-23efi/gop: Allow specifying mode number on command lineArvind Sankar
Add the ability to choose a video mode for the selected gop by using a command-line argument of the form video=efifb:mode=<n> Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20200320020028.1936003-12-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-04-23efi/gop: Add prototypes for query_mode and set_modeArvind Sankar
Add prototypes and argmap for the Graphics Output Protocol's QueryMode and SetMode functions. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20200320020028.1936003-11-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-04-23efi/gop: Remove unreachable code from setup_pixel_infoArvind Sankar
pixel_format must be one of PIXEL_RGB_RESERVED_8BIT_PER_COLOR PIXEL_BGR_RESERVED_8BIT_PER_COLOR PIXEL_BIT_MASK since we skip PIXEL_BLT_ONLY when finding a gop. Remove the redundant code and add another check in find_gop to skip any pixel formats that we don't know about, in case a later version of the UEFI spec adds one. Reformat the code a little. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20200320020028.1936003-10-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-04-23efi/gop: Use helper macros for find_bitsArvind Sankar
Use the __ffs/__fls macros to calculate the position and size of the mask. Correct type of mask to u32 instead of unsigned long. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20200320020028.1936003-9-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-04-23efi/gop: Use helper macros for populating lfb_baseArvind Sankar
Use the lower/upper_32_bits macros from kernel.h to initialize si->lfb_base and si->ext_lfb_base. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20200320020028.1936003-8-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-04-23efi/gop: Move variable declarations into loop blockArvind Sankar
Declare the variables inside the block where they're used. Get rid of a couple of redundant initializers. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20200320020028.1936003-7-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-04-23efi/gop: Slightly re-arrange logic of find_gopArvind Sankar
Small cleanup to get rid of conout_found. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20200320020028.1936003-6-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-04-23efi/gop: Factor out locating the gop into a functionArvind Sankar
Move the loop to find a gop into its own function. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20200320020028.1936003-5-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-04-23efi/gop: Get mode information outside the loopArvind Sankar
Move extraction of the mode information parameters outside the loop to find the gop, and eliminate some redundant variables. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20200320020028.1936003-4-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-04-23efi/gop: Move check for framebuffer before con_outArvind Sankar
If the gop doesn't have a framebuffer, there's no point in checking for con_out support. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20200320020028.1936003-3-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org>