summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorWolfram Sang <wsa@the-dreams.de>2016-07-23 21:59:21 +0200
committerWolfram Sang <wsa@the-dreams.de>2016-07-23 22:00:58 +0200
commit38fa8afff0a99fe8caabbde0d590df3067cf695a (patch)
treef4c3e612b15427a6612751686e247a2d550d92ec
parent85946abc961957df08c58acf838810f08c2a4594 (diff)
downloadlinux-38fa8afff0a99fe8caabbde0d590df3067cf695a.tar.bz2
Documentation: i2c: slave: describe buffer problems a bit better
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
-rw-r--r--Documentation/i2c/slave-interface15
1 files changed, 8 insertions, 7 deletions
diff --git a/Documentation/i2c/slave-interface b/Documentation/i2c/slave-interface
index 61ed05cd9531..abd10186a9e9 100644
--- a/Documentation/i2c/slave-interface
+++ b/Documentation/i2c/slave-interface
@@ -173,13 +173,14 @@ During development of this API, the question of using buffers instead of just
bytes came up. Such an extension might be possible, usefulness is unclear at
this time of writing. Some points to keep in mind when using buffers:
-* Buffers should be opt-in and slave drivers will always have to support
- byte-based transactions as the ultimate fallback because this is how the
- majority of HW works.
-
-* For backends simulating hardware registers, buffers are not helpful because
- on writes an action should be immediately triggered. For reads, the data in
- the buffer might get stale.
+* Buffers should be opt-in and backend drivers will always have to support
+ byte-based transactions as the ultimate fallback anyhow because this is how
+ the majority of HW works.
+
+* For backends simulating hardware registers, buffers are largely not helpful
+ because after each byte written an action should be immediately triggered.
+ For reads, the data kept in the buffer might get stale if the backend just
+ updated a register because of internal processing.
* A master can send STOP at any time. For partially transferred buffers, this
means additional code to handle this exception. Such code tends to be