On Tue, Sep 23, 2025 at 06:08:24PM -0700, [email protected] wrote: > Mike Rapoport wrote: > > From: "Mike Rapoport (Microsoft)" <[email protected]> > > > > There are use cases, for example virtual machine hosts, that create > > "persistent" memory regions using memmap= option on x86 or dummy > > pmem-region device tree nodes on DT based systems. > > > > Both these options are inflexible because they create static regions and > > the layout of the "persistent" memory cannot be adjusted without reboot > > and sometimes they even require firmware update. > > > > Add a ramdax driver that allows creation of DIMM devices on top of > > E820_TYPE_PRAM regions and devicetree pmem-region nodes. > > > > The DIMMs support label space management on the "device" and provide a > > flexible way to access RAM using fsdax and devdax. > > Hi Mike, I like this. Some questions below: > > > +static struct platform_driver ramdax_driver = { > > + .probe = ramdax_probe, > > + .remove = ramdax_remove, > > + .driver = { > > + .name = "e820_pmem", > > + .of_match_table = of_match_ptr(ramdax_of_matches), > > So this driver collides with both e820_pmem and of_pmem, but I think it > would be useful to have both options (with/without labels) available and > not require disabling both those other drivers at compile time. > > 'struct pci_device_id' has this useful "override_only" flag to require > that the only driver that attaches is one that is explicitly requested > (see pci_match_device()). > > Now, admittedly platform_match() is a bit more complicated in that it > matches 3 different platform device id types, but I think the ability to > opt-in to this turns this from a "cloud-host-provider-only" config > option to something distro kernels can enable by default.
It looks like /sys/bus/platform/devices/e820_pmem/driver_override does the trick. I'll make the driver to use "ramdax" as the name and rely on driver_override for binding it to a device. -- Sincerely yours, Mike.
