Linux CXL
 help / color / mirror / Atom feed
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
Subject: Re: [PATCH 1/1] cxl/acpi.c: Add buggy BIOS hint for CXL ACPI lookup failure
Date: Wed, 01 May 2024 08:28:22 -0700	[thread overview]
Message-ID: <f5078550384a6b9be5a6d05415ea321332c7fb96.camel@kernel.org> (raw)
In-Reply-To: <662fe860eb889_1487294e8@dwillia2-mobl3.amr.corp.intel.com.notmuch>

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 wrote:
> > > > > From: PJ Waskiewicz <ppwaskie@kernel.org>
> > > > > 
> > > > > 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.
> [..] 
> > 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?
> 
> 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.  :)

> 
> ACPI to PCI association is then typical pci_root lookup, i.e.:
> 
>         pci_root = acpi_pci_find_root(hb->handle);
>         bridge = pci_root->bus->bridge;

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 =>
../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

  reply	other threads:[~2024-05-01 15:28 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-07 21:05 [PATCH 1/1] cxl/acpi.c: Add buggy BIOS hint for CXL ACPI lookup failure ppwaskie
2024-04-07 21:28 ` Lukas Wunner
2024-04-08  2:03   ` PJ Waskiewicz
2024-04-08  8:34     ` Jonathan Cameron
2024-04-08 19:29       ` PJ Waskiewicz
2024-04-08 20:45         ` Dan Williams
2024-04-08 21:32           ` PJ Waskiewicz
2024-04-09  4:22             ` PJ Waskiewicz
2024-04-08 16:54 ` Dan Williams
2024-04-08 19:25   ` PJ Waskiewicz
2024-04-09 13:22 ` Bjorn Helgaas
2024-04-29  5:57   ` PJ Waskiewicz
2024-04-29 15:31     ` Bjorn Helgaas
2024-04-29 18:35       ` Dan Williams
2024-05-01 15:28         ` PJ Waskiewicz [this message]
2024-05-01 15:47           ` Dan Williams
2024-05-02 17:34             ` PJ Waskiewicz
2024-05-02 18:29               ` Dan Williams
2024-05-01 17:54           ` Bjorn Helgaas
2024-05-02 17:30             ` PJ Waskiewicz

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=f5078550384a6b9be5a6d05415ea321332c7fb96.camel@kernel.org \
    --to=ppwaskie@kernel.org \
    --cc=dan.j.williams@intel.com \
    --cc=helgaas@kernel.org \
    --cc=linux-cxl@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    /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