[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <68027c9b27e42_1834cf29448@iweiny-mobl.notmuch>
Date: Fri, 18 Apr 2025 11:23:55 -0500
From: Ira Weiny <ira.weiny@...el.com>
To: Smita Koralahalli <Smita.KoralahalliChannabasappa@....com>,
<linux-kernel@...r.kernel.org>, <linux-cxl@...r.kernel.org>
CC: Alison Schofield <alison.schofield@...el.com>, Vishal Verma
<vishal.l.verma@...el.com>, Ira Weiny <ira.weiny@...el.com>, Dan Williams
<dan.j.williams@...el.com>, Jonathan Cameron <Jonathan.Cameron@...wei.com>,
Yazen Ghannam <yazen.ghannam@....com>, Terry Bowman <terry.bowman@....com>,
Smita Koralahalli <Smita.KoralahalliChannabasappa@....com>, Robert Richter
<rrichter@....com>
Subject: Re: [PATCH] cxl/core/regs.c: Skip Memory Space Enable check for RCD
and RCH Ports
Smita Koralahalli wrote:
> According to CXL r3.2 section 8.2.1.2, the PCI_COMMAND register fields,
> including Memory Space Enable bit, have no effect on the behavior of an
> RCD Upstream Port. Retaining this check may incorrectly cause
> cxl_pci_probe() to fail on a valid RCD upstream Port.
>
> While the specification is explicit only for RCD Upstream Ports, this
> check is solely for accessing the RCRB, which is always mapped through
> memory space. Therefore, its safe to remove the check entirely. In
> practice, firmware reliably enables the Memory Space Enable bit for
> RCH Downstream Ports and no failures have been observed.
>
> Removing the check simplifies the code and avoids unnecessary
> special-casing, while relying on BIOS/firmware to configure devices
> correctly. Moreover, any failures due to inaccessible RCRB regions
> will still be caught either in __rcrb_to_component() or while
> parsing the component register block.
>
> The following failure was observed in dmesg when the check was present:
> cxl_pci 0000:7f:00.0: No component registers (-6)
>
> Fixes: d5b1a27143cb ("cxl/acpi: Extract component registers of restricted hosts from RCRB")
> Signed-off-by: Smita Koralahalli <Smita.KoralahalliChannabasappa@....com>
Reviewed-by: Ira Weiny <ira.weiny@...el.com>
[snip]
Powered by blists - more mailing lists