Re: [PATCH RFC 0/3] genirq: Allow drivers to respect userspace IRQ affinities

Hi Andrew,

On Thu, 2026-08-20 at 01:54 +0200, Andrew Lunn wrote:

quoted

That raises the question why request_irq() is called on "link up" time,
while the low level vector allocation takes place during device probing.

If the interface is admin down, the hardware should not be generating
any interrupts. So there is no need to request them.

quoted

At least that seems to be the common pattern. Can someone tell me why
this is done this way? Shouldn't we call request_irq() at the same time?

If you want to change anything, move the low level vector allocation
into open(). But you need to be careful of EPROBE_DEFER. If the
interrupt controller has not loaded yet, i _guess_ the low level
vector allocation will return EPROBE_DEFER, and the MAC driver will
try to probe again later. If you get EPROBE_DEFER in open(), there is
nothing you can do about it.

	Andrew

Moving (=delaying) the vector allocation into open() would not help
here. The /proc/irq/<n> interface is populated on request_irq(),
normally done inside open() as well. Up to this point userspace is not
able to set any affinities.

This is one of the shortcomings mentioned in the cover letter. Once
/proc/irq/<n> appears, it might already be too late for a proper
affinity setting, the IRQ might have fired already. In addition there is
no notification mechanism that informs userspace about newly requested
IRQs.

It's more of the opposite that might help: Moving request_irq() into the
probe() phase. I'm wondering why the pattern is
    vector alloc => probe()
    request irq => open()

Seems that we would not "waste" too much resources when we move
request_irq() calls into probe() as well. But as always: I might miss
something.

Florian