[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0bb12889-cb28-44e7-b2d6-7ecba6264d1a@freeshell.de>
Date: Mon, 8 Dec 2025 16:53:23 -0800
From: E Shattow <e@...eshell.de>
To: 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 12/8/25 08:38, Heinrich Schuchardt wrote:
> On 12/8/25 17:29, Conor Dooley wrote:
>> On Sat, Dec 06, 2025 at 12:45:30PM -0800, E Shattow wrote:
>>> Append starfive,jh7110 compatible to VisionFive 2 Lite and VisionFive 2
>>> Lite eMMC in the "least compatible" end of the list. JH7110S on these
>>> boards is the same tape-out as JH7110 however rated for thermal,
>>> voltage,
>>> and frequency characteristics for a maximum of 1.25GHz operation.
>>>
>>> Link to previous discussion suggesting this change:
>>> https://lore.kernel.org/lkml/1f96a267-f5c6-498e-
>>> a2c4-7a47a73ea7e7@...onical.com/
>>>
>>> Fixes: 900b32fd601b ("riscv: dts: starfive: Add VisionFive 2 Lite
>>> board device tree")
>>> Fixes: ae264ae12442 ("riscv: dts: starfive: Add VisionFive 2 Lite
>>> eMMC board device tree")
>>> Suggested-by: Heinrich Schuchardt <heinrich.schuchardt@...onical.com>
>>> Signed-off-by: E Shattow <e@...eshell.de>
>>
>> You can't do this without modifying the binding too, as this doesn't
>> pass dtbs_check.
Will fix, thanks.
>>
>> However, is this actually correct? The frequency of operation and the
>> temperature range aren't a superset of what the jh7110 can do, what is
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?
The devicetree/usage-model documentation does mention SoC family but is
not specific about any marketing or quality assurance test for silicon
binning. For the K1/M1 SpacemiT chips relabled as Ky manufacture there's
no suggestion that the relabeled chips have different operational
parameters and so a new compatible was rejected then.
The reset condition of 1000MHz @ 0.9V on the family of JH7110/JH7110-S
boards is not present in the dts OPP tables for jh7110 and jh7110s dts.
I've asked previously [1] (in the discussions about bootph-pre-ram
hints) before having knowledge that there was a JH-7110S product
planned, what prevents JH-7110 from having more than 4 divider operating
points and including this default condition? Not having been tested
seems to be the answer. Not all testing results are published or
described in code upstream either. I'm making my guess based on what
information that is available.
1:
https://lore.kernel.org/lkml/40d77aae-9e53-4981-a2aa-dcdc6f11ac83@freeshell.de/
>> the actual advantage of having it? If there's some software that this
Unless I misunderstand the meaning (as above), then this is what is
recommended for in the documentation. Heinrich confirms this avoids the
need for checking the new "starfive,jh7110s" SoC compatible. Maybe I'm
wrong about this approach for binned silicon? Please someone give me a
clue if this was answered already and I missed it.
>> would make a difference for, please mention it in the commit message.
>
> Appending "starfive,jh7110" would reduce the number of compatible
> strings to check in the OpenSBI platform driver.
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.
>
> Best regards
>
> Heinrich
>
>>
>> Cheers,
>> Conor.
>>
Thanks for the review, -E
Powered by blists - more mailing lists