Received: by 2002:a05:6358:9144:b0:117:f937:c515 with SMTP id r4csp4563208rwr; Mon, 8 May 2023 09:20:34 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7bJhSv6CsBOuRmXmjBhOGd7nrfgaZuKtrBaRO4wOW+XrpHbaquMMe/+C3XVdntV89MVjRs X-Received: by 2002:a05:6a00:2e94:b0:641:3fa1:bf7f with SMTP id fd20-20020a056a002e9400b006413fa1bf7fmr16045946pfb.20.1683562834021; Mon, 08 May 2023 09:20:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1683562834; cv=none; d=google.com; s=arc-20160816; b=efpS89xv5SJziBxTVlpbyCtNm8POaiBPn4IBVipNhX4vcHaLAVTy3xsI2hnhdSSSK2 CBgcU/sVBtT1rhE6wa6PCGuiwjDLYr1bVy2A5lHWrV5B6ai5IhEwosdMuHGIQmHLes+E ZmnEEAJfSSLBu3FRoSR648mV8y5ijF6tGAwBKxWWm5ULFC0cJ12yplvbZXDXFpKXEb/3 vbg7TO4RebncziAQRuotxU7q0qZLxTjV3gwPU0N1wJf+q9mhq11NX1wVf51XwoPLu1ml IXX0+k9DXlWjgGiYyGpDQBu+1p8O4lzMU99u5ual40JJFiWP9+CMz3hI570CQdcYs5kg OEVw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=A7PNWKjPp5vdOnPtTwejCh20ufHJfGIhgchS2cBSj3E=; b=lCtL1TV6Q1OghZlCaXp49LQOW+R3gDylYJ2tSt+ijo7yYaIiSWXrmP1Nc224YPLU0H gFPC9P5w3+PUfd3L9YcfTodh0WDLXtz/jWKEddREnPT1MSZamuOf6FSXACU0oYz77NdQ F9ycGqmVbJt0P2usaAIYgpTdMO7QVT1AjRqQAYXzOUQzFX7zqtxZu3Usw2srrI3U2JJB 45LW02uVbz06cVJQYKsA9wfZgRrTTlm9S2jQPKaCoirxVmIJKIlEe3n+dngwGTpgv3h+ TCbr/Aqcax7vXS6a4TJgZZ5Q8JwxUVHiH5Q5n5XAoISQJP0gaxZ2Q5OnT1JlbXDtj8B8 o31w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=sntech.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id d1-20020a621d01000000b00645e8c9e27esi184233pfd.386.2023.05.08.09.20.19; Mon, 08 May 2023 09:20:33 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=sntech.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234093AbjEHP4P convert rfc822-to-8bit (ORCPT + 99 others); Mon, 8 May 2023 11:56:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38078 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229523AbjEHP4O (ORCPT ); Mon, 8 May 2023 11:56:14 -0400 Received: from gloria.sntech.de (gloria.sntech.de [185.11.138.130]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B4D2C90; Mon, 8 May 2023 08:56:11 -0700 (PDT) Received: from ip4d1634d3.dynamic.kabel-deutschland.de ([77.22.52.211] helo=diego.localnet) by gloria.sntech.de with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1pw3DW-00063i-N6; Mon, 08 May 2023 17:56:02 +0200 From: Heiko =?ISO-8859-1?Q?St=FCbner?= To: Conor Dooley Cc: Conor Dooley , Jisheng Zhang , Icenowy Zheng , Thomas Gleixner , Marc Zyngier , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Palmer Dabbelt , Paul Walmsley , Albert Ou , linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-riscv@lists.infradead.org, Guo Ren Subject: Re: [PATCH 3/5] riscv: dts: add initial T-HEAD light SoC device tree Date: Mon, 08 May 2023 17:56:01 +0200 Message-ID: <3554468.R56niFO833@diego> In-Reply-To: <20230508-refute-reliable-f50dafa6afbd@wendy> References: <20230507182304.2934-1-jszhang@kernel.org> <7518428.EvYhyI6sBW@diego> <20230508-refute-reliable-f50dafa6afbd@wendy> MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS, T_SCC_BODY_TEXT_LINE,T_SPF_HELO_TEMPERROR autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am Montag, 8. Mai 2023, 10:35:38 CEST schrieb Conor Dooley: > On Mon, May 08, 2023 at 10:23:02AM +0200, Heiko Stübner wrote: > > Am Montag, 8. Mai 2023, 05:32:17 CEST schrieb Icenowy Zheng: > > > 在 2023-05-07星期日的 22:35 +0100,Conor Dooley写道: > > > > Hey Jisheng, > > > > > > > > On Mon, May 08, 2023 at 02:23:02AM +0800, Jisheng Zhang wrote: > > > > > > > > > + c910_0: cpu@0 { > > > > > + compatible = "thead,c910", "riscv"; > > > > > + device_type = "cpu"; > > > > > + riscv,isa = "rv64imafdc"; > > > > > > > > Does this support more than "rv64imafdc"? > > > > I assume there's some _xtheadfoo extensions that it does support, > > > > although I am not sure how we are proceeding with those - Heiko might > > > > have a more nuanced take. > > > > I guess the interesting question still is, are these part of the isa > > string or more of an errata? > > Yeah, I dunno. That's possible a policy decision more than anything > else. I don't remember if it was one of your patchsets or elsewhere, but > I do recall a split between xtheadba etc and vector, where xtheadba was > defined as a vendor extension, whereas vector is not. Their extension > spec repo appears > to be aligned with that view, apart from the CMOs that we have already > called an erratum. I think the CMO stuff came a bit before that repo actually existed ;-) . I guess another argument for riscv,isa would be that we don't have to trust MVENDORID, and especially values in MARCHID and MIMPID. Somehow part of me doesn't have enough trust that these values will always be suitably different when they are baked into the hardware ;-) . I guess vector is somewhat special, with it implementing version 0.7.1 it's not a t-head invention but also not the real RISCV "v" . So I _guess_ the jury might still be out on how to handle that everywhere. > > The binding currently says > > Identifies the specific RISC-V instruction set architecture > > supported by the hart. These are documented in the RISC-V > > User-Level ISA document, available from > > https://riscv.org/specifications/ > > > > > > I guess if we decide to make them part of the isa-string the binding > > then should get a paragraph mention _xfoo vendor-extensions too. > > I have an idea in the works that may allow dealing with this kind of > thing, but it's a bit of a departure from the existing binding. > I will hopefully post an early RFC of it later today. > That said, the binding does currently allow you to put in _xfoo vendor > extensions as-is. > > > Personally, making these part of the ISA string definitly sounds like > > the best solution though :-) . > > You would say that wouldn't you! In general, I'd rather we filled in as > much information as possible here, even if it is not currently in use, > to avoid having to retrofit as support becomes available. yep definitively. Especially as switching to expecting _xfoo later on then causes of course compatiblity issues. The fun part will be though to get vendors, toolchains and friends to agree on the naming. Heiko