Merge branch 'next'

Bring in the assorted changes that have been staged in the 'next' branch
prior to release.

Signed-off-by: Tom Rini <trini@konsulko.com>

11 files changed, 518 insertions, 8 deletions

diff --git a/doc/README.chromium b/doc/README.chromium
index 8f67da6..75f2f24 100644
--- a/doc/README.chromium
+++ b/doc/README.chromium
@@ -23,6 +23,13 @@ available:
         from U-Boot in 2013) and coreboot. See below for more information on
         this.
 
+   - Running U-Boot from coreboot. This allows U-Boot to run on more devices
+        since many of them only support coreboot as the bootloader and have
+        no bare-metal support in U-Boot. For this, use the 'coreboot' target.
+
+   - Running U-Boot and booting into a Chrome OS image, but without verified
+        boot. This can be useful for testing.
+
 
 U-Boot with Chromium OS verified boot
 -------------------------------------
@@ -168,14 +175,42 @@ existed in U-Boot were not brought over to coreboot or depthcharge.
 The U-Boot tests ('make check') do operate, but at present there are no
 Chromium OS tests available. These will hopefully come together over time. Of
 course the above sandbox feature provides a sort of functional test and can
-detecte problems that affect the flow or particular vboot features.
+detect problems that affect the flow or particular vboot features.
+
+
+U-Boot without Chromium OS verified boot
+----------------------------------------
+
+The following script can be used to boot a Chrome OS image on coral:
+
+   # Read the image header and obtain the address of the kernel
+   # The offset 4f0 is defined by verified boot and may change for other
+   # Chromebooks
+   read mmc 2:2 100000 0 80; setexpr loader *001004f0;
+
+   # Get the kernel size and calculate the number of blocks (0x200 bytes each)
+   setexpr size *00100518; setexpr blocks $size / 200;
+
+   # Read the full kernel and calculate the address of the setup block
+   read mmc 2:2 100000 80 $blocks; setexpr setup $loader - 1000;
+
+   # Locate the command line
+   setexpr cmdline $loader - 2000;
+
+   # Start the zboot process with the loaded kernel, setup block and cmdline
+   zboot start 100000 0 0 0 $setup $cmdline;
+
+   # Load the kernel, fix up the 'setup' block, dump information
+   zboot load; zboot setup; zboot dump
+
+   # Boot into Chrome OS
+   zboot go
 
 
 TO DO
 -----
 
-- Support for booting from coreboot (patches expected March 2019)
-- Support for booting from an ARM board, e.g. bob
+Get the full ACPI tables working with Coral
 
 
 Simon Glass
diff --git a/doc/README.udp b/doc/README.udp
new file mode 100644
index 0000000..da07257
--- /dev/null
+++ b/doc/README.udp
@@ -0,0 +1,35 @@
+Udp framework
+
+The udp framework is build on top of network framework and is designed
+to define new protocol or new command based on udp without modifying
+the network framework.
+
+The udp framework define a function udp_loop that take as argument
+a structure udp_ops (defined in include/net/udp.h) :
+
+struct udp_ops {
+	int (*prereq)(void *data);
+	int (*start)(void *data);
+	void *data;
+};
+
+The callback prereq define if all the requirements are
+valid before running the network/udp loop.
+
+The callback start define the first step in the network/udp loop,
+and it may also be used to configure a timemout and udp handler.
+
+The pointer data is used to store private data that
+could be used by both callback.
+
+A simple example to use this framework:
+
+static struct udp_ops udp_ops = {
+	.prereq = wmp_prereq,
+	.start = wmp_start,
+	.data = NULL,
+};
+
+...
+
+err = udp_loop(&udp_ops);
diff --git a/doc/board/intel/edison.rst b/doc/board/intel/edison.rst
index 1aee2a1..d658fac 100644
--- a/doc/board/intel/edison.rst
+++ b/doc/board/intel/edison.rst
@@ -39,3 +39,123 @@ use.
    reset the board::
 
    => reset
+
+
+Updating U-Boot using xFSTK
+---------------------------
+
+You can also update U-Boot using the xfstk-dldr-solo tool if you can build it.
+One way to do that is to follow the `xFSTK`_ instructions. You may need to use
+a virtual machine running Ubuntu Trusty. Once you have built it and installed
+libboost-all-dev, you can copy xfstk-dldr-solo to /usr/local/bin and
+libboost_program_options.so.1.54.0 to /usr/lib/i386-linux-gnu/ and with luck
+it will work. You might fine this `drive`_ helpful.
+
+If it does, then you can download and unpack the Edison reocovery image,
+install dfu-util, reset your board and flash U-Boot like this::
+
+   $ xfstk-dldr-solo --gpflags 0x80000007 \
+      --osimage u-boot-edison.img \
+      --fwdnx recover/edison_dnx_fwr.bin \
+      --fwimage recover/edison_ifwi-dbg-00.bin \
+      --osdnx recover/edison_dnx_osr.bin
+
+This should show the following
+
+.. code-block:: none
+
+  XFSTK Downloader Solo 0.0.0
+  Copyright (c) 2015 Intel Corporation
+  Build date and time: Aug 15 2020 15:07:13
+
+  .Intel SoC Device Detection Found
+  Parsing Commandline....
+  Registering Status Callback....
+  .Initiating Download Process....
+  .......(lots of dots)........XFSTK-STATUS--Reconnecting to device - Attempt #1
+  .......(even more dots)......................
+
+
+You have about 10 seconds after resetting the board to type the above command.
+If you want to check if the board is ready, type:
+
+.. code-block:: none
+
+  lsusb |egrep "8087|8086"
+  Bus 001 Device 004: ID 8086:e005 Intel Corp.
+
+If you see a device with the same ID as above, the board is waiting for your
+command.
+
+After about 5 seconds you should see some console output from the board:
+
+.. code-block:: none
+
+  ******************************
+  PSH KERNEL VERSION: b0182b2b
+  		WR: 20104000
+  ******************************
+
+  SCU IPC: 0x800000d0  0xfffce92c
+
+  PSH miaHOB version: TNG.B0.VVBD.0000000c
+
+  microkernel built 11:24:08 Feb  5 2015
+
+  ******* PSH loader *******
+  PCM page cache size = 192 KB
+  Cache Constraint = 0 Pages
+  Arming IPC driver ..
+  Adding page store pool ..
+  PagestoreAddr(IMR Start Address) = 0x04899000
+  pageStoreSize(IMR Size)          = 0x00080000
+
+  *** Ready to receive application ***
+
+  After another 10 seconds the xFSTK tool completes and the board resets. About
+  10 seconds after that should see the above message again and then within a
+  few seconds U-Boot should start on your board:
+
+.. code-block:: none
+
+  U-Boot 2020.10-rc3 (Sep 03 2020 - 18:44:28 -0600)
+
+  CPU:   Genuine Intel(R) CPU   4000  @  500MHz
+  DRAM:  980.6 MiB
+  WDT:   Started with servicing (60s timeout)
+  MMC:   mmc@ff3fc000: 0, mmc@ff3fa000: 1
+  Loading Environment from MMC... OK
+  In:    serial
+  Out:   serial
+  Err:   serial
+  Saving Environment to MMC... Writing to redundant MMC(0)... OK
+  Saving Environment to MMC... Writing to MMC(0)... OK
+  Net:   No ethernet found.
+  Hit any key to stop autoboot:  0
+  Target:blank
+  Partitioning using GPT
+  Writing GPT: success!
+  Saving Environment to MMC... Writing to redundant MMC(0)... OK
+  Flashing already done...
+  5442816 bytes read in 238 ms (21.8 MiB/s)
+  Valid Boot Flag
+  Setup Size = 0x00003c00
+  Magic signature found
+  Using boot protocol version 2.0c
+  Linux kernel version 3.10.17-poky-edison+ (ferry@kalamata) #1 SMP PREEMPT Mon Jan 11 14:54:18 CET 2016
+  Building boot_params at 0x00090000
+  Loading bzImage at address 100000 (5427456 bytes)
+  Magic signature found
+  Kernel command line: "rootwait root=PARTUUID=ada722ed-6410-764e-8619-abff6f66e10e rootfstype=ext4 console=ttyMFD2 earlyprintk=ttyMFD2,keep loglevel=4 g_multi.ethernet_config=cdc systemd.unit=multi-user.target hardware_id=00 g_multi.iSerialNumber=2249baf774c675598661a63098c0ad41 g_multi.dev_addr=02:00:86:c0:ad:41 platform_mrfld_audio.audio_codec=dummy"
+  Magic signature found
+
+  Starting kernel ...
+
+  ...
+
+  Poky (Yocto Project Reference Distro) 1.7.2 edison ttyMFD2
+
+  edison login:
+
+.. _xFSTK: https://community.intel.com/t5/Intel-Makers/Building-xFSTK-on-Ubuntu-14-04-32-bit-for-flashing-Edison/td-p/538081
+.. _drive: https://drive.google.com/drive/u/0/folders/1URPHrOk9-UBsh8hjv-7WwC0W6Fy61uAJ
diff --git a/doc/board/sipeed/maix.rst b/doc/board/sipeed/maix.rst
index efcde9a..3f791b4 100644
--- a/doc/board/sipeed/maix.rst
+++ b/doc/board/sipeed/maix.rst
@@ -59,7 +59,7 @@ Sipeed MAIX BiT          sipeed_maix_bitm_defconfig bit        first
 Sipeed MAIX BiT with Mic sipeed_maix_bitm_defconfig bit_mic    first
 Sipeed MAIXDUINO         sipeed_maix_bitm_defconfig maixduino  first
 Sipeed MAIX GO                                      goE        second
-Sipeed MAIX ONE DOCK                                goD        first
+Sipeed MAIX ONE DOCK                                dan        first
 ======================== ========================== ========== ==========
 
 Flashing causes a reboot of the device. Parameter -t specifies that the serial
@@ -285,11 +285,15 @@ Technical Details
 Boot Sequence
 ^^^^^^^^^^^^^
 
-1. ``RESET`` pin is deasserted.
+1. ``RESET`` pin is deasserted. The pin is connected to the ``RESET`` button. It
+   can also be set to low via either the ``DTR`` or the ``RTS`` line of the
+   serial interface (depending on the board).
 2. Both harts begin executing at ``0x00001000``.
 3. Both harts jump to firmware at ``0x88000000``.
 4. One hart is chosen as a boot hart.
-5. Firmware reads value of pin ``IO_16`` (ISP).
+5. Firmware reads the value of pin ``IO_16`` (ISP). This pin is connected to the
+   ``BOOT`` button. The pin can equally be set to low via either the ``DTR`` or
+   ``RTS`` line of the serial interface (depending on the board).
 
    * If the pin is low, enter ISP mode. This mode allows loading data to ram,
      writing it to flash, and booting from specific addresses.
diff --git a/doc/device-tree-bindings/arm/arm,scmi.txt b/doc/device-tree-bindings/arm/arm,scmi.txt
new file mode 100644
index 0000000..1f293ea
--- /dev/null
+++ b/doc/device-tree-bindings/arm/arm,scmi.txt
@@ -0,0 +1,197 @@
+System Control and Management Interface (SCMI) Message Protocol
+----------------------------------------------------------
+
+The SCMI is intended to allow agents such as OSPM to manage various functions
+that are provided by the hardware platform it is running on, including power
+and performance functions.
+
+This binding is intended to define the interface the firmware implementing
+the SCMI as described in ARM document number ARM DEN 0056A ("ARM System Control
+and Management Interface Platform Design Document")[0] provide for OSPM in
+the device tree.
+
+Required properties:
+
+The scmi node with the following properties shall be under the /firmware/ node.
+
+- compatible : shall be "arm,scmi" or "arm,scmi-smc" for smc/hvc transports
+- mboxes: List of phandle and mailbox channel specifiers. It should contain
+	  exactly one or two mailboxes, one for transmitting messages("tx")
+	  and another optional for receiving the notifications("rx") if
+	  supported.
+- shmem : List of phandle pointing to the shared memory(SHM) area as per
+	  generic mailbox client binding.
+- #address-cells : should be '1' if the device has sub-nodes, maps to
+	  protocol identifier for a given sub-node.
+- #size-cells : should be '0' as 'reg' property doesn't have any size
+	  associated with it.
+- arm,smc-id : SMC id required when using smc or hvc transports
+
+Optional properties:
+
+- mbox-names: shall be "tx" or "rx" depending on mboxes entries.
+
+See Documentation/devicetree/bindings/mailbox/mailbox.txt for more details
+about the generic mailbox controller and client driver bindings.
+
+The mailbox is the only permitted method of calling the SCMI firmware.
+Mailbox doorbell is used as a mechanism to alert the presence of a
+messages and/or notification.
+
+Each protocol supported shall have a sub-node with corresponding compatible
+as described in the following sections. If the platform supports dedicated
+communication channel for a particular protocol, the 3 properties namely:
+mboxes, mbox-names and shmem shall be present in the sub-node corresponding
+to that protocol.
+
+Clock/Performance bindings for the clocks/OPPs based on SCMI Message Protocol
+------------------------------------------------------------
+
+This binding uses the common clock binding[1].
+
+Required properties:
+- #clock-cells : Should be 1. Contains the Clock ID value used by SCMI commands.
+
+Power domain bindings for the power domains based on SCMI Message Protocol
+------------------------------------------------------------
+
+This binding for the SCMI power domain providers uses the generic power
+domain binding[2].
+
+Required properties:
+ - #power-domain-cells : Should be 1. Contains the device or the power
+			 domain ID value used by SCMI commands.
+
+Sensor bindings for the sensors based on SCMI Message Protocol
+--------------------------------------------------------------
+SCMI provides an API to access the various sensors on the SoC.
+
+Required properties:
+- #thermal-sensor-cells: should be set to 1. This property follows the
+			 thermal device tree bindings[3].
+
+			 Valid cell values are raw identifiers (Sensor ID)
+			 as used by the firmware. Refer to  platform details
+			 for your implementation for the IDs to use.
+
+Reset signal bindings for the reset domains based on SCMI Message Protocol
+------------------------------------------------------------
+
+This binding for the SCMI reset domain providers uses the generic reset
+signal binding[5].
+
+Required properties:
+ - #reset-cells : Should be 1. Contains the reset domain ID value used
+		  by SCMI commands.
+
+SRAM and Shared Memory for SCMI
+-------------------------------
+
+A small area of SRAM is reserved for SCMI communication between application
+processors and SCP.
+
+The properties should follow the generic mmio-sram description found in [4]
+
+Each sub-node represents the reserved area for SCMI.
+
+Required sub-node properties:
+- reg : The base offset and size of the reserved area with the SRAM
+- compatible : should be "arm,scmi-shmem" for Non-secure SRAM based
+	       shared memory
+
+[0] http://infocenter.arm.com/help/topic/com.arm.doc.den0056a/index.html
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+[2] Documentation/devicetree/bindings/power/power-domain.yaml
+[3] Documentation/devicetree/bindings/thermal/thermal.txt
+[4] Documentation/devicetree/bindings/sram/sram.yaml
+[5] Documentation/devicetree/bindings/reset/reset.txt
+
+Example:
+
+sram@50000000 {
+	compatible = "mmio-sram";
+	reg = <0x0 0x50000000 0x0 0x10000>;
+
+	#address-cells = <1>;
+	#size-cells = <1>;
+	ranges = <0 0x0 0x50000000 0x10000>;
+
+	cpu_scp_lpri: scp-shmem@0 {
+		compatible = "arm,scmi-shmem";
+		reg = <0x0 0x200>;
+	};
+
+	cpu_scp_hpri: scp-shmem@200 {
+		compatible = "arm,scmi-shmem";
+		reg = <0x200 0x200>;
+	};
+};
+
+mailbox@40000000 {
+	....
+	#mbox-cells = <1>;
+	reg = <0x0 0x40000000 0x0 0x10000>;
+};
+
+firmware {
+
+	...
+
+	scmi {
+		compatible = "arm,scmi";
+		mboxes = <&mailbox 0 &mailbox 1>;
+		mbox-names = "tx", "rx";
+		shmem = <&cpu_scp_lpri &cpu_scp_hpri>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		scmi_devpd: protocol@11 {
+			reg = <0x11>;
+			#power-domain-cells = <1>;
+		};
+
+		scmi_dvfs: protocol@13 {
+			reg = <0x13>;
+			#clock-cells = <1>;
+		};
+
+		scmi_clk: protocol@14 {
+			reg = <0x14>;
+			#clock-cells = <1>;
+		};
+
+		scmi_sensors0: protocol@15 {
+			reg = <0x15>;
+			#thermal-sensor-cells = <1>;
+		};
+
+		scmi_reset: protocol@16 {
+			reg = <0x16>;
+			#reset-cells = <1>;
+		};
+	};
+};
+
+cpu@0 {
+	...
+	reg = <0 0>;
+	clocks = <&scmi_dvfs 0>;
+};
+
+hdlcd@7ff60000 {
+	...
+	reg = <0 0x7ff60000 0 0x1000>;
+	clocks = <&scmi_clk 4>;
+	power-domains = <&scmi_devpd 1>;
+	resets = <&scmi_reset 10>;
+};
+
+thermal-zones {
+	soc_thermal {
+		polling-delay-passive = <100>;
+		polling-delay = <1000>;
+					/* sensor ID */
+		thermal-sensors = <&scmi_sensors0 3>;
+		...
+	};
+};
diff --git a/doc/device-tree-bindings/chosen.txt b/doc/device-tree-bindings/chosen.txt
index d4dfc05..e5ba672 100644
--- a/doc/device-tree-bindings/chosen.txt
+++ b/doc/device-tree-bindings/chosen.txt
@@ -143,3 +143,21 @@ This provides the ordering to use when writing device data to the ACPI SSDT
 node to add. The ACPI information is written in this order.
 
 If the ordering does not include all nodes, an error is generated.
+
+e820-entries
+------------
+
+This provides a way to add entries to the e820 table which tells the OS about
+the memory map. The property contains three sets of 64-bit values:
+
+   address   - Start address of region
+   size      - Size of region
+   flags     - Flags (E820_...)
+
+Example:
+
+chosen {
+	e820-entries = /bits/ 64 <
+		IOMAP_P2SB_BAR IOMAP P2SB_SIZE E820_RESERVED
+		MCH_BASE_ADDRESS     MCH_SIZE  E820_RESERVED>;
+};
diff --git a/doc/device-tree-bindings/device.txt b/doc/device-tree-bindings/device.txt
index 2a5736c..73ce2a3 100644
--- a/doc/device-tree-bindings/device.txt
+++ b/doc/device-tree-bindings/device.txt
@@ -22,6 +22,8 @@ the acpi,compatible property.
  - acpi,name : Provides the ACPI name for a device, which is a string consisting
    of four alphanumeric character (upper case)
  - acpi,uid : _UID value for device
+ - acpi,wake : Provides the GPE used to detect a request from a device to wake
+   from sleep
  - linux,probed : Tells U-Boot to add 'linux,probed' to the ACPI tables so that
     Linux will only load the driver if the device can be detected (e.g. on I2C
     bus). Note that this is an out-of-tree Linux feature.
@@ -46,6 +48,7 @@ pcie-a0@14,0 {
 		compatible = "intel,generic-wifi";
 		acpi,ddn = "Intel WiFi";
 		acpi,name = "WF00";
+		acpi,wake = <GPE0_DW3_00>;
 		interrupts-extended = <&acpi_gpe 0x3c 0>;
 	};
 };
diff --git a/doc/device-tree-bindings/i2c/generic-acpi.txt b/doc/device-tree-bindings/i2c/generic-acpi.txt
new file mode 100644
index 0000000..3510a71
--- /dev/null
+++ b/doc/device-tree-bindings/i2c/generic-acpi.txt
@@ -0,0 +1,42 @@
+I2C generic device
+==================
+
+This is used only to generate ACPI tables for an I2C device.
+
+Required properties :
+
+ - compatible : "i2c-chip";
+ - reg : I2C chip address
+ - acpi,hid : HID name for the device
+
+Optional properies in addition to device.txt:
+
+ - reset-gpios : GPIO used to assert reset to the device
+ - irq-gpios : GPIO used for interrupt (if Interrupt is not used)
+ - stop-gpios : GPIO used to stop the device
+ - interrupts-extended : Interrupt to use for the device
+ - reset-delay-ms : Delay after de-asserting reset, in ms
+ - reset-off-delay-ms : Delay after asserting reset (during power off)
+ - enable-delay-ms : Delay after asserting enable
+ - enable-off-delay-ms : Delay after de-asserting enable (during power off)
+ - stop-delay-ms : Delay after de-aserting stop
+ - stop-off-delay-ms : Delay after asserting stop (during power off)
+ - hid-descr-addr : HID register offset (for Human Interface Devices)
+
+Example
+-------
+
+	elan-touchscreen@10 {
+		compatible = "i2c-chip";
+		reg = <0x10>;
+		acpi,hid = "ELAN0001";
+		acpi,ddn = "ELAN Touchscreen";
+		interrupts-extended = <&acpi_gpe GPIO_21_IRQ
+			IRQ_TYPE_EDGE_FALLING>;
+		linux,probed;
+		reset-gpios = <&gpio_n GPIO_36 GPIO_ACTIVE_HIGH>;
+		reset-delay-ms = <20>;
+		enable-gpios = <&gpio_n GPIO_152 GPIO_ACTIVE_HIGH>;
+		enable-delay-ms = <1>;
+		acpi,has-power-resource;
+	};
diff --git a/doc/device-tree-bindings/net/fsl-tsec-phy.txt b/doc/device-tree-bindings/net/fsl-tsec-phy.txt
index 8e8574b..a44c5fd 100644
--- a/doc/device-tree-bindings/net/fsl-tsec-phy.txt
+++ b/doc/device-tree-bindings/net/fsl-tsec-phy.txt
@@ -2,7 +2,7 @@
 
 Properties:
 
-  - compatible : Should be "fsl,etsec2"
+  - compatible : Should be "fsl,etsec2" or "gianfar"
   - reg : Offset and length of the register set for the device
   - phy-handle : See ethernet.txt file in the same directory.
   - phy-connection-type : See ethernet.txt file in the same directory. This
diff --git a/doc/device-tree-bindings/remoteproc/ti,k3-r5f-rproc.txt b/doc/device-tree-bindings/remoteproc/ti,k3-r5f-rproc.txt
index c2fa6e8..5708c23 100644
--- a/doc/device-tree-bindings/remoteproc/ti,k3-r5f-rproc.txt
+++ b/doc/device-tree-bindings/remoteproc/ti,k3-r5f-rproc.txt
@@ -25,6 +25,8 @@ The following are the mandatory properties:
 			                       K3 AM65x SoCs
 			    "ti,j721e-r5fss" for R5F clusters/subsystems on
 			                       K3 J721E SoCs
+			    "ti,j7200-r5fss" for R5F clusters/subsystems on
+			                       K3 J7200 SoCs
 - power-domains:	Should contain a phandle to a PM domain provider node
 			and an args specifier containing the R5FSS device id
 			value. This property is as per the binding,
@@ -56,6 +58,7 @@ The following are the mandatory properties:
 - compatible:		Should be one of the following,
 			    "ti,am654-r5f" for the R5F cores in K3 AM65x SoCs
 			    "ti,j721e-r5f" for the R5F cores in K3 J721E SOCs
+			    "ti,j7200-r5f" for the R5F cores in K3 J7200 SOCs
 - reg:			Should contain an entry for each value in 'reg-names'.
 			Each entry should have the memory region's start address
 			and the size of the region, the representation matching
@@ -79,7 +82,7 @@ The following are the mandatory properties:
 			specifier. Please refer to the following reset bindings
 			for the reset argument specifier,
 			Documentation/devicetree/bindings/reset/ti,sci-reset.txt
-			    for AM65x and J721E SoCs
+			    for AM65x, J721E and J7200 SoCs
 
 Optional properties:
 --------------------
diff --git a/doc/device-tree-bindings/soc/fsl/cpm_qe/qe/ucc.txt b/doc/device-tree-bindings/soc/fsl/cpm_qe/qe/ucc.txt
new file mode 100644
index 0000000..2758f86
--- /dev/null
+++ b/doc/device-tree-bindings/soc/fsl/cpm_qe/qe/ucc.txt
@@ -0,0 +1,53 @@
+* UCC (Unified Communications Controllers)
+
+Required properties:
+- compatible : ucc_geth
+- cell-index : the ucc number(1-8), corresponding to UCCx in UM.
+- reg : Offset and length of the register set for the device
+- rx-clock-name: the UCC receive clock source
+  "none": clock source is disabled
+  "brg1" through "brg16": clock source is BRG1-BRG16, respectively
+  "clk1" through "clk24": clock source is CLK1-CLK24, respectively
+- tx-clock-name: the UCC transmit clock source
+  "none": clock source is disabled
+  "brg1" through "brg16": clock source is BRG1-BRG16, respectively
+  "clk1" through "clk24": clock source is CLK1-CLK24, respectively
+The following two properties are deprecated.  rx-clock has been replaced
+with rx-clock-name, and tx-clock has been replaced with tx-clock-name.
+Drivers that currently use the deprecated properties should continue to
+do so, in order to support older device trees, but they should be updated
+to check for the new properties first.
+- rx-clock : represents the UCC receive clock source.
+  0x00 : clock source is disabled;
+  0x1~0x10 : clock source is BRG1~BRG16 respectively;
+  0x11~0x28: clock source is QE_CLK1~QE_CLK24 respectively.
+- tx-clock: represents the UCC transmit clock source;
+  0x00 : clock source is disabled;
+  0x1~0x10 : clock source is BRG1~BRG16 respectively;
+  0x11~0x28: clock source is QE_CLK1~QE_CLK24 respectively.
+- phy-handle : The phandle for the PHY connected to this controller.
+- phy-connection-type : a string naming the controller/PHY interface type,
+  i.e., "mii" (default), "rmii", "gmii", "rgmii", "rgmii-id" (Internal
+  Delay), "rgmii-txid" (delay on TX only), "rgmii-rxid" (delay on RX only),
+  "tbi", or "rtbi".
+- pio-handle : The phandle for the Parallel I/O port configuration.
+
+Deprecated properties:
+- device-id : the ucc number(1-8), corresponding to UCCx in UM.
+    you should use cell-index
+
+Example:
+        ucc@2000 {
+                device_type = "network";
+                compatible = "ucc_geth";
+                cell-index = <1>;
+                reg = <2000 200>;
+                interrupts = <a0 0>;
+                interrupt-parent = <700>;
+                mac-address = [ 00 04 9f 00 23 23 ];
+                rx-clock = "none";
+                tx-clock = "clk9";
+                phy-handle = <212000>;
+                phy-connection-type = "gmii";
+                pio-handle = <140001>;
+        };