On Mon, Feb 24, 2020 at 3:43 PM Alastair D'Silva <alastair@xxxxxxxxxxx> wrote: > > On Sun, 2020-02-23 at 20:37 -0800, Matthew Wilcox wrote: > > On Mon, Feb 24, 2020 at 03:34:07PM +1100, Alastair D'Silva wrote: > > > V3: > > > - Rebase against next/next-20200220 > > > - Move driver to arch/powerpc/platforms/powernv, we now expect > > > this > > > driver to go upstream via the powerpc tree > > > > That's rather the opposite direction of normal; mostly drivers live > > under > > drivers/ and not in arch/. It's easier for drivers to get overlooked > > when doing tree-wide changes if they're hiding. > > This is true, however, given that it was not all that desirable to have > it under drivers/nvdimm, it's sister driver (for the same hardware) is > also under arch, and that we don't expect this driver to be used on any > platform other than powernv, we think this was the most reasonable > place to put it. Historically powernv specific platform drivers go in their respective subsystem trees rather than in arch/ and I'd prefer we kept it that way. When I added the papr_scm driver I put it in the pseries platform directory because most of the pseries paravirt code lives there for some reason; I don't know why. Luckily for me that followed the same model that Dan used when he put the NFIT driver in drivers/acpi/ and the libnvdimm core in drivers/nvdimm/ so we didn't have anything to argue about. However, as Matthew pointed out, it is at odds with how most subsystems operate. Is there any particular reason we're doing things this way or should we think about moving libnvdimm users to drivers/nvdimm/? Oliver
