linux-acpi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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!

> 

  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).