All of lore.kernel.org
 help / color / mirror / Atom feed
From: <dan.j.williams@intel.com>
To: Alejandro Lucero Palau <alucerop@amd.com>,
	Dan Williams <dan.j.williams@intel.com>, <dave.jiang@intel.com>
Cc: <linux-cxl@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<Smita.KoralahalliChannabasappa@amd.com>,
	<alison.schofield@intel.com>, <terry.bowman@amd.com>,
	<alejandro.lucero-palau@amd.com>, <linux-pci@vger.kernel.org>,
	<Jonathan.Cameron@huawei.com>, Shiju Jose <shiju.jose@huawei.com>
Subject: Re: [PATCH 0/6] cxl: Initialization reworks in support Soft Reserve Recovery and Accelerator Memory
Date: Fri, 5 Dec 2025 13:17:55 -0800	[thread overview]
Message-ID: <69334c038705b_1b2e100b5@dwillia2-mobl4.notmuch> (raw)
In-Reply-To: <143deecb-aa53-42e6-b7eb-91fb392e7502@amd.com>

Alejandro Lucero Palau wrote:
[..]
> > For "Accelerator Memory", the driver is not cxl_pci, but any potential
> > PCI driver that wants to use the devm_cxl_add_memdev() ABI to attach to
> > the CXL memory domain. Those drivers want to know if the CXL link is
> > live end-to-end (from endpoint, through switches, to the host bridge)
> > and CXL memory operations are enabled. If not, a CXL accelerator may be
> > able to fall back to PCI-only operation. Similar to the "Soft Reserve
> > Memory" it needs to know that the CXL subsystem had a chance to probe
> > the ancestor topology of the device and let that driver make a
> > synchronous decision about CXL operation.
> 
> 
> IMO, this is not the problem with accelerators, because this can not be 
> dynamically done, or not easily.

Hmm, what do you mean can not be dynamically done? The observation is
that a CXL card and its driver have no idea if the card is going to be
plugged into a PCIe only slot.

At runtime the driver only finds out the CXL is not there from the
result of devm_cxl_add_memdev().

> The HW will support CXL or PCI, and if 
> CXL mem is not enabled by the firmware, likely due to a 
> negotiation/linking problem, the driver can keep going with CXL.io.

Right, I think we are in violent agreement.

> Of course, this is from my experience with sfc driver/hardware. Note
> sfc driver added the check for CXL availability based on Terry's v13.

Note that Terry's check for CXL availabilty is purely a hardware
detection, there are still software reasons why cxl_acpi and cxl_mem
can prevent devm_cxl_add_memdev() success.

> But this is useful for solving the problem of module removal which can 
> leave the type2 driver without the base for doing any unwinding. Once a 
> type2 uses code from those other cxl modules explicitly, the problem is 
> avoided. You seem to have forgotten about this problem, what I think it 
> is worth to describe.

What problem exactly? If it needs to be captured in these changelogs or
code comments, let me know.

  reply	other threads:[~2025-12-05 21:18 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-04  2:21 [PATCH 0/6] cxl: Initialization reworks in support Soft Reserve Recovery and Accelerator Memory Dan Williams
2025-12-04  2:21 ` [PATCH 1/6] cxl/mem: Fix devm_cxl_memdev_edac_release() confusion Dan Williams
2025-12-04 16:48   ` Dave Jiang
2025-12-04 20:15     ` dan.j.williams
2025-12-04 19:09   ` Cheatham, Benjamin
2025-12-05  2:46   ` Alison Schofield
2025-12-08 14:19   ` Alejandro Lucero Palau
2025-12-15 21:11     ` dan.j.williams
2025-12-08 19:20   ` Shiju Jose
2025-12-15 12:00   ` Jonathan Cameron
2025-12-04  2:21 ` [PATCH 2/6] cxl/mem: Arrange for always-synchronous memdev attach Dan Williams
2025-12-04 16:58   ` Dave Jiang
2025-12-04 19:09   ` Cheatham, Benjamin
2025-12-05  2:49   ` Alison Schofield
2025-12-15 12:08   ` Jonathan Cameron
2025-12-04  2:21 ` [PATCH 3/6] cxl/port: Arrange for always synchronous endpoint attach Dan Williams
2025-12-04 18:36   ` Dave Jiang
2025-12-04 19:09   ` Cheatham, Benjamin
2025-12-05  3:36   ` Alison Schofield
2025-12-15 12:09   ` Jonathan Cameron
2025-12-04  2:21 ` [PATCH 4/6] cxl/mem: Convert devm_cxl_add_memdev() to scope-based-cleanup Dan Williams
2025-12-04 18:58   ` Dave Jiang
2025-12-04 19:09   ` Cheatham, Benjamin
2025-12-04 20:50     ` dan.j.williams
2025-12-05  3:37   ` Alison Schofield
2025-12-04  2:21 ` [PATCH 5/6] cxl/mem: Drop @host argument to devm_cxl_add_memdev() Dan Williams
2025-12-04 19:09   ` Cheatham, Benjamin
2025-12-04 20:02   ` Dave Jiang
2025-12-05  3:38   ` Alison Schofield
2025-12-15 12:15   ` Jonathan Cameron
2025-12-04  2:21 ` [PATCH 6/6] cxl/mem: Introduce a memdev creation ->probe() operation Dan Williams
2025-12-04 19:10   ` Cheatham, Benjamin
2025-12-04 21:11     ` dan.j.williams
2025-12-04 22:02       ` dan.j.williams
2025-12-04 22:15         ` Cheatham, Benjamin
2025-12-04 20:03   ` Dave Jiang
2025-12-05 15:15 ` [PATCH 0/6] cxl: Initialization reworks in support Soft Reserve Recovery and Accelerator Memory Alejandro Lucero Palau
2025-12-05 21:17   ` dan.j.williams [this message]
2025-12-08 14:04     ` Alejandro Lucero Palau
2025-12-09  7:53       ` dan.j.williams
2025-12-08 17:04 ` Alejandro Lucero Palau
2025-12-15 23:29   ` dan.j.williams

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=69334c038705b_1b2e100b5@dwillia2-mobl4.notmuch \
    --to=dan.j.williams@intel.com \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=Smita.KoralahalliChannabasappa@amd.com \
    --cc=alejandro.lucero-palau@amd.com \
    --cc=alison.schofield@intel.com \
    --cc=alucerop@amd.com \
    --cc=dave.jiang@intel.com \
    --cc=linux-cxl@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=shiju.jose@huawei.com \
    --cc=terry.bowman@amd.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.