Message ID | 20230803175916.3174453-10-sunilvl@ventanamicro.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:9f41:0:b0:3e4:2afc:c1 with SMTP id v1csp1359243vqx; Thu, 3 Aug 2023 12:24:01 -0700 (PDT) X-Google-Smtp-Source: APBJJlHLbwB8b5svEL5Lr81KkoX+n3wDn/zWqIDo9aMNJIgCAtHSVbUwSBGSVMyPTGyu/wXhjvK6 X-Received: by 2002:a17:902:c94e:b0:1bb:32de:95c5 with SMTP id i14-20020a170902c94e00b001bb32de95c5mr18862488pla.65.1691090640953; Thu, 03 Aug 2023 12:24:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1691090640; cv=none; d=google.com; s=arc-20160816; b=vFdLdL2jp7c/j85jFPFotyQYENyVbXfGmlBT3gPl4ZI0YgzCACUXJeOWXdJqEnlM7L /tJNgtxdAFfY65xTxDzp9ggwXcW+oDN+0YXthBMXRwoxDypStCMRWe4o5O2Q1c7N/1A9 6ULrAArHrnkxNa4fHTmmjP/DV67FTLg7GiDN2RSVNFxmqKKPYSeotO6If6KErkjPJz55 Hhh7bd6gkxzKfmCuNvO95kGoUIS2x79uFlhkdx3DHkHhXrwcXEIF1nzcK+qbZ3tID64j K4siXXQ8Qkw4coFDlC440RsqMV3p7X+aKNQFnd/oykjQyIy8tLi+Q/rSGEbnCgB0D0l3 WWig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=dVaxSLrcyWrDv537p1b6trWUWlm89roci1AhpEn7YYs=; fh=dzn7FZXuyjRD/SsADoLVmv8ajN6bypv0shpvYBNDmUc=; b=pRDFxp+13Sv7D8wzhoHgRagKm5To74ledVCJra8jo9Pw1AxOefejOsK8iaOI9Sy3aT B3sW9amuFGYHaRS6chUfWBCHDY3UU2tS/TU3HVqPJErSPT3ef7R3eyibCUYPWrd6zwgi BhMbi8mIPt2pXxQTg6jPyqUW97iLOFCYrimHj9u89NvoImO9ODxhocXRLuO3t3FWFnni V7vmWRcaoRzjHznRKfPVVkNPboR60F+55UoliQ0djHcBg6yysjYvdwuk4wAYLicxj17A ykbUXL1dePf6wSONaQoNEJ5aL5vaIwPzTdIDp+1HQuVjirvqTs1cYJA0WpY9bvphClHx UlmQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ventanamicro.com header.s=google header.b="fYo/3hat"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id y17-20020a170902cad100b001bc33214101si362601pld.596.2023.08.03.12.23.47; Thu, 03 Aug 2023 12:24:00 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@ventanamicro.com header.s=google header.b="fYo/3hat"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232571AbjHCSCD (ORCPT <rfc822;guoshuai5156@gmail.com> + 99 others); Thu, 3 Aug 2023 14:02:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60404 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231553AbjHCSBZ (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 3 Aug 2023 14:01:25 -0400 Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2946A3C23 for <linux-kernel@vger.kernel.org>; Thu, 3 Aug 2023 11:00:52 -0700 (PDT) Received: by mail-pf1-x436.google.com with SMTP id d2e1a72fcca58-686daaa5f1fso893195b3a.3 for <linux-kernel@vger.kernel.org>; Thu, 03 Aug 2023 11:00:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ventanamicro.com; s=google; t=1691085641; x=1691690441; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=dVaxSLrcyWrDv537p1b6trWUWlm89roci1AhpEn7YYs=; b=fYo/3hatpzRNQHoHD581iWzQIHlOzusgQsa6qibNN0GLNn1R7S4p/XTrzg4lClBc1p lJKgy1mbJhBtdMSWvCGh9zo1ep2Gb3uA2P3XQbn7aI/LMI4bTDshu3hqT/1QFrqsfu7m TIdcKLkqWqqkK/tNhUcjdcoUPhpOgQm7R1QCCvGw5YQNWhSTvYAfTTAX+lJGELc3ARqy uX+JaTHismEAtWt+icKb9NzCOg5nBT52EbnylGIEAzjm2gWGkCHux7TB4Bi59RFPoIqH 3R5ZRXHZLPpTl5R/PsHSm82EmxC7TCybtefpHDuU1MaqhlgUMegZvF1tMLSTrgHDefTg PaXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691085641; x=1691690441; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=dVaxSLrcyWrDv537p1b6trWUWlm89roci1AhpEn7YYs=; b=cZ+Ev87LpRS/aVbLmja1W7W+/XhdcM04DUcVKq/wA5ZHGmkj8Tn7W4ybZZhBKF599r cUp61GxwZuVwjRJge953i0AVlDkcAuk3i+Ukce+Z2b3YEz00IdHnZCmKvHtlvti/QvN/ i34Jz6m5fvOTs4rkJ73lfVJ07ScUg/x8HCYH8Cpe58CeC2rYZHSMZaP1va+U8fY3o6iy uX8P5HjWDF0bvZz9h2fc+iWd+EhbaGC0+DlV4+qbpsIEMomclfgjfyJJS68ywuqNWLyn oWMHkiDVrVOTeqVCrqyKsVzbnZb9LLYDIL69z/9qjYA5jSqEfEsQyjPNFEfnmgJl4sWc GHMw== X-Gm-Message-State: ABy/qLbcWsEyAE6iG/roM13h5C9DmODXSoQsUCw00sLEySbWiQ2ixOPB SmOyT9mGk74NOO8em7dJSiPvIg== X-Received: by 2002:a05:6a21:6da1:b0:13d:82eb:795a with SMTP id wl33-20020a056a216da100b0013d82eb795amr13802350pzb.56.1691085641397; Thu, 03 Aug 2023 11:00:41 -0700 (PDT) Received: from sunil-pc.Dlink ([106.51.190.143]) by smtp.gmail.com with ESMTPSA id s8-20020aa78d48000000b0065a1b05193asm134952pfe.185.2023.08.03.11.00.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 03 Aug 2023 11:00:41 -0700 (PDT) From: Sunil V L <sunilvl@ventanamicro.com> To: linux-doc@vger.kernel.org, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-acpi@vger.kernel.org, linux-pci@vger.kernel.org Cc: Jonathan Corbet <corbet@lwn.net>, Paul Walmsley <paul.walmsley@sifive.com>, Palmer Dabbelt <palmer@dabbelt.com>, Albert Ou <aou@eecs.berkeley.edu>, Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>, "Rafael J . Wysocki" <rafael@kernel.org>, Len Brown <lenb@kernel.org>, Andy Shevchenko <andriy.shevchenko@linux.intel.com>, Daniel Scally <djrscally@gmail.com>, Heikki Krogerus <heikki.krogerus@linux.intel.com>, Sakari Ailus <sakari.ailus@linux.intel.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Daniel Lezcano <daniel.lezcano@linaro.org>, Thomas Gleixner <tglx@linutronix.de>, Anup Patel <anup@brainfault.org>, Marc Zyngier <maz@kernel.org>, Bjorn Helgaas <bhelgaas@google.com>, Robert Moore <robert.moore@intel.com>, Haibo Xu <haibo1.xu@intel.com>, Andrew Jones <ajones@ventanamicro.com>, Conor Dooley <conor.dooley@microchip.com>, Atish Kumar Patra <atishp@rivosinc.com>, Sunil V L <sunilvl@ventanamicro.com> Subject: [RFC PATCH v1 09/21] RISC-V: cacheflush: Initialize CBO variables on ACPI systems Date: Thu, 3 Aug 2023 23:29:04 +0530 Message-Id: <20230803175916.3174453-10-sunilvl@ventanamicro.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20230803175916.3174453-1-sunilvl@ventanamicro.com> References: <20230803175916.3174453-1-sunilvl@ventanamicro.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_BLOCKED, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1773237060255263134 X-GMAIL-MSGID: 1773237060255263134 |
Series |
RISC-V: ACPI: Add external interrupt controller support
|
|
Commit Message
Sunil V L
Aug. 3, 2023, 5:59 p.m. UTC
Using new interface to get the CBO block size information in
RHCT, initialize the variables on ACPI platforms.
Signed-off-by: Sunil V L <sunilvl@ventanamicro.com>
---
arch/riscv/mm/cacheflush.c | 37 +++++++++++++++++++++++++++++++------
1 file changed, 31 insertions(+), 6 deletions(-)
Comments
On Thu, Aug 03, 2023 at 11:29:04PM +0530, Sunil V L wrote: > Using new interface to get the CBO block size information in > RHCT, initialize the variables on ACPI platforms. ... > #include <linux/of.h> > +#include <linux/acpi.h> Can you keep it sorted (to some extent)? > +#include <asm/acpi.h> What do you need this for? > #include <asm/cacheflush.h>
On Fri, Aug 04, 2023 at 08:56:29AM +0300, Andy Shevchenko wrote: > On Thu, Aug 03, 2023 at 11:29:04PM +0530, Sunil V L wrote: > > Using new interface to get the CBO block size information in > > RHCT, initialize the variables on ACPI platforms. > > ... > > > #include <linux/of.h> > > +#include <linux/acpi.h> > > Can you keep it sorted (to some extent)? > Sure. > > +#include <asm/acpi.h> > > What do you need this for? > > > #include <asm/cacheflush.h> > When CONFIG_ACPI is disabled, this include is required to get acpi_get_cbo_block_size(). Thanks, Sunil
On Fri, Aug 04, 2023 at 02:50:34PM +0530, Sunil V L wrote: > On Fri, Aug 04, 2023 at 08:56:29AM +0300, Andy Shevchenko wrote: > > On Thu, Aug 03, 2023 at 11:29:04PM +0530, Sunil V L wrote: > > > Using new interface to get the CBO block size information in > > > RHCT, initialize the variables on ACPI platforms. ... > > > +#include <asm/acpi.h> > > > > What do you need this for? > > > > > #include <asm/cacheflush.h> > > > When CONFIG_ACPI is disabled, this include is required to get > acpi_get_cbo_block_size(). How is it useful without ACPI being enabled? If it's indeed (in which I do not believe), better to make sure you have it avaiable independently on CONFIG_ACPI. Otherwise, just put #ifdef CONFIG_ACPI around the call.
On Fri, Aug 04, 2023 at 05:59:51PM +0300, Andy Shevchenko wrote: > On Fri, Aug 04, 2023 at 02:50:34PM +0530, Sunil V L wrote: > > On Fri, Aug 04, 2023 at 08:56:29AM +0300, Andy Shevchenko wrote: > > > On Thu, Aug 03, 2023 at 11:29:04PM +0530, Sunil V L wrote: > > > > Using new interface to get the CBO block size information in > > > > RHCT, initialize the variables on ACPI platforms. > > ... > > > > > +#include <asm/acpi.h> > > > > > > What do you need this for? > > > > > > > #include <asm/cacheflush.h> > > > > > When CONFIG_ACPI is disabled, this include is required to get > > acpi_get_cbo_block_size(). > > How is it useful without ACPI being enabled? It is not, as evidenced by the `return -EINVAL;`. > If it's indeed > (in which I do not believe), better to make sure you have it > avaiable independently on CONFIG_ACPI. Otherwise, just put > #ifdef CONFIG_ACPI around the call. Let's not litter the code with ifdeffery please where it can be easily avoided.
On Fri, Aug 04, 2023 at 04:19:27PM +0100, Conor Dooley wrote: > On Fri, Aug 04, 2023 at 05:59:51PM +0300, Andy Shevchenko wrote: > > On Fri, Aug 04, 2023 at 02:50:34PM +0530, Sunil V L wrote: > > > On Fri, Aug 04, 2023 at 08:56:29AM +0300, Andy Shevchenko wrote: > > > > On Thu, Aug 03, 2023 at 11:29:04PM +0530, Sunil V L wrote: ... > > > > > +#include <asm/acpi.h> > > > > > > > > What do you need this for? > > > > > > > > > #include <asm/cacheflush.h> > > > > > > > When CONFIG_ACPI is disabled, this include is required to get > > > acpi_get_cbo_block_size(). > > > > How is it useful without ACPI being enabled? > > It is not, as evidenced by the `return -EINVAL;`. > > > If it's indeed > > (in which I do not believe), better to make sure you have it > > avaiable independently on CONFIG_ACPI. Otherwise, just put > > #ifdef CONFIG_ACPI around the call. > > Let's not litter the code with ifdeffery please where it can be easily > avoided. Including asm/acpi.h looks to me as a "let's avoid it with a hack that it is uglier than ifdeffery". Sorry, but ifdeffery for ACPI, with all my full agreement with the statement that it's not good, is the correct way to fix this.
On Fri, Aug 04, 2023 at 07:52:56PM +0300, Andy Shevchenko wrote: > On Fri, Aug 04, 2023 at 04:19:27PM +0100, Conor Dooley wrote: > > On Fri, Aug 04, 2023 at 05:59:51PM +0300, Andy Shevchenko wrote: > > > On Fri, Aug 04, 2023 at 02:50:34PM +0530, Sunil V L wrote: > > > > On Fri, Aug 04, 2023 at 08:56:29AM +0300, Andy Shevchenko wrote: > > > > > On Thu, Aug 03, 2023 at 11:29:04PM +0530, Sunil V L wrote: ... > > > > > > +#include <asm/acpi.h> > > > > > > > > > > What do you need this for? > > > > > > > > > > > #include <asm/cacheflush.h> > > > > > > > > > When CONFIG_ACPI is disabled, this include is required to get > > > > acpi_get_cbo_block_size(). > > > > > > How is it useful without ACPI being enabled? > > > > It is not, as evidenced by the `return -EINVAL;`. > > > > > If it's indeed > > > (in which I do not believe), better to make sure you have it > > > avaiable independently on CONFIG_ACPI. Otherwise, just put > > > #ifdef CONFIG_ACPI around the call. > > > > Let's not litter the code with ifdeffery please where it can be easily > > avoided. > > Including asm/acpi.h looks to me as a "let's avoid it with a hack that it > is uglier than ifdeffery". Sorry, but ifdeffery for ACPI, with all my full > agreement with the statement that it's not good, is the correct way to fix > this. On the other hand this is an arch code and I see precedents of using the headers together, alas, it seems not better to me that ugly ifdeffery. So, I leave it to the respective maintainers to decide.
diff --git a/arch/riscv/mm/cacheflush.c b/arch/riscv/mm/cacheflush.c index fbc59b3f69f2..63bb56819b37 100644 --- a/arch/riscv/mm/cacheflush.c +++ b/arch/riscv/mm/cacheflush.c @@ -4,6 +4,8 @@ */ #include <linux/of.h> +#include <linux/acpi.h> +#include <asm/acpi.h> #include <asm/cacheflush.h> #ifdef CONFIG_SMP @@ -131,15 +133,38 @@ void __init riscv_init_cbo_blocksizes(void) unsigned long cbom_hartid, cboz_hartid; u32 cbom_block_size = 0, cboz_block_size = 0; struct device_node *node; + struct acpi_table_header *rhct; + acpi_status status; + unsigned int cpu; + + if (!acpi_disabled) { + status = acpi_get_table(ACPI_SIG_RHCT, 0, &rhct); + if (ACPI_FAILURE(status)) + return; + } - for_each_of_cpu_node(node) { - /* set block-size for cbom and/or cboz extension if available */ - cbo_get_block_size(node, "riscv,cbom-block-size", - &cbom_block_size, &cbom_hartid); - cbo_get_block_size(node, "riscv,cboz-block-size", - &cboz_block_size, &cboz_hartid); + for_each_possible_cpu(cpu) { + if (acpi_disabled) { + node = of_cpu_device_node_get(cpu); + if (!node) { + pr_warn("Unable to find cpu node\n"); + continue; + } + + /* set block-size for cbom and/or cboz extension if available */ + cbo_get_block_size(node, "riscv,cbom-block-size", + &cbom_block_size, &cbom_hartid); + cbo_get_block_size(node, "riscv,cboz-block-size", + &cboz_block_size, &cboz_hartid); + } else { + acpi_get_cbo_block_size(rhct, cpu, &cbom_block_size, + &cboz_block_size, NULL); + } } + if (!acpi_disabled && rhct) + acpi_put_table((struct acpi_table_header *)rhct); + if (cbom_block_size) riscv_cbom_block_size = cbom_block_size;