Merge branch 'linus' into x86/urgent

See the comment headers in the source code (or the docbook generated

from them) for more information.

However, given that there are no fewer than four families of RCU APIs

in the Linux kernel, how do you choose which one to use?  The following

list can be helpful:

a.	Will readers need to block?  If so, you need SRCU.

b.	What about the -rt patchset?  If readers would need to block

	in an non-rt kernel, you need SRCU.  If readers would block

	in a -rt kernel, but not in a non-rt kernel, SRCU is not

	necessary.

c.	Do you need to treat NMI handlers, hardirq handlers,

	and code segments with preemption disabled (whether

	via preempt_disable(), local_irq_save(), local_bh_disable(),

	or some other mechanism) as if they were explicit RCU readers?

	If so, you need RCU-sched.

d.	Do you need RCU grace periods to complete even in the face

	of softirq monopolization of one or more of the CPUs?  For

	example, is your code subject to network-based denial-of-service

	attacks?  If so, you need RCU-bh.

e.	Is your workload too update-intensive for normal use of

	RCU, but inappropriate for other synchronization mechanisms?

	If so, consider SLAB_DESTROY_BY_RCU.  But please be careful!

f.	Otherwise, use RCU.

Of course, this all assumes that you have determined that RCU is in fact

the right tool for your job.

8.  ANSWERS TO QUICK QUIZZES

CE4100 I2C

----------

CE4100 has one PCI device which is described as the I2C-Controller. This

PCI device has three PCI-bars, each bar contains a complete I2C

controller. So we have a total of three independent I2C-Controllers

which share only an interrupt line.

The driver is probed via the PCI-ID and is gathering the information of

attached devices from the devices tree.

Grant Likely recommended to use the ranges property to map the PCI-Bar

number to its physical address and to use this to find the child nodes

of the specific I2C controller. This were his exact words:

       Here's where the magic happens.  Each entry in

       ranges describes how the parent pci address space

       (middle group of 3) is translated to the local

       address space (first group of 2) and the size of

       each range (last cell).  In this particular case,

       the first cell of the local address is chosen to be

       1:1 mapped to the BARs, and the second is the

       offset from be base of the BAR (which would be

       non-zero if you had 2 or more devices mapped off

       the same BAR)

       ranges allows the address mapping to be described

       in a way that the OS can interpret without

       requiring custom device driver code.

This is an example which is used on FalconFalls:

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

	i2c-controller@b,2 {

		#address-cells = <2>;

		#size-cells = <1>;

		compatible = "pci8086,2e68.2",

				"pci8086,2e68",

				"pciclass,ff0000",

				"pciclass,ff00";

		reg = <0x15a00 0x0 0x0 0x0 0x0>;

		interrupts = <16 1>;

		/* as described by Grant, the first number in the group of

		* three is the bar number followed by the 64bit bar address

		* followed by size of the mapping. The bar address

		* requires also a valid translation in parents ranges

		* property.

		*/

		ranges = <0 0   0x02000000 0 0xdffe0500 0x100

			  1 0   0x02000000 0 0xdffe0600 0x100

			  2 0   0x02000000 0 0xdffe0700 0x100>;

		i2c@0 {

			#address-cells = <1>;

			#size-cells = <0>;

			compatible = "intel,ce4100-i2c-controller";

			/* The first number in the reg property is the

			* number of the bar

			*/

			reg = <0 0 0x100>;

			/* This I2C controller has no devices */

		};

		i2c@1 {

			#address-cells = <1>;

			#size-cells = <0>;

			compatible = "intel,ce4100-i2c-controller";

			reg = <1 0 0x100>;

			/* This I2C controller has one gpio controller */

			gpio@26 {

				#gpio-cells = <2>;

				compatible = "ti,pcf8575";

				reg = <0x26>;

				gpio-controller;

			};

		};

		i2c@2 {

			#address-cells = <1>;

			#size-cells = <0>;

			compatible = "intel,ce4100-i2c-controller";

			reg = <2 0 0x100>;

			gpio@26 {

				#gpio-cells = <2>;

				compatible = "ti,pcf8575";

				reg = <0x26>;

				gpio-controller;

			};

		};

	};

 Motorola mc146818 compatible RTC

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Required properties:

  - compatible : "motorola,mc146818"

  - reg : should contain registers location and length.

Optional properties:

  - interrupts : should contain interrupt.

  - interrupt-parent : interrupt source phandle.

  - ctrl-reg : Contains the initial value of the control register also

    called "Register B".

  - freq-reg : Contains the initial value of the frequency register also

    called "Regsiter A".

"Register A" and "B" are usually initialized by the firmware (BIOS for

instance). If this is not done, it can be performed by the driver.

ISA Example:

	rtc@70 {

	         compatible = "motorola,mc146818";

	         interrupts = <8 3>;

	         interrupt-parent = <&ioapic1>;

	         ctrl-reg = <2>;

	         freq-reg = <0x26>;

	         reg = <1 0x70 2>;

	 };

CE4100 Device Tree Bindings

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

The CE4100 SoC uses for in core peripherals the following compatible

format: <vendor>,<chip>-<device>.

Many of the "generic" devices like HPET or IO APIC have the ce4100

name in their compatible property because they first appeared in this

SoC.

The CPU node

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

	cpu@0 {

		device_type = "cpu";

		compatible = "intel,ce4100";

		reg = <0>;

		lapic = <&lapic0>;

	};

The reg property describes the CPU number. The lapic property points to

the local APIC timer.

The SoC node

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

This node describes the in-core peripherals. Required property:

  compatible = "intel,ce4100-cp";

The PCI node

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

This node describes the PCI bus on the SoC. Its property should be

  compatible = "intel,ce4100-pci", "pci";

If the OS is using the IO-APIC for interrupt routing then the reported

interrupt numbers for devices is no longer true. In order to obtain the

correct interrupt number, the child node which represents the device has

to contain the interrupt property. Besides the interrupt property it has

to contain at least the reg property containing the PCI bus address and

compatible property according to "PCI Bus Binding Revision 2.1".

Interrupt chips

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

* Intel I/O Advanced Programmable Interrupt Controller (IO APIC)

  Required properties:

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

     compatible = "intel,ce4100-ioapic";

     #interrupt-cells = <2>;

  Device's interrupt property:

     interrupts = <P S>;

  The first number (P) represents the interrupt pin which is wired to the

  IO APIC. The second number (S) represents the sense of interrupt which

  should be configured and can be one of:

    0 - Edge Rising

    1 - Level Low

    2 - Level High

    3 - Edge Falling

* Local APIC

  Required property:

     compatible = "intel,ce4100-lapic";