Received: by 2002:ac8:156:0:b0:3e0:cd10:60c8 with SMTP id f22csp117197qtg; Thu, 6 Apr 2023 14:12:30 -0700 (PDT) X-Google-Smtp-Source: AKy350bFkh4qQOoFV6OtfMczMzAvd4uOkDKjvSEyfYpOoyP41nzGJDPNJkLWfstdU4nwIFuEvMgq X-Received: by 2002:a05:6a20:4ca3:b0:d9:dbb6:2e67 with SMTP id fq35-20020a056a204ca300b000d9dbb62e67mr821266pzb.31.1680815549987; Thu, 06 Apr 2023 14:12:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1680815549; cv=none; d=google.com; s=arc-20160816; b=BjhCBj2xS43iSLAJzwXf9Y6ry8ZEuzfGoFI9oCgtntfY2Z8wGyE68QjI4R5A7xdwwI GahISlTVHVFV77AIDO83S8jppOPOKrTUd4QmYnxqQMYOzdwnQZo590oIGE0/qYqukQyV gxVbBTCYpj2AgdSqo++yHXvxx0o2ggG7yKwAuq95noEidgz6Zzr/OPgs0Y2oD0j14N3t LUTy3f4TDGkc1L02aKsyNaZiojf+3/uwEspV36I0tdGjAK3CXz2YV0DzcubjvbnO9Puw Aa5yvbGO5bDLRNpJS+oZZQOXLMZzAeC/gOpMrTeyq2+2h5qK4NjELRAex2E972UGWp6Q i4nw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:message-id:subject:cc:to:from:date :dkim-signature; bh=/yRxrtQ+aEuaznMHHGfVW8QS2xXG63U9gvM7JkE++uc=; b=UpsAGZi85exp1p/LdlP3P6mV/dpvW+vh7ryDcLcLiyifA5OvM+w8qb2/blFK6yK1mR 7h2LDjkeJtJvvVSvS7e8otRD09af6evEhOY5WfRX+1HqqcxjEm+L4o9BSiGUtUSsM1HN ubHdvZZFK9kPEcFgMycmu1ffa9KkOZigpy1o/0LqcgSvkUDlK3yodCBHv4SBiSY4YqEf dwN78PIJIoC8SkJ3bxVQj8GBADENwiIEBXe3qO6wp/G0hVPrktWEzoGxe435p3Wa/Vhh mDeYOQa85sDXUX03zG+3G93r/KrgfeQ7z5A2m+HwFhXuyBiJhAGa8uncvmUlVKN1BxKn Gx8Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=V7eOYvv+; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id i62-20020a638741000000b004fd10490f3dsi2158288pge.251.2023.04.06.14.12.18; Thu, 06 Apr 2023 14:12:29 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=V7eOYvv+; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 S238738AbjDFVIA (ORCPT + 99 others); Thu, 6 Apr 2023 17:08:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36770 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240181AbjDFVHo (ORCPT ); Thu, 6 Apr 2023 17:07:44 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E12E07683; Thu, 6 Apr 2023 14:07:24 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 7B8C064CB6; Thu, 6 Apr 2023 21:07:24 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A71EBC433D2; Thu, 6 Apr 2023 21:07:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1680815243; bh=8o09ePc36Ij55cMUJKfcEw4yEArsEF1zRPWn37E0t4U=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=V7eOYvv+KF/5rTFMKF7zuUFsCyJcROELAP1MFStTnS9t8HPv0KJKl/flsDeMEH+zR +l15xKbGdIJRY6up+rp6YMGN0LFavYC1t1D23c+LMAvc1Ts0uQZLOwiJPFoppsx/aR /C/bHulCIOrlvS1Ogdt2WOeBFJOYKmJ4TXj6BBghZXQKI3xG2QfM8i6jm1BD5VM7vo 0VdbSltR2WEHpWUp6s3BjeWMLIUa7Xyq5bC5wo02w64u9DMQp0K1y5yACMu/bhPXY9 84LZfMmXWYUuRNdJcKICCTIYniFSkBrqETJIZHojDbsW0ylESUAaQnyGO3nfZGM+8i wopze1cT975Ew== Date: Thu, 6 Apr 2023 16:07:22 -0500 From: Bjorn Helgaas To: Kuppuswamy Sathyanarayanan Cc: Bjorn Helgaas , linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] PCI/EDR: Clear PCIe Device Status errors after EDR error recovery Message-ID: <20230406210722.GA3735581@bhelgaas> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20230315235449.1279209-1-sathyanarayanan.kuppuswamy@linux.intel.com> X-Spam-Status: No, score=-5.2 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI,SPF_HELO_NONE, SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 15, 2023 at 04:54:49PM -0700, Kuppuswamy Sathyanarayanan wrote: > Commit 068c29a248b6 ("PCI/ERR: Clear PCIe Device Status errors only if > OS owns AER") adds support to clear error status in the Device Status > Register(DEVSTA) only if OS owns the AER support. But this change > breaks the requirement of the EDR feature which requires OS to cleanup > the error registers even if firmware owns the control of AER support. > > More details about this requirement can be found in PCIe Firmware > specification v3.3, Table 4-6 Interpretation of the _OSC Control Field. > If the OS supports the Error Disconnect Recover (EDR) feature and > firmware sends the EDR event, then during the EDR recovery window, OS > is responsible for the device error recovery and holds the ownership of > the following error registers. > > • Device Status Register > • Uncorrectable Error Status Register > • Correctable Error Status Register > • Root Error Status Register > • RP PIO Status Register > > So call pcie_clear_device_status() in edr_handle_event() if the error > recovery is successful. > > Reported-by: Tsaur Erwin > Signed-off-by: Kuppuswamy Sathyanarayanan > --- > > Changes since v1: > * Rebased on top of v6.3-rc1. > * Fixed a typo in pcie_clear_device_status(). > > drivers/pci/pcie/edr.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/pci/pcie/edr.c b/drivers/pci/pcie/edr.c > index a6b9b479b97a..87734e4c3c20 100644 > --- a/drivers/pci/pcie/edr.c > +++ b/drivers/pci/pcie/edr.c > @@ -193,6 +193,7 @@ static void edr_handle_event(acpi_handle handle, u32 event, void *data) > */ > if (estate == PCI_ERS_RESULT_RECOVERED) { > pci_dbg(edev, "DPC port successfully recovered\n"); > + pcie_clear_device_status(edev); > acpi_send_edr_status(pdev, edev, EDR_OST_SUCCESS); The implementation note in PCI Firmware r3.3, sec 4.6.12, shows the OS clearing error status *after* _OST is evaluated. On the other hand, the _OSC DPC control bit in table 4-6 says that if the OS does not have DPC control, it can only write the Device Status error bits between the EDR Notify and invoking _OST. Is one of those wrong, or am I missing something? Bjorn