Skip to content
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

Closed
pabigot opened this issue Jul 21, 2020 · 9 comments · Fixed by #43166
Closed

Update terminology related to I2C #27033

pabigot opened this issue Jul 21, 2020 · 9 comments · Fixed by #43166
Assignees
Labels
area: I2C Enhancement Changes/Updates/Additions to existing features Inclusive Language

Comments

@pabigot
Copy link
Collaborator

pabigot commented Jul 21, 2020

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.

@pabigot pabigot added RFC Request For Comments: want input from the community area: I2C labels Jul 21, 2020
@mrrosen
Copy link
Contributor

mrrosen commented Jul 27, 2020

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
Copy link
Contributor

sslupsky commented Aug 13, 2020

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
Copy link
Collaborator Author

pabigot commented Sep 3, 2020

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
Copy link
Collaborator Author

pabigot commented Sep 7, 2020

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.

@pabigot
Copy link
Collaborator Author

pabigot commented Feb 6, 2021

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.

@pabigot pabigot removed the RFC Request For Comments: want input from the community label Feb 6, 2021
@pabigot pabigot changed the title RFC: Update terminology related to I2C Update terminology related to I2C Feb 8, 2021
@github-actions
Copy link

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.

@dleach02
Copy link
Member

dleach02 commented Feb 24, 2022

NXP has published version 7 of the I2C specification with the following modification:

  • Updated the terms "master/slave" to "controller/target" throughout to align with MIPI I3C specification and NXP's Inclusive Language Project

https://www.nxp.com/docs/en/user-guide/UM10204.pdf

@pabigot
Copy link
Collaborator Author

pabigot commented Feb 24, 2022

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.

@teburd
Copy link
Collaborator

teburd commented Feb 24, 2022

Wonderful, glad to finally have some updated names. Happy to see you comment here @pabigot

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: I2C Enhancement Changes/Updates/Additions to existing features Inclusive Language
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants