From: Gregory Price <gourry@gourry.net>
To: Alejandro Lucero Palau <alucerop@amd.com>
Cc: linux-cxl@vger.kernel.org, linux-kernel@vger.kernel.org,
kernel-team@meta.com, dave@stgolabs.net,
jonathan.cameron@huawei.com, dave.jiang@intel.com,
alison.schofield@intel.com, vishal.l.verma@intel.com,
ira.weiny@intel.com, dan.j.williams@intel.com
Subject: Re: [PATCH 0/6] CXL: Introduce memory controller abstraction and sysram controller
Date: Thu, 15 Jan 2026 13:56:01 -0500 [thread overview]
Message-ID: <aWk4QX_zbyA3sDMT@gourry-fedora-PF4VCD3F> (raw)
In-Reply-To: <edb6cd44-76df-4d68-8df8-2e7f3a7db73b@amd.com>
On Thu, Jan 15, 2026 at 06:43:08PM +0000, Alejandro Lucero Palau wrote:
> Hi Gregory,
>
>
> I was concerned with how this could affect Type2 but I think there is no
> issue at all, but I prefer to ask specifically about it.
>
>
> Type2 can obtain an auto region if BIOS enabled/configured the HDMs, or it
> can create one on purpose if not. Type2 patchset does not allow to create a
> dax region when region probing and it will be the same type2 check
> precluding call to enabling the sysram controller.
>
>
> However, I can see the region will have default sysfs files for setting the
> controller. I think even with such a change there is no way for enabling the
> controller from the type2 region probing, so I guess it is safe, but I would
> prefer to not allow a Type2 region setting a controller at all.
>
>
> I like the approach for solving the problem pointed out, and I think
> something similar or a controller extension for type2 could be needed in the
> future, but maybe adding more flexibility for theoretical per type2 driver
> memory-handling uniqueness.
>
>
(pre-note: we changed the verbiage from controller to driver)
I think Type2 devices (and some special memory devices) are exactly
the use case that drives formalizing region-drivers.
Some Type2 devices might just register a normal memory region.
Some Type2 devices might want a dax device.
Some Type2 devices might want a "private memory" region (private node).
Some Type2 devices might have a completely different usage pattern.
Maybe we might want a control that limits which drivers a given device
can use (limiting switch-ability), and let devices inform the core
region driver of that in some way.
The sysfs toggle is a pressure-valve for devices that might be configurable
in multiple ways. Maybe it won't actually be needed, but at least for
"Regular Memory" devices i can see us having dax and sysram drivers at a
minimum.
The base sysram driver may even be the basis for a dcd_sysram driver.
After all it's just a sysram driver w/ add/remove extent functions :]
~Gregory
prev parent reply other threads:[~2026-01-15 18:56 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20260113093758epcas5p10cc9749a657b8e4d32db75b8b973b67d@epcas5p1.samsung.com>
2026-01-12 16:35 ` [PATCH 0/6] CXL: Introduce memory controller abstraction and sysram controller Gregory Price
2026-01-12 16:35 ` [PATCH 1/6] drivers/cxl: add cxl_memctrl_mode and region->memctrl Gregory Price
2026-01-12 20:59 ` dan.j.williams
2026-01-12 22:25 ` Gregory Price
2026-01-13 18:00 ` Dave Jiang
2026-01-13 20:07 ` Gregory Price
2026-01-14 16:36 ` dan.j.williams
2026-01-12 21:10 ` Cheatham, Benjamin
2026-01-12 22:34 ` Gregory Price
2026-01-14 17:18 ` Jonathan Cameron
2026-01-14 18:25 ` Gregory Price
2026-01-14 18:36 ` Jonathan Cameron
2026-01-12 16:35 ` [PATCH 2/6] cxl: add sysram_region memory controller Gregory Price
2026-01-12 20:00 ` David Hildenbrand (Red Hat)
2026-01-12 22:43 ` Gregory Price
2026-01-12 21:10 ` dan.j.williams
2026-01-12 22:47 ` Gregory Price
2026-01-12 21:10 ` Cheatham, Benjamin
2026-01-12 22:55 ` Gregory Price
2026-01-13 22:34 ` Cheatham, Benjamin
2026-01-12 16:35 ` [PATCH 3/6] cxl/core/region: move pmem memctrl logic into memctrl/pmem_region Gregory Price
2026-01-12 21:10 ` Cheatham, Benjamin
2026-01-12 22:58 ` Gregory Price
2026-01-13 9:12 ` Neeraj Kumar
2026-01-12 16:35 ` [PATCH 4/6] cxl: add CONFIG_CXL_REGION_CTRL_AUTO_* build config options Gregory Price
2026-01-12 21:10 ` Cheatham, Benjamin
2026-01-12 23:05 ` Gregory Price
2026-01-13 4:31 ` dan.j.williams
2026-01-13 13:55 ` Gregory Price
2026-01-12 16:35 ` [PATCH 5/6] cxl: add CXL_REGION_SYSRAM_DEFAULT_* build options Gregory Price
2026-01-12 21:11 ` Cheatham, Benjamin
2026-01-12 23:07 ` Gregory Price
2026-01-12 16:35 ` [PATCH 6/6] cxl/sysram: disallow onlining in ZONE_NORMAL if state is movable only Gregory Price
2026-01-12 21:11 ` Cheatham, Benjamin
2026-01-12 23:14 ` Gregory Price
2026-01-13 22:35 ` Cheatham, Benjamin
2026-01-13 9:37 ` [PATCH 0/6] CXL: Introduce memory controller abstraction and sysram controller Neeraj Kumar
2026-01-13 13:33 ` Gregory Price
2026-01-15 18:43 ` Alejandro Lucero Palau
2026-01-15 18:56 ` Gregory Price [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=aWk4QX_zbyA3sDMT@gourry-fedora-PF4VCD3F \
--to=gourry@gourry.net \
--cc=alison.schofield@intel.com \
--cc=alucerop@amd.com \
--cc=dan.j.williams@intel.com \
--cc=dave.jiang@intel.com \
--cc=dave@stgolabs.net \
--cc=ira.weiny@intel.com \
--cc=jonathan.cameron@huawei.com \
--cc=kernel-team@meta.com \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox