Hi Matt, "Matthew R. Ochs" <mro...@linux.vnet.ibm.com> writes: > The purpose for the count is so the AFU driver is only called when it > has something to send. Otherwise we don't want to be called.
Agreed, but this opens up a possible boundary condition where in we have non-zero event count and deliver_event callback returns a NULL/empty struct (This isn't handled correctly at the moment). Imo the condition event-count == number-of-calls-to-deliver_events is bit too rigid. Instead a more relaxed condition can be number-of-calls-to-deliver_event == count-until-deliver_event-returns-NULL. This could be implemented as boolean flag inside the context to indicate that afu-driver has some events queued. This flag can be set when cxl_context_events_pending gets called. The cxl code can simply call deliver_event on each read call untill it returns NULL in which case this boolean flag is reset. This should slightly simplify the code flow at the afu-driver end as enquing to an event need not be paired by a call to cxl_context_events_pending. It can quite possibly enqueue bunch of events and then do a single call to cxl_context_events_pending. In this case the function cxl_context_events_pending essentially works more like a function named as cxl_context_events_flush. ~ Vaibhav _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev