cpu: fix returns of i2c_acquire and i2c_release

[smlng]

Contribution description

This PR replaces asserts with if statements in periph/i2c for all CPUs to return proper error codes according to the API spec. The rational behind this is that (theoretically) one could write a driver and simply link against RIOT without recompiling the periph/i2c, hence asserts will not work but according to the API specs acquire and release should return -1 on error, which in this case mostly means: wrong device

Testing procedure

run tests/periph_i2c (or any drivers requiring I2C) for different boards to match all CPUs, it should still work.

Issues/PRs references

[dylad]

@MrKevinWeiss @gschorcht @gebart I think this is related to #10673 ;)
I think it is time to take a decision here.

[aabadie]

Maybe link to #10673. You could give your opinion there as well ?

[kaspar030]

NACK, we've had this discussion many times. periph device args get checked on init() only.
It is forbidden to call any i2c function with a device value that has not been checked through init(). The checks are not necessary and bloat the code. Any code that triggers the fail case is buggy from the start. Hence asserts must be enough.

Adding this error here would basically force any user to actually check for the error, which is just overkill for embedded use.

[gschorcht]

@MrKevinWeiss @gschorcht @gebart I think this is related to #10673 ;)
I think it is time to take a decision here.

Indeed. As stated in #10673, 95 % of our drivers do not check these return values. An assert might be better than nothing.

BTW, I would rather add a further assert to check that these functions are not called from interrupt context to avoid problems as described in issue #10488 and in PR #10430 which are tried to be solved by PR #10555.

[MrKevinWeiss]

Any movement on this front? Can we agree asserts are enough?

[tcschmidt]

This almost looks like a rough consensus to me: Those who disagree closing this PR (+related) should speak up asap.

[smlng]

closing ... as discussed, this should be addressed differently.