Linaro-acpi

linaro-acpi@lists.linaro.org

820 discussions

by Tomasz Nowicki

Hi Yi, I prepared couple of pointers for you. - wiki page about APEI which use SCI mechanism for x86: https://wiki.linaro.org/LEG/Engineering/Kernel/ACPI/EINJ - since there is no SCI for ARM we added to our acpi git tree commit which simulates SCI behaviour for test purposes: ACPI: Enable SCI_EMULATE to manually simulate physical hotplug testing You can find SCI emulation usage example on wiki page above. - JIRA card description which gives brief description of GPIO signalled events idea for ACPI Hardware Reduced profile: https://cards.linaro.org/browse/CARD-756 Let me know if you will have any questions. Tomasz

10 years, 9 months

[RFC PATCH v2 0/4] Introducing the Grand Unified Firmware Interface

by al.stone＠linaro.org

From: Al Stone <al.stone(a)linaro.org> These patches are experimental; they do actually compile and they even seem to execute correctly. They are by no means complete. The reason for posting them is really just to stir some discussion and see if this is a truly crazy idea or if it has some potential for easing the ACPI transition. These patches introduce GUFI: the Grand Unified Firmware Interface. Okay, yes, it is a silly name. I didn't spend a lot of time on it. What I'm most interested in is the idea and whether it is worth pursuing further, and whether or not there are better ways to do this if it does make sense. The idea is very simple: introduce a shim layer that looks like a merge of some sort between ACPI and FDT functionality in the kernel. In that shim layer, make it possible for a driver to make a single call to a function, and with that call, retrieve configuration information stored in either ACPI tables or a DT. Further, allow the kernel to specify which has priority -- i.e., search through ACPI tables, and then through FDT if data is not found, or vice versa -- or which is exclusive, either ACPI or FDT only. Why would I do this? As a kernel developer, this allows me to make changes in the direction of either FDT or ACPI as quickly or as slowly as I want to. Most of my config can be in FDT and I can then piecemeal convert to ACPI as I figure out ASL and/or any driver changes that may be needed. Secondly, if I do this well, the changes to convert from FDT to ACPI *should* be very small; from ACPI to FDT may be more difficult but over time that can likely be improved as well. If someone was clever, they could even add support for a specific board file and gradually convert that to FDT or ACPI. Third, in the really, really long term, maybe someone comes up with yet another hardware configuration description format that is so cool it provides sharks with laser beams on their heads and *everyone* wants to convert to it. With this layer in place, perhaps we can smooth even that transition by abstracting out the config info that's needed and the API to retrieve it. So, what do you think? Changes in v2: -- Took a completely different approach to the overall structure based on feedback from Tomasz Nowicki. -- Changed an assumption: originally, I wanted to absolutely minimize the changes in API between OF and GUFI. That assumption has been dropped in favor of defining a more general API that will attempt to merge the best of ACPI and OF. -- The changes to vexpress-sysreg are for only one OF call for now. The previous version was more complete, but this version works. Over time, further changes will be made as each call is converted to this newer API. Al Stone (4): GUFI: add kernel config options for GUFI GUFI: introduce the basic framework ARM64: GUFI: add setup_arch() call to gufi_init() GUFI: MFD: initial change to use one GUFI API call in vexpress-sysreg arch/arm64/Kconfig | 6 - arch/arm64/kernel/setup.c | 5 + drivers/Kconfig | 2 + drivers/gufi/Kconfig | 44 +++++++ drivers/gufi/Makefile | 11 ++ drivers/gufi/acpi_protocol.c | 35 +++++ drivers/gufi/acpi_protocol.h | 37 ++++++ drivers/gufi/core.c | 296 ++++++++++++++++++++++++++++++++++++++++++ drivers/gufi/of_protocol.c | 44 +++++++ drivers/gufi/of_protocol.h | 37 ++++++ drivers/mfd/vexpress-sysreg.c | 5 +- include/linux/gufi.h | 62 +++++++++ 12 files changed, 577 insertions(+), 7 deletions(-) create mode 100644 drivers/gufi/Kconfig create mode 100644 drivers/gufi/Makefile create mode 100644 drivers/gufi/acpi_protocol.c create mode 100644 drivers/gufi/acpi_protocol.h create mode 100644 drivers/gufi/core.c create mode 100644 drivers/gufi/of_protocol.c create mode 100644 drivers/gufi/of_protocol.h create mode 100644 include/linux/gufi.h -- 1.8.4.2

10 years, 9 months

[PATCH v6 0/6] Hardware Reduced Mode Cleanup for ACPI

by al.stone＠linaro.org

From: Al Stone <al.stone(a)linaro.org> This series of patches starts with Hanjun's patch to create a kernel config item for CONFIG_ACPI_REDUCED_HARDWARE [0]. Building on that, I then reviewed all of the code that touched any of several fields in the FADT that the OSPM is supposed to ignore when ACPI is in Hardware Reduced mode [1]. Any time there was a use of one of the fields to be ignored, I evaluated whether or not the code was implementing Hardware Reduced mode correctly. Similarly, for each the flags in the FADT flags field that are to be ignored in Hardware Reduced mode, the kernel code was again scanned for proper usage. The remainder of the patches are to fix all of the situations I could find where the kernel would not behave correctly in this ACPI mode. These seem to work just fine on the RTSM model for ARMv7, both with and without ACPI enabled, and with and without ACPI_REDUCED_HARDWARE enabled; similarly for the FVP model for ARMv8. The patches for ACPI on ARM hardware have been submitted elsewhere but they presume that reduced HW mode is functioning correctly. In the meantime, there's no way I can think of to test all possible scenarios so feedback would be greatly appreciated. [0] List at https://wiki.linaro.org/LEG/Engineering/Kernel/ACPI/AcpiReducedHw#Section_5… [1] Please see the ACPI Specification v5.0 for details on Hardware Reduced mode (sections 3.11.1, 4.1, 5.2.9, at a minimum). Changes for v6: -- Allow selection of CONFIG_ACPI_REDUCED_HARDWARE_ONLY to be more architecture-independent, but make it harder to accidentally enable. -- Make sure that ACPI ECs do not use the ACPI global lock when in hardware reduced mode (I had missed this case in earlier reviews of the kernel tree). Changes for v5: -- Clarify that if the kernel config option to build ACPI hardware reduced mode is used, it builds a hardware reduced *only* kernel (i.e., full legacy ACPI mode will no longer work). Changes for v4: -- Given the current state of ACPICA, disable CONFIG_ACPI_REDUCED_HARDWARE for use on anything other than ARM. -- Replaced #ifdefs with run-time checking for hardware reduced mode, whenever possible Changes for v3: -- Modified enabling ACPI_REDUCED_HARDWARE in ACPICA when using kernel config item CONFIG_ACPI_REDUCED_HARDWARE; now consistent with ACPICA code base where needed -- Enable X86 for CONFIG_ACPI_REDUCED_HARDWARE -- Minimize bus master reload patching -- Remove unneeded patch for dmi_check_system() (was 4/6) -- Correct the patch for removing unneeded map/unmap of FADT fields Changes for v2: -- Remove patch that was outside of reduced HW mode changes -- Simplify CONFIG_ACPI_REDUCED_HARDWARE in Kconfig -- Simplify use of CONFIG_ACPI_REDUCED_HARDWARE in #ifdefs -- Ensure changelogs are present -- Combine and simplify previous patches 8 & 10 Al Stone (6): ACPI: introduce CONFIG_ACPI_REDUCED_HARDWARE_ONLY to enforce this ACPI mode ACPI: bus master reload not supported in reduced HW mode ACPI: HW reduced mode does not allow use of the FADT sci_interrupt field ACPI: in HW reduced mode, using FADT PM information is not allowed. ACPI: do not map/unmap memory regions for FADT entries in reduced HW mode ACPI: make sure ECs do not use the ACPI global lock drivers/acpi/Kconfig | 12 ++++++++++++ drivers/acpi/bus.c | 30 ++++++++++++++++-------------- drivers/acpi/ec.c | 12 ++++++++++-- drivers/acpi/osl.c | 38 +++++++++++++++++++------------------- drivers/acpi/pci_link.c | 2 ++ drivers/acpi/processor_idle.c | 14 ++++++++++++-- include/acpi/platform/aclinux.h | 6 ++++++ 7 files changed, 77 insertions(+), 37 deletions(-) -- 1.8.4.2

10 years, 9 months

[PATCH v5 0/5] Hardware Reduced Mode Cleanup for ACPI

by al.stone＠linaro.org

From: Al Stone <al.stone(a)linaro.org> This series of patches starts with Hanjun's patch to create a kernel config item for CONFIG_ACPI_REDUCED_HARDWARE [0]. Building on that, I then reviewed all of the code that touched any of several fields in the FADT that the OSPM is supposed to ignore when ACPI is in Hardware Reduced mode [1]. Any time there was a use of one of the fields to be ignored, I evaluated whether or not the code was implementing Hardware Reduced mode correctly. Similarly, for each the flags in the FADT flags field that are to be ignored in Hardware Reduced mode, the kernel code was again scanned for proper usage. The remainder of the patches are to fix all of the situations I could find where the kernel would not behave correctly in this ACPI mode. These seem to work just fine on the RTSM model for ARMv7, both with and without ACPI enabled, and with and without ACPI_REDUCED_HARDWARE enabled; similarly for the FVP model for ARMv8. The patches for ACPI on ARM hardware have been submitted elsewhere but they presume that reduced HW mode is functioning correctly. In the meantime, there's no way I can think of to test all possible scenarios so feedback would be greatly appreciated. [0] List at https://wiki.linaro.org/LEG/Engineering/Kernel/ACPI/AcpiReducedHw#Section_5… [1] Please see the ACPI Specification v5.0 for details on Hardware Reduced mode (sections 3.11.1, 4.1, 5.2.9, at a minimum). Changes for v5: -- Clarify that if the kernel config option to build ACPI hardware reduced mode is used, it builds a hardware reduced *only* kernel (i.e., full legacy ACPI mode will no longer work). Changes for v4: -- Given the current state of ACPICA, disable CONFIG_ACPI_REDUCED_HARDWARE for use on anything other than ARM. -- Replaced #ifdefs with run-time checking for hardware reduced mode, whenever possible Changes for v3: -- Modified enabling ACPI_REDUCED_HARDWARE in ACPICA when using kernel config item CONFIG_ACPI_REDUCED_HARDWARE; now consistent with ACPICA code base where needed -- Enable X86 for CONFIG_ACPI_REDUCED_HARDWARE -- Minimize bus master reload patching -- Remove unneeded patch for dmi_check_system() (was 4/6) -- Correct the patch for removing unneeded map/unmap of FADT fields Changes for v2: -- Remove patch that was outside of reduced HW mode changes -- Simplify CONFIG_ACPI_REDUCED_HARDWARE in Kconfig -- Simplify use of CONFIG_ACPI_REDUCED_HARDWARE in #ifdefs -- Ensure changelogs are present -- Combine and simplify previous patches 8 & 10 Al Stone (5): ACPI: introduce CONFIG_ACPI_REDUCED_HARDWARE_ONLY to enforce this ACPI mode ACPI: bus master reload not supported in reduced HW mode ACPI: HW reduced mode does not allow use of the FADT sci_interrupt field ACPI: in HW reduced mode, using FADT PM information is not allowed. ACPI: do not map/unmap memory regions for FADT entries in reduced HW mode drivers/acpi/Kconfig | 12 ++++++++++++ drivers/acpi/bus.c | 30 ++++++++++++++++-------------- drivers/acpi/osl.c | 38 +++++++++++++++++++------------------- drivers/acpi/pci_link.c | 2 ++ drivers/acpi/processor_idle.c | 14 ++++++++++++-- include/acpi/platform/aclinux.h | 6 ++++++ 6 files changed, 67 insertions(+), 35 deletions(-) -- 1.8.4.2

10 years, 10 months

[PATCH 0/3] ASL adjustments for APEI test via GRUB

by Tomasz Nowicki

This patch set is needed due to: - APEI tables address adjustments - rebase to the kernel 3.13 - more descriptive error example Tomasz Nowicki (3): apei: Adjust addresses for APEI testing via UEFI -> GRUB -> ACPI kernel. acpi, apei: More detailed info regarding memory error. apei: Follow up lately kernel changes. platforms/rtsm_ve-aemv8a.acpi/bert.asl | 2 +- platforms/rtsm_ve-aemv8a.acpi/einj.asl | 16 ++++++++-------- platforms/rtsm_ve-aemv8a.acpi/erst.asl | 32 +++++++++++++++---------------- platforms/rtsm_ve-aemv8a.acpi/hest.asl | 2 +- tools/bfapei/bfapei.c | 20 ++++++++++++++++++- tools/common/include/acpi.h | 33 ++++++++++++++++++++++++++------ 6 files changed, 72 insertions(+), 33 deletions(-) -- 1.7.9.5

10 years, 10 months

[PATCH] APEI: Add 'apei'command for APEI blob loading into the specified address.

by Tomasz Nowicki

--- grub-core/loader/arm64/linux.c | 70 +++++++++++++++++++++++++++++++++++++++- 1 file changed, 69 insertions(+), 1 deletion(-) diff --git a/grub-core/loader/arm64/linux.c b/grub-core/loader/arm64/linux.c index 75ad871..17938ba 100644 --- a/grub-core/loader/arm64/linux.c +++ b/grub-core/loader/arm64/linux.c @@ -54,6 +54,8 @@ static grub_addr_t initrd_end; static void *loaded_fdt; static void *fdt; +static void *apei_data; + static void * get_firmware_fdt (void) { @@ -241,6 +243,69 @@ out: } static grub_err_t +grub_cmd_apei (grub_command_t cmd __attribute__ ((unused)), + int argc, char *argv[]) +{ + grub_efi_physical_address_t apei_phy_addr; + grub_efi_boot_services_t *b; + grub_efi_status_t status; + grub_file_t apei; + void *blob = NULL; + int size; + + if (!loaded) + { + grub_error (GRUB_ERR_BAD_ARGUMENT, + N_("you need to load the kernel first")); + return GRUB_ERR_BAD_OS; + } + + if (argc != 1) + return grub_error (GRUB_ERR_BAD_ARGUMENT, N_("filename expected")); + + apei = grub_file_open (argv[0]); + if (!apei) + goto out; + + size = grub_file_size (apei); + if (size == 0) + goto out; + + blob = grub_malloc (size); + if (!blob) + goto out; + + if (grub_file_read (apei, blob, size) < size) + { + if (!grub_errno) + grub_error (GRUB_ERR_BAD_OS, N_("premature end of file %s"), argv[0]); + goto out; + } + + grub_dprintf ("linux", "allocating %ld bytes for APEI blob\n", size); + apei_phy_addr = 0x80000000 + 0x2000000 - 0x200000; + apei_data = grub_efi_allocate_pages (apei_phy_addr, BYTES_TO_PAGES(size)); + if (!apei_data) { + grub_error (GRUB_ERR_OUT_OF_MEMORY, + N_("can not allocate at 0x%lx"), apei_phy_addr); + goto out; + } + + grub_memmove (apei_data, blob, size); + + grub_dprintf ("linux", "Installed APEI blob @ %p\n", apei_data); + +out: + if (apei) + grub_file_close (apei); + + if (blob) + grub_free (blob); + + return grub_errno; +} + +static grub_err_t grub_linux_boot (void) { grub_efi_memory_mapped_device_path_t *mempath; @@ -465,7 +530,7 @@ fail: } -static grub_command_t cmd_linux, cmd_initrd, cmd_devicetree; +static grub_command_t cmd_linux, cmd_initrd, cmd_devicetree, cmd_apei; GRUB_MOD_INIT (linux) { @@ -476,6 +541,9 @@ GRUB_MOD_INIT (linux) cmd_devicetree = grub_register_command ("devicetree", grub_cmd_devicetree, 0, N_("Load DTB file.")); + + cmd_apei = grub_register_command ("apei", grub_cmd_apei, 0, + N_("Load APEI blob.")); my_mod = mod; } -- 1.7.9.5

10 years, 10 months

[PATCH 0/1 v2] Support for flash device in physical memory map based on ACPI description

by Tomasz Nowicki

Changes for v2: - fix ID driver - use generic utility acpi_keyvalue to retrieve properties from _DSM Tomasz Nowicki (1): acpi, mtd: Add support for flash device in physical memory map based on ACPI description drivers/acpi/acpi_platform.c | 4 + drivers/mtd/maps/Kconfig | 9 + drivers/mtd/maps/Makefile | 1 + drivers/mtd/maps/physmap_acpi.c | 372 +++++++++++++++++++++++++++++++++++++++ 4 files changed, 386 insertions(+) create mode 100644 drivers/mtd/maps/physmap_acpi.c -- 1.7.9.5

10 years, 10 months

[PATCH] rtsm_ve-aemv8a: Add ASL for cf-flash memory

by Tomasz Nowicki

Added info: - memory resource ranges - DSM property, specific for cfi-flash memory Signed-off-by: Tomasz Nowicki <tomasz.nowicki(a)linaro.org> --- platforms/rtsm_ve-aemv8a.acpi/dsdt.asl | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/platforms/rtsm_ve-aemv8a.acpi/dsdt.asl b/platforms/rtsm_ve-aemv8a.acpi/dsdt.asl index 62f1402..43ac170 100644 --- a/platforms/rtsm_ve-aemv8a.acpi/dsdt.asl +++ b/platforms/rtsm_ve-aemv8a.acpi/dsdt.asl @@ -467,6 +467,29 @@ DefinitionBlock ( } } + Device (FLH0) { + Name (_HID, "LNRO0015") + Name (_UID, 0) + Method (_CRS, 0x0, Serialized) { + Name (RBUF, ResourceTemplate () { + Memory32Fixed (ReadWrite, 0x08000000, 0x04000000) + Memory32Fixed (ReadWrite, 0x0C000000, 0x04000000) + }) + Return (RBUF) + } + + Method(_DSM, 4, NotSerialized) { + Store (Package () + { + "bank-width", "4", + }, Local0) + + DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0)) + + Return (Local0) + } + } + Device (AMBA) { Name (_HID, "AMBA0000") Name (_UID, 0) -- 1.7.9.5

10 years, 10 months

[PATCH 0/3] make DSM lookup generic and add fixed regulator

by Graeme Gregory

I took the _DSM lookup code from Brandon and moved it to generic acpi drivers directory so it can be accessed from any driver. I then implemented a fixed-regulator in ACPI using the _DSM lookups for the regulator parameters. This is obviously all prototype stuff until upstream/UEFI guys make a decision on _DSM vs _PRP and also unified key/value fetching. ASL patch will follow. Graeme

10 years, 10 months

[PATCH 0/4] ACPI / ARM64: Whitelist rtc, kmi, wdt devices.

by naresh.bhat＠linaro.org

From: Naresh Bhat <naresh.bhat(a)linaro.org> Whitelist few more devices (rtc, kmi and wdt). Test log on FVP model as below root@genericarmv8:~# dmesg |grep -i wdt [ 80.051138] sp805-wdt LNRO0011:00: registration successful root@genericarmv8:~# dmesg |grep -i rtc [ 80.047447] rtc-pl031 LNRO0013:00: rtc core: registered pl031 as rtc0 [ 80.066564] rtc-pl031 LNRO0013:00: setting system clock to 1970-01-01 00:01:18 UTC (78) root@genericarmv8:~# root@genericarmv8:/sys# find . -name LNRO* ./bus/acpi/devices/LNRO0003:00 ./bus/acpi/devices/LNRO0005:00 ./bus/acpi/devices/LNRO0007:00 ./bus/acpi/devices/LNRO0008:00 ./bus/acpi/devices/LNRO0008:01 ./bus/acpi/devices/LNRO0008:02 ./bus/acpi/devices/LNRO0009:00 ./bus/acpi/devices/LNRO0011:00 ./bus/acpi/devices/LNRO0012:00 ./bus/acpi/devices/LNRO0012:01 ./bus/acpi/devices/LNRO0013:00 ./bus/acpi/devices/LNRO0014:00 ./bus/acpi/devices/LNRO000A:00 ./bus/acpi/devices/LNRO000A:01 ./bus/acpi/devices/LNRO000A:02 ./bus/acpi/devices/LNRO000A:03 ./bus/acpi/devices/LNRO000C:00 ./bus/acpi/devices/LNRO000D:00 ./bus/acpi/devices/LNRO000E:00 ./bus/acpi/devices/LNRO000F:00 ./bus/acpi/devices/LNRO000F:01 ./bus/amba/devices/LNRO0011:00 ./bus/amba/devices/LNRO0012:00 ./bus/amba/devices/LNRO0012:01 ./bus/amba/devices/LNRO0013:00 ./bus/amba/devices/LNRO0014:00 ./bus/amba/devices/LNRO000A:00 ./bus/amba/devices/LNRO000A:01 ./bus/amba/devices/LNRO000A:02 ./bus/amba/devices/LNRO000A:03 ./bus/amba/devices/LNRO000D:00 ./bus/amba/devices/LNRO000E:00 ./bus/amba/devices/LNRO000F:00 ./bus/amba/devices/LNRO000F:01 ./bus/amba/drivers/kmi-pl050/LNRO000F:00 ./bus/amba/drivers/kmi-pl050/LNRO000F:01 ./bus/amba/drivers/sp805-wdt/LNRO0011:00 ./bus/amba/drivers/rtc-pl031/LNRO0013:00 ./bus/amba/drivers/uart-pl011/LNRO000A:00 ./bus/amba/drivers/uart-pl011/LNRO000A:01 ./bus/amba/drivers/uart-pl011/LNRO000A:02 ./bus/amba/drivers/uart-pl011/LNRO000A:03 ./bus/platform/devices/LNRO0003:00 ./bus/platform/devices/LNRO0005:00 ./bus/platform/devices/LNRO0007:00 ./bus/platform/devices/LNRO0008:00 ./bus/platform/devices/LNRO0008:01 ./bus/platform/devices/LNRO0008:02 ./bus/platform/devices/LNRO0009:00 ./bus/platform/drivers/vexpress-sysreg/LNRO0009:00 ./bus/platform/drivers/smc91x/LNRO0003:00 ./bus/platform/drivers/fixed-clk/LNRO0008:00 ./bus/platform/drivers/fixed-clk/LNRO0008:01 ./bus/platform/drivers/fixed-clk/LNRO0008:02 ./bus/platform/drivers/arm-pmu/LNRO0007:00 ./bus/platform/drivers/virtio-mmio/LNRO0005:00 ./devices/platform/LNRO0003:00 ./devices/platform/LNRO0005:00 ./devices/platform/LNRO0007:00 ./devices/platform/LNRO0008:00 ./devices/platform/LNRO0008:01 ./devices/platform/LNRO0008:02 ./devices/platform/LNRO0009:00 ./devices/platform/AMBA0000:00/LNRO0011:00 ./devices/platform/AMBA0000:00/LNRO0012:00 ./devices/platform/AMBA0000:00/LNRO0012:01 ./devices/platform/AMBA0000:00/LNRO0013:00 ./devices/platform/AMBA0000:00/LNRO0014:00 ./devices/platform/AMBA0000:00/LNRO000A:00 ./devices/platform/AMBA0000:00/LNRO000A:01 ./devices/platform/AMBA0000:00/LNRO000A:02 ./devices/platform/AMBA0000:00/LNRO000A:03 ./devices/platform/AMBA0000:00/LNRO000D:00 ./devices/platform/AMBA0000:00/LNRO000E:00 ./devices/platform/AMBA0000:00/LNRO000F:00 ./devices/platform/AMBA0000:00/LNRO000F:01 ./devices/LNXSYSTM:00/device:00/LNRO0007:00 ./devices/LNXSYSTM:00/device:00/AMBA0000:00/LNRO0011:00 ./devices/LNXSYSTM:00/device:00/AMBA0000:00/LNRO0012:00 ./devices/LNXSYSTM:00/device:00/AMBA0000:00/LNRO0012:01 ./devices/LNXSYSTM:00/device:00/AMBA0000:00/LNRO0013:00 ./devices/LNXSYSTM:00/device:00/AMBA0000:00/LNRO0014:00 ./devices/LNXSYSTM:00/device:00/AMBA0000:00/LNRO000A:00 ./devices/LNXSYSTM:00/device:00/AMBA0000:00/LNRO000A:01 ./devices/LNXSYSTM:00/device:00/AMBA0000:00/LNRO000A:02 ./devices/LNXSYSTM:00/device:00/AMBA0000:00/LNRO000A:03 ./devices/LNXSYSTM:00/device:00/AMBA0000:00/LNRO000C:00 ./devices/LNXSYSTM:00/device:00/AMBA0000:00/LNRO000D:00 ./devices/LNXSYSTM:00/device:00/AMBA0000:00/LNRO000E:00 ./devices/LNXSYSTM:00/device:00/AMBA0000:00/LNRO000F:00 ./devices/LNXSYSTM:00/device:00/AMBA0000:00/LNRO000F:01 ./devices/LNXSYSTM:00/device:00/ACPI0004:01/LNRO0003:00 ./devices/LNXSYSTM:00/device:00/ACPI0004:01/LNRO0008:00 ./devices/LNXSYSTM:00/device:00/ACPI0004:01/LNRO0008:01 ./devices/LNXSYSTM:00/device:00/ACPI0004:01/LNRO0008:02 ./devices/LNXSYSTM:00/device:00/ACPI0004:01/ACPI0004:02/LNRO0005:00 ./devices/LNXSYSTM:00/device:00/ACPI0004:01/ACPI0004:02/LNRO0009:00 root@genericarmv8:/sys# Naresh Bhat (4): ACPI / ARM64: Whitelist the ACPI ID for wdt watchdog: Add sp805_wdt depends on ARM64 ACPI / ARM64: Whitelist the ACPI ID for kmi ACPI / ARM64: Whitelist the ACPI ID for rtc drivers/acpi/acpi_platform.c | 3 +++ drivers/watchdog/Kconfig | 2 +- 2 files changed, 4 insertions(+), 1 deletion(-) -- 1.7.9.5

10 years, 10 months

← Newer
1
...
53
54
55
56
57
58
59
...
82
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Linaro-acpi