From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BAD68ECE58E for ; Tue, 8 Oct 2019 09:28:06 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8F3D221929 for ; Tue, 8 Oct 2019 09:28:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1570526886; bh=o4JjrPE/C/7wBUmbzIV+mumH6nlKKYLQ31Y152eTPxM=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=vrGHYWbFyaMn4CF0B0cHHSLwXspySFrkGBPbW6CEOZD/rjNVxpIqKzOSJAnsA/0Sh 2wVRe0i0aFXkVbTaNmW/VySeEmAjdEQrNT813lEU0B9DwBmGuNgFoOQsKojNxCTqc+ b9L1wBhQ0m9HlSHmXZhvXp3ODV8IerX+Omizy5zg= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730093AbfJHJ2F (ORCPT ); Tue, 8 Oct 2019 05:28:05 -0400 Received: from mail-ot1-f66.google.com ([209.85.210.66]:41441 "EHLO mail-ot1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729624AbfJHJ2F (ORCPT ); Tue, 8 Oct 2019 05:28:05 -0400 Received: by mail-ot1-f66.google.com with SMTP id g13so13456005otp.8; Tue, 08 Oct 2019 02:28:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QKKY+n0fqxvornYxomfHtDCFFUAFeT4prYVwRJVInPM=; b=ckY+zNExIcUC5NBoOi2JKR9eIikARZcuG92gDxOfzx1zts/euVMNQnLPCRrMvePtP+ BmCK5G3edgMkC4rtHWGidd8P8AIMDxauNtNoEQz1VpcuGsH1FkxWzn/bi+tahuGrYRVU HFN8t9qyoVdVm31Byif4xyjoNspGCdO+169HC6WNhkKDxjNO+IIl4SCrGzrKUYBOwzQq T/k/KQzonObASrwnHnr9vdw8vw3RUl8EGxp74gW/eFrEIo8rFMHTelUd0uz0xHbpQJM3 /UT2s0mqzY4krZrk0NtgGP/LQ06PqsK/AbzC+foD0Z4rv/1qoeT+VTIGcZzoicb8nta9 KPSw== X-Gm-Message-State: APjAAAXCyXopY+au3ZExm7O6xW+PDMIZe6GGC9S/MogsQeiObdkeXm4d RGUrxDOC/6eADp4hYXSl4xwFOtbIcZGEA++2O68= X-Google-Smtp-Source: APXvYqwQBIjj/f9VAfJwpHSCImUUYHgrpGtnMscXEcYAppVnL05e8hrF/hWaXl6pQAYZTJGneIWYEkNVNtdguXb8Mqg= X-Received: by 2002:a9d:664:: with SMTP id 91mr3454984otn.189.1570526882896; Tue, 08 Oct 2019 02:28:02 -0700 (PDT) MIME-Version: 1.0 References: <1618955.HVa0YQSOW5@kreacher> <20191007223428.GA72605@google.com> In-Reply-To: <20191007223428.GA72605@google.com> From: "Rafael J. Wysocki" Date: Tue, 8 Oct 2019 11:27:51 +0200 Message-ID: Subject: Re: [PATCH v3 1/2] PCI: PCIe: ASPM: Introduce pcie_aspm_enabled() To: Bjorn Helgaas Cc: "Rafael J. Wysocki" , linux-nvme , Keith Busch , Mario Limonciello , Kai-Heng Feng , Keith Busch , Christoph Hellwig , Sagi Grimberg , Linux PM , Linux Kernel Mailing List , Rajat Jain , Linux PCI , Heiner Kallweit Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 8, 2019 at 12:34 AM Bjorn Helgaas wrote: > > [+cc Heiner] > > On Thu, Aug 08, 2019 at 11:55:07PM +0200, Rafael J. Wysocki wrote: > > From: Rafael J. Wysocki > > > > Add a function checking whether or not PCIe ASPM has been enabled for > > a given device. > > > > It will be used by the NVMe driver to decide how to handle the > > device during system suspend. > > > > Signed-off-by: Rafael J. Wysocki > > --- > > > > v2 -> v3: > > * Make the new function return bool. > > * Change its name back to pcie_aspm_enabled(). > > * Fix kerneldoc comment formatting. > > > > -> v2: > > * Move the PCI/PCIe ASPM changes to a separate patch. > > * Add the _mask suffix to the new function name. > > * Add EXPORT_SYMBOL_GPL() to the new function. > > * Avoid adding an unnecessary blank line. > > > > --- > > drivers/pci/pcie/aspm.c | 20 ++++++++++++++++++++ > > include/linux/pci.h | 3 +++ > > 2 files changed, 23 insertions(+) > > > > Index: linux-pm/drivers/pci/pcie/aspm.c > > =================================================================== > > --- linux-pm.orig/drivers/pci/pcie/aspm.c > > +++ linux-pm/drivers/pci/pcie/aspm.c > > @@ -1170,6 +1170,26 @@ static int pcie_aspm_get_policy(char *bu > > module_param_call(policy, pcie_aspm_set_policy, pcie_aspm_get_policy, > > NULL, 0644); > > > > +/** > > + * pcie_aspm_enabled - Check if PCIe ASPM has been enabled for a device. > > + * @pci_device: Target device. > > + */ > > +bool pcie_aspm_enabled(struct pci_dev *pci_device) > > +{ > > + struct pci_dev *bridge = pci_upstream_bridge(pci_device); > > + bool ret; > > + > > + if (!bridge) > > + return false; > > + > > + mutex_lock(&aspm_lock); > > + ret = bridge->link_state ? !!bridge->link_state->aspm_enabled : false; > > + mutex_unlock(&aspm_lock); > > Why do we need to acquire aspm_lock here? We aren't modifying > anything, and I don't think we're preventing a race. If this races > with another thread that changes aspm_enabled, we'll return either the > old state or the new one, and I think that's still the case even if we > don't acquire aspm_lock. Well, if we can guarantee that pci_remove_bus_device() will never be called in parallel with this helper, then I agree, but can we guarantee that?