Message ID | 20230626-silk-colonize-824390303994@wendy |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:994d:0:b0:3d9:f83d:47d9 with SMTP id k13csp7412887vqr; Mon, 26 Jun 2023 04:36:07 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ6VQUMlei1NLEqDkyGoK7hdNOYvM6HIb9IUl+Bmi2yoo4MApoDo0ja49wAug1MWfRMRpTHS X-Received: by 2002:a17:906:9b88:b0:988:98a3:fd44 with SMTP id dd8-20020a1709069b8800b0098898a3fd44mr20210410ejc.28.1687779366815; Mon, 26 Jun 2023 04:36:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1687779366; cv=none; d=google.com; s=arc-20160816; b=zkc545jhYJMdtk07+8c3Zwwt6sR0h/npDhoNlcGjXBxxN1QqqSQHVEQE7kz9Rq+QJ2 HWu+FjHlvmk5qvqR4DOrmEwDG96SFMclbYUHUEsJ/rTIQ/MzYMu5xezZFAKmbBYS9LDJ gNV/VAJ/cLNQHgjt2S8greYNA/UmOMh+19EqnIYDZDg6+O7WFkQpZLyv6ZSCGmJmmhvp MZ6equW98on/A+P6QNC7AV3JMQH+sM5X0DzAvL2O3t9S0zO3RZP5WnCTnYMzAHqov1iY H9a2WvJqYX+PjRuFhpBmTSHekLi+/wmxoOH/CJHyJ3/V8tiarr56UsNPEKK987ZSBhLi i4MA== 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=8OZmO8EQ4qgbFmtKj5ZzMjCQ/pk3oPAHrCY5XROnR2o=; fh=id5NoWTfrmVnmm2w/Ed5X4erHGUuViLdGWw+WL1NNbc=; b=r2taYJKFqspRXKtxnh2yoHE/ZdA0F8dYh3W4JGE+knQEFnwc1jIXjIX1mSDzvlQae3 tAl9GW/5mlSmQwqU9xI9ud5rFGqjt16zqwAIIyQZbovhNAPq9/vX3n8FZHFjFTFI6RJR 0/mmIBDUNrzOlMvid81hHW0BiBYretA9BPCNetWGADwoNigGlElaG2yWAUKugU4WDmCP OXig38QIOo/+/qTh9EeVxqjKm19x+rWBzhHt+T7VMl78gpoqRhCsQGjnTkDV79BnRZtU mgDJCaofOz00uxkT7mdaync4U7Ms9NoXYuLzdq5y3yHRSQB0WVGIzhNJ6F9Ix71lt1pp wgOQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@microchip.com header.s=mchp header.b="RS3M/voF"; 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; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=microchip.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id qw3-20020a170906fca300b0098dfa5abc0bsi2181267ejb.88.2023.06.26.04.35.41; Mon, 26 Jun 2023 04:36:06 -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=@microchip.com header.s=mchp header.b="RS3M/voF"; 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; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=microchip.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230154AbjFZLU4 (ORCPT <rfc822;filip.gregor98@gmail.com> + 99 others); Mon, 26 Jun 2023 07:20:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56348 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230164AbjFZLUx (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 26 Jun 2023 07:20:53 -0400 Received: from esa.microchip.iphmx.com (esa.microchip.iphmx.com [68.232.153.233]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1854FFF; Mon, 26 Jun 2023 04:20:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=microchip.com; i=@microchip.com; q=dns/txt; s=mchp; t=1687778450; x=1719314450; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=Mu+g58nhjsHPstxLBmB5/V/xzpUyBi/njYK6W3OCzlM=; b=RS3M/voFSpsuqh5KRfsnkmkUUqO2jVFsyRiaiqS+H10NhSyZ0VoJ/SbO JmiRZfbeHHQCIBTdxrUD1wup+OwUgjBIE67E0DxBDRKXaV23rwoO2eMpK t8lVlSRxFI3JFZPPwRyqGOXfGINfX9zOAeRUPr+zSTXum+xiCPOg7YPho ZiplFxYY9Zh5n2y8yK+vGu8H221tWPm+mahA3/1cffPO9dh1hGLWvXE17 qM5R6xGitLn4tcNH+gYc+bPfGJUmsG96zZDdmTluR0bseB/PHmqyj+PiH EcMKbSzIGboO23+zP+V0YEKr/sheeSRgZncpsp1/VGyY5dxtftPolPDZn Q==; X-IronPort-AV: E=Sophos;i="6.01,159,1684825200"; d="scan'208";a="232170762" X-Amp-Result: SKIPPED(no attachment in message) Received: from unknown (HELO email.microchip.com) ([170.129.1.10]) by esa1.microchip.iphmx.com with ESMTP/TLS/AES256-SHA256; 26 Jun 2023 04:20:49 -0700 Received: from chn-vm-ex02.mchp-main.com (10.10.87.72) by chn-vm-ex02.mchp-main.com (10.10.87.72) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.21; Mon, 26 Jun 2023 04:20:48 -0700 Received: from wendy.microchip.com (10.10.115.15) by chn-vm-ex02.mchp-main.com (10.10.85.144) with Microsoft SMTP Server id 15.1.2507.21 via Frontend Transport; Mon, 26 Jun 2023 04:20:45 -0700 From: Conor Dooley <conor.dooley@microchip.com> To: <palmer@dabbelt.com> CC: <conor@kernel.org>, <conor.dooley@microchip.com>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Paul Walmsley <paul.walmsley@sifive.com>, Albert Ou <aou@eecs.berkeley.edu>, Andrew Jones <ajones@ventanamicro.com>, Heiko Stuebner <heiko.stuebner@vrull.eu>, "Evan Green" <evan@rivosinc.com>, Sunil V L <sunilvl@ventanamicro.com>, <linux-riscv@lists.infradead.org>, <devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org> Subject: [PATCH v1 1/9] RISC-V: don't parse dt/acpi isa string to get rv32/rv64 Date: Mon, 26 Jun 2023 12:19:39 +0100 Message-ID: <20230626-silk-colonize-824390303994@wendy> X-Mailer: git-send-email 2.40.1 In-Reply-To: <20230626-provable-angrily-81760e8c3cc6@wendy> References: <20230626-provable-angrily-81760e8c3cc6@wendy> MIME-Version: 1.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=2178; i=conor.dooley@microchip.com; h=from:subject:message-id; bh=Zp2OijcNG2QSKXKrNz/jnk7bkS3lWHsdOCwgyctpfpk=; b=owGbwMvMwCFWscWwfUFT0iXG02pJDCkzS3yV91hPUsrLUjn8U36bqs73+S/0OJyXVuhk5uSevTAp eKNbRykLgxgHg6yYIkvi7b4WqfV/XHY497yFmcPKBDKEgYtTACZy1pmRYWb8nHMvymR93EJYDRm2Ky 8q7dW8JPXC2lDym4nJi9//hRl+Mm7JDLa73Xc+8GGy2YJd9ywm9AssWMA/9ckcw1P5qrv1WAA= X-Developer-Key: i=conor.dooley@microchip.com; a=openpgp; fpr=F9ECA03CF54F12CD01F1655722E2C55B37CF380C Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_PASS,SPF_NONE,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: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1769764937114601495?= X-GMAIL-MSGID: =?utf-8?q?1769764937114601495?= |
Series |
RISC-V: Probe DT extension support using riscv,isa-extensions & riscv,isa-base
|
|
Commit Message
Conor Dooley
June 26, 2023, 11:19 a.m. UTC
From: Heiko Stuebner <heiko.stuebner@vrull.eu> When filling hwcap the kernel already expects the isa string to start with rv32 if CONFIG_32BIT and rv64 if CONFIG_64BIT. So when recreating the runtime isa-string we can also just go the other way to get the correct starting point for it. Signed-off-by: Heiko Stuebner <heiko.stuebner@vrull.eu> Co-developed-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Conor Dooley <conor.dooley@microchip.com> --- arch/riscv/kernel/cpu.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-)
Comments
On Mon, Jun 26, 2023 at 12:19:39PM +0100, Conor Dooley wrote: > From: Heiko Stuebner <heiko.stuebner@vrull.eu> > > When filling hwcap the kernel already expects the isa string to start with > rv32 if CONFIG_32BIT and rv64 if CONFIG_64BIT. > > So when recreating the runtime isa-string we can also just go the other way > to get the correct starting point for it. > > Signed-off-by: Heiko Stuebner <heiko.stuebner@vrull.eu> > Co-developed-by: Conor Dooley <conor.dooley@microchip.com> > Signed-off-by: Conor Dooley <conor.dooley@microchip.com> > --- > arch/riscv/kernel/cpu.c | 16 ++++++++-------- > 1 file changed, 8 insertions(+), 8 deletions(-) > > diff --git a/arch/riscv/kernel/cpu.c b/arch/riscv/kernel/cpu.c > index a2fc952318e9..742bb42e7e86 100644 > --- a/arch/riscv/kernel/cpu.c > +++ b/arch/riscv/kernel/cpu.c > @@ -253,13 +253,16 @@ static void print_isa_ext(struct seq_file *f) > */ > static const char base_riscv_exts[13] = "imafdqcbkjpvh"; > > -static void print_isa(struct seq_file *f, const char *isa) > +static void print_isa(struct seq_file *f) > { > int i; > > seq_puts(f, "isa\t\t: "); > - /* Print the rv[64/32] part */ > - seq_write(f, isa, 4); > + if (IS_ENABLED(CONFIG_32BIT)) > + seq_write(f, "rv32", 4); > + else > + seq_write(f, "rv64", 4); > + > for (i = 0; i < sizeof(base_riscv_exts); i++) { > if (__riscv_isa_extension_available(NULL, base_riscv_exts[i] - 'a')) > /* Print only enabled the base ISA extensions */ > @@ -316,15 +319,14 @@ static int c_show(struct seq_file *m, void *v) > unsigned long cpu_id = (unsigned long)v - 1; > struct riscv_cpuinfo *ci = per_cpu_ptr(&riscv_cpuinfo, cpu_id); > struct device_node *node; > - const char *compat, *isa; > + const char *compat; > > seq_printf(m, "processor\t: %lu\n", cpu_id); > seq_printf(m, "hart\t\t: %lu\n", cpuid_to_hartid_map(cpu_id)); > + print_isa(m); > > if (acpi_disabled) { > node = of_get_cpu_node(cpu_id, NULL); > - if (!of_property_read_string(node, "riscv,isa", &isa)) > - print_isa(m, isa); > > print_mmu(m); > if (!of_property_read_string(node, "compatible", &compat) && > @@ -333,8 +335,6 @@ static int c_show(struct seq_file *m, void *v) > > of_node_put(node); > } else { > - if (!acpi_get_riscv_isa(NULL, cpu_id, &isa)) > - print_isa(m, isa); > Extra blank line here to remove. Actually the whole 'else' can be removed because the print_mmu() call can be brought up above the 'if (acpi_disabled)' > print_mmu(m); > } > -- > 2.40.1 > Otherwise, Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Thanks, drew
On Mon, Jun 26, 2023 at 05:14:15PM +0200, Andrew Jones wrote: > On Mon, Jun 26, 2023 at 12:19:39PM +0100, Conor Dooley wrote: > > From: Heiko Stuebner <heiko.stuebner@vrull.eu> > > @@ -333,8 +335,6 @@ static int c_show(struct seq_file *m, void *v) > > > > of_node_put(node); > > } else { > > - if (!acpi_get_riscv_isa(NULL, cpu_id, &isa)) > > - print_isa(m, isa); > > > > Extra blank line here to remove. Actually the whole 'else' can be removed > because the print_mmu() call can be brought up above the > 'if (acpi_disabled)' Can it be? I intentionally did not make that change - wasn't sure whether re-ordering the fields in there was permissible. One of the few things I know does parsing of /proc/cpuinfo is: https://github.com/google/cpu_features/blob/main/src/impl_riscv_linux.c and that doesn't seem to care about the mmu, but does rely on vendor/uarch ordering. Makes me wonder, does ACPI break things by leaving out uarch/vendor fields, if there is something that expects them to exist? We should not intentionally break stuff in /proc/cpuinfo, but can't say I feel any sympathy for naively parsing it. > > print_mmu(m);
On Mon, Jun 26, 2023 at 04:51:29PM +0100, Conor Dooley wrote: > On Mon, Jun 26, 2023 at 05:14:15PM +0200, Andrew Jones wrote: > > On Mon, Jun 26, 2023 at 12:19:39PM +0100, Conor Dooley wrote: > > > From: Heiko Stuebner <heiko.stuebner@vrull.eu> > > > @@ -333,8 +335,6 @@ static int c_show(struct seq_file *m, void *v) > > > > > > of_node_put(node); > > > } else { > > > - if (!acpi_get_riscv_isa(NULL, cpu_id, &isa)) > > > - print_isa(m, isa); > > > > > > > Extra blank line here to remove. Actually the whole 'else' can be removed > > because the print_mmu() call can be brought up above the > > 'if (acpi_disabled)' > > Can it be? I intentionally did not make that change - wasn't sure > whether re-ordering the fields in there was permissible. I agree we shouldn't change the order, but moving print_mmu() up won't, afaict. > > One of the few things I know does parsing of /proc/cpuinfo is: > https://github.com/google/cpu_features/blob/main/src/impl_riscv_linux.c > and that doesn't seem to care about the mmu, but does rely on > vendor/uarch ordering. > > Makes me wonder, does ACPI break things by leaving out uarch/vendor > fields, if there is something that expects them to exist? We should > not intentionally break stuff in /proc/cpuinfo, but can't say I feel any > sympathy for naively parsing it. Yes, it would be nice for ACPI to be consistent. I'm not sure what can be done about that. Thanks, drew > > > > print_mmu(m); >
On Mon, Jun 26, 2023 at 06:05:40PM +0200, Andrew Jones wrote: > On Mon, Jun 26, 2023 at 04:51:29PM +0100, Conor Dooley wrote: > > On Mon, Jun 26, 2023 at 05:14:15PM +0200, Andrew Jones wrote: > > > On Mon, Jun 26, 2023 at 12:19:39PM +0100, Conor Dooley wrote: > > > > From: Heiko Stuebner <heiko.stuebner@vrull.eu> > > > > @@ -333,8 +335,6 @@ static int c_show(struct seq_file *m, void *v) > > > > > > > > of_node_put(node); > > > > } else { > > > > - if (!acpi_get_riscv_isa(NULL, cpu_id, &isa)) > > > > - print_isa(m, isa); > > > > > > > > > > Extra blank line here to remove. Actually the whole 'else' can be removed > > > because the print_mmu() call can be brought up above the > > > 'if (acpi_disabled)' > > > > Can it be? I intentionally did not make that change - wasn't sure > > whether re-ordering the fields in there was permissible. > > I agree we shouldn't change the order, but moving print_mmu() up won't, > afaict. D'oh, I'm an eejit. Sure, I'll do that for v2. Thanks! > > One of the few things I know does parsing of /proc/cpuinfo is: > > https://github.com/google/cpu_features/blob/main/src/impl_riscv_linux.c > > and that doesn't seem to care about the mmu, but does rely on > > vendor/uarch ordering. > > > > Makes me wonder, does ACPI break things by leaving out uarch/vendor > > fields, if there is something that expects them to exist? We should > > not intentionally break stuff in /proc/cpuinfo, but can't say I feel any > > sympathy for naively parsing it. > > Yes, it would be nice for ACPI to be consistent. I'm not sure what can be > done about that. Print "unknown", until there's a way of passing the info? Speaking of being an eejit, adding new fields to the file would probably break some really naive parsers & quite frankly that sort of thing can keep the pieces IMO. Ditto if adding more extensions breaks someone that expects _zicbom_zicboz that breaks when _zicbop is slid into the middle.
On Mon, Jun 26, 2023 at 05:16:09PM +0100, Conor Dooley wrote: > On Mon, Jun 26, 2023 at 06:05:40PM +0200, Andrew Jones wrote: > > On Mon, Jun 26, 2023 at 04:51:29PM +0100, Conor Dooley wrote: > > > On Mon, Jun 26, 2023 at 05:14:15PM +0200, Andrew Jones wrote: > > > > On Mon, Jun 26, 2023 at 12:19:39PM +0100, Conor Dooley wrote: > > > > > From: Heiko Stuebner <heiko.stuebner@vrull.eu> > > > > > @@ -333,8 +335,6 @@ static int c_show(struct seq_file *m, void *v) > > > > > > > > > > of_node_put(node); > > > > > } else { > > > > > - if (!acpi_get_riscv_isa(NULL, cpu_id, &isa)) > > > > > - print_isa(m, isa); > > > > > > > > > > > > > Extra blank line here to remove. Actually the whole 'else' can be removed > > > > because the print_mmu() call can be brought up above the > > > > 'if (acpi_disabled)' > > > > > > Can it be? I intentionally did not make that change - wasn't sure > > > whether re-ordering the fields in there was permissible. > > > > I agree we shouldn't change the order, but moving print_mmu() up won't, > > afaict. > > D'oh, I'm an eejit. Sure, I'll do that for v2. Thanks! > > > > One of the few things I know does parsing of /proc/cpuinfo is: > > > https://github.com/google/cpu_features/blob/main/src/impl_riscv_linux.c > > > and that doesn't seem to care about the mmu, but does rely on > > > vendor/uarch ordering. > > > > > > Makes me wonder, does ACPI break things by leaving out uarch/vendor > > > fields, if there is something that expects them to exist? We should > > > not intentionally break stuff in /proc/cpuinfo, but can't say I feel any > > > sympathy for naively parsing it. > > > > Yes, it would be nice for ACPI to be consistent. I'm not sure what can be > > done about that. > > Print "unknown", until there's a way of passing the info? > Speaking of being an eejit, adding new fields to the file would probably > break some really naive parsers & quite frankly that sort of thing can > keep the pieces IMO. Ditto if adding more extensions breaks someone that > expects _zicbom_zicboz that breaks when _zicbop is slid into the middle. Hi Conor, Instead of unknown, could you print "risc-v" or "riscv"? There is nothing equivalent to compatible property in ACPI. Using mvendorid, marchid and mimpid, people can determine the exact processor <manufacturer>,<model>. Thanks! Sunil
On Tue, Jun 27, 2023 at 01:32:23PM +0530, Sunil V L wrote: > On Mon, Jun 26, 2023 at 05:16:09PM +0100, Conor Dooley wrote: > > On Mon, Jun 26, 2023 at 06:05:40PM +0200, Andrew Jones wrote: > > > On Mon, Jun 26, 2023 at 04:51:29PM +0100, Conor Dooley wrote: > > > > On Mon, Jun 26, 2023 at 05:14:15PM +0200, Andrew Jones wrote: > > > > > On Mon, Jun 26, 2023 at 12:19:39PM +0100, Conor Dooley wrote: > > > > One of the few things I know does parsing of /proc/cpuinfo is: > > > > https://github.com/google/cpu_features/blob/main/src/impl_riscv_linux.c > > > > and that doesn't seem to care about the mmu, but does rely on > > > > vendor/uarch ordering. > > > > > > > > Makes me wonder, does ACPI break things by leaving out uarch/vendor > > > > fields, if there is something that expects them to exist? We should > > > > not intentionally break stuff in /proc/cpuinfo, but can't say I feel any > > > > sympathy for naively parsing it. > > > > > > Yes, it would be nice for ACPI to be consistent. I'm not sure what can be > > > done about that. > > > > Print "unknown", until there's a way of passing the info? > > Speaking of being an eejit, adding new fields to the file would probably > > break some really naive parsers & quite frankly that sort of thing can > > keep the pieces IMO. Ditto if adding more extensions breaks someone that > > expects _zicbom_zicboz that breaks when _zicbop is slid into the middle. > Instead of unknown, could you print "risc-v" or "riscv"? I don't really see how that is better. "riscv" is not the uarch or vendor. If we don't know, we should either say we don't know or omit the field IMO. Cheers, Conor.
On Tue, Jun 27, 2023 at 09:51:05AM +0100, Conor Dooley wrote: > On Tue, Jun 27, 2023 at 01:32:23PM +0530, Sunil V L wrote: > > On Mon, Jun 26, 2023 at 05:16:09PM +0100, Conor Dooley wrote: > > > On Mon, Jun 26, 2023 at 06:05:40PM +0200, Andrew Jones wrote: > > > > On Mon, Jun 26, 2023 at 04:51:29PM +0100, Conor Dooley wrote: > > > > > On Mon, Jun 26, 2023 at 05:14:15PM +0200, Andrew Jones wrote: > > > > > > On Mon, Jun 26, 2023 at 12:19:39PM +0100, Conor Dooley wrote: > > > > > > One of the few things I know does parsing of /proc/cpuinfo is: > > > > > https://github.com/google/cpu_features/blob/main/src/impl_riscv_linux.c > > > > > and that doesn't seem to care about the mmu, but does rely on > > > > > vendor/uarch ordering. > > > > > > > > > > Makes me wonder, does ACPI break things by leaving out uarch/vendor > > > > > fields, if there is something that expects them to exist? We should > > > > > not intentionally break stuff in /proc/cpuinfo, but can't say I feel any > > > > > sympathy for naively parsing it. > > > > > > > > Yes, it would be nice for ACPI to be consistent. I'm not sure what can be > > > > done about that. > > > > > > Print "unknown", until there's a way of passing the info? > > > Speaking of being an eejit, adding new fields to the file would probably > > > break some really naive parsers & quite frankly that sort of thing can > > > keep the pieces IMO. Ditto if adding more extensions breaks someone that > > > expects _zicbom_zicboz that breaks when _zicbop is slid into the middle. > > > Instead of unknown, could you print "risc-v" or "riscv"? > > I don't really see how that is better. "riscv" is not the uarch or > vendor. If we don't know, we should either say we don't know or omit the > field IMO. > Okay. Makes sense. In that case, I prefer to skip. uarch is anyway printed using other ways. Even in DT, this is not printed for generic cpus having compatible string riscv. So, consumers should expect it not being printed. Thanks, Sunil
diff --git a/arch/riscv/kernel/cpu.c b/arch/riscv/kernel/cpu.c index a2fc952318e9..742bb42e7e86 100644 --- a/arch/riscv/kernel/cpu.c +++ b/arch/riscv/kernel/cpu.c @@ -253,13 +253,16 @@ static void print_isa_ext(struct seq_file *f) */ static const char base_riscv_exts[13] = "imafdqcbkjpvh"; -static void print_isa(struct seq_file *f, const char *isa) +static void print_isa(struct seq_file *f) { int i; seq_puts(f, "isa\t\t: "); - /* Print the rv[64/32] part */ - seq_write(f, isa, 4); + if (IS_ENABLED(CONFIG_32BIT)) + seq_write(f, "rv32", 4); + else + seq_write(f, "rv64", 4); + for (i = 0; i < sizeof(base_riscv_exts); i++) { if (__riscv_isa_extension_available(NULL, base_riscv_exts[i] - 'a')) /* Print only enabled the base ISA extensions */ @@ -316,15 +319,14 @@ static int c_show(struct seq_file *m, void *v) unsigned long cpu_id = (unsigned long)v - 1; struct riscv_cpuinfo *ci = per_cpu_ptr(&riscv_cpuinfo, cpu_id); struct device_node *node; - const char *compat, *isa; + const char *compat; seq_printf(m, "processor\t: %lu\n", cpu_id); seq_printf(m, "hart\t\t: %lu\n", cpuid_to_hartid_map(cpu_id)); + print_isa(m); if (acpi_disabled) { node = of_get_cpu_node(cpu_id, NULL); - if (!of_property_read_string(node, "riscv,isa", &isa)) - print_isa(m, isa); print_mmu(m); if (!of_property_read_string(node, "compatible", &compat) && @@ -333,8 +335,6 @@ static int c_show(struct seq_file *m, void *v) of_node_put(node); } else { - if (!acpi_get_riscv_isa(NULL, cpu_id, &isa)) - print_isa(m, isa); print_mmu(m); }