linux-efi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: Smita Koralahalli <Smita.KoralahalliChannabasappa@amd.com>
Cc: <linux-efi@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<linux-cxl@vger.kernel.org>, Ard Biesheuvel <ardb@kernel.org>,
	"Alison Schofield" <alison.schofield@intel.com>,
	Vishal Verma <vishal.l.verma@intel.com>,
	Ira Weiny <ira.weiny@intel.com>,
	Dan Williams <dan.j.williams@intel.com>,
	Yazen Ghannam <yazen.ghannam@amd.com>,
	"Bowman Terry" <terry.bowman@amd.com>
Subject: Re: [PATCH 4/4] cxl/pci: Define a common function get_cxl_dev()
Date: Fri, 7 Jun 2024 16:40:49 +0100	[thread overview]
Message-ID: <20240607164049.0000564f@Huawei.com> (raw)
In-Reply-To: <20240522150839.27578-5-Smita.KoralahalliChannabasappa@amd.com>

On Wed, 22 May 2024 15:08:39 +0000
Smita Koralahalli <Smita.KoralahalliChannabasappa@amd.com> wrote:

> Refactor computation of cxlds to a common function get_cxl_dev() and reuse
> the function in both cxl_handle_cper_event() and cxl_handle_prot_err().
> 
> Signed-off-by: Smita Koralahalli <Smita.KoralahalliChannabasappa@amd.com>
> ---
>  drivers/cxl/pci.c | 52 +++++++++++++++++++++++------------------------
>  1 file changed, 26 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/cxl/pci.c b/drivers/cxl/pci.c
> index 3e3c36983686..26e65e5b68cb 100644
> --- a/drivers/cxl/pci.c
> +++ b/drivers/cxl/pci.c
> @@ -974,32 +974,43 @@ static struct pci_driver cxl_pci_driver = {
>  	},
>  };
>  
> +static struct cxl_dev_state *get_cxl_dev(u16 segment, u8 bus, u8 device,
> +					 u8 function)
I'd not expect a function with this name to return anything other
than a struct device *
get_cxl_devstate() maybe?

> +{
> +	struct pci_dev *pdev __free(pci_dev_put) = NULL;
> +	struct cxl_dev_state *cxlds;
> +	unsigned int devfn;
> +
> +	devfn = PCI_DEVFN(device, function);
Might as well do
	unsigned int devfn = PCI_DEVFN(device, function);

> +	pdev = pci_get_domain_bus_and_slot(segment, bus, devfn);

	struct pci_dev *pdev __free(pci_dev_put) =
		pci_get_domain_bus_and_slot(segment, bus, devfn);

see fwctl thread for a reference to Linus expressing a preference for
keeping construct and destructor definitions together even when
that means relaxing c conventions that we are so used to!

Obviously this is copied from below, but might as well tidy it up
whilst here.

However, do the devfn change above and it is in the definitions block...




> +
> +	if (!pdev)
> +		return NULL;
> +
> +	guard(device)(&pdev->dev);
> +	if (pdev->driver != &cxl_pci_driver)
> +		return NULL;
> +
> +	cxlds = pci_get_drvdata(pdev);
> +
> +	return cxlds;
return pci_get_drvdata(pdev);

I think the function is small enough having cxlds just so it's obvious
what is being returned is unnecessary.
> +}
> +
>  #define CXL_EVENT_HDR_FLAGS_REC_SEVERITY GENMASK(1, 0)
>  static void cxl_handle_cper_event(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;
>  
>  	pr_debug("CPER event %d for device %u:%u:%u.%u\n", ev_type,
>  		 device_id->segment_num, device_id->bus_num,
>  		 device_id->device_num, device_id->func_num);
>  
> -	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;
> -
> -	guard(device)(&pdev->dev);
> -	if (pdev->driver != &cxl_pci_driver)
> -		return;
> -
> -	cxlds = pci_get_drvdata(pdev);
> +	cxlds = get_cxl_dev(device_id->segment_num, device_id->bus_num,
> +			    device_id->device_num, device_id->func_num);
>  	if (!cxlds)
>  		return;
>  
> @@ -1013,21 +1024,10 @@ static void cxl_handle_cper_event(enum cxl_event_type ev_type,
>  
>  static void cxl_handle_prot_err(struct cxl_cper_prot_err *p_err)
>  {
> -	struct pci_dev *pdev __free(pci_dev_put) = NULL;
>  	struct cxl_dev_state *cxlds;
> -	unsigned int devfn;
>  
> -	devfn = PCI_DEVFN(p_err->device, p_err->function);
> -	pdev = pci_get_domain_bus_and_slot(p_err->segment,
> -					   p_err->bus, devfn);
> -	if (!pdev)
> -		return;
> -
> -	guard(device)(&pdev->dev);
> -	if (pdev->driver != &cxl_pci_driver)
> -		return;
> -
> -	cxlds = pci_get_drvdata(pdev);
> +	cxlds = get_cxl_dev(p_err->segment, p_err->bus,
> +			    p_err->device, p_err->function);
>  	if (!cxlds)
>  		return;
>  


      parent reply	other threads:[~2024-06-07 15:40 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-22 15:08 [PATCH 0/4] acpi/ghes, cper, cxl: Trace FW-First CXL Protocol Errors Smita Koralahalli
2024-05-22 15:08 ` [PATCH 1/4] efi/cper, cxl: Make definitions and structures global Smita Koralahalli
2024-05-22 17:28   ` Dave Jiang
2024-05-22 23:40   ` Alison Schofield
2024-06-07 15:14   ` Jonathan Cameron
2024-06-10 18:31     ` Smita Koralahalli
2024-05-22 15:08 ` [PATCH 2/4] acpi/ghes, efi/cper: Recognize and process CXL Protocol Errors Smita Koralahalli
2024-05-22 17:59   ` Dave Jiang
2024-05-23 21:19     ` Smita Koralahalli
2024-05-23 22:51       ` Dave Jiang
2024-05-23  0:03   ` Alison Schofield
2024-05-23 21:21     ` Smita Koralahalli
2024-06-07 15:26       ` Jonathan Cameron
2024-06-10 19:07         ` Smita Koralahalli
2024-05-22 15:08 ` [PATCH 3/4] acpi/ghes, cxl/pci: Trace FW-First " Smita Koralahalli
2024-05-22 18:05   ` Dave Jiang
2024-05-23  4:38     ` Alison Schofield
2024-05-23 21:23     ` Smita Koralahalli
2024-05-23  0:22   ` Alison Schofield
2024-05-23 21:35     ` Smita Koralahalli
2024-06-12  0:07   ` Dan Williams
2024-06-13 17:47     ` Smita Koralahalli
2024-06-24 22:04       ` Smita Koralahalli
2024-05-22 15:08 ` [PATCH 4/4] cxl/pci: Define a common function get_cxl_dev() Smita Koralahalli
2024-05-22 19:42   ` Dave Jiang
2024-05-23 21:37     ` Smita Koralahalli
2024-05-23  0:45   ` Alison Schofield
2024-06-07 15:40   ` Jonathan Cameron [this message]

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=20240607164049.0000564f@Huawei.com \
    --to=jonathan.cameron@huawei.com \
    --cc=Smita.KoralahalliChannabasappa@amd.com \
    --cc=alison.schofield@intel.com \
    --cc=ardb@kernel.org \
    --cc=dan.j.williams@intel.com \
    --cc=ira.weiny@intel.com \
    --cc=linux-cxl@vger.kernel.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=terry.bowman@amd.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;
as well as URLs for NNTP newsgroup(s).