arm: remove interrupt nesting by ipi_preempt()/ipi_hardclock()

[ehem_freebsd_m5p.com]

Summary

This was needed when intr_ipi_dispatch() was called by hardware-specific
IPI interrupt routines which didn't save the trap frame. Now all ARM
interrupts pass through INTRNG which will have already saved the trap
frame and disabled preemption.

Remove the conditional trapframe/argument passing to the handlers.

MFC after: 1 month

[ehem_freebsd_m5p.com]

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.

[ehem_freebsd_m5p.com]

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.

[andrew]

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.

[ehem_freebsd_m5p.com]

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.

[ehem_freebsd_m5p.com]

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.

[ehem_freebsd_m5p.com]

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

[jrtc27]

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.

[ehem_freebsd_m5p.com]

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).

[ehem_freebsd_m5p.com]

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.