- 02 Dec, 2014 6 commits
-
-
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 <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
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 <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
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 <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
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 <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
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: Alex Elder <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
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: Greg Kroah-Hartman <greg@kroah.com>
-
- 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 <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
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 <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
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 <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
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 <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
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 <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
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 <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
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 <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
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: Alex Elder <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
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: Greg Kroah-Hartman <greg@kroah.com>
-
- 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 <greg@kroah.com>
-
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 <greg@kroah.com> Reviewed-by: Alex Elder <elder@linaro.org>
-
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 <greg@kroah.com> Reviewed-by: Alex Elder <elder@linaro.org>
-
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 <greg@kroah.com> Reviewed-by: Alex Elder <elder@linaro.org>
-
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 <greg@kroah.com> Reviewed-by: Alex Elder <elder@linaro.org>
-
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 <greg@kroah.com> Reviewed-by: Alex Elder <elder@linaro.org>
-
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 <greg@kroah.com> Reviewed-by: Alex Elder <elder@linaro.org>
-
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: Greg Kroah-Hartman <greg@kroah.com> Reviewed-by: Alex Elder <elder@linaro.org>
-
- 22 Nov, 2014 9 commits
-
-
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: Alex Elder <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
Alex Elder authored
When a caller wants an operation to complete synchronously, there is generally no need for any other threads to wait for the operation's completion. So here's no need for gb_operation_wait() to be available for synchronous requests. At the moment, all operations are done synchronously. Knowing that, get rid of the public gb_operation_wait() function, and open-code it in gb_operation_request_send(). The public wait function can be re-implemented when it's really needed. With that function gone, the only waiter for the completion of an operation is the submitter itself, and only then if it's synchronous. So rather than complete_all(), we can simply use complete() to signal the submitter. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
Alex Elder authored
Cancel the operation--not just the request message--if waiting for a synchronous operation to complete is interrupted. Return the operation result (which in that case will be -EINTR). The cancelation will result in the normal operation completion path being taken before returning. Make gb_operation_wait() private, since it's only ever used for for synchronous operations. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
Alex Elder authored
If an operation times out, we need to cancel whatever message it has in-flight. Do that instead of completing the operation, in the timeout handler. When the in-flight request message is canceled its completion function will lead to the proper completion of the operation. Change gb_operation_cancel() so it takes the errno that it's supposed to assign as the result of the operation. Note that we want to preserve the original -ETIMEDOUT error, so don't overwrite the operation result value if it has already been set. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
Alex Elder authored
Any time we queue work on the operation work queue we need to have set the operation errno first. This patch moves the assignment of that field to be immediately prior to the queue_work() call in gb_connection_recv_response(), so it is easier to see at a glance that this has been done. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
Alex Elder authored
Grab an extra reference to an operation before sending it. Drop that reference at the end of its completion handling. It turns out gb_operation_get() got deleted along the way, so this re-introduces it. We're assuming we only get a reference when there's at least one in existence so we don't need a semaphore to protect it. Emphasize this by *not* returning a pointer to the referenced operation. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
Alex Elder authored
The data sent callback can execute in atomic context. If an error occurred, we shouldn't be completing the operation right then and there. Instead, hand it off to the operation workqueue to complete the operation. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
Alex Elder authored
Change the operation "receive workqueue" to be just the operation "workqueue". All it does is complete an operation in non-atomic context. This is all that's required for an outgoing request. Similarly, ignore any notion that a response will only exist for outgoing requests in gb_operation_cancel(). I'm doing this in the interest of getting the outgoing request path verified without the encumbrance of any preconceptions about how incoming requests need to work. When I finally turn my full attenion to incoming requests I'll adapt the code as needed. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
Alex Elder authored
An in-core operation structure tracks the progress of an operation. Currently it holds a result field that was intended to take the status value that arrives in an operation response message header. But operations can fail for reasons other than that, and it's inconvenient to try to represent those using the operation status codes. So change the operation->result field to be an int, and switch to storing negative errno values in it. Rename it "errno" to make it obvious how to interpret the value. This patch makes another change, which simplifies the protocol drivers a lot. It's being done as part of this patch because it affects all the same code as the above change does. If desired I can split this into two separate patches. If a caller makes a synchronous gb_operation_request_send() request (i.e., no callback function is supplied), and the operation request and response messages were transferred successfully, have gb_operation_request_send() return the result of the request (i.e., operation->errno). This allows the caller (or more generally, any caller of gb_request_wait() to avoid having to look at this field for every successful send. Any caller that does an asynchronous request will of course need to look at request->errno in the callback function to see the result of the operation. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
- 21 Nov, 2014 8 commits
-
-
Viresh Kumar authored
Reviewed-by: Alex Elder <elder@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
Alex Elder authored
This function is associated with a host device (interface), not a CPort. Change its name to reflect that, and to match its "sent" callback counterpart. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
Alex Elder authored
Define greybus_data_sent(), which is a callback the host driver makes when a buffer send request has completed. The main use for this is to actively detect errors that can occur while sending. (Something like this existed at one time and was removed.) This also defines gb_hd_message_find(), which looks up a message pointer associated with a buffer sent over a given host device. This is now a pretty trival mapping. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
Alex Elder authored
Embed the buffer for message data into the message structure itself. This allows us to use a single allocation for each message, and more importantly will allow us to derive the message structure describing a message from the buffer itself. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
Alex Elder authored
Have an operation's request and response messages be dynamically allocated rather than embedded in an operation. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
Alex Elder authored
The beginning of an operation message always contains the message header. Rename the "buffer" field in an operation message to be "header" to reflect this. Change its type as well. The size of a message is the combined size of its header and its payload. Rename the "buffer_size" field in a message header to be simply "size", so message->size describes exactly that. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
Alex Elder authored
Rather than having the host driver allocate the buffers that the Greybus core uses to hold its data for sending or receiving, have the host driver define what it requires those buffers to look like. Two constraints define what the host driver requires: the maximum number of bytes that the host device can send in a single request; and a statement of the "headroom" that needs to be present for use by the host device. The direct description of the headroom is that it's the extra byte the host device needs at the beginning of the "data" portion of the buffer so the ES1 driver can insert the destination CPort id. But more generally, the host driver could put other data in there as well. By stating these two parameters, Greybus can allocate the buffers it uses by itself. The host driver still allocates the buffers it uses for receiving data--the content of those are copied as needed into Greybus buffers when data arrives. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
Alex Elder authored
If a response arrives for an operation request and the allotted buffer isn't big enough we report the error, but we don't finish processing the response. Instead, set the operation result, but then finish processing the response (no different from any other operation error). This will allow the normal completion handling to occur for this error case. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-