We have lately started to put some efforts in re-modeling/overhauling our peripheral driver interfaces, and have already improved them quite a bit. Looking at all the open issues and PRs to this topic, I put some high-level thoughts on how we could find a generic concept which makes clear, which driver has to implement what kind of properties. I came to the following table (see explanation below):

Peripheral  Multiple    Shared  Atomic
adc         x           -       x (one shot)
adc         x           -       - (periodic)
cpuid       -           -       x
dac         x           -       -
gpio        x           -       -
i2c         x           x       x (master mode)
i2c         x           -       - (slave mode)
pwm         x           -       -
hwrng       -           -       x
rtc         -           -       -
rtt         -           -       -
spi         x           x       x  (master mode)
spi         x           -       - (slave mode)
timer       x           -       -
uart        x           -       -

(x := yes, - := no)

Multiple: There is/can be more than one instance of this peripheral on a MCU. This means, that the interface must specify the used instance (what we do with the first parameter)
Shared: These peripherals are shared by 1-to-N 'consumers' (i.e. device drivers), typically bus systems. I don't consider UART to be shared, as it is an 1-to-1 connection (also for STDIO, only the syscall implementation uses the UART directly...).
Atomic: Must a peripheral only be active for the amount of time it is accessed or has it to be active the complete time? E.g. UART and timers must be active for RX and for running, respectively. But reading the CPUID, acquiring a single ADC value or sending some bytes via SPI can be considered as atomic in this sense.

Now let's see what implications these three groups bring us:
Multiple: Easy: all functions of an interface for these peripherals must include a dev parameter to identify the peripheral that should be used. Also we need means to configure the different instances of a peripheral on a per-board basis.

Shared: All shared devices must include means, to get and hand back exclusive access to a device. I think our current concept with xx_aquire() and xx_release() is the way to go here.

Atomic: This is the most interesting property, and I would propose to change our current thinking here slightly:

• all 'atomic' peripherals should be in off state per default
• so typically intially: enable device (turn on), initilize global options, disable device (turn off)
• when used: turn on, do something, turn off
• this means: supply poweron and poweroff functions only for none-atomic peripherals, for all others call them implicit internally
• for shared peripherals the enabling and disabling should be put in their aquire/release functions

@gebart, @kaspar030, @thomaseichinger, @jfischer-phytec-iot, @cgundogan - opinions?

If we all agree on this (or something else), I will write it down in more detail an put it into the periph driver doxygen documentation...