On Thu, Sep 9, 2021 at 1:35 PM Ben Widawsky <[email protected]> wrote: > > On 21-09-09 11:50:01, Dan Williams wrote: > > On Thu, Sep 9, 2021 at 9:41 AM Ben Widawsky <[email protected]> wrote: > > > > > > On 21-09-08 22:12:32, Dan Williams wrote: > > > > Now that the internals of mailbox operations are abstracted from the PCI > > > > specifics a bulk of infrastructure can move to the core. > > > > > > > > The CXL_PMEM driver intends to proxy LIBNVDIMM UAPI and driver requests > > > > to the equivalent functionality provided by the CXL hardware mailbox > > > > interface. In support of that intent move the mailbox implementation to > > > > a shared location for the CXL_PCI driver native IOCTL path and CXL_PMEM > > > > nvdimm command proxy path to share. > > > > > > > > A unit test framework seeks to implement a unit test backend transport > > > > for mailbox commands to communicate mocked up payloads. It can reuse all > > > > of the mailbox infrastructure minus the PCI specifics, so that also gets > > > > moved to the core. > > > > > > > > Finally with the mailbox infrastructure and ioctl handling being > > > > transport generic there is no longer any need to pass file > > > > file_operations to devm_cxl_add_memdev(). That allows all the ioctl > > > > boilerplate to move into the core for unit test reuse. > > > > > > > > No functional change intended, just code movement. > > > > > > At some point, I think some of the comments and kernel docs need updating > > > since > > > the target is no longer exclusively memory devices. Perhaps you do this > > > in later > > > patches.... > > > > I would wait to rework comments when/if it becomes clear that a > > non-memory-device driver wants to reuse the mailbox core. I do not see > > any indications that the comments are currently broken, do you? > > I didn't see anything which is incorrect, no. But to would be > non-memory-driver > writers, they could be scared off by such comments... I don't mean that it > should hold this patch up btw.
Ok, we can cross that bridge when it comes to it. I don't expect someone to reinvent mailbox command infrastructure especially when the the changelog for the commit creating drivers/cxl/core/mbox.c specifically mentions disconnecting the mailbox core from the cxl_pci driver. > > > > > [..] > > > > diff --git a/drivers/cxl/core/core.h b/drivers/cxl/core/core.h > > > > index 036a3c8106b4..c85b7fbad02d 100644 > > > > --- a/drivers/cxl/core/core.h > > > > +++ b/drivers/cxl/core/core.h > > > > @@ -14,7 +14,15 @@ static inline void unregister_cxl_dev(void *dev) > > > > device_unregister(dev); > > > > } > > > > > > > > +struct cxl_send_command; > > > > +struct cxl_mem_query_commands; > > > > +int cxl_query_cmd(struct cxl_memdev *cxlmd, > > > > + struct cxl_mem_query_commands __user *q); > > > > +int cxl_send_cmd(struct cxl_memdev *cxlmd, struct cxl_send_command > > > > __user *s); > > > > + > > > > int cxl_memdev_init(void); > > > > void cxl_memdev_exit(void); > > > > +void cxl_mbox_init(void); > > > > +void cxl_mbox_exit(void); > > > > > > cxl_mbox_fini()? > > > > The idiomatic kernel module shutdown function is suffixed _exit(). > > > > [..] > > Got it, I argue that these aren't kernel module init/exit functions though. I > will leave it at that. I would expect a _fini() function to destruct a single object, not a void _exit() that is tearing down global static infrastructure related to a compilation unit.
