Description

Just saw something that might cause some trouble: currently we are calling i2c_init_master in all the device drivers that use I2C (yes thats broken, but this issue is not about that). We also call i2c_acquire in all the init functions. BUT the order in which we call these functions is not defined currently, so some drivers call acquire before init_master, others to it the other way around. The problem is now, that some i2c driver implemenations break this way, as they initialize their internal mutex in the init_master function, leading to undefined behavior when calling mutex_lock in acquire() before initializing the mutex. But then again, not acquiring the bus before calling init_master might also break things when more than one device uses the i2c bus, and their initialization is done in multithreaded contexts...

As I see it, there is no easy/quick fix for that in the current state of the I2C interface and this issue will be solved when moving to the reworked interface... But none the less, it exists and maybe this gives us some further pressure to finally get going on the i2c remodeling...