kernel.git/drivers/acpi/property.c, branch linux-5.1.y

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

2019-05-31T13:43:18Z

[ Upstream commit 23583f7795025e3c783b680d906509366b0906ad ] 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 Signed-off-by: Sasha Levin

PCI / ACPI: Identify untrusted PCI devices

2018-12-05T09:01:55Z

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:40Z

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:40Z

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:52Z

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:52Z

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:52Z

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:52Z

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

ACPI: Convert ACPI reference args to generic fwnode reference args

2018-07-23T10:44:52Z

Convert all users of struct acpi_reference_args to more generic fwnode_reference_args. This will 1) avoid an ACPI specific references to device nodes with integer arguments as well as 2) allow making references to nodes other than device nodes in ACPI. As a by-product, convert the fwnode interger arguments to u64. The arguments were 64-bit integers on ACPI but the fwnode arguments were just 32-bit. Signed-off-by: Sakari Ailus Signed-off-by: Rafael J. Wysocki

device property: Constify device_get_match_data()

2018-02-12T09:41:11Z

Constify device_get_match_data() as OF and ACPI variants return constant value. Acked-by: Sakari Ailus Signed-off-by: Andy Shevchenko Reviewed-by: Mika Westerberg Signed-off-by: Rafael J. Wysocki