public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
	Ira Weiny <ira.weiny@intel.com>,
	Jonathan Cameron <jonathan.cameron@huawei.com>,
	Smita Koralahalli <Smita.KoralahalliChannabasappa@amd.com>,
	Shiju Jose <shiju.jose@huawei.com>,
	Yazen Ghannam <yazen.ghannam@amd.com>,
	Davidlohr Bueso <dave@stgolabs.net>,
	Dave Jiang <dave.jiang@intel.com>,
	Alison Schofield <alison.schofield@intel.com>,
	Vishal Verma <vishal.l.verma@intel.com>,
	Ard Biesheuvel <ardb@kernel.org>,
	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
Date: Wed, 3 Jan 2024 17:01:47 -0600	[thread overview]
Message-ID: <20240103230147.GA1800245@bhelgaas> (raw)
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
> > 
> 
> 

  reply	other threads:[~2024-01-03 23:01 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-21  0:17 [PATCH v5 0/9] efi/cxl-cper: Report CPER CXL component events through trace events Ira Weiny
2023-12-21  0:17 ` [PATCH v5 1/9] cxl/trace: Pass uuid explicitly to event traces Ira Weiny
2024-01-08 12:56   ` Jonathan Cameron
2023-12-21  0:17 ` [PATCH v5 2/9] cxl/events: Promote CXL event structures to a core header Ira Weiny
2024-01-08 13:05   ` Jonathan Cameron
2023-12-21  0:17 ` [PATCH v5 3/9] cxl/events: Create common event UUID defines Ira Weiny
2024-01-08 13:07   ` Jonathan Cameron
2023-12-21  0:17 ` [PATCH v5 4/9] cxl/events: Remove passing a UUID to known event traces Ira Weiny
2024-01-08 13:23   ` Jonathan Cameron
2024-01-09 23:38     ` Dan Williams
2024-01-10 14:22       ` Jonathan Cameron
2023-12-21  0:17 ` [PATCH v5 5/9] cxl/events: Separate UUID from event structures Ira Weiny
2024-01-08 13:27   ` Jonathan Cameron
2023-12-21  0:17 ` [PATCH v5 6/9] cxl/events: Create a CXL event union Ira Weiny
2024-01-08 13:31   ` Jonathan Cameron
2023-12-21  0:17 ` [PATCH v5 7/9] acpi/ghes: Process CXL Component Events Ira Weiny
2024-01-08 13:41   ` Jonathan Cameron
2023-12-21  0:17 ` [PATCH v5 8/9] PCI: Define scoped based management functions Ira Weiny
2024-01-03 22:38   ` Dan Williams
2024-01-03 23:01     ` Bjorn Helgaas [this message]
2024-01-04  0:21       ` Dan Williams
2024-01-04 17:17         ` Ira Weiny
2024-01-04 18:32         ` Bjorn Helgaas
2024-01-04 18:59           ` Dan Williams
2024-01-04 21:46             ` Ira Weiny
2024-01-04 22:37               ` Bjorn Helgaas
2024-01-04 23:00                 ` Ira Weiny
2024-01-04  6:05   ` Lukas Wunner
2024-01-04  6:43     ` Dan Williams
2024-01-04  7:02       ` Lukas Wunner
2024-01-04  7:37         ` Ard Biesheuvel
2024-01-04 17:41           ` Dan Williams
2024-01-08 13:44   ` Jonathan Cameron
2023-12-21  0:17 ` [PATCH v5 9/9] cxl/pci: Register for and process CPER events Ira Weiny
2024-01-02 15:14   ` Smita Koralahalli
2024-01-02 20:29     ` Ira Weiny
2024-01-03 22:08   ` Dan Williams
2024-01-04 18:31   ` Ira Weiny
2024-01-08 13:50   ` Jonathan Cameron
2024-01-09 23:59     ` Dan Williams
2024-01-04 22:55 ` [PATCH v5 0/9] efi/cxl-cper: Report CPER CXL component events through trace events Bjorn Helgaas
2024-01-08 16:58 ` Jonathan Cameron
2024-01-08 20:04   ` Smita Koralahalli
2024-01-09  2:08     ` Dan Williams
2024-01-09  2:32       ` Ira Weiny
2024-01-09  2:59         ` Dan Williams
2024-01-09 16:04           ` Jonathan Cameron
2024-01-09 20:49             ` Dan Williams
2024-01-09 23:30               ` Dan Williams
2024-01-09 23:31                 ` Ard Biesheuvel
2024-01-10 14:24                   ` Jonathan Cameron

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240103230147.GA1800245@bhelgaas \
    --to=helgaas@kernel.org \
    --cc=Smita.KoralahalliChannabasappa@amd.com \
    --cc=alison.schofield@intel.com \
    --cc=ardb@kernel.org \
    --cc=bhelgaas@google.com \
    --cc=dan.j.williams@intel.com \
    --cc=dave.jiang@intel.com \
    --cc=dave@stgolabs.net \
    --cc=ira.weiny@intel.com \
    --cc=jonathan.cameron@huawei.com \
    --cc=linux-cxl@vger.kernel.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=shiju.jose@huawei.com \
    --cc=vishal.l.verma@intel.com \
    --cc=yazen.ghannam@amd.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox