Re: [PATCH v6 0/5] efi/firmware/platform-x86: Add EFI embedded fw support

On Fri, Jun 1, 2018 at 5:53 AM Hans de Goede wrote: > > Hi All, > > Here is v6 of my patch-set to add support for EFI embedded fw to the kernel. > > This patch-set applies on top of the "[PATCH v7 00/14] firmware_loader > changes for v4.18" series from mcgrof. > > It now also depends on the

Re: [PATCH V5 0/3] Use efi_rts_wq to invoke EFI Runtime Services

On 29 May 2018 at 07:51, Sai Praneeth Prakhya wrote: > From: Sai Praneeth > > Problem statement: > -- > Presently, efi_runtime_services() silently switch %cr3 from swapper_pgd > to efi_pgd. As a consequence, kernel code that runs in efi_pgd (e.g., > perf code via an NMI) will

Re: [PATCH v6 2/5] efi: Add embedded peripheral firmware support

On 06/01/2018 05:53 AM, Hans de Goede wrote: > > Reported-by: Dave Olsthoorn > Suggested-by: Peter Jones > Acked-by: Ard Biesheuvel > Signed-off-by: Hans de Goede > --- > --- > .../driver-api/firmware/request_firmware.rst | 76 + > drivers/base/firmware_loader/Makefile |

RE: [PATCH V5 0/3] Use efi_rts_wq to invoke EFI Runtime Services

> >> Testing: > >> > >> Tested using LUV (Linux UEFI Validation) for x86_64, x86_32 and arm64 > >> (qemu only). Will appreciate the effort if someone could test the > >> patches on real ARM/ARM64 machines. > > I would give the latest v5 a try on my ARM64 qualcomm board as well. > WIll

Re: [PATCH v3 2/5] efi: Add embedded peripheral firmware support

On Tue, May 08, 2018 at 03:38:05PM +, Luis R. Rodriguez wrote: > On Fri, May 04, 2018 at 12:44:37PM -0700, Martijn Coenen wrote: > > On Wed, Apr 25, 2018 at 10:55 AM, Luis R. Rodriguez > > wrote: > > > Is ptr below > > > > > > ret = request_firmware_into_buf(_fw, fw_name, dev, > > >

Re: [PATCH V5 0/3] Use efi_rts_wq to invoke EFI Runtime Services

Hi Sai, Ard, On Tue, May 29, 2018 at 4:39 PM, Ard Biesheuvel wrote: > On 29 May 2018 at 04:21, Sai Praneeth Prakhya > wrote: >> From: Sai Praneeth >> >> Problem statement: >> -- >> Presently, efi_runtime_services() silently switch %cr3 from swapper_pgd >> to efi_pgd. As a

Re: [PATCH 2/3] x86/build: use -std=gnu89 for proper extern inline semantics

On June 1, 2018 9:55:49 AM PDT, Nick Desaulniers wrote: >The top level Makefile explicitly sets the C standard used in the >kernel >to gnu89. By overriding KBUILD_CFLAGS, the C standard used for this >subdir is now implicit based on compiler and compiler version. GCC >changes this implicit

[PATCH 3/3] x86: paravirt: make native_save_fl extern inline

native_save_fl() is marked static inline, but by using it as a function pointer in arch/x86/kernel/paravirt.c, it MUST be outlined. paravirt's use of native_save_fl() also requires that no GPRs other than %rax are clobbered. Compilers have different heuristics which they use to emit stack guard

[PATCH 1/3] efi: use -std=gnu89 for proper extern inline semantics

The top level Makefile explicitly sets the C standard used in the kernel to gnu89. By overriding KBUILD_CFLAGS, the C standard used for this subdir is now implicit based on compiler and compiler version. GCC changes this implicit default from gnu89 to gnu11 in v5.1. This implies that depending on

[PATCH 2/3] x86/build: use -std=gnu89 for proper extern inline semantics

The top level Makefile explicitly sets the C standard used in the kernel to gnu89. By overriding KBUILD_CFLAGS, the C standard used for this subdir is now implicit based on compiler and compiler version. GCC changes this implicit default from gnu89 to gnu11 in v5.1. This implies that depending on

[PATCH 0/3] extern inline native_save_fl for paravirt

paravirt depends on a custom calling convention (callee saved), but expects this from a static inline function that it then forces to be outlined. This is problematic because different compilers or flags can then add a stack guard that violates the calling conventions. Uses extern inline with the

[PATCH v6 3/5] platform/x86: Rename silead_dmi to touchscreen_dmi

Not only silead touchscreens need some extra info not available in the ACPI tables to work properly. X86 devices with a Chipone ICN8505 chip also need some DMI based extra configuration. There is no reason to have separate dmi config code per touchscreen controller vendor. This commit renames

[PATCH v6 1/5] efi: Export boot-services code and data as debugfs-blobs

Sometimes it is useful to be able to dump the efi boot-services code and data. This commit adds these as debugfs-blobs to /sys/kernel/debug/efi, but only if efi=debug is passed on the kernel-commandline as this requires not freeing those memory-regions, which costs 20+ MB of RAM. Reviewed-by:

[PATCH v6 2/5] efi: Add embedded peripheral firmware support

Just like with PCI options ROMs, which we save in the setup_efi_pci* functions from arch/x86/boot/compressed/eboot.c, the EFI code / ROM itself sometimes may contain data which is useful/necessary for peripheral drivers to have access to. Specifically the EFI code may contain an embedded copy of

[PATCH v6 5/5] platform/x86: touchscreen_dmi: Add info for the Chuwi Vi8 Plus tablet

Add touchscreen info for the Chuwi Vi8 Plus tablet. This tablet uses a Chipone ICN8505 touchscreen controller, with the firmware used by the touchscreen embedded in the EFI firmware. Acked-by: Andy Shevchenko Acked-by: Ard Biesheuvel Signed-off-by: Hans de Goede --- Changes in v6: -Switch from

[PATCH v6 4/5] platform/x86: touchscreen_dmi: Add EFI embedded firmware info support

Sofar we have been unable to get permission from the vendors to put the firmware for touchscreens listed in touchscreen_dmi in linux-firmware. Some of the tablets with such a touchscreen have a touchscreen driver, and thus a copy of the firmware, as part of their EFI code. This commit adds the

[PATCH v6 0/5] efi/firmware/platform-x86: Add EFI embedded fw support

Hi All, Here is v6 of my patch-set to add support for EFI embedded fw to the kernel. This patch-set applies on top of the "[PATCH v7 00/14] firmware_loader changes for v4.18" series from mcgrof. It now also depends on the series from Andy Lutomirski which allow using the sha256 code in a