Merge tag 'v4.6' into patchwork (4ddd4fd4) · Commits · 戴 / test

Documentation/devicetree/bindings/regmap/regmap.txt

+19 −40

Original line number	Diff line number	Diff line
		Device-Tree binding for regmap

		The endianness mode of CPU & Device scenarios:
		Index Device Endianness properties
		---------------------------------------------------
		1 BE 'big-endian'
		2 LE 'little-endian'
		3 Native 'native-endian'

		For one device driver, which will run in different scenarios above
		on different SoCs using the devicetree, we need one way to simplify
		this.
		Devicetree binding for regmap

		Optional properties:
		- {big,little,native}-endian: these are boolean properties, if absent
		then the implementation will choose a default based on the device
		being controlled. These properties are for register values and all
		the buffers only. Native endian means that the CPU and device have
		the same endianness.

		Examples:
		Scenario 1 : CPU in LE mode & device in LE mode.
		dev: dev@40031000 {
		compatible = "name";
		reg = <0x40031000 0x1000>;
		...
		};
		little-endian,
		big-endian,
		native-endian: See common-properties.txt for a definition

		Scenario 2 : CPU in LE mode & device in BE mode.
		dev: dev@40031000 {
		compatible = "name";
		reg = <0x40031000 0x1000>;
		...
		big-endian;
		};
		Note:
		Regmap defaults to little-endian register access on MMIO based
		devices, this is by far the most common setting. On CPU
		architectures that typically run big-endian operating systems
		(e.g. PowerPC), registers can be defined as big-endian and must
		be marked that way in the devicetree.

		Scenario 3 : CPU in BE mode & device in BE mode.
		dev: dev@40031000 {
		compatible = "name";
		reg = <0x40031000 0x1000>;
		...
		};
		On SoCs that can be operated in both big-endian and little-endian
		modes, with a single hardware switch controlling both the endianess
		of the CPU and a byteswap for MMIO registers (e.g. many Broadcom MIPS
		chips), "native-endian" is used to allow using the same device tree
		blob in both cases.

		Scenario 4 : CPU in BE mode & device in LE mode.
		Examples:
		Scenario 1 : a register set in big-endian mode.
		dev: dev@40031000 {
		compatible = "name";
		compatible = "syscon";
		reg = <0x40031000 0x1000>;
		big-endian;
		...
		little-endian;
		};

Documentation/networking/checksum-offloads.txt

+7 −7

Original line number	Diff line number	Diff line
		@@ -69,18 +69,18 @@ LCO: Local Checksum Offload
		LCO is a technique for efficiently computing the outer checksum of an
		encapsulated datagram when the inner checksum is due to be offloaded.
		The ones-complement sum of a correctly checksummed TCP or UDP packet is
		equal to the sum of the pseudo header, because everything else gets
		'cancelled out' by the checksum field. This is because the sum was
		equal to the complement of the sum of the pseudo header, because everything
		else gets 'cancelled out' by the checksum field. This is because the sum was
		complemented before being written to the checksum field.
		More generally, this holds in any case where the 'IP-style' ones complement
		checksum is used, and thus any checksum that TX Checksum Offload supports.
		That is, if we have set up TX Checksum Offload with a start/offset pair, we
		know that _after the device has filled in that checksum_, the ones
		know that after the device has filled in that checksum, the ones
		complement sum from csum_start to the end of the packet will be equal to
		_whatever value we put in the checksum field beforehand_. This allows us
		to compute the outer checksum without looking at the payload: we simply
		stop summing when we get to csum_start, then add the 16-bit word at
		(csum_start + csum_offset).
		the complement of whatever value we put in the checksum field beforehand.
		This allows us to compute the outer checksum without looking at the payload:
		we simply stop summing when we get to csum_start, then add the complement of
		the 16-bit word at (csum_start + csum_offset).
		Then, when the true inner checksum is filled in (either by hardware or by
		skb_checksum_help()), the outer checksum will become correct by virtue of
		the arithmetic.

Documentation/sysctl/kernel.txt

+1 −1

Original line number	Diff line number	Diff line
		@@ -645,7 +645,7 @@ allowed to execute.
		perf_event_paranoid:

		Controls use of the performance events system by unprivileged
		users (without CAP_SYS_ADMIN). The default value is 1.
		users (without CAP_SYS_ADMIN). The default value is 2.

		-1: Allow use of (almost) all events by all users
		>=0: Disallow raw tracepoint access by users without CAP_IOC_LOCK

MAINTAINERS

+14 −0

Original line number	Diff line number	Diff line
		@@ -11326,6 +11326,20 @@ F: include/trace/
		F: kernel/trace/
		F: tools/testing/selftests/ftrace/

		TRACING MMIO ACCESSES (MMIOTRACE)
		M: Steven Rostedt <rostedt@goodmis.org>
		M: Ingo Molnar <mingo@kernel.org>
		R: Karol Herbst <karolherbst@gmail.com>
		R: Pekka Paalanen <ppaalanen@gmail.com>
		S: Maintained
		L: linux-kernel@vger.kernel.org
		L: nouveau@lists.freedesktop.org
		F: kernel/trace/trace_mmiotrace.c
		F: include/linux/mmiotrace.h
		F: arch/x86/mm/kmmio.c
		F: arch/x86/mm/mmio-mod.c
		F: arch/x86/mm/testmmiotrace.c

		TRIVIAL PATCHES
		M: Jiri Kosina <trivial@kernel.org>
		T: git git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial.git

Makefile

+1 −1

Original line number	Diff line number	Diff line
		VERSION = 4
		PATCHLEVEL = 6
		SUBLEVEL = 0
		EXTRAVERSION = -rc7
		EXTRAVERSION =
		NAME = Charred Weasel

		# DOCUMENTATION

Admin message