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] [thread-next>] [day] [month] [year] [list]

Message-ID: <68f968d34154f_10e9100e0@dwillia2-mobl4.notmuch>
Date: Wed, 22 Oct 2025 16:29:23 -0700
From: <dan.j.williams@...el.com>
To: Mike Rapoport <rppt@...nel.org>, <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

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.