Sukadev Bhattiprolu [suka...@linux.vnet.ibm.com] wrote: > Michael Neuling [mi...@neuling.org] wrote: > > On Thu, 2017-03-16 at 20:33 -0700, Sukadev Bhattiprolu wrote: > > > Define macros for the VAS hardware registers and bit-fields as well > > > as couple of data structures needed by the VAS driver. > > > > > > > Signed-off-by: Sukadev Bhattiprolu <suka...@linux.vnet.ibm.com> > > > --- > > > Changelog[v3] > > > - Rename winctx->pid to winctx->pidr to reflect that its a value > > > from the PID register (SPRN_PID), not the linux process id. > > > - Make it easier to split header into kernel/user parts > > > - To keep user interface simple, use macros rather than enum for > > > the threshold-control modes. > > > - Add a pid field to struct vas_window - needed for user space > > > send windows. > > > > > > Changelog[v2] > > > - Add an overview of VAS in vas-internal.h > > > - Get window context parameters from device tree and drop > > > unnecessary macros. > > > --- > > > MAINTAINERS | 6 + > > > arch/powerpc/include/asm/vas.h | 43 +++++ > > > drivers/misc/vas/vas-internal.h | 392 > > > ++++++++++++++++++++++++++++++++++++++++ > > > > This is going to have to go through gregkh/lkml if it's drivers/misc. > > you'll at > > least need gregkh's ack/ok before mpe will take them (which is what we did > > for > > CAPI). > > > > We might want to keep this in arch/powerpc but I'm not sure. > > > > We will have device nodes accessible to user space so put it here and can > copy Gregkh next time. But let me know if we should move to arch/powerpc. >
Thinking about this some more, the VAS module itself does not provide the device nodes. Rather, the drivers that use VAS, like NX-GZIP, will provide them. So, I am moving the VAS code into arch/powerpc/kernel. Please let me know of any comments/concerns. Thanks Suka