V3: Picard: "Let's make sure history never forgets the name ... Enterprise." Drop gb_operation_cancel_async. The sync version works just as well - Johan V2: Scotty : "What are you standing around for - do you not know a jailbreak when you see one" ? Making sure to run format-patch against the right tree this time.. Updated meta-comments to highlight adding a generic async timeout - Johan Captured the result code of schedule_work/queue_work - Bryan Drop reference count on failure to submit schedule_work/queue_work - Bryan Added timeout suffix back to new gb_operation_request_send - Johan/Greg Updated Signed-off-by to my nexus-software.ie address - Bryan Iterated requisite Star Trek Quote - Bryan/Johan V4-private -> V1-public: McCOY: You've got him, Jim! You've got him where you want him. This patchset adds async operations to greybus-core. Rather than have different drivers do variations on the same theme of launching and timing out asynchronous operations, it makes sense instead to provide this functionality via greybus-core. This patchset makes it possible to launch asynchronous operations and have the completion callback for an operation indicate -ETIMEDOUT for timeouts without drivers having to manage that locally. This set doesn't convert the existing synchronous operations away from wait_for_completion_interruptible_timeout() since that would involve adding an extra work-queue item to each synchronous call, with no added benefit for synchronous operations. Synchronous operations can already detect -ETIMEDOUT by blocking on the synchronous send operations, asynchronous operations and the driver associated with those operations OTOH must implement a completion handler. The main improvement this patchset makes is to pass the -ETIMEDOUT completion status into that completion handler - hiding the setup/timeout of operations away from a driver-level and into a core-level set of logic. Loopback as an example can have lots and lots of redundant code removed and given we previously had some in-flight effort to add asynchronous operations to SDIO it makes sense to move the generic types of things we need to do on the asynchronous path into greybus-core so that SDIO and other bundle drivers can reuse instead of reimplement asynchronous operations. Note: we had approximately three internal versions of this on Project-Ara. Here's the log for completeness. V3-private -> V4-private: Fix bug in loopback conversion - Mitch Tasman V2-private -> V3-private: remotes/ara-main/sandbox/bodonoghue/ara-main-current+async_op3 Drop patch #6 converting sync operations to new t/o structure. Johan had a concern about doing an in-depth analysis on that change and considering our compressed timelines now, this analysis won't happen. OTOH the new async API is the right thing for loopback and for potential later greybus users/implementers to reuse. Although it wasn't part of the motive for this change - I observe slightly better performance than baseline with loopback tests with this change in place - which shouldn't be surprising since we have less aggregate context switching for operation timeouts. V1-private -> V2-private: Rename async_private => private - Greg gb_operation_request_send_async_timeout -> gb_operation_request_send_async() - Greg Using existing gb_operation_completion_wq - Viresh Split out gb_operation_cancel() - timeout need not wait synchronously on cancellation queue - Bryan Move timeout to work-queue - Greg/Viresh cancel timeout workqueue @ operation completion point - Viresh/Bryan Bryan O'Donoghue (4): staging: greybus: operation: add generic asynchronous timeout operation support staging: greybus: operation: add private data with get/set accessors staging: greybus: loopback: convert loopback to use generic async operations staging: greybus: loopback: convert to use msecs internally drivers/staging/greybus/loopback.c | 181 ++++++++---------------------------- drivers/staging/greybus/operation.c | 66 +++++++++++++ drivers/staging/greybus/operation.h | 18 ++++ 3 files changed, 123 insertions(+), 142 deletions(-) -- 2.7.4 _______________________________________________ greybus-dev mailing list greybus-dev@xxxxxxxxxxxxxxxx https://lists.linaro.org/mailman/listinfo/greybus-dev
![]() |