Re: [PATCH v17 00/22] Type2 device basic support

[PJ Waskiewicz <ppwaskie@kernel.org>]

Hi Alejandro,

On Thu, 2025-08-28 at 09:02 +0100, Alejandro Lucero Palau wrote:
> Hi PJ,
> 
> On 8/27/25 17:48, PJ Waskiewicz wrote:
> > On Tue, 2025-06-24 at 15:13 +0100, alejandro.lucero-palau@amd.com
> > wrote:
> > 
> > Hi Alejandro,
> > 
> > > From: Alejandro Lucero <alucerop@amd.com>
> > > 
> > > v17 changes: (Dan Williams review)
> > >   - use devm for cxl_dev_state allocation
> > >   - using current cxl struct for checking capability registers
> > > found
> > > by
> > >     the driver.
> > >   - simplify dpa initialization without a mailbox not supporting
> > > pmem
> > >   - add cxl_acquire_endpoint for protection during initialization
> > >   - add callback/action to cxl_create_region for a driver
> > > notified
> > > about cxl
> > >     core kernel modules removal.
> > >   - add sfc function to disable CXL-based PIO buffers if such a
> > > callback
> > >     is invoked.
> > >   - Always manage a Type2 created region as private not allowing
> > > DAX.
> > > 
> > I've been following the patches here since your initial RFC.  What
> > platform are you testing these on out of curiosity?

A bit more info for the weekend to digest.

On my AMD Purico CRB, it looks like I may be missing pieces of the ACPI
tables in the BIOS.  I'm going to shift to a GNR that is pretty healthy
and keep hacking away.  But this is what I'm seeing now that I ported
everything over to these V17 patches.

- devm_cxl_dev_state_create() - succeeds

- cxl_pci_set_regs(pdev, CXL_REGLOC_RBI_COMPONENT, &cxl-
>cxlds.reg_map): this is where things go wrong.  I get -ENODEV
returned.  I'm digging into the BIOS settings, but this is the same
place I landed on with the V16 patches.  The device is fully trained on
all protocols.

Hope this rings a bell where to look.

Cheers,
-PJ