From: Andrew Jones <ajones@ventanamicro.com>
To: Anup Patel <apatel@ventanamicro.com>
Cc: Palmer Dabbelt <palmer@dabbelt.com>,
Paul Walmsley <paul.walmsley@sifive.com>,
Thomas Gleixner <tglx@linutronix.de>,
Marc Zyngier <maz@kernel.org>, Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Frank Rowand <frowand.list@gmail.com>,
Conor Dooley <conor+dt@kernel.org>,
Atish Patra <atishp@atishpatra.org>,
Sunil V L <sunilvl@ventanamicro.com>,
Saravana Kannan <saravanak@google.com>,
Anup Patel <anup@brainfault.org>,
linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org
Subject: Re: [PATCH v7 01/15] RISC-V: Add riscv_get_intc_hartid() function
Date: Wed, 2 Aug 2023 20:09:18 +0300 [thread overview]
Message-ID: <20230802-b0c478839e55890385d98f31@orel> (raw)
In-Reply-To: <20230802150018.327079-2-apatel@ventanamicro.com>
On Wed, Aug 02, 2023 at 08:30:04PM +0530, Anup Patel wrote:
> We add a common riscv_get_intc_hartid() which help device drivers to
> get hartid of the HART associated with a INTC (i.e. local interrupt
> controller) fwnode. This new function is more generic compared to
> the existing riscv_of_parent_hartid() function hence we also replace
> use of riscv_of_parent_hartid() with riscv_get_intc_hartid().
>
> Also, while we are here let us update riscv_of_parent_hartid() to
> always return the hartid irrespective whether the CPU/HART DT node
> is disabled or not.
This change should probably be a separate patch with its own
justification in its commit message.
>
> Signed-off-by: Anup Patel <apatel@ventanamicro.com>
> ---
> arch/riscv/include/asm/processor.h | 4 +++-
> arch/riscv/kernel/cpu.c | 26 ++++++++++++++++++++------
> drivers/irqchip/irq-riscv-intc.c | 2 +-
> drivers/irqchip/irq-sifive-plic.c | 3 ++-
> 4 files changed, 26 insertions(+), 9 deletions(-)
>
> diff --git a/arch/riscv/include/asm/processor.h b/arch/riscv/include/asm/processor.h
> index c950a8d9edef..662da1e112dd 100644
> --- a/arch/riscv/include/asm/processor.h
> +++ b/arch/riscv/include/asm/processor.h
> @@ -79,7 +79,9 @@ static inline void wait_for_interrupt(void)
> struct device_node;
> int riscv_of_processor_hartid(struct device_node *node, unsigned long *hartid);
> int riscv_early_of_processor_hartid(struct device_node *node, unsigned long *hartid);
> -int riscv_of_parent_hartid(struct device_node *node, unsigned long *hartid);
> +
> +struct fwnode_handle;
> +int riscv_get_intc_hartid(struct fwnode_handle *node, unsigned long *hartid);
Do we want a function that is named in a way that appears to be
intc-specific in processor.h?
>
> extern void riscv_fill_hwcap(void);
> extern int arch_dup_task_struct(struct task_struct *dst, struct task_struct *src);
> diff --git a/arch/riscv/kernel/cpu.c b/arch/riscv/kernel/cpu.c
> index a2fc952318e9..c3eaa8a55bbe 100644
> --- a/arch/riscv/kernel/cpu.c
> +++ b/arch/riscv/kernel/cpu.c
> @@ -81,21 +81,35 @@ int riscv_early_of_processor_hartid(struct device_node *node, unsigned long *har
> * To achieve this, we walk up the DT tree until we find an active
> * RISC-V core (HART) node and extract the cpuid from it.
> */
> -int riscv_of_parent_hartid(struct device_node *node, unsigned long *hartid)
> +static int riscv_of_parent_hartid(struct device_node *node,
> + unsigned long *hartid)
> {
> - int rc;
> -
> for (; node; node = node->parent) {
> if (of_device_is_compatible(node, "riscv")) {
> - rc = riscv_of_processor_hartid(node, hartid);
> - if (!rc)
> - return 0;
> + *hartid = (unsigned long)of_get_cpu_hwid(node, 0);
Shouldn't we still do something like
if (*hartid == ~0UL) {
pr_warn_once("Found CPU without hart ID\n");
return -ENODEV;
}
> + return 0;
> }
> }
>
> return -1;
> }
>
> +/* Find hart ID of the INTC fwnode. */
> +int riscv_get_intc_hartid(struct fwnode_handle *node, unsigned long *hartid)
> +{
> + int rc;
> + u64 temp;
> +
> + if (!is_of_node(node)) {
> + rc = fwnode_property_read_u64_array(node, "hartid", &temp, 1);
This fwnode property read call seems premature, since we don't have any
way to know that "hartid" will be a property of the intc since it's not a
property documented in the DT binding. (I know Sunil has a series in
progress which will introduce "hartid" for ACPI, but, even then, it seems
like we need some documentation to point at that says '"hartid" is the
name to use'.
> + if (!rc)
> + *hartid = temp;
> + } else
> + rc = riscv_of_parent_hartid(to_of_node(node), hartid);
> +
> + return rc;
> +}
> +
> DEFINE_PER_CPU(struct riscv_cpuinfo, riscv_cpuinfo);
>
> unsigned long riscv_cached_mvendorid(unsigned int cpu_id)
> diff --git a/drivers/irqchip/irq-riscv-intc.c b/drivers/irqchip/irq-riscv-intc.c
> index 4adeee1bc391..65f4a2afb381 100644
> --- a/drivers/irqchip/irq-riscv-intc.c
> +++ b/drivers/irqchip/irq-riscv-intc.c
> @@ -143,7 +143,7 @@ static int __init riscv_intc_init(struct device_node *node,
> int rc;
> unsigned long hartid;
>
> - rc = riscv_of_parent_hartid(node, &hartid);
> + rc = riscv_get_intc_hartid(of_fwnode_handle(node), &hartid);
> if (rc < 0) {
> pr_warn("unable to find hart id for %pOF\n", node);
> return 0;
> diff --git a/drivers/irqchip/irq-sifive-plic.c b/drivers/irqchip/irq-sifive-plic.c
> index e1484905b7bd..56b0544b1f27 100644
> --- a/drivers/irqchip/irq-sifive-plic.c
> +++ b/drivers/irqchip/irq-sifive-plic.c
> @@ -477,7 +477,8 @@ static int __init __plic_init(struct device_node *node,
> continue;
> }
>
> - error = riscv_of_parent_hartid(parent.np, &hartid);
> + error = riscv_get_intc_hartid(of_fwnode_handle(parent.np),
> + &hartid);
> if (error < 0) {
> pr_warn("failed to parse hart ID for context %d.\n", i);
> continue;
> --
> 2.34.1
>
Thanks,
drew
next prev parent reply other threads:[~2023-08-02 17:11 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-02 15:00 [PATCH v7 00/15] Linux RISC-V AIA Support Anup Patel
2023-08-02 15:00 ` [PATCH v7 01/15] RISC-V: Add riscv_get_intc_hartid() function Anup Patel
2023-08-02 17:09 ` Andrew Jones [this message]
2023-08-02 17:18 ` Conor Dooley
2023-08-03 4:12 ` Anup Patel
2023-08-02 17:20 ` Conor Dooley
2023-08-03 4:35 ` Anup Patel
2023-08-02 15:00 ` [PATCH v7 02/15] of: property: Add fw_devlink support for msi-parent Anup Patel
2023-08-11 19:39 ` Rob Herring
2023-08-11 20:59 ` Saravana Kannan
2023-08-12 2:49 ` Anup Patel
2023-08-02 15:00 ` [PATCH v7 03/15] drivers: irqchip/riscv-intc: Mark all INTC nodes as initialized Anup Patel
2023-08-02 15:00 ` [PATCH v7 04/15] irqchip/sifive-plic: Fix syscore registration for multi-socket systems Anup Patel
2023-08-02 15:00 ` [PATCH v7 05/15] irqchip/sifive-plic: Convert PLIC driver into a platform driver Anup Patel
2023-08-02 15:00 ` [PATCH v7 06/15] irqchip/riscv-intc: Add support for RISC-V AIA Anup Patel
2023-08-02 15:00 ` [PATCH v7 07/15] dt-bindings: interrupt-controller: Add RISC-V incoming MSI controller Anup Patel
2023-08-02 15:00 ` [PATCH v7 08/15] irqchip: Add RISC-V incoming MSI controller early driver Anup Patel
2023-08-02 15:00 ` [PATCH v7 09/15] irqchip/riscv-imsic: Add support for platform MSI irqdomain Anup Patel
2023-08-02 15:00 ` [PATCH v7 10/15] irqchip/riscv-imsic: Add support for PCI " Anup Patel
2023-08-02 15:00 ` [PATCH v7 11/15] dt-bindings: interrupt-controller: Add RISC-V advanced PLIC Anup Patel
[not found] ` <CABvJ_xi5r-NL=22tJWfyQQSti4XgUwsx94B8mQ3LJU29kiQC8w@mail.gmail.com>
2023-08-10 8:08 ` Anup Patel
[not found] ` <CABvJ_xiZY5RGMXOq0bWKRdkzD=b4ar6cFiujmPbUYmHUzSW5Qw@mail.gmail.com>
2023-08-12 2:59 ` Anup Patel
2023-08-14 6:43 ` Vincent Chen
2023-08-02 15:00 ` [PATCH v7 12/15] irqchip: Add RISC-V advanced PLIC driver for direct-mode Anup Patel
2023-08-02 15:00 ` [PATCH v7 13/15] irqchip/riscv-aplic: Add support for MSI-mode Anup Patel
2023-08-02 15:00 ` [PATCH v7 14/15] RISC-V: Select APLIC and IMSIC drivers Anup Patel
2023-08-02 15:00 ` [PATCH v7 15/15] MAINTAINERS: Add entry for RISC-V AIA drivers Anup Patel
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=20230802-b0c478839e55890385d98f31@orel \
--to=ajones@ventanamicro.com \
--cc=anup@brainfault.org \
--cc=apatel@ventanamicro.com \
--cc=atishp@atishpatra.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=frowand.list@gmail.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=maz@kernel.org \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=robh+dt@kernel.org \
--cc=saravanak@google.com \
--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 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).