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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <aPnbuurCUlErW0Yf@kernel.org>
Date: Thu, 23 Oct 2025 10:39:38 +0300
From: Mike Rapoport <rppt@...nel.org>
To: dan.j.williams@...el.com
Cc: Dave Jiang <dave.jiang@...el.com>, Ira Weiny <ira.weiny@...el.com>,
	Vishal Verma <vishal.l.verma@...el.com>, jane.chu@...cle.com,
	Michał Cłapiński <mclapinski@...gle.com>,
	Pasha Tatashin <pasha.tatashin@...een.com>,
	Tyler Hicks <code@...icks.com>, linux-kernel@...r.kernel.org,
	nvdimm@...ts.linux.dev
Subject: Re: [PATCH v2 1/1] nvdimm: allow exposing RAM carveouts as NVDIMM
 DIMM devices

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