Re: [PATCH] ARM: dts: ti/omap: omap4-serial: fix interrupts syntax

[Roger Quadros]

On 04/01/2025 20:20, Andreas Kemnade wrote:
> Am Sat, 4 Jan 2025 19:45:35 +0200
> schrieb Roger Quadros <rogerq@xxxxxxxxxx>:
> 
>> Hi Andreas,
>>
>> On 30/12/2024 21:55, Andreas Kemnade wrote:
>>> Usually interrupts are overwritten in the board file to specify a
>>> mux-dependent dedicated wakeup irq, so there is interrupts and
>>> interrupts-extended property which is not allowed. That has generated a
>>> lot of noise during dts changes if just a phandle involved has randomly
>>> changed.
>>>
>>> Avoid that mess by specifying interrupts-extended in the dtsi file.
>>>
>>> Signed-off-by: Andreas Kemnade <andreas@xxxxxxxxxxxx>
>>> Reported-by: Rob Herring <robh@xxxxxxxxxx>
>>> Closes: https://lore.kernel.org/linux-omap/173558214240.2262575.18233884215338168789.robh@xxxxxxxxxx/
>>> Closes: https://lore.kernel.org/linux-omap/172784021601.525825.18405282128990798038.robh@xxxxxxxxxx/
>>> ---
>>>  arch/arm/boot/dts/ti/omap/omap4-l4.dtsi | 8 ++++----
>>>  1 file changed, 4 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/arch/arm/boot/dts/ti/omap/omap4-l4.dtsi b/arch/arm/boot/dts/ti/omap/omap4-l4.dtsi
>>> index 3fcef3080eae..150dd84c9e0f 100644
>>> --- a/arch/arm/boot/dts/ti/omap/omap4-l4.dtsi
>>> +++ b/arch/arm/boot/dts/ti/omap/omap4-l4.dtsi
>>> @@ -1414,7 +1414,7 @@ SYSC_OMAP2_SOFTRESET |
>>>  			uart3: serial@0 {
>>>  				compatible = "ti,omap4-uart";
>>>  				reg = <0x0 0x100>;
>>> -				interrupts = <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>;
>>> +				interrupts-extended = <&wakeupgen GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>;  
>>
>> At this point interrupts-extended is not applicable.
>>
> we have it this way also in omap3. I do not understand what is the
> problem with it. Do you have a pointer where it is forbidden?
> At least
> Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
> says nothing againt using it in such cases.

Pasting the quoted text here for reference.

"The "interrupts-extended" property is a special form; useful when a node needs
to reference multiple interrupt parents or a different interrupt parent than
the inherited one."

I understood both were false so said that it is not applicable here.

> 
>> We could use
>> 	/delete-property/ interrupts
>> in the board files that needs multiple interrupt parents?
>>
> What is the advantage of using that more complex solution? I would then
> prefer to have the same with omap3 and omap4. If we do anything about
> interrupts in board file here, they will have multiple parents.

I was suggesting from the point to avoid churn in SoC dtsi file.
But I see your point now.

I don't have any objections.

-- 
cheers,
-roger