maybe we should have a way to release a claimed EXTI interrupt?

Since we can only receive EXTI interrupts on one pin per port on the STM32s, it's difficult to use EXTI for "oneshot" GPIO interrupts. A task which only needs to receive an IRQ from a GPIO level change once will nonetheless permanently allocate that port, preventing any other task from ever receiving GPIO IRQs on pins on that port. It might be nice to add to the stm32xx-sys API to permit a task to temporarily claim an EXTI port, and then give it back once it's done using it.

See, for instance:

On the other hand, I don't think we currently have an interface for a task to release a claimed EXTI notification, so using EXTI for this would permanently occupy our ability to receive interrupts for pin changes on port B, so...we probably shouldn't do that. It might be a good idea to have a way for a task to release its configured EXTI interrupt, so that we can use EXTI for one shot stuff like this without tying up that port forever...

Originally posted by @hawkw in https://github.com/oxidecomputer/hubris/pull/1814#discussion_r1638623851

If we did something like this, it would introduce another locking-type IPC protocol and might, therefore, require the planned priority-ceiling protocol work @cbiffle and I keep discussing but not actually working on...

Start with the stm32xx-sys EXTI API and the referenced discussion in PR 1814 to understand how EXTI ports are currently claimed. Done means defining a safe way to release a claimed EXTI notification for one-shot GPIO use, including the locking and priority-ceiling implications described in the issue.