1. 29 Sep, 2016 1 commit
  2. 30 Aug, 2016 1 commit
  3. 08 Jul, 2016 5 commits
  4. 18 Apr, 2016 1 commit
    • Lv Zheng's avatar
      ACPI / tables: Convert initrd table override to table upgrade mechanism · 5d881327
      Lv Zheng authored
      This patch converts the initrd table override mechanism to the table
      upgrade mechanism by restricting its usage to the tables released with
      compatibility and more recent revision.
      This use case has been encouraged by the ACPI specification:
       1. OEMID:
          An OEM-supplied string that identifies the OEM.
       2. OEM Table ID:
          An OEM-supplied string that the OEM uses to identify the particular data
          table. This field is particularly useful when defining a definition
          block to distinguish definition block functions. OEM assigns each
          dissimilar table a new OEM Table Id.
       3. OEM Revision:
          An OEM-supplied revision number. Larger numbers are assumed to be newer
      For OEMs, good practices will ensure consistency when assigning OEMID and
      OEM Table ID fields in any table. The intent of these fields is to allow
      for a binary control system that support services can use. Because many
      support function can be automated, it is useful when a tool can
      programatically determine which table release is a compatible and more
      recent revision of a prior table on the same OEMID and OEM Table ID.
      The facility can now be used by the vendors to upgrade wrong tables for bug
      fixing purpose, thus lockdep disabling taint is not suitable for it and it
      should be a default 'y' option to implement the spec encouraged use case.
      Note that, by implementing table upgrade inside of ACPICA itself, it is
      possible to remove acpi_table_initrd_override() and tables can be upgraded
      by acpi_install_table() automatically. Though current ACPICA impelentation
      hasn't implemented this, this patched changes the table flag setting timing
      to allow this to be implemented in ACPICA without changing the code here.
      Documentation of initrd override mechanism is upgraded accordingly.
      Original-by: default avatarOctavian Purdila <octavian.purdila@intel.com>
      Signed-off-by: default avatarLv Zheng <lv.zheng@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
  5. 26 Oct, 2015 1 commit
  6. 25 Oct, 2015 1 commit
    • Dustin Byford's avatar
      i2c: add ACPI support for I2C mux ports · 8eb5c87a
      Dustin Byford authored
      Although I2C mux devices are easily enumerated using ACPI (_HID/_CID or
      device property compatible string match), enumerating I2C client devices
      connected through an I2C mux needs a little extra work.
      This change implements a method for describing an I2C device hierarchy that
      includes mux devices by using an ACPI Device() for each mux channel along
      with an _ADR to set the channel number for the device.  See
      Documentation/acpi/i2c-muxes.txt for a simple example.
      To make this work the ismt, i801, and designware pci/platform devs now
      share an ACPI companion with their I2C adapter dev similar to how it's done
      in OF.  This is done on the assumption that power management functions will
      not be called directly on the I2C dev that is sharing the ACPI node.
      Acked-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Tested-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: default avatarDustin Byford <dustin@cumulusnetworks.com>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
  7. 23 Oct, 2015 1 commit
  8. 07 Aug, 2015 1 commit
  9. 18 Jun, 2015 2 commits
  10. 04 May, 2015 1 commit
  11. 30 Apr, 2015 1 commit
  12. 18 Mar, 2015 1 commit
  13. 19 Feb, 2015 1 commit
  14. 22 Jan, 2015 1 commit
  15. 04 Nov, 2014 2 commits
    • Rafael J. Wysocki's avatar
      ACPI / GPIO: Document ACPI GPIO mappings API · e36d453e
      Rafael J. Wysocki authored
      Document the previously introduced method that can be used by device
      drivers to provide the GPIO subsystem with mappings between GPIO names
      (connection IDs) and GpioIo()/GpioInt() resources in _CRS.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Reviewed-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
    • Mika Westerberg's avatar
      gpio / ACPI: Add support for _DSD device properties · 0d9a693c
      Mika Westerberg authored
      With release of ACPI 5.1 and _DSD method we can finally name GPIOs (and
      other things as well) returned by _CRS. Previously we were only able to
      use integer index to find the corresponding GPIO, which is pretty error
      prone if the order changes.
      With _DSD we can now query GPIOs using name instead of an integer index,
      like the below example shows:
        // Bluetooth device with reset and shutdown GPIOs
        Device (BTH)
            Name (_HID, ...)
            Name (_CRS, ResourceTemplate ()
                GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
                        "\\_SB.GPO0", 0, ResourceConsumer) {15}
                GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
                        "\\_SB.GPO0", 0, ResourceConsumer) {27, 31}
            Name (_DSD, Package ()
                Package ()
                    Package () {"reset-gpio", Package() {^BTH, 1, 1, 0 }},
                    Package () {"shutdown-gpio", Package() {^BTH, 0, 0, 0 }},
      The format of the supported GPIO property is:
        Package () { "name", Package () { ref, index, pin, active_low }}
        ref - The device that has _CRS containing GpioIo()/GpioInt() resources,
              typically this is the device itself (BTH in our case).
        index - Index of the GpioIo()/GpioInt() resource in _CRS starting from zero.
        pin - Pin in the GpioIo()/GpioInt() resource. Typically this is zero.
        active_low - If 1 the GPIO is marked as active_low.
      Since ACPI GpioIo() resource does not have field saying whether it is
      active low or high, the "active_low" argument can be used here. Setting
      it to 1 marks the GPIO as active low.
      In our Bluetooth example the "reset-gpio" refers to the second GpioIo()
      resource, second pin in that resource with the GPIO number of 31.
      This patch implements necessary support to gpiolib for extracting GPIOs
      using _DSD device properties.
      Signed-off-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Acked-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Acked-by: default avatarGrant Likely <grant.likely@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
  16. 26 Sep, 2014 1 commit
    • Mika Westerberg's avatar
      mfd: Add ACPI support · 6ab34301
      Mika Westerberg authored
      If an MFD device is backed by ACPI namespace, we should allow subdevice
      drivers to access their corresponding ACPI companion devices through normal
      means (e.g using ACPI_COMPANION()).
      This patch adds such support to the MFD core. If the MFD parent device
      does not specify any ACPI _HID/_CID for the child device, the child
      device will share the parent ACPI companion device. Otherwise the child
      device will be assigned with the corresponding ACPI companion, if found
      in the namespace below the parent.
      Signed-off-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Reviewed-by: default avatarDarren Hart <dvhart@linux.intel.com>
      Signed-off-by: default avatarLee Jones <lee.jones@linaro.org>
  17. 11 Jul, 2014 1 commit
  18. 23 May, 2014 1 commit
  19. 08 Jan, 2014 1 commit
  20. 18 Dec, 2013 1 commit
    • Luck, Tony's avatar
      ACPI, APEI, EINJ: Changes to the ACPI/APEI/EINJ debugfs interface · 3482fb5e
      Luck, Tony authored
      When I added support for ACPI5 I made the assumption that
      injected processor errors would just need to know the APICID,
      memory errors just the address and mask, and PCIe errors just the
      segment/bus/device/function. So I had the code check the type of injection
      and multiplex the "param1" value appropriately.
      This was not a good assumption :-(
      There are injection scenarios where we need to specify more than one of
      these items. E.g. injecting a cache error we need to specify an APICID
      of the cpu that owns the cache, and also an address (so that we can trip
      the error by accessing the address).
      Add a "flags" file to give the user direct access to specify which items
      are valid in the ACPI SET_ERROR_TYPE_WITH_ADDRESS structure. Also add
      new files param3 and param4 to hold all these values.
      For backwards compatability with old injection scripts we maintain the
      old behaviour if flags remains set at zero (or is reset to 0).
      Acked-by: default avatarNaveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
  21. 22 Nov, 2013 1 commit
    • Rafael J. Wysocki's avatar
      ACPI / scan: Add acpi_device objects for all device nodes in the namespace · 202317a5
      Rafael J. Wysocki authored
      Modify the ACPI namespace scanning code to register a struct
      acpi_device object for every namespace node representing a device,
      processor and so on, even if the device represented by that namespace
      node is reported to be not present and not functional by _STA.
      There are multiple reasons to do that.  First of all, it avoids
      quite a lot of overhead when struct acpi_device objects are
      deleted every time acpi_bus_trim() is run and then added again
      by a subsequent acpi_bus_scan() for the same scope, although the
      namespace objects they correspond to stay in memory all the time
      (which always is the case on a vast majority of systems).
      Second, it will allow user space to see that there are namespace
      nodes representing devices that are not present at the moment and may
      be added to the system.  It will also allow user space to evaluate
      _SUN for those nodes to check what physical slots the "missing"
      devices may be put into and it will make sense to add a sysfs
      attribute for _STA evaluation after this change (that will be
      useful for thermal management on some systems).
      Next, it will help to consolidate the ACPI hotplug handling among
      subsystems by making it possible to store hotplug-related information
      in struct acpi_device objects in a standard common way.
      Finally, it will help to avoid a race condition related to the
      deletion of ACPI namespace nodes.  Namely, namespace nodes may be
      deleted as a result of a table unload triggered by _EJ0 or _DCK.
      If a hotplug notification for one of those nodes is triggered
      right before the deletion and it executes a hotplug callback
      via acpi_hotplug_execute(), the ACPI handle passed to that
      callback may be stale when the callback actually runs.  One way
      to work around that is to always pass struct acpi_device pointers
      to hotplug callbacks after doing a get_device() on the objects in
      question which eliminates the use-after-free possibility (the ACPI
      handles in those objects are invalidated by acpi_scan_drop_device(),
      so they will trigger ACPICA errors on attempts to use them).
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Tested-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
  22. 19 Oct, 2013 1 commit
  23. 11 Oct, 2013 1 commit
  24. 23 Aug, 2013 2 commits
  25. 20 Aug, 2013 1 commit
  26. 20 Jun, 2013 3 commits
  27. 06 Jun, 2013 1 commit
  28. 15 Apr, 2013 1 commit
    • Andy Shevchenko's avatar
      dma: acpi-dma: introduce ACPI DMA helpers · 1b2e98bc
      Andy Shevchenko authored
      There is a new generic API to get a DMA channel for a slave device (commit
      9a6cecc8 "dmaengine: add helper function to request a slave DMA channel"). In
      similar fashion to the DT case (commit aa3da644 "of: Add generic device tree
      DMA helpers") we introduce helpers to the DMAC drivers which are enumerated by
      The proposed extension provides the following API calls:
      	acpi_dma_controller_register(), devm_acpi_dma_controller_register()
      	acpi_dma_controller_free(), devm_acpi_dma_controller_free()
      The first two should be used, for example, at probe() and remove() of the
      corresponding DMAC driver. At the register stage the DMAC driver supplies a
      custom xlate() function to translate a struct dma_spec into struct dma_chan.
      Accordingly to the ACPI Fixed DMA resource specification the only two pieces of
      information the slave device has are the channel id and the request line (slave
      id). Those two are represented by struct dma_spec. The
      acpi_dma_request_slave_chan_by_index() provides access to the specifix FixedDMA
      resource by its index. Whereas dma_request_slave_channel() takes a string
      parameter to identify the DMA resources required by the slave device. To make a
      slave device driver work with both DeviceTree and ACPI enumeration a simple
      convention is established: "tx" corresponds to the index 0 and "rx" to the
      index 1. In case of robust configuration the slave device driver unfortunately
      needs to call acpi_dma_request_slave_chan_by_index() directly.
      Additionally the patch provides "managed" version of the register/free pair
      i.e. devm_acpi_dma_controller_register() and devm_acpi_dma_controller_free().
      Usually, the driver uses only devm_acpi_dma_controller_register().
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Reviewed-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Acked-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
  29. 11 Apr, 2013 1 commit
  30. 13 Feb, 2013 1 commit
  31. 30 Jan, 2013 1 commit
    • Rafael J. Wysocki's avatar
      ACPI / scan: Introduce struct acpi_scan_handler · ca589f94
      Rafael J. Wysocki authored
      Introduce struct acpi_scan_handler for representing objects that
      will do configuration tasks depending on ACPI device nodes'
      hardware IDs (HIDs).
      Currently, those tasks are done either directly by the ACPI namespace
      scanning code or by ACPI device drivers designed specifically for
      this purpose.  None of the above is desirable, however, because
      doing that directly in the namespace scanning code makes that code
      overly complicated and difficult to follow and doing that in
      "special" device drivers leads to a great deal of confusion about
      their role and to confusing interactions with the driver core (for
      example, sysfs directories are created for those drivers, but they
      are completely unnecessary and only increase the kernel's memory
      footprint in vain).
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarYinghai Lu <yinghai@kernel.org>
      Acked-by: default avatarYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Acked-by: default avatarToshi Kani <toshi.kani@hp.com>