Re: [PATCH] irqchip/gic-v3-its: Don't try to move a disabled irq

From: Marc Zyngier <maz@kernel.org>
To: "Saidi, Ali" <alisaidi@amazon.com>
Cc: "Herrenschmidt, Benjamin" <benh@amazon.com>,
	tglx@linutronix.de, jason@lakedaemon.net,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, "Woodhouse,
	David" <dwmw@amazon.co.uk>, "Zilberman, Zeev" <zeev@amazon.com>,
	"Machulsky, Zorik" <zorik@amazon.com>
Subject: Re: [PATCH] irqchip/gic-v3-its: Don't try to move a disabled irq
Date: Wed, 03 Jun 2020 16:16:48 +0100	[thread overview]
Message-ID: <622fb6be108e894ee365d6b213535c8b@kernel.org> (raw)
In-Reply-To: <AE04B507-C5E2-44D2-9190-41E9BE720F9D@amazon.com>

On 2020-06-02 19:47, Saidi, Ali wrote:

[...]

> Looks like the x86 apic set_affinity call explicitly checks for if
> it’s activated in the managed case which makes sense given the code
> Ben posted above:
>           /*
>            * Core code can call here for inactive interrupts. For 
> inactive
>            * interrupts which use managed or reservation mode there is 
> no
>            * point in going through the vector assignment right now as 
> the
>            * activation will assign a vector which fits the destination
>            * cpumask. Let the core code store the destination mask and 
> be
>            * done with it.
>            */
>           if (!irqd_is_activated(irqd) &&
>               (apicd->is_managed || apicd->can_reserve))
> 
> My original patch should certain check activated and not disabled.
> With that do you still have reservations Marc?

I'd still prefer it if we could do something in core code, rather
than spreading these checks in the individual drivers. If we can't,
fair enough. But it feels like the core set_affinity function could
just do the same thing in a single place (although the started vs
activated is yet another piece of the puzzle I didn't consider,
and the ITS doesn't need the "can_reserve" thing).

Thanks,

         M.
-- 
Jazz is not dead. It just smells funny...