All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ira Weiny <ira.weiny@intel.com>
To: Dan Williams <dan.j.williams@intel.com>,
	Bjorn Helgaas <helgaas@kernel.org>
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: Thu, 4 Jan 2024 13:46:56 -0800	[thread overview]
Message-ID: <6597275045fbf_267e82949d@iweiny-mobl.notmuch> (raw)
In-Reply-To: <65970003ee9ef_8dc6829412@dwillia2-xfh.jf.intel.com.notmuch>

Dan Williams wrote:
> Bjorn Helgaas wrote:
> [..]
> > > ---
> > > PCI: Introduce cleanup helpers for device reference counts and locks
> > > 
> > > The "goto error" pattern is notorious for introducing subtle resource
> > > leaks. Use the new cleanup.h helpers for PCI device reference counts and
> > > locks.
> > > 
> > > Similar to the new put_device() and device_lock() cleanup helpers,
> > > __free(put_device) and guard(device), define the same for PCI devices,
> > > __free(pci_dev_put) and guard(pci_dev).  These helpers eliminate the
> > > need for "goto free;" and "goto unlock;" patterns. For example, A
> > > 'struct pci_dev *' instance declared as:
> > > 
> > > 	struct pci_dev *pdev __free(pci_dev_put) = NULL;
> > 
> > I see several similar __free() uses with NULL initializations in gpio,
> > but I think this idiom would be slightly improved if the __free()
> > function were more closely associated with the actual pci_dev_get():
> > 
> >   struct pci_dev *pdev __free(pci_dev_put) = pci_get_device(...);
> > 
> > Not always possible, I know, but easier to analyze when it is.
> 
> I tend to agree, but it does lead to some long lines, for example:
> 
> diff --git a/drivers/cxl/pci.c b/drivers/cxl/pci.c
> index 4fd1f207c84e..549ba4b8294e 100644
> --- a/drivers/cxl/pci.c
> +++ b/drivers/cxl/pci.c
> @@ -975,15 +975,14 @@ static void cxl_cper_event_call(enum cxl_event_type ev_type,
>  				struct cxl_cper_event_rec *rec)
>  {
>  	struct cper_cxl_event_devid *device_id = &rec->hdr.device_id;
> -	struct pci_dev *pdev __free(pci_dev_put) = NULL;
>  	enum cxl_event_log_type log_type;
>  	struct cxl_dev_state *cxlds;
>  	unsigned int devfn;
>  	u32 hdr_flags;
>  
>  	devfn = PCI_DEVFN(device_id->device_num, device_id->func_num);
> -	pdev = pci_get_domain_bus_and_slot(device_id->segment_num,
> -					   device_id->bus_num, devfn);
> +	struct pci_dev *pdev __free(pci_dev_put) = pci_get_domain_bus_and_slot(
> +		device_id->segment_num, device_id->bus_num, devfn);
>  	if (!pdev)
>  		return;
>  
> ...so I think people are choosing the "... __free(x) = NULL;" style for
> code density readability.
> 

Also in this case we need devfn assigned first.

Is the above patch compliant with current style guidelines?

Or would it be better to do?

diff --git a/drivers/cxl/pci.c b/drivers/cxl/pci.c
index b14237f824cf..8a180c6abb67 100644
--- a/drivers/cxl/pci.c
+++ b/drivers/cxl/pci.c
@@ -975,15 +975,14 @@ static void cxl_cper_event_call(enum cxl_event_type ev_type,
                                struct cxl_cper_event_rec *rec)
 {
        struct cper_cxl_event_devid *device_id = &rec->hdr.device_id;
-       struct pci_dev *pdev __free(pci_dev_put) = NULL;
        enum cxl_event_log_type log_type;
        struct cxl_dev_state *cxlds;
-       unsigned int devfn;
+       unsigned int devfn = PCI_DEVFN(device_id->device_num, device_id->func_num);
+       struct pci_dev *pdev __free(pci_dev_put) = pci_get_domain_bus_and_slot(
+                                                       device_id->segment_num,
+                                                       device_id->bus_num, devfn);
        u32 hdr_flags;
 
-       devfn = PCI_DEVFN(device_id->device_num, device_id->func_num);
-       pdev = pci_get_domain_bus_and_slot(device_id->segment_num,
-                                          device_id->bus_num, devfn);
        if (!pdev)
                return;
 

Ira

  reply	other threads:[~2024-01-04 21:47 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
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 [this message]
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=6597275045fbf_267e82949d@iweiny-mobl.notmuch \
    --to=ira.weiny@intel.com \
    --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=helgaas@kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.