Re: [PATCH] Add support for turning PCIe ECRC on or off

[Kenji Kaneshige]

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/