From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8D8DFC433DB for ; Wed, 6 Jan 2021 23:12:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5504523142 for ; Wed, 6 Jan 2021 23:12:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726439AbhAFXMW (ORCPT ); Wed, 6 Jan 2021 18:12:22 -0500 Received: from mail.kernel.org ([198.145.29.99]:47582 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725788AbhAFXMV (ORCPT ); Wed, 6 Jan 2021 18:12:21 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 631FD225AC; Wed, 6 Jan 2021 23:11:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1609974700; bh=C4lkCxq3GgpIZnzJfvMgGcqHjmU2Xc7PbSpPSnKU/7A=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=MPCGJRH+rxnFAiLtgNX43diPJzGYKtNVmdsQNqc7ITnYe7s1YxYF4b5m23Xm0xgiJ owZ/vBZYJmDsixuBNrON2YUAMPMV3ks+B+pAPxj79/plkwvRe/4pdB79mLHgqLCROZ opbYJnAMrW/htY19T+KTSsGKVhdBiZyQ/TecMneAsH+uH+y97OdNkcPu5Rj131ZrGt y+kw6ft6WCt6a689lqrt2lpUW4Ay7nJAZijjPEo0vgfGDBrMPbgRWacXVSoKtZP+Ds kLjRgmeg5EU/faSdPi5YwVlX3RvTgcKbMRb+S471if/hTECfxAReQxyxe1UAOyNSfk KpLjyA2RguIlQ== Date: Wed, 6 Jan 2021 17:11:39 -0600 From: Bjorn Helgaas To: Jim Quinlan Cc: Jim Quinlan , Bjorn Helgaas , linux-pci , Nicolas Saenz Julienne , Mark Brown , bcm-kernel-feedback-list , Lorenzo Pieralisi , Rob Herring , Florian Fainelli , "moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" , "moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" , open list Subject: Re: [PATCH v2 5/6] PCI: brcmstb: Add panic/die handler to RC driver Message-ID: <20210106231139.GA1350432@bjorn-Precision-5520> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org On Wed, Jan 06, 2021 at 02:57:19PM -0500, Jim Quinlan wrote: > On Wed, Jan 6, 2021 at 2:42 PM Jim Quinlan wrote: > > > > ---------- Forwarded message --------- > > From: Bjorn Helgaas > > Date: Wed, Jan 6, 2021 at 2:19 PM > > Subject: Re: [PATCH v2 5/6] PCI: brcmstb: Add panic/die handler to RC driver > > To: Jim Quinlan > > Cc: , Nicolas Saenz Julienne > > , , > > , Lorenzo Pieralisi > > , Rob Herring , Bjorn > > Helgaas , Florian Fainelli > > , moderated list:BROADCOM BCM2711/BCM2835 ARM > > ARCHITECTURE , moderated > > list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE > > , open list > > > > > > > > On Mon, Nov 30, 2020 at 04:11:42PM -0500, Jim Quinlan wrote: > > > Whereas most PCIe HW returns 0xffffffff on illegal accesses and the like, > > > by default Broadcom's STB PCIe controller effects an abort. This simple > > > handler determines if the PCIe controller was the cause of the abort and if > > > so, prints out diagnostic info. > > > > > > Example output: > > > brcm-pcie 8b20000.pcie: Error: Mem Acc: 32bit, Read, @0x38000000 > > > brcm-pcie 8b20000.pcie: Type: TO=0 Abt=0 UnspReq=1 AccDsble=0 BadAddr=0 > > > > What does this mean for all the other PCI core code that expects > > 0xffffffff data returns? Does it work? Does it break differently on > > STB than on other platforms? > Hi Bjorn, > > Our PCIe HW causes a CPU abort when this happens. Occasionally a > customer will have a fault handler try to fix up the abort and > continue on, but we recommend solving the root problem. This commit > just gives us a chance to glean info about the problem. Our newer > SOCs have a mode that doesn't abort and instead returns 0xffffffff. > > BTW, can you point me to example files where "PCI core code that > expects 0xffffffff data returns" [on bad accesses]? The most important case is during enumeration. A config read to a device that doesn't exist normally terminates as an Unsupported Request, and pci_bus_generic_read_dev_vendor_id() depends on reading 0xffffffff in that case. I assume this particular case does work that way for brcm-pcie, because I assume enumeration does work. pci_cfg_space_size_ext() is similar. I assume this also works for brcm-pcie for the same reason. pci_raw_set_power_state() looks for ~0, which it may see if it does a config read to a device in D3cold. pci_dev_wait(), dpc_irq(), pcie_pme_work_fn(), pcie_pme_irq() are all similar. Yes, this is ugly and we should check for these more consistently. The above are all for config reads. The PCI core doesn't do MMIO accesses except for a few cases like MSI-X. But drivers do, and if they check for PCIe errors on MMIO reads, they do it by looking for 0xffffffff, e.g., pci_mmio_enabled() (in hfi1), qib_pci_mmio_enabled(), bnx2x_get_hwinfo(), etc. Bjorn