From patchwork Wed Oct 25 22:10:46 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Bjorn Helgaas X-Patchwork-Id: 10027299 X-Patchwork-Delegate: bhelgaas@google.com Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id CC1046032C for ; Wed, 25 Oct 2017 22:10:51 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id BEB0928649 for ; Wed, 25 Oct 2017 22:10:51 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id B37EA289FD; Wed, 25 Oct 2017 22:10:51 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 6816228713 for ; Wed, 25 Oct 2017 22:10:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752006AbdJYWKt (ORCPT ); Wed, 25 Oct 2017 18:10:49 -0400 Received: from mail.kernel.org ([198.145.29.99]:60400 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752000AbdJYWKs (ORCPT ); Wed, 25 Oct 2017 18:10:48 -0400 Received: from localhost (unknown [64.22.249.253]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id C5A3920C09; Wed, 25 Oct 2017 22:10:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C5A3920C09 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=helgaas@kernel.org Date: Wed, 25 Oct 2017 17:10:46 -0500 From: Bjorn Helgaas To: Alex Williamson Cc: Sinan Kaya , linux-pci@vger.kernel.org, timur@codeaurora.org, linux-arm-msm@vger.kernel.org, Bjorn Helgaas , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH] PCI: rework error checking in the reset path Message-ID: <20171025221046.GA25858@bhelgaas-glaptop.roam.corp.google.com> References: <1508794608-15310-1-git-send-email-okaya@codeaurora.org> <20171025134511.GL21840@bhelgaas-glaptop.roam.corp.google.com> <20171025232805.163ccaad@t450s.home> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20171025232805.163ccaad@t450s.home> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Wed, Oct 25, 2017 at 11:28:05PM +0200, Alex Williamson wrote: > On Wed, 25 Oct 2017 08:45:11 -0500 > Bjorn Helgaas wrote: > > > [+cc Alex] > > > > On Mon, Oct 23, 2017 at 05:36:48PM -0400, Sinan Kaya wrote: > > > The return codes from various reset types are not consistent. The code is > > > assuming that all reset types will return -ENOTTY when things go wrong. > > > Instead of relying on negative error status, let's bail out if the > > > operation is successful instead. > > > > I like this (no surprise since I suggested something similar at > > http://lkml.kernel.org/r/20171011210057.GU25517@bhelgaas-glaptop.roam.corp.google.com), > > but I'd like Alex's opinion before merging it. > > > > Previously, we only tried the next reset method if one method failed > > with -ENOTTY. With this patch, we'll try the next reset method if one > > method fails for any reason, not just -ENOTTY. > > Hmm, I thought the return codes were pretty consistent. -ENOTTY means > that the reset callback doesn't handle the device, move on. Many > ioctls use the same return code to indicate an unknown ioctl. This > allows us to differentiate success vs error vs unhandled. In the code > below we lose the ability to, for instance, have a device specific > reset that returns -EINVAL to prevent the PCI core for triggering > further reset mechanisms which might be broken on the device. So, I > don't see that this patch specifically fixes anything, but it does > remove what seems like useful functionality... I'd veto it. Thanks, I didn't understand the intention of -EINVAL vs -ENOTTY, so that might be a reasonable argument. The knowledge about mechanisms being broken on a specific device seems like it would belong in pci_dev_specific_reset() and not really applicable to other methods, though. But I'm not sure the current usage makes a lot of sense. The only places I found that return an error other than -ENOTTY are reset_ivb_igd() and pci_pm_reset(). In reset_ivb_igd(), we return -ENOMEM if an ioremap() fails. That's not a case of "other reset mechanisms are broken and we shouldn't try them." pci_pm_reset() returns -EINVAL if the device is not in D0. Maybe it makes sense to not try any other reset methods in that case, but I really don't know. If we leave it as-is, maybe a comment like the following would be useful. diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index f0d68066c726..2c98f309bc8a 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -4170,6 +4170,13 @@ int __pci_reset_function_locked(struct pci_dev *dev) might_sleep(); + /* + * Reset method return values: + * 0: Device was successfully reset + * -ENOTTY: Method doesn't support resetting this device; + * try the next method + * anything else: Reset failed; don't try any other mechanisms + */ rc = pci_dev_specific_reset(dev, 0); if (rc != -ENOTTY) return rc;