1. 13 Oct, 2015 1 commit
  2. 14 Sep, 2015 1 commit
    • Rafael J. Wysocki's avatar
      ACPI / property: Add support for data-only subnodes · 445b0eb0
      Rafael J. Wysocki authored
      In some cases, the information expressed via device properties is
      hierarchical by nature.  For example, the properties of a composite
      device consisting of multiple semi-dependent components may need
      to be represented in the form of a tree of property data sets
      corresponding to specific components of the device.
      
      Unfortunately, using ACPI device objects for this purpose turns out
      to be problematic, mostly due to the assumption made by some operating
      systems (that platform firmware generally needs to work with) that
      each device object in the ACPI namespace represents a device requiring
      a separate driver.  That assumption leads to complications which
      reportedly are impractically difficult to overcome and a different
      approach is needed for the sake of interoperability.
      
      The approach implemented here is based on extending _DSD via pointers
      (links) to additional ACPI objects returning data packages formatted
      in accordance with the _DSD formatting rules defined by Section 6.2.5
      of ACPI 6.  Those additional objects are referred to as data-only
      subnodes of the device object containing the _DSD pointing to them.
      
      The links to them need to be located in a separate section of the
      _DSD data package following UUID dbb8e3e6-5886-4ba6-8795-1319f52a966b
      referred to as the Hierarchical Data Extension UUID as defined in [1].
      Each of them is represented by a package of two strings.  The first
      string in that package (the key) is regarded as the name of the
      data-only subnode pointed to by the link.  The second string in it
      (the target) is expected to hold the ACPI namespace path (possibly
      utilizing the usual ACPI namespace search rules) of an ACPI object
      evaluating to a data package extending the _DSD.
      
      The device properties initialization code follows those links,
      creates a struct acpi_data_node object for each of them to store
      the data returned by the ACPI object pointed to by it and processes
      those data recursively (which may lead to the creation of more
      struct acpi_data_node objects if the returned data package contains
      the Hierarchical Data Extension UUID section with more links in it).
      
      All of the struct acpi_data_node objects are present until the the
      ACPI device object containing the _DSD with links to them is deleted
      and they are deleted along with that object.
      
      [1]: http://www.uefi.org/sites/default/files/resources/_DSD-hierarchical-data-extension-UUID-v1.pdfSigned-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Tested-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      445b0eb0
  3. 03 Apr, 2015 2 commits
    • Rafael J. Wysocki's avatar
      device property: Introduce firmware node type for platform data · 16ba08d5
      Rafael J. Wysocki authored
      Introduce data structures and code allowing "built-in" properties
      to be associated with devices in such a way that they will be used
      by the device_property_* API if no proper firmware node (neither DT
      nor ACPI) is present for the given device.
      
      Each property is to be represented by a property_entry structure.
      An array of property_entry structures (terminated with a null
      entry) can be pointed to by the properties field of struct
      property_set that can be added as a firmware node to a struct
      device using device_add_property_set().  That will cause the
      device_property_* API to use that property_set as the source
      of properties if the given device does not have a DT node or
      an ACPI companion device object associated with it.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Tested-by: default avatarHeikki Krogerus <heikki.krogerus@linux.intel.com>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      16ba08d5
    • Rafael J. Wysocki's avatar
      device property: Make it possible to use secondary firmware nodes · 97badf87
      Rafael J. Wysocki authored
      Add a secondary pointer to struct fwnode_handle so as to make it
      possible for a device to have two firmware nodes associated with
      it at the same time, for example, an ACPI node and a node with
      a set of properties provided by platform initialization code.
      
      In the future that will allow device property lookup to fall back
      from the primary firmware node to the secondary one if the given
      property is not present there to make it easier to provide defaults
      for device properties used by device drivers.
      
      Introduce two helper routines, set_primary_fwnode() and
      set_secondary_fwnode() allowing callers to add a primary/secondary
      firmware node to the given device in such a way that
      
       (1) If there's only one firmware node for that device, it will be
           pointed to by the device's firmware node pointer.
       (2) If both the primary and secondary firmware nodes are present,
           the primary one will be pointed to by the device's firmware
           node pointer, while the secondary one will be pointed to by the
           primary node's secondary pointer.
       (3) If one of these nodes is removed (by calling one of the new
           nelpers with NULL as the second argument), the other one will
           be preserved.
      
      Make ACPI use set_primary_fwnode() for attaching its firmware nodes
      to devices.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Tested-by: default avatarHeikki Krogerus <heikki.krogerus@linux.intel.com>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      97badf87
  4. 16 Mar, 2015 1 commit