drivers: ISR-friendly driver APIs

[carlescufi]

Statement of problem: Zephyr's driver APIs are designed to be called only from threads, and never from ISRs. There are several aspects that prevent those APIs from being called from an ISR:

• Many APIs are blocking
• Many APIs make use of kernel objects or primitives that are not allowed to be used from an ISR
• All driver APIs are mappable to system calls

Therefore I suggest we extend the current driver APIs where applicable with additional, ISR-friendly API calls that:

• Are postfixed with _isr
• Do not block or use kernel objects/primitives that are not allowed from ISR
• Are never mapped to system calls
• Can take shortcuts (no device structure for example)

[pfalcon]

Another facet of entropy drivers which need clarification: #6187

[andrewboie]

Therefore I suggest we extend the current driver APIs where applicable with additional, ISR-friendly API calls

No objections to doing this from me.
For the ones that block, it might in some cases preferable to add a timeout parameter where ISR invocation it would be 0. We do this for a bunch of kernel APIs.

All driver APIs are mappable to system calls

Mostly. Ones that register callbacks and so forth we intentionally leave out. But yes in the general case they are intended for use from thread context.

[pabigot]

I'm concerned that creating new API with _isr suffixes is going to make things more confusing, and won't help when the ISR indirectly invokes code that calls a non-ISR-safe function. Also this is only part of answering a user's "what will this function do?" question.

Further comments are in #18970.

[pabigot]

API 2020-07-07: Closing as duplicate of #18970 which is the centerpoint of current plans to document API expectations.