linux-stable.git/drivers/acpi/property.c, branch linux-5.2.y

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500

2019-06-19T15:09:55+00:00

Based on 2 normalized pattern(s):

  this program is free software you can redistribute it and or modify
  it under the terms of the gnu general public license version 2 as
  published by the free software foundation

  this program is free software you can redistribute it and or modify
  it under the terms of the gnu general public license version 2 as
  published by the free software foundation #

extracted by the scancode license scanner the SPDX license identifier

  GPL-2.0-only

has been chosen to replace the boilerplate/reference in 4122 file(s).

Signed-off-by: Thomas Gleixner 
Reviewed-by: Enrico Weigelt 
Reviewed-by: Kate Stewart 
Reviewed-by: Allison Randal 
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de
Signed-off-by: Greg Kroah-Hartman

ACPI / property: fix handling of data_nodes in acpi_get_next_subnode()

2019-05-01T08:06:08+00:00

When the DSDT tables expose devices with subdevices and a set of
hierarchical _DSD properties, the data returned by
acpi_get_next_subnode() is incorrect, with the results suggesting a bad
pointer assignment. The parser works fine with device_nodes or
data_nodes, but not with a combination of the two.

The problem is traced to an invalid pointer used when jumping from
handling device_nodes to data nodes. The existing code looks for data
nodes below the last subdevice found instead of the common root. Fix
by forcing the acpi_device pointer to be derived from the same fwnode
for the two types of subnodes.

This same problem of handling device and data nodes was already fixed
in a similar way by 'commit bf4703fdd166 ("ACPI / property: fix data
node parsing in acpi_get_next_subnode()")' but broken later by 'commit
34055190b19 ("ACPI / property: Add fwnode_get_next_child_node()")', so
this should probably go to linux-stable all the way to 4.12

Signed-off-by: Pierre-Louis Bossart 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Rafael J. Wysocki

ACPI: property: restore _DSD data subnodes GUID comment

2019-04-17T07:55:27+00:00

Commit 5f5e4890d57a ("ACPI / property: Allow multiple property
compatible _DSD entries") removed the comment of _DSD data subnodes
GUID.  Restore it.

Fixes: 5f5e4890d57a ("ACPI / property: Allow multiple property compatible _DSD entries")
Signed-off-by: Shunyong Yang 
Signed-off-by: Rafael J. Wysocki

PCI / ACPI: Identify untrusted PCI devices

2018-12-05T09:01:55+00:00

A malicious PCI device may use DMA to attack the system. An external
Thunderbolt port is a convenient point to attach such a device. The OS
may use IOMMU to defend against DMA attacks.

Some BIOSes mark these externally facing root ports with this
ACPI _DSD [1]:

  Name (_DSD, Package () {
      ToUUID ("efcc06cc-73ac-4bc3-bff0-76143807c389"),
      Package () {
          Package () {"ExternalFacingPort", 1},
	  Package () {"UID", 0 }
      }
  })

If we find such a root port, mark it and all its children as untrusted.
The rest of the OS may use this information to enable DMA protection
against malicious devices. For instance the device may be put behind an
IOMMU to keep it from accessing memory outside of what the driver has
allocated for it.

While at it, add a comment on top of prp_guids array explaining the
possible caveat resulting when these GUIDs are treated equivalent.

[1] https://docs.microsoft.com/en-us/windows-hardware/drivers/pci/dsd-for-pcie-root-ports#identifying-externally-exposed-pcie-root-ports

Signed-off-by: Mika Westerberg 
Acked-by: Rafael J. Wysocki 
Acked-by: Bjorn Helgaas

PCI / ACPI: Whitelist D3 for more PCIe hotplug ports

2018-10-02T21:04:40+00:00

In order to have better power management for Thunderbolt PCIe chains,
Windows enables power management for native PCIe hotplug ports if there is
the following ACPI _DSD attached to the root port:

  Name (_DSD, Package () {
      ToUUID ("6211e2c0-58a3-4af3-90e1-927a4e0c55a4"),
      Package () {
          Package () {"HotPlugSupportInD3", 1}
      }
  })

This is also documented in:

  https://docs.microsoft.com/en-us/windows-hardware/drivers/pci/dsd-for-pcie-root-ports#identifying-pcie-root-ports-supporting-hot-plug-in-d3

Do the same in Linux by introducing new firmware PM callback
(->bridge_d3()) and then implement it for ACPI based systems so that the
above property is checked.

There is one catch, though. The initial pci_dev->bridge_d3 is set before
the root port has ACPI companion bound (the device is not added to the PCI
bus either) so we need to look up the ACPI companion manually in that case
in acpi_pci_bridge_d3().

Signed-off-by: Mika Westerberg 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Rafael J. Wysocki

ACPI / property: Allow multiple property compatible _DSD entries

2018-10-02T21:04:40+00:00

It is possible to have _DSD entries where the data is compatible with
device properties format but are using different GUID for various reasons.
In addition to that there can be many such _DSD entries for a single device
such as for PCIe root port used to host a Thunderbolt hierarchy:

    Scope (\_SB.PCI0.RP21)
    {
        Name (_DSD, Package () {
            ToUUID ("6211e2c0-58a3-4af3-90e1-927a4e0c55a4"),
            Package () {
                Package () {"HotPlugSupportInD3", 1}
            },

            ToUUID ("efcc06cc-73ac-4bc3-bff0-76143807c389"),
            Package () {
                Package () {"ExternalFacingPort", 1},
                Package () {"UID", 0 }
            }
        })
    }

More information about these new _DSD entries can be found in:

  https://docs.microsoft.com/en-us/windows-hardware/drivers/pci/dsd-for-pcie-root-ports

To make these available for drivers via unified device property APIs,
modify ACPI property core so that it supports multiple _DSD entries
organized in a linked list. We also store GUID of each _DSD entry in struct
acpi_device_properties in case there is need to differentiate between
entries. The supported GUIDs are then listed in prp_guids array.

Signed-off-by: Mika Westerberg 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Rafael J. Wysocki 
Acked-by: Sakari Ailus

ACPI: property: Use data node name and reg property for graphs

2018-07-23T10:44:52+00:00

Instead of using the port and endpoint properties, rely on the names of
the port and endpoint nodes as well as the reg property, as on DT.

Signed-off-by: Sakari Ailus 
Signed-off-by: Rafael J. Wysocki

ACPI: property: Allow direct graph endpoint references

2018-07-23T10:44:52+00:00

By using device and further data node references, allow direct references
to endpoints. These are of form

	Package() { \DEV, "portX", "endpointY" }

where X is the number of the port and Y is the number of the endpoint.

Signed-off-by: Sakari Ailus 
Signed-off-by: Rafael J. Wysocki

ACPI: property: Make the ACPI graph API private

2018-07-23T10:44:52+00:00

The fwnode graph API is preferred over the ACPI graph API. Therefore
make the ACPI graph API private, and use it as a back-end for the
fwnode graph API only.

Unused functionality is removed while the functionality actually used
remains the same.

Signed-off-by: Sakari Ailus 
Signed-off-by: Rafael J. Wysocki

ACPI: property: Allow making references to non-device nodes

2018-07-23T10:44:52+00:00

Implement references to non-device nodes using the first package
entry in the hierarchical data extension reference, the second one
being the name of the referred object.

The data node references are parsed just after the device arguments
before the integer arguments. If there are no strings after the
device arguments, the parsing works exactly as it used to be.

Referring to a data node called "node" under device DEV, with
integer arguments 0, 2 would thus look like:

	Package() { DEV, "node", 0, 2 }

Signed-off-by: Sakari Ailus 
Signed-off-by: Rafael J. Wysocki