Commit b207892b authored by Jens Axboe's avatar Jens Axboe
Browse files

Merge branch 'for-linus' into for-3.18/core 



A bit of churn on the for-linus side that would be nice to have
in the core bits for 3.18, so pull it in to catch us up and make
forward progress easier.

Signed-off-by: default avatarJens Axboe <axboe@fb.com>

Conflicts:
	block/scsi_ioctl.c
parents 018a17bd a5164405

Documentation/devicetree/bindings/mfd/tc3589x.txt

0 → 100644
+107 −0
Original line number Diff line number Diff line 
* Toshiba TC3589x multi-purpose expander



The Toshiba TC3589x series are I2C-based MFD devices which may expose the

following built-in devices: gpio, keypad, rotator (vibrator), PWM (for

e.g. LEDs or vibrators) The included models are:



- TC35890

- TC35892

- TC35893

- TC35894

- TC35895

- TC35896



Required properties:

 - compatible : must be "toshiba,tc35890", "toshiba,tc35892", "toshiba,tc35893",

   "toshiba,tc35894", "toshiba,tc35895" or "toshiba,tc35896"

 - reg : I2C address of the device

 - interrupt-parent : specifies which IRQ controller we're connected to

 - interrupts : the interrupt on the parent the controller is connected to

 - interrupt-controller : marks the device node as an interrupt controller

 - #interrupt-cells : should be <1>, the first cell is the IRQ offset on this

   TC3589x interrupt controller.



Optional nodes:



- GPIO

  This GPIO module inside the TC3589x has 24 (TC35890, TC35892) or 20

  (other models) GPIO lines.

 - compatible : must be "toshiba,tc3589x-gpio"

 - interrupts : interrupt on the parent, which must be the tc3589x MFD device

 - interrupt-controller : marks the device node as an interrupt controller

 - #interrupt-cells : should be <2>, the first cell is the IRQ offset on this

   TC3589x GPIO interrupt controller, the second cell is the interrupt flags

   in accordance with <dt-bindings/interrupt-controller/irq.h>. The following

   flags are valid:

   - IRQ_TYPE_LEVEL_LOW

   - IRQ_TYPE_LEVEL_HIGH

   - IRQ_TYPE_EDGE_RISING

   - IRQ_TYPE_EDGE_FALLING

   - IRQ_TYPE_EDGE_BOTH

 - gpio-controller : marks the device node as a GPIO controller

 - #gpio-cells : should be <2>, the first cell is the GPIO offset on this

   GPIO controller, the second cell is the flags.



- Keypad

  This keypad is the same on all variants, supporting up to 96 different

  keys. The linux-specific properties are modeled on those already existing

  in other input drivers.

 - compatible : must be "toshiba,tc3589x-keypad"

 - debounce-delay-ms : debounce interval in milliseconds

 - keypad,num-rows : number of rows in the matrix, see

   bindings/input/matrix-keymap.txt

 - keypad,num-columns : number of columns in the matrix, see

   bindings/input/matrix-keymap.txt

 - linux,keymap: the definition can be found in

   bindings/input/matrix-keymap.txt

 - linux,no-autorepeat: do no enable autorepeat feature.

 - linux,wakeup: use any event on keypad as wakeup event.



Example:



tc35893@44 {

	compatible = "toshiba,tc35893";

	reg = <0x44>;

	interrupt-parent = <&gpio6>;

	interrupts = <26 IRQ_TYPE_EDGE_RISING>;



	interrupt-controller;

	#interrupt-cells = <1>;



	tc3589x_gpio {

		compatible = "toshiba,tc3589x-gpio";

		interrupts = <0>;



		interrupt-controller;

		#interrupt-cells = <2>;

		gpio-controller;

		#gpio-cells = <2>;

	};

	tc3589x_keypad {

		compatible = "toshiba,tc3589x-keypad";

		interrupts = <6>;

		debounce-delay-ms = <4>;

		keypad,num-columns = <8>;

		keypad,num-rows = <8>;

		linux,no-autorepeat;

		linux,wakeup;

		linux,keymap = <0x0301006b

				0x04010066

				0x06040072

				0x040200d7

				0x0303006a

				0x0205000e

				0x0607008b

				0x0500001c

				0x0403000b

				0x03040034

				0x05020067

				0x0305006c

				0x040500e7

				0x0005009e

				0x06020073

				0x01030039

				0x07060069

				0x050500d9>;

	};

};

Documentation/devicetree/bindings/mtd/gpmc-nand.txt

+1 −1
Original line number Diff line number Diff line
@@ -22,7 +22,7 @@ Optional properties: 
				width of 8 is assumed.



 - ti,nand-ecc-opt:		A string setting the ECC layout to use. One of:

		"sw"		<deprecated> use "ham1" instead

		"sw"		1-bit Hamming ecc code via software

		"hw"		<deprecated> use "ham1" instead

		"hw-romcode"	<deprecated> use "ham1" instead

		"ham1"		1-bit Hamming ecc code

Documentation/devicetree/bindings/pinctrl/qcom,apq8064-pinctrl.txt

+1 −1
Original line number Diff line number Diff line
@@ -62,7 +62,7 @@ Example: 
		#gpio-cells = <2>;

		interrupt-controller;

		#interrupt-cells = <2>;

		interrupts = <0 32 0x4>;

		interrupts = <0 16 0x4>;



		pinctrl-names = "default";

		pinctrl-0 = <&gsbi5_uart_default>;

Documentation/dma-buf-sharing.txt

+8 −6
Original line number Diff line number Diff line
@@ -56,10 +56,10 @@ The dma_buf buffer sharing API usage contains the following steps: 
				     size_t size, int flags,

				     const char *exp_name)



   If this succeeds, dma_buf_export allocates a dma_buf structure, and returns a

   pointer to the same. It also associates an anonymous file with this buffer,

   so it can be exported. On failure to allocate the dma_buf object, it returns

   NULL.

   If this succeeds, dma_buf_export_named allocates a dma_buf structure, and

   returns a pointer to the same. It also associates an anonymous file with this

   buffer, so it can be exported. On failure to allocate the dma_buf object,

   it returns NULL.



   'exp_name' is the name of exporter - to facilitate information while

   debugging.
@@ -76,7 +76,7 @@ The dma_buf buffer sharing API usage contains the following steps: 
   drivers and/or processes.



   Interface:

      int dma_buf_fd(struct dma_buf *dmabuf)

      int dma_buf_fd(struct dma_buf *dmabuf, int flags)



   This API installs an fd for the anonymous file associated with this buffer;

   returns either 'fd', or error.
@@ -157,7 +157,9 @@ to request use of buffer for allocation. 
   "dma_buf->ops->" indirection from the users of this interface.



   In struct dma_buf_ops, unmap_dma_buf is defined as

      void (*unmap_dma_buf)(struct dma_buf_attachment *, struct sg_table *);

      void (*unmap_dma_buf)(struct dma_buf_attachment *,

                            struct sg_table *,

                            enum dma_data_direction);



   unmap_dma_buf signifies the end-of-DMA for the attachment provided. Like

   map_dma_buf, this API also must be implemented by the exporter.

Documentation/kdump/kdump.txt

+33 −3
Original line number Diff line number Diff line
@@ -18,7 +18,7 @@ memory image to a dump file on the local disk, or across the network to 
a remote system.



Kdump and kexec are currently supported on the x86, x86_64, ppc64, ia64,

and s390x architectures.

s390x and arm architectures.



When the system kernel boots, it reserves a small section of memory for

the dump-capture kernel. This ensures that ongoing Direct Memory Access
@@ -112,7 +112,7 @@ There are two possible methods of using Kdump. 
2) Or use the system kernel binary itself as dump-capture kernel and there is

   no need to build a separate dump-capture kernel. This is possible

   only with the architectures which support a relocatable kernel. As

   of today, i386, x86_64, ppc64 and ia64 architectures support relocatable

   of today, i386, x86_64, ppc64, ia64 and arm architectures support relocatable

   kernel.



Building a relocatable kernel is advantageous from the point of view that
@@ -241,6 +241,13 @@ Dump-capture kernel config options (Arch Dependent, ia64) 
  kernel will be aligned to 64Mb, so if the start address is not then

  any space below the alignment point will be wasted.



Dump-capture kernel config options (Arch Dependent, arm)

----------------------------------------------------------



-   To use a relocatable kernel,

    Enable "AUTO_ZRELADDR" support under "Boot" options:



    AUTO_ZRELADDR=y



Extended crashkernel syntax

===========================
@@ -256,6 +263,10 @@ The syntax is: 
    crashkernel=<range1>:<size1>[,<range2>:<size2>,...][@offset]

    range=start-[end]



Please note, on arm, the offset is required.

    crashkernel=<range1>:<size1>[,<range2>:<size2>,...]@offset

    range=start-[end]



    'start' is inclusive and 'end' is exclusive.



For example:
@@ -296,6 +307,12 @@ Boot into System Kernel 
   on the memory consumption of the kdump system. In general this is not

   dependent on the memory size of the production system.



   On arm, use "crashkernel=Y@X". Note that the start address of the kernel

   will be aligned to 128MiB (0x08000000), so if the start address is not then

   any space below the alignment point may be overwritten by the dump-capture kernel,

   which means it is possible that the vmcore is not that precise as expected.





Load the Dump-capture Kernel

============================
@@ -315,7 +332,8 @@ For ia64: 
	- Use vmlinux or vmlinuz.gz

For s390x:

	- Use image or bzImage



For arm:

	- Use zImage



If you are using a uncompressed vmlinux image then use following command

to load dump-capture kernel.
@@ -331,6 +349,15 @@ to load dump-capture kernel. 
   --initrd=<initrd-for-dump-capture-kernel> \

   --append="root=<root-dev> <arch-specific-options>"



If you are using a compressed zImage, then use following command

to load dump-capture kernel.



   kexec --type zImage -p <dump-capture-kernel-bzImage> \

   --initrd=<initrd-for-dump-capture-kernel> \

   --dtb=<dtb-for-dump-capture-kernel> \

   --append="root=<root-dev> <arch-specific-options>"





Please note, that --args-linux does not need to be specified for ia64.

It is planned to make this a no-op on that architecture, but for now

it should be omitted
@@ -347,6 +374,9 @@ For ppc64: 
For s390x:

	"1 maxcpus=1 cgroup_disable=memory"



For arm:

	"1 maxcpus=1 reset_devices"



Notes on loading the dump-capture kernel:



* By default, the ELF headers are stored in ELF64 format to support

CRA Git | Maintained and supported by SUSTech CRA and CCSE