Hi Fabio,

Thanks for your email. To the best of my knowledge, none is working on ZLI on Baseline Cortex-M. If you would like to move with this forward, the best way is to an RFC issue in the Zephyr main tree Github, to get feedback from the architecture maintainers/collaborators. Remember to copy the content in this email thread.

Some comments to your suggestion:

ZLI works OK on Mainline Cortex-M, essentially because we can guarantee the following priority level order:
       ZLI > Kernel > HW IRQs (+misc) > PendSV (Faults are always given highest configurable priority)
So ZLIs can preempt all HW IRQs, and can also preempt the Kernel (i.e. SVCs).

Now on Baseline (If I understand the proposal):
- PRIMASK won't be used at all for IRQ locking, if the ZLI feature is enabled.
- For ZLIs to preempt the kernel (thus, for ZLI to have the same functionality as in Mainline), SVCs need to be given a priority level lower than the ZLIs. That means, 1 out of 4 priority levels need to be reserved, which is something we were trying to avoid for some time.

There's also the performance of irq_lock and _unlock functions: the beauty of the current solution is that no memory-mapped register access is performed. This speeds up the execution, and requires only an ISB barrier. With NVIC, read-modify-write and ram-variable-storing we will need memory-mapped accesses in addition to data synchronization barriers, which might increase the overhead of locking and unlocking the IRQs. The problem will be harder on Armv8-m Baseline, which has support for much more than 32 IRQ lines.

Guess these are reasons why the software emulation of irq locking "up-to-a-priority-level" has not attracted much attention so far, but I'd be happy to see an actual discussion going on here, ideally in an RFC Github issue.

Best,
Ioannis