Received-SPF: pass (google.com: domain of linux-kernel+bounces-180464-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Date: Wed, 15 May 2024 16:08:17 -0700
From: Charlie Jenkins <charlie@rivosinc.com>
To: Jessica Clarke <jrtc27@jrtc27.com>
Cc: Conor Dooley <conor@kernel.org>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Palmer Dabbelt <palmer@sifive.com>,
	linux-riscv <linux-riscv@lists.infradead.org>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" <devicetree@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Conor Dooley <conor.dooley@microchip.com>
Subject: Re: [PATCH 0/2] riscv: Allow vlenb to be probed from DT
Message-ID: <ZkVAYeNnvj99YHXt@ghost>
References: <20240515-add_vlenb_to_dt-v1-0-4ebd7cba0aa1@rivosinc.com>
 <A9EDD470-B8EC-4644-82A0-7444729EF885@jrtc27.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <A9EDD470-B8EC-4644-82A0-7444729EF885@jrtc27.com>

On Wed, May 15, 2024 at 11:25:16PM +0100, Jessica Clarke wrote:
> On 15 May 2024, at 22:50, Charlie Jenkins <charlie@rivosinc.com> wrote:
> > 
> > The kernel currently requires all harts to have the same value in the
> > vlenb csr that is present when a hart supports vector. In order to read
> > this csr, the kernel needs to boot the hart. Adding vlenb to the DT will
> > allow the kernel to detect the inconsistency early and not waste time
> > trying to boot harts that it doesn't support.
> 
> That doesn’t seem sufficient justification to me. If it can be read
> from the hardware, why should we have to put it in the FDT? The whole
> point of the FDT is to communicate the hardware configuration that
> isn’t otherwise discoverable.

Yes you are correct in that vlenb is discoverable on any conforming
chip. However, the motivation here is for making decisions about how to
boot a hart before it is booted. By placing it in the device tree, we
are able to disable vector before the chip is booted instead of trying
to boot the chip with vector enabled only to disable it later. In both
cases when there is different vlenb on different harts, all harts still
boot and the outcome is that vector is disabled. The difference is that
with the DT entry, no vector setup code needs to be ran on a booting
hart when the outcome will be that vector is not enabled.

> 
> As for T-HEAD stuff, if they need it they can have a custom property.
> Though naively I’d assume there’s a way to avoid it still...

T-Head does not expose vlenb on all of their chips so I do not know of
any other way of getting the vlenb without having it be provided in a
DT. That was the motivation for this patch in the first place, but
making this available to all vendors allows optimizations to happen
during boot.

- Charlie

> 
> Jess
>