Search Linux Wireless

Re: [PATCH] wifi: brcmfmac: of: Support interrupts-extended

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




Am 22.06.24 um 16:07 schrieb Alex Bee:

Am 22.06.24 um 15:49 schrieb Arend Van Spriel:
On June 22, 2024 3:38:32 PM Arend Van Spriel <arend.vanspriel@xxxxxxxxxxxx> wrote:

On June 22, 2024 12:56:02 AM Alex Bee <knaerzche@xxxxxxxxx> 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.

Sure, if you insist on it, I can update the bindings document. So far not
many (no) users did that, as it is clearly specified as an alternative in
devicetree/bindings/interrupt-controller/interrupts.txt (sure, it's not yet
converted to yaml yet).
If you are worried about schema validation: Some magic will accept both
"interrupts" and "interrupts-extended" if only "interrupts" is specified in
the binding. Not sure that happens.

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.

They point in this particular case is not how many interrupts exsist, but
"... or a different interrupt parent than
the inherited ..." which is almost always the case for brcmfmac, as it
usually specifies a gpio controller as interrupt parent. So:

Maybe I should resend with a verbosity-increased commit message?
...
        interrupt-parent = <&gpio0>;
        interrupts = <RK_PA0 IRQ_TYPE_LEVEL_HIGH>;
...

gets to (a single line):
...
    interrupts-extended:  = <&gpio0 RK_PA0 IRQ_TYPE_LEVEL_HIGH>;
...

Which is a much nicer form, imho.
And by the way for instance
arch/arm/boot/dts/qcom/qcom-apq8026-lg-lenok.dts already uses it that way
and the interrupt will currently not picked up (at least not by this
driver).

Alex

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







[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Wireless Regulations]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux