All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Sinan Kaya <okaya@kernel.org>
Cc: linux-acpi@vger.kernel.org,
	"open list:PCI SUBSYSTEM" <linux-pci@vger.kernel.org>,
	open list <linux-kernel@vger.kernel.org>,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Robin Murphy <robin.murphy@arm.com>,
	Logan Gunthorpe <logang@deltatee.com>
Subject: Re: [PATCH v9 6/6] PCI: Stub out pci_request_acs() when CONFIG_PCI is not set
Date: Fri, 14 Dec 2018 16:26:01 -0600	[thread overview]
Message-ID: <20181214222601.GH20725@google.com> (raw)
In-Reply-To: <20181214163319.27479-7-okaya@kernel.org>

[+cc Lorenzo, Robin, Logan]

On Fri, Dec 14, 2018 at 04:33:19PM +0000, Sinan Kaya wrote:
> ACPI IORT table code relies on pci_request_acs() to be present. Define
> a stub function when CONFI_PCI is not set.

This doesn't seem like the simplest approach to me, but I probably
don't understand what's going on in IORT.

It looks like *all* of iort_enable_acs() (the caller of
pci_request_acs()) is PCI-specific; at least, the whole thing is
wrapped in a test for ACPI_IORT_NODE_PCI_ROOT_COMPLEX.  So the whole
function could be wrapped in #ifdef CONFIG_PCI.

Here's the caller of iort_enable_acs():

  iort_init_platform_devices
    acs_enabled = false
    for (i = 0; i < iort->node_count; i++) {
      if (!acs_enabled)
        acs_enabled = iort_enable_acs(iort_node);

It seems like the acs_enabled state could be encapsulated inside
iort_enable_acs().

Today pci_request_acs() is a system-wide thing, but I don't know why
that's the case.  Isn't it conceivable that different PCI hierarchies
could have different ACS policies, e.g., because of P2P DMA or
something?

Bottom line, pci_request_acs() is being called from what looks like
PCI-specific code in IORT, and it would make more sense to me to prune
out that code in IORT than to make a stub pci_request_acs().

> Signed-off-by: Sinan Kaya <okaya@kernel.org>
> ---
>  include/linux/pci.h | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 51a5a5217667..f0f2f55ea93c 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -2101,7 +2101,11 @@ static inline struct pci_dev *pcie_find_root_port(struct pci_dev *dev)
>  	return NULL;
>  }
>  
> +#ifdef CONFIG_PCI
>  void pci_request_acs(void);
> +#else
> +static inline void pci_request_acs(void) {}
> +#endif
>  bool pci_acs_enabled(struct pci_dev *pdev, u16 acs_flags);
>  bool pci_acs_path_enabled(struct pci_dev *start,
>  			  struct pci_dev *end, u16 acs_flags);
> -- 
> 2.19.0
> 

  reply	other threads:[~2018-12-14 22:26 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20181214163319.27479-1-okaya@kernel.org>
2018-12-14 16:33 ` [PATCH v9 1/6] ACPI: Allow CONFIG_PCI to be unset for reboot Sinan Kaya
2018-12-14 16:33   ` Sinan Kaya
2018-12-14 16:33 ` [PATCH v9 2/6] ACPI / OSL: Stub out acpi_os_(read/write)_pci_configurations() Sinan Kaya
2018-12-14 16:33   ` Sinan Kaya
2018-12-14 16:33 ` [PATCH v9 3/6] PCI/ACPI: Allow ACPI to be built without CONFIG_PCI set Sinan Kaya
2018-12-14 16:33   ` Sinan Kaya
2018-12-14 21:52   ` Bjorn Helgaas
2018-12-14 21:52     ` Bjorn Helgaas
2018-12-14 16:33 ` [PATCH v9 4/6] ACPICA: Remove PCI bits from ACPICA when CONFIG_PCI is unset Sinan Kaya
2018-12-14 16:33   ` Sinan Kaya
2018-12-14 16:33 ` [PATCH v9 5/6] arm64: select ACPI PCI code only both features are enabled Sinan Kaya
2018-12-14 16:33   ` Sinan Kaya
2018-12-14 16:33   ` Sinan Kaya
2018-12-14 16:33 ` [PATCH v9 6/6] PCI: Stub out pci_request_acs() when CONFIG_PCI is not set Sinan Kaya
2018-12-14 16:33   ` Sinan Kaya
2018-12-14 22:26   ` Bjorn Helgaas [this message]
2018-12-14 23:33     ` Robin Murphy

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=20181214222601.GH20725@google.com \
    --to=helgaas@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=logang@deltatee.com \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=okaya@kernel.org \
    --cc=robin.murphy@arm.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.