Message-ID: <4b08ce35-9d2d-4e7b-9ea6-c1dcbc4ad04d@freeshell.de>
Date: Wed, 10 Dec 2025 20:23:54 -0800
From: E Shattow <e@...eshell.de>
To: Conor Dooley <conor@...nel.org>,
 Samuel Holland <samuel.holland@...ive.com>
Cc: 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 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.

1. Can we now remove "starfive,jh7110s" compatible and replace with
"starfive,jh7110" or is this not possible because it is already merged?

2. From the StarFive maintainer: "I prefer to keep 'starfive,jh7110s'
compatible, because 'JH7110S' is the chip name in StarFive documents and
the name printed on the chip. It is easier for the users to know which
chip they are using and select the correct device tree."

https://lore.kernel.org/lkml/ZQ2PR01MB13075CDDEFC2F03C837E1B31E6C92@ZQ2PR01MB1307.CHNPR01.prod.partner.outlook.cn/

So this is the only reason for a new compatible and I'm doing as
Heinrich suggests with a follow-up after that new compatible is merged
to add the actual "starfive,jh7110" compatible to the list.

What then, what is the consensus, is "starfive,jh7110" more or less
compatible than "starfive,jh7110s" for adding to the compatible list of
the VisionFive 2 Lite board(s)?

https://lore.kernel.org/lkml/1f96a267-f5c6-498e-a2c4-7a47a73ea7e7@canonical.com/

3. Does everyone instead agree that "starfive,jh7110" cannot be added to
StarFive VisionFive 2 Lite compatible list when a new compatible
"starfive,jh7110s" has been merged and I should drop this ?  Seems
pointless to me now to pursue this if there is not any consistency and
what Heinrich suggested is not accepted.

-E

Powered by blists - more mailing lists