[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <622fb6be108e894ee365d6b213535c8b@kernel.org>
Date: Wed, 03 Jun 2020 16:16:48 +0100
From: Marc Zyngier <maz@...nel.org>
To: "Saidi, Ali" <alisaidi@...zon.com>
Cc: "Herrenschmidt, Benjamin" <benh@...zon.com>, tglx@...utronix.de,
jason@...edaemon.net, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org,
"Woodhouse, David" <dwmw@...zon.co.uk>,
"Zilberman, Zeev" <zeev@...zon.com>,
"Machulsky, Zorik" <zorik@...zon.com>
Subject: Re: [PATCH] irqchip/gic-v3-its: Don't try to move a disabled irq
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...
Powered by blists - more mailing lists