Zephyr: RFC: Update terminology related to I2C

[pabigot]

Following Linux and OSHWA I'd like to see the language associated with the I2C bus roles changed to be less insensitive.

At this time I haven't been able to identify an I2C-specific precedent to follow, but candidate terminology to replace "master" (device that drives the clock signal) and "slave" (reacts to the clock signal changes) include:

• leader/follower
• primary/secondary
• controller/peripheral

These are listed in decreasing order of my personal preference taking into account the semantics and pragmatics of the different terms and how the protocol works.

At this time I'm floating this to see whether there's significant support or opposition to such a change.

[mrrosen]

I would suggest "master" -> "host" and "slave" -> "device". This terminology is common in other bus protocols like USB; and at least the term "device" is used interchangeably with "slave" in some documentation Ive seen (Ive seen "device address" used a quite alot instead of "slave address"). I would recommend against at least two of the suggestions you provided:

• primary/secondary: some I2C devices have multiple I2C device addresses they can listen for (common in camera sensors); these addresses are referred to as secondary addresses, so it might be overloading terms leading to confusion.
• controller/peripheral: these terms are very common to refer the I2C module on an SoC level, either as an SoC peripheral or an I2C controller; so again, overloading terms might lead to confusion as to whether something is in SoC or not.

Of course, Im sure theres some overloading of "device" at very least in I2C device documentation, but I think its the best choice.

[sslupsky]

I do not want to appear to be "insensitive" ... but unless you can get NXP to change the I2C specification, I see changing terminology here will result in a lot of confusion. I think this is an issue that NXP needs to address first.

[pabigot]

More details on why I'm using leader/follower:

"controller" already has a meaning in the Zephyr I2C world: it's the I2C peripheral that interacts with the bus. The driver for that peripheral is the I2C controller, which can be configured into leader ("master") or follower ("slave") modes.

"Leader" is because it's the one that controls the clock, which the "follower" reacts to (absent clock stretching).

[pabigot]

A little more background to keep this moving:

As a software professional and student of social science I feel strongly that the terms "master" and "slave" subtly reinforce structural racism in tech culture. They also blunt the impact of the word "slave" in relation to the more euphemistic "human trafficking" that continues today world-wide.

Other major open source projects have already taken steps to address these problems.

As a contributing member of the open source community I'm in a position to act. As the Zephyr I2C maintainer I have a responsibility to act. So #27996 starts the process.

As I note there the text projecting my views upwards to Zephyr as a whole in the explanation of the new language is overstepping, and I'm willing to adjust that to TSC-approved text, or take it out entirely (though as I2C maintainer I think that would be foolish as it makes it harder for people to understand).

But if the requirement to merge the new documentation I've written is that it must be changed to use the terms "master" and "slave", I want that to be a positive decision made by Zephyr as a project, which I must then follow as a community member.