Received-SPF: pass (google.com: domain of linux-kernel+bounces-165473-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Message-ID: <f5078550384a6b9be5a6d05415ea321332c7fb96.camel@kernel.org>
Subject: Re: [PATCH 1/1] cxl/acpi.c: Add buggy BIOS hint for CXL ACPI lookup
 failure
From: PJ Waskiewicz <ppwaskie@kernel.org>
To: Dan Williams <dan.j.williams@intel.com>, Bjorn Helgaas
 <helgaas@kernel.org>
Cc: linux-cxl@vger.kernel.org, linux-pci@vger.kernel.org, 
	linux-kernel@vger.kernel.org
Date: Wed, 01 May 2024 08:28:22 -0700
In-Reply-To: <662fe860eb889_1487294e8@dwillia2-mobl3.amr.corp.intel.com.notmuch>
References: <ce49c67c24f57ffab166d688a1c9e3139733f412.camel@kernel.org>
	 <20240429153138.GA681245@bhelgaas>
	 <662fe860eb889_1487294e8@dwillia2-mobl3.amr.corp.intel.com.notmuch>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.50.0-1 
Precedence: bulk
MIME-Version: 1.0

On Mon, 2024-04-29 at 11:35 -0700, Dan Williams wrote:
> Bjorn Helgaas wrote:
> > On Sun, Apr 28, 2024 at 10:57:13PM -0700, PJ Waskiewicz wrote:
> > > On Tue, 2024-04-09 at 08:22 -0500, Bjorn Helgaas wrote:
> > > > On Sun, Apr 07, 2024 at 02:05:26PM -0700,
> > > > ppwaskie@kernel.org=C2=A0wrote:
> > > > > From: PJ Waskiewicz <ppwaskie@kernel.org>
> > > > >=20
> > > > > Currently, Type 3 CXL devices (CXL.mem) can train using host
> > > > > CXL
> > > > > drivers on Emerald Rapids systems.=C2=A0 However, on some
> > > > > production
> > > > > systems from some vendors, a buggy BIOS exists that
> > > > > improperly
> > > > > populates the ACPI =3D> PCI mappings.
> > > >=20
> > > > Can you be more specific about what this ACPI =3D> PCI mapping
> > > > is?
> > > > If you already know what the problem is, I'm sure this is
> > > > obvious,
> > > > but otherwise it's not.
> [..]=20
> > It's just a buggy BIOS that doesn't supply _UID for an ACPI0016
> > object, so you can't locate the corresponding CEDT entry, right?
>=20
> Correct, the problem is 100% contained to ACPI, and PCI is innocent.
> The
> ACPI bug leads to failures to associate ACPI host-bridge objects with
> CEDT.CHBS entries.

Sorry for the confusion here!!  I was definitely not trying to blame
PCI.  :)

>=20
> ACPI to PCI association is then typical pci_root lookup, i.e.:
>=20
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 pci_root =3D acpi_pci_find_roo=
t(hb->handle);
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 bridge =3D pci_root->bus->brid=
ge;

Yes, this here.  In my use case, I'm starting with a PCIe/CXL device.
In my driver, I try to discover the host bridge, and then the ACPI _UID
so I can look things up in the CEDT.

So I'm trying to do the programmatic equivalent of this:

Start here in my PCIe/CXL host driver:

/sys/devices/pci0000:37/firmware_node =3D>
./LNXSYSTM:00/LNXSYBUS:00/ACPI0016:02

Retrieve _UID (uid) from /sys/devices/pci0000:37/firmware_node/uid

Buggy BIOS, that above value resolves to CX02.  In fact, it *should* be
49.  This is very much a bug in the ACPI arena.

The kernel APIs allowing me to walk this path would fail in the
acpi_evaluate_object() when trying to pass in the bad _UID (CX02).

Again, sorry for the confusion if it looked like I was trying to
implicate PCI in any way.  The whole intent here was to leave some
breadcrumbs so anyone else running into this wouldn't be left
scratching their heads wondering wtf was going on.

Cheers,
-PJ