Received: by 2002:a05:7412:b995:b0:f9:9502:5bb8 with SMTP id it21csp7399036rdb; Wed, 3 Jan 2024 15:01:58 -0800 (PST) X-Google-Smtp-Source: AGHT+IFP2lISgq/mNUJ08iU3smTY14j++ophjW+MNVI3d8Kxkz6XuuJePRiTTKrDnVrVDJlPqFWe X-Received: by 2002:ac8:5c81:0:b0:428:1bcb:a591 with SMTP id r1-20020ac85c81000000b004281bcba591mr4731803qta.133.1704322917850; Wed, 03 Jan 2024 15:01:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1704322917; cv=none; d=google.com; s=arc-20160816; b=V465F5PHuHL8LdbUtsf0MwWSVQCHP44XwXjQaY0oGftZeM4Jnf9LldYT1+EaMKO9vx d2at4JJRbnpIdKwPgYAWtIfcqbkpaP9L10v2Yo61KIoSuqKIR/d0LaYZxlTtr8buuXGe GQf2ZtOiBBp1d4fiQ+ukDfppmIJcQC3rYAEnxHhQ9O51AyLQ/B+rASsVC/cPAbI9ZPxL ZInQkn4WVRYOfXstCxPOT8oKxMbMBnLhBMNtNbfUOzNF9w5nOb5s0P0ceFWhXYv+OWxE 8FyD2GRfgLu+wbTZ1B0UxcPSR+fSgHSJ2RFUtHb9/hGUApm4D6gvksx1zRa9rEekWwd1 nbMw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-disposition:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:subject:cc:to:from :date:dkim-signature; bh=59agtt3Wvm27moVgJ8meEYacagAhihV1T7yiDy5A/hQ=; fh=Ev8HE+5BIP02ab0WpFNqXhsy+Ki4lBu8+SSdVE4CH9Q=; b=lspZc3JLl9jcZ2KITf/RBwjxFXOmJBtB08tT90Bcf30WYAl9u4xBhg5KG/gpPH8bYc osPd/29TcrDMhPwL7qiGGRkmMTTaQvmxvB/lbVjsAfLb3462vGdEbuOLaAAPOj7vc4eC VPfj6bWi1AXJrrEZH3f49n5YZp3tJl24h84uPiwZLuCMMkg/Hkd5R4HVYjHdFdTNezuA fXYcEVB3+yr0ap0rAEC2lpNGGLS8+8UaY7529TlOpoiFvkEGQIfZsXp9svQZyA8DrO4q vtnqwpvM1gSq7yAa9+yOIO0Ecb14KGFUWEuSHWAY+XhkpArcvBhxhYsxHX5IgODGc7Yu wJTA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=DZdPlows; spf=pass (google.com: domain of linux-kernel+bounces-16094-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-16094-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [2604:1380:45d1:ec00::1]) by mx.google.com with ESMTPS id i15-20020ac85c0f000000b0042839f5ec52si1857391qti.192.2024.01.03.15.01.57 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Jan 2024 15:01:57 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-16094-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=DZdPlows; spf=pass (google.com: domain of linux-kernel+bounces-16094-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-16094-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 964F21C247D1 for ; Wed, 3 Jan 2024 23:01:57 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 25AC91EB3C; Wed, 3 Jan 2024 23:01:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="DZdPlows" X-Original-To: linux-kernel@vger.kernel.org Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4B7B71DDE6; Wed, 3 Jan 2024 23:01:48 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8206CC433C8; Wed, 3 Jan 2024 23:01:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1704322908; bh=KIH/kxO3N+Os8WnlfgT8ax5cLQr2L2egFhTNUTO9ulM=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=DZdPlowsvov65k9D9B7URnlt/esrBDhGSXzmr1P9ZWAwPs+/H1c/EPu0KEyLY/HRh 6nMx1exvU9cDAYxxaizA6aWe1qDoSkQ2BqCMihwE8TYJlo5NaR0P76L/3YWR/IKCdS veCzh7tt+ap5HD5kiol177H/c/CKLj81MliYcGuC8dECuJXm8j3rrafk5VJyLY1GWP Krn65x7Zn3P4LjzMlj3+lvcw2DWKl8it1zXgPjNlqJPGXmMYy2CpoAKFewm/sNQPkw EwEElxDMBD0Mcw0QIEY4FoVgzi6kDkBcM1xGWLt8I/emXyXrIc0S1B7JiZxgP+eesW HmNykZHFR4+bQ== Date: Wed, 3 Jan 2024 17:01:47 -0600 From: Bjorn Helgaas To: Dan Williams Cc: Bjorn Helgaas , Ira Weiny , Jonathan Cameron , Smita Koralahalli , Shiju Jose , Yazen Ghannam , Davidlohr Bueso , Dave Jiang , Alison Schofield , Vishal Verma , Ard Biesheuvel , linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org, linux-cxl@vger.kernel.org, linux-pci@vger.kernel.org Subject: Re: [PATCH v5 8/9] PCI: Define scoped based management functions Message-ID: <20240103230147.GA1800245@bhelgaas> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6595e201beb4_be7022944d@dwillia2-xfh.jf.intel.com.notmuch> On Wed, Jan 03, 2024 at 02:38:57PM -0800, Dan Williams wrote: > Ira Weiny wrote: > > Users of pci_dev_get() can benefit from a scoped based put. Also, > > locking a PCI device is often done within a single scope. > > > > Define a pci_dev_put() free function and a PCI device lock guard. These > > will initially be used in new CXL event processing code but is defined > > in a separate patch for others to pickup and use/backport easier. > > Any heartburn if I take this through cxl.git with the rest in this > series? Patch 9 has a dependency on this one. No real heartburn. I was trying to figure out what this does since I'm not familiar with the "scoped based put" idea and 'git grep -i "scope.*base"' wasn't much help. I would kind of like the commit log to say a little more about what the "scoped based put" (does that have too many past tenses in it?) means and how users of pci_dev_get() will benefit. I don't know what "locking a PCI device is often done within a single scope" is trying to tell me either. What if it's *not* done within a single scope? Does this change anything for callers of pci_dev_get() and pci_dev_put()? Does this avoid a common programming error? I just don't know what the benefit of this is yet. I'm sure this is really cool stuff, but there's little documentation, few existing users, and I don't know what I need to look for when reviewing things. > > --- a/include/linux/pci.h > > +++ b/include/linux/pci.h > > @@ -1170,6 +1170,7 @@ int pci_get_interrupt_pin(struct pci_dev *dev, struct pci_dev **bridge); > > u8 pci_common_swizzle(struct pci_dev *dev, u8 *pinp); > > struct pci_dev *pci_dev_get(struct pci_dev *dev); > > void pci_dev_put(struct pci_dev *dev); > > +DEFINE_FREE(pci_dev_put, struct pci_dev *, if (_T) pci_dev_put(_T)) > > void pci_remove_bus(struct pci_bus *b); > > void pci_stop_and_remove_bus_device(struct pci_dev *dev); > > void pci_stop_and_remove_bus_device_locked(struct pci_dev *dev); > > @@ -1871,6 +1872,7 @@ void pci_cfg_access_unlock(struct pci_dev *dev); > > void pci_dev_lock(struct pci_dev *dev); > > int pci_dev_trylock(struct pci_dev *dev); > > void pci_dev_unlock(struct pci_dev *dev); > > +DEFINE_GUARD(pci_dev, struct pci_dev *, pci_dev_lock(_T), pci_dev_unlock(_T)) > > > > /* > > * PCI domain support. Sometimes called PCI segment (eg by ACPI), > > > > -- > > 2.43.0 > > > >