tests: i2c_slave_api: update to current standard terminology

Zephyr does not currently allow deviation from standard terminology
for a technology even if it is non-inclusive, until the corresponding
standards body has confirmed intent to change that terminology.  The
terms used in a previous attempt to be inclusive do not match the
expected forthcoming standard terms.

Revert to standard terms until the new ones have been announced and
the switch made throughout Zephyr.

Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
This commit is contained in:
Peter Bigot 2021-02-06 07:09:45 -06:00 committed by Anas Nashif
parent b7da2e258f
commit 2a9b9b74bc
3 changed files with 23 additions and 19 deletions

View file

@ -1,16 +1,19 @@
I2C Slave API test
##################
.. note:
See :ref:`coding_guideline_inclusive_language` for information about
plans to change the terminology used in this API.
This test verifies I2C slave driver implementations using two I2C
controllers on a common bus. The test is supported by a test-specific
driver that simulates an EEPROM with an I2C bus follower ("slave")
interface. Data is pre-loaded into the simulated devices outside the
I2C API, and the Zephyr application issues commands to one controller
that are responded to by the simulated EEPROM connected through the
other controller.
driver that simulates an EEPROM with an I2C bus slave interface. Data
is pre-loaded into the simulated devices outside the I2C API, and the
Zephyr application issues commands to one controller that are responded
to by the simulated EEPROM connected through the other controller.
This test was originally designed for I2C controllers that support both
leader and follower behavior simultaneously. This is not true of all
master and slave behavior simultaneously. This is not true of all
I2C controllers, so this behavior is now opt-in using
CONFIG_APP_DUAL_ROLE_I2C. However, the devicetree still must provide a
second EEPROM just to identify the bus.
@ -19,13 +22,14 @@ In slightly more detail the test has these phases:
* Use API specific to the simulated EEPROM to pre-populate the simulated
devices with device-specific content.
* Register a simulated EEPROM as a I2C follower device on a bus. If
* Register a simulated EEPROM as a I2C slave device on a bus. If
CONFIG_APP_DUAL_ROLE_I2C is selected, register both.
* Issue commands on one bus controller (operating as the bus leader
(master)) and verify that the data supplied by the other controller
(as bus follower) match the expected values given the content known to
be present on the simulated device. If CONFIG_APP_DUAL_ROLE_I2C is
selected, do this with the roles reversed.
* Issue commands on one bus controller (operating as the bus master) and
verify that the data supplied by the other controller (slave) match
the expected values given the content known to be present on the
simulated device. If CONFIG_APP_DUAL_ROLE_I2C is selected, do this
with the roles reversed.
Transfer of commands from one bus controller to the other is
accomplished by hardware through having the SCL (and SDA) signals

View file

@ -16,4 +16,4 @@ config I2C_VIRTUAL_NAME
depends on I2C_VIRTUAL
config APP_DUAL_ROLE_I2C
bool "Enable test with combined leader/follower behavior"
bool "Enable test with combined master/slave behavior"

View file

@ -175,7 +175,7 @@ void test_eeprom_slave(void)
zassert_equal(ret, 0, "Failed to program EEPROM %s", label_1);
}
/* Attach each EEPROM to its owning bus as a follower device. */
/* Attach each EEPROM to its owning bus as a slave device. */
ret = i2c_slave_driver_register(eeprom_0);
zassert_equal(ret, 0, "Failed to register EEPROM %s", label_0);
@ -184,14 +184,14 @@ void test_eeprom_slave(void)
zassert_equal(ret, 0, "Failed to register EEPROM %s", label_1);
}
/* The simulated EP0 is configured to be accessed as a follower device
/* The simulated EP0 is configured to be accessed as a slave device
* at addr_0 on i2c_0 and should expose eeprom_0_data. The validation
* uses i2c_1 as a bus leader to access this device, which works because
* uses i2c_1 as a bus master to access this device, which works because
* i2c_0 and i2_c have their SDA (SCL) pins shorted (they are on the
* same physical bus). Thus in these calls i2c_1 is a leader device
* operating on the follower address addr_0.
* same physical bus). Thus in these calls i2c_1 is a master device
* operating on the slave address addr_0.
*
* Similarly validation of EP1 uses i2c_0 as a leader with addr_1 and
* Similarly validation of EP1 uses i2c_0 as a master with addr_1 and
* eeprom_1_data for validation.
*/
ret = run_full_read(i2c_1, addr_0, eeprom_0_data);