-
Notifications
You must be signed in to change notification settings - Fork 6.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update terminology related to I2C #27033
Comments
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:
Of course, Im sure theres some overloading of "device" at very least in I2C device documentation, but I think its the best choice. |
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. |
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). |
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. |
The requested decision has been made and the I2C terminology will change when the conditions specified in the coding guidelines have been met. Until that point this can make no progress. |
This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time. |
NXP has published version 7 of the I2C specification with the following modification:
|
Thanks. For reference the updated specification can be found: https://www.nxp.com/docs/en/user-guide/UM10204.pdf https://www.i2c-bus.org/ appears to be managed by somebody else and at the time of writing does not link to the standard anymore. |
Wonderful, glad to finally have some updated names. Happy to see you comment here @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:
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.
The text was updated successfully, but these errors were encountered: