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

[Conor Dooley]

On Wed, Dec 10, 2025 at 08:23:54PM -0800, E Shattow wrote:
> 
> On 12/10/25 08:43, Conor Dooley wrote:
> > 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.
> 
> I agree, there's not any benefit to add "starfive,jh7110s" as the
> least-compatible to existing stuff.
> 
> The reply from Samuel is quite helpful however it's not any clearer to
> me what direction to take this.

I think the idea is fine, just explain why it'd be helpful in the commit
message and do the dt-binding change that this doesn't cause warnings.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-riscv/attachments/20251212/79388a88/attachment.sig>