On Mon, Nov 18, 2019 at 3:48 PM Andrew Donnellan <ajd@xxxxxxxxxxxxx> wrote: > > On 15/11/19 3:35 am, Dan Williams wrote: > >> Have you discussed with the directory owner if it's ok to split the > >> driver over several files? > > > > My thought is to establish drivers/opencapi/ and move this and the > > existing drivers/misc/ocxl/ bits there. > > Is there any other justification for this we can think of apart from not > wanting to put this driver in the nvdimm directory? OpenCAPI drivers > aren't really a category of driver unto themselves. The concern is less about adding to drivers/nvdimm/ and more about the proper location to house opencapi specific transport and enumeration details. The organization I'm looking for is to group platform transport and enumeration code together similar to how drivers/pci/ exists independent of all pci drivers that use that common core. For libnvdimm the enumeration is platform specific and calls into the nvdimm core. This is why the x86 platform persistent memory bus driver lives under drivers/acpi/nfit/ instead of drivers/nvdimm/. The nfit driver is an ACPI extension that translates ACPI details into libnvdimm core objects. The usage of "ocxl" in the source leads me to think part of this driver belongs in a directory that has other opencapi specific considerations.
