removing of some unused/unsupported dts entries

Hi,

I have found some dts entries which are not evaluated by the drivers. This patch remove this entries from the dts files.
Jason has mentioned I should CC: Thomas, Marc and him self to this mails.

thanks and best regards,
Silvio

Silvio Fricke (3):
ARM: mx5: dts: remove unused irq-trigger entry
ARM: tegra: dts: remove unused irq-trigger entry
ARM: SPEAr: dts: remove unused irq-trigger, id and block entries

 arch/arm/boot/dts/imx53-m53.dtsi      | 1 -
 arch/arm/boot/dts/spear1310-evb.dts   | 1 -
 arch/arm/boot/dts/spear1340-evb.dts   | 2 --
 arch/arm/boot/dts/spear320-hmi.dts    | 3 ---
 arch/arm/boot/dts/tegra30-apalis.dtsi | 1 -
 5 files changed, 8 deletions(-)

2.1.3

---
 arch/arm/boot/dts/imx53-m53.dtsi | 1 -
 1 file changed, 1 deletion(-)

index 87a7fc7..8a5acb5 100644
@@ -60,7 +60,6 @@
 		blocks = <0x5>;
 		interrupts = <6 0x0>;
 		interrupt-parent = <&gpio7>;
-		irq-trigger = <0x1>;
 
 		stmpe_touchscreen {
 			compatible = "st,stmpe-ts";

2.1.3

---
 arch/arm/boot/dts/tegra30-apalis.dtsi | 1 -
 1 file changed, 1 deletion(-)

index a5446cb..c2a7528 100644
@@ -540,7 +540,6 @@
 			interrupt-controller;
 			id = <0>;
 			blocks = <0x5>;
-			irq-trigger = <0x1>;
 
 			stmpe_touchscreen {
 				compatible = "st,stmpe-ts";

2.1.3

---
 arch/arm/boot/dts/spear1310-evb.dts | 1 -
 arch/arm/boot/dts/spear1340-evb.dts | 2 --
 arch/arm/boot/dts/spear320-hmi.dts  | 3 ---
 3 files changed, 6 deletions(-)

index d42c84b..95c2ff1 100644
@@ -369,7 +369,6 @@
 					pl022,duplex = <0>;
 					interrupts = <6 0x4>;
 					interrupt-parent = <&gpio1>;
-					irq-trigger = <0x2>;
 
 					stmpe_touchscreen {
 						compatible = "st,stmpe-ts";

index b23e05e..bba3389 100644
@@ -325,7 +325,6 @@
 					reg = <0x41>;
 					interrupts = <4 0x4>;
 					interrupt-parent = <&gpio0>;
-					irq-trigger = <0x2>;
 
 					stmpegpio: stmpe_gpio {
 						compatible = "st,stmpe-gpio";

@@ -478,7 +477,6 @@
 					pl022,duplex = <0>;
 					interrupts = <100 0>;
 					interrupt-parent = <&gpiopinctrl>;
-					irq-trigger = <0x2>;
 					#address-cells = <1>;
 					#size-cells = <0>;
 

index 0aa6fef..f8ed01e 100644
@@ -243,9 +243,6 @@
 					reg = <0x41>;
 					irq-over-gpio;
 					irq-gpios = <&gpiopinctrl 29 0x4>;
-					id = <0>;
-					blocks = <0x5>;
-					irq-trigger = <0x1>;
 
 					stmpegpio: stmpe-gpio {
 						compatible = "stmpe,gpio";

2.1.3

On Sat, Dec 13 2014 at 1:46:45 am GMT, Silvio Fricke <[email protected]> wrote:

Hi Silvio,

As far as I can tell, this looks correct. A few key things though:

- Please write decent commit logs. Indicate *why* you think these properties can be removed (hint: not finding corresponding in the drivers is not enough a reason, the binding itself matters).

- Spend two minutes looking at the ML archives, and try to find why we ended-up with these orphan properties (something like this:
https://lists.ozlabs.org/pipermail/devicetree-discuss/2012-November/023482.html
contains useful historical information).

- Cc the relevant platform maintainers. You're changing things that they care about, basic courtesy is to keep them in the loop.

All of this will help maintainers to quickly decide on the fate of these patches.

Thanks,

	M.

Without deviation from the norm, progress is not possible.

Silvio, Marc,

Right. The real issue is the state of these properties within the binding documentation. Linux isn't the only consumer of these dts files (*BSD, barebox, etc), so us not using them doesn't necessarily mean the property should be removed.

The most important lesson (recently learned ;-) ) is to make sure all properties are accurately describing the *hardware*. Not Linux's implementation of talking to the hardware. That'll go a long way if the changelog discusses how property X is an implementation detail vice a hardware characteristic or feature.

True. In Silvio's defense, I just told him to Cc us to get the ball rolling. (I tend to dislike long discussions on chat mediums, I'd much rather they be in email. So I was definitely too succinct).

For the record, you can use ./scripts/get_maintainer.pl on your patches to make sure you get most of the right people. In this case, that'll include the DT maintainers. You may want to run a get_maintainer.pl -f arch/arm/mach-$ARCH for each of the dts file you touch. Those maintainers usually wrangle the patches for their dts files. Unfortunately, not all of them have updated MAINTAINERS (<cough>mvebu<cough>) to include the dts file patterns.

thx,

Jason.