Merge branch 'linus' into x86/entry, to resolve conflicts (2c92d787) · Commits · 戴 / test

Documentation/ABI/testing/dev-kmsg

+0 −5

Original line number	Diff line number	Diff line
		@@ -56,11 +56,6 @@ Description: The /dev/kmsg character device node provides userspace access
		seek after the last record available at the time
		the last SYSLOG_ACTION_CLEAR was issued.

		Due to the record nature of this interface with a "read all"
		behavior and the specific positions each seek operation sets,
		SEEK_CUR is not supported, returning -ESPIPE (invalid seek) to
		errno whenever requested.

		The output format consists of a prefix carrying the syslog
		prefix including priority and facility, the 64 bit message
		sequence number and the monotonic timestamp in microseconds,

0 → 100644

+27 −0

Original line number	Diff line number	Diff line
		What: /sys/bus/nd/devices/nmemX/papr/flags
		Date: Apr, 2020
		KernelVersion: v5.8
		Contact: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>, linux-nvdimm@lists.01.org,
		Description:
		(RO) Report flags indicating various states of a
		papr-pmem NVDIMM device. Each flag maps to a one or
		more bits set in the dimm-health-bitmap retrieved in
		response to H_SCM_HEALTH hcall. The details of the bit
		flags returned in response to this hcall is available
		at 'Documentation/powerpc/papr_hcalls.rst' . Below are
		the flags reported in this sysfs file:

		* "not_armed" : Indicates that NVDIMM contents will not
		survive a power cycle.
		* "flush_fail" : Indicates that NVDIMM contents
		couldn't be flushed during last
		shut-down event.
		* "restore_fail": Indicates that NVDIMM contents
		couldn't be restored during NVDIMM
		initialization.
		* "encrypted" : NVDIMM contents are encrypted.
		* "smart_notify": There is health event for the NVDIMM.
		* "scrubbed" : Indicating that contents of the
		NVDIMM have been scrubbed.
		* "locked" : Indicating that NVDIMM contents cant
		be modified until next power cycle.

+3 −3

Original line number	Diff line number	Diff line
		@@ -186,7 +186,7 @@ prctl(PR_SVE_SET_VL, unsigned long arg)

		flags:

		PR_SVE_SET_VL_INHERIT
		PR_SVE_VL_INHERIT

		Inherit the current vector length across execve(). Otherwise, the
		vector length is reset to the system default at execve(). (See
		@@ -247,7 +247,7 @@ prctl(PR_SVE_GET_VL)

		The following flag may be OR-ed into the result:

		PR_SVE_SET_VL_INHERIT
		PR_SVE_VL_INHERIT

		Vector length will be inherited across execve().

		@@ -393,7 +393,7 @@ The regset data starts with struct user_sve_header, containing:
		* At every execve() call, the new vector length of the new process is set to
		the system default vector length, unless

		* PR_SVE_SET_VL_INHERIT (or equivalently SVE_PT_VL_INHERIT) is set for the
		* PR_SVE_VL_INHERIT (or equivalently SVE_PT_VL_INHERIT) is set for the
		calling thread, or

		* a deferred vector length change is pending, established via the

+17 −9

Original line number	Diff line number	Diff line
		@@ -34,12 +34,15 @@ properties:
		maxItems: 1

		clocks:
		maxItems: 1
		minItems: 1
		maxItems: 2
		items:
		- description: controller register bus clock
		- description: baud rate generator and delay control clock

		clock-names:
		description: input clock for the baud rate generator
		items:
		- const: core
		minItems: 1
		maxItems: 2

		if:
		properties:
		@@ -51,17 +54,22 @@ if:
		then:
		properties:
		clocks:
		contains:
		items:
		- description: controller register bus clock
		- description: baud rate generator and delay control clock
		minItems: 2

		clock-names:
		minItems: 2
		items:
		- const: core
		- const: pclk

		else:
		properties:
		clocks:
		maxItems: 1

		clock-names:
		items:
		- const: core

		required:
		- compatible
		- reg

+1 −1

Original line number	Diff line number	Diff line
		@@ -451,7 +451,7 @@ The bridge driver also has some helper functions it can use:
		"module_foo", "chipid", 0x36, NULL);

		This loads the given module (can be ``NULL`` if no module needs to be loaded)
		and calls :c:func:`i2c_new_device` with the given ``i2c_adapter`` and
		and calls :c:func:`i2c_new_client_device` with the given ``i2c_adapter`` and
		chip/address arguments. If all goes well, then it registers the subdev with
		the v4l2_device.