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=-3.8 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 8D512C433E2 for ; Wed, 15 Jul 2020 22:14:12 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (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 3756B2065F for ; Wed, 15 Jul 2020 22:14:12 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="S/WhYifu" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3756B2065F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from bilbo.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 4B6WrL1MNwzDqLy for ; Thu, 16 Jul 2020 08:14:10 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=kernel.org (client-ip=198.145.29.99; helo=mail.kernel.org; envelope-from=helgaas@kernel.org; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=pass (p=none dis=none) header.from=kernel.org Authentication-Results: lists.ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=default header.b=S/WhYifu; dkim-atps=neutral Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4B6WpW1hKhzDqGt for ; Thu, 16 Jul 2020 08:12:35 +1000 (AEST) Received: from localhost (mobile-166-175-191-139.mycingular.net [166.175.191.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 3066F2065F; Wed, 15 Jul 2020 22:12:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1594851152; bh=yiFReVioS6K+TBmJa6LKAY/XmzClp9+1AGEcxSQDlBk=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=S/WhYifuBwhLApPX94Rc/0RHdh1EsD3Lsktt1aoGethpDycX9QnYAuXsckOndJhw5 n3QaIQohtvY8AFWnVXQuc092VZjXlIZnqtKtIWZvilP5gx9OzeqCMahn+95Usq7PJx YtSiGFgryUo4JNKSiAdj114J+tlIwEPKap8PPewk= Date: Wed, 15 Jul 2020 17:12:30 -0500 From: Bjorn Helgaas To: David Laight Subject: Re: [RFC PATCH 00/35] Move all PCIBIOS* definitions into arch/x86 Message-ID: <20200715221230.GA563957@bjorn-Precision-5520> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1e2ae69a55f542faa18988a49e9b9491@AcuMS.aculab.com> X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Greg Kroah-Hartman , linux-pci , "bjorn@helgaas.com" , Paul Mackerras , sparclinux , Toan Le , Christoph Hellwig , Marek Vasut , Rob Herring , Lorenzo Pieralisi , Sagi Grimberg , Kevin Hilman , Russell King , Ley Foon Tan , Greg Ungerer , Geert Uytterhoeven , Jakub Kicinski , Matt Turner , "linux-kernel-mentees@lists.linuxfoundation.org" , Guenter Roeck , Arnd Bergmann , Ray Jui , linuxppc-dev , Jens Axboe , Ivan Kokshaysky , Shuah Khan , Keith Busch , Boris Ostrovsky , Richard Henderson , Juergen Gross , Thomas Bogendoerfer , Scott Branden , Jingoo Han , "linux-kernel@vger.kernel.org" , Philipp Zabel , "Saheed O. Bolarinwa" , 'Oliver O'Halloran' , Gustavo Pimentel , Bjorn Helgaas , "David S. Miller" , Heiner Kallweit Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Wed, Jul 15, 2020 at 02:38:29PM +0000, David Laight wrote: > From: Oliver O'Halloran > > Sent: 15 July 2020 05:19 > > > > On Wed, Jul 15, 2020 at 8:03 AM Arnd Bergmann wrote: > ... > > > - config space accesses are very rare compared to memory > > > space access and on the hardware side the error handling > > > would be similar, but readl/writel don't return errors, they just > > > access wrong registers or return 0xffffffff. > > > arch/powerpc/kernel/eeh.c has a ton extra code written to > > > deal with it, but no other architectures do. > > > > TBH the EEH MMIO hooks were probably a mistake to begin with. Errors > > detected via MMIO are almost always asynchronous to the error itself > > so you usually just wind up with a misleading stack trace rather than > > any kind of useful synchronous error reporting. It seems like most > > drivers don't bother checking for 0xFFs either and rely on the > > asynchronous reporting via .error_detected() instead, so I have to > > wonder what the point is. I've been thinking of removing the MMIO > > hooks and using a background poller to check for errors on each PHB > > periodically (assuming we don't have an EEH interrupt) instead. That > > would remove the requirement for eeh_dev_check_failure() to be > > interrupt safe too, so it might even let us fix all the godawful races > > in EEH. > > I've 'played' with PCIe error handling - without much success. > What might be useful is for a driver that has just read ~0u to > be able to ask 'has there been an error signalled for this device?'. In many cases a driver will know that ~0 is not a valid value for the register it's reading. But if ~0 *could* be valid, an interface like you suggest could be useful. I don't think we have anything like that today, but maybe we could. It would certainly be nice if the PCI core noticed, logged, and cleared errors. We have some of that for AER, but that's an optional feature, and support for the error bits in the garden-variety PCI_STATUS register is pretty haphazard. As you note below, this sort of SERR/PERR reporting is frequently hard-wired in ways that takes it out of our purview. Bjorn