Re: [PATCH v1] riscv: dts: starfive: Append starfive,jh7110 compatible to VisionFive 2 Lite

From: Conor Dooley <conor@kernel.org>
To: Samuel Holland <samuel.holland@sifive.com>
Cc: E Shattow <e@freeshell.de>,
	Heinrich Schuchardt <heinrich.schuchardt@canonical.com>,
	Emil Renner Berthing <kernel@esmil.dk>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Paul Walmsley <pjw@kernel.org>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Alexandre Ghiti <alex@ghiti.fr>,
	Hal Feng <hal.feng@starfivetech.com>,
	linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org,
	devicetree@vger.kernel.org,
	Emil Renner Berthing <emil.renner.berthing@canonical.com>,
	Conor Dooley <conor.dooley@microchip.com>
Subject: Re: [PATCH v1] riscv: dts: starfive: Append starfive,jh7110 compatible to VisionFive 2 Lite
Date: Wed, 10 Dec 2025 16:43:37 +0000	[thread overview]
Message-ID: <20251210-pull-pleading-57c880596510@spud> (raw)
In-Reply-To: <d8fa12cc-7a03-4954-8ea5-1e2edf9a149d@sifive.com>

[-- Attachment #1.1: Type: text/plain, Size: 2330 bytes --]

On Tue, Dec 09, 2025 at 03:18:58PM +0900, Samuel Holland wrote:
> On 2025-12-09 9:53 AM, E Shattow wrote:
> > The unanswered question what I was asking in the code review of StarFive 
> > VisionFive 2 Lite series: What is the normal thing to do for compatible 
> > strings of relabeled silicon when there is a suggestion of different 
> > operational parameters?
> I don't think we are very consistent on this, and some of it depends on how
> different the binned chips are from each other.

Largely I think the lack of consistency stems from there being relatively
few users of these soc-level compatibles, so there's nothing really gained
from having one in a lot of cases.

> Example 1: Rockchip RK3399 has several bins. RK3399-S and RK3399-T just override
> the OPPs, but reuse the SoC compatible string without change. On the other hand
> RK3399pro is a superset of RK3399, but uses a new compatible string without a
> fallback.
> 
> Example 2: Allwinner H616 (https://linux-sunxi.org/H616) has multiple
> bins/packages/die revisions. H313 is a down-binned version of H616, which reuses
> the SoC compatible string without change. H700 is a superset of H616 (same die,
> more pins), but uses a new compatible string without a fallback.
> 
> > I can include the (paraphrased) above summary by Heinrich, yes. Although
> > now I doubt whether this is the best approach, when removal of
> > "starfive,jh7110s" compatible is potentially an equally valid fix, or if
> > we're rather considering JH7110 at 1.5GHz maximum to be a superset of
> > itself at 1.25GHz maximum (JH-7110S). Would we want to change all the
> > JH-7110 boards to then have JH-7110S as the least-compatible, if I am
> > understanding that meaning of "superset"? I would like to know what is
> > expected.
> 
> If starfive,jh7110 is a superset of starfive,jh7110s, yes, it would be valid to
> add starfive,jh7110s as a fallback compatible string in all of the existing
> board bindings. But this is not very useful, as existing software already looks
> for starfive,jh7110, and you can't replace that without breaking compatibility
> with existing DTs. So the advantage of one compatible string (mostly) covering
> both SoCs only applies to new software.

Yeah, adding it to the existing stuff provides no real benefit.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 161 bytes --]

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