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.
