Re: RFC: Extension to External Interrupt API

Chettimada, Vinayak Kariappa

OK with this, what's the use-case though?
I am implementing a "work" (tasklet in Linux terms), a "work", being a function/routine, is invoked as a direct call i.e. if the caller is in the same priority as the ISR and the software interrupt (my "work" group) that would have been offloaded to (if were at another priority) is enabled. Hence, the need for irq_is_enabled().
In theory, each h/w interrupt can have separate/own bottom-half "work" group (ISR). Why, to have priority levels for the bottom-halves.

NACK. This isn't easily portable to other arches. You brought this up
as a candidate to replace irq_offload(), but irq_offload() only exists
as a debug feature, so that we can run some unit tests in IRQ context.
Advanced stuff like your needs, do this in your application.

Fine w/this.

NACK, for the same reasons as irq_pending_set().

As explained above. Seemed like I was thinking or was inspired by Tasklet, definitely solving my design needs. Some day a device/subsystem will look for a similar solution.

Thinking aloud:
1. driver/interrupt_controller needs unification.
2. Introduce "work" feature now in BLE controller in a separate patch.


Join to automatically receive all group messages.