intrng: expose lower-level device interface for INTRNG

[ehem_freebsd_m5p.com]

Summary

Specialized peripheral PIC drivers may need to handle most interrupt
setup steps themselves without touching newbus. Two cases are
intr_add_handler() and intr_describe() which are internally used by
intr_setup_irq()/intr_describe_irq(). Exposing these allow for
alternative use case.

In fact the BUS interface for INTRNG is arguably a layering violation.
Those 6 functions could just as well be in nexus.c or a kernel library.

[ehem_freebsd_m5p.com]

Any suggestions for reviewers?

sys/kern/subr_intr.c

734–735

Hopefully the reasoning for argument order change is obvious, this is to move closer to matching x86's intr_add_handler() function (doesn't yet match precisely).

[mmel]

I strongly disagree, it's a clear step backwards. Intrng was designed with strong layer separation and you are trying to break it in a similar way to x86.
The consumer interface for interrupts is in the kern_intr.c file and no one else is allowed to use it. The provider interface is intr_isrc_*. All other functions should (and must) remain private or unpublished outside of intrng.

[ehem_freebsd_m5p.com]

I am in fact taking inspiration from x86 since the general idea was to fully split the layers apart (move the outermost functions to perhaps sys/kern/subr_nexus.c). Then it might also match x86's needs and push architectures closer together. In particular, D35559 plus D39178 greatly help with merging.

Unfortunately this really isn't a single-person task and needs more guidance to achieve (or perhaps the sluggish handling of patches for FreeBSD has worn me down).

[ehem_freebsd_m5p.com]

Looks like sys/arm/mv/gpio.c has a situation similar to what I'm looking at. The approach of doing local calls to intr_event_create() has been tested and functions, but this seemed unlikely to be accepted by a reviewer. Yet this makes me the second person to run into troubles with INTRNG due to assumptions in its interface.