Received: by 2002:a05:6358:45e:b0:b5:b6eb:e1f9 with SMTP id 30csp4436925rwe; Tue, 30 Aug 2022 10:03:14 -0700 (PDT) X-Google-Smtp-Source: AA6agR4rogvw4ekqo+2Mw8w0ZZqKWovLtvmNCLQaM8gGPih7SRMtt5DcFetsR3fqYrHvzJO9nzxb X-Received: by 2002:a17:90b:3149:b0:1fd:dcbb:918f with SMTP id ip9-20020a17090b314900b001fddcbb918fmr9406557pjb.18.1661878994374; Tue, 30 Aug 2022 10:03:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1661878994; cv=none; d=google.com; s=arc-20160816; b=rHKVAsjWK732K3EoNchuDSZyKcet7KKxNmCwnoQuYPt3e0kRFCEvAVQsu5UUfQRqm6 BuXahDYrStxajSyduQ4fGTyP2G92Y5HZuqiRkB04MXTyzPMr6aK5QQmzkAZq/kipzEIx CQ/9xLE9Jmrv2CgP+4BzlFv7UHnzOmdLncS6GEAX7U0MSAGJprJaWtA2MS77HJIVRQJI G14hEYN8dV7GhyERL0V24Y/XqaR2e2k/yy11kZYQmLmdBRS0/pYNAK0GtcuRtt4KB3Ed uXbcTQAD81dZJvKT6vecsv94OHDWiqZLN1FIuQ6W9c8XGpMftKeBHQPmyaG4OvyVAOOE JdtQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version; bh=QwTPzippv9nFknfyh2bt7Km8y3L5Y24/vUQnMoNu/zw=; b=B57xsOfBrsiJ5fFysm2U/ZyP5XpU2bRWCzKu3bN2ua9Y2LzW+yQYSL1glE5BuiLAc8 od8Bsx1lY3A+VhYY7OEcAqa4AFV/4hTdouFPmvlftcwJ4aWMlboYHEecgyXfcdlMq1tS oEEyAm0Zq6VwDeyAQ/4iTZN7mTk/un2Od/z2wILUHXWEYmly+LrHJXuXouIxJLGA04S2 ShWwCKTQ3MXMEWI/XOXQJKFlBsu/CzcmitP1kHoNG2qgqEp5bgZgxDV7mS6D1iwAnvU8 F7W7xMVAmNxTzTXvS7qmF/9d1iVRo60lfMBpjWmmVMhPGKaNBr2SsAgjRFSblBuXP2s2 ix9g== ARC-Authentication-Results: i=1; mx.google.com; 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 q12-20020a170902f78c00b001747a322a2csi9070421pln.262.2022.08.30.10.02.57; Tue, 30 Aug 2022 10:03:14 -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; 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 S230388AbiH3Q6i (ORCPT + 99 others); Tue, 30 Aug 2022 12:58:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52108 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230398AbiH3Q6e (ORCPT ); Tue, 30 Aug 2022 12:58:34 -0400 Received: from mail-yb1-f172.google.com (mail-yb1-f172.google.com [209.85.219.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EF7C7B69CF; Tue, 30 Aug 2022 09:58:32 -0700 (PDT) Received: by mail-yb1-f172.google.com with SMTP id y197so429553yby.13; Tue, 30 Aug 2022 09:58:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=QwTPzippv9nFknfyh2bt7Km8y3L5Y24/vUQnMoNu/zw=; b=YNFZdZlfGNc4/e4qpIJTi5d6fY7hVg48oZmQDZtG5s+2/z0yJ3pZ4+so8DeQYRW8Sn BwSlmDSAxC+4XjuaXHuo1Rw8SAWjcD9M9HKmL2qyDP+9NuHDzAZ8QDYkt+Pc/pXJvwFI 1+T86dhJ/SCBOMZoXjk+uuFp3DziusujNuC/jQ3qTVTjyEk92flJJZumR7NblpR+7aq1 qoJ/zP6c5oSfJEFtR1fRNUxqmY/cwCz3wZ4Uz7IbgpqtqeKpiYETxTOmcvvB2uzDJT4g QtEW//LmL602bc1CB69l7qXL09HnMn81uSyPWg1lXSUzBCAsGaSioEi3S2MAcpZlQkyp R+Lg== X-Gm-Message-State: ACgBeo0zhRqtKo2z77viDhLANW2zzJwsSjkdpvzHu1SgFHBlczSbAUmd JS+zM8HlTVdJjbJnnPZNps8CAqaWxfQjWZYq/vw= X-Received: by 2002:a25:664f:0:b0:66c:d0f4:36cc with SMTP id z15-20020a25664f000000b0066cd0f436ccmr12426812ybm.482.1661878711809; Tue, 30 Aug 2022 09:58:31 -0700 (PDT) MIME-Version: 1.0 References: <20220830104913.1620539-2-rajvi.jingar@linux.intel.com> <20220830162529.GA106073@bhelgaas> In-Reply-To: <20220830162529.GA106073@bhelgaas> From: "Rafael J. Wysocki" Date: Tue, 30 Aug 2022 18:58:20 +0200 Message-ID: Subject: Re: [RESEND PATCH v3 2/2] PCI/PTM: fix to maintain pci_dev->ptm_enabled To: Bjorn Helgaas Cc: Rajvi Jingar , Rafael Wysocki , Bjorn Helgaas , David Box , Linux PCI , Linux Kernel Mailing List , Linux PM , Kai-Heng Feng Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=no 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 Tue, Aug 30, 2022 at 6:25 PM Bjorn Helgaas wrote: > > [+cc Kai-Heng] > > On Tue, Aug 30, 2022 at 03:49:13AM -0700, Rajvi Jingar wrote: > > pci_dev->ptm_enabled needs to be maintained to reflect the current PTM > > state of the device. In pci_ptm_disable(), clear ptm_enabled from > > 'struct pci_dev' on disabling PTM state for the device. > > In pci_restore_ptm_state(), set dev->ptm_enabled based on the restored > > PTM state of the device. > > > > In pci_ptm_disable(), perform ptm_enabled check to avoid config space > > access in case if PTM is already disabled for the device. ptm_enabled > > won't be set for non-PCIe devices so pci_is_pcie(dev) check is not > > needed anymore. > > This one sounds like it's supposed to fix something, but I'm not clear > exactly what. > > I have a vague memory of config accesses messing up a low power state. > But this is still completely magical and unmaintainable since AFAIK > there is nothing in the PCIe spec about avoiding config accesses when > PTM is disabled. Because ptm_enabled is expected to always reflect the hardware state, pci_disable_ptm() needs to be amended to clear it. Also it is prudent to explicitly make it reflect the new hardware state in pci_restore_ptm_state(). Then, pci_disable_ptm() can be made bail out if ptm_enabled is clear, because it has nothing to do then and the pci_is_pcie() check in there is not necessary, because ptm_enabled will never be set for devices that are not PCIe. > At the very least, we would need more details in the commit log and > a hint in the code about this. > > > Signed-off-by: Rajvi Jingar > > Reviewed-by: Rafael J. Wysocki > > --- > > v1->v2: > > - add ptm_enabled check in pci_ptm_disable(). > > - set the dev->ptm_enabled value in pci_restore_ptm_state(). > > v2->v3: > > - remove pci_is_pcie(dev) check in pci_ptm_disable(). > > - add Reviewed-by tag in commit message > > --- > > drivers/pci/pcie/ptm.c | 4 +++- > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/pci/pcie/ptm.c b/drivers/pci/pcie/ptm.c > > index 368a254e3124..1ce241d4538f 100644 > > --- a/drivers/pci/pcie/ptm.c > > +++ b/drivers/pci/pcie/ptm.c > > @@ -34,7 +34,7 @@ void pci_disable_ptm(struct pci_dev *dev) > > int ptm; > > u16 ctrl; > > > > - if (!pci_is_pcie(dev)) > > + if (!dev->ptm_enabled) > > return; > > This will conflict with a change Kai-Heng Feng and I have been working > on, but I can resolve it when applying. > > > ptm = pci_find_ext_capability(dev, PCI_EXT_CAP_ID_PTM); > > @@ -44,6 +44,7 @@ void pci_disable_ptm(struct pci_dev *dev) > > pci_read_config_word(dev, ptm + PCI_PTM_CTRL, &ctrl); > > ctrl &= ~(PCI_PTM_CTRL_ENABLE | PCI_PTM_CTRL_ROOT); > > pci_write_config_word(dev, ptm + PCI_PTM_CTRL, ctrl); > > + dev->ptm_enabled = 0; > > } > > > > void pci_save_ptm_state(struct pci_dev *dev) > > @@ -83,6 +84,7 @@ void pci_restore_ptm_state(struct pci_dev *dev) > > > > cap = (u16 *)&save_state->cap.data[0]; > > pci_write_config_word(dev, ptm + PCI_PTM_CTRL, *cap); > > + dev->ptm_enabled = !!(*cap & PCI_PTM_CTRL_ENABLE); > > } > > > > void pci_ptm_init(struct pci_dev *dev) > > -- > > 2.25.1 > >