[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6250c57b-6d38-4085-9a79-58e4e5ed1e3d@linaro.org>
Date: Sun, 3 Dec 2023 16:04:58 +0100
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: James Tai [戴志峰] <james.tai@...ltek.com>,
Thomas Gleixner <tglx@...utronix.de>,
Marc Zyngier <maz@...nel.org>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Conor Dooley <conor+dt@...nel.org>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: [PATCH v2 1/6] dt-bindings: interrupt-controller: Add support for
Realtek DHC SoCs
On 02/12/2023 17:18, James Tai [戴志峰] wrote:
> Hi Krzysztof,
>
>>>> +
>>>> + compatible:
>>>> + enum:
>>>> + - realtek,rtd1319-intc-iso
>>>> + - realtek,rtd1319-intc-misc
>>>> +
>>>> + "#address-cells":
>>>> + const: 0
>>>> +
>>>> + interrupt-controller: true
>>>> +
>>>> + interrupts-extended:
>>>
>>> interrupts instead.
>>>
>>> Anyway, you must describe the items. Why this is not fixed but flexible?
>>> Hardware has different number of pins? That's unlikely.
>>>
>> I will replace it with 'interrupts'. Since our Interrupt controller architecture
>> doesn't involve multiple interrupt sources, using 'interrupts' should suffice.
>>
>
> Due to changes in hardware design, some peripheral interrupts pin initially connected to the Realtek interrupt controller were redirected to the GIC.
> However, the associated fields and statuses in the Realtek interrupt controller registers were not removed.
> As a result, these interrupts cannot be cleared by peripheral register, and their status clearing is still needing the Realtek interrupt controller driver to manage.
>
> That's why flexibility is necessary.
This does not explain why this is not fixed per variant.
Best regards,
Krzysztof
Powered by blists - more mailing lists