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=-5.5 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_2 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 35F14C433E3 for ; Wed, 15 Jul 2020 02:22:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 174C820729 for ; Wed, 15 Jul 2020 02:22:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728299AbgGOCWb (ORCPT ); Tue, 14 Jul 2020 22:22:31 -0400 Received: from kernel.crashing.org ([76.164.61.194]:36952 "EHLO kernel.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726458AbgGOCWb (ORCPT ); Tue, 14 Jul 2020 22:22:31 -0400 Received: from localhost (gate.crashing.org [63.228.1.57]) (authenticated bits=0) by kernel.crashing.org (8.14.7/8.14.7) with ESMTP id 06F2JlC0001315 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 14 Jul 2020 21:19:51 -0500 Message-ID: <2629240c07af7fec5989127ed6da405e12cf77a3.camel@kernel.crashing.org> Subject: Re: [RFC PATCH 00/35] Move all PCIBIOS* definitions into arch/x86 From: Benjamin Herrenschmidt To: Bjorn Helgaas , Arnd Bergmann Cc: "Saheed O. Bolarinwa" , bjorn@helgaas.com, Shuah Khan , linux-pci , linux-kernel-mentees@lists.linuxfoundation.org, "linux-kernel@vger.kernel.org" , Richard Henderson , Ivan Kokshaysky , Matt Turner , Greg Ungerer , Geert Uytterhoeven , Russell King , Boris Ostrovsky , Juergen Gross , Thomas Bogendoerfer , Michael Ellerman , Paul Mackerras , linuxppc-dev , "David S. Miller" , sparclinux , Guenter Roeck , Greg Kroah-Hartman , Heiner Kallweit , Jakub Kicinski , Keith Busch , Jens Axboe , Christoph Hellwig , Sagi Grimberg , Lorenzo Pieralisi , Rob Herring , Bjorn Helgaas , Kevin Hilman , Philipp Zabel , Jingoo Han , Gustavo Pimentel , Toan Le , Ray Jui , Scott Branden , Ley Foon Tan , Marek Vasut , Kjetil Oftedal Date: Wed, 15 Jul 2020 12:19:46 +1000 In-Reply-To: <20200714234625.GA428442@bjorn-Precision-5520> References: <20200714234625.GA428442@bjorn-Precision-5520> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org On Tue, 2020-07-14 at 18:46 -0500, Bjorn Helgaas wrote: > Yes. I have no problem with that. There are a few cases where it's > important to check for errors, e.g., we read a status register and do > something based on a bit being set. A failure will return all bits > set, and we may do the wrong thing. But most of the errors we care > about will be on MMIO reads, not config reads, so we can probably > ignore most config read errors. And in both cases, we don't have the plumbing to provide accurate and reliable error returns for all platforms anyways (esp. not for MMIO). I think it makes sense to stick to the good old "if all 1's, then go out of line" including for config space. ../.. > Yep, except for things like device removal or other PCI errors. A whole bunch of these are reported asynchronously, esp for writes (and yes, including config writes, they are supposed to be non-posted but more often than not, the path from the CPU to the PCI bridge remains posted for writes including config ones). > So maybe a good place to start is by removing some of the useless > error checking for pci_read_config_*() and pci_write_config_*(). > That's a decent-sized but not impractical project that could be done > per subsystem or something: > > git grep -E "(if|return|=).*\ > finds about 400 matches. > > Some of those callers probably really *do* want to check for errors, > and I guess we'd have to identify them and do them separately as you > mentioned. I'd be curious about these considering how unreliable our error return is accross the board. Cheers, Ben.