Andrew Patterson wrote:
On Tue, 2009-04-07 at 10:43 +0900, Kenji Kaneshige wrote:
Andrew Patterson wrote:
On Fri, 2009-04-03 at 11:08 +0900, Kenji Kaneshige wrote:
Andrew Patterson wrote:
Add support for turning PCIe ECRC on or off
(snip.)
The reason why I think we need to request control over AER from firmware
is based on the following descriptions in "6.2.9 _OSC (Operating System
Capabilities) of ACPI3.0b spec. For example,
"... If any bits in the Control Field are returned cleared (masked
to zero) by the _OSC control method, the respective feature is
designated unsupported by the platform and must not be enabled by the
OS. Some of these features may be controlled by platform firmware
prior to OS boot or during runtime for a legacy OS, while others may
be disabled/inoperative until native OS support is available. ..."
(in "6.2.9.1 _OSC Implementation Example for PCI Host Bridge Devices")
"... The OS must evaluate _OSC under the following conditions:
During initialization of any driver that provides native support for
features described in the section above. ..." (in "6.2.9.1.1.2
Evaluation Conditions")
Please also see "Table 6-10 Interpretation of _OSC Control Field, Passed
in via Arg3" and "Table 6-11 Interpretation of _OSC Control Field,
Returned Value".
Here is the AER entry in table 6-11:
"The firmware sets this bit to 1 to grant control over PCI Express
Advanced Error Reporting. If firmware allows the OS control of this
feature, then in the context of
the _OSC method it must ensure that error messages are routed to device
interrupts as described in the PCI Express Base Specification.
Additionally, after control is transferred to the OS, firmware must not
modify the Advanced Error Reporting Capability. If control of this
feature was requested and denied or was not requested, firmware returns
this bit set to 0."
Does this mean that you can't access any of the bits in any AER
registers unless you take control via _OSC? On the other hand, given
that firmware cannot touch AER registers after _OSC grants control, it
makes some sense that software cannot do so without permission.
Yes, I think so.
(I think we cannot program AER registers).
And my interpretation is also based on the following spec in "6.2.7.3
PCI Express Setting Record (Type 2)" in ACPI3.0b.
"... The Type 2 Setting Record allows a PCI Express-aware OS that
supports native hot plug to configure the specified registers of the
hot plugged PCI Express device. A PCI Express-aware OS that has
assumed ownership of native hot plug (via _OSC) but does not support
or does not have ownership of the AER register set must use the data
values returned by the _HPX object‘s Type 2 record to program the
AER registers of a hot-added PCI Express device. ..."
I believe "PCI Express Advanced Error capabilities and Control Register"
is one of the AER registers.
Yes.
I am mostly convinced. I will rework this.
Just in case, what I thought from the description of _HPX is that the
OS must not program AER registers by its own decision if the OS does
not have ownership of the AER registers.
Thanks,
Kenji Kaneshige
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
