i2c: mcux driver does not prevent simultaneous transactions

[drandreas]

Introduction

Several peripherals might be attached to one i2c bus. Some of those peripherals might therefore, access the same i2c bus simultaneously. I am expecting the i2c bus to have locking mechanism in place to prevent race conditions if an i2c transfer consists of multiple i2c_msg.

Problem description

Neither i2c_transfer in i2c.h nor i2c_mcux_transfer in i2c_mcux.c have any sort of locking. If e.g. an i2c eprom is updated using a shell and simultaneously the system work queue accesses an i2c-port-expander then one of the two transfers will fail or produce a random result. I suspect several of the i2c drivers are affected but haven't checked them all.

Proposed change

Add a semaphore to i2c_transfer in i2c.h or every i2c bus driver.

Alternatives

• Global I2C Lock
• Queue i2c_msgs

[pabigot]

There is currently no global solution for exclusive access to devices, though there is a proposal in #24511 (which needs to be discussed since some drivers shouldn't use blocking locks).

Many (most?) drivers take a semaphore on entry to i2c_transfer() and hold it until done. The MCUX I2C implementation needs to do this.

@drandreas Would you mind if I converted this from an RFC to a bug against MCUX and any other I2C drivers that seem to lack a mutex?

[tbursztyka]

For the time being - until we agree on a generic solutions - I'd go for the same solution as in SPI: see drivers/spi/spi_context.h
It generalizes such lock and sync to SPI, so each and every driver uses such structure. You could get the same for i²C. That, at least would not need any changes to any public API.

[drandreas]

Sure, feel free to convert this ticket

For MCUX I2C I've already created a patch:
drandreas@0174989
I'm happy to create a PR.

[pabigot]

@drandreas Done, please submit your PR.