linux-acpi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sunil V L <sunilvl@ventanamicro.com>
To: Conor Dooley <conor@kernel.org>
Cc: Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	"Rafael J . Wysocki" <rafael@kernel.org>,
	Len Brown <lenb@kernel.org>, Thomas Gleixner <tglx@linutronix.de>,
	Marc Zyngier <maz@kernel.org>,
	Daniel Lezcano <daniel.lezcano@linaro.org>,
	Jonathan Corbet <corbet@lwn.net>,
	linux-riscv@lists.infradead.org, linux-acpi@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
	Anup Patel <apatel@ventanamicro.com>,
	Andrew Jones <ajones@ventanamicro.com>,
	Atish Patra <atishp@rivosinc.com>
Subject: Re: [PATCH 06/24] RISC-V: ACPI: Add PCI functions to build ACPI core
Date: Mon, 13 Feb 2023 20:53:01 +0530	[thread overview]
Message-ID: <Y+pV1aafHUNP6QfU@sunil-laptop> (raw)
In-Reply-To: <Y+QToXO2kYQ2ipdz@spud>

On Wed, Feb 08, 2023 at 09:26:57PM +0000, Conor Dooley wrote:
> On Mon, Jan 30, 2023 at 11:52:07PM +0530, Sunil V L wrote:
> > When CONFIG_PCI is enabled, ACPI core expects few arch
> > functions related to PCI. Add those functions so that
> > ACPI core gets build. These are levraged from arm64.
> > 
> > Signed-off-by: Sunil V L <sunilvl@ventanamicro.com>
> > ---
> >  arch/riscv/kernel/Makefile |   1 +
> >  arch/riscv/kernel/pci.c    | 173 +++++++++++++++++++++++++++++++++++++
> >  2 files changed, 174 insertions(+)
> >  create mode 100644 arch/riscv/kernel/pci.c
> 
> > diff --git a/arch/riscv/kernel/pci.c b/arch/riscv/kernel/pci.c
> > new file mode 100644
> > index 000000000000..3388af3a67a0
> > --- /dev/null
> > +++ b/arch/riscv/kernel/pci.c
> > @@ -0,0 +1,173 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Code borrowed from ARM64
> > + *
> > + * Copyright (C) 2003 Anton Blanchard <anton@au.ibm.com>, IBM
> > + * Copyright (C) 2014 ARM Ltd.
> > + * Copyright (C) 2022-2023 Ventana Micro System Inc.
> > + */
> > +
> > +#include <linux/acpi.h>
> > +#include <linux/init.h>
> > +#include <linux/io.h>
> > +#include <linux/kernel.h>
> > +#include <linux/mm.h>
> > +#include <linux/pci.h>
> > +#include <linux/pci-acpi.h>
> > +#include <linux/pci-ecam.h>
> > +
> > +#ifdef CONFIG_ACPI
> 
> Quickly checking against ARM64, they do not wrap the read/write
> functions in this ifdef, so why do we need to do so?
> 
I didn't find any callers other than ACPI. But let me keep them outside so
that we are consistent.

> > +/*
> > + * raw_pci_read/write - Platform-specific PCI config space access.
> > + */
> > +int raw_pci_read(unsigned int domain, unsigned int bus,
> > +		  unsigned int devfn, int reg, int len, u32 *val)
> > +{
> > +	struct pci_bus *b = pci_find_bus(domain, bus);
> > +
> > +	if (!b)
> > +		return PCIBIOS_DEVICE_NOT_FOUND;
> > +	return b->ops->read(b, devfn, reg, len, val);
> 
> A newline before the return would be appreciated by my eyes :)
> 
Okay.

> > +}
> > +
> > +int raw_pci_write(unsigned int domain, unsigned int bus,
> > +		unsigned int devfn, int reg, int len, u32 val)
> 
> Also, both read and write functions here appear to have incorrect
> alignment on the second lines.
> 
Okay.

> > +{
> > +	struct pci_bus *b = pci_find_bus(domain, bus);
> > +
> > +	if (!b)
> > +		return PCIBIOS_DEVICE_NOT_FOUND;
> > +	return b->ops->write(b, devfn, reg, len, val);
> > +}
> > +
> > +
> 
> Extra newline here too, looks to be exactly where you deleted the numa
> stuff from arm64 ;)
> 
Okay.

> > +struct acpi_pci_generic_root_info {
> > +	struct acpi_pci_root_info	common;
> > +	struct pci_config_window	*cfg;	/* config space mapping */
> > +};
> > +
> > +int acpi_pci_bus_find_domain_nr(struct pci_bus *bus)
> > +{
> > +	struct pci_config_window *cfg = bus->sysdata;
> > +	struct acpi_device *adev = to_acpi_device(cfg->parent);
> > +	struct acpi_pci_root *root = acpi_driver_data(adev);
> > +
> > +	return root->segment;
> > +}
> > +
> > +static int pci_acpi_root_prepare_resources(struct acpi_pci_root_info *ci)
> 
> Rhetorical question perhaps, but what does "ci" mean?
>
I don't know either :-). I guess since there is one more generic
ri, this is named as ci.

> > +{
> > +	struct resource_entry *entry, *tmp;
> > +	int status;
> > +
> > +	status = acpi_pci_probe_root_resources(ci);
> > +	resource_list_for_each_entry_safe(entry, tmp, &ci->resources) {
> > +		if (!(entry->res->flags & IORESOURCE_WINDOW))
> > +			resource_list_destroy_entry(entry);
> > +	}
> > +	return status;
> 
> Perhaps that extra newline from above could migrate down to the line
> above the return here.
>
Okay.

> > +}
> > +
> > +/*
> > + * Lookup the bus range for the domain in MCFG, and set up config space
> > + * mapping.
> > + */
> > +static struct pci_config_window *
> > +pci_acpi_setup_ecam_mapping(struct acpi_pci_root *root)
> 
> This all fits on 1 line.
> 
It actually goes beyond 80 characters, right?

> > +{
> > +	struct device *dev = &root->device->dev;
> > +	struct resource *bus_res = &root->secondary;
> > +	u16 seg = root->segment;
> > +	const struct pci_ecam_ops *ecam_ops;
> > +	struct resource cfgres;
> > +	struct acpi_device *adev;
> > +	struct pci_config_window *cfg;
> > +	int ret;
> > +
> > +	ret = pci_mcfg_lookup(root, &cfgres, &ecam_ops);
> > +	if (ret) {
> > +		dev_err(dev, "%04x:%pR ECAM region not found\n", seg, bus_res);
> > +		return NULL;
> > +	}
> > +
> > +	adev = acpi_resource_consumer(&cfgres);
> > +	if (adev)
> > +		dev_info(dev, "ECAM area %pR reserved by %s\n", &cfgres,
> > +			 dev_name(&adev->dev));
> > +	else
> > +		dev_warn(dev, FW_BUG "ECAM area %pR not reserved in ACPI namespace\n",
> > +			 &cfgres);
> > +
> > +	cfg = pci_ecam_create(dev, &cfgres, bus_res, ecam_ops);
> > +	if (IS_ERR(cfg)) {
> > +		dev_err(dev, "%04x:%pR error %ld mapping ECAM\n", seg, bus_res,
> > +			PTR_ERR(cfg));
> > +		return NULL;
> > +	}
> > +
> > +	return cfg;
> > +}
> > +
> > +/* release_info: free resources allocated by init_info */
> 
> The fact that you haven't picked a consistent comment style for this
> functions really bothers my OCD. Yes, it may be copy-paste from arm64,
> but since this is "new code" I don't think there's harm in at least
> *starting* with something that looks cohesive.
> 
Agree. Will try to fix them in the next revision.

> > +static void pci_acpi_generic_release_info(struct acpi_pci_root_info *ci)
> > +{
> > +	struct acpi_pci_generic_root_info *ri;
> > +
> > +	ri = container_of(ci, struct acpi_pci_generic_root_info, common);
> > +	pci_ecam_free(ri->cfg);
> > +	kfree(ci->ops);
> > +	kfree(ri);
> > +}
> > +
> > +
> 
> Extra newline here.
>
Okay.
 
> > +/* Interface called from ACPI code to setup PCI host controller */
> > +struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
> > +{
> > +	struct acpi_pci_generic_root_info *ri;
> > +	struct pci_bus *bus, *child;
> > +	struct acpi_pci_root_ops *root_ops;
> > +	struct pci_host_bridge *host;
> > +
> > +	ri = kzalloc(sizeof(*ri), GFP_KERNEL);
> > +	if (!ri)
> > +		return NULL;
> > +
> > +	root_ops = kzalloc(sizeof(*root_ops), GFP_KERNEL);
> > +	if (!root_ops) {
> > +		kfree(ri);
> > +		return NULL;
> > +	}
> > +
> > +	ri->cfg = pci_acpi_setup_ecam_mapping(root);
> > +	if (!ri->cfg) {
> > +		kfree(ri);
> > +		kfree(root_ops);
> > +		return NULL;
> > +	}
> > +
> > +	root_ops->release_info = pci_acpi_generic_release_info;
> > +	root_ops->prepare_resources = pci_acpi_root_prepare_resources;
> > +	root_ops->pci_ops = (struct pci_ops *)&ri->cfg->ops->pci_ops;
> > +	bus = acpi_pci_root_create(root, root_ops, &ri->common, ri->cfg);
> > +	if (!bus)
> > +		return NULL;
> > +
> > +	/* If we must preserve the resource configuration, claim now */
> > +	host = pci_find_host_bridge(bus);
> > +	if (host->preserve_config)
> > +		pci_bus_claim_resources(bus);
> > +
> > +	/*
> > +	 * Assign whatever was left unassigned. If we didn't claim above,
> > +	 * this will reassign everything.
> > +	 */
> > +	pci_assign_unassigned_root_bus_resources(bus);
> > +
> > +	list_for_each_entry(child, &bus->children, node)
> > +		pcie_bus_configure_settings(child);
> > +
> > +	return bus;
> > +}
> 
> Anyways, this does look to be "leveraged from arm64" as you say and I
> only had minor nits to comment about...
> Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
> 
Thanks!
Sunil

  reply	other threads:[~2023-02-13 15:23 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-30 18:22 [PATCH 00/24] Add basic ACPI support for RISC-V Sunil V L
2023-01-30 18:22 ` [PATCH 01/24] riscv: move sbi_init() earlier before jump_label_init() Sunil V L
2023-01-30 18:22 ` [PATCH 02/24] ACPICA: MADT: Add RISC-V INTC interrupt controller Sunil V L
2023-02-08 19:59   ` Conor Dooley
2023-02-13  5:13     ` Sunil V L
2023-01-30 18:22 ` [PATCH 03/24] ACPICA: Add structure definitions for RISC-V RHCT Sunil V L
2023-01-30 18:22 ` [PATCH 04/24] RISC-V: ACPI: Add empty headers to enable ACPI core Sunil V L
2023-02-08 19:55   ` Conor Dooley
2023-01-30 18:22 ` [PATCH 05/24] RISC-V: ACPI: Add basic functions to build " Sunil V L
2023-02-08 20:58   ` Conor Dooley
2023-02-13 15:16     ` Sunil V L
2023-01-30 18:22 ` [PATCH 06/24] RISC-V: ACPI: Add PCI " Sunil V L
2023-02-08 21:26   ` Conor Dooley
2023-02-13 15:23     ` Sunil V L [this message]
2023-02-13 17:14       ` Conor Dooley
2023-02-13 17:26   ` Jessica Clarke
2023-02-14  4:42     ` Sunil V L
2023-01-30 18:22 ` [PATCH 07/24] RISC-V: ACPI: Enable ACPI build infrastructure Sunil V L
2023-02-08 21:31   ` Conor Dooley
2023-02-13 15:23     ` Sunil V L
2023-01-30 18:22 ` [PATCH 08/24] ACPI: Enable ACPI_PROCESSOR for RISC-V Sunil V L
2023-01-30 18:22 ` [PATCH 09/24] ACPI: OSL: Make should_use_kmap() 0 " Sunil V L
2023-01-30 18:22 ` [PATCH 10/24] ACPI: processor_core: RISC-V: Enable mapping processor to the hartid Sunil V L
2023-01-30 18:22 ` [PATCH 11/24] RISC-V: ACPI: irqchip/riscv-intc: Add ACPI support Sunil V L
2023-01-30 23:38   ` Jessica Clarke
2023-01-31  9:11     ` Sunil V L
2023-02-08 21:49   ` Conor Dooley
2023-02-13 15:25     ` Sunil V L
2023-01-30 18:22 ` [PATCH 12/24] RISC-V: ACPI: smpboot: Create wrapper smp_setup() Sunil V L
2023-02-08 21:34   ` Conor Dooley
2023-01-30 18:22 ` [PATCH 13/24] RISC-V: ACPI: smpboot: Add ACPI support in smp_setup() Sunil V L
2023-02-08 22:10   ` Conor Dooley
2023-02-13 15:27     ` Sunil V L
2023-01-30 18:22 ` [PATCH 14/24] RISC-V: ACPI: smpboot: Add function to retrieve the hartid Sunil V L
2023-02-09 20:30   ` Conor Dooley
2023-02-13 17:00     ` Sunil V L
2023-01-30 18:22 ` [PATCH 15/24] clocksource/timer-riscv: Refactor riscv_timer_init_dt() Sunil V L
2023-02-09 20:54   ` Conor Dooley
2023-02-13 17:22     ` Sunil V L
2023-01-30 18:22 ` [PATCH 16/24] RISC-V: ACPI: clocksource/timer-riscv: Add ACPI support Sunil V L
2023-02-09 20:58   ` Conor Dooley
2023-02-13 17:39     ` Sunil V L
2023-01-30 18:22 ` [PATCH 17/24] ACPI: RISC-V: drivers/acpi: Add RHCT related code Sunil V L
2023-01-30 18:22 ` [PATCH 18/24] RISC-V: ACPI: time.c: Add ACPI support for time_init() Sunil V L
2023-01-30 18:22 ` [PATCH 19/24] RISC-V: ACPI: cpufeature: Add ACPI support in riscv_fill_hwcap() Sunil V L
2023-02-09 21:47   ` Conor Dooley
2023-02-13 17:51     ` Sunil V L
2023-01-30 18:22 ` [PATCH 20/24] RISC-V: ACPI: cpu: Enable cpuinfo for ACPI systems Sunil V L
2023-02-09 21:13   ` Conor Dooley
2023-02-13 17:42     ` Sunil V L
2023-01-30 18:22 ` [PATCH 21/24] RISC-V: ACPI: Add ACPI initialization in setup_arch() Sunil V L
2023-02-09 21:53   ` Conor Dooley
2023-02-13 17:52     ` Sunil V L
2023-01-30 18:22 ` [PATCH 22/24] RISC-V: ACPI: Enable ACPI in defconfig Sunil V L
2023-01-30 23:47   ` Conor Dooley
2023-01-31  8:41     ` Sunil V L
2023-01-30 18:22 ` [PATCH 23/24] MAINTAINERS: Add entry for drivers/acpi/riscv Sunil V L
2023-02-09 21:54   ` Conor Dooley
2023-02-13 17:53     ` Sunil V L
2023-01-30 18:22 ` [PATCH 24/24] Documentation/kernel-parameters.txt: Add RISC-V for ACPI parameter Sunil V L
2023-02-09  2:02   ` Bagas Sanjaya
2023-02-13 15:29     ` Sunil V L
2023-01-30 19:11 ` [PATCH 00/24] Add basic ACPI support for RISC-V Rafael J. Wysocki
2023-02-08 18:28 ` Conor Dooley
2023-02-08 18:50   ` Conor Dooley
2023-02-13  4:51     ` Sunil V L

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=Y+pV1aafHUNP6QfU@sunil-laptop \
    --to=sunilvl@ventanamicro.com \
    --cc=ajones@ventanamicro.com \
    --cc=aou@eecs.berkeley.edu \
    --cc=apatel@ventanamicro.com \
    --cc=atishp@rivosinc.com \
    --cc=conor@kernel.org \
    --cc=corbet@lwn.net \
    --cc=daniel.lezcano@linaro.org \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=maz@kernel.org \
    --cc=palmer@dabbelt.com \
    --cc=rafael@kernel.org \
    --cc=tglx@linutronix.de \
    /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).