linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bjorn Helgaas <bhelgaas@google.com>
To: "Chen, Gong" <gong.chen@linux.intel.com>
Cc: rdunlap@infradead.org, bp@alien8.de, tony.luck@intel.com,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RESEND RFC 5/5] PCIe, AER: Update initial value of UC error mask
Date: Fri, 5 Sep 2014 17:34:21 -0600	[thread overview]
Message-ID: <20140905233421.GL8080@google.com> (raw)
In-Reply-To: <1407910961-7798-6-git-send-email-gong.chen@linux.intel.com>

On Wed, Aug 13, 2014 at 02:22:41AM -0400, Chen, Gong wrote:
> In PCI-e SPEC r3.0, BIT 0 of Uncorrectable Error Status Register
> is redefined and it has an explicit requirement that when writing
> this field, a value of 1b is the only choice. So change previous
> initial maks from 0 to 1.
> 
> Signed-off-by: Chen, Gong <gong.chen@linux.intel.com>
> ---
> NOTE: After scratching all use cases, this is the most obvious use
> case to violate the SPEC. Most of use cases just read first and
> then overwrite for clear purpose. Even so, such fix is obvious to
> not compatiable with previous SPEC definition. Do we need a dirty
> hack?
> 
>  arch/mips/pci/pci-octeon.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/mips/pci/pci-octeon.c b/arch/mips/pci/pci-octeon.c
> index 59cccd95688b..f1bfdc201297 100644
> --- a/arch/mips/pci/pci-octeon.c
> +++ b/arch/mips/pci/pci-octeon.c
> @@ -134,7 +134,7 @@ int pcibios_plat_dev_init(struct pci_dev *dev)
>  				       dconfig);
>  		/* Enable reporting of all uncorrectable errors */
>  		/* Uncorrectable Error Mask - turned on bits disable errors */
> -		pci_write_config_dword(dev, pos + PCI_ERR_UNCOR_MASK, 0);
> +		pci_write_config_dword(dev, pos + PCI_ERR_UNCOR_MASK, 1);

I see the text in the spec that says we should only write 1 to bit 0 (sec
7.10.3, for anybody following along).  It looks like that change was made
between PCIe r1.0 and r1.1.  It would really be nice to have more context
about why the change was made, because if there's hardware in the field
that implements r1.0 behavior, this patch will change the way it works, and
I don't know how to verify that is safe.

Does this actually change fix a problem?  If it fixes a problem that
happens on real hardware, that's a much better reason to make a change than
just to comply with the spec.

Sec 7.10.2 also says we should ignore the value of bit 0 in the
Uncorrectable Error Status register, and I don't see any place where we
follow that advice.

Bjorn

>  		 * Leave severity at HW default. This only controls if
>  		 * errors are reported as uncorrectable or
> -- 
> 2.0.0.rc2
> 

  reply	other threads:[~2014-09-05 23:34 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-13  6:22 [RESEND 0/5] PCIe, AER: Misc cleanup Chen, Gong
2014-08-13  6:22 ` [RESEND 1/5] RAS, trace: Update error definition format Chen, Gong
2014-08-13  6:22 ` [RESEND 2/5] PCIe, AER: Replenish missed AER status bits for AER driver Chen, Gong
2014-09-05 23:15   ` Bjorn Helgaas
2014-09-09  7:03     ` Chen, Gong
2014-09-25 15:51   ` Bjorn Helgaas
2014-08-13  6:22 ` [RESEND 3/5] PCIe, trace: Replenish missed AER status bits for PCIE trace I/F Chen, Gong
2014-08-13  6:22 ` [RESEND 4/5] PCIe, AER: Make AER UC status naming clearer Chen, Gong
2014-08-13  6:22 ` [RESEND RFC 5/5] PCIe, AER: Update initial value of UC error mask Chen, Gong
2014-09-05 23:34   ` Bjorn Helgaas [this message]
2014-09-09  7:12     ` Chen, Gong
2014-08-13 13:52 ` [RESEND 0/5] PCIe, AER: Misc cleanup Bjorn Helgaas
2014-08-14  1:52   ` Chen, Gong
2014-09-02  1:31     ` Chen, Gong
2014-09-25 15:54 ` Bjorn Helgaas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140905233421.GL8080@google.com \
    --to=bhelgaas@google.com \
    --cc=bp@alien8.de \
    --cc=gong.chen@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=rdunlap@infradead.org \
    --cc=tony.luck@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).