From: "Verma, Vishal L" <vishal.l.verma@intel.com>
To: "Williams, Dan J" <dan.j.williams@intel.com>
Cc: "rafael@kernel.org" <rafael@kernel.org>,
"Moore, Robert" <robert.moore@intel.com>,
"linux-cxl@vger.kernel.org" <linux-cxl@vger.kernel.org>,
"Jonathan.Cameron@huawei.com" <Jonathan.Cameron@huawei.com>,
"Wysocki, Rafael J" <rafael.j.wysocki@intel.com>,
"bhelgaas@google.com" <bhelgaas@google.com>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>
Subject: Re: [RFC PATCH 2/2] acpi/pci_root: negotiate CXL _OSC
Date: Thu, 17 Mar 2022 03:49:48 +0000 [thread overview]
Message-ID: <7c577fd6c824890144b698a9e7164ab334b14016.camel@intel.com> (raw)
In-Reply-To: <CAPcyv4iOOrefEF5QOrZyvPYJ9_5GuhpMKPeSbvVXci=qGevmBw@mail.gmail.com>
On Wed, 2022-03-16 at 20:19 -0700, Dan Williams wrote:
> On Wed, Mar 16, 2022 at 5:27 PM Vishal Verma <vishal.l.verma@intel.com> wrote:
> >
> > Add full support for negotiating _OSC as defined in the CXL 2.0 spec, as
> > applicable to CXL-enabled platforms. Advertise support for the CXL
> > features we support - 'CXL 2.0 port/device register access', 'Protocol
> > Error Reporting', and 'CL Native Hot Plug'. Request control for 'CXL
> > Memory Error Reporting'. The requests are dependent on CONFIG_* based
> > pre-requisites, and prior PCI enabling, similar to how the standard PCI
> > _OSC bits are determined.
>
> Might want to add a clarification here of why this just reflects the
> PCIe support into the similar CXL fields. For example:
>
> The CXL specification does not define any additional constraints on
> the hotplug flow beyond PCIe native hotplug, so a kernel that supports
> native PCIe hotplug, supports CXL hotplug. For error handling protocol
> and link errors just use PCIe AER. There is nascent support for
> amending AER events with CXL specific status [1], but there's
> otherwise no additional OS responsibility for CXL errors beyond PCIe
> AER. CXL Memory Errors behave the same as typical memory errors so
> CONFIG_MEMORY_FAILURE is sufficient to indicate support to platform
> firmware.
>
> [1]: https://lore.kernel.org/linux-cxl/164740402242.3912056.8303625392871313860.stgit@dwillia2-desk3.amr.corp.intel.com/
Yes that sounds good, will add.
> >
[..]
> > @@ -440,6 +511,18 @@ static u32 calculate_support(void)
> > return support;
> > }
> >
> > +static u32 calculate_cxl_support(void)
> > +{
> > + u32 support;
> > +
> > + support = OSC_CXL_2_0_PORT_DEV_REG_ACCESS_SUPPORT;
> > + support |= OSC_CXL_PER_SUPPORT;
>
> I would expect this one to be gated by pci_aer_available() since these
> errors are reported by PCIe AER.
>
> Perhaps also s/PER/PORT_ERROR/? I keep reading PER like 'per' as in 'per-cpu'.
Expanding the acronym sounds good, though it is Protocol Error
Reporting, not Port.
>
> > + if (IS_ENABLED(CONFIG_HOTPLUG_PCI_PCIE))
> > + support |= OSC_CXL_NATIVE_HP_SUPPORT;
> > +
> > + return support;
> > +}
> > +
> > static u32 calculate_control(void)
> > {
> > u32 control;
> > @@ -471,6 +554,16 @@ static u32 calculate_control(void)
> > return control;
> > }
> >
> > +static u32 calculate_cxl_control(void)
> > +{
> > + u32 control;
> > +
> > + if (pci_aer_available())
> > + control |= OSC_CXL_ERROR_REPORTING_CONTROL;
>
> In this case the error handling is for memory errors, so this one should be:
>
> if (IS_ENABLED(CONFIG_MEMORY_FAILURE))
> control |= OSC_CXL_ERROR_REPORTING_CONTROL;
Makes sense, I'll change to this.
>
> ...other than that looks good to me.
Thanks for the review!
>
next prev parent reply other threads:[~2022-03-17 6:12 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-17 0:27 [RFC PATCH 0/2] acpi: add support for CXL _OSC Vishal Verma
2022-03-17 0:27 ` [RFC PATCH 1/2] PCI/ACPI: Use CXL _OSC instead of PCIe _OSC Vishal Verma
2022-03-17 1:47 ` Dan Williams
2022-03-17 15:40 ` Jonathan Cameron
2022-03-17 0:27 ` [RFC PATCH 2/2] acpi/pci_root: negotiate CXL _OSC Vishal Verma
2022-03-17 3:19 ` Dan Williams
2022-03-17 3:49 ` Verma, Vishal L [this message]
2022-03-17 16:10 ` Jonathan Cameron
2022-03-18 21:16 ` Verma, Vishal L
2022-03-17 15:19 ` [RFC PATCH 0/2] acpi: add support for " Jonathan Cameron
2022-03-18 19:52 ` Verma, Vishal L
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=7c577fd6c824890144b698a9e7164ab334b14016.camel@intel.com \
--to=vishal.l.verma@intel.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=bhelgaas@google.com \
--cc=dan.j.williams@intel.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-cxl@vger.kernel.org \
--cc=rafael.j.wysocki@intel.com \
--cc=rafael@kernel.org \
--cc=robert.moore@intel.com \
/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;
as well as URLs for NNTP newsgroup(s).