1

i2c: testunit: return current command on read messages

Because the testunit can start tests in the future via the DELAY
register, it may happen that a command is still pending. Support
detecting that by returning the number of a command in progress (if
there is one).

Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
This commit is contained in:
Wolfram Sang 2024-08-11 23:23:16 +02:00
parent 6b21470af0
commit 45c03c65ea
2 changed files with 10 additions and 8 deletions

View File

@ -20,11 +20,13 @@ Instantiating the device is regular. Example for bus 0, address 0x30::
# echo "slave-testunit 0x1030" > /sys/bus/i2c/devices/i2c-0/new_device
After that, you will have a write-only device listening. Reads will just return
an 8-bit version number of the testunit. When writing, the device consists of 4
8-bit registers and, except for some "partial" commands, all registers must be
written to start a testcase, i.e. you usually write 4 bytes to the device. The
registers are:
After that, you will have the device listening. Reading will return a single
byte. Its value is 0 if the testunit is idle, otherwise the command number of
the currently running command.
When writing, the device consists of 4 8-bit registers and, except for some
"partial" commands, all registers must be written to start a testcase, i.e. you
usually write 4 bytes to the device. The registers are:
.. csv-table::
:header: "Offset", "Name", "Description"
@ -170,4 +172,4 @@ are not equivalent to a REPEATED START. As an example, this returns just the
default response::
# i2cset -y 0 0x30 4 0 0 i; i2cget -y 0 0x30
0x01
0x00

View File

@ -15,7 +15,6 @@
#include <linux/slab.h>
#include <linux/workqueue.h> /* FIXME: is system_long_wq the best choice? */
#define TU_CUR_VERSION 0x01
#define TU_VERSION_MAX_LENGTH 128
enum testunit_cmds {
@ -159,7 +158,8 @@ static int i2c_slave_testunit_slave_cb(struct i2c_client *client,
else if (is_proc_call)
*val = tu->regs[TU_REG_DATAH];
else
*val = TU_CUR_VERSION;
*val = test_bit(TU_FLAG_IN_PROCESS, &tu->flags) ?
tu->regs[TU_REG_CMD] : 0;
break;
}