summaryrefslogtreecommitdiffstats
path: root/Documentation/connector/connector.txt
diff options
context:
space:
mode:
authorDavid Fries <David@Fries.net>2014-04-08 22:37:09 -0500
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2014-05-27 13:56:21 -0700
commit8a0427d192e6043834414210dd14cc1289daff18 (patch)
tree1e76812e3744b6946a815fb94f877cc31d11b302 /Documentation/connector/connector.txt
parent34470e0bfae223e3f22bd2bd6e0e1dac366c9290 (diff)
downloadop-kernel-dev-8a0427d192e6043834414210dd14cc1289daff18.zip
op-kernel-dev-8a0427d192e6043834414210dd14cc1289daff18.tar.gz
w1: optional bundling of netlink kernel replies
Applications can submit a set of commands in one packet to the kernel, and in some cases it is required such as reading the temperature sensor results. This adds an option W1_CN_BUNDLE to the flags of cn_msg to request the kernel to reply in one packet for efficiency. The cn_msg flags now check for unknown flag values and return an error if one is seen. See "Proper handling of unknown flags in system calls" http://lwn.net/Articles/588444/ This corrects the ack values returned as per the protocol standard, namely the original ack for status messages and seq + 1 for all others such as the data returned from a read. Some of the common variable names have been standardized as follows. struct cn_msg *cn struct w1_netlink_msg *msg struct w1_netlink_cmd *cmd struct w1_master *dev When an argument and a function scope variable would collide, add req_ to the argument. Signed-off-by: David Fries <David@Fries.net> Acked-by: Evgeniy Polyakov <zbr@ioremap.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'Documentation/connector/connector.txt')
-rw-r--r--Documentation/connector/connector.txt2
1 files changed, 1 insertions, 1 deletions
diff --git a/Documentation/connector/connector.txt b/Documentation/connector/connector.txt
index e56abdb..f6215f9 100644
--- a/Documentation/connector/connector.txt
+++ b/Documentation/connector/connector.txt
@@ -118,7 +118,7 @@ acknowledge number MUST be the same + 1.
If we receive a message and its sequence number is not equal to one we
are expecting, then it is a new message. If we receive a message and
its sequence number is the same as one we are expecting, but its
-acknowledge is not equal to the acknowledge number in the original
+acknowledge is not equal to the sequence number in the original
message + 1, then it is a new message.
Obviously, the protocol header contains the above id.
OpenPOWER on IntegriCloud