SPI_DEV, SPI_UNDEF?

Those macros are very handy when it comes to writing tests or similar: Say your CPU defines i2c_t to be a pointer, the CPU can than define the I2C_DEV macro in a way, that creates a mapping between an integer and this counter (e.g. as done in the GPIO driver for some CPUs). So instead of using I2C_0, I2C_1, etc, which you can not iterate, you can use I2C_DEV(0), I2C_DEV(1)`, and so on.

The undefined value is useful for situations, where you could have an optional i2c parameter in a function. You could for example write a device driver, that can use either I2C or SPI and the driver can chose on runtime by the given parameters which mode it will use...

sorry, I was just remarking on the use of the term SPI inside the message of the I2C commit. I agree with you that this is a useful improvement to the API.
We should finish the UART, SPI and I2C API improvements after the release 2015.09 is out.

sorry, I was just remarking on the use of the term SPI inside the message of the I2C commit

ups, now I got it :-) Thx!

Yepp, lets get the release out of the door and then get those updated periph APIs merged, next in line is than re-visiting the power management concepts :-)

@haukepetersen sounds like a good plan forward!

Seems reasonable to me. I will test it in the next week, just to be on the safe side. But we wanted to wait until the release is out anyway...

Tested with samr21-xpro and srf02 ultrasonic sensor (i2c) and works. So ACK (after Travis is fine some day)

And go