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

[Mike Rapoport <rppt@kernel.org>]

On Wed, Oct 22, 2025 at 04:29:23PM -0700, dan.j.williams@intel.com wrote:
> 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

Works for me :)
 
> ...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.

-- 
Sincerely yours,
Mike.