On 01/10/2014 10:03 AM, Gerhard Sittig wrote: > On Fri, Jan 10, 2014 at 09:30 -0600, Rob Herring wrote: >> >> As for *.h vs. *.dtsi naming, if the include is only pre-processor >> defines, then I think using .h is the right way. Otherwise, if there >> is any dts syntax, then .dtsi is the right name. It looks to me like >> this style has been followed in both the imx and s3c64xx cases. >> >> On a side note, I'm not really a fan of this pattern: >> >> #define FOO1 1 2 3 >> >> #define BAR FOO1 FOO2 FOO3 >> >> While it definitely simplifies the dts files, it would never be used >> in C and obfuscates what the actual property size is. Reading a dts >> file, I would naturally assume the define was a single value while in >> fact it could expand to a very large property size. > > For more complex yet tedious repetitive cases like GPIO banks and > pins I've seen #define directives which introduce "functions" > (macros with parameters). They appear to be rather useful, can > reflect very well the essence of the information, don't > necessarily pretend to be single values, but still may hide how > many cells they expand to. For example: > > arch/arm/boot/dts/tegra30-cardhu.dtsi: > interrupts = <TEGRA_GPIO(L, 0) IRQ_TYPE_LEVEL_HIGH>; I'm not sure I entirely understand your point, but for the record, both TEGRA_GPIO() and IRQ_TYPE_LEVEL_HIGH expand to a single cell, as I would expect (almost?) any DT macro to do. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html