greybus: move the definition of struct gbuf

We no longer need struct gbuf defined in "greybus.h".  An upcoming
patch will embed a gbuf struct (not a pointer) into the operation
structure, and to do that we'll need the struct defined prior to the
operation.  Just move the gbuf definition into "operation.h".

Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

diff --git a/drivers/staging/greybus/greybus.h b/drivers/staging/greybus/greybus.h
index 173170065261bc259d514eb262f60a45d8513ab7..d6bfe6b2f70f30b41b2092e418b2c3c54d0925c9 100644 (file)
--- a/drivers/staging/greybus/greybus.h
+++ b/drivers/staging/greybus/greybus.h
@@ -56,80 +56,6 @@
 #define HOST_DEV_CPORT_ID_MAX  CONFIG_HOST_DEV_CPORT_ID_MAX
 #define CPORT_ID_BAD           U16_MAX         /* UniPro max id is 4095 */
 
-/*
-  gbuf
-
-  This is the "main" data structure to send / receive Greybus messages
-
-  There are two different "views" of a gbuf structure:
-    - a greybus driver
-    - a greybus host controller
-
-  A Greybus driver needs to worry about the following:
-    - creating a gbuf
-    - putting data into a gbuf
-    - sending a gbuf to a device
-    - receiving a gbuf from a device
-
-  Creating a gbuf:
-    A greybus driver calls greybus_alloc_gbuf()
-  Putting data into a gbuf:
-    copy data into gbuf->transfer_buffer
-  Send a gbuf:
-    A greybus driver calls greybus_submit_gbuf()
-    The completion function in a gbuf will be called if the gbuf is successful
-    or not.  That completion function runs in user context.  After the
-    completion function is called, the gbuf must not be touched again as the
-    greybus core "owns" it.  But, if a greybus driver wants to "hold on" to a
-    gbuf after the completion function has been called, a reference must be
-    grabbed on the gbuf with a call to greybus_get_gbuf().  When finished with
-    the gbuf, call greybus_free_gbuf() and when the last reference count is
-    dropped, it will be removed from the system.
-  Receive a gbuf:
-    A greybus driver calls gb_register_cport_complete() with a pointer to the
-    callback function to be called for when a gbuf is received from a specific
-    cport and device.  That callback will be made in user context with a gbuf
-    when it is received.  To stop receiving messages, call
-    gb_deregister_cport_complete() for a specific cport.
-
-
-  Greybus Host controller drivers need to provide
-    - a way to allocate the transfer buffer for a gbuf
-    - a way to free the transfer buffer for a gbuf when it is "finished"
-    - a way to submit gbuf for transmissions
-    - notify the core the gbuf is complete
-    - receive gbuf from the wire and submit them to the core
-    - a way to send and receive svc messages
-  Allocate a transfer buffer
-    the host controller function alloc_gbuf_data is called
-  Free a transfer buffer
-    the host controller function free_gbuf_data is called
-  Submit a gbuf to the hardware
-    the host controller function submit_gbuf is called
-  Notify the gbuf is complete
-    the host controller driver must call greybus_gbuf_finished()
-  Submit a SVC message to the hardware
-    the host controller function send_svc_msg is called
-  Receive gbuf messages
-    the host controller driver must call greybus_cport_in() with the data
-  Reveive SVC messages from the hardware
-    The host controller driver must call greybus_svc_in
-
-
-*/
-
-struct gbuf {
-       struct greybus_host_device *hd;
-       u16 dest_cport_id;              /* Destination CPort id */
-       int status;
-
-       void *transfer_buffer;
-       u32 transfer_buffer_length;
-
-       void *hcd_data;                 /* for the HCD to track the gbuf */
-};
-
-
 /* For SP1 hardware, we are going to "hardcode" each device to have all logical
  * blocks in order to be able to address them as one unified "unit".  Then
  * higher up layers will then be able to talk to them as one logical block and
@@ -142,6 +68,7 @@ struct gbuf {
 
 struct greybus_host_device;
 struct svc_msg;
+struct gbuf;
 
 /* Greybus "Host driver" structure, needed by a host controller driver to be
  * able to handle both SVC control as well as "real" greybus messages

diff --git a/drivers/staging/greybus/operation.h b/drivers/staging/greybus/operation.h
index dc15c2f61e30a1cf5a552e5a0744b389b34d9a2b..c19313608e81b27d5fe8c3c96a7c2e25724a74d7 100644 (file)
--- a/drivers/staging/greybus/operation.h
+++ b/drivers/staging/greybus/operation.h
@@ -11,6 +11,8 @@
 
 #include <linux/completion.h>
 
+struct gb_operation;
+
 enum gb_operation_status {
        GB_OP_SUCCESS           = 0,
        GB_OP_INVALID           = 1,
@@ -22,6 +24,17 @@ enum gb_operation_status {
        GB_OP_TIMEOUT           = 0xff,
 };
 
+struct gbuf {
+       struct greybus_host_device *hd;
+       u16 dest_cport_id;              /* Destination CPort id */
+       int status;
+
+       void *transfer_buffer;
+       u32 transfer_buffer_length;
+
+       void *hcd_data;                 /* for the HCD to track the gbuf */
+};
+
 /*
  * A Greybus operation is a remote procedure call performed over a
  * connection between the AP and a function on Greybus module.
@@ -50,7 +63,6 @@ enum gb_operation_status {
  * is guaranteed to be 64-bit aligned.
  * XXX and callback?
  */
-struct gb_operation;
 typedef void (*gb_operation_callback)(struct gb_operation *);
 struct gb_operation {
        struct gb_connection    *connection;