[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c1fb95450690466eb562f48666902cd2@AUSX13MPC107.AMER.DELL.COM>
Date: Tue, 10 Mar 2020 20:49:29 +0000
From: <Austin.Bolen@...l.com>
To: <sathyanarayanan.kuppuswamy@...ux.intel.com>,
<Austin.Bolen@...l.com>, <helgaas@...nel.org>
CC: <linux-pci@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<ashok.raj@...el.com>
Subject: Re: [PATCH v17 09/12] PCI/AER: Allow clearing Error Status Register
in FF mode
On 3/10/2020 3:44 PM, Kuppuswamy Sathyanarayanan wrote:
>
<snip>
>
> Please check the following spec reference (change to 4.5.1 Table 4-6)
>
> the OS is permitted to read or write DPC Control and Status registers of a
> port while processing an Error Disconnect Recover notification from firmware
> on that port. Error Disconnect Recover notification processing begins
> with the
> Error Disconnect Recover notify from Firmware, and *ends when the OS
> releases
> DPC by clearing the DPC Trigger Status bit*.Firmware can read DPC Trigger
> Status bit to determine the ownership of DPC Control and Status
> registers. Firmware
> is not permitted to write to DPC Control and Status registers if DPC
> Trigger Status is
> set i.e. the link is in DPC state. *Outside of the Error Disconnect
> Recover notification
> processing window, the OS is not permitted to modify DPC Control or
> Status registers*;
> only firmware is allowed to.
>
> Since the EDR processing window ends with clearing DPC Trigger status
> bit, OS needs to
> clear DPC and AER registers before it ends.
>
> Austin,
>
> I think the order needs to be reversed in the implementation note.
Agreed.
Powered by blists - more mailing lists