All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Rapoport <rppt@kernel.org>
To: dan.j.williams@intel.com
Cc: Dave Jiang <dave.jiang@intel.com>,
	Ira Weiny <ira.weiny@intel.com>,
	Vishal Verma <vishal.l.verma@intel.com>,
	jane.chu@oracle.com, Pasha Tatashin <pasha.tatashin@soleen.com>,
	Tyler Hicks <code@tyhicks.com>,
	linux-kernel@vger.kernel.org, nvdimm@lists.linux.dev
Subject: Re: [PATCH 1/1] nvdimm: allow exposing RAM carveouts as NVDIMM DIMM devices
Date: Tue, 30 Sep 2025 12:11:37 +0200	[thread overview]
Message-ID: <aNus2chNlLGmEiOg@kernel.org> (raw)
In-Reply-To: <68d34488c5b8d_10520100b6@dwillia2-mobl4.notmuch>

On Tue, Sep 23, 2025 at 06:08:24PM -0700, dan.j.williams@intel.com wrote:
> Mike Rapoport wrote:
> > From: "Mike Rapoport (Microsoft)" <rppt@kernel.org>
> > 
> > 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.

It looks like /sys/bus/platform/devices/e820_pmem/driver_override does the
trick.

I'll make the driver to use "ramdax" as the name and rely on
driver_override for binding it to a device.

-- 
Sincerely yours,
Mike.

      reply	other threads:[~2025-09-30 10:11 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-26  8:04 [PATCH 0/1] nvdimm: allow exposing RAM as libnvdimm DIMMs Mike Rapoport
2025-08-26  8:04 ` [PATCH 1/1] nvdimm: allow exposing RAM carveouts as NVDIMM DIMM devices Mike Rapoport
2025-08-29  0:47   ` Ira Weiny
2025-08-29  7:57     ` Mike Rapoport
2025-09-01 16:01       ` Michał Cłapiński
2025-09-02 15:35         ` Mike Rapoport
2025-09-24  1:16         ` dan.j.williams
2025-09-26 12:47           ` Michał Cłapiński
2025-09-26 18:45             ` dan.j.williams
2025-09-30 10:15               ` Mike Rapoport
2025-10-01 14:14               ` Michał Cłapiński
2025-10-01 22:28                 ` dan.j.williams
2025-12-09 20:10                   ` Michał Cłapiński
2025-12-17  3:14                     ` dan.j.williams
2025-12-29 16:39                       ` Michał Cłapiński
2026-01-12 23:36                         ` Ira Weiny
2026-01-13 12:39                           ` Michał Cłapiński
2026-01-14  2:34                             ` dan.j.williams
2025-09-24  1:08   ` dan.j.williams
2025-09-30 10:11     ` Mike Rapoport [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aNus2chNlLGmEiOg@kernel.org \
    --to=rppt@kernel.org \
    --cc=code@tyhicks.com \
    --cc=dan.j.williams@intel.com \
    --cc=dave.jiang@intel.com \
    --cc=ira.weiny@intel.com \
    --cc=jane.chu@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nvdimm@lists.linux.dev \
    --cc=pasha.tatashin@soleen.com \
    --cc=vishal.l.verma@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.