- 20 Nov, 2014 2 commits
-
-
Alex Elder authored
This fixes a problem similar to what was found in the battery protcool driver code. There's no need to allocate a local buffer, that already set up by gb_operation_create(). Just use that instead. Change a few variable names to reflect that they hold response messages, not request messages. Signed-off-by:
Alex Elder <elder@linaro.org> Signed-off-by:
Greg Kroah-Hartman <greg@kroah.com>
-
Alex Elder authored
This patch fixes some problems with the battery protocol driver. First, when gb_operation_create() is called, it creates buffers of the requested sizes to hold the operation request and response messages. There is therefore no reason to allocate a local response buffer. By the time the (synchronous) gb_operation_request_send() call returns, the operation response buffer will have been filled in. (In addition, the content of local_response was not being filled before its contents were used...) Next, all the message structures are misnamed. The structures that are defined are all the content of operation response messages (not request messages). So this changes all the types names to properly reflect their role. All the local variables using these types are similarly renamed. I added a new type, gb_generic_battery_response, to be used for casting the fake_response used in battery_operation(). Signed-off-by:
-
- 19 Nov, 2014 11 commits
-
-
Viresh Kumar authored
Signed-off-by:
Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by:
-
Alex Elder authored
Define two helper functions to break down handling of a received message. One is used to handle receiving an incoming request message, the other for a response message. Three other changes are made: - We verify message size recorded in the message header does not exceed the amount of data that's arriving. - We no longer warn if a request' recorded message size differs from the number of bytes that have arrived. - We now record the operation id for an incoming request. Signed-off-by: -
Alex Elder authored
A message header contains a field "id" that is an operation id. Since the field doesn't identify the message itself, rename this field so it's clearer what it's referring to. Similarly gb_pending_operation_find() has a parameter "id" that is really an operation id, so rename that as well. Signed-off-by:
-
Alex Elder authored
We (sort of) maintain the status of each message, but we shouldn't need to. Right now we're not using it consistently in any case. If a message fails to send, the caller will know to destroy the operation that contained it. If a message has been sent (i.e., handed to the host device layer) it'll have a non-null cookie pointer. If a does complete in error, we can update the status of the operation that contains it. That isn't happening right now but it will soon. Signed-off-by:
-
Alex Elder authored
The only use of local variable "es1" in in svc_in_callback() and cport_in_callback() is to get at its hd field. But we already have that, so we can get rid of that local variable. Also, rename the "cport" variable "cport_id" in cport_in_callback() is to match the convention used elsewhere, and make it the proper u16 type. Signed-off-by:
-
Alex Elder authored
Use simple macros to mark the conversion of an URB pointer into an opaque cookie value (and vice-versa). We scramble some bits, but the main point is to make it explicit where we're returning and using opaque values. Signed-off-by:
-
Viresh Kumar authored
Signed-off-by:
-
Viresh Kumar authored
Signed-off-by:
-
Viresh Kumar authored
Signed-off-by:
-
Viresh Kumar authored
Signed-off-by:
-
Greg Kroah-Hartman authored
s/i2c/vibrator/ Signed-off-by:
-
- 18 Nov, 2014 27 commits
-
-
Greg Kroah-Hartman authored
-
Alex Elder authored
The only reason gb_operation_message_init() gets its "outbound" argument is so we can determine what allocation flags to use. Just pass the flags in directly instead. Signed-off-by:
-
Alex Elder authored
We can derive the destination CPort id of any (outbound) message from the connection it's operation is associated with. So we don't need to store that information in every message. As a result, we no longer need to record it at message initialization time. Signed-off-by:
-
Alex Elder authored
The host device pointer doesn't have to be stored in every message. It can be derived by following up the chain of pointers back to the operation's connection. Signed-off-by:
-
Alex Elder authored
All the code has now been adjusted such that we can do away with the old gbuf structure. Three unused references remained in "greybus.h", so those are deleted. Other than that most of the changes were done by simple global substitution. The gb_message structure incorporates the fields that were previously found its embedded gbuf structure. A few names have been changed in the process: gbuf->transfer_buffer message->buffer gbuf->transfer_buffer_size message->buffer_size gbuf->hcd_data; message->cookie Signed-off-by: -
Alex Elder authored
Rework gb_connection_operation_recv() to be more oriented toward an operation message, and to no longer use a struct gbuf local variable. Rename it to be a little more wieldy. Signed-off-by:
-
Alex Elder authored
Rework greybus_kill_gbuf() to be oriented toward an operation message rather than a gbuf, and rename it. Signed-off-by:
-
Alex Elder authored
Rework greybus_submit_gbuf() to be oriented toward an operation message rather than a gbuf, and rename it accordingly. Signed-off-by:
-
Alex Elder authored
Rework gb_opreation_message_init() so it doesn't use a struct gbuf local variable. Signed-off-by:
-
Alex Elder authored
Change the method that sends messages so that it sends "raw" buffers rather than gbufs. To do this, we supply the host device and destination CPort when sending. As with other recent patches, change the name of the method to reflect that we're no longer dealing with gbufs. The interface has changed as well. Now this routine will return a "cookie" value. The cookie is used to represent the outgoing request, and is supplied by the caller if necessary to cancel a previously-sent buffer. We'll store the result in gbuf->hcd_data for now (which produces the same result as before...). Signed-off-by:
-
Alex Elder authored
This changes the context value stashed with each USB URB so that it is always the host device pointer. In cport_out_callback() this allows us to get away with *not* requiring the gbuf for handling completions any more. We are (currently) ignoring the gbuf status value returned anyway, so we'll skip setting it altogether. Greg's comments in cport_out_callback() point out that ignoring this was misguided, and handling send errors will be put in place in an upcoming patch. The context is set to the host device pointer for SVC receive and CPort receive URBs for consistency--because we can. Signed-off-by:
-
Alex Elder authored
Change the interface for canceling in-flight buffers to take a magic cookie value as argument rather than a gbuf. Right now we pass the gbuf->hcd_data pointer that's assumed to have been set by the submit routine. But the next patch will change the submit routine to return the cookie to be used, and the caller will be responsible for keeping track of it. Signed-off-by:
-
Alex Elder authored
Switch the host driver free routine to take a pointer to the previously-allocated buffer that should be freed. Rename the method to reflect it's no longer tied to a gbuf. Signed-off-by:
-
Alex Elder authored
This begins the transition to buffer allocation that does not rely on the gbuf construct. The host driver allocation routine will return a pointer to the buffer to be used, and the caller will be responsible for keeping track of that pointer, as well as the requested buffer size. Rename the allocation method to reflect it's no longer tied to a gbuf. Signed-off-by:
-
Alex Elder authored
For ES1 we need to insert the destination CPort id before the data to be sent over UniPro. Currently this is done at the time the buffer is created, but there's no need to do so until we're actually going to send the content of the buffer. Move the setting of that destination information into submit_gbuf(). Note that this allows us to defer initializing a few other gbuf fields until after we know the buffer allocation has succeeded. Signed-off-by:
-
Alex Elder authored
For ES1 we need to insert the destination CPort id in whatever we supply for sending over UniPro. Currently we allocate one extra byte supply the caller with an address that's offset by one from the beginning of the allocated space. As a result we always return a poorly-aligned buffer pointer. Instead, allocate enough space so that we can return a better aligned buffer to the caller. Notes: - It may be that it's more important to supply an aligned address to the hardware. - We probably need to be more careful about writing into these buffers at unaligned offsets anyway. (E.g., writing a 2-byte value at an odd offset can't be assumed to work.) Signed-off-by: -
Alex Elder authored
Treat communication buffers for both inbound and outbound data the same way, prepending a "destination cport id" byte before the data in the buffer. Currently this is done only for outbound data buffers. This isn't needed for inbound data, but handling it this way allows the free routine to work without knowing whether the buffer was used for sending or receiving. Signed-off-by:
-
Alex Elder authored
We allocate message buffers with GFP_KERNEL allocation flags if possible. However when an incoming request message is received we can be in interrupt context, so we must use GFP_ATOMIC in that case. The computation of gfp_flags in gb_operation_message_init() is wrong. It is needlessly using GFP_ATOMIC when allocating outbound response buffers. Fix the flawed logic. Change the name of "data_out" to be "outbound" to be consistent with usage elsewhere. (Data/messages are "inbound" or "outbound"; requests are "incoming" or "outgoing".) Signed-off-by:
-
Greg Kroah-Hartman authored
responses changed in 'master' so fix up things so that the vibrator driver works properly. Signed-off-by: -
Greg Kroah-Hartman authored
-
Alex Elder authored
Only three functions remain in "gbuf.c". Move one of them into "connection.c" and the other two into "operation.c". Some more cleanup is coming that will further straighten out gbufs but for now there's no sense in drawing this out any longer. Signed-off-by:
-
Alex Elder authored
Nobody dynamically allocates gbufs any more, so we can get rid of the allocation and free routines, as as the slab cache and its related code. Signed-off-by:
-
Alex Elder authored
Embed the gbuf structures for operation messages into the message structure rather than pointing to a dynamically allocated one. Use a null gbuf->transfer_buffer pointer rather than a null gbuf pointer to indicate an unused gbuf. Signed-off-by:
-
Alex Elder authored
Make sure gbuf->transfer_buffer gets reset to NULL when the buffer is freed. We can leverage that to do a little extra error checking. We'll also use a null transfer buffer in the next patch to indicate an unused gbuf. Signed-off-by:
-
Alex Elder authored
Change greybus_alloc_gbuf() so all it does is allocate the gbuf data structure. Move all of the initialization of the gbuf structure in the caller. Do the inverse in the caller prior to freeing the gbuf structure via greybus_free_gbuf(). Use a null gbuf->transfer_buffer pointer rather than a null gbuf pointer to indicate an unused gbuf. Signed-off-by:
-
Alex Elder authored
This converts some of the operation code to start leveraging the new gb_message type. Instead of creating the request and response gbufs, we initialize (and tear down with a new function) the request and response message structures. Signed-off-by:
-
Alex Elder authored
A Greybus buffer (gbuf) is a generic buffer used for data transfer over a Greybus interconnect. We only ever use gbufs in operations, which always involve exactly two of them. The lifetime of a gbuf is therefore directly connected to the lifetime of an operation, so there no real need to manage gbufs separate from operations. This patch begins the process of removing the gbuf abstraction, on favor of a new data type, gb_message. The purpose of a gb_message is--like a gbuf--to represent data to be transferred over Greybus. However a gb_message is oriented toward the more restrictive way we do Greybus transfers--as operation messages (either a request or a response). This patch simply defines the structure in its initial form, and defines the request and response fields in a Greybus operation structure as embedded instances of that type. The gbuf pointer is defined within the gb_message structure, and as a result lots of code needs to be tweaked to reference the request and response gbufs as subfields of the request and response structures. Signed-off-by:
-
