All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Amey Narkhede <ameynarkhede03@gmail.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
	alex.williamson@redhat.com,
	Raphael Norwitz <raphael.norwitz@nutanix.com>,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	kw@linux.com, Shanker Donthineni <sdonthineni@nvidia.com>,
	Sinan Kaya <okaya@kernel.org>, Len Brown <lenb@kernel.org>,
	"Rafael J . Wysocki" <rjw@rjwysocki.net>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Mika Westerberg <mika.westerberg@linux.intel.com>
Subject: Re: [PATCH v15 7/9] PCI: Setup ACPI fwnode early and at the same time with OF
Date: Fri, 13 Aug 2021 18:04:28 -0500	[thread overview]
Message-ID: <20210813230428.GA2745285@bjorn-Precision-5520> (raw)
In-Reply-To: <20210805162917.3989-8-ameynarkhede03@gmail.com>

[+cc Ben, Mika]

On Thu, Aug 05, 2021 at 09:59:15PM +0530, Amey Narkhede wrote:
> From: Shanker Donthineni <sdonthineni@nvidia.com>
> 
> The pci_dev objects are created through two mechanisms 1) during PCI
> bus scan and 2) from I/O Virtualization. The fwnode in pci_dev object
> is being set at different places depends on the type of firmware used,
> device creation mechanism, and acpi_pci_bridge_d3().
> 
> The software features which have a dependency on ACPI fwnode properties
> and need to be handled before device_add() will not work. One use case,
> the software has to check the existence of _RST method to support ACPI
> based reset method.
> 
> This patch does the two changes in order to provide fwnode consistently.
>  - Set ACPI and OF fwnodes from pci_setup_device().
>  - Remove pci_set_acpi_fwnode() in acpi_pci_bridge_d3().
> 
> After this patch, ACPI/OF firmware properties are visible at the same
> time during the early stage of pci_dev setup. And also call sites should
> be able to use firmware agnostic functions device_property_xxx() for the
> early PCI quirks in the future.
> 
> Signed-off-by: Shanker Donthineni <sdonthineni@nvidia.com>
> Reviewed-by: Alex Williamson <alex.williamson@redhat.com>
> ---
>  drivers/pci/pci-acpi.c | 1 -
>  drivers/pci/probe.c    | 7 ++++---
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/pci/pci-acpi.c b/drivers/pci/pci-acpi.c
> index eaddbf701759..dae021322b3f 100644
> --- a/drivers/pci/pci-acpi.c
> +++ b/drivers/pci/pci-acpi.c
> @@ -952,7 +952,6 @@ static bool acpi_pci_bridge_d3(struct pci_dev *dev)
>  		return false;
>  
>  	/* Assume D3 support if the bridge is power-manageable by ACPI. */
> -	pci_set_acpi_fwnode(dev);
>  	adev = ACPI_COMPANION(&dev->dev);

I *think* the Root Port code farther down in this function is also now
unnecessary:

  acpi_pci_bridge_d3(...)
  {
    ...
    root = pcie_find_root_port(dev);
    adev = ACPI_COMPANION(&root->dev);
    if (root == dev) {
      /*
       * It is possible that the ACPI companion is not yet bound
       * for the root port so look it up manually here.
       */
      if (!adev && !pci_dev_is_added(root))
        adev = acpi_pci_find_companion(&root->dev);
    }

Since we're now setting the ACPI_COMPANION for every pci_dev long
before we get here, I think this could now be simplified to something
like this:

  acpi_pci_bridge_d3(...)
  {
    if (!dev->is_hotplug_bridge)
      return false;

    adev = ACPI_COMPANION(&dev->dev);
    if (adev && acpi_device_power_manageable(adev))
      return true;

    root = pcie_find_root_port(dev);
    if (!root)
      return false;

    adev = ACPI_COMPANION(&root->dev);
    if (!adev)
      return false;

    rc = acpi_dev_get_property(dev, "HotPlugSupportInD3",
                               ACPI_TYPE_INTEGER, &val);
    if (rc < 0)
      return false;

    return val == 1;
  }

acpi_pci_bridge_d3() was added by 26ad34d510a8 ("PCI / ACPI: Whitelist
D3 for more PCIe hotplug ports") [1], so I cc'd Mika in case he has
any comment.

>  	if (adev && acpi_device_power_manageable(adev))
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index 379e85037d9b..15a6975d3757 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -1789,6 +1789,9 @@ int pci_setup_device(struct pci_dev *dev)
>  	dev->error_state = pci_channel_io_normal;
>  	set_pcie_port_type(dev);
>  
> +	pci_set_of_node(dev);
> +	pci_set_acpi_fwnode(dev);

Is there a reason why you moved pci_set_of_node() from
pci_scan_device() to here?  I think it's a good change; I'm just
curious if you tripped over something that required it.

The pci_set_of_node() was added to pci_scan_device() by 98d9f30c820d
("pci/of: Match PCI devices to OF nodes dynamically") [2], so I cc'd
Ben just in case there's some reason he didn't put it in
pci_setup_device() in the first place.

>  	pci_dev_assign_slot(dev);
>  
>  	/*
> @@ -1924,6 +1927,7 @@ int pci_setup_device(struct pci_dev *dev)
>  	default:				    /* unknown header */
>  		pci_err(dev, "unknown header type %02x, ignoring device\n",
>  			dev->hdr_type);
> +		pci_release_of_node(dev);
>  		return -EIO;
>  
>  	bad:
> @@ -2351,10 +2355,7 @@ static struct pci_dev *pci_scan_device(struct pci_bus *bus, int devfn)
>  	dev->vendor = l & 0xffff;
>  	dev->device = (l >> 16) & 0xffff;
>  
> -	pci_set_of_node(dev);
> -
>  	if (pci_setup_device(dev)) {
> -		pci_release_of_node(dev);
>  		pci_bus_put(dev->bus);
>  		kfree(dev);
>  		return NULL;

[1] https://git.kernel.org/linus/26ad34d510a8
[2] https://git.kernel.org/linus/98d9f30c820d

  reply	other threads:[~2021-08-13 23:04 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-05 16:29 [PATCH v15 0/9] PCI: Expose and manage PCI device reset Amey Narkhede
2021-08-05 16:29 ` [PATCH v15 1/9] PCI: Cache PCIe FLR capability Amey Narkhede
2021-08-09 11:13   ` Raphael Norwitz
2021-08-05 16:29 ` [PATCH v15 2/9] PCI: Add pcie_reset_flr to follow calling convention of other reset methods Amey Narkhede
2021-08-09 11:15   ` Raphael Norwitz
2021-08-05 16:29 ` [PATCH v15 3/9] PCI: Add new array for keeping track of ordering of " Amey Narkhede
2021-08-09 11:18   ` Raphael Norwitz
2021-08-05 16:29 ` [PATCH v15 4/9] PCI: Remove reset_fn field from pci_dev Amey Narkhede
2021-08-05 16:29 ` [PATCH v15 5/9] PCI: Allow userspace to query and set device reset mechanism Amey Narkhede
2021-08-09 11:23   ` Raphael Norwitz
2021-08-05 16:29 ` [PATCH v15 6/9] PCI: Define a function to set ACPI_COMPANION in pci_dev Amey Narkhede
2021-08-05 16:29 ` [PATCH v15 7/9] PCI: Setup ACPI fwnode early and at the same time with OF Amey Narkhede
2021-08-13 23:04   ` Bjorn Helgaas [this message]
2021-08-14  3:35     ` Shanker R Donthineni
2021-08-14  4:10       ` Bjorn Helgaas
2021-08-14 16:16         ` Shanker R Donthineni
2021-08-16 17:07           ` Bjorn Helgaas
2021-08-05 16:29 ` [PATCH v15 8/9] PCI: Add support for ACPI _RST reset method Amey Narkhede
2021-08-05 16:29 ` [PATCH v15 9/9] PCI: Change the type of probe argument in reset functions Amey Narkhede
2021-08-14 14:05   ` Shanker R Donthineni
2021-08-12 13:03 ` [PATCH v15 0/9] PCI: Expose and manage PCI device reset Shanker R Donthineni

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=20210813230428.GA2745285@bjorn-Precision-5520 \
    --to=helgaas@kernel.org \
    --cc=alex.williamson@redhat.com \
    --cc=ameynarkhede03@gmail.com \
    --cc=benh@kernel.crashing.org \
    --cc=bhelgaas@google.com \
    --cc=kw@linux.com \
    --cc=lenb@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mika.westerberg@linux.intel.com \
    --cc=okaya@kernel.org \
    --cc=raphael.norwitz@nutanix.com \
    --cc=rjw@rjwysocki.net \
    --cc=sdonthineni@nvidia.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.