From: Conor Dooley <conor@kernel.org>
To: Sunil V L <sunilvl@ventanamicro.com>
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: Wed, 8 Feb 2023 21:26:57 +0000 [thread overview]
Message-ID: <Y+QToXO2kYQ2ipdz@spud> (raw)
In-Reply-To: <20230130182225.2471414-7-sunilvl@ventanamicro.com>
[-- Attachment #1: Type: text/plain, Size: 6736 bytes --]
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?
> +/*
> + * 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 :)
> +}
> +
> +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.
> +{
> + 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 ;)
> +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?
> +{
> + 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.
> +}
> +
> +/*
> + * 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.
> +{
> + 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.
> +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.
> +/* 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>
Cheers,
Conor.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Conor Dooley <conor@kernel.org>
To: Sunil V L <sunilvl@ventanamicro.com>
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: Wed, 8 Feb 2023 21:26:57 +0000 [thread overview]
Message-ID: <Y+QToXO2kYQ2ipdz@spud> (raw)
In-Reply-To: <20230130182225.2471414-7-sunilvl@ventanamicro.com>
[-- Attachment #1.1: Type: text/plain, Size: 6736 bytes --]
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?
> +/*
> + * 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 :)
> +}
> +
> +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.
> +{
> + 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 ;)
> +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?
> +{
> + 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.
> +}
> +
> +/*
> + * 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.
> +{
> + 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.
> +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.
> +/* 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>
Cheers,
Conor.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 161 bytes --]
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2023-02-08 21:27 UTC|newest]
Thread overview: 132+ 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 ` 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 ` Sunil V L
2023-01-30 18:22 ` [PATCH 02/24] ACPICA: MADT: Add RISC-V INTC interrupt controller Sunil V L
2023-01-30 18:22 ` Sunil V L
2023-02-08 19:59 ` Conor Dooley
2023-02-08 19:59 ` Conor Dooley
2023-02-13 5:13 ` Sunil V L
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 ` 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-01-30 18:22 ` Sunil V L
2023-02-08 19:55 ` Conor Dooley
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-01-30 18:22 ` Sunil V L
2023-02-08 20:58 ` Conor Dooley
2023-02-08 20:58 ` Conor Dooley
2023-02-13 15:16 ` Sunil V L
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-01-30 18:22 ` Sunil V L
2023-02-08 21:26 ` Conor Dooley [this message]
2023-02-08 21:26 ` Conor Dooley
2023-02-13 15:23 ` Sunil V L
2023-02-13 15:23 ` Sunil V L
2023-02-13 17:14 ` Conor Dooley
2023-02-13 17:14 ` Conor Dooley
2023-02-13 17:26 ` Jessica Clarke
2023-02-13 17:26 ` Jessica Clarke
2023-02-14 4:42 ` Sunil V L
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-01-30 18:22 ` Sunil V L
2023-02-08 21:31 ` Conor Dooley
2023-02-08 21:31 ` Conor Dooley
2023-02-13 15:23 ` Sunil V L
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 ` 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 ` 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 ` 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 18:22 ` Sunil V L
2023-01-30 23:38 ` Jessica Clarke
2023-01-30 23:38 ` Jessica Clarke
2023-01-31 9:11 ` Sunil V L
2023-01-31 9:11 ` Sunil V L
2023-02-08 21:49 ` Conor Dooley
2023-02-08 21:49 ` Conor Dooley
2023-02-13 15:25 ` Sunil V L
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-01-30 18:22 ` Sunil V L
2023-02-08 21:34 ` Conor Dooley
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-01-30 18:22 ` Sunil V L
2023-02-08 22:10 ` Conor Dooley
2023-02-08 22:10 ` Conor Dooley
2023-02-13 15:27 ` Sunil V L
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-01-30 18:22 ` Sunil V L
2023-02-09 20:30 ` Conor Dooley
2023-02-09 20:30 ` Conor Dooley
2023-02-13 17:00 ` Sunil V L
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-01-30 18:22 ` Sunil V L
2023-02-09 20:54 ` Conor Dooley
2023-02-09 20:54 ` Conor Dooley
2023-02-13 17:22 ` Sunil V L
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-01-30 18:22 ` Sunil V L
2023-02-09 20:58 ` Conor Dooley
2023-02-09 20:58 ` Conor Dooley
2023-02-13 17:39 ` Sunil V L
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 ` 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 ` 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-01-30 18:22 ` Sunil V L
2023-02-09 21:47 ` Conor Dooley
2023-02-09 21:47 ` Conor Dooley
2023-02-13 17:51 ` Sunil V L
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-01-30 18:22 ` Sunil V L
2023-02-09 21:13 ` Conor Dooley
2023-02-09 21:13 ` Conor Dooley
2023-02-13 17:42 ` Sunil V L
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-01-30 18:22 ` Sunil V L
2023-02-09 21:53 ` Conor Dooley
2023-02-09 21:53 ` Conor Dooley
2023-02-13 17:52 ` Sunil V L
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 18:22 ` Sunil V L
2023-01-30 23:47 ` Conor Dooley
2023-01-30 23:47 ` Conor Dooley
2023-01-31 8:41 ` Sunil V L
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-01-30 18:22 ` Sunil V L
2023-02-09 21:54 ` Conor Dooley
2023-02-09 21:54 ` Conor Dooley
2023-02-13 17:53 ` Sunil V L
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-01-30 18:22 ` Sunil V L
2023-02-09 2:02 ` Bagas Sanjaya
2023-02-09 2:02 ` Bagas Sanjaya
2023-02-13 15:29 ` Sunil V L
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-01-30 19:11 ` Rafael J. Wysocki
2023-02-08 18:28 ` Conor Dooley
2023-02-08 18:28 ` Conor Dooley
2023-02-08 18:50 ` Conor Dooley
2023-02-08 18:50 ` Conor Dooley
2023-02-13 4:51 ` Sunil V L
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+QToXO2kYQ2ipdz@spud \
--to=conor@kernel.org \
--cc=ajones@ventanamicro.com \
--cc=aou@eecs.berkeley.edu \
--cc=apatel@ventanamicro.com \
--cc=atishp@rivosinc.com \
--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=sunilvl@ventanamicro.com \
--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 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.