Re: [PATCH v3 3/4] irq: Allow multiple clients to register for irq affinity notification

[Kevin Hilman <khilman@kernel.org>]

Hi Thomas,

Thomas Gleixner <tglx@linutronix.de> writes:

[...]

> All I can see from your postings so far is:
>
>     1) You want to use the notification for PM QoS
>
>     2) You run into conflicts with the existing notifiers
>
>     3) You want to solve that conflict
>
> What you are not telling is:
>
>     1) In which way is PM QoS going to use that notifier
>
>     2) How does that conflict with the existing users. And we only
>        have two of them:
>
>        - InfiniPath 7322 chip driver
>
>        - cpu_rmap driver, which is used by
>        	- solarflare NIC driver
> 		- mellanox mlx4 driver
>	 	- cisco enic driver
>
> 	So how is that conflicting with your ARM centric PM QoS work?
>
> 	Please provide proper debug info about such a conflict, if it
> 	exists at all.

Ignoring any new users of the affinity notifiers for now, aren't the
existing users you list above conflicting with each other already?

Maybe I'm missing something, or maybe we're just lucky and nobody uses
them together, but irq_set_affinity_notifier() only allows a single
notifier to be registered at any given time.  So if you had a system
with the inifinipath driver and a cpu_rmap user, only the one who's
lucky enough to be the last to call irq_set_affinity_notifier() will
ever be notified.

So I think the main question for Lina is: assuming we need more than one
co-existing driver/subsystem to get IRQ affinity notifiers (and we
already seem to have them, but are lucky they don't currently co-exist),
how should the IRQ core be changed to support that?  Is the list
approach proposed in $SUBJECT path reasonable?

Kevin