summaryrefslogtreecommitdiff
path: root/drivers/staging/greybus/operation.h
diff options
context:
space:
mode:
authorAlex Elder <elder@linaro.org>2014-12-03 12:27:46 -0600
committerGreg Kroah-Hartman <greg@kroah.com>2014-12-03 15:09:12 -0800
commit82b5e3feb71482fe63f3c62d81a1528a890dfe74 (patch)
tree142dee50ec94321f1472214262583834db728822 /drivers/staging/greybus/operation.h
parent746e0ef95ade8dd6d8633679a87ab573b5e1f69e (diff)
greybus: record type in operation structure
I've gone back and forth on this, but now that I'm looking at asynchronous operations I know that the asynchronous callback will want to know what type of operation it is handling, and right now that's only available in the message header. So record an operation's type in the operation structure, and use it in a few spots where the header type was being used previously. Pass the type to gb_operation_create_incoming() so it can fill it in after the operation has been created. Clean up the crap comments above the definition of the operation structure. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Diffstat (limited to 'drivers/staging/greybus/operation.h')
-rw-r--r--drivers/staging/greybus/operation.h38
1 files changed, 15 insertions, 23 deletions
diff --git a/drivers/staging/greybus/operation.h b/drivers/staging/greybus/operation.h
index a79e88a3b314..a173aa9feb17 100644
--- a/drivers/staging/greybus/operation.h
+++ b/drivers/staging/greybus/operation.h
@@ -56,39 +56,31 @@ struct gb_message {
/*
* A Greybus operation is a remote procedure call performed over a
- * connection between the AP and a function on Greybus module.
- * Every operation consists of a request message sent to the other
- * end of the connection coupled with a reply returned to the
- * sender.
- *
- * The state for managing active requests on a connection is held in
- * the connection structure.
+ * connection between two UniPro interfaces.
*
- * YADA YADA
+ * Every operation consists of a request message sent to the other
+ * end of the connection coupled with a reply message returned to
+ * the sender. Every operation has a type, whose interpretation is
+ * dependent on the protocol associated with the connection.
*
- * submitting each request and providing its matching response to
- * the caller when it arrives. Operations normally complete
- * asynchronously, and when an operation's response arrives its
- * callback function is executed. The callback pointer is supplied
- * at the time the operation is submitted; a null callback pointer
- * causes synchronous operation--the caller is blocked until
- * the response arrives. In addition, it is possible to await
- * the completion of a submitted asynchronous operation.
+ * Only four things in an operation structure are intended to be
+ * directly usable by protocol handlers: the operation's connection
+ * pointer; the operation type; the request message payload (and
+ * size); and the response message payload (and size). Note that a
+ * message with a 0-byte payload has a null message payload pointer.
*
- * A Greybus device operation includes a Greybus buffer to hold the
- * data sent to the device. The only field within a Greybus
- * operation that should be used by a caller is the payload pointer,
- * which should be used to populate the request data. This pointer
- * is guaranteed to be 64-bit aligned.
- * XXX and callback?
+ * In addition, every operation has a result, which is an errno
+ * value. Protocol handlers access the operation result using
+ * gb_operation_result().
*/
typedef void (*gb_operation_callback)(struct gb_operation *);
struct gb_operation {
struct gb_connection *connection;
struct gb_message *request;
struct gb_message *response;
- u16 id;
+ u8 type;
+ u16 id;
int errno; /* Operation result */
struct work_struct work;