Message ID | 20240213033744.4069020-3-samuel.holland@sifive.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-62912-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:bc8a:b0:106:860b:bbdd with SMTP id dn10csp308597dyb; Mon, 12 Feb 2024 19:38:41 -0800 (PST) X-Google-Smtp-Source: AGHT+IELcNlu6Q3bciZ8mrIbA/tfA4gmkBq3qPBPs/RfD1sCgdvYoFyyYZWWT7cG29pZlozDImAV X-Received: by 2002:aa7:c0c3:0:b0:561:f3af:433b with SMTP id j3-20020aa7c0c3000000b00561f3af433bmr325903edp.16.1707795521129; Mon, 12 Feb 2024 19:38:41 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1707795521; cv=pass; d=google.com; s=arc-20160816; b=UcshieBGBuDCQ1s2CfxLyxqOxeDS7A1Wpj4ShNKc/MQY32fg/Yhx4TOSrAsu9FcrF5 q33hMPkMW93+JuFtwmyrvIYqHC9/YiLrrxJSVUWuK5PX8Fp1YL1DiT+waav6Yg0QLQvk gE9ruNA/ErgLVYmkCbiBCozqoAlGuCwQBSQ+Na9PeYNcVWZFv6xCNuRHjgIthzzrQeER JD5fVcD7N4tZxGxe2XVq4ZiTVvKnMW8JIUIA6SzUNorlU/J3gtolyTqLemk33xKWX8wt twFjE/lpXPmoBnkLg0DrRm29j++ADIKxq4PCI2JIGi8C5gO06cjsW8UmpDsxRq/jXoTh USGg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature; bh=Jim7Yvb6VmY6JIh3NrVmUpVFosXkDK31kcFuWFcbExg=; fh=VFETjARecO7pAKwH4oOJKNAs99G7WDYTwR2+dPzFdjc=; b=ZTjD7vy09hOk/ERu01hj8CmqoaM6BJyhl4OI44t9WQKWZZwyyDQw1J9QSPS/BOP9Y/ Ss+69BQltscBkLgBmk05+mUwIqyuCianq6h8kMgvZEL10lU0EM8QkJWjxjj1vCFUVUhS 6NV3Eo0mqxZa0t6E41Mm6wO6kp4fJ1tCqytE1YE4tzJN218C7VGo8pq1qYXTxF1OTxav ++WrAackn0eEw+CSZNlb+7BFW6r0UgA+KER69JZm1yJjjW5zaU3q7BWPSu+tlXR+B0VW 5OUDY/k/XcehFfQ0U/Zz5Myf+j/4TqCGyvei61hFuamWNnBCJci0dR9xk0/Ufs5+1X3I YABg==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@sifive.com header.s=google header.b=lab23ese; arc=pass (i=1 spf=pass spfdomain=sifive.com dkim=pass dkdomain=sifive.com dmarc=pass fromdomain=sifive.com); spf=pass (google.com: domain of linux-kernel+bounces-62912-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-62912-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=sifive.com X-Forwarded-Encrypted: i=2; AJvYcCWLP4wlH4VQ2XHBgFSQmk3FiFDRnODhOvZy869KT5zWOOM26ykNzeq6I84jeeYx7aMhxI90mWmERckVwWjZq5C3oNF40Q== Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [2604:1380:4601:e00::3]) by mx.google.com with ESMTPS id cm18-20020a0564020c9200b0055ced896819si3447791edb.212.2024.02.12.19.38.40 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Feb 2024 19:38:41 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-62912-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3; Authentication-Results: mx.google.com; dkim=pass header.i=@sifive.com header.s=google header.b=lab23ese; arc=pass (i=1 spf=pass spfdomain=sifive.com dkim=pass dkdomain=sifive.com dmarc=pass fromdomain=sifive.com); spf=pass (google.com: domain of linux-kernel+bounces-62912-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-62912-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=sifive.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id 92E121F22C65 for <ouuuleilei@gmail.com>; Tue, 13 Feb 2024 03:38:40 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 4549910A22; Tue, 13 Feb 2024 03:37:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=sifive.com header.i=@sifive.com header.b="lab23ese" Received: from mail-pf1-f176.google.com (mail-pf1-f176.google.com [209.85.210.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DA1B79479 for <linux-kernel@vger.kernel.org>; Tue, 13 Feb 2024 03:37:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.176 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707795470; cv=none; b=GYoqNNpCWhv9+RvGzasqVEJ19StYBD+r1FjgKYU3ToAABiXlaePe7bYJTmcfXWdr3mhh+rkl75XOc66HtHKBtMdXxkXcrpxED/Uz3jBzbE4KqP9OYWAqcCiaTE6gWtVPfWYgYhkfHF57UDb3FteROVbwrwdzlVXm6aN9T1N/aw4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707795470; c=relaxed/simple; bh=8pIhNYnxLRa/X2tsQjOh7P2wqEz3w33s57I1KemeK24=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=OzHCynYHYgdr1EfdePCOKtGHFMdRHFUOLFHLC+bWVc33ahz/1Cpxh8eZvL3tOD8s0D5maz35ug0KamubCrlNK5lIQHKR4kS4hPeF6AAPlPxr9amAdY9S6VCiItnlfumRef/sHi3Efjq03q8LPZVXn0l3tj2CrZhxQuQiFE9izbU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=sifive.com; spf=pass smtp.mailfrom=sifive.com; dkim=pass (2048-bit key) header.d=sifive.com header.i=@sifive.com header.b=lab23ese; arc=none smtp.client-ip=209.85.210.176 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=sifive.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=sifive.com Received: by mail-pf1-f176.google.com with SMTP id d2e1a72fcca58-6e0ac91e1e9so1435785b3a.3 for <linux-kernel@vger.kernel.org>; Mon, 12 Feb 2024 19:37:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; t=1707795468; x=1708400268; darn=vger.kernel.org; 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=Jim7Yvb6VmY6JIh3NrVmUpVFosXkDK31kcFuWFcbExg=; b=lab23esePh3NDeXbEI7/zXxRWu9K4hd3w4hojzCmQKAp4sN4dUe8Tzdl+oXym0ZwQz 4v1kmmOXJXnABk/XZunIETPquj4uW4PaQwghKoQhtzAD3LBPD51Vd1esed4j3PARXtDv IIGeVDMOcAZz94s+6h7pnltOS6D+wXIsZh3o2M6i23mHykDkkakfzHJO5clp0+ZQ1+0W n5dzVy+ExteTrHHgXbTM4larYUecoBIbSBJDvHRiQu4bZehVD2qJdb30ovN88pbNeHXr TEHfmYvleoAYhwrJq4LzPpaMHNRb3iDdVVegINQ5xHNn6uzAAVgJs7rRmNXcoqFzlyEk z58Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707795468; x=1708400268; 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=Jim7Yvb6VmY6JIh3NrVmUpVFosXkDK31kcFuWFcbExg=; b=uY1yOtPWVuXwcTRtIpFH60Z55yQeDQ6grbcVBeOvzY39e3HLXVO78gkw6kCWnLVM+d NKxlgWnBpxWz5TC9nWqySYdgjtXEhdbLwn8eYtM+6Ej4NSZGw2Rbb9+dEbEVbD7vJac3 RLYHWib/57tLxc3QVFEzGxQVHJHS1TjrPhX/AQM6otz0Gl82kLvRoO9FzjwltJdOq7U2 hILoEqitandbd1xMaaNYyieQYPc5QQkrmTQ9xVIyP76FCjlKWZqCyP/3ahqMAgndfeEN CiakWQtI02ZcybBYeMDtXj3Q2ZJTPQ7g2dcWjOxzTLC7SLAjETGLttwqXG+tOo+0SbzV fRXA== X-Gm-Message-State: AOJu0YxUkgoFQbNbiTJlOPZbx5scVmJZC+gQhaY158r5dcewg6ki+5fI 844yJFwo1IRjkdwAjPNQ0ytZge+nfQXAc0VIaiDBhJ76/fuwnsHmqh5Y416pUcc= X-Received: by 2002:aa7:8685:0:b0:6e0:5317:6772 with SMTP id d5-20020aa78685000000b006e053176772mr6713708pfo.1.1707795468162; Mon, 12 Feb 2024 19:37:48 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCUtDxXelkbmm+CM8OLoo8WM4giaZcxrKGw5FC1up94u0V6jYFdJloVUPvWRQ0Omxq/n9YRlGpQXAYGpmEIR7+klWd8162GgnV8tbjfr9NG9RNhsxttq1+vCK9foEoC0wKl6LWJ+VJ9OhaR6eZRwNvpqxF3p8xEUSYrb8ksnc2H07sCCYQfJvwH5l0u3YCp2Z9mi1xR2N69GDslZW7YF Received: from sw06.internal.sifive.com ([4.53.31.132]) by smtp.gmail.com with ESMTPSA id v11-20020a056a00148b00b006e0334e3dd9sm6188633pfu.76.2024.02.12.19.37.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Feb 2024 19:37:47 -0800 (PST) From: Samuel Holland <samuel.holland@sifive.com> To: Palmer Dabbelt <palmer@dabbelt.com> Cc: Andrew Jones <ajones@ventanamicro.com>, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, Stefan O'Rear <sorear@fastmail.com>, Samuel Holland <samuel.holland@sifive.com> Subject: [PATCH -fixes v2 2/4] dt-bindings: riscv: Add ratified privileged ISA versions Date: Mon, 12 Feb 2024 19:37:33 -0800 Message-ID: <20240213033744.4069020-3-samuel.holland@sifive.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240213033744.4069020-1-samuel.holland@sifive.com> References: <20240213033744.4069020-1-samuel.holland@sifive.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1790753396602399323 X-GMAIL-MSGID: 1790753396602399323 |
Series |
riscv: cbo.zero fixes
|
|
Commit Message
Samuel Holland
Feb. 13, 2024, 3:37 a.m. UTC
The baseline for the RISC-V privileged ISA is version 1.10. Using
features from newer versions of the privileged ISA requires the
supported version to be reported by platform firmware, either in the ISA
string (where the binding already accepts version numbers) or in the
riscv,isa-extensions property. So far two newer versions are ratified.
Signed-off-by: Samuel Holland <samuel.holland@sifive.com>
---
Changes in v2:
- New patch for v2
.../devicetree/bindings/riscv/extensions.yaml | 20 +++++++++++++++++++
1 file changed, 20 insertions(+)
Comments
On 13/02/2024 04:37, Samuel Holland wrote: > The baseline for the RISC-V privileged ISA is version 1.10. Using > features from newer versions of the privileged ISA requires the > supported version to be reported by platform firmware, either in the ISA > string (where the binding already accepts version numbers) or in the > riscv,isa-extensions property. So far two newer versions are ratified. > > Signed-off-by: Samuel Holland <samuel.holland@sifive.com> > --- Please Cc DT list. Standard disclaimer: Please use scripts/get_maintainers.pl to get a list of necessary people and lists to CC. It might happen, that command when run on an older kernel, gives you outdated entries. Therefore please be sure you base your patches on recent Linux kernel. Tools like b4 or scripts/get_maintainer.pl provide you proper list of people, so fix your workflow. Tools might also fail if you work on some ancient tree (don't, instead use mainline), work on fork of kernel (don't, instead use mainline) or you ignore some maintainers (really don't). Just use b4 and everything should be fine, although remember about `b4 prep --auto-to-cc` if you added new patches to the patchset. You missed at least devicetree list (maybe more), so this won't be tested by automated tooling. Please kindly resend and include all necessary To/Cc entries. Best regards, Krzysztof
On Mon, Feb 12, 2024 at 07:37:33PM -0800, Samuel Holland wrote: > The baseline for the RISC-V privileged ISA is version 1.10. Using > features from newer versions of the privileged ISA requires the > supported version to be reported by platform firmware, either in the ISA > string (where the binding already accepts version numbers) or in the > riscv,isa-extensions property. So far two newer versions are ratified. > > Signed-off-by: Samuel Holland <samuel.holland@sifive.com> > --- > > Changes in v2: > - New patch for v2 > > .../devicetree/bindings/riscv/extensions.yaml | 20 +++++++++++++++++++ > 1 file changed, 20 insertions(+) > > diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml > index 63d81dc895e5..7faf22df01af 100644 > --- a/Documentation/devicetree/bindings/riscv/extensions.yaml > +++ b/Documentation/devicetree/bindings/riscv/extensions.yaml > @@ -121,6 +121,16 @@ properties: > version of the privileged ISA specification. > > # multi-letter extensions, sorted alphanumerically > + - const: sm1p11 > + description: > + The standard Machine ISA v1.11, as ratified in the 20190608 > + version of the privileged ISA specification. > + > + - const: sm1p12 > + description: > + The standard Machine ISA v1.12, as ratified in the 20211203 > + version of the privileged ISA specification. > + > - const: smaia > description: | > The standard Smaia supervisor-level extension for the advanced > @@ -134,6 +144,16 @@ properties: > added by other RISC-V extensions in H/S/VS/U/VU modes and as > ratified at commit a28bfae (Ratified (#7)) of riscv-state-enable. > > + - const: ss1p11 > + description: > + The standard Supervisor ISA v1.11, as ratified in the 20190608 > + version of the privileged ISA specification. > + > + - const: ss1p12 > + description: > + The standard Supervisor ISA v1.12, as ratified in the 20211203 > + version of the privileged ISA specification. > + > - const: ssaia > description: | > The standard Ssaia supervisor-level extension for the advanced > -- > 2.43.0 > Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Note, QEMU doesn't add these extensions to the ISA string yet, but I think it should start, particularly the profile CPU types which should ensure all the profile's mandatory extensions are added to the ISA string in order to avoid any confusion. Thanks, drew
On Mon, Feb 12, 2024 at 07:37:33PM -0800, Samuel Holland wrote: > The baseline for the RISC-V privileged ISA is version 1.10. Using > features from newer versions of the privileged ISA requires the > supported version to be reported by platform firmware, either in the ISA > string (where the binding already accepts version numbers) or in the > riscv,isa-extensions property. So far two newer versions are ratified. > > Signed-off-by: Samuel Holland <samuel.holland@sifive.com> > --- > > Changes in v2: > - New patch for v2 > > .../devicetree/bindings/riscv/extensions.yaml | 20 +++++++++++++++++++ > 1 file changed, 20 insertions(+) > > diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml > index 63d81dc895e5..7faf22df01af 100644 > --- a/Documentation/devicetree/bindings/riscv/extensions.yaml > +++ b/Documentation/devicetree/bindings/riscv/extensions.yaml > @@ -121,6 +121,16 @@ properties: > version of the privileged ISA specification. > > # multi-letter extensions, sorted alphanumerically > + - const: sm1p11 Why are we beholden to this "1p11" format of RVI's? We have free choice of characters here, what's stopping us using "machine-v1.11", for example? Thanks, Conor. > + description: > + The standard Machine ISA v1.11, as ratified in the 20190608 > + version of the privileged ISA specification. > + > + - const: sm1p12 > + description: > + The standard Machine ISA v1.12, as ratified in the 20211203 > + version of the privileged ISA specification. > + > - const: smaia > description: | > The standard Smaia supervisor-level extension for the advanced > @@ -134,6 +144,16 @@ properties: > added by other RISC-V extensions in H/S/VS/U/VU modes and as > ratified at commit a28bfae (Ratified (#7)) of riscv-state-enable. > > + - const: ss1p11 > + description: > + The standard Supervisor ISA v1.11, as ratified in the 20190608 > + version of the privileged ISA specification. > + > + - const: ss1p12 > + description: > + The standard Supervisor ISA v1.12, as ratified in the 20211203 > + version of the privileged ISA specification. > + > - const: ssaia > description: | > The standard Ssaia supervisor-level extension for the advanced > -- > 2.43.0 > > > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv
On Tue, Feb 13, 2024 at 05:03:46PM +0000, Conor Dooley wrote: > On Mon, Feb 12, 2024 at 07:37:33PM -0800, Samuel Holland wrote: > > The baseline for the RISC-V privileged ISA is version 1.10. Using > > features from newer versions of the privileged ISA requires the > > supported version to be reported by platform firmware, either in the ISA > > string (where the binding already accepts version numbers) or in the > > riscv,isa-extensions property. So far two newer versions are ratified. > > > > Signed-off-by: Samuel Holland <samuel.holland@sifive.com> > > --- > > > > Changes in v2: > > - New patch for v2 > > > > .../devicetree/bindings/riscv/extensions.yaml | 20 +++++++++++++++++++ > > 1 file changed, 20 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml > > index 63d81dc895e5..7faf22df01af 100644 > > --- a/Documentation/devicetree/bindings/riscv/extensions.yaml > > +++ b/Documentation/devicetree/bindings/riscv/extensions.yaml > > @@ -121,6 +121,16 @@ properties: > > version of the privileged ISA specification. > > > > # multi-letter extensions, sorted alphanumerically > > > + - const: sm1p11 > > Why are we beholden to this "1p11" format of RVI's? We have free choice > of characters here, what's stopping us using "machine-v1.11", for > example? We could also choose to communicate this using a specific property, but I have not really thought that one through yet.
On Tue, Feb 13, 2024, at 12:03 PM, Conor Dooley wrote: > On Mon, Feb 12, 2024 at 07:37:33PM -0800, Samuel Holland wrote: >> The baseline for the RISC-V privileged ISA is version 1.10. Using >> features from newer versions of the privileged ISA requires the >> supported version to be reported by platform firmware, either in the ISA >> string (where the binding already accepts version numbers) or in the >> riscv,isa-extensions property. So far two newer versions are ratified. >> >> Signed-off-by: Samuel Holland <samuel.holland@sifive.com> >> --- >> >> Changes in v2: >> - New patch for v2 >> >> .../devicetree/bindings/riscv/extensions.yaml | 20 +++++++++++++++++++ >> 1 file changed, 20 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml >> index 63d81dc895e5..7faf22df01af 100644 >> --- a/Documentation/devicetree/bindings/riscv/extensions.yaml >> +++ b/Documentation/devicetree/bindings/riscv/extensions.yaml >> @@ -121,6 +121,16 @@ properties: >> version of the privileged ISA specification. >> >> # multi-letter extensions, sorted alphanumerically > >> + - const: sm1p11 > > Why are we beholden to this "1p11" format of RVI's? We have free choice > of characters here, what's stopping us using "machine-v1.11", for > example? > > Thanks, > Conor. I'd prefer to use names that are at least somewhat recognizable, e.g. in the profiles spec, rather than making up something from whole cloth. -s > >> + description: >> + The standard Machine ISA v1.11, as ratified in the 20190608 >> + version of the privileged ISA specification. >> + >> + - const: sm1p12 >> + description: >> + The standard Machine ISA v1.12, as ratified in the 20211203 >> + version of the privileged ISA specification. >> + >> - const: smaia >> description: | >> The standard Smaia supervisor-level extension for the advanced >> @@ -134,6 +144,16 @@ properties: >> added by other RISC-V extensions in H/S/VS/U/VU modes and as >> ratified at commit a28bfae (Ratified (#7)) of riscv-state-enable. >> >> + - const: ss1p11 >> + description: >> + The standard Supervisor ISA v1.11, as ratified in the 20190608 >> + version of the privileged ISA specification. >> + >> + - const: ss1p12 >> + description: >> + The standard Supervisor ISA v1.12, as ratified in the 20211203 >> + version of the privileged ISA specification. >> + >> - const: ssaia >> description: | >> The standard Ssaia supervisor-level extension for the advanced >> -- >> 2.43.0 >> >> >> _______________________________________________ >> linux-riscv mailing list >> linux-riscv@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-riscv > > Attachments: > * signature.asc
On 2024-02-13 11:42 AM, Stefan O'Rear wrote: > On Tue, Feb 13, 2024, at 12:03 PM, Conor Dooley wrote: >> On Mon, Feb 12, 2024 at 07:37:33PM -0800, Samuel Holland wrote: >>> The baseline for the RISC-V privileged ISA is version 1.10. Using >>> features from newer versions of the privileged ISA requires the >>> supported version to be reported by platform firmware, either in the ISA >>> string (where the binding already accepts version numbers) or in the >>> riscv,isa-extensions property. So far two newer versions are ratified. >>> >>> Signed-off-by: Samuel Holland <samuel.holland@sifive.com> >>> --- >>> >>> Changes in v2: >>> - New patch for v2 >>> >>> .../devicetree/bindings/riscv/extensions.yaml | 20 +++++++++++++++++++ >>> 1 file changed, 20 insertions(+) >>> >>> diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml >>> index 63d81dc895e5..7faf22df01af 100644 >>> --- a/Documentation/devicetree/bindings/riscv/extensions.yaml >>> +++ b/Documentation/devicetree/bindings/riscv/extensions.yaml >>> @@ -121,6 +121,16 @@ properties: >>> version of the privileged ISA specification. >>> >>> # multi-letter extensions, sorted alphanumerically >> >>> + - const: sm1p11 >> >> Why are we beholden to this "1p11" format of RVI's? We have free choice >> of characters here, what's stopping us using "machine-v1.11", for >> example? > > I'd prefer to use names that are at least somewhat recognizable, e.g. in > the profiles spec, rather than making up something from whole cloth. Right, exactly. My two immediate reasons for choosing this are: 1) this is the exact name used in the profiles[1][2], and 2) the same list of extensions is used for the riscv,isa-extensions property and the ISA string, and this is the expected format for the ISA string. If we want invent something brand new for the DT binding (which I'm not sure we do), then I would recommend adding a property like riscv,privileged-isa-version, because that removes the duplication between the Sm and Ss extensions (since almost all implementations would have both). On the other hand, there will likely be other extensions in the future that need version numbers in riscv,isa-extensions. Adding a special case for the privileged ISA doesn't help with this, whereas deciding on a syntax for version numbers in the extension name does. Regards, Samuel [1]: https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc#rva20s64-mandatory-extensions [2]: https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc#rva22s64-mandatory-extensions
On Tue, Feb 13, 2024 at 03:25:44PM +0100, Andrew Jones wrote: > On Mon, Feb 12, 2024 at 07:37:33PM -0800, Samuel Holland wrote: > Note, QEMU doesn't add these extensions to the ISA string yet, but I think > it should start, particularly the profile CPU types which should ensure > all the profile's mandatory extensions are added to the ISA string in > order to avoid any confusion. Something to note about these "mandatory extensions" that are names for things we already assumed were present - they're utterly useless and any DT property should note their absence, not presence, in order to be of any use. Anything parsing a DT cannot see "svbare" and gain any new information, since the lack of it could be something that predates the definition of "svbare" or something without "svbare". Shit, but that's exactly why I deprecated riscv,isa. Cheers, Conor.
On Thu, Feb 15, 2024, at 8:14 AM, Conor Dooley wrote: > On Tue, Feb 13, 2024 at 03:25:44PM +0100, Andrew Jones wrote: >> On Mon, Feb 12, 2024 at 07:37:33PM -0800, Samuel Holland wrote: > >> Note, QEMU doesn't add these extensions to the ISA string yet, but I think >> it should start, particularly the profile CPU types which should ensure >> all the profile's mandatory extensions are added to the ISA string in >> order to avoid any confusion. > > Something to note about these "mandatory extensions" that are names for > things we already assumed were present - they're utterly useless and any > DT property should note their absence, not presence, in order to be of any > use. Anything parsing a DT cannot see "svbare" and gain any new > information, since the lack of it could be something that predates the > definition of "svbare" or something without "svbare". This is consistent with the way we handle other extensions that are assumed at compile time - if you build with RISCV_ISA_C=y, omitting "c" from riscv,isa-extensions will not cause an error. It's also the case for any extension whatsoever that if that extension is not present in the device tree, no information is provided. It might be useful for diagnostic purposes to have a "binding version" somewhere to indicate which extensions _would_ be documented; not sure if there is already a mechanism for this. For extensions that the kernel has a hard requirement on like svbare, see above. > Shit, but that's exactly why I deprecated riscv,isa. If zicsr and zifencei were broken out from i today, there would not be a problem, because i as specified by riscv,isa-extensions would refer to a specific version that included zicsr and zifencei with a new name for the new, smaller version of i. It's not working here because privileged architecture versions aren't (yet) included in riscv,isa-extensions. -s > Cheers, > Conor. > > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv > > Attachments: > * signature.asc
diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml index 63d81dc895e5..7faf22df01af 100644 --- a/Documentation/devicetree/bindings/riscv/extensions.yaml +++ b/Documentation/devicetree/bindings/riscv/extensions.yaml @@ -121,6 +121,16 @@ properties: version of the privileged ISA specification. # multi-letter extensions, sorted alphanumerically + - const: sm1p11 + description: + The standard Machine ISA v1.11, as ratified in the 20190608 + version of the privileged ISA specification. + + - const: sm1p12 + description: + The standard Machine ISA v1.12, as ratified in the 20211203 + version of the privileged ISA specification. + - const: smaia description: | The standard Smaia supervisor-level extension for the advanced @@ -134,6 +144,16 @@ properties: added by other RISC-V extensions in H/S/VS/U/VU modes and as ratified at commit a28bfae (Ratified (#7)) of riscv-state-enable. + - const: ss1p11 + description: + The standard Supervisor ISA v1.11, as ratified in the 20190608 + version of the privileged ISA specification. + + - const: ss1p12 + description: + The standard Supervisor ISA v1.12, as ratified in the 20211203 + version of the privileged ISA specification. + - const: ssaia description: | The standard Ssaia supervisor-level extension for the advanced