Merge branch 'linus' into x86/urgent, to pick up dependent commits (415812f2) · Commits · EulixOS / Software / Kernel

CREDITS

+8 −0

Original line number	Diff line number	Diff line
		@@ -1034,6 +1034,10 @@ S: 2037 Walnut #6
		S: Boulder, Colorado 80302
		S: USA

		N: Hans-Christian Noren Egtvedt
		E: egtvedt@samfundet.no
		D: AVR32 architecture maintainer.

		N: Heiko Eißfeldt
		E: heiko@colossus.escape.de heiko@unifix.de
		D: verify_area stuff, generic SCSI fixes
		@@ -3398,6 +3402,10 @@ S: Suite 101
		S: Markham, Ontario L3R 2Z6
		S: Canada

		N: Haavard Skinnemoen
		M: Haavard Skinnemoen <hskinnemoen@gmail.com>
		D: AVR32 architecture port to Linux and maintainer.

		N: Rick Sladkey
		E: jrs@world.std.com
		D: utility hacker: Emacs, NFS server, mount, kmem-ps, UPS debugger, strace, GDB

Documentation/ABI/obsolete/sysfs-firmware-acpi

0 → 100644

+8 −0

Original line number	Diff line number	Diff line
		What: /sys/firmware/acpi/hotplug/force_remove
		Date: Mar 2017
		Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
		Description:
		Since the force_remove is inherently broken and dangerous to
		use for some hotplugable resources like memory (because ignoring
		the offline failure might lead to memory corruption and crashes)
		enabling this knob is not safe and thus unsupported.

Documentation/ABI/testing/sysfs-block

+2 −8

Original line number	Diff line number	Diff line
		@@ -213,14 +213,8 @@ What: /sys/block/<disk>/queue/discard_zeroes_data
		Date: May 2011
		Contact: Martin K. Petersen <martin.petersen@oracle.com>
		Description:
		Devices that support discard functionality may return
		stale or random data when a previously discarded block
		is read back. This can cause problems if the filesystem
		expects discarded blocks to be explicitly cleared. If a
		device reports that it deterministically returns zeroes
		when a discarded area is read the discard_zeroes_data
		parameter will be set to one. Otherwise it will be 0 and
		the result of reading a discarded area is undefined.
		Will always return 0. Don't rely on any specific behavior
		for discards, and don't read this file.

		What: /sys/block/<disk>/queue/write_same_max_bytes
		Date: January 2012

Documentation/ABI/testing/sysfs-firmware-acpi

+0 −10

Original line number	Diff line number	Diff line
		@@ -44,16 +44,6 @@ Description:
		or 0 (unset). Attempts to write any other values to it will
		cause -EINVAL to be returned.

		What: /sys/firmware/acpi/hotplug/force_remove
		Date: May 2013
		Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
		Description:
		The number in this file (0 or 1) determines whether (1) or not
		(0) the ACPI subsystem will allow devices to be hot-removed even
		if they cannot be put offline gracefully (from the kernel's
		viewpoint). That number can be changed by writing a boolean
		value to this file.

		What: /sys/firmware/acpi/interrupts/
		Date: February 2008
		Contact: Len Brown <lenb@kernel.org>

Documentation/acpi/dsd/graph.txt

0 → 100644

+162 −0

Original line number	Diff line number	Diff line
		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 property extension related to
		each port node must contain the key "port" and an integer value which
		is the number of the port. The object it refers to should be called "PRTX",
		where "X" is the number of the port.

		Further on, endpoints are located under the individual port nodes. The
		first hierarchical data extension package list entry of the endpoint
		nodes must begin with "endpoint" and must be followed by 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.

		Each port node contains a property extension key "port", the value of
		which is the number of the port node. The each endpoint is similarly numbered
		with a property extension key "endpoint". Port numbers must be unique within a
		device and endpoint numbers must be unique within a port.

		The endpoint reference uses property extension with "remote-endpoint" property
		name followed by a reference in the same package. Such references consist of the
		the remote device reference, number of the port in the device and finally the
		number of the endpoint in that port. Individual references thus appear as:

		Package() { device, port_number, endpoint_number }

		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 () { "port0", "PRT0" },
		}
		})
		Name (PRT0, Package() {
		ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
		Package () {
		Package () { "port", 0 },
		},
		ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
		Package () {
		Package () { "endpoint0", "EP00" },
		}
		})
		Name (EP00, Package() {
		ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
		Package () {
		Package () { "endpoint", 0 },
		Package () { "remote-endpoint", Package() { \_SB.PCI0.ISP, 4, 0 } },
		}
		})
		}
		}

		Scope (\_SB.PCI0)
		{
		Device (ISP)
		{
		Name (_DSD, Package () {
		ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
		Package () {
		Package () { "port4", "PRT4" },
		}
		})

		Name (PRT4, Package() {
		ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
		Package () {
		Package () { "port", 4 }, /* CSI-2 port number */
		},
		ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
		Package () {
		Package () { "endpoint0", "EP40" },
		}
		})

		Name (EP40, Package() {
		ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
		Package () {
		Package () { "endpoint", 0 },
		Package () { "remote-endpoint", Package () { \_SB.PCI0.I2C2.CAM0, 0, 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.
		<URL:http://www.uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel-1_1.htm>,
		referenced 2016-10-03.

		[2] Devicetree. <URL:http://www.devicetree.org>, referenced 2016-10-03.

		[3] Documentation/devicetree/bindings/graph.txt

		[4] Device Properties UUID For _DSD.
		<URL:http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf>,
		referenced 2016-10-04.

		[5] Hierarchical Data Extension UUID For _DSD.
		<URL:http://www.uefi.org/sites/default/files/resources/_DSD-hierarchical-data-extension-UUID-v1.pdf>,
		referenced 2016-10-04.

		[6] Advanced Configuration and Power Interface Specification.
		<URL:http://www.uefi.org/sites/default/files/resources/ACPI_6_1.pdf>,
		referenced 2016-10-04.

		[7] _DSD Device Properties Usage Rules.
		Documentation/acpi/DSD-properties-rules.txt