diff options
Diffstat (limited to 'Documentation/i2c/gpio-fault-injection')
| -rw-r--r-- | Documentation/i2c/gpio-fault-injection | 49 |
1 files changed, 38 insertions, 11 deletions
diff --git a/Documentation/i2c/gpio-fault-injection b/Documentation/i2c/gpio-fault-injection index e0c4f775e239..a4ce62090fd5 100644 --- a/Documentation/i2c/gpio-fault-injection +++ b/Documentation/i2c/gpio-fault-injection @@ -34,21 +34,48 @@ I2C specification version 4, section 3.1.16) using the helpers of the Linux I2C core (see 'struct bus_recovery_info'). However, the bus recovery will not succeed because SDA is still pinned low until you manually release it again with "echo 1 > sda". A test with an automatic release can be done with the -'incomplete_transfer' file. +following class of fault injectors. -"incomplete_transfer" ---------------------- +Introduction to incomplete transfers +------------------------------------ + +The following fault injectors create situations where SDA will be held low by a +device. Bus recovery should be able to fix these situations. But please note: +there are I2C client devices which detect a stuck SDA on their side and release +it on their own after a few milliseconds. Also, there might be an external +device deglitching and monitoring the I2C bus. It could also detect a stuck SDA +and will init a bus recovery on its own. If you want to implement bus recovery +in a bus master driver, make sure you checked your hardware setup for such +devices before. And always verify with a scope or logic analyzer! + +"incomplete_address_phase" +-------------------------- This file is write only and you need to write the address of an existing I2C -client device to it. Then, a transfer to this device will be started, but it -will stop at the ACK phase after the address of the client has been +client device to it. Then, a read transfer to this device will be started, but +it will stop at the ACK phase after the address of the client has been transmitted. Because the device will ACK its presence, this results in SDA being pulled low by the device while SCL is high. So, similar to the "sda" file above, the bus master under test should detect this condition and try a bus recovery. This time, however, it should succeed and the device should release -SDA after toggling SCL. Please note: there are I2C client devices which detect -a stuck SDA on their side and release it on their own after a few milliseconds. -Also, there are external devices deglitching and monitoring the I2C bus. They -can also detect a stuck SDA and will init a bus recovery on their own. If you -want to implement bus recovery in a bus master driver, make sure you checked -your hardware setup carefully before. +SDA after toggling SCL. + +"incomplete_write_byte" +----------------------- + +Similar to above, this file is write only and you need to write the address of +an existing I2C client device to it. + +The injector will again stop at one ACK phase, so the device will keep SDA low +because it acknowledges data. However, there are two differences compared to +'incomplete_address_phase': + +a) the message sent out will be a write message +b) after the address byte, a 0x00 byte will be transferred. Then, stop at ACK. + +This is a highly delicate state, the device is set up to write any data to +register 0x00 (if it has registers) when further clock pulses happen on SCL. +This is why bus recovery (up to 9 clock pulses) must either check SDA or send +additional STOP conditions to ensure the bus has been released. Otherwise +random data will be written to a device! + |