[PATCH v2] dt-bindings: xilinx: Remove EDK/Ethernet references

[Pandey, Radhey Shyam]

> The latest EDK version was 14.7 released in 2013 that's why remove
> description for it. Also remove generic description for Ethernet which
> doesn't bring any value.
> 
> Signed-off-by: Michal Simek <michal.simek at amd.com>

Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey at amd.com>
Thanks!

> ---
> 
> Changes in v2:
> - Update description for additional bindings - reported by Sashiko
> 
>   Documentation/devicetree/bindings/xilinx.txt | 98 +-------------------
>   1 file changed, 1 insertion(+), 97 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/xilinx.txt b/Documentation/devicetree/bindings/xilinx.txt
> index 0ee9de99b3ae..a1a2cde7b7d8 100644
> --- a/Documentation/devicetree/bindings/xilinx.txt
> +++ b/Documentation/devicetree/bindings/xilinx.txt
> @@ -1,93 +1,4 @@
> -   d) Xilinx IP cores
> -
> -   The Xilinx EDK toolchain ships with a set of IP cores (devices) for use
> -   in Xilinx Spartan and Virtex FPGAs.  The devices cover the whole range
> -   of standard device types (network, serial, etc.) and miscellaneous
> -   devices (gpio, LCD, spi, etc).  Also, since these devices are
> -   implemented within the fpga fabric every instance of the device can be
> -   synthesised with different options that change the behaviour.
> -
> -   Each IP-core has a set of parameters which the FPGA designer can use to
> -   control how the core is synthesized.  Historically, the EDK tool would
> -   extract the device parameters relevant to device drivers and copy them
> -   into an 'xparameters.h' in the form of #define symbols.  This tells the
> -   device drivers how the IP cores are configured, but it requires the kernel
> -   to be recompiled every time the FPGA bitstream is resynthesized.
> -
> -   The new approach is to export the parameters into the device tree and
> -   generate a new device tree each time the FPGA bitstream changes.  The
> -   parameters which used to be exported as #defines will now become
> -   properties of the device node.  In general, device nodes for IP-cores
> -   will take the following form:
> -
> -	(name): (generic-name)@(base-address) {
> -		compatible = "xlnx,(ip-core-name)-(HW_VER)"
> -			     [, (list of compatible devices), ...];
> -		reg = <(baseaddr) (size)>;
> -		interrupt-parent = <&interrupt-controller-phandle>;
> -		interrupts = < ... >;
> -		xlnx,(parameter1) = "(string-value)";
> -		xlnx,(parameter2) = <(int-value)>;
> -	};
> -
> -	(generic-name):   an open firmware-style name that describes the
> -			generic class of device.  Preferably, this is one word, such
> -			as 'serial' or 'ethernet'.
> -	(ip-core-name):	the name of the ip block (given after the BEGIN
> -			directive in system.mhs).  Should be in lowercase
> -			and all underscores '_' converted to dashes '-'.
> -	(name):		is derived from the "PARAMETER INSTANCE" value.
> -	(parameter#):	C_* parameters from system.mhs.  The C_ prefix is
> -			dropped from the parameter name, the name is converted
> -			to lowercase and all underscore '_' characters are
> -			converted to dashes '-'.
> -	(baseaddr):	the baseaddr parameter value (often named C_BASEADDR).
> -	(HW_VER):	from the HW_VER parameter.
> -	(size):		the address range size (often C_HIGHADDR - C_BASEADDR + 1).
> -
> -   Typically, the compatible list will include the exact IP core version
> -   followed by an older IP core version which implements the same
> -   interface or any other device with the same interface.
> -
> -   'reg' and 'interrupts' are all optional properties.
> -
> -   For example, the following block from system.mhs:
> -
> -	BEGIN opb_uartlite
> -		PARAMETER INSTANCE = opb_uartlite_0
> -		PARAMETER HW_VER = 1.00.b
> -		PARAMETER C_BAUDRATE = 115200
> -		PARAMETER C_DATA_BITS = 8
> -		PARAMETER C_ODD_PARITY = 0
> -		PARAMETER C_USE_PARITY = 0
> -		PARAMETER C_CLK_FREQ = 50000000
> -		PARAMETER C_BASEADDR = 0xEC100000
> -		PARAMETER C_HIGHADDR = 0xEC10FFFF
> -		BUS_INTERFACE SOPB = opb_7
> -		PORT OPB_Clk = CLK_50MHz
> -		PORT Interrupt = opb_uartlite_0_Interrupt
> -		PORT RX = opb_uartlite_0_RX
> -		PORT TX = opb_uartlite_0_TX
> -		PORT OPB_Rst = sys_bus_reset_0
> -	END
> -
> -   becomes the following device tree node:
> -
> -	opb_uartlite_0: serial at ec100000 {
> -		device_type = "serial";
> -		compatible = "xlnx,opb-uartlite-1.00.b";
> -		reg = <ec100000 10000>;
> -		interrupt-parent = <&opb_intc_0>;
> -		interrupts = <1 0>; // got this from the opb_intc parameters
> -		current-speed = <d#115200>;	// standard serial device prop
> -		clock-frequency = <d#50000000>;	// standard serial device prop
> -		xlnx,data-bits = <8>;
> -		xlnx,odd-parity = <0>;
> -		xlnx,use-parity = <0>;
> -	};
> -
> -   That covers the general approach to binding xilinx IP cores into the
> -   device tree.  The following are bindings for specific devices:
> +   Bindings for specific devices:
>   
>         i) Xilinx ML300 Framebuffer
>   
> @@ -102,13 +13,6 @@
>                                              Default is <d#1024 d#480>.
>          - rotate-display (empty) : rotate display 180 degrees.
>   
> -      iii) Xilinx EMAC and Xilinx TEMAC
> -
> -      Xilinx Ethernet devices.  In addition to general xilinx properties
> -      listed above, nodes for these devices should include a phy-handle
> -      property, and may include other common network device properties
> -      like local-mac-address.
> -
>         v) Xilinx hwicap
>   
>   		Xilinx hwicap devices provide access to the configuration logic
> ---
> base-commit: f608bce703fc31a2cdf67abe1de882d5bbc45142
> branch: zynqmp/dt
>