Documentation: i2c: slave: describe buffer problems a bit better
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
diff --git a/Documentation/i2c/slave-interface b/Documentation/i2c/slave-interface
index 61ed05c..abd1018 100644
--- a/Documentation/i2c/slave-interface
+++ b/Documentation/i2c/slave-interface
@@ -173,13 +173,14 @@
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.
+* 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 not helpful because
- on writes an action should be immediately triggered. For reads, the data in
- the buffer might get stale.
+* 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