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: 10027303 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 35DA26032C for ; Wed, 25 Oct 2017 22:11:19 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 2558D28649 for ; Wed, 25 Oct 2017 22:11:19 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 174DC289FD; Wed, 25 Oct 2017 22:11:19 +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=-4.2 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_MED autolearn=unavailable version=3.3.1 Received: from bombadil.infradead.org (bombadil.infradead.org [65.50.211.133]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 9B37928649 for ; Wed, 25 Oct 2017 22:11:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.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:References: 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: List-Owner; bh=peg8ePYTUhA3279CCbWeofw6sJdSBQohdpgBxMHhq6U=; b=Jxuq4H1hg8uGb+ 2DiQq046JbJ3RuneDlNwtqQId5N/bn8ud856/XoLtq+2BHRF3Kfnad6PLtPo/NdzvMCwjb+rsyoq9 7onvM1NIDhlk5DMtVz1GidGG5KrUMPqZhWEcmLZIeRBVRIR7NSjKc8SUuVzSdSYZ/5g7DZCFyFiAj 1AHOspaZYX1dpRQpk1fp3UQG8RUWguuJ83OIS5yj1EwFBX3SQdjnOJSuNWu61mOnEpi2Mpi/hL3Do /wcEw9vfbgaFQua1AbxTUtddkPpRA38LydiX2nVEWYSgy4sTE7prM8zGvJs+cQ0YmKCFso3xO2O7A zfygZbWJAN3iwd4vCF+w==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux)) id 1e7TtI-0001Cu-Hx; Wed, 25 Oct 2017 22:11:12 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux)) id 1e7TtE-0001C2-Oh for linux-arm-kernel@lists.infradead.org; Wed, 25 Oct 2017 22:11:11 +0000 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 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) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20171025_151108_850309_4C2E5C2D X-CRM114-Status: GOOD ( 24.41 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-pci@vger.kernel.org, timur@codeaurora.org, linux-kernel@vger.kernel.org, Sinan Kaya , linux-arm-msm@vger.kernel.org, Bjorn Helgaas , linux-arm-kernel@lists.infradead.org Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.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;