Re: [PATCH v2 1/1] nvdimm: allow exposing RAM carveouts as NVDIMM DIMM devices

[<dan.j.williams@intel.com>]

Mike Rapoport wrote:
[..]
> > > +config RAMDAX
> > > +	tristate "Support persistent memory interfaces on RAM carveouts"
> > > +	depends on OF || X86
> > 
> > I see no compile time dependency for CONFIG_OF. The one call to
> > dev_of_node() looks like it still builds in the CONFIG_OF=n case. For
> > CONFIG_X86 the situation is different because the kernel needs
> > infrastructure to build the device.
> > 
> > So maybe change the dependency to drop OF and make it:
> > 
> > 	depends on X86_PMEM_LEGACY if X86
> 
> We can't put if in a depends statement :(

Ugh, yeah, whoops.

> My intention with "depends on OF || X86" was that if it's not really
> possible to use this driver if it's not X86 or OF because there's nothing
> to define a platform device for ramdax to bind.
> 
> Maybe what we actually need is
> 
> 	select X86_PMEM_LEGACY_DEVICE if X86
> 	default n
> so that it could be only explicitly enabled in the configuration and if it
> is, it will also enable X86_PMEM_LEGACY_DEVICE on x86.
> With default set to no it won't be build "accidentailly", but OTOH cloud
> providers can disable X86_PMEM_LEGACY and enable RAMDAX and distros can
> build them as modules on x86 and architectures that support OF. 
> 
> What do you think?

Perhaps:

    depends on X86_PMEM_LEGACY || OF || COMPILE_TEST

...because it is awkward to select symbols that has dependencies that
may be missing, and it shows that this driver has no compile time
dependencies on those symbols.

[..] 
> With how driver_override is implemented it's possible to get fireworks with
> any platform device :)

True.

> I'll add a manual check for of_match_node() to be on the safer side.

Sounds good.