[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <19040354ba8.279b.9b12b7fc0a3841636cfb5e919b41b954@broadcom.com>
Date: Sat, 22 Jun 2024 15:49:13 +0200
From: Arend Van Spriel <arend.vanspriel@...adcom.com>
To: Alex Bee <knaerzche@...il.com>, Kalle Valo <kvalo@...nel.org>, <linux-wireless@...r.kernel.org>, <brcm80211@...ts.linux.dev>, <brcm80211-dev-list.pdl@...adcom.com>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] wifi: brcmfmac: of: Support interrupts-extended
On June 22, 2024 3:38:32 PM Arend Van Spriel <arend.vanspriel@...adcom.com>
wrote:
> On June 22, 2024 12:56:02 AM Alex Bee <knaerzche@...il.com> wrote:
>
>> This "new" version of defining external interrupts is around for a very
>> long time now and supported and preferred by irq_of_parse_and_map
>> respectively of_irq_parse_one.
>>
>> Support it in brcmfmac as well by checking if either "interrupts" or
>> "interrupts-extended" property exists as indication if irq_of_parse_and_map
>> should be called.
>
> All very interesting, but why should we add code for something that is not
> specified in the bindings documentation?
>
> NAK (for now). Feel free to update the bindings document.
So looked up the interrupts-extended definition:
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. Each entry in this property contains both the parent phandle
and the interrupt specifier.
Given that brcmfmac device will only have one interrupt item defined there
is no need to use it. If someone can give a good argument to support it
please chime in.
Regards,
Arend
Download attachment "smime.p7s" of type "application/pkcs7-signature" (4219 bytes)
Powered by blists - more mailing lists