mirror of
https://github.com/AuxXxilium/linux_dsm_epyc7002.git
synced 2024-12-23 15:15:59 +07:00
4ce7796632
Rationale: Reduces attack surface on kernel devs opening the links for MITM as HTTPS traffic is much harder to manipulate. Deterministic algorithm: For each file: If not .svg: For each line: If doesn't contain `\bxmlns\b`: For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`: If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`: If both the HTTP and HTTPS versions return 200 OK and serve the same content: Replace HTTP with HTTPS. Signed-off-by: Alexander A. Klimov <grandmaster@al2klimov.de> Acked-by: Vishal Verma <vishal.l.verma@intel.com> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
178 lines
6.0 KiB
ReStructuredText
178 lines
6.0 KiB
ReStructuredText
.. SPDX-License-Identifier: GPL-2.0
|
||
|
||
======
|
||
Graphs
|
||
======
|
||
|
||
_DSD
|
||
====
|
||
|
||
_DSD (Device Specific Data) [7] is a predefined ACPI device
|
||
configuration object that can be used to convey information on
|
||
hardware features which are not specifically covered by the ACPI
|
||
specification [1][6]. There are two _DSD extensions that are relevant
|
||
for graphs: property [4] and hierarchical data extensions [5]. The
|
||
property extension provides generic key-value pairs whereas the
|
||
hierarchical data extension supports nodes with references to other
|
||
nodes, forming a tree. The nodes in the tree may contain properties as
|
||
defined by the property extension. The two extensions together provide
|
||
a tree-like structure with zero or more properties (key-value pairs)
|
||
in each node of the tree.
|
||
|
||
The data structure may be accessed at runtime by using the device_*
|
||
and fwnode_* functions defined in include/linux/fwnode.h .
|
||
|
||
Fwnode represents a generic firmware node object. It is independent on
|
||
the firmware type. In ACPI, fwnodes are _DSD hierarchical data
|
||
extensions objects. A device's _DSD object is represented by an
|
||
fwnode.
|
||
|
||
The data structure may be referenced to elsewhere in the ACPI tables
|
||
by using a hard reference to the device itself and an index to the
|
||
hierarchical data extension array on each depth.
|
||
|
||
|
||
Ports and endpoints
|
||
===================
|
||
|
||
The port and endpoint concepts are very similar to those in Devicetree
|
||
[3]. A port represents an interface in a device, and an endpoint
|
||
represents a connection to that interface.
|
||
|
||
All port nodes are located under the device's "_DSD" node in the hierarchical
|
||
data extension tree. The data extension related to each port node must begin
|
||
with "port" and must be followed by the "@" character and the number of the
|
||
port as its key. The target object it refers to should be called "PRTX", where
|
||
"X" is the number of the port. An example of such a package would be::
|
||
|
||
Package() { "port@4", "PRT4" }
|
||
|
||
Further on, endpoints are located under the port nodes. The hierarchical
|
||
data extension key of the endpoint nodes must begin with
|
||
"endpoint" and must be followed by the "@" character and the number of the
|
||
endpoint. The object it refers to should be called "EPXY", where "X" is the
|
||
number of the port and "Y" is the number of the endpoint. An example of such a
|
||
package would be::
|
||
|
||
Package() { "endpoint@0", "EP40" }
|
||
|
||
Each port node contains a property extension key "port", the value of which is
|
||
the number of the port. Each endpoint is similarly numbered with a property
|
||
extension key "reg", the value of which is the number of the endpoint. Port
|
||
numbers must be unique within a device and endpoint numbers must be unique
|
||
within a port. If a device object may only has a single port, then the number
|
||
of that port shall be zero. Similarly, if a port may only have a single
|
||
endpoint, the number of that endpoint shall be zero.
|
||
|
||
The endpoint reference uses property extension with "remote-endpoint" property
|
||
name followed by a reference in the same package. Such references consist of
|
||
the remote device reference, the first package entry of the port data extension
|
||
reference under the device and finally the first package entry of the endpoint
|
||
data extension reference under the port. Individual references thus appear as::
|
||
|
||
Package() { device, "port@X", "endpoint@Y" }
|
||
|
||
In the above example, "X" is the number of the port and "Y" is the number of
|
||
the endpoint.
|
||
|
||
The references to endpoints must be always done both ways, to the
|
||
remote endpoint and back from the referred remote endpoint node.
|
||
|
||
A simple example of this is show below::
|
||
|
||
Scope (\_SB.PCI0.I2C2)
|
||
{
|
||
Device (CAM0)
|
||
{
|
||
Name (_DSD, Package () {
|
||
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
|
||
Package () {
|
||
Package () { "compatible", Package () { "nokia,smia" } },
|
||
},
|
||
ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
|
||
Package () {
|
||
Package () { "port@0", "PRT0" },
|
||
}
|
||
})
|
||
Name (PRT0, Package() {
|
||
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
|
||
Package () {
|
||
Package () { "reg", 0 },
|
||
},
|
||
ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
|
||
Package () {
|
||
Package () { "endpoint@0", "EP00" },
|
||
}
|
||
})
|
||
Name (EP00, Package() {
|
||
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
|
||
Package () {
|
||
Package () { "reg", 0 },
|
||
Package () { "remote-endpoint", Package() { \_SB.PCI0.ISP, "port@4", "endpoint@0" } },
|
||
}
|
||
})
|
||
}
|
||
}
|
||
|
||
Scope (\_SB.PCI0)
|
||
{
|
||
Device (ISP)
|
||
{
|
||
Name (_DSD, Package () {
|
||
ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
|
||
Package () {
|
||
Package () { "port@4", "PRT4" },
|
||
}
|
||
})
|
||
|
||
Name (PRT4, Package() {
|
||
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
|
||
Package () {
|
||
Package () { "reg", 4 }, /* CSI-2 port number */
|
||
},
|
||
ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
|
||
Package () {
|
||
Package () { "endpoint@0", "EP40" },
|
||
}
|
||
})
|
||
|
||
Name (EP40, Package() {
|
||
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
|
||
Package () {
|
||
Package () { "reg", 0 },
|
||
Package () { "remote-endpoint", Package () { \_SB.PCI0.I2C2.CAM0, "port@0", "endpoint@0" } },
|
||
}
|
||
})
|
||
}
|
||
}
|
||
|
||
Here, the port 0 of the "CAM0" device is connected to the port 4 of
|
||
the "ISP" device and vice versa.
|
||
|
||
|
||
References
|
||
==========
|
||
|
||
[1] _DSD (Device Specific Data) Implementation Guide.
|
||
https://www.uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel-1_1.htm,
|
||
referenced 2016-10-03.
|
||
|
||
[2] Devicetree. https://www.devicetree.org, referenced 2016-10-03.
|
||
|
||
[3] Documentation/devicetree/bindings/graph.txt
|
||
|
||
[4] Device Properties UUID For _DSD.
|
||
https://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf,
|
||
referenced 2016-10-04.
|
||
|
||
[5] Hierarchical Data Extension UUID For _DSD.
|
||
https://www.uefi.org/sites/default/files/resources/_DSD-hierarchical-data-extension-UUID-v1.1.pdf,
|
||
referenced 2016-10-04.
|
||
|
||
[6] Advanced Configuration and Power Interface Specification.
|
||
https://www.uefi.org/sites/default/files/resources/ACPI_6_1.pdf,
|
||
referenced 2016-10-04.
|
||
|
||
[7] _DSD Device Properties Usage Rules.
|
||
:doc:`../DSD-properties-rules`
|