lkml.org 
[lkml]   [2009]   [Apr]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] Add support for turning PCIe ECRC on or off
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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2009-04-08 03:07    [W:1.304 / U:0.288 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site