diff options
author | David Fries <David@Fries.net> | 2014-04-08 22:37:09 -0500 |
---|---|---|
committer | Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2014-05-27 13:56:21 -0700 |
commit | 8a0427d192e6043834414210dd14cc1289daff18 (patch) | |
tree | 1e76812e3744b6946a815fb94f877cc31d11b302 /Documentation/connector/connector.txt | |
parent | 34470e0bfae223e3f22bd2bd6e0e1dac366c9290 (diff) | |
download | op-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.txt | 2 |
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. |