Quelle  sysfs-firmware-acpi   Sprache: C

What:  /sys/firmware/acpi/fpdt/
Date:  Jan 2021
Contact: Zhang Rui <rui.zhang@intel.com>
Description:
  ACPI Firmware Performance Data Table (FPDT) provides
  information for firmware performance data for system boot,
  S3 suspend and S3 resume. This sysfs entry contains the
  performance data retrieved from the FPDT.

  boot:
   firmware_start_ns: Timer value logged at the beginning
    of firmware image execution. In nanoseconds.
   bootloader_load_ns: Timer value logged just prior to
    loading the OS boot loader into memory.
    In nanoseconds.
   bootloader_launch_ns: Timer value logged just prior to
    launching the currently loaded OS boot loader
    image. In nanoseconds.
   exitbootservice_start_ns: Timer value logged at the
    point when the OS loader calls the
    ExitBootServices function for UEFI compatible
    firmware. In nanoseconds.
   exitbootservice_end_ns: Timer value logged at the point
    just prior to the OS loader gaining control
    back from the ExitBootServices function for
    UEFI compatible firmware. In nanoseconds.
  suspend:
   suspend_start_ns: Timer value recorded at the previous
    OS write to SLP_TYP upon entry to S3. In
    nanoseconds.
   suspend_end_ns: Timer value recorded at the previous
    firmware write to SLP_TYP used to trigger
    hardware entry to S3. In nanoseconds.
  resume:
   resume_count: A count of the number of S3 resume cycles
    since the last full boot sequence.
   resume_avg_ns: Average timer value of all resume cycles
    logged since the last full boot sequence,
    including the most recent resume. In nanoseconds.
   resume_prev_ns: Timer recorded at the end of the previous
    platform runtime firmware S3 resume, just prior to
    handoff to the OS waking vector. In nanoseconds.

What:  /sys/firmware/acpi/bgrt/
Date:  January 2012
Contact: Matthew Garrett <mjg@redhat.com>
Description:
  The BGRT is an ACPI 5.0 feature that allows the OS
  to obtain a copy of the firmware boot splash and
  some associated metadata. This is intended to be used
  by boot splash applications in order to interact with
  the firmware boot splash in order to avoid jarring
  transitions.

  image: The image bitmap. Currently a 32-bit BMP.
  status: 1 if the image is valid, 0 if firmware invalidated it.
  type: 0 indicates image is in BMP format.

  ======== ===================================================
  version: The version of the BGRT. Currently 1.
  xoffset: The number of pixels between the left of the screen
    and the left edge of the image.
  yoffset: The number of pixels between the top of the screen
    and the top edge of the image.
  ======== ===================================================

What:  /sys/firmware/acpi/hotplug/
Date:  February 2013
Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Description:
  There are separate hotplug profiles for different classes of
  devices supported by ACPI, such as containers, memory modules,
  processors, PCI root bridges etc.  A hotplug profile for a given
  class of devices is a collection of settings defining the way
  that class of devices will be handled by the ACPI core hotplug
  code.  Those profiles are represented in sysfs as subdirectories
  of /sys/firmware/acpi/hotplug/.

  The following setting is available to user space for each
  hotplug profile:

  ======== =======================================================
  enabled: If set, the ACPI core will handle notifications of
    hotplug events associated with the given class of
    devices and will allow those devices to be ejected with
    the help of the _EJ0 control method.  Unsetting it
    effectively disables hotplug for the corresponding
    class of devices.
  ======== =======================================================

  The value of the above attribute is an integer number: 1 (set)
  or 0 (unset).  Attempts to write any other values to it will
  cause -EINVAL to be returned.

What:  /sys/firmware/acpi/interrupts/
Date:  February 2008
Contact: Len Brown <lenb@kernel.org>
Description:
  All ACPI interrupts are handled via a single IRQ,
  the System Control Interrupt (SCI), which appears
  as "acpi" in /proc/interrupts.

  However, one of the main functions of ACPI is to make
  the platform understand random hardware without
  special driver support.  So while the SCI handles a few
  well known (fixed feature) interrupts sources, such
  as the power button, it can also handle a variable
  number of a "General Purpose Events" (GPE).

  A GPE vectors to a specified handler in AML, which
  can do anything the BIOS writer wants from
  OS context.  GPE 0x12, for example, would vector
  to a level or edge handler called _L12 or _E12.
  The handler may do its business and return.
  Or the handler may send a Notify event
  to a Linux device driver registered on an ACPI device,
  such as a battery, or a processor.

  To figure out where all the SCIs are coming from,
  /sys/firmware/acpi/interrupts contains a file listing
  every possible source, and the count of how many
  times it has triggered::

    $ cd /sys/firmware/acpi/interrupts
    $ grep . *
    error:      0
    ff_gbl_lock:      0   enable
    ff_pmtimer:      0  invalid
    ff_pwr_btn:      0   enable
    ff_rt_clk:      2  disable
    ff_slp_btn:      0  invalid
    gpe00:      0 invalid
    gpe01:      0  enable
    gpe02:    108  enable
    gpe03:      0 invalid
    gpe04:      0 invalid
    gpe05:      0 invalid
    gpe06:      0  enable
    gpe07:      0  enable
    gpe08:      0 invalid
    gpe09:      0 invalid
    gpe0A:      0 invalid
    gpe0B:      0 invalid
    gpe0C:      0 invalid
    gpe0D:      0 invalid
    gpe0E:      0 invalid
    gpe0F:      0 invalid
    gpe10:      0 invalid
    gpe11:      0 invalid
    gpe12:      0 invalid
    gpe13:      0 invalid
    gpe14:      0 invalid
    gpe15:      0 invalid
    gpe16:      0 invalid
    gpe17:   1084  enable
    gpe18:      0  enable
    gpe19:      0 invalid
    gpe1A:      0 invalid
    gpe1B:      0 invalid
    gpe1C:      0 invalid
    gpe1D:      0 invalid
    gpe1E:      0 invalid
    gpe1F:      0 invalid
    gpe_all:   1192
    sci:    1194
    sci_not:      0

  ===========  ==================================================
  sci      The number of times the ACPI SCI
        has been called and claimed an interrupt.

  sci_not      The number of times the ACPI SCI
        has been called and NOT claimed an interrupt.

  gpe_all      count of SCI caused by GPEs.

  gpeXX      count for individual GPE source

  ff_gbl_lock  Global Lock

  ff_pmtimer   PM Timer

  ff_pwr_btn   Power Button

  ff_rt_clk    Real Time Clock

  ff_slp_btn   Sleep Button

  error      an interrupt that can't be accounted for above.

  invalid      it's either a GPE or a Fixed Event that
        doesn't have an event handler.

  disable      the GPE/Fixed Event is valid but disabled.

  enable       the GPE/Fixed Event is valid and enabled.
  ===========  ==================================================

  Root has permission to clear any of these counters.  Eg.::

    # echo 0 > gpe11

  All counters can be cleared by clearing the total "sci"::

    # echo 0 > sci

  None of these counters has an effect on the function
  of the system, they are simply statistics.

  Besides this, user can also write specific strings to these files
  to enable/disable/clear ACPI interrupts in user space, which can be
  used to debug some ACPI interrupt storm issues.

  Note that only writing to VALID GPE/Fixed Event is allowed,
  i.e. user can only change the status of runtime GPE and
  Fixed Event with event handler installed.

  Let's take power button fixed event for example, please kill acpid
  and other user space applications so that the machine won't shutdown
  when pressing the power button::

    # cat ff_pwr_btn
    0 enabled
    # press the power button for 3 times;
    # cat ff_pwr_btn
    3 enabled
    # echo disable > ff_pwr_btn
    # cat ff_pwr_btn
    3 disabled
    # press the power button for 3 times;
    # cat ff_pwr_btn
    3 disabled
    # echo enable > ff_pwr_btn
    # cat ff_pwr_btn
    4 enabled
    /*
     * this is because the status bit is set even if the enable
     * bit is cleared, and it triggers an ACPI fixed event when
     * the enable bit is set again
     */
    # press the power button for 3 times;
    # cat ff_pwr_btn
    7 enabled
    # echo disable > ff_pwr_btn
    # press the power button for 3 times;
    # echo clear > ff_pwr_btn /* clear the status bit */
    # echo disable > ff_pwr_btn
    # cat ff_pwr_btn
    7 enabled

What:  /sys/firmware/acpi/memory_ranges/rangeX
Date:  February 2025
Contact: Tony Luck <tony.luck@intel.com>
Description:
  On systems with the ACPI MRRM table reports the parameters for
  each range.

  base: Starting system physical address.

  length: Length of this range in bytes.

  node: NUMA node that this range belongs to. Negative numbers
  indicate that the node number could not be determined (e.g
  for an address range that is reserved for future hot add of
  memory).

  local_region_id: ID associated with access by agents
  local to this range of addresses.

  remote_region_id: ID associated with access by agents
  non-local to this range of addresses.