My hope is to have this before D35898. Noticing how a similar construct inside intr_event_handle() has lasted a decade after having been deprecated.

Looks very much like the nesting inside ipi_preempt()/ipi_hardclock() were a transition mechanism while INTRNG was taking over. Since INTRNG is now used by all ARM hardware, time to remove this.

Note, once this is done the struct trapframe *tf argument to intr_ipi_dispatch() will no longer serve any purpose. I've got removing that handy as a distinct patch, since that is purely cleanup. This also has the effect of making passing the trap frame around in bcm2836.c pointless, which is also handy as a cleanup patch.

This is the portion which has a real effect.

Do we ever set ii_handler_arg to a non-NULL value? If not we could probably drop it and have the handlers take no arguments.

I had also noticed that, but it doesn't strike me as urgent to remove. I don't know whether @jrtc27 has any plans to use the argument after D35898. I'm kind of wondering whether any of the handlers could be shared with RISC-V given how similar they are on ARM/ARM64.

Making it explicit, I had noticed there aren't any calls to intr_ipi_setup() where the last argument is non-NULL. I'm reluctant to remove such since it is low-cost to leave it in and could be very useful. Having typed that, since this has been lurking on ARM for >5 years and never been used it seems a bit unlikely RISC-V will need to use the functionality.

The more notable follow-on is this makes the second argument to intr_ipi_dispatch() unused and that should be removed. I've got that alongside this commit in my tree, but only this portion has an actual functional change.

Ping D37938? I was really hoping to get this through as I would mark D35898 approved once this goes in...

I have no plans to use it but if it's moving to a generic location it's probably worth keeping the flexibility, it's not really a burden to keep. Having said that, IPIs aren't dynamically registered in the same way as normal interrupts, so it seems a bit unnecessary when you can just have a global variable that the handler reads.

D37938 has been sitting here approved, but not in the main tree for some time. This is the "D37938" branch on GitLab (git) (includes 2 associated cleanup commits).

Is there a committer in the house? @imp? @andrew?

This is visible on GitLab as the branch "D37938". The branch includes 3 cleanup commits which I believe do not effect function. The first is the pretty trivial step of removing that now unused trapframe argument.

Needing 4 months to get simple changes through does leave the impression of the organization not really wanting contributions.