[PATCH v5 0/5] Add device tree data for AM33XX devices

[PATCH v5 0/5] Add device tree data for AM33XX devices

[AnilKumar Ch]

Add pinctrl and d_can device tree data to AM33XX family of devices.
First two patches add support for pinctrl DT data and third one
adds dcan DT data.

Reason behind combining these patches is to apply cleanly on
linux-omap tree, because these are sequential patches.

These patches were tested on AM335x-Bone, AM335x-EVM and based
on linux-omap:master with this patch
http://www.mail-archive.com/linux-omap at vger.kernel.org/msg74393.html

d_can:
  Changes from v4:
	- Incorporated Tony's comments on v4
	  * Converted all hex numbers to lower-case.
	- Updated C_CAN bindings documentation according to recent
	  changes.

  Changes from v3:
	- Removed d_can1 node from am335x-evm.dts file. Instance
	  one of CAN (d_can1) is available on AM335x-EVM only under
	  a specific CPLD mode selection. am335x-evm.dts does not
          support this mode so remove the d_can1 node.
	- Dropped d_can pinmux settings patch, above comment
	  applies here as well.

  Changes from v2:
	- Incorporated Vaibhav H's comments on v2
	  * Added dcan0 instances to am33xx.dtsi file

  Changes from v1:
	- These two patches separated from c_can DT support
	  patch series.

pinctrl:
  Changes from v4:
	- Incorporated Tony's comments on v4
	  * Converted all hex numbers to lower-case.
	- Added pinctrl api to leds-gpio driver to configure led
	  pins to GPIO mode.

  Changes from v3:
	- Updated the reg length based on latest AM335x TRM.

  Changes from v2:
	- user led pinmux comments updated according to Tony's
	  comment.

  Changes from v1:
	- Rebased the patches based on latest pinctrl-single driver

AnilKumar Ch (5):
  arm/dts: AM33XX: Add basic pinctrl device tree data
  arm/dts: AM33XX: Configure pinmuxs for user leds control on Bone
  arm/dts: AM33XX: Add D_CAN device tree data
  leds: leds-gpio: adopt pinctrl support
  of: Modify c_can binding documentation

 .../devicetree/bindings/net/can/c_can.txt          |   25 +++++++++---
 arch/arm/boot/dts/am335x-bone.dts                  |   41 ++++++++++++++++++++
 arch/arm/boot/dts/am33xx.dtsi                      |   27 +++++++++++++
 drivers/leds/leds-gpio.c                           |   31 +++++++++++----
 4 files changed, 112 insertions(+), 12 deletions(-)

-- 
1.7.9.5

[PATCH v5 1/5] arm/dts: AM33XX: Add basic pinctrl device tree data

[AnilKumar Ch]

Adds basic pinctrl device tree data for AM33XX family of devices.
This patch is based on the pinctrl-single driver.

Signed-off-by: AnilKumar Ch <anilkumar@ti.com>
---
 arch/arm/boot/dts/am33xx.dtsi |    9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index be43511..bf5f713 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -40,6 +40,15 @@
 		};
 	};
 
+	am3358_pinmux: pinmux at 44e10800 {
+		compatible = "pinctrl-single";
+		reg = <0x44e10800 0x0238>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		pinctrl-single,register-width = <32>;
+		pinctrl-single,function-mask = <0x7f>;
+	};
+
 	/*
 	 * XXX: Use a flat representation of the AM33XX interconnect.
 	 * The real AM33XX interconnect network is quite complex.Since
-- 
1.7.9.5

[PATCH v5 1/5] arm/dts: AM33XX: Add basic pinctrl device tree data

[Tony Lindgren]

* AnilKumar Ch <anilkumar@ti.com> [120831 02:30]:
> Adds basic pinctrl device tree data for AM33XX family of devices.
> This patch is based on the pinctrl-single driver.
> 
> Signed-off-by: AnilKumar Ch <anilkumar@ti.com>
> ---
>  arch/arm/boot/dts/am33xx.dtsi |    9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> index be43511..bf5f713 100644
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -40,6 +40,15 @@
>  		};
>  	};
>  
> +	am3358_pinmux: pinmux at 44e10800 {
> +		compatible = "pinctrl-single";
> +		reg = <0x44e10800 0x0238>;
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		pinctrl-single,register-width = <32>;
> +		pinctrl-single,function-mask = <0x7f>;
> +	};
> +

Is this controller the same for all am33xx? If so, please use
am33xx_pinmux naming. Note that some padconf registers may not
be listed for all the variants, but the registers may still be
there for all the variants. So a generic entry is a better
choice here as otherwise you'l need to include am33xx.dtsi into
am3358.dtsi.

Regards,

Tony

[PATCH v5 1/5] arm/dts: AM33XX: Add basic pinctrl device tree data

[AnilKumar, Chimata]

On Thu, Sep 06, 2012 at 05:02:05, Tony Lindgren wrote:
> * AnilKumar Ch <anilkumar@ti.com> [120831 02:30]:
> > Adds basic pinctrl device tree data for AM33XX family of devices.
> > This patch is based on the pinctrl-single driver.
> > 
> > Signed-off-by: AnilKumar Ch <anilkumar@ti.com>
> > ---
> >  arch/arm/boot/dts/am33xx.dtsi |    9 +++++++++
> >  1 file changed, 9 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> > index be43511..bf5f713 100644
> > --- a/arch/arm/boot/dts/am33xx.dtsi
> > +++ b/arch/arm/boot/dts/am33xx.dtsi
> > @@ -40,6 +40,15 @@
> >  		};
> >  	};
> >  
> > +	am3358_pinmux: pinmux at 44e10800 {
> > +		compatible = "pinctrl-single";
> > +		reg = <0x44e10800 0x0238>;
> > +		#address-cells = <1>;
> > +		#size-cells = <0>;
> > +		pinctrl-single,register-width = <32>;
> > +		pinctrl-single,function-mask = <0x7f>;
> > +	};
> > +
> 
> Is this controller the same for all am33xx? If so, please use
> am33xx_pinmux naming. Note that some padconf registers may not
> be listed for all the variants, but the registers may still be
> there for all the variants. So a generic entry is a better
> choice here as otherwise you'l need to include am33xx.dtsi into
> am3358.dtsi.
> 

Controller is same for all am33xx devices, I will spin a patch
by renaming to am33xx_****

Thanks
AnilKumar

[PATCH v5 2/5] arm/dts: AM33XX: Configure pinmuxs for user leds control on Bone

[AnilKumar Ch]

Adds GPIO pinctrl nodes to am3358_pinmux master node to control
user leds (USR0, USR1, USR2 and USR3) present on BeagleBone.

Signed-off-by: AnilKumar Ch <anilkumar@ti.com>
---
 arch/arm/boot/dts/am335x-bone.dts |   41 +++++++++++++++++++++++++++++++++++++
 1 file changed, 41 insertions(+)

diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts
index c634f87..ce486fc 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -18,11 +18,52 @@
 		reg = <0x80000000 0x10000000>; /* 256 MB */
 	};
 
+	am3358_pinmux: pinmux at 44e10800 {
+		userled_pins: pinmux_userled_pins {
+			pinctrl-single,pins = <
+				0x54 0x7	/* gpmc_a5.gpio1_21, OUTPUT | MODE7 */
+				0x58 0x17	/* gpmc_a6.gpio1_22, OUTPUT_PULLUP | MODE7 */
+				0x5c 0x7	/* gpmc_a7.gpio1_23, OUTPUT | MODE7 */
+				0x60 0x17	/* gpmc_a8.gpio1_24, OUTPUT_PULLUP | MODE7 */
+			>;
+		};
+	};
+
 	ocp {
 		uart1: serial at 44e09000 {
 			status = "okay";
 		};
 
+		gpio-leds {
+			compatible = "gpio-leds";
+			pinctrl-names = "default";
+			pinctrl-0 = <&userled_pins>;
+
+			led0 {
+				label = "status:green:user0";
+				gpios = <&gpio2 21 0>;
+				default-state = "off";
+			};
+
+			led1 {
+				label = "status:green:user1";
+				gpios = <&gpio2 22 0>;
+				default-state = "off";
+			};
+
+			led2 {
+				label = "status:green:user2";
+				gpios = <&gpio2 23 0>;
+				default-state = "off";
+			};
+
+			led3 {
+				label = "status:green:user3";
+				gpios = <&gpio2 24 0>;
+				default-state = "off";
+			};
+		};
+
 		i2c1: i2c at 44e0b000 {
 			status = "okay";
 			clock-frequency = <400000>;
-- 
1.7.9.5

[PATCH v5 3/5] arm/dts: AM33XX: Add D_CAN device tree data

[AnilKumar Ch]

Add Bosch D_CAN controller device tree data to AM33XX dtsi
file by adding d_can device nodes with all the necessary
parameters.

Signed-off-by: AnilKumar Ch <anilkumar@ti.com>
---
 arch/arm/boot/dts/am33xx.dtsi |   18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index bf5f713..ab744d6 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -177,5 +177,23 @@
 			compatible = "ti,omap3-wdt";
 			ti,hwmods = "wd_timer2";
 		};
+
+		dcan0: d_can at 481cc000 {
+			compatible = "bosch,d_can";
+			ti,hwmods = "d_can0";
+			reg = <0x481cc000 0x2000>;
+			interrupts = <52>;
+			interrupt-parent = <&intc>;
+			status = "disabled";
+		};
+
+		dcan1: d_can at 481d0000 {
+			compatible = "bosch,d_can";
+			ti,hwmods = "d_can1";
+			reg = <0x481d0000 0x2000>;
+			interrupts = <55>;
+			interrupt-parent = <&intc>;
+			status = "disabled";
+		};
 	};
 };
-- 
1.7.9.5

[PATCH 4/5] leds: leds-gpio: adopt pinctrl support

[AnilKumar Ch]

Adopt pinctrl support to leds-gpio driver, based on the device
pointer (leds-gpio) pinctrl driver configure SoC pins to GPIO
mode.

Signed-off-by: AnilKumar Ch <anilkumar@ti.com>
---
 drivers/leds/leds-gpio.c |   31 ++++++++++++++++++++++++-------
 1 file changed, 24 insertions(+), 7 deletions(-)

diff --git a/drivers/leds/leds-gpio.c b/drivers/leds/leds-gpio.c
index c032b21..d98dfb9 100644
--- a/drivers/leds/leds-gpio.c
+++ b/drivers/leds/leds-gpio.c
@@ -20,6 +20,7 @@
 #include <linux/slab.h>
 #include <linux/workqueue.h>
 #include <linux/module.h>
+#include <linux/pinctrl/consumer.h>
 
 struct gpio_led_data {
 	struct led_classdev cdev;
@@ -236,14 +237,23 @@ static int __devinit gpio_led_probe(struct platform_device *pdev)
 {
 	struct gpio_led_platform_data *pdata = pdev->dev.platform_data;
 	struct gpio_leds_priv *priv;
-	int i, ret = 0;
+	struct pinctrl *pinctrl;
+	int i = 0;
+	int ret = 0;
+
+	pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
+	if (IS_ERR(pinctrl)) {
+		return PTR_ERR(pinctrl);
+	}
 
 	if (pdata && pdata->num_leds) {
 		priv = devm_kzalloc(&pdev->dev,
 				sizeof_gpio_leds_priv(pdata->num_leds),
 					GFP_KERNEL);
-		if (!priv)
-			return -ENOMEM;
+		if (!priv) {
+			ret = -ENOMEM;
+			goto err_pctrl_put;
+		}
 
 		priv->num_leds = pdata->num_leds;
 		for (i = 0; i < priv->num_leds; i++) {
@@ -254,18 +264,25 @@ static int __devinit gpio_led_probe(struct platform_device *pdev)
 				/* On failure: unwind the led creations */
 				for (i = i - 1; i >= 0; i--)
 					delete_gpio_led(&priv->leds[i]);
-				return ret;
+				goto err_pctrl_put;
 			}
 		}
 	} else {
 		priv = gpio_leds_create_of(pdev);
-		if (!priv)
-			return -ENODEV;
+		if (!priv) {
+			ret = -ENODEV;
+			goto err_del_gpio_led;
+		}
 	}
 
 	platform_set_drvdata(pdev, priv);
 
-	return 0;
+err_pctrl_put:
+	pinctrl_put(pinctrl);
+err_del_gpio_led:
+	while (--i >= 0)
+		delete_gpio_led(&priv->leds[i]);
+	return ret;
 }
 
 static int __devexit gpio_led_remove(struct platform_device *pdev)
-- 
1.7.9.5

[PATCH 4/5] leds: leds-gpio: adopt pinctrl support

[Tony Lindgren]

* AnilKumar Ch <anilkumar@ti.com> [120831 02:30]:
> Adopt pinctrl support to leds-gpio driver, based on the device
> pointer (leds-gpio) pinctrl driver configure SoC pins to GPIO
> mode.
> 
> Signed-off-by: AnilKumar Ch <anilkumar@ti.com>
> ---
>  drivers/leds/leds-gpio.c |   31 ++++++++++++++++++++++++-------
>  1 file changed, 24 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/leds/leds-gpio.c b/drivers/leds/leds-gpio.c
> index c032b21..d98dfb9 100644
> --- a/drivers/leds/leds-gpio.c
> +++ b/drivers/leds/leds-gpio.c
> @@ -20,6 +20,7 @@
>  #include <linux/slab.h>
>  #include <linux/workqueue.h>
>  #include <linux/module.h>
> +#include <linux/pinctrl/consumer.h>
>  
>  struct gpio_led_data {
>  	struct led_classdev cdev;
> @@ -236,14 +237,23 @@ static int __devinit gpio_led_probe(struct platform_device *pdev)
>  {
>  	struct gpio_led_platform_data *pdata = pdev->dev.platform_data;
>  	struct gpio_leds_priv *priv;
> -	int i, ret = 0;
> +	struct pinctrl *pinctrl;
> +	int i = 0;
> +	int ret = 0;
> +
> +	pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
> +	if (IS_ERR(pinctrl)) {
> +		return PTR_ERR(pinctrl);
> +	}

I think you need to just print out a warning here as most systems don't
have the pinctrl implemented. And some people just do static pinmuxing
in the bootloader.

Regards,

Tony

[PATCH 4/5] leds: leds-gpio: adopt pinctrl support

[AnilKumar, Chimata]

Hi Tony,

Thanks for the review,

On Fri, Aug 31, 2012 at 21:34:04, Tony Lindgren wrote:
> * AnilKumar Ch <anilkumar@ti.com> [120831 02:30]:
> > Adopt pinctrl support to leds-gpio driver, based on the device
> > pointer (leds-gpio) pinctrl driver configure SoC pins to GPIO
> > mode.
> > 
> > Signed-off-by: AnilKumar Ch <anilkumar@ti.com>
> > ---
> >  drivers/leds/leds-gpio.c |   31 ++++++++++++++++++++++++-------
> >  1 file changed, 24 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/leds/leds-gpio.c b/drivers/leds/leds-gpio.c
> > index c032b21..d98dfb9 100644
> > --- a/drivers/leds/leds-gpio.c
> > +++ b/drivers/leds/leds-gpio.c
> > @@ -20,6 +20,7 @@
> >  #include <linux/slab.h>
> >  #include <linux/workqueue.h>
> >  #include <linux/module.h>
> > +#include <linux/pinctrl/consumer.h>
> >  
> >  struct gpio_led_data {
> >  	struct led_classdev cdev;
> > @@ -236,14 +237,23 @@ static int __devinit gpio_led_probe(struct platform_device *pdev)
> >  {
> >  	struct gpio_led_platform_data *pdata = pdev->dev.platform_data;
> >  	struct gpio_leds_priv *priv;
> > -	int i, ret = 0;
> > +	struct pinctrl *pinctrl;
> > +	int i = 0;
> > +	int ret = 0;
> > +
> > +	pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
> > +	if (IS_ERR(pinctrl)) {
> > +		return PTR_ERR(pinctrl);
> > +	}
> 
> I think you need to just print out a warning here as most systems don't
> have the pinctrl implemented. And some people just do static pinmuxing
> in the bootloader.
> 

Yes, that is better approach I will fix this in my next version.
I will separate out this patch from the series because these changes are
leds-gpio driver specific which are different from DT data (pinctrl and
d_can).

Thanks
AnilKumar

[PATCH 5/5] of: Modify c_can binding documentation

[AnilKumar Ch]

Modify c_can binding documentation according to recent review comments
on device tree data addition patches.

Signed-off-by: AnilKumar Ch <anilkumar@ti.com>
---
 .../devicetree/bindings/net/can/c_can.txt          |   25 ++++++++++++++++----
 1 file changed, 20 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/can/c_can.txt b/Documentation/devicetree/bindings/net/can/c_can.txt
index a43f083..90a70be 100644
--- a/Documentation/devicetree/bindings/net/can/c_can.txt
+++ b/Documentation/devicetree/bindings/net/can/c_can.txt
@@ -8,6 +8,8 @@ Required properties:
 			  registers map
 - interrupts		: property with a value describing the interrupt
 			  number
+- status		: describes the node status either "disabled" or
+			  "okay"
 
 Optional properties:
 - interrupt-parent	: The parent interrupt controller
@@ -20,18 +22,31 @@ Future plan is to migrate hwmod data base contents into device tree
 blob so that, all the required data will be used from device tree dts
 file.
 
-Examples:
+Example:
 
-	d_can at 481D0000 {
+Step1: SoC common .dtsi file
+
+	d_can1: d_can at 481d0000 {
 		compatible = "bosch,d_can";
-		reg = <0x481D0000 0x1000>;
-		interrupts = <55 0x4>;
+		reg = <0x481d0000 0x2000>;
+		interrupts = <55>;
 		interrupt-parent = <&intc>;
+		status = "disabled";
 	};
 
 (or)
 
-	d_can at 481D0000 {
+	d_can1: d_can at 481d0000 {
 		compatible = "bosch,d_can";
 		ti,hwmods = "d_can1";
+		reg = <0x481d0000 0x2000>;
+		interrupts = <55>;
+		interrupt-parent = <&intc>;
+		status = "disabled";
+	};
+
+Step 2: board specific .dts file
+
+	&dcan1 {
+		status = "okay";
 	};
-- 
1.7.9.5

[PATCH 5/5] of: Modify c_can binding documentation

[AnilKumar, Chimata]

Hi Marc,

On Fri, Aug 31, 2012 at 14:59:21, AnilKumar, Chimata wrote:
> Modify c_can binding documentation according to recent review comments
> on device tree data addition patches.
> 
> Signed-off-by: AnilKumar Ch <anilkumar@ti.com>
> ---
>  .../devicetree/bindings/net/can/c_can.txt          |   25 ++++++++++++++++----
>  1 file changed, 20 insertions(+), 5 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/net/can/c_can.txt b/Documentation/devicetree/bindings/net/can/c_can.txt
> index a43f083..90a70be 100644
> --- a/Documentation/devicetree/bindings/net/can/c_can.txt
> +++ b/Documentation/devicetree/bindings/net/can/c_can.txt
> @@ -8,6 +8,8 @@ Required properties:
>  			  registers map
>  - interrupts		: property with a value describing the interrupt
>  			  number
> +- status		: describes the node status either "disabled" or
> +			  "okay"
>  
>  Optional properties:
>  - interrupt-parent	: The parent interrupt controller
> @@ -20,18 +22,31 @@ Future plan is to migrate hwmod data base contents into device tree
>  blob so that, all the required data will be used from device tree dts
>  file.
>  
> -Examples:
> +Example:
>  
> -	d_can at 481D0000 {
> +Step1: SoC common .dtsi file
> +
> +	d_can1: d_can at 481d0000 {
>  		compatible = "bosch,d_can";
> -		reg = <0x481D0000 0x1000>;
> -		interrupts = <55 0x4>;
> +		reg = <0x481d0000 0x2000>;
> +		interrupts = <55>;
>  		interrupt-parent = <&intc>;
> +		status = "disabled";
>  	};
>  
>  (or)
>  
> -	d_can at 481D0000 {
> +	d_can1: d_can at 481d0000 {
>  		compatible = "bosch,d_can";
>  		ti,hwmods = "d_can1";
> +		reg = <0x481d0000 0x2000>;
> +		interrupts = <55>;
> +		interrupt-parent = <&intc>;
> +		status = "disabled";
> +	};
> +
> +Step 2: board specific .dts file
> +
> +	&dcan1 {
> +		status = "okay";
>  	};
> -- 
> 1.7.9.5
> 
> 

Can you review this patch and push it to linux-can tree?
Because initial version of this file c_can.txt is in
linux-can tree.

Thanks
AnilKumar

[PATCH 5/5] of: Modify c_can binding documentation

[Stephen Warren]

On 09/01/2012 12:05 AM, AnilKumar, Chimata wrote:
> On Fri, Aug 31, 2012 at 14:59:21, AnilKumar, Chimata wrote:
>> Modify c_can binding documentation according to recent review comments
>> on device tree data addition patches.

>> diff --git a/Documentation/devicetree/bindings/net/can/c_can.txt b/Documentation/devicetree/bindings/net/can/c_can.txt
>> index a43f083..90a70be 100644
>> --- a/Documentation/devicetree/bindings/net/can/c_can.txt
>> +++ b/Documentation/devicetree/bindings/net/can/c_can.txt
>> @@ -8,6 +8,8 @@ Required properties:
>>  			  registers map
>>  - interrupts		: property with a value describing the interrupt
>>  			  number
>> +- status		: describes the node status either "disabled" or
>> +			  "okay"

That's a standrd property that applies to any node, and doesn't describe
data required by the device itself (as do regs/interrupts) by simply
whether the node is activated; I'm not sure it's worth mentioning it in
a device-specific binding.

A similar comment exists for the pre-existing description of
interrupt-parent below.

>>  Optional properties:
>>  - interrupt-parent	: The parent interrupt controller

[PATCH 5/5] of: Modify c_can binding documentation

[AnilKumar, Chimata]

Hi Stephen,

Thanks for the review,

On Sun, Sep 02, 2012 at 07:32:38, Stephen Warren wrote:
> On 09/01/2012 12:05 AM, AnilKumar, Chimata wrote:
> > On Fri, Aug 31, 2012 at 14:59:21, AnilKumar, Chimata wrote:
> >> Modify c_can binding documentation according to recent review comments
> >> on device tree data addition patches.
> 
> >> diff --git a/Documentation/devicetree/bindings/net/can/c_can.txt b/Documentation/devicetree/bindings/net/can/c_can.txt
> >> index a43f083..90a70be 100644
> >> --- a/Documentation/devicetree/bindings/net/can/c_can.txt
> >> +++ b/Documentation/devicetree/bindings/net/can/c_can.txt
> >> @@ -8,6 +8,8 @@ Required properties:
> >>  			  registers map
> >>  - interrupts		: property with a value describing the interrupt
> >>  			  number
> >> +- status		: describes the node status either "disabled" or
> >> +			  "okay"
> 
> That's a standrd property that applies to any node, and doesn't describe
> data required by the device itself (as do regs/interrupts) by simply
> whether the node is activated; I'm not sure it's worth mentioning it in
> a device-specific binding.
> 
> A similar comment exists for the pre-existing description of
> interrupt-parent below.
> 
> >>  Optional properties:
> >>  - interrupt-parent	: The parent interrupt controller
> 

Then, I will remove these properties from the doc.

Thanks
AnilKumar