Received-SPF: pass (google.com: domain of linux-kernel+bounces-213758-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Date: Thu, 13 Jun 2024 10:37:19 -0700
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
Message-ID: <ZmsuTyVcxelGvGw+@ghost>
References: <20240609-support_vendor_extensions-v2-0-9a43f1fdcbb9@rivosinc.com>
 <20240613-deepness-refried-c6dea811f6f6@spud>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
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