GPIO Interrupts handling (ARM)

Yes, the wiki page I mentioned is referring namely to that. But there is nothing related to interrupts. Just checked gpioctl(8) from FreeBSD 11-CURRENT - it's not mentioning any interrupt configuration either.
In other discussions people advise to poll GPIOs instead, but that makes no sense in an embedded system.
I'm wondering who's working on an overarching framework for GPIO and their corresponding interrupts. I've written a few device drivers for the Raspberry Pi recently that interface to hardware via GPIO pins, and I'm using interrupts (and kqueue to communicate to user space). For my needs, writing a specific device driver is perfectly reasonable since my hardware configurations are fixed (HATs I designed, complete hardware setup is dedicated to a particular set of tasks). But I completely understand the desire to have GPIO interrupt facilities without having to write a device driver.

There are some quirks remaining with GPIO interrupts within the kernel that I haven't dug into yet. There are cases where it's desirable to have separate handlers for rising and falling edge interrupts, but the 11.0-CURRENT I have right now doesn't allow it. On my first pass at my rotary encoder driver, I found that gpio_alloc_intr_resource() failed for the second edge interrupt (order of rising or falling edge didn't matter). I wound up working around it and moving on, but I am hoping to make time to look at it again. Might already be fixed, I haven't had a chance to update in many weeks (or even open a bug report). And of course it's entirely possible that I did something wrong, but from memory I reviewed my code thoroughly before deciding on a workaround.

I have a wish list in my head for GPIO functionality, but haven't written it down. I do know I don't want to see the warts in Raspbian's solution to trickle into FreeBSD. But I'd like to have per-pin permissions per ioctl (i.e. better access control granularity), be able to do more without changing the FDT, etc. And of course efficient interrupts -> userspace.

If someone here know anyone who is working on such things, I'd be willing to help where I can. Even if it's just helping flesh out what would be 'nice to have'. I admit to not having a ton of time to contribute code outside of my immediate needs, but that's true of many of us who target FreeBSD in our spare time. There's been quite a bit of change in the trunk since 10.x with respect to this stuff, but unfortunately I don't seem to be clued in to the set of design goals and I don't have enough different SBCs to understand what will work in the general case versus what only works on the Pis and BeagleBones. :(
I think a WG is a fine idea. I'm sure that many of us have the same desires, as well as the same ideas. Just coalescing them into something high level but cogent would be a good start and something I haven't yet seen for GPIO.

For some background... my bread and butter today is embedded development in the automotive industry. But I spent 15 years of my career writing software for UNIX and I haven't stopped. I've been running FreeBSD for various things professionally and at home for as long as I can remember (since the a.out and pre-SMP days). My primary language for FreeBSD and UNIX work has been C++ for a long time (coming up on 20 years), but my day job is nearly all C.

Hardware-wise, today's off-the-shelf SBCs are very capable devices at low cost. But there are those of us who'd like to bring the real differentiator of these platforms to bear (versus say a nanoITX x86 or amd64 platform) in our problem domains, on top of a freenix. I want a rock solid TCP/IP stack, filesystem, full POSIX APIs, real security facilities, etc. But I also want at least the minimal set of embedded functionality too: a complete GPIO API, SPI, I2C, CAN. Some higher-level hardware abstractions would be nice for everyone to have as well (quadrature rotary encoders, PWM, others). For most IoT stuff, I don't need a true real-time OS as much as I need real security (ssh, SSL, CryptoPP, etc.), robust TCP/IP and a complete development environment without a huge investment. And I much prefer a BSD license over GPL, which is one of the handful of reasons that FreeBSD remains my primary freenix target.