Fix get_efi_config_table using the wrong structs when booting a
64 bit kernel on 32 bit firmware.
Cc: Matthew Garrett
Cc: Ard Biesheuvel
Cc: Jarkko Sakkinen
Fixes: 82d736ac56d7 ("Abstract out support for locating an EFI config table")
Signed-off-by: Hans de Goede
---
.../firmware/e
Hi,
On 05-08-19 18:01, Ard Biesheuvel wrote:
On Sun, 4 Aug 2019 at 19:12, Hans de Goede wrote:
Hi,
On 04-08-19 17:33, Ard Biesheuvel wrote:
Hi Hans,
On Sun, 4 Aug 2019 at 13:00, Hans de Goede wrote:
Hi All,
While testing 5.3-rc2 on an Irbis TW90 Intel Cherry Trail based
tablet I
Hi,
On 07-08-19 22:13, Hans de Goede wrote:
Hi,
On 07-08-19 21:58, Hans de Goede wrote:
Hi,
On 05-08-19 18:01, Ard Biesheuvel wrote:
On Sun, 4 Aug 2019 at 19:12, Hans de Goede wrote:
Hi,
On 04-08-19 17:33, Ard Biesheuvel wrote:
Hi Hans,
On Sun, 4 Aug 2019 at 13:00, Hans de Goede
Hi,
On 07-08-19 21:58, Hans de Goede wrote:
Hi,
On 05-08-19 18:01, Ard Biesheuvel wrote:
On Sun, 4 Aug 2019 at 19:12, Hans de Goede wrote:
Hi,
On 04-08-19 17:33, Ard Biesheuvel wrote:
Hi Hans,
On Sun, 4 Aug 2019 at 13:00, Hans de Goede wrote:
Hi All,
While testing 5.3-rc2 on an
Hi,
On 05-08-19 18:01, Ard Biesheuvel wrote:
On Sun, 4 Aug 2019 at 19:12, Hans de Goede wrote:
Hi,
On 04-08-19 17:33, Ard Biesheuvel wrote:
Hi Hans,
On Sun, 4 Aug 2019 at 13:00, Hans de Goede wrote:
Hi All,
While testing 5.3-rc2 on an Irbis TW90 Intel Cherry Trail based
tablet I
Hi,
On 06-08-19 17:53, Chris Coulson wrote:
Hi,
On 04/08/2019 11:00, Hans de Goede wrote:
Hi All,
While testing 5.3-rc2 on an Irbis TW90 Intel Cherry Trail based
tablet I noticed that it does not boot on this device.
A git bisect points to commit 166a2809d65b ("tpm: Don't duplic
Hi,
On 04-08-19 17:33, Ard Biesheuvel wrote:
Hi Hans,
On Sun, 4 Aug 2019 at 13:00, Hans de Goede wrote:
Hi All,
While testing 5.3-rc2 on an Irbis TW90 Intel Cherry Trail based
tablet I noticed that it does not boot on this device.
A git bisect points to commit 166a2809d65b ("tpm:
Hi All,
While testing 5.3-rc2 on an Irbis TW90 Intel Cherry Trail based
tablet I noticed that it does not boot on this device.
A git bisect points to commit 166a2809d65b ("tpm: Don't duplicate
events from the final event log in the TCG2 log")
And I can confirm that reverting just that single co
the valid BGRT table on this
device.
Rather then changing the reserved bits check, allowing only the 2 new bits,
instead just completely remove it so that we do not end up with a similar
problem when more bits are added in the future.
Signed-off-by: Hans de Goede
---
drivers/firmware/efi/efi
e options are
always processed. This fixes quiet not working.
This also fixes the libstub code ignoring nokaslr and efi=nochunk.
Reported-by: Peter Robinson
Signed-off-by: Hans de Goede
---
Changes in v2:
-Fix a compiler warning on 32 bit builds about casting a non pointer
sized integer to a pointe
Hi,
On 12-09-18 17:06, Ard Biesheuvel wrote:
On 12 September 2018 at 15:18, Hans de Goede wrote:
Before this commit we were only calling efi_parse_options() from
make_boot_params(), but make_boot_params() only gets called if the
kernel gets booted directly as an EFI executable. So when booted
e options are
always processed. This fixes quiet not working.
This also fixes the libstub code ignoring nokaslr and efi=nochunk.
Reported-by: Peter Robinson
Signed-off-by: Hans de Goede
---
arch/x86/boot/compressed/eboot.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/x86/boot/
Hi,
On 03-09-18 17:11, David Herrmann wrote:
Hey
On Mon, Sep 3, 2018 at 4:47 PM Hans de Goede wrote:
Hi,
On 03-09-18 16:16, Bartlomiej Zolnierkiewicz wrote:
Hi,
On Monday, September 03, 2018 03:23:38 PM David Herrmann wrote:
Hey
Since this commit:
34db50e55656 efifb: Copy the
Hi,
On 03-09-18 16:16, Bartlomiej Zolnierkiewicz wrote:
Hi,
On Monday, September 03, 2018 03:23:38 PM David Herrmann wrote:
Hey
Since this commit:
34db50e55656 efifb: Copy the ACPI BGRT
the kernel will override boot-splashs unasked. This breaks the
graphical boot-process on our setups
configurations
that don't need them (32-bit only and 64-bit only)
I've given a kernel with these patches a quick spin running in mixed
mode on a Bay Trail based tablet:
Tested-by: Hans de Goede
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-efi&qu
Hi,
On 11-07-18 12:13, Ingo Molnar wrote:
* Ard Biesheuvel wrote:
The following changes since commit 1e4b044d22517cae7047c99038abb23243ca:
Linux 4.18-rc4 (2018-07-08 16:34:02 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git
Bartlomiej,
Now that the fbcon deferred console takeover patches have been
merged I believe this series can be merged too ?
Note the first patch has an ack from Ard for merging the
1 line efi change through the fbdev tree.
Regards,
Hans
On 18-06-18 17:13, Hans de Goede wrote
set.
As this was the only use of the attributes field, we can remove
the call to PciIo->Attributes() entirely, which is especially
nice because its prototype involves uint64_t type by-value
arguments which the EFI mixed mode has trouble dealing with.
Cc: Wilfried Klaebe
Cc: Ingo Molnar
Cc: T
Hi Ard,
On 23-06-18 23:19, Ard Biesheuvel wrote:
Commit 2c3625cb9fa2
efi/x86: Fold __setup_efi_pci32() and __setup_efi_pci64() into one function
merged the two versions of __setup_efi_pciXX(), without taking into
account that the 32-bit version used a rather dodgy trick to pass an
immediate
Hi,
On 21-06-18 09:57, Ard Biesheuvel wrote:
On 21 June 2018 at 09:42, Hans de Goede wrote:
Commit 79832f0b5f71 ("efi/libstub/tpm: Initialize pointer variables to zero
for mixed mode") fixes a problem with the tpm code on mixed mode (64 bit
kernel on 32 bit UEFI), where 64-b
o 0 to, to ensure the upper 32 bits are
0 in mixed mode. This fixes recent kernels sometimes hanging during
early boot on mixed mode UEFI systems.
Signed-off-by: Hans de Goede
---
Changes in v2:
-Change commit message to reflect that efi_physical_addr_t is 64 bit
everywhere and some firmwares on
Hi,
On 20-06-18 09:49, Ard Biesheuvel wrote:
On 19 June 2018 at 21:50, Hans de Goede wrote:
Commit 79832f0b5f71 ("efi/libstub/tpm: Initialize pointer variables to zero
for mixed mode") fixes a problem with the tpm code on mixed mode (64 bit
kernel on 32 bit UEFI), where 64-b
ies to the efi_physical_addr_t variables which
are written by the get_event_log EFI call.
This commit initializes these to 0 to, to ensure the upper 32 bits are
0 in mixed mode. This fixes recent kernels sometimes hanging during
early boot on mixed mode UEFI systems.
Signed-off-by: Hans de Goede
---
driver
patch adds support to efifb to show the boot graphics and
automatically enables this when fbcon is configured for deferred
console takeover.
Signed-off-by: Hans de Goede
---
Changes in v2:
-Simplify the comment about acpi_bgrt.status
-Clear the parts of the screen which don't contain the logo to
bgrt_image_size is necessary to (optionally) show the boot graphics from
the efifb code. The efifb driver is a platform driver, using a normal
driver probe() driver callback. So even though it is always builtin it
cannot reference __initdata.
Acked-by: Ard Biesheuvel
Signed-off-by: Hans de Goede
Hi,
On 18-06-18 11:23, Daniel Vetter wrote:
On Sun, Jun 17, 2018 at 05:32:33PM +0200, Hans de Goede wrote:
Hi All,
Here is a patch-set to make sure that the efifb contains the boot
graphics from the ACPI BGRT extension when the kernel is configured
to use the (new) deferred fbcon console
Hi,
On 18-06-18 10:43, Ard Biesheuvel wrote:
On 18 June 2018 at 10:30, Hans de Goede wrote:
Hi,
On 18-06-18 09:36, Ard Biesheuvel wrote:
Hallo Hans,
On 17 June 2018 at 17:32, Hans de Goede wrote:
On systems where fbcon is configured for deferred console takeover, the
intend is for the
Hi,
On 18-06-18 09:36, Ard Biesheuvel wrote:
Hallo Hans,
On 17 June 2018 at 17:32, Hans de Goede wrote:
On systems where fbcon is configured for deferred console takeover, the
intend is for the framebuffer to show the boot graphics (e.g a vendor
logo) until some message (e.g. an error) is
Hi,
On 18-06-18 10:53, Môshe van der Sterre wrote:
Hi Hans,
On 06/17/2018 05:32 PM, Hans de Goede wrote:
On systems where fbcon is configured for deferred console takeover, the
intend is for the framebuffer to show the boot graphics (e.g a vendor
logo) until some message (e.g. an error) is
Hi All,
Here is a patch-set to make sure that the efifb contains the boot
graphics from the ACPI BGRT extension when the kernel is configured
to use the (new) deferred fbcon console takeover support.
Let me explain why this is desirable (same reason as for the deferred
fbcon console takeover supp
bgrt_image_size is necessary to (optionally) show the boot graphics from
the efifb code. The efifb driver is a platform driver, using a normal
driver probe() driver callback. So even though it is always builtin it
cannot reference __initdata.
Signed-off-by: Hans de Goede
---
drivers/firmware
(indicated by bgrt_tab.status being 0) and the boot graphics may have
been destroyed by e.g. the grub boot menu.
This patch adds support to efifb to show the boot graphics and
automatically enables this when fbcon is configured for deferred
console takeover.
Signed-off-by: Hans de Goede
---
drivers
Hi,
On 06-06-18 23:42, Luis R. Rodriguez wrote:
On Wed, Jun 06, 2018 at 08:39:15PM +0200, Hans de Goede wrote:
On 05-06-18 23:07, Luis R. Rodriguez wrote:
+To make request_firmware() fallback to trying EFI embedded firmwares after
this,
+the driver must set a boolean "efi-embedded-fir
Hi,
On 05-06-18 23:07, Luis R. Rodriguez wrote:
On Fri, Jun 01, 2018 at 02:53:27PM +0200, Hans de Goede wrote:
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
Hi,
On 05-06-18 22:46, Luis R. Rodriguez wrote:
On Fri, Jun 01, 2018 at 02:53:25PM +0200, 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&qu
Shevchenko
Acked-by: Ard Biesheuvel
Signed-off-by: Hans de Goede
---
MAINTAINERS | 2 +-
drivers/platform/x86/Kconfig | 16 ++---
drivers/platform/x86/Makefile | 2 +-
.../x86/{silead_dmi.c => touchscreen_dmi.c} |
: Greg Kroah-Hartman
Acked-by: Ard Biesheuvel
Signed-off-by: Hans de Goede
---
Changes in v5:
-Rename the EFI_BOOT_SERVICES flag to EFI_PRESERVE_BS_REGIONS
Changes in v4:
-Add new EFI_BOOT_SERVICES flag and use it to determine if the boot-services
memory segments are available (and thus if it makes
Acked-by: Ard Biesheuvel
Signed-off-by: Hans de Goede
---
Changes in v6:
-Rework code to remove casts from if (prefix == mem) comparison
-Use SHA256 hashes instead of crc32 sums
-Add new READING_FIRMWARE_EFI_EMBEDDED read_file_id and use it
-Call security_kernel_read_file(NULL
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
necessary info for the new EFI embedded-firmware code
to extract these firmwares, making the touchscreen work OOTB without the
user needing to manually add the firmware.
Acked-by: Andy Shevchenko
Acked-by: Ard Biesheuvel
Signed-off-by: Hans de Goede
---
Changes in v6:
-Switch from crc sums to
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 standal
Hi,
On 05/08/2018 06:12 PM, Luis R. Rodriguez wrote:
On Fri, May 04, 2018 at 07:54:28AM +0200, Ard Biesheuvel wrote:
On 4 May 2018 at 01:29, Luis R. Rodriguez wrote:
On Sun, Apr 29, 2018 at 11:35:55AM +0200, Hans de Goede wrote:
[...]
diff --git a/Documentation/driver-api/firmware
Hi,
On 05/13/2018 12:43 PM, Ard Biesheuvel wrote:
On 13 May 2018 at 13:03, Hans de Goede wrote:
Hi,
On 05/04/2018 06:56 AM, Ard Biesheuvel wrote:
Hi Hans,
One comment below, which I missed in review before.
On 29 April 2018 at 11:35, Hans de Goede wrote:
Just like with PCI options
Hi,
On 05/03/2018 11:35 PM, Andy Lutomirski wrote:
On Thu, May 3, 2018 at 3:31 PM Luis R. Rodriguez wrote:
On Wed, May 02, 2018 at 04:49:53PM +0200, Hans de Goede wrote:
Hi,
On 05/01/2018 09:29 PM, Andy Lutomirski wrote:
On Sun, Apr 29, 2018 at 2:36 AM Hans de Goede
wrote:
+The EFI
Hi,
On 05/03/2018 11:31 PM, Luis R. Rodriguez wrote:
On Wed, May 02, 2018 at 04:49:53PM +0200, Hans de Goede wrote:
Hi,
On 05/01/2018 09:29 PM, Andy Lutomirski wrote:
On Sun, Apr 29, 2018 at 2:36 AM Hans de Goede wrote:
+The EFI embedded-fw code works by scanning all EFI_BOOT_SERVICES_CODE
Hi,
On 05/04/2018 06:56 AM, Ard Biesheuvel wrote:
Hi Hans,
One comment below, which I missed in review before.
On 29 April 2018 at 11:35, Hans de Goede wrote:
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
Hi,
On 05/01/2018 09:29 PM, Andy Lutomirski wrote:
On Sun, Apr 29, 2018 at 2:36 AM Hans de Goede wrote:
+The EFI embedded-fw code works by scanning all EFI_BOOT_SERVICES_CODE
memory
+segments for an eight byte sequence matching prefix, if the prefix is
found it
+then does a crc32 over
Hi,
On 01-05-18 16:36, Mimi Zohar wrote:
[Cc'ing linux-security]
On Sun, 2018-04-29 at 11:35 +0200, Hans de Goede wrote:
[...]
diff --git a/drivers/base/firmware_loader/fallback_efi.c
b/drivers/base/firmware_loader/fallback_efi.c
new file mode 100644
index ..82ba82f48a79
---
on both a device with a 32 bit UEFI and on a device with
a 64 bit UEFI, using a 64 bit kernel on both cases. The second device also
used to show the "failed to alloc mem for rom" errors and I can confirm
this series fixes this:
Tested-by: Hans de Goede
Regards,
Hans
Changes in v4:
: Greg Kroah-Hartman
Acked-by: Ard Biesheuvel
Signed-off-by: Hans de Goede
---
Changes in v5:
-Rename the EFI_BOOT_SERVICES flag to EFI_PRESERVE_BS_REGIONS
Changes in v4:
-Add new EFI_BOOT_SERVICES flag and use it to determine if the boot-services
memory segments are available (and thus if it makes
Acked-by: Ard Biesheuvel
Signed-off-by: Hans de Goede
---
Changes in v5:
-Rename the EFI_BOOT_SERVICES flag to EFI_PRESERVE_BS_REGIONS
Changes in v4:
-Drop note in docs about EFI_FIRMWARE_VOLUME_PROTOCOL, it is not part of
UEFI proper, so the EFI maintainers don't want us referring people
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
---
drivers/platform/x86
necessary info for the new EFI embedded-firmware code
to extract these firmwares, making the touchscreen work OOTB without the
user needing to manually add the firmware.
Acked-by: Andy Shevchenko
Acked-by: Ard Biesheuvel
Signed-off-by: Hans de Goede
---
drivers/firmware/efi/embedded-firmware.c
Hi All,
Here is v5 of my patch-set to add support for EFI embedded fw to the kernel.
Changes since v4:
-Rename the EFI_BOOT_SERVICES flag to EFI_PRESERVE_BS_REGIONS
So I think this patch-set is getting close to ready for merging, which
brings us to the question of how to merge this, I think that
Shevchenko
Acked-by: Ard Biesheuvel
Signed-off-by: Hans de Goede
---
MAINTAINERS | 2 +-
drivers/platform/x86/Kconfig | 16 ++---
drivers/platform/x86/Makefile | 2 +-
.../x86/{silead_dmi.c => touchscreen_dmi.c} |
Hi,
On 29-04-18 11:07, Ard Biesheuvel wrote:
On 29 April 2018 at 10:40, Hans de Goede wrote:
Hi,
On 29-04-18 09:43, Ingo Molnar wrote:
* Hans de Goede wrote:
diff --git a/arch/x86/boot/compressed/eboot.c
b/arch/x86/boot/compressed/eboot.c
index 47d3efff6805..8650ab268ee7 100644
--- a
Hi,
On 29-04-18 09:43, Ingo Molnar wrote:
* Hans de Goede wrote:
diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index 47d3efff6805..8650ab268ee7 100644
--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
@@ -122,7 +122,14
mmit avoids the printing of these errors, by checking romsize before
doing the alloc and if it is larger then the EFI spec limit of 16 MiB
silently ignore the ROM fields instead of trying to alloc mem and fail.
Reviewed-by: Ard Biesheuvel
Signed-off-by: Hans de Goede
---
Changes in v3:
-Limit
Hi,
On 28-04-18 08:40, Ard Biesheuvel wrote:
Hi Hans,
On 27 April 2018 at 23:35, Hans de Goede wrote:
setup_efi_pci() tries to save a copy of each PCI option ROM as this may
be necessary for the device driver for the PCI device to have access too.
On some systems the efi_pci_io_protocol_64
s commit avoids the printing of these errors, by checking romsize
before doing the alloc and if it is larger then 256M silently ignore the
ROM fields instead of trying to alloc mem and fail.
Signed-off-by: Hans de Goede
---
Changes in v2:
-Add the check to both __setup_efi_pci32 and __setup_efi_p
Hi,
On 26-04-18 23:35, Ard Biesheuvel wrote:
On 26 April 2018 at 23:02, Hans de Goede wrote:
Hi,
On 26-04-18 18:51, Ard Biesheuvel wrote:
On 26 April 2018 at 14:06, Hans de Goede wrote:
Sometimes it is useful to be able to dump the efi boot-services code and
data. This commit adds
Hi,
On 26-04-18 18:51, Ard Biesheuvel wrote:
On 26 April 2018 at 14:06, Hans de Goede wrote:
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
Signed-off-by: Hans de Goede
---
Changes in v4:
-Drop note in docs about EFI_FIRMWARE_VOLUME_PROTOCOL, it is not part of
UEFI proper, so the EFI maintainers don't want us referring people to it
-Use new EFI_BOOT_SERVICES flag
-Put the new fw_get_efi_embedded_fw() function in it
: Greg Kroah-Hartman
Signed-off-by: Hans de Goede
---
Changes in v4:
-Add new EFI_BOOT_SERVICES flag and use it to determine if the boot-services
memory segments are available (and thus if it makes sense to register the
debugfs bits for them)
Changes in v2:
-Do not call pr_err on debugfs call
necessary info for the new EFI embedded-firmware code
to extract these firmwares, making the touchscreen work OOTB without the
user needing to manually add the firmware.
Acked-by: Andy Shevchenko
Signed-off-by: Hans de Goede
---
drivers/firmware/efi/embedded-firmware.c | 3 +++
drivers/platform
Shevchenko
Signed-off-by: Hans de Goede
---
MAINTAINERS | 2 +-
drivers/platform/x86/Kconfig | 16 ++---
drivers/platform/x86/Makefile | 2 +-
.../x86/{silead_dmi.c => touchscreen_dmi.c} | 66 +--
4 fi
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
Signed-off-by: Hans de Goede
---
drivers/platform/x86/touchscreen_dmi.c | 25
Hi All,
Here is v4 of my patch-set to add support for EFI embedded fw to the kernel.
Changes since v3:
-Drop note in docs about EFI_FIRMWARE_VOLUME_PROTOCOL, it is not part of
UEFI proper, so the EFI maintainers don't want us referring people to it
-Use new EFI_BOOT_SERVICES flag
-Put the new fw
Hi,
On 24-04-18 18:07, Mimi Zohar wrote:
On Tue, 2018-04-24 at 17:09 +0200, Hans de Goede wrote:
Hi,
On 23-04-18 23:11, Luis R. Rodriguez wrote:
Hans, please see use of READING_FIRMWARE_PREALLOC_BUFFER, we'll need a new ID
and security for this type of request so IMA can reject it i
Hi,
On 23-04-18 23:11, Luis R. Rodriguez wrote:
Hans, please see use of READING_FIRMWARE_PREALLOC_BUFFER, we'll need a new ID
and security for this type of request so IMA can reject it if the policy is
configured for it.
Hmm, interesting, actually it seems like the whole existence
of READING_F
Hi,
On 16-04-18 10:28, Ard Biesheuvel wrote:
On 8 April 2018 at 19:40, Hans de Goede wrote:
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
Hi,
On 16-04-18 10:23, Ard Biesheuvel wrote:
Hallo Hans,
On 8 April 2018 at 19:40, Hans de Goede wrote:
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
Hi,
On 17-04-18 02:17, Luis R. Rodriguez wrote:
On Sun, Apr 08, 2018 at 07:40:11PM +0200, Hans de Goede wrote:
static void firmware_free_data(const struct firmware *fw)
{
@@ -576,6 +600,15 @@ _request_firmware(const struct firmware **firmware_p,
const char *name,
goto out
Hi,
On 17-04-18 02:17, Luis R. Rodriguez wrote:
On Sun, Apr 08, 2018 at 07:40:11PM +0200, Hans de Goede wrote:
static void firmware_free_data(const struct firmware *fw)
{
@@ -576,6 +600,15 @@ _request_firmware(const struct firmware **firmware_p,
const char *name,
goto out
: Hans de Goede
---
Changes in v2:
-Do not call pr_err on debugfs call failures
---
arch/x86/platform/efi/quirks.c | 4 +++
drivers/firmware/efi/efi.c | 53 ++
2 files changed, 57 insertions(+)
diff --git a/arch/x86/platform/efi/quirks.c b/arch/x86/platform/efi
: Hans de Goede
---
MAINTAINERS | 2 +-
drivers/platform/x86/Kconfig | 16 ++---
drivers/platform/x86/Makefile | 2 +-
.../x86/{silead_dmi.c => touchscreen_dmi.c} | 66 +--
4 files changed, 43 insertions(+),
Signed-off-by: Hans de Goede
---
Changes in v2:
-Rebased on driver-core/driver-core-next
-Add documentation describing the EFI embedded firmware mechanism to:
Documentation/driver-api/firmware/request_firmware.rst
-Add a new EFI_EMBEDDED_FIRMWARE Kconfig bool and only build the embedded
fw
Hi All,
Sorry for sending a v3 so soon after v2, I got the property name wrong in the
documentation added in v2 and of course noticed that minutes after sending v2.
This version fixes this.
Here is the v2 coverletter again:
Here is v2 of my patch-set to add support for EFI embedded fw to the ker
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.
Signed-off-by: Hans de Goede
---
drivers/platform/x86/touchscreen_dmi.c | 25 +
1 file
necessary info for the new EFI embedded-firmware code
to extract these firmwares, making the touchscreen work OOTB without the
user needing to manually add the firmware.
Signed-off-by: Hans de Goede
---
drivers/firmware/efi/embedded-firmware.c | 3 +++
drivers/platform/x86/Kconfig
: Hans de Goede
---
Changes in v2:
-Do not call pr_err on debugfs call failures
---
arch/x86/platform/efi/quirks.c | 4 +++
drivers/firmware/efi/efi.c | 53 ++
2 files changed, 57 insertions(+)
diff --git a/arch/x86/platform/efi/quirks.c b/arch/x86/platform/efi
Signed-off-by: Hans de Goede
---
Changes in v2:
-Rebased on driver-core/driver-core-next
-Add documentation describing the EFI embedded firmware mechanism to:
Documentation/driver-api/firmware/request_firmware.rst
-Add a new EFI_EMBEDDED_FIRMWARE Kconfig bool and only build the embedded
fw
: Hans de Goede
---
MAINTAINERS | 2 +-
drivers/platform/x86/Kconfig | 16 ++---
drivers/platform/x86/Makefile | 2 +-
.../x86/{silead_dmi.c => touchscreen_dmi.c} | 66 +--
4 files changed, 43 insertions(+),
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.
Signed-off-by: Hans de Goede
---
drivers/platform/x86/touchscreen_dmi.c | 25 +
1 file
necessary info for the new EFI embedded-firmware code
to extract these firmwares, making the touchscreen work OOTB without the
user needing to manually add the firmware.
Signed-off-by: Hans de Goede
---
drivers/firmware/efi/embedded-firmware.c | 3 +++
drivers/platform/x86/Kconfig
Hi All,
Here is v2 of my patch-set to add support for EFI embedded fw to the kernel.
The 3 most prominent changes are:
1) Add documentation describing the EFI embedded firmware mechanism to:
Documentation/driver-api/firmware/request_firmware.rst
2) Instead of having a single dmi_system_id ar
Hi,
On 06-04-18 16:08, Luis R. Rodriguez wrote:
On Thu, Apr 05, 2018 at 07:43:49AM +0200, Lukas Wunner wrote:
On Wed, Apr 04, 2018 at 01:18:36PM -0400, Peter Jones wrote:
On Tue, Apr 03, 2018 at 08:07:11PM +0200, Lukas Wunner wrote:
* Add the EFI Firmware Volume Protocol to include/linux/efi.
pr 03, 2018 at 10:33:25AM +0200, Hans de Goede wrote:
This is not part of the standard. There has been a long(ish) standing issue
with us not being able to get re-distribute permission for the firmware for
some touchscreen controllers found on cheap x86 devices. Which means that
we cannot put
Hi,
On 03-04-18 21:53, Peter Jones wrote:
On Sat, Mar 31, 2018 at 02:19:44PM +0200, Hans de Goede wrote:
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index fddc5f706fd2..1a5ea950f58f 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -455,6
HI,
On 04-04-18 19:18, Peter Jones wrote:
On Tue, Apr 03, 2018 at 06:58:48PM +, Luis R. Rodriguez wrote:
On Tue, Apr 03, 2018 at 08:07:11PM +0200, Lukas Wunner wrote:
On Tue, Apr 03, 2018 at 10:33:25AM +0200, Hans de Goede wrote:
I asked Peter Jones for suggestions how to extract this
Hi Luis,
Thank you for the review.
On 03-04-18 01:23, Luis R. Rodriguez wrote:
On Sat, Mar 31, 2018 at 02:19:44PM +0200, Hans de Goede wrote:
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
Hi,
On 03/31/2018 04:10 PM, Greg Kroah-Hartman wrote:
On Sat, Mar 31, 2018 at 02:19:43PM +0200, Hans de Goede wrote:
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
commit also modifies efi_mem_desc_lookup() to not skip
EFI_BOOT_SERVICES_CODE memory-segments, so that efi_mem_reserve() works
on such segments.
Reported-by: Dave Olsthoorn
Suggested-by: Peter Jones
Signed-off-by: Hans de Goede
---
drivers/base/firmware_class.c| 29 +++
drivers
: Hans de Goede
---
arch/x86/platform/efi/quirks.c | 4 +++
drivers/firmware/efi/efi.c | 57 ++
2 files changed, 61 insertions(+)
diff --git a/arch/x86/platform/efi/quirks.c b/arch/x86/platform/efi/quirks.c
index 5b513ccffde4..0f968c7bcfec 100644
--- a/arch/x86
s commit avoids the printing of these errors, by checking romsize
before doing the alloc and if it is larger then 256M silently ignore the
ROM fields instead of trying to alloc mem and fail.
Signed-off-by: Hans de Goede
---
arch/x86/boot/compressed/eboot.c | 8 +++-
1 file changed, 7 i
Hi,
On 12-03-18 22:02, Ard Biesheuvel wrote:
On 12 March 2018 at 19:55, Thiebaud Weksteen wrote:
On Mon, Mar 12, 2018 at 7:33 PM Jeremy Cline wrote:
On 03/12/2018 02:29 PM, Thiebaud Weksteen wrote:
On Mon, Mar 12, 2018 at 6:30 PM Ard Biesheuvel <
ard.biesheu...@linaro.org>
wrote:
On 12
Hi,
On 12-03-18 20:55, Thiebaud Weksteen wrote:
On Mon, Mar 12, 2018 at 7:33 PM Jeremy Cline wrote:
On 03/12/2018 02:29 PM, Thiebaud Weksteen wrote:
On Mon, Mar 12, 2018 at 6:30 PM Ard Biesheuvel <
ard.biesheu...@linaro.org>
wrote:
On 12 March 2018 at 17:01, Jeremy Cline wrote:
On 03/1
Hi,
On 08-03-18 18:26, Jeremy Cline wrote:
On 03/08/2018 11:50 AM, Hans de Goede wrote:
Hi,
On 07-03-18 12:34, Javier Martinez Canillas wrote:
Are you also able to read the TPM event logs?
$ hexdump /sys/kernel/security/tpm0/binary_bios_measurements
Yes for me that outputs a lot of
Hi,
On 07-03-18 12:34, Javier Martinez Canillas wrote:
On 03/07/2018 12:10 PM, Hans de Goede wrote:
Both according to the BIOS and to the /sys/class/tpm/tpm0/device/description
file it is a TPM 2.0.
I see, so you can choose enabling the TPM 1.2 or TPM 2.0 device? At least that'
Hi,
On 07-03-18 09:41, Thiebaud Weksteen wrote:
Hi,
Thanks for testing and sending this report! This patch relies heavily on
the functions exposed by the firmware. My first guess would be that some of
these may not be implemented correctly by the manufacturer.
Could you share more information
1 - 100 of 103 matches
Mail list logo
