Re: [PATCH 1/2 v1] gpio: sifive: Set affinity callback to parent

[Marc Zyngier <maz@kernel.org>]

On Tue, 06 Apr 2021 11:20:57 +0100,
Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> 
> Hi Linus,
> 
> On Tue, Nov 17, 2020 at 10:37 PM Linus Walleij <linus.walleij@linaro.org> wrote:
> > This assigns the .irq_set_affinity to the parent callback.
> > I assume the sifive GPIO can be used in systems with
> > SMP.
> >
> > I used the pattern making the hirerarchy tolerant for missing
> > parent as in Marc's earlier patches.
> >
> > Cc: Yash Shah <yash.shah@sifive.com>
> > Cc: Wesley W. Terpstra <wesley@sifive.com>
> > Suggested-by: Marc Zyngier <maz@kernel.org>
> > Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> 
> Thanks for your patch!
> 
> > ---
> > ChangeLog RFT->v1:
> > - Make the affinity setting call return -EINVAL if there
> >   is no parent.
> 
> Would it make sense to incorporate this check into
> irq_chip_set_affinity_parent(), so drivers can just point
> .irq_set_affinity to the latter, without having to provide (duplicate)
> the same wrapper over and over?

Calling one of the irq_chip_*_parent() functions assumes that there
*is* a parent at all times, because you really need to know what
context you are in by construction. There are a couple of exceptions
to this rule (irqchip state, retriggering), but overall I'd like to
stick to it and leave the checks on the implementations that have
weird setups.

I would assume that it is possible to know at the point where you map
the interrupt whether it has a parent or not, and use a different
irqchip. Is that doable in this case?

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.