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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251210-pull-pleading-57c880596510@spud>
Date: Wed, 10 Dec 2025 16:43:37 +0000
From: Conor Dooley <conor@...nel.org>
To: Samuel Holland <samuel.holland@...ive.com>
Cc: E Shattow <e@...eshell.de>,
	Heinrich Schuchardt <heinrich.schuchardt@...onical.com>,
	Emil Renner Berthing <kernel@...il.dk>,
	Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Paul Walmsley <pjw@...nel.org>, Palmer Dabbelt <palmer@...belt.com>,
	Albert Ou <aou@...s.berkeley.edu>, Alexandre Ghiti <alex@...ti.fr>,
	Hal Feng <hal.feng@...rfivetech.com>, linux-kernel@...r.kernel.org,
	linux-riscv@...ts.infradead.org, devicetree@...r.kernel.org,
	Emil Renner Berthing <emil.renner.berthing@...onical.com>,
	Conor Dooley <conor.dooley@...rochip.com>
Subject: Re: [PATCH v1] riscv: dts: starfive: Append starfive,jh7110
 compatible to VisionFive 2 Lite

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.

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)