From: PJ Waskiewicz <ppwaskie@kernel.org>
To: alejandro.lucero-palau@amd.com, linux-cxl@vger.kernel.org,
netdev@vger.kernel.org, dan.j.williams@intel.com,
edward.cree@amd.com, davem@davemloft.net, kuba@kernel.org,
pabeni@redhat.com, edumazet@google.com, dave.jiang@intel.com
Cc: Alejandro Lucero <alucerop@amd.com>
Subject: Re: [PATCH v21 00/23] Type2 device basic support
Date: Fri, 28 Nov 2025 11:44:42 -0800 [thread overview]
Message-ID: <31dae6910b0863dee44069d01a909f8ed0b19bb2.camel@kernel.org> (raw)
In-Reply-To: <20251119192236.2527305-1-alejandro.lucero-palau@amd.com>
Hi Alejandro,
On Wed, 2025-11-19 at 19:22 +0000, alejandro.lucero-palau@amd.com
wrote:
> From: Alejandro Lucero <alucerop@amd.com>
>
> The patchset should be applied on the described base commit then
> applying
> Terry's v13 about CXL error handling. The first 4 patches come from
> Dan's
> for-6.18/cxl-probe-order branch with minor modifications.
>
> v21 changes;
>
> patch1-2: v20 patch1 splitted up doing the code move in the second
> patch in v21. (Jonathan)
>
> patch1-4: adding my Signed-off tag along with Dan's
>
> patch5: fix duplication of CXL_NR_PARTITION definition
>
> patch7: dropped the cxl test fixes removing unused function. It was
> sent independently ahead of this version.
>
> patch12: optimization for max free space calculation (Jonathan)
>
> patch19: optimization for returning on error (Jonathan)
>
So I'm unable to get these patches working with a Type2 device that
just needs its existing resources auto-discovered by the CXL core.
These patches are assuming the underlying device will require full
setup and allocations for DPA and HPA. I'd argue that a true Type2
device will not be doing that today with existing BIOS implementations.
I've tested this behavior on both Intel and AMD platforms (GNR and
Turin), and they're behaving the same way. Both will train up the
Type2 device, see there's an advertised CXL.mem region marked EFI
Special Purpose memory, and will map it and program the decoders.
These patches partially see those decoders are already programmed, but
does not bypass that fact, and still attemps to dynamically allocate,
configure, and commit, the whole flow. This assumption fails the init
path.
I think there needs to be a bit of a re-think here. I briefly chatted
with Dan offline about this, and we do think a different approach is
likely needed. The current CXL core for Type3 devices can handle when
the BIOS/platform firmware already discovers and maps resources, so we
should be able to do that for this case.
If you're going to be at Plumbers in a week or so, this would be a
great topic if we could grab a whiteboard somewhere and just hack on
it. Otherwise we can also chat on the Discord (I just joined finally).
Cheers,
-PJ
next prev parent reply other threads:[~2025-11-28 19:44 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-19 19:22 [PATCH v21 00/23] Type2 device basic support alejandro.lucero-palau
2025-11-19 19:22 ` [PATCH v21 01/23] cxl/mem: refactor memdev allocation alejandro.lucero-palau
2025-11-20 18:08 ` Jonathan Cameron
2025-11-20 18:27 ` Alejandro Lucero Palau
2025-11-21 12:06 ` Jonathan Cameron
2025-11-21 13:46 ` Alejandro Lucero Palau
2025-11-20 20:27 ` Koralahalli Channabasappa, Smita
2025-11-21 13:41 ` Alejandro Lucero Palau
2025-12-02 2:52 ` dan.j.williams
2025-12-02 4:58 ` dan.j.williams
2025-12-02 8:47 ` Alejandro Lucero Palau
2025-11-19 19:22 ` [PATCH v21 02/23] cxl/mem: Arrange for always-synchronous memdev attach alejandro.lucero-palau
2025-12-02 5:03 ` dan.j.williams
2025-11-19 19:22 ` [PATCH v21 03/23] cxl/port: Arrange for always synchronous endpoint attach alejandro.lucero-palau
2025-12-02 5:08 ` dan.j.williams
2025-11-19 19:22 ` [PATCH v21 04/23] cxl/mem: Introduce a memdev creation ->probe() operation alejandro.lucero-palau
2025-11-19 19:22 ` [PATCH v21 05/23] cxl: Add type2 device basic support alejandro.lucero-palau
2025-11-19 19:22 ` [PATCH v21 06/23] sfc: add cxl support alejandro.lucero-palau
2025-11-19 19:22 ` [PATCH v21 07/23] cxl: Move pci generic code alejandro.lucero-palau
2025-11-19 19:22 ` [PATCH v21 08/23] cxl/sfc: Map cxl component regs alejandro.lucero-palau
2025-11-21 6:54 ` PJ Waskiewicz
2025-11-21 11:01 ` Alejandro Lucero Palau
2025-11-22 1:11 ` PJ Waskiewicz
2025-11-19 19:22 ` [PATCH v21 09/23] cxl/sfc: Initialize dpa without a mailbox alejandro.lucero-palau
2025-11-19 19:22 ` [PATCH v21 10/23] cxl: Prepare memdev creation for type2 alejandro.lucero-palau
2025-11-19 19:22 ` [PATCH v21 11/23] sfc: create type2 cxl memdev alejandro.lucero-palau
2025-11-19 19:22 ` [PATCH v21 12/23] cxl: Define a driver interface for HPA free space enumeration alejandro.lucero-palau
2025-11-19 19:22 ` [PATCH v21 13/23] sfc: get root decoder alejandro.lucero-palau
2025-11-19 19:22 ` [PATCH v21 14/23] cxl: Define a driver interface for DPA allocation alejandro.lucero-palau
2025-11-19 19:22 ` [PATCH v21 15/23] sfc: get endpoint decoder alejandro.lucero-palau
2025-11-26 1:27 ` PJ Waskiewicz
2025-11-26 9:09 ` Alejandro Lucero Palau
2025-11-26 18:35 ` PJ Waskiewicz
2025-11-27 9:08 ` Alejandro Lucero Palau
2025-12-02 8:49 ` PJ Waskiewicz
2025-12-02 9:09 ` Alejandro Lucero Palau
2025-12-02 16:35 ` Dave Jiang
2025-11-19 19:22 ` [PATCH v21 16/23] cxl: Make region type based on endpoint type alejandro.lucero-palau
2025-11-19 19:22 ` [PATCH v21 17/23] cxl/region: Factor out interleave ways setup alejandro.lucero-palau
2025-11-19 19:22 ` [PATCH v21 18/23] cxl/region: Factor out interleave granularity setup alejandro.lucero-palau
2025-11-19 19:22 ` [PATCH v21 19/23] cxl: Allow region creation by type2 drivers alejandro.lucero-palau
2025-11-19 19:22 ` [PATCH v21 20/23] cxl: Avoid dax creation for accelerators alejandro.lucero-palau
2025-11-19 19:22 ` [PATCH v21 21/23] sfc: create cxl region alejandro.lucero-palau
2025-11-19 19:22 ` [PATCH v21 22/23] cxl: Add function for obtaining region range alejandro.lucero-palau
2025-11-19 19:22 ` [PATCH v21 23/23] sfc: support pio mapping based on cxl alejandro.lucero-palau
2025-11-21 6:41 ` [PATCH v21 00/23] Type2 device basic support PJ Waskiewicz
2025-11-21 10:40 ` Alejandro Lucero Palau
2025-11-22 1:08 ` PJ Waskiewicz
2025-11-28 19:44 ` PJ Waskiewicz [this message]
2025-11-28 20:29 ` Alejandro Lucero Palau
2025-11-29 16:26 ` Alejandro Lucero Palau
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=31dae6910b0863dee44069d01a909f8ed0b19bb2.camel@kernel.org \
--to=ppwaskie@kernel.org \
--cc=alejandro.lucero-palau@amd.com \
--cc=alucerop@amd.com \
--cc=dan.j.williams@intel.com \
--cc=dave.jiang@intel.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=edward.cree@amd.com \
--cc=kuba@kernel.org \
--cc=linux-cxl@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.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;
as well as URLs for NNTP newsgroup(s).