Merge tag 'davinci-for-v3.10/board' of... (21cb7963) · Commits · e / devices / android_kernel_teracube_emerald

Documentation/devicetree/bindings/mfd/ab8500.txt

+1 −5

Original line number	Original line	Diff line number	Diff line
	@@ -13,9 +13,6 @@ Required parent device properties:
	4 = active high level-sensitive		4 = active high level-sensitive
	8 = active low level-sensitive		8 = active low level-sensitive

	Optional parent device properties:
	- reg : contains the PRCMU mailbox address for the AB8500 i2c port

	The AB8500 consists of a large and varied group of sub-devices:		The AB8500 consists of a large and varied group of sub-devices:

	Device IRQ Names Supply Names Description		Device IRQ Names Supply Names Description
	@@ -86,9 +83,8 @@ Non-standard child device properties:
	- stericsson,amic2-bias-vamic1 : Analoge Mic wishes to use a non-standard Vamic		- stericsson,amic2-bias-vamic1 : Analoge Mic wishes to use a non-standard Vamic
	- stericsson,earpeice-cmv : Earpeice voltage (only: 950 \| 1100 \| 1270 \| 1580)		- stericsson,earpeice-cmv : Earpeice voltage (only: 950 \| 1100 \| 1270 \| 1580)

	ab8500@5 {		ab8500 {
	compatible = "stericsson,ab8500";		compatible = "stericsson,ab8500";
	reg = <5>; /* mailbox 5 is i2c */
	interrupts = <0 40 0x4>;		interrupts = <0 40 0x4>;
	interrupt-controller;		interrupt-controller;
	#interrupt-cells = <2>;		#interrupt-cells = <2>;

Documentation/devicetree/bindings/tty/serial/of-serial.txt

+3 −0

Original line number	Original line	Diff line number	Diff line
	@@ -11,6 +11,9 @@ Required properties:
	- "nvidia,tegra20-uart"		- "nvidia,tegra20-uart"
	- "nxp,lpc3220-uart"		- "nxp,lpc3220-uart"
	- "ibm,qpace-nwp-serial"		- "ibm,qpace-nwp-serial"
			- "altr,16550-FIFO32"
			- "altr,16550-FIFO64"
			- "altr,16550-FIFO128"
	- "serial" if the port type is unknown.		- "serial" if the port type is unknown.
	- reg : offset and length of the register set for the device.		- reg : offset and length of the register set for the device.
	- interrupts : should contain uart interrupt.		- interrupts : should contain uart interrupt.

Documentation/input/alps.txt

+60 −7

Original line number	Original line	Diff line number	Diff line
	@@ -3,10 +3,26 @@ ALPS Touchpad Protocol

	Introduction		Introduction
	------------		------------
			Currently the ALPS touchpad driver supports five protocol versions in use by
	Currently the ALPS touchpad driver supports four protocol versions in use by		ALPS touchpads, called versions 1, 2, 3, 4 and 5.
	ALPS touchpads, called versions 1, 2, 3, and 4. Information about the various
	protocol versions is contained in the following sections.		Since roughly mid-2010 several new ALPS touchpads have been released and
			integrated into a variety of laptops and netbooks. These new touchpads
			have enough behavior differences that the alps_model_data definition
			table, describing the properties of the different versions, is no longer
			adequate. The design choices were to re-define the alps_model_data
			table, with the risk of regression testing existing devices, or isolate
			the new devices outside of the alps_model_data table. The latter design
			choice was made. The new touchpad signatures are named: "Rushmore",
			"Pinnacle", and "Dolphin", which you will see in the alps.c code.
			For the purposes of this document, this group of ALPS touchpads will
			generically be called "new ALPS touchpads".

			We experimented with probing the ACPI interface _HID (Hardware ID)/_CID
			(Compatibility ID) definition as a way to uniquely identify the
			different ALPS variants but there did not appear to be a 1:1 mapping.
			In fact, it appeared to be an m:n mapping between the _HID and actual
			hardware type.

	Detection		Detection
	---------		---------
	@@ -20,9 +36,13 @@ If the E6 report is successful, the touchpad model is identified using the "E7
	report" sequence: E8-E7-E7-E7-E9. The response is the model signature and is		report" sequence: E8-E7-E7-E7-E9. The response is the model signature and is
	matched against known models in the alps_model_data_array.		matched against known models in the alps_model_data_array.

	With protocol versions 3 and 4, the E7 report model signature is always		For older touchpads supporting protocol versions 3 and 4, the E7 report
	73-02-64. To differentiate between these versions, the response from the		model signature is always 73-02-64. To differentiate between these
	"Enter Command Mode" sequence must be inspected as described below.		versions, the response from the "Enter Command Mode" sequence must be
			inspected as described below.

			The new ALPS touchpads have an E7 signature of 73-03-50 or 73-03-0A but
			seem to be better differentiated by the EC Command Mode response.

	Command Mode		Command Mode
	------------		------------
	@@ -47,6 +67,14 @@ address of the register being read, and the third contains the value of the
	register. Registers are written by writing the value one nibble at a time		register. Registers are written by writing the value one nibble at a time
	using the same encoding used for addresses.		using the same encoding used for addresses.

			For the new ALPS touchpads, the EC command is used to enter command
			mode. The response in the new ALPS touchpads is significantly different,
			and more important in determining the behavior. This code has been
			separated from the original alps_model_data table and put in the
			alps_identify function. For example, there seem to be two hardware init
			sequences for the "Dolphin" touchpads as determined by the second byte
			of the EC response.

	Packet Format		Packet Format
	-------------		-------------

	@@ -187,3 +215,28 @@ There are several things worth noting here.
	well.		well.

	So far no v4 devices with tracksticks have been encountered.		So far no v4 devices with tracksticks have been encountered.

			ALPS Absolute Mode - Protocol Version 5
			---------------------------------------
			This is basically Protocol Version 3 but with different logic for packet
			decode. It uses the same alps_process_touchpad_packet_v3 call with a
			specialized decode_fields function pointer to correctly interpret the
			packets. This appears to only be used by the Dolphin devices.

			For single-touch, the 6-byte packet format is:

			byte 0: 1 1 0 0 1 0 0 0
			byte 1: 0 x6 x5 x4 x3 x2 x1 x0
			byte 2: 0 y6 y5 y4 y3 y2 y1 y0
			byte 3: 0 M R L 1 m r l
			byte 4: y10 y9 y8 y7 x10 x9 x8 x7
			byte 5: 0 z6 z5 z4 z3 z2 z1 z0

			For mt, the format is:

			byte 0: 1 1 1 n3 1 n2 n1 x24
			byte 1: 1 y7 y6 y5 y4 y3 y2 y1
			byte 2: ? x2 x1 y12 y11 y10 y9 y8
			byte 3: 0 x23 x22 x21 x20 x19 x18 x17
			byte 4: 0 x9 x8 x7 x6 x5 x4 x3
			byte 5: 0 x16 x15 x14 x13 x12 x11 x10

Documentation/networking/tuntap.txt

+77 −0

Original line number	Original line	Diff line number	Diff line
	@@ -105,6 +105,83 @@ Copyright (C) 1999-2000 Maxim Krasnyansky <max_mk@yahoo.com>
	Proto [2 bytes]		Proto [2 bytes]
	Raw protocol(IP, IPv6, etc) frame.		Raw protocol(IP, IPv6, etc) frame.

			3.3 Multiqueue tuntap interface:

			From version 3.8, Linux supports multiqueue tuntap which can uses multiple
			file descriptors (queues) to parallelize packets sending or receiving. The
			device allocation is the same as before, and if user wants to create multiple
			queues, TUNSETIFF with the same device name must be called many times with
			IFF_MULTI_QUEUE flag.

			char *dev should be the name of the device, queues is the number of queues to
			be created, fds is used to store and return the file descriptors (queues)
			created to the caller. Each file descriptor were served as the interface of a
			queue which could be accessed by userspace.

			#include <linux/if.h>
			#include <linux/if_tun.h>

			int tun_alloc_mq(char dev, int queues, int fds)
			{
			struct ifreq ifr;
			int fd, err, i;

			if (!dev)
			return -1;

			memset(&ifr, 0, sizeof(ifr));
			/* Flags: IFF_TUN - TUN device (no Ethernet headers)
			* IFF_TAP - TAP device
			*
			* IFF_NO_PI - Do not provide packet information
			* IFF_MULTI_QUEUE - Create a queue of multiqueue device
			*/
			ifr.ifr_flags = IFF_TAP \| IFF_NO_PI \| IFF_MULTI_QUEUE;
			strcpy(ifr.ifr_name, dev);

			for (i = 0; i < queues; i++) {
			if ((fd = open("/dev/net/tun", O_RDWR)) < 0)
			goto err;
			err = ioctl(fd, TUNSETIFF, (void *)&ifr);
			if (err) {
			close(fd);
			goto err;
			}
			fds[i] = fd;
			}

			return 0;
			err:
			for (--i; i >= 0; i--)
			close(fds[i]);
			return err;
			}

			A new ioctl(TUNSETQUEUE) were introduced to enable or disable a queue. When
			calling it with IFF_DETACH_QUEUE flag, the queue were disabled. And when
			calling it with IFF_ATTACH_QUEUE flag, the queue were enabled. The queue were
			enabled by default after it was created through TUNSETIFF.

			fd is the file descriptor (queue) that we want to enable or disable, when
			enable is true we enable it, otherwise we disable it

			#include <linux/if.h>
			#include <linux/if_tun.h>

			int tun_set_queue(int fd, int enable)
			{
			struct ifreq ifr;

			memset(&ifr, 0, sizeof(ifr));

			if (enable)
			ifr.ifr_flags = IFF_ATTACH_QUEUE;
			else
			ifr.ifr_flags = IFF_DETACH_QUEUE;

			return ioctl(fd, TUNSETQUEUE, (void *)&ifr);
			}

	Universal TUN/TAP device driver Frequently Asked Question.		Universal TUN/TAP device driver Frequently Asked Question.

	1. What platforms are supported by TUN/TAP driver ?		1. What platforms are supported by TUN/TAP driver ?

Documentation/trace/ftrace.txt

+1 −1

Original line number	Original line	Diff line number	Diff line
	@@ -1873,7 +1873,7 @@ feature:

	status\input \| 0 \| 1 \| else \|		status\input \| 0 \| 1 \| else \|
	--------------+------------+------------+------------+		--------------+------------+------------+------------+
	not allocated \|(do nothing)\| alloc+swap \| EINVAL \|		not allocated \|(do nothing)\| alloc+swap \|(do nothing)\|
	--------------+------------+------------+------------+		--------------+------------+------------+------------+
	allocated \| free \| swap \| clear \|		allocated \| free \| swap \| clear \|
	--------------+------------+------------+------------+		--------------+------------+------------+------------+