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 for Android: free password hash cracker in your pocket

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

Message-ID: <d8fa12cc-7a03-4954-8ea5-1e2edf9a149d@sifive.com>
Date: Tue, 9 Dec 2025 15:18:58 +0900
From: Samuel Holland <samuel.holland@...ive.com>
To: E Shattow <e@...eshell.de>,
 Heinrich Schuchardt <heinrich.schuchardt@...onical.com>,
 Conor Dooley <conor@...nel.org>
Cc: 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 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.

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.

Regards,
Samuel