From 3c3cef400ea7eadc87a66a974cd9e388ad99640a Mon Sep 17 00:00:00 2001 From: Alex Elder Date: Mon, 17 Nov 2014 18:08:30 -0600 Subject: [PATCH] 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 Signed-off-by: Greg Kroah-Hartman --- drivers/staging/greybus/greybus.h | 75 +------------------------------------ drivers/staging/greybus/operation.h | 14 ++++++- 2 files changed, 14 insertions(+), 75 deletions(-) diff --git a/drivers/staging/greybus/greybus.h b/drivers/staging/greybus/greybus.h index 1731700..d6bfe6b 100644 --- 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 dc15c2f..c193136 100644 --- a/drivers/staging/greybus/operation.h +++ b/drivers/staging/greybus/operation.h @@ -11,6 +11,8 @@ #include +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; -- 2.7.4