[PATCH V15 03/11] cper: add timestamp print to CPER status printing

The ACPI 6.1 spec added a timestamp to the HEST generic data structure. Print the timestamp out when printing out the error status information. Signed-off-by: Tyler Baicar CC: Jonathan (Zhixiong) Zhang Reviewed-by: James Morse

[PATCH V15 00/11] Add UEFI 2.6 and ACPI 6.1 updates for RAS on ARM64

When a memory error, CPU error, PCIe error, or other type of hardware error that's covered by RAS occurs, firmware should populate the shared GHES memory location with the proper GHES structures to notify the OS of the error. For example, platforms that implement firmware first handling may

[PATCH V15 02/11] ras: acpi/apei: cper: add support for generic data v3 structure

The ACPI 6.1 spec adds a new version of the generic data structure. Add support to handle the new structure as well as properly verify and iterate through the generic data entries. Signed-off-by: Tyler Baicar CC: Jonathan (Zhixiong) Zhang

[PATCH V15 06/11] acpi: apei: handle SEA notification type for ARMv8

ARM APEI extension proposal added SEA (Synchronous External Abort) notification type for ARMv8. Add a new GHES error source handling function for SEA. If an error source's notification type is SEA, then this function can be registered into the SEA exception handler. That way GHES will parse and

[PATCH V15 04/11] efi: parse ARM processor error

Add support for ARM Common Platform Error Record (CPER). UEFI 2.6 specification adds support for ARM specific processor error information to be reported as part of the CPER records. This provides more detail on for processor error logs. Signed-off-by: Tyler Baicar CC:

[PATCH V15 05/11] arm64: exception: handle Synchronous External Abort

SEA exceptions are often caused by an uncorrected hardware error, and are handled when data abort and instruction abort exception classes have specific values for their Fault Status Code. When SEA occurs, before killing the process, report the error in the kernel logs. Update fault_info[] with

[PATCH V15 07/11] acpi: apei: panic OS with fatal error status block

From: "Jonathan (Zhixiong) Zhang" Even if an error status block's severity is fatal, the kernel does not honor the severity level and panic. With the firmware first model, the platform could inform the OS about a fatal hardware error through the non-NMI GHES notification

[PATCH V15 09/11] ras: acpi / apei: generate trace event for unrecognized CPER section

UEFI spec allows for non-standard section in Common Platform Error Record. This is defined in section N.2.3 of UEFI version 2.5. Currently if the CPER section's type (UUID) does not match with any section type that the kernel knows how to parse, trace event is not generated for such section. And

[PATCH V15 08/11] efi: print unrecognized CPER section

UEFI spec allows for non-standard section in Common Platform Error Record. This is defined in section N.2.3 of UEFI version 2.5. Currently if the CPER section's type (UUID) does not match with one of the section types that the kernel knows how to parse, the section is skipped. Therefore, user is

[PATCH V15 10/11] trace, ras: add ARM processor error trace event

Currently there are trace events for the various RAS errors with the exception of ARM processor type errors. Add a new trace event for such errors so that the user will know when they occur. These trace events are consistent with the ARM processor error section type defined in UEFI 2.6 spec

[PATCH V15 11/11] arm/arm64: KVM: add guest SEA support

Currently external aborts are unsupported by the guest abort handling. Add handling for SEAs so that the host kernel reports SEAs which occur in the guest kernel. When an SEA occurs in the guest kernel, the guest exits and is routed to kvm_handle_guest_abort(). Prior to this patch, a print

[PATCH v5 01/32] x86: Documentation for AMD Secure Memory Encryption (SME)

Create a Documentation entry to describe the AMD Secure Memory Encryption (SME) feature and add documentation for the mem_encrypt= kernel parameter. Signed-off-by: Tom Lendacky --- Documentation/admin-guide/kernel-parameters.txt | 11

[PATCH v5 06/32] x86/mm: Add Secure Memory Encryption (SME) support

Add support for Secure Memory Encryption (SME). This initial support provides a Kconfig entry to build the SME support into the kernel and defines the memory encryption mask that will be used in subsequent patches to mark pages as encrypted. Signed-off-by: Tom Lendacky

[PATCH v5 01/32] x86: Documentation for AMD Secure Memory Encryption (SME)

Create a Documentation entry to describe the AMD Secure Memory Encryption (SME) feature and add documentation for the mem_encrypt= kernel parameter. Signed-off-by: Tom Lendacky --- Documentation/admin-guide/kernel-parameters.txt | 11

[PATCH v5 03/32] x86, mpparse, x86/acpi, x86/PCI, SFI: Use memremap for RAM mappings

The ioremap() function is intended for mapping MMIO. For RAM, the memremap() function can be used. Convert calls from ioremap() to memremap() when re-mapping RAM. This will be used later by SME to control how the encryption mask is applied to memory mappings, with certain memory locations being

[PATCH v5 08/32] x86/mm: Simplify p[g4um]d_page() macros

Create a pgd_pfn() and p4d_pfn() macro similar to the p[um]d_pfn() macros and then use the p[g4um]d_pfn() macros in the p[g4um]d_page() macros instead of duplicating the code. Signed-off-by: Tom Lendacky --- arch/x86/include/asm/pgtable.h | 16 +--- 1 file

[PATCH v5 07/32] x86/mm: Add support to enable SME in early boot processing

Add support to the early boot code to use Secure Memory Encryption (SME). Since the kernel has been loaded into memory in a decrypted state, support is added to encrypt the kernel in place and update the early pagetables with the memory encryption mask so that new pagetable entries will use memory

[PATCH v5 10/32] x86/mm: Extend early_memremap() support with additional attrs

Add early_memremap() support to be able to specify encrypted and decrypted mappings with and without write-protection. The use of write-protection is necessary when encrypting data "in place". The write-protect attribute is considered cacheable for loads, but not stores. This implies that the

[PATCH v5 14/32] efi: Add an EFI table address match function

Add a function that will determine if a supplied physical address matches the address of an EFI table. Signed-off-by: Tom Lendacky --- drivers/firmware/efi/efi.c | 33 + include/linux/efi.h|7 +++ 2 files changed, 40

[PATCH v5 13/32] x86/boot/e820: Add support to determine the E820 type of an address

Add a function that will return the E820 type associated with an address range. Signed-off-by: Tom Lendacky --- arch/x86/include/asm/e820/api.h |2 ++ arch/x86/kernel/e820.c | 26 +++--- 2 files changed, 25 insertions(+), 3

[PATCH v5 18/32] x86, mpparse: Use memremap to map the mpf and mpc data

The SMP MP-table is built by UEFI and placed in memory in a decrypted state. These tables are accessed using a mix of early_memremap(), early_memunmap(), phys_to_virt() and virt_to_phys(). Change all accesses to use early_memremap()/early_memunmap(). This allows for proper setting of the

[PATCH v5 20/32] x86/mm: Add support for changing the memory encryption attribute

Add support for changing the memory encryption attribute for one or more memory pages. This will be useful when we have to change the AP trampoline area to not be encrypted. Or when we need to change the SWIOTLB area to not be encrypted in support of devices that can't support the encryption mask

[PATCH v5 23/32] swiotlb: Add warnings for use of bounce buffers with SME

Add warnings to let the user know when bounce buffers are being used for DMA when SME is active. Since the bounce buffers are not in encrypted memory, these notifications are to allow the user to determine some appropriate action - if necessary. Signed-off-by: Tom Lendacky

[PATCH v5 19/32] x86/mm: Add support to access persistent memory in the clear

Persistent memory is expected to persist across reboots. The encryption key used by SME will change across reboots which will result in corrupted persistent memory. Persistent memory is handed out by block devices through memory remapping functions, so be sure not to map this memory as encrypted.

[PATCH v5 17/32] x86/mm: Add support to access boot related data in the clear

Boot data (such as EFI related data) is not encrypted when the system is booted because UEFI/BIOS does not run with SME active. In order to access this data properly it needs to be mapped decrypted. The early_memremap() support is updated to provide an arch specific routine to modify the

[PATCH v5 26/32] x86, drm, fbdev: Do not specify encrypted memory for video mappings

Since video memory needs to be accessed decrypted, be sure that the memory encryption mask is not set for the video ranges. Signed-off-by: Tom Lendacky --- arch/x86/include/asm/vga.h | 13 + arch/x86/mm/pageattr.c |2 ++

[PATCH v5 22/32] x86, swiotlb: DMA support for memory encryption

Since DMA addresses will effectively look like 48-bit addresses when the memory encryption mask is set, SWIOTLB is needed if the DMA mask of the device performing the DMA does not support 48-bits. SWIOTLB will be initialized to create decrypted bounce buffers for use by these devices.

[PATCH v5 32/32] x86/mm: Add support to make use of Secure Memory Encryption

Add support to check if SME has been enabled and if memory encryption should be activated (checking of command line option based on the configuration of the default state). If memory encryption is to be activated, then the encryption mask is set and the kernel is encrypted "in place."

[PATCH v5 30/32] x86/boot: Add early cmdline parsing for options with arguments

Add a cmdline_find_option() function to look for cmdline options that take arguments. The argument is returned in a supplied buffer and the argument length (regardless of whether it fits in the supplied buffer) is returned, with -1 indicating not found. Signed-off-by: Tom Lendacky

[PATCH v5 31/32] x86: Add sysfs support for Secure Memory Encryption

Add sysfs support for SME so that user-space utilities (kdump, etc.) can determine if SME is active. A new directory will be created: /sys/kernel/mm/sme/ And two entries within the new directory: /sys/kernel/mm/sme/active /sys/kernel/mm/sme/encryption_mask Signed-off-by: Tom Lendacky

[PATCH v5 29/32] x86/mm: Add support to encrypt the kernel in-place

Add the support to encrypt the kernel in-place. This is done by creating new page mappings for the kernel - a decrypted write-protected mapping and an encrypted mapping. The kernel is encrypted by copying it through a temporary buffer. Signed-off-by: Tom Lendacky ---

[PATCH v5 28/32] x86/mm, kexec: Allow kexec to be used with SME

Provide support so that kexec can be used to boot a kernel when SME is enabled. Support is needed to allocate pages for kexec without encryption. This is needed in order to be able to reboot in the kernel in the same manner as originally booted. Additionally, when shutting down all of the CPUs

[PATCH v5 27/32] kvm: x86: svm: Enable Secure Memory Encryption within KVM

Update the KVM support to work with SME. The VMCB has a number of fields where physical addresses are used and these addresses must contain the memory encryption mask in order to properly access the encrypted memory. Also, use the memory encryption mask when creating and using the nested page

[PATCH v5 25/32] x86, realmode: Check for memory encryption on the APs

Add support to check if memory encryption is active in the kernel and that it has been enabled on the AP. If memory encryption is active in the kernel but has not been enabled on the AP, then set the memory encryption bit (bit 23) of MSR_K8_SYSCFG to enable memory encryption on that AP and allow

[PATCH v5 24/32] iommu/amd: Disable AMD IOMMU if memory encryption is active

For now, disable the AMD IOMMU if memory encryption is active. A future patch will re-enable the function with full memory encryption support. Signed-off-by: Tom Lendacky --- drivers/iommu/amd_iommu_init.c |7 +++ 1 file changed, 7 insertions(+) diff --git

[PATCH v5 21/32] x86, realmode: Decrypt trampoline area if memory encryption is active

When Secure Memory Encryption is enabled, the trampoline area must not be encrypted. A CPU running in real mode will not be able to decrypt memory that has been encrypted because it will not be able to use addresses with the memory encryption mask. Signed-off-by: Tom Lendacky

[PATCH v5 15/32] efi: Update efi_mem_type() to return an error rather than 0

The efi_mem_type() function currently returns a 0, which maps to EFI_RESERVED_TYPE, if the function is unable to find a memmap entry for the supplied physical address. Returning EFI_RESERVED_TYPE implies that a memmap entry exists, when it doesn't. Instead of returning 0, change the function to

[PATCH v5 12/32] x86/mm: Insure that boot memory areas are mapped properly

The boot data and command line data are present in memory in a decrypted state and are copied early in the boot process. The early page fault support will map these areas as encrypted, so before attempting to copy them, add decrypted mappings so the data is accessed properly when copied. For the

[PATCH v5 05/32] x86/CPU/AMD: Handle SME reduction in physical address size

When System Memory Encryption (SME) is enabled, the physical address space is reduced. Adjust the x86_phys_bits value to reflect this reduction. Signed-off-by: Tom Lendacky --- arch/x86/kernel/cpu/amd.c | 14 +++--- 1 file changed, 11 insertions(+), 3

[PATCH v5 04/32] x86/CPU/AMD: Add the Secure Memory Encryption CPU feature

Update the CPU features to include identifying and reporting on the Secure Memory Encryption (SME) feature. SME is identified by CPUID 0x801f, but requires BIOS support to enable it (set bit 23 of MSR_K8_SYSCFG). Only show the SME feature as available if reported by CPUID and enabled by

[PATCH v5 00/32] x86: Secure Memory Encryption (AMD)

This patch series provides support for AMD's new Secure Memory Encryption (SME) feature. SME can be used to mark individual pages of memory as encrypted through the page tables. A page of memory that is marked encrypted will be automatically decrypted when read from DRAM and will be automatically

[PATCH v5 04/32] x86/CPU/AMD: Add the Secure Memory Encryption CPU feature

Update the CPU features to include identifying and reporting on the Secure Memory Encryption (SME) feature. SME is identified by CPUID 0x801f, but requires BIOS support to enable it (set bit 23 of MSR_K8_SYSCFG). Only show the SME feature as available if reported by CPUID and enabled by

[PATCH v5 02/32] x86/mm/pat: Set write-protect cache mode for full PAT support

For processors that support PAT, set the write-protect cache mode (_PAGE_CACHE_MODE_WP) entry to the actual write-protect value (x05). Acked-by: Borislav Petkov Signed-off-by: Tom Lendacky --- arch/x86/mm/pat.c |6 +++--- 1 file changed, 3

[PATCH v5 05/32] x86/CPU/AMD: Handle SME reduction in physical address size

When System Memory Encryption (SME) is enabled, the physical address space is reduced. Adjust the x86_phys_bits value to reflect this reduction. Signed-off-by: Tom Lendacky --- arch/x86/kernel/cpu/amd.c | 14 +++--- 1 file changed, 11 insertions(+), 3

[PATCH v5 06/32] x86/mm: Add Secure Memory Encryption (SME) support

Add support for Secure Memory Encryption (SME). This initial support provides a Kconfig entry to build the SME support into the kernel and defines the memory encryption mask that will be used in subsequent patches to mark pages as encrypted. Signed-off-by: Tom Lendacky

[PATCH v5 00/32] x86: Secure Memory Encryption (AMD)

This patch series provides support for AMD's new Secure Memory Encryption (SME) feature. SME can be used to mark individual pages of memory as encrypted through the page tables. A page of memory that is marked encrypted will be automatically decrypted when read from DRAM and will be automatically

Re: [PATCH 8/8] efi/capsule: Add support for Quark security header

On 2017-04-18 19:10, Ard Biesheuvel wrote: > On 18 April 2017 at 14:46, Ard Biesheuvel wrote: >> On 18 April 2017 at 14:44, Matt Fleming wrote: >>> On Tue, 18 Apr, at 02:59:43PM, Jan Kiszka wrote: I've implemented this, but for the

Re: [PATCH 12/24] PCI: Lock down BAR access when the kernel is locked down

On Wed, Apr 05, 2017 at 09:16:18PM +0100, David Howells wrote: > From: Matthew Garrett > > Any hardware that can potentially generate DMA has to be locked down in > order to avoid it being possible for an attacker to modify kernel code, > allowing them to circumvent

Re: [PATCH 15/24] asus-wmi: Restrict debugfs interface when the kernel is locked down

On Tue, 2017-04-18 at 16:30 +0100, David Howells wrote: > Ben Hutchings wrote: > > > So it's generally not going to be OK to turn off debugfs.  There will > > probably need to be a distinction between believed-safe and unsafe > > directories/files. > > Any suggestion on

Re: [PATCH 8/8] efi/capsule: Add support for Quark security header

On 18 April 2017 at 14:46, Ard Biesheuvel wrote: > On 18 April 2017 at 14:44, Matt Fleming wrote: >> On Tue, 18 Apr, at 02:59:43PM, Jan Kiszka wrote: >>> >>> I've implemented this, but for the old design, and Ard took over then. >>> So it

Re: [PATCH 0/8] efi: add support for non-standard capsule headers

On 2017-04-18 18:23, Ard Biesheuvel wrote: > On 18 April 2017 at 17:26, Bryan O'Donoghue > wrote: >> >> >> On 05/04/17 10:23, Ard Biesheuvel wrote: >>> >>> This is a followup to Jan's series [0] to add support for the non-standard >>> and awkward capsule header

Re: [PATCH 0/8] efi: add support for non-standard capsule headers

On 18/04/17 17:23, Ard Biesheuvel wrote: On 18 April 2017 at 17:26, Bryan O'Donoghue wrote: On 05/04/17 10:23, Ard Biesheuvel wrote: This is a followup to Jan's series [0] to add support for the non-standard and awkward capsule header layout that is used by

Re: [PATCH 0/8] efi: add support for non-standard capsule headers

On 18 April 2017 at 17:26, Bryan O'Donoghue wrote: > > > On 05/04/17 10:23, Ard Biesheuvel wrote: >> >> This is a followup to Jan's series [0] to add support for the non-standard >> and awkward capsule header layout that is used by the Quark platform. >> >> While we

Re: [PATCH 0/8] efi: add support for non-standard capsule headers

On 05/04/17 10:23, Ard Biesheuvel wrote: This is a followup to Jan's series [0] to add support for the non-standard and awkward capsule header layout that is used by the Quark platform. While we would prefer to adhere to the standard rigorously, the reality (and common practice) in Linux is

Re: [PATCH 15/24] asus-wmi: Restrict debugfs interface when the kernel is locked down

Ben Hutchings wrote: > > Shouldn't this now appear under /sys/kernel/tracing/ ? > > True, but old tracing scripts didn't go away. Conversion to a symlink would fix that. David -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a

Re: [PATCH 15/24] asus-wmi: Restrict debugfs interface when the kernel is locked down

Ben Hutchings wrote: > So it's generally not going to be OK to turn off debugfs. There will > probably need to be a distinction between believed-safe and unsafe > directories/files. Any suggestion on how to mark this distinction? I'd prefer not to modify every read/write

Re: [PATCH 15/24] asus-wmi: Restrict debugfs interface when the kernel is locked down

On Tue, 2017-04-18 at 15:55 +0100, David Howells wrote: > Ben Hutchings wrote: > > > - tracing (now tracefs, but it's expected to appear under debugfs) > > Shouldn't this now appear under /sys/kernel/tracing/ ? True, but old tracing scripts didn't go away. Ben. -- Ben

Re: [PATCH 15/24] asus-wmi: Restrict debugfs interface when the kernel is locked down

Ben Hutchings wrote: > - tracing (now tracefs, but it's expected to appear under debugfs) Shouldn't this now appear under /sys/kernel/tracing/ ? David -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to

Re: [PATCH 15/24] asus-wmi: Restrict debugfs interface when the kernel is locked down

On Tue, 2017-04-18 at 09:06 +0300, Andy Shevchenko wrote: > > On Mon, Apr 10, 2017 at 4:16 PM, David Howells wrote: > > > > Andy Shevchenko wrote: > > > > > > > It looks a bit fragile when responsility of whatever reasons kernel > > > > > can't

Re: [PATCH] arm64: xen: Implement EFI reset_system callback

On Thu, 06 Apr, at 04:55:11PM, Mark Rutland wrote: > > Please, let's keep the Xen knowledge constrained to the Xen EFI wrapper, > rather than spreading it further. > > IMO, given reset_system is a *mandatory* function, the Xen wrapper > should provide an implementation. > > I don't see why you

Re: [PATCH 8/8] efi/capsule: Add support for Quark security header

On Tue, 18 Apr, at 02:59:43PM, Jan Kiszka wrote: > > I've implemented this, but for the old design, and Ard took over then. > So it never made it to the list. > > Whatever layout of these bits is preferred, it can probably be done. I > just need an indication that there is (likely) a consensus.

Re: [PATCH 7/8] efi/capsule-loader: use page addresses rather than struct page pointers

On Tue, 18 Apr, at 02:01:21PM, Ard Biesheuvel wrote: > On 18 April 2017 at 13:56, Matt Fleming wrote: > > On Wed, 05 Apr, at 10:23:16AM, Ard Biesheuvel wrote: > >> To give some leeway to code that handles non-standard capsule headers, > >> let's keep an array of page

Re: [PATCH 7/8] efi/capsule-loader: use page addresses rather than struct page pointers

On 18 April 2017 at 13:56, Matt Fleming wrote: > On Wed, 05 Apr, at 10:23:16AM, Ard Biesheuvel wrote: >> To give some leeway to code that handles non-standard capsule headers, >> let's keep an array of page addresses rather than struct page pointers. >> >> This gives

Re: [PATCH 8/8] efi/capsule: Add support for Quark security header

On 2017-04-18 14:55, Andy Shevchenko wrote: > On Tue, Apr 18, 2017 at 3:48 PM, Matt Fleming > wrote: >> On Wed, 05 Apr, at 10:23:17AM, Ard Biesheuvel wrote: > >>> The firmware for Quark X102x prepends a security header to the capsule >>> which is needed to support the

Re: [PATCH 7/8] efi/capsule-loader: use page addresses rather than struct page pointers

On Wed, 05 Apr, at 10:23:16AM, Ard Biesheuvel wrote: > To give some leeway to code that handles non-standard capsule headers, > let's keep an array of page addresses rather than struct page pointers. > > This gives special implementations of efi_capsule_setup_info() the > opportunity to mangle

Re: [PATCH 8/8] efi/capsule: Add support for Quark security header

On Tue, Apr 18, 2017 at 3:48 PM, Matt Fleming wrote: > On Wed, 05 Apr, at 10:23:17AM, Ard Biesheuvel wrote: >> The firmware for Quark X102x prepends a security header to the capsule >> which is needed to support the mandatory secure boot on this processor. >> The header

Re: [PATCH 8/8] efi/capsule: Add support for Quark security header

On Wed, 05 Apr, at 10:23:17AM, Ard Biesheuvel wrote: > From: Jan Kiszka > > The firmware for Quark X102x prepends a security header to the capsule > which is needed to support the mandatory secure boot on this processor. > The header can be detected by checking for the

Re: [PATCH 6/8] efi/capsule-loader: indirect calls to efi_capsule_setup_info via weak alias

On Wed, 05 Apr, at 10:23:15AM, Ard Biesheuvel wrote: > To allow platform specific code to hook into the capsule loading > routines, indirect calls to efi_capsule_setup_info() via a weak alias > of __efi_capsule_setup_info(), allowing platforms to redefine the former > but still use the latter. >

Re: [PATCH 5/8] efi/capsule-loader: use cached copy of capsule header

On Wed, 05 Apr, at 10:23:14AM, Ard Biesheuvel wrote: > Instead of kmapping the capsule data twice, copy the capsule header > into the capsule info struct we keep locally. This is an improvement > by itself, but will also enable handling of non-standard header formats > more easily. > >

Re: [PATCH 4/8] efi/capsule: Adjust return type of efi_capsule_setup_info

On Wed, 05 Apr, at 10:23:13AM, Ard Biesheuvel wrote: > From: Jan Kiszka > > We actually expect int at the caller and never return any size > information. > > Signed-off-by: Jan Kiszka > Cc: Matt Fleming > Signed-off-by:

Re: [PATCH 3/8] efi/capsule: Clean up pr_err/info messages

On Wed, 05 Apr, at 10:23:12AM, Ard Biesheuvel wrote: > From: Jan Kiszka > > Avoid __func__, improve the information provided by some of the > messages. > > Signed-off-by: Jan Kiszka > Cc: Matt Fleming > Signed-off-by:

Re: [PATCH 1/8] efi/capsule: Fix return code on failing kmap/vmap

On Wed, 05 Apr, at 10:23:10AM, Ard Biesheuvel wrote: > From: Jan Kiszka > > If kmap or vmap fail, it means we ran out of memory. There are no > user-provided addressed involved that would justify EFAULT. > > Signed-off-by: Jan Kiszka > Cc: Matt

Re: [PATCH 2/8] efi/capsule: Remove pr_debug on ENOMEM or EFAULT

On Wed, 05 Apr, at 10:23:11AM, Ard Biesheuvel wrote: > From: Jan Kiszka > > Both cases are not worth a debug log message - the error code is telling > enough. > > Signed-off-by: Jan Kiszka > Cc: Matt Fleming >

Re: [PATCH 15/24] asus-wmi: Restrict debugfs interface when the kernel is locked down

On Mon, Apr 10, 2017 at 4:16 PM, David Howells wrote: > Andy Shevchenko wrote: > >> >> It looks a bit fragile when responsility of whatever reasons kernel >> >> can't serve become a driver burden. >> >> Can we fix this in debugfs framework instead?