All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Jones <ajones@ventanamicro.com>
To: Charlie Jenkins <charlie@rivosinc.com>
Cc: Paul Walmsley <paul.walmsley@sifive.com>,
	 Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	 Conor Dooley <conor.dooley@microchip.com>,
	Evan Green <evan@rivosinc.com>, Andy Chiu <andy.chiu@sifive.com>,
	 linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
	 Yu Chien Peter Lin <peterlin@andestech.com>
Subject: Re: [PATCH v3 0/4] riscv: Separate vendor extensions from standard extensions
Date: Mon, 22 Jul 2024 14:32:49 -0500	[thread overview]
Message-ID: <20240722-0c2488245ce33131693c6d34@orel> (raw)
In-Reply-To: <20240719-support_vendor_extensions-v3-0-0af7587bbec0@rivosinc.com>

On Fri, Jul 19, 2024 at 09:15:17AM GMT, Charlie Jenkins wrote:
> All extensions, both standard and vendor, live in one struct
> "riscv_isa_ext". There is currently one vendor extension, xandespmu, but
> it is likely that more vendor extensions will be added to the kernel in
> the future. As more vendor extensions (and standard extensions) are
> added, riscv_isa_ext will become more bloated with a mix of vendor and
> standard extensions.

But the mix doesn't hurt and with everything in one place it makes it easy
to know where to look.

> 
> This also allows each vendor to be conditionally enabled through
> Kconfig.

We can do that anyway by adding an extension menu for each vendor. If we
don't want a vendor's extensions bloating the array then we just need
some #ifdefs, e.g.

@@ -405,7 +405,9 @@ const struct riscv_isa_ext_data riscv_isa_ext[] = {
        __RISCV_ISA_EXT_DATA(svinval, RISCV_ISA_EXT_SVINVAL),
        __RISCV_ISA_EXT_DATA(svnapot, RISCV_ISA_EXT_SVNAPOT),
        __RISCV_ISA_EXT_DATA(svpbmt, RISCV_ISA_EXT_SVPBMT),
+#ifdef RISCV_ISA_VENDOR_EXT_ANDES
        __RISCV_ISA_EXT_DATA(xandespmu, RISCV_ISA_EXT_XANDESPMU),
+#endif
 };


So, I'm not convinced we want the additional complexity of vendor
extension arrays, but maybe I'm missing something.

Thanks,
drew

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

WARNING: multiple messages have this Message-ID (diff)
From: Andrew Jones <ajones@ventanamicro.com>
To: Charlie Jenkins <charlie@rivosinc.com>
Cc: Paul Walmsley <paul.walmsley@sifive.com>,
	 Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	 Conor Dooley <conor.dooley@microchip.com>,
	Evan Green <evan@rivosinc.com>, Andy Chiu <andy.chiu@sifive.com>,
	 linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
	 Yu Chien Peter Lin <peterlin@andestech.com>
Subject: Re: [PATCH v3 0/4] riscv: Separate vendor extensions from standard extensions
Date: Mon, 22 Jul 2024 14:32:49 -0500	[thread overview]
Message-ID: <20240722-0c2488245ce33131693c6d34@orel> (raw)
In-Reply-To: <20240719-support_vendor_extensions-v3-0-0af7587bbec0@rivosinc.com>

On Fri, Jul 19, 2024 at 09:15:17AM GMT, Charlie Jenkins wrote:
> All extensions, both standard and vendor, live in one struct
> "riscv_isa_ext". There is currently one vendor extension, xandespmu, but
> it is likely that more vendor extensions will be added to the kernel in
> the future. As more vendor extensions (and standard extensions) are
> added, riscv_isa_ext will become more bloated with a mix of vendor and
> standard extensions.

But the mix doesn't hurt and with everything in one place it makes it easy
to know where to look.

> 
> This also allows each vendor to be conditionally enabled through
> Kconfig.

We can do that anyway by adding an extension menu for each vendor. If we
don't want a vendor's extensions bloating the array then we just need
some #ifdefs, e.g.

@@ -405,7 +405,9 @@ const struct riscv_isa_ext_data riscv_isa_ext[] = {
        __RISCV_ISA_EXT_DATA(svinval, RISCV_ISA_EXT_SVINVAL),
        __RISCV_ISA_EXT_DATA(svnapot, RISCV_ISA_EXT_SVNAPOT),
        __RISCV_ISA_EXT_DATA(svpbmt, RISCV_ISA_EXT_SVPBMT),
+#ifdef RISCV_ISA_VENDOR_EXT_ANDES
        __RISCV_ISA_EXT_DATA(xandespmu, RISCV_ISA_EXT_XANDESPMU),
+#endif
 };


So, I'm not convinced we want the additional complexity of vendor
extension arrays, but maybe I'm missing something.

Thanks,
drew

  parent reply	other threads:[~2024-07-22 19:32 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-19 16:15 [PATCH v3 0/4] riscv: Separate vendor extensions from standard extensions Charlie Jenkins
2024-07-19 16:15 ` Charlie Jenkins
2024-07-19 16:15 ` [PATCH v3 1/4] riscv: Extend cpufeature.c to detect vendor extensions Charlie Jenkins
2024-07-19 16:15   ` Charlie Jenkins
2024-07-19 16:15 ` [PATCH v3 2/4] riscv: Add vendor extensions to /proc/cpuinfo Charlie Jenkins
2024-07-19 16:15   ` Charlie Jenkins
2024-07-19 16:15 ` [PATCH v3 3/4] riscv: Introduce vendor variants of extension helpers Charlie Jenkins
2024-07-19 16:15   ` Charlie Jenkins
2024-07-19 16:15 ` [PATCH v3 4/4] riscv: cpufeature: Extract common elements from extension checking Charlie Jenkins
2024-07-19 16:15   ` Charlie Jenkins
2024-07-22 19:32 ` Andrew Jones [this message]
2024-07-22 19:32   ` [PATCH v3 0/4] riscv: Separate vendor extensions from standard extensions Andrew Jones
2024-07-22 20:23   ` Charlie Jenkins
2024-07-22 20:23     ` Charlie Jenkins
2024-07-22 23:45     ` Palmer Dabbelt
2024-07-22 23:45       ` Palmer Dabbelt
2024-07-23 12:58 ` patchwork-bot+linux-riscv
2024-07-23 12:58   ` patchwork-bot+linux-riscv

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=20240722-0c2488245ce33131693c6d34@orel \
    --to=ajones@ventanamicro.com \
    --cc=andy.chiu@sifive.com \
    --cc=aou@eecs.berkeley.edu \
    --cc=charlie@rivosinc.com \
    --cc=conor.dooley@microchip.com \
    --cc=evan@rivosinc.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=peterlin@andestech.com \
    /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.