- 02 Dec, 2014 22 commits
-
-
Alex Elder authored
The memcpy of request data into the request payload was copying the data into the wrong location. Fix that. Signed-off-by:
Alex Elder <elder@linaro.org> Signed-off-by:
Greg Kroah-Hartman <greg@kroah.com>
-
Alex Elder authored
The PWM config request defines two 32-bit values using u32. All over-the-wire values have to be in little-endian format. Fix this. Signed-off-by:
Matt Porter <mporter@linaro.org> Signed-off-by:
-
Alex Elder authored
Define a helper function gb_operation_response_alloc() and use it to allocate the response buffer for outgoing operations in gb_operation_create_common(. Use it also in gb_operation_response_send() if the caller has not allocated a response buffer. Once a response buffer is allocated, fill in its result code and send it. Signed-off-by:
-
Alex Elder authored
Define gb_operation_errno_map(), which maps an operation->errno into the u8 value that represents it in the status field of an operation response header. It'll be used in an upcoming patch. Make gb_operation_status_map() a private function. It's not used outside "operation.c" and I don't believe it ever should be. Signed-off-by:
-
Alex Elder authored
Un-comment gb_operation_request_handle(), which was recently disabled to avoid distraction. In gb_connection_recv_request(), activate handling incoming requests by defining gb_operation_request_handle() as an incoming operation's callback function. Incoming operation requests have Signed-off-by:
-
Alex Elder authored
Change gb_operation_response_send() so it takes an errno to assign as an operation's result. This emphasizes that setting the result should be the last thing done to an incoming operation before sending its response. Signed-off-by:
-
Alex Elder authored
A large number of request and response message types have no payload. Such "simple" messages have a known, fixed maximum size, so we can preallocate and use a pool (slab cache) of them. Here are two benefits to doing this: - There can be (small) performance and memory utilization benefits to using a slab cache. - Error responses can be sent with no payload; the cache is likely to have a free entry to use for an error response even in a low memory situation. The plan here is that an incoming request handler that has no response payload to fill will not need to allocate a response message. If no message has been allocated when a response is to be sent, one will be allocated from the cache by the core code. Signed-off-by: -
Alex Elder authored
Define a maximum size that a host device can use for its private area ahead of the payload space used by Greybus in a message buffer. Signed-off-by:
-
Alex Elder authored
Separate the allocation of a message structure from its basic initialization. This will allow very common fixed-size operation response buffers to be allocated from a slab cache. Signed-off-by:
-
Alex Elder authored
When incoming data is going to be handled as a request, we create a new operation whose request buffer will hold the received data. There is no need to initialize the message header in such a request buffer because it will be immediately overwritten. Use operation type value of 0x00 in gb_operation_create_common() to signal that we are creating an incoming operation, and therefore do not need to initialize the request message header. This allows us to get rid of the Boolean "outgoing" parameter. As a result, we can stop supplying the "type" parameter to both gb_operation_create_incoming() and gb_connection_recv_request(). Update the header comments for gb_operation_message_alloc() and gb_operation_create_common(). Signed-off-by:
-
Alex Elder authored
The operation type 0x00 is reserved as an explicitly invalid operation type in all protocols. Enforce this. Add a check for callers who erroneously have the RESPONSE message type flag set in the operation type passed in gb_operation_create(). Signed-off-by:
-
Alex Elder authored
Pass the operation result to gb_connection_recv_response() as a parameter. Signed-off-by:
-
Alex Elder authored
We enforce a rule that a response message must completely fill the buffer that's been allocated to hold it. However, if an error occurs, the payload is off limits, so we should allow a short message to convey an error result. Change gb_connection_recv_response() to require the right message size only if there's no error. One other thing: The arriving data is only being copied into the response buffer if the request was successful. That means the response message header is assumed to have been initialized. That isn't a valid assumption. So change it so that if an error is seen, the header portion of the message is copied into the response buffer--but only the header. Signed-off-by:
-
Alex Elder authored
Currently incoming request data is copied into a request message buffer in gb_connection_recv_request(). Move that--along with the assignment of the message id--into gb_operation_create_incoming(). Signed-off-by:
-
Greg Kroah-Hartman authored
gb_connection_recv_request should be static, so mark it as such. Signed-off-by: -
Alex Elder authored
Currently we issue a warning in gb_operation_work() if an operation has no callback function defined. But we return without dropping the reference to the operation as we should. Stop warning if there's no callback, call it only if it's defined, and always drop the operation reference before returning. This means we're now treating a NULL callback pointer as a normal condition. Signed-off-by:
-
Alex Elder authored
We will only send messages from process context. Drop the gfp_mask parameter from gb_message_send(), and just supply GFP_KERNEL to the host driver's buffer_send method. Signed-off-by:
-
Alex Elder authored
Define a new operation status GB_OP_MALFUNCTION, which will be used to represent that something unexpected happened while handling an operation. This is intended as an indication similar to a BUG() call--whatever went wrong should *never* happen and because it's unexpected we need to treat it as a fatal error. Define another new operation status GB_OP_UNKNOWN_ERROR, which will represent the case where an operation ended in error, but the error was not recognized to be properly represented by one of the other status values. Renumber the operation status values, defining those that are produced by core operations code ahead of those that are more likely to come from operation handlers. Represent the values in hexadecimal to emphasize that they must be represented with 8 bits. The Use 0xff for GB_OP_MALFUNCTION instead of GB_OP_TIMEOUT; the latter is special, but a malfunction is in a class by itself. Reorder the cases in gb_operation_status_map() to match their numeric order. Map GB_OP_UNKNOWN_ERROR to -EIO in gb_operation_status_map(). Map GB_OP_MALFUNCTION to -EILSEQ in gb_operation_status_map(), since that value is used to represent an implementation error. Signed-off-by:
-
Alex Elder authored
Reserve operation result code -EILSEQ to represent that the code that implements an operation is broken. This is used (initially) for any attempt to set the result to -EBADR (which is reserved for an operation in initial state), or for an attempt to set the result of an operation that is *not* in initial state to -EINPROGRESS. Note that we still use -EIO gb_operation_status_map() to represent a gb_operation_result value that isn't recognized. In gb_operation_result(), warn if operation->errno is -EBADR. That is another value that indicates the operation is not in a state where it's valid to query an operation's result. Update a bunch of comments above gb_operation_result_set() to explain constraints on operation->errno. Signed-off-by:
-
Alex Elder authored
We represent the size of a message using a 16-bit field. It's possible for a host driver to advertise a maximum message size that's bigger than that. If that happens, reduce the host device's maximum buffer size to the maximum we can represent the first time a message is allocated. This information is actually only used by the Greybus code, but because we're modifying a value that's "owned" by the host driver, issue a warning when this limit is being imposed Ensure (at build time) that our own definition is sane as well. Signed-off-by:
-
Alex Elder authored
In gb_operation_create_common(), a zero response size is still being used to determine whether to use GFP_KERNEL or GFP_ATOMIC when allocating a message. Use the value of the "outgoing" parameter to decide this instead. Signed-off-by:
-
Greg Kroah-Hartman authored
Based on Fabien's original driver, this version is converted (mostly) to the new greybus operation apis. Lots of things still to do, not the least being hooking up proper responses... Signed-off-by:
-
- 25 Nov, 2014 9 commits
-
-
Alex Elder authored
When a Greybus message is sent, the host driver supplies a cookie for Greybus to use to identify the sent message in the event it needs to be canceled. The cookie will be non-null while the message is in flight, and a null pointer otherwise. There are two problems with this, which arise out of the fact that a message can be canceled at any time--even concurrent with it getting sent (such as when Greybus is getting shut down). First, the host driver's buffer_send method can return an error value, which is non-null but not a valid cookie. So we need to ensure such a bogus cookie is never used to cancel a message. Second, we can't resolve that problem by assigning message->cookie only after we've determined it's not an error. The instant buffer_send() returns, the message may well be in flight and *should* be canceled at shutdown, so we need the cookie value to reflect that. In order to avoid these problems, protect access to a message's cookie value with a mutex. A spin lock can't be used because the window that needs protecting covers code that can block. We reset the cookie value to NULL as soon as the host driver has notified us it has been sent (or failed to). Signed-off-by:
-
Alex Elder authored
It's possible for an in-flight buffer to be recorded as sent *after* a thread has begin the process of canceling it. In that case the Greybus message cookie will be set to NULL, and that value can end up getting passed to buffer_cancel(). Change buffer_cancel() so it properly handles (ignores) a null cookie pointer. Signed-off-by:
-
Alex Elder authored
An operation result can be set both in and out of interrupt context. For example, a response message could be arriving at the same time a timeout of the operation is getting processed. We therefore need to ensure the result is accessed atomically. Protect updates to the errno field using the operations spinlock. Signed-off-by:
-
Alex Elder authored
When an operation is created its receive buffer size is specified. In all current cases, the size supplied for the receive buffer is exactly the size that should be returned. In other words, if any fewer than that many bytes arrived in a response, it would be an error. So tighten the check on the number of bytes arriving for a response message, ensuring that the number of bytes received is *exactly the same* as the number of bytes available (rather than just less than). We'll expand our interpretation of of -EMSGSIZE to mean "wrong message size" rather than just "message too long." If we someday encounter an actual case where we want to be able to successfully receive something less than the full receive buffer we can adjust the code to handle that (and give it a way to tell the receiver how many bytes are present). Signed-off-by:
-
Alex Elder authored
Change the message result values used in two cases. First, use -EMSGSIZE rather than -E2BIG to represent a message that is larger than the buffer intended to hold it. That is the proper code for this situation. Second, use -ECANCELED rather than -EINTR for an operation that has been canceled. The definition of that error is literally "Operation Canceled" so it seems like the right thing to do. Signed-off-by:
-
Alex Elder authored
This is more or less re-implementing this commit: 96f95d4 greybus: update gbuf status for completion handlers But this time we're doing this for an operation, not the gbuf. Define an initial operation result value (-EBADR) to signify that no valid result has been set. Nobody should ever set that value after the operation is initially created. Since only the operation core code sets the result, an attempt to set -EBADR would be a bug. Define another known operation result value (-EINPROGRESS) for an outgoing operation whose request has been sent but whose response has not yet been successfully received. This should the first (non-initial) result value set, and it should happen exactly once. Any other attempt to set this value once set would be a bug. Finally, once the request message is in flight, the result value will be set exactly once more, to indicate the final result of the operation. Signed-off-by: -
Alex Elder authored
If an operation already has an error result recorded, don't overwrite it with a new error code. In order to ensure a request completes exactly once, return a Boolean indicating whether setting the result was successful. If two threads are racing to complete an operation (for example if a slow-but-normal response message arrives at the same time timeout processing commences) only the one that sets the final result will finish its activity. Signed-off-by:
-
Alex Elder authored
Hide the setting and getting of the operation result (stored in operation->errno) behind a pair of accessor functions. Only the operation core should be setting the result, but operations that complete asynchronously will need access to the result so expose the function that provides that. Signed-off-by:
-
Greg Kroah-Hartman authored
We always pass the same option to send_line_coding() for the line_coding structure, which is already in the struct gb_tty variable, so just remove the second parameter as it's not needed. This logic came from the cdc-acm.c driver, where it's also not needed anymore, I'll go fix up that later on when I get a chance. Signed-off-by:
-
- 24 Nov, 2014 8 commits
-
-
Viresh Kumar authored
greybus_remove_hd() will free memory allocated to 'es1' and so using it after the routine has returned isn't right. Signed-off-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
-
Greg Kroah-Hartman authored
This converts the PWM protocol driver to use gb_operation_sync, removing lots of places where the create/send/destroy pattern was being used to send greybus messages. Signed-off-by:
-
Greg Kroah-Hartman authored
This converts the I2C protocol driver to use gb_operation_sync, removing lots of places where the create/send/destroy pattern was being used to send greybus messages. Signed-off-by:
-
Greg Kroah-Hartman authored
This converts the GPIO protocol driver to use gb_operation_sync, removing lots of places where the create/send/destroy pattern was being used to send greybus messages. Signed-off-by:
-
Greg Kroah-Hartman authored
This converts the UART protocol driver to use gb_operation_sync, removing lots of places where the create/send/destroy pattern was being used to send greybus messages. Signed-off-by:
-
Greg Kroah-Hartman authored
This converts the vibrator protocol driver to use gb_operation_sync, removing the hand-rolled version of the same function, as well as removing an open-coded version for a request when turning on the vibrator motor. Signed-off-by:
-
Greg Kroah-Hartman authored
This converts the battery protocol driver to use gb_operation_sync, removing the hand-rolled version of the same function. Signed-off-by:
-
Greg Kroah-Hartman authored
Everyone keeps doing the same create/send/destroy logic all over the place, so abstract that out to a simple function that can handle any arbritrary request and/or response. This will let us save lots of duplicated logic in the protocol drivers. Signed-off-by:
-
- 22 Nov, 2014 1 commit
-
-
Alex Elder authored
The only time we need a completion signaled on a request is when the request provided no callback function. In that case, we wait for a completion on behalf of the caller. If an interrupt occurs, we attempt to cancel the message that's been sent, but we don't actually complete the operation as required. Instead of simply waiting for the completion, put in place a special callback function for the synchronous operation. The only job the callback has is to signal completion, allowing the waiter to know it's done. This means gb_operation_complete() will always have a non-null callback pointer, so it becomes a simple wrapper, and we can get rid of it and invoke the callback directly, in gb_operation_work(). Be defensive by checking for a null callback pointer, and reset it to NULL once it's been called. Signed-off-by:
-
