Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 10 Aug 2023 18:20:41 -0500
From:   Bjorn Helgaas <helgaas@kernel.org>
To:     LeoLiu-oc <LeoLiu-oc@zhaoxin.com>
Cc:     lenb@kernel.org, james.morse@arm.com, tony.luck@intel.com,
        bp@alien8.de, bhelgaas@google.com, robert.moore@intel.com,
        linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-pci@vger.kernel.org, acpica-devel@lists.linuxfoundation.org
Subject: Re: [PATCH v3 0/5] Parse the PCIe AER and set to relevant registers
Message-ID: <20230810232041.GA50619@bhelgaas>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20230704120453.1322069-1-LeoLiu-oc@zhaoxin.com>
Precedence: bulk

On Tue, Jul 04, 2023 at 08:04:53PM +0800, LeoLiu-oc wrote:
> From: leoliu-oc <leoliu-oc@zhaoxin.com>
> 
> According to the sec 18.3.2.4, 18.3.2.5 and 18.3.2.6 in ACPI r6.5, the
> register values form HEST PCI Express AER Structure should be written to
> relevant PCIe Device's AER Capabilities. So the purpose of the patch set
> is to extract register values from HEST PCI Express AER structures and
> program them into AER Capabilities.
> Refer to the ACPI Spec r6.5 for a more detailed description.
> Considering that HEST AER patch is an effective supplement to _HPP/_HPX
> method when the Firmware does not support the _HPP/_HPX method and can be
> specially configured for the AER register of a specific device.
> The question about whether OS has control of AER to write the information
> in the HEST AER structure to the AER register of the corresponding device
> is similar to the question about _HPX/_HPP method to write the AER
> information to the AER register of the corresponding device.I looked in
> ACPI Spec for a description of the relationship between writing to the AER
> register through the _HPP/_HPX method and whether the OS requires AER
> control:
> 1.OSPM uses the information returned by _HPX to determine how to
> configure PCI Functions that are hot- plugged into the system, to
> configure Functions not configured by the platform firmware during initial
> system boot, and to configure Functions any time they lose configuration
> space settings (e.g. OSPM issues a Secondary Bus Reset/Function Level
> Reset or Downstream Port Containment is triggered).
> 
> 2._HPX may return multiple types or Record Settings (each setting in a
> single sub-package.) OSPM is responsible for detecting the type of
> Function and for applying the appropriate settings. OSPM is also
> responsible for detecting the device / port type of the PCI Express
> Function and applying the appropriate settings provided.
> For example, the Secondary Uncorrectable Error Severity and Secondary
> Uncorrectable Error Mask settings of Type 2 record are only applicable to
> PCI Express to PCI-X/PCI Bridge whose device / port type is 1000b.
> Similarly, AER settings are only applicable to hot plug PCI Express
> devices that support the optional AER capability.
> 
> 3.Note: OSPM may override the settings provided by the _HPX object's Type2
> record (PCI Express Settings) or Type3 record (PCI Express Descriptor
> Settings) when OSPM has assumed native control of the corresponding
> feature. For example, if OSPM has assumed ownership of AER (via _OSC),
> OSPM may override AER related settings returned by _HPX. This means that
> writing the AER register value by _HPX does not require the OS to gain
> control of the AER. Also from the usage description of _HPX, I think
> ownership of AER means who decides the configuration value of the AER
> register rather than who can write the configuration value. Even though
> the OS does not have control or ownership of the AER, it should still
> write the configuration values determined by the firmware to the AER
> register at the request of the firmware. 
> Therefore, the ownership of AER is not considered in this patch.

There's a lot of good information above, but this is the cover letter,
so it won't make it into the git history.  Can you move this
information to the relevant patches, where it will help justify the
need for the patch?

Also, if at all possible, can you arrange for the patches themselves
to be sent as *responses* to the cover letter?  This makes the series
thread nicely and makes it much easier to download and apply it.

Bjorn