[v7, 1/2] cxl: Add mechanism for delivering AFU driver specific events

[Matthew R. Ochs]

> On Jun 23, 2016, at 8:03 AM, Philippe Bergheaud <felix at linux.vnet.ibm.com> wrote:
> 
> This adds an afu_driver_ops structure with fetch_event() and
> event_delivered() callbacks. An AFU driver such as cxlflash can fill
> this out and associate it with a context to enable passing custom AFU
> specific events to userspace.
> 
> This also adds a new kernel API function cxl_context_pending_events(),
> that the AFU driver can use to notify the cxl driver that new specific
> events are ready to be delivered, and wake up anyone waiting on the
> context wait queue.
> 
> The current count of AFU driver specific events is stored in the field
> afu_driver_events of the context structure.
> 
> The cxl driver checks the afu_driver_events count during poll, select,
> read, etc. calls to check if an AFU driver specific event is pending,
> and calls fetch_event() to obtain and deliver that event. This way, the
> cxl driver takes care of all the usual locking semantics around these
> calls and handles all the generic cxl events, so that the AFU driver
> only needs to worry about it's own events.
> 
> fetch_event() return a struct cxl_event_afu_driver_reserved, allocated
> by the AFU driver, and filled in with the specific event information and
> size. Total event size (header + data) should not be greater than
> CXL_READ_MIN_SIZE (4K).
> 
> Th cxl driver prepends an appropriate cxl event header, copies the event
> to userspace, and finally calls event_delivered() to return the status of
> the operation to the AFU driver. The event is identified by the context
> and cxl_event_afu_driver_reserved pointers.
> 
> Since AFU drivers provide their own means for userspace to obtain the
> AFU file descriptor (i.e. cxlflash uses an ioctl on their scsi file
> descriptor to obtain the AFU file descriptor) and the generic cxl driver
> will never use this event, the ABI of the event is up to each individual
> AFU driver.
> 
> Signed-off-by: Philippe Bergheaud <felix at linux.vnet.ibm.com>

Reviewed-by: Matthew R. Ochs <mrochs at linux.vnet.ibm.com>