Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp2240159imm; Sat, 30 Jun 2018 14:32:38 -0700 (PDT) X-Google-Smtp-Source: ADUXVKLIlTdVfEvhoj7aXdoN18SGZLASc9/PuUkhk5A2acFecFLYebLvNd7zFNAZ3hXCYGqbpGDK X-Received: by 2002:a17:902:5a0c:: with SMTP id q12-v6mr19879431pli.300.1530394358780; Sat, 30 Jun 2018 14:32:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530394358; cv=none; d=google.com; s=arc-20160816; b=R3/PJfR2SCmw8EeprfxkXG2X3/z+3MZH6MCQjZ75chsELrw1gor9m4Ws36wNqZgfVB U98tC+8c9CZ5CmuJOPhzXx8TjyuZky4aYmeVLb+6rrYWpCaHRJmoBaYU/u8lN9ZyTS6R aElwSVTsuZ8s+/9pNuXGapIkFXPbpRlCplRzwTCzZ5WQCwhVznGQNiS+9jdUUjzhj9np dtDvhOU+e7QR+sPVcHIhDqQQAic7fM5da1g8pZX1ExbJ90DJU7OgtGVVTr55yfHUIy6H Xf47eUet+F4dJl40drAY9xMvId+GMZ48kSSXBDttG7ehfQ4ABK6aqlF/yJVR8cqmz8c5 UuAA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=xenoksQcCysJ9di+4RsjnDcniiN1VGHR65h6TDhAnOo=; b=xggnVwEEeVpJ43KPKbWErWsl+rM0jjcXwBvQ+y3xRlpgFqMcTpZfoGUgTYMzNyVc5a Aw0CVCzlg4PqiZy/ni8nXXPqgBow6/RPHaTWzlTNDH6R2uGN06mk0qJMLUrs5lKe4hBw 432LLDETDFjcjmy1mFXepWdnZvEWHnbGKSKUQxX72AVGtoKsm8noTSKLg1WVA6ki+uu3 LRaCw5Z1356so4wXcp1zyMsEZsHmF3IlAZDieZ0bR1ud6rmqck1YT/+BGLKSxb+0+est UqGNhoxYARCxdLYiZXBmPewtuJ7xXYVkaPNimrzHkkpJ4jvWxCvv3TP0JXTratdGtZ4j QVvQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=Rg6M9fBg; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h1-v6si11740957pfn.285.2018.06.30.14.32.24; Sat, 30 Jun 2018 14:32:38 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=Rg6M9fBg; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751879AbeF3Vbo (ORCPT + 99 others); Sat, 30 Jun 2018 17:31:44 -0400 Received: from mail.kernel.org ([198.145.29.99]:35994 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751486AbeF3Vbm (ORCPT ); Sat, 30 Jun 2018 17:31:42 -0400 Received: from localhost (unknown [69.71.4.100]) (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 BED6324094; Sat, 30 Jun 2018 21:31:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1530394302; bh=aV5Ioz4+RwQU5/5Xf4M7DQbDJ7Jo8Z5z+38CO5PwwHw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Rg6M9fBgIjYOLyOuupS0NJrkjcn175ZiGfo8P9IRKaV91RcuTugps4wtwEEfMGpo4 iwj6YfDR6kCwD/67gNu8v8eJjZ0jM71gWsEkjdrrAMY25oVScdIgY3DxJxVuaeDY4H V2pglhEvzduZqBzhEXokbnUXN9D86qjMlhaJFdbk= Date: Sat, 30 Jun 2018 16:31:40 -0500 From: Bjorn Helgaas To: Alexandru Gagniuc Cc: bhelgaas@google.com, keith.busch@intel.com, alex_gagniuc@dellteam.com, austin_bolen@dell.com, shyam_iyer@dell.com, Frederick Lawler , Greg Kroah-Hartman , Oza Pawandeep , linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, Borislav Petkov Subject: Re: [PATCH v2] PCI/AER: Fix aerdrv loading with "pcie_ports=native" parameter Message-ID: <20180630213140.GG9547@bhelgaas-glaptop.roam.corp.google.com> References: <20180619195835.5423-1-mr.nuke.me@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180619195835.5423-1-mr.nuke.me@gmail.com> User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [+cc Borislav, linux-acpi, since this involves APEI/HEST] On Tue, Jun 19, 2018 at 02:58:20PM -0500, Alexandru Gagniuc wrote: > According to the documentation, "pcie_ports=native", linux should use > native AER and DPC services. While that is true for the _OSC method > parsing, this is not the only place that is checked. Should the HEST > table list PCIe ports as firmware-first, linux will not use native > services. Nothing in ACPI-land looks at pcie_ports_native. How should ACPI things work in the "pcie_ports=native" case? I guess we still have to expect to receive error records from the firmware, because it may certainly send us non-PCI errors (machine checks, etc) and maybe even some PCI errors (even if the Linux AER driver claims AER interrupts, we don't know what notification mechanisms the firmware may be using). I guess best-case, we'll get ACPI error records for all non-PCI things, and the Linux AER driver will see all the AER errors. Worst-case, I don't really know what to expect. Duplicate reporting of AER errors via firmware and Linux AER driver? Some kind of confusion about who acknowledges and clears them? Out of curiosity, what is your use case for "pcie_ports=native"? Presumably there's something that works better when using it, and things work even *better* with this patch? I know people do use it, because I often see it mentioned in forums and bug reports, but I really don't expect it to work very well because we're ignoring the usage model the firmware is designed around. My unproven suspicion is that most uses are in the black magic category of "there's a bug here, and we don't know how to fix it, but pcie_ports=native makes it work better". Obviously I would much rather find and fix those bugs so people wouldn't have to stumble over the problem in the first place. > This happens because aer_acpi_firmware_first() doesn't take > 'pcie_ports' into account. This is wrong. DPC uses the same logic when > it decides whether to load or not, so fixing this also fixes DPC not > loading. > > Signed-off-by: Alexandru Gagniuc > --- > drivers/pci/pcie/aer.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > Changes since v1: > - Re-tested with latest and greatest (v4.18-rc1) -- works great > > diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c > index a2e88386af28..98ced0f7c850 100644 > --- a/drivers/pci/pcie/aer.c > +++ b/drivers/pci/pcie/aer.c > @@ -291,7 +291,7 @@ static void aer_set_firmware_first(struct pci_dev *pci_dev) > > rc = apei_hest_parse(aer_hest_parse, &info); > > - if (rc) > + if (rc || pcie_ports_native) > pci_dev->__aer_firmware_first = 0; > else > pci_dev->__aer_firmware_first = info.firmware_first; > @@ -327,6 +327,9 @@ bool aer_acpi_firmware_first(void) > apei_hest_parse(aer_hest_parse, &info); > aer_firmware_first = info.firmware_first; > parsed = true; > + if (pcie_ports_native) > + aer_firmware_first = 0; > + > } > return aer_firmware_first; > } > -- > 2.14.3 >