All of lore.kernel.org
 help / color / mirror / Atom feed
From: Charlie Jenkins <charlie@rivosinc.com>
To: Conor Dooley <conor@kernel.org>
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
Subject: Re: [PATCH v2 0/4] riscv: Separate vendor extensions from standard extensions
Date: Thu, 13 Jun 2024 10:37:19 -0700	[thread overview]
Message-ID: <ZmsuTyVcxelGvGw+@ghost> (raw)
In-Reply-To: <20240613-deepness-refried-c6dea811f6f6@spud>

On Thu, Jun 13, 2024 at 03:45:33PM +0100, Conor Dooley wrote:
> On Sun, Jun 09, 2024 at 09:34:13PM -0700, 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.
> > 
> > This also allows each vendor to be conditionally enabled through
> > Kconfig.
> > 
> > ---
> > This has been split out from the previous series that contained the
> > addition of xtheadvector due to lack of reviews. The xtheadvector
> > support will be posted again separately from this.
> 
> I think that's a good call.
> 
> > The reviewed-bys on "riscv: Extend cpufeature.c to detect vendor extensions"
> > and "riscv: Introduce vendor variants of extension helpers" have been
> > dropped in this series. The majority of the code is the same in these
> > patches, but thead-specific code is swapped out with andes-specific
> > code. The changes are minimal, but I decided to drop the reviews in case
> > I inadvertently introduced issues.
> 
> Actually, you only completely did that on the first of the two patches
> you mention, but I don't mind.

You reviewed the third patch of this series in the first revision of
this series and I should have updated this comment.

- Charlie


_______________________________________________
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: Charlie Jenkins <charlie@rivosinc.com>
To: Conor Dooley <conor@kernel.org>
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
Subject: Re: [PATCH v2 0/4] riscv: Separate vendor extensions from standard extensions
Date: Thu, 13 Jun 2024 10:37:19 -0700	[thread overview]
Message-ID: <ZmsuTyVcxelGvGw+@ghost> (raw)
In-Reply-To: <20240613-deepness-refried-c6dea811f6f6@spud>

On Thu, Jun 13, 2024 at 03:45:33PM +0100, Conor Dooley wrote:
> On Sun, Jun 09, 2024 at 09:34:13PM -0700, 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.
> > 
> > This also allows each vendor to be conditionally enabled through
> > Kconfig.
> > 
> > ---
> > This has been split out from the previous series that contained the
> > addition of xtheadvector due to lack of reviews. The xtheadvector
> > support will be posted again separately from this.
> 
> I think that's a good call.
> 
> > The reviewed-bys on "riscv: Extend cpufeature.c to detect vendor extensions"
> > and "riscv: Introduce vendor variants of extension helpers" have been
> > dropped in this series. The majority of the code is the same in these
> > patches, but thead-specific code is swapped out with andes-specific
> > code. The changes are minimal, but I decided to drop the reviews in case
> > I inadvertently introduced issues.
> 
> Actually, you only completely did that on the first of the two patches
> you mention, but I don't mind.

You reviewed the third patch of this series in the first revision of
this series and I should have updated this comment.

- Charlie


  reply	other threads:[~2024-06-13 17:37 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-10  4:34 [PATCH v2 0/4] riscv: Separate vendor extensions from standard extensions Charlie Jenkins
2024-06-10  4:34 ` Charlie Jenkins
2024-06-10  4:34 ` [PATCH v2 1/4] riscv: Extend cpufeature.c to detect vendor extensions Charlie Jenkins
2024-06-10  4:34   ` Charlie Jenkins
2024-06-13 14:44   ` Conor Dooley
2024-06-13 14:44     ` Conor Dooley
2024-06-21  7:37   ` Andy Chiu
2024-06-21  7:37     ` Andy Chiu
2024-07-02  9:54   ` Yu-Chien Peter Lin
2024-07-02  9:54     ` Yu-Chien Peter Lin
2024-06-10  4:34 ` [PATCH v2 2/4] riscv: Add vendor extensions to /proc/cpuinfo Charlie Jenkins
2024-06-10  4:34   ` Charlie Jenkins
2024-06-10  4:34 ` [PATCH v2 3/4] riscv: Introduce vendor variants of extension helpers Charlie Jenkins
2024-06-10  4:34   ` Charlie Jenkins
2024-06-21  8:37   ` Andy Chiu
2024-06-21  8:37     ` Andy Chiu
2024-06-10  4:34 ` [PATCH v2 4/4] riscv: cpufeature: Extract common elements from extension checking Charlie Jenkins
2024-06-10  4:34   ` Charlie Jenkins
2024-06-21  8:38   ` Andy Chiu
2024-06-21  8:38     ` Andy Chiu
2024-06-13 14:45 ` [PATCH v2 0/4] riscv: Separate vendor extensions from standard extensions Conor Dooley
2024-06-13 14:45   ` Conor Dooley
2024-06-13 17:37   ` Charlie Jenkins [this message]
2024-06-13 17:37     ` Charlie Jenkins

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=ZmsuTyVcxelGvGw+@ghost \
    --to=charlie@rivosinc.com \
    --cc=andy.chiu@sifive.com \
    --cc=aou@eecs.berkeley.edu \
    --cc=conor.dooley@microchip.com \
    --cc=conor@kernel.org \
    --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 \
    /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.