On Tue, 2024-04-09 at 08:22 -0500, Bjorn Helgaas wrote: > On Sun, Apr 07, 2024 at 02:05:26PM -0700, ppwaskie@xxxxxxxxxx wrote: > > From: PJ Waskiewicz <ppwaskie@xxxxxxxxxx> > > > > Currently, Type 3 CXL devices (CXL.mem) can train using host CXL > > drivers on Emerald Rapids systems. However, on some production > > systems from some vendors, a buggy BIOS exists that improperly > > populates the ACPI => PCI mappings. > > Can you be more specific about what this ACPI => PCI mapping is? > If you already know what the problem is, I'm sure this is obvious, > but > otherwise it's not. Apologies for the delay in response. Things got a bit busy with travel and whatnot... On one of these particular hosts, in /sys/bus/acpi/devices/ACPI0016:00, for example, the UID would be something like CX01. It isn't an u64 at all, and there's no atoi() or other conversions that would match what the UID should be. In my case, /sys/bus/acpi/devices/ACPI0016:02/ is my CXL device in question. The UID that is presented from enumeration was CX02. However, if I scour the CEDT manually, the UID of my particular CXL device is really UID 49. So, if I went from the PCI/CXL device side, and called something along the lines of to_cxl_host_bridge() and tried to go from the pci_dev to the acpi_handle, I'd get CX02 back. Then trying to use that to call acpi_table_parse_cedt() would fail. The BIOS fix from the vendor corrected the UID enumeration on the ACPI side. This allowed things to properly line up when traversing through the kernel APIs and parsing the ACPI tables. Let me know if this helps clarify! If not, I can try and get more detailed info. -PJ
