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=-4.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,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 C1361C433E0 for ; Wed, 6 Jan 2021 23:14:24 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 6D6C423332 for ; Wed, 6 Jan 2021 23:14:24 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6D6C423332 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Message-ID:Subject:To:From: Date:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:References:List-Owner; bh=9Bm61ptOWhpAsApPPzzJbWJuWeoPiRbOLw5a8WeNhKI=; b=I2XqQPx5kYXTw782wJbuL1tEy FjDzHhIUKa0MriIhfGQUPLVB1o66cXyqrB3DPNFNNtVrWhZ9vlyJp8Bdy4HcAc4x+671rdzrf88mN XMqJBloSOj8fISuimWKpOePxZLMza0DuSxElHBIcBOv5sffqSLcFjOQGWyYXFpJAintOb9tPsyZvp H7bHnsowREquxdPkElqWmrexzeCr7qZiIuDHoNEd7USloDcmrgBa/rgDpBMKNWzBfdxdClQjH+/v0 r/ZacXOwru0HDZhomeTyMRqR5gDF1YTYjS3Yj7b74+QtmcF2uDVpbkhj0mMXrpB7unMg7bhRT9pAR ZJPBiwjXg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kxHxx-00037r-0Q; Wed, 06 Jan 2021 23:11:45 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kxHxt-00037S-M7; Wed, 06 Jan 2021 23:11:42 +0000 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 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-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210106_181141_855217_3734506A X-CRM114-Status: GOOD ( 21.63 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" , Lorenzo Pieralisi , linux-pci , open list , Mark Brown , bcm-kernel-feedback-list , "moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" , Jim Quinlan , Bjorn Helgaas , Florian Fainelli , Nicolas Saenz Julienne Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel