i2c: API should define fine-grained error responses

[pabigot]

The I2C API defines only -EIO as a diagnostic response to a failure in transfers. This is too coarse. At a minimum failure to receive an acknowledgment should be distinguished from all other failures, as some devices use that to indicate that a triggered measurement is not yet complete (e.g. SHT21/Si7021 in no-hold mode). This error can be recovered by trying again later; other errors may be truly fatal.

Appropriate error codes for supported I2C failure types across supported boards should be identified based on existing practice outside Zephyr, and implemented in all drivers that are capable of detecting I2C NAK.

[carlescufi]

Linux uses ENXIO when an ack is not received from the peer.

[zephyrbot]

Hi @teburd,

This issue, marked as an Enhancement, was opened a while ago and did not get any traction. It was just assigned to you based on the labels. If you don't consider yourself the right person to address this issue, please re-assing it to the right person.

Please take a moment to review if the issue is still relevant to the project. If it is, please provide feedback and direction on how to move forward. If it is not, has already been addressed, is a duplicate, or is no longer relevant, please close it with a short comment explaining the reason.

@pabigot you are also encouraged to help moving this issue forward by providing additional information and confirming this request/issue is still relevant to you.

Thanks!