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] [day] [month] [year] [list]
Message-ID:
 <ZQ2PR01MB1307DADE17FFEFCE70C3F391E6D62@ZQ2PR01MB1307.CHNPR01.prod.partner.outlook.cn>
Date: Tue, 18 Nov 2025 02:12:58 +0000
From: Hal Feng <hal.feng@...rfivetech.com>
To: E Shattow <e@...eshell.de>, Emil Renner Berthing
	<emil.renner.berthing@...onical.com>, Albert Ou <aou@...s.berkeley.edu>,
	Bjorn Helgaas <bhelgaas@...gle.com>, Conor Dooley <conor+dt@...nel.org>,
	Heinrich Schuchardt <heinrich.schuchardt@...onical.com>, Krzysztof Kozlowski
	<krzk+dt@...nel.org>, Krzysztof WilczyƄski
	<kwilczynski@...nel.org>, Lorenzo Pieralisi <lpieralisi@...nel.org>,
	Manivannan Sadhasivam <mani@...nel.org>, Palmer Dabbelt <palmer@...belt.com>,
	Paul Walmsley <pjw@...nel.org>, "Rafael J . Wysocki" <rafael@...nel.org>, Rob
 Herring <robh@...nel.org>, Viresh Kumar <viresh.kumar@...aro.org>
CC: "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-riscv@...ts.infradead.org" <linux-riscv@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v2 0/8] Add support for StarFive VisionFive 2 Lite board

> On 18.11.25 05:55, E Shattow wrote:
> On 11/16/25 22:54, Hal Feng wrote:
> >> On 16.11.25 00:29, Emil Renner Berthing wrote:
> >> Quoting E Shattow (2025-11-13 16:16:12)
> >>>
> >>>
> >>> On 11/13/25 02:42, Emil Renner Berthing wrote:
> >>>> Quoting Hal Feng (2025-11-13 04:42:05)
> >>>>>> On 12.11.25 21:54, Emil Renner Berthing wrote:
> >>>>>> Quoting Hal Feng (2025-11-07 10:55:22)
> >>>>>>> VisionFive 2 Lite is a mini SBC based on the StarFive JH7110S
> >>>>>>> industrial SoC which can run at -40~85 degrees centigrade and up
> >>>>>>> to 1.25GHz.
> >>>> [...]
> >>>>>> Currently the JH7110 device trees are layed out like this, with a
> >>>>>> nice separation between the SoC description and board descriptions:
> >>>>>>
> >>>>>> jh7110.dtsi               # JH7110 SoC description
> >>>>>> |- jh7110-common.dtsi     # Peripherals common to all JH7110 boards
> >>>>>>    |- jh7110-starfive-visionfive-2.dtsi # Peripherals common to
> >>>>>> VF2
> >> boards
> >>>>>>    |  |- <VF2 boards>     # Final VF2 board descriptions
> >>>>>>    |- jh7110-milkv-marscm.dtsi # Peripherals common to Mars CM
> >> boards
> >>>>>>    |  |- <Mars CM boards> # Final Mars CM board descriptions
> >>>>>>    |- <other boards>      # Other JH7110 board descriptions
> >>>>>>
> >>>>>> With this series it moves to
> >>>>>>
> >>>>>> jh711x.dtsi
> >>>>>> |- jh711x-common.dtsi
> >>>>>>    |- jh7110-common.dtsi
> >>>>>>    |  |- <jh7110 boards>
> >>>>>>    |- jh7110s-common.dtsi
> >>>>>>       |- <jh7110s boards>
> >>>>>>
> >>>>>> ..which I can't even give clear labels like above. In other words
> >>>>>> when new patches are sent in it would not be easy to explain
> >>>>>> exactly where each change should go and why.
> >>>>>> I'm also worried that you'll find that more of the peripherals on
> >>>>>> the JH7110S need special handling and a new jh7110s-...
> >>>>>> compatible string. Then I guess they'll need to jump from
> >>>>>> jh7110x.dtsi two levels down to jh7110{,s}- common.dtsi which
> >>>>>> then both describe SoC
> >> and board properties.
> >>>>>>
> >>>>>> If you're serious about calling this a new SoC then I'd expect
> >>>>>> something more like this:
> >>>>>>
> >>>>>> jh711x.dtsi                  # Peripherals common to both SoCs
> >>>>>> |- jh7110.dtsi               # JH7110 SoC description
> >>>>>> |  |- jh7110-common.dtsi     # Peripherals common to all JH7110
> boards
> >>>>>> |     |- jh7110-starfive-visionfive-2.dtsi # Peripherals common
> >>>>>> |to VF2
> >> boards
> >>>>>> |     |  |- <VF2 boards>     # Final VF2 board descriptions
> >>>>>> |     |- jh7110-milkv-marscm.dtsi # Peripherals common to Mars CM
> >> boards
> >>>>>> |     |  |- <Mars CM boards> # Final Mars CM board descriptions
> >>>>>> |     |- <other boards>      # Other JH7110 board descriptions
> >>>>>> |- jh7110s.dtsi              # JH7110S SoC description
> >>>>>>    |- jh7110s-common.dtsi    # Peripherals common to all JH7110S
> >> boards
> >>>>>>       |- <JH7110S boards>    # Final JH7110S board descriptions
> >>>>>>
> >>>>>> I know this will mean some duplication in jh7110{,s}-common.dtsi,
> >>>>>> but I would prefer that to not having a clear explanation of what
> >>>>>> each file
> >> describes.
> >>>>>>
> >>>>>> Do you think this layout could work for you?
> >>>>>
> >>>>> Yeah, it is clearer for developers and maintainers.
> >>>>>
> >>>>> Considering Conor's suggestion, what about:
> >>>>>
> >>>>> jh7110.dtsi               # JH7110 SoC description
> >>>>> |- jh7110-common.dtsi     # Peripherals common to all JH7110 boards
> >>>>>    |- jh7110-starfive-visionfive-2.dtsi # Peripherals common to VF2
> boards
> >>>>>    |  |- <VF2 boards>     # Final VF2 board descriptions
> >>>>>    |- jh7110-milkv-marscm.dtsi # Peripherals common to Mars CM
> boards
> >>>>>    |  |- <Mars CM boards> # Final Mars CM board descriptions
> >>>>>    |- <other boards>      # Other JH7110 board descriptions
> >>>>> |- <JH7110S boards>
> >>>>>
> >>>
> >>> JH-7110 and JH-7110I reference docs are listed (not any JH-7110S) at:
> >>> https://doc-en.rvspace.org/Doc_Center/datasheet_0.html
> >>>
> >>> Does the JH-7110I use the OPP table for JH-7110 or JH-7110S?
> >>>
> >>>>> Move the opp table from jh7110.dtsi to jh7110-common.dtsi.
> >>>>> Remove jh7110s-common.dtsi, because only one board uses JH7110S
> >> now.
> >>>>
> >>>> This patchset adds 2 different boards. Has this changed?
> >>>>
> >>>> Also this would mean that you're not using the starfive,jh7110s
> >>>> compatible or any other starfive,jh7110s-.. compatible strings, so
> >>>> effectively you're not treating it as a new chip, but just a board
> >>>> that needs a
> >> different opp table.
> >>>>
> >>>> I see now that the opp table is effectively the only difference
> >>>> between the two chips in this patchset, so if that's closer to
> >>>> reality then what you suggest is fine with me.
> >>>>
> >>>> /Emil
> >>>
> >>> Are we now re-visiting Hal's suggestion then (during code review for
> >>> Milk-V Mars CM and Mars CM Lite) to split out the OPP tables and
> >>> make them per-board, as before introduction of the StarFive
> >>> VisionFive 2 Lite
> >>> board(s) ?
> >>>
> >>> Can we then do as from where we are now before this series:
> >>>
> >>> - Move "the JH-7110" OPP table into jh7110-common-opp-1500.dtsi
> >>>
> >>> - Each board jh7110-{deepcomputing,milkv,pine64,starfive}*.dts
> >>> includes said OPP dtsi file.
> >>>
> >>> and for this series:
> >>>
> >>> - Drop the adding of a new compatible
> >>>
> >>> - Add "the JH-7110S" OPP table into jh7110-common-opp-1250.dtsi
> >>>
> >>> - Use existing jh7110-* prefix for "JH-7110S" board dtsi and dts,
> >>> include jh7110-common.dtsi as usual, and include
> >>> jh7110-common-opp-1250.dtsi
> >>>
> >>> The exact filename pattern for the OPP tables I suggest here are
> >>> approximations, however that idea is my suggestion if we're just
> >>> doing a breakout of the tables and not a new compatible.
> >>>
> >>> I am positive on having the 1250MHz OPP tables split out into dtsi
> >>> instead of stuffing them into the VisionFive 2 Lite common dtsi.
> >>> That's all it is?
> >>
> >> I think this suggestion makes sense if we're 100% sure the JH7110 and
> >> JH7110S will only ever differ by the opp table. If there is any
> >> chance we'll need to add different compatible string for some
> >> peripheral then I think Hal's suggestion will be easier untangle.
> >> We'll even be able to do it without touching all the board dts files once
> again.
> >>
> >> I'm interested to hear Hal's opinion on this. Hopefully they'll have
> >> more details on the two version of the JH7110.
> >
> > Here are the differences between JH7110 and JH7110S:
> > JH7110 supports 0~70 degrees centigrade and up to 1.5GHz.
> > JH7110S supports -40~85 degrees centigrade and up to 1.25GHz.
> >
> > 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.
> >
> > And patch [1] and [2] had accepted the "starfive,jh7110s" compatible.
> > [1]
> > https://lore.kernel.org/all/jurnfpufll4twv2hfp2dv6qk6d3gr7gfmek5czigb5
> > bcon636q@...6hrdb424p/ [2]
> >
> https://lore.kernel.org/all/CAAhSdy2Jr+EoW9AZooRDa12Kx9MSSaBaDXbJUo
> Vym
> > 1qTt3r0-Q@...l.gmail.com/
> >
> > Best regards,
> > Hal
> 
> Hal,
> 
> OpenSBI development can accept a revert for that 1-liner of code if needed,
> and anyways that new compatible was not tagged in any release yet while also
> being moot because if you do use it somewhere else and OpenSBI keeps this
> around it has no effect on upstream Linux using the compatible for JH7110.
> 
> Devicetree in Linux describes hardware not related to the feelings of customers
> so that should not be a concern here.
> 
> The data given for JH7110 and JH7110S does not make sense from what can
> be found in published technical documentation. The technical documentation
> is however lacking a chart for JH7110 from which to derive any useful
> comment here.
> 
> All,
> 
> I repeat that the suggestion was made months ago (by Hal) to split out the
> OPP tables per-board from the period of time when I was complaining about
> 1.5GHz JH-7110 operation pushing TDP into over-temperature thermal limit
> on Milk-V Mars CM SoM.
> 
> Whether or not JH7110S is a new compatible should follow precedence in
> Linux development. JH-7110S is evidently the same tape-out as JH-7110 and
> however you deal with that in Linux is the appropriate way to deal with that
> here. Selection of OPP table for correct operation will be determined by
> bootloader, where, it is demonstrated by patch series sent to U-Boot
> upstream to be selected ** per-board ** based on EEPROM content as if it
> was any other JH-7110 board deciding dts based on EEPROM content. Given
> that it is the same tape-out I do not find a valid justification for a new
> compatible in the stack of adjacent software besides going along with some
> kind of marketing-driven answer about whether or not this is a new SoC.
> 
> What I care about now is that the VisionFive 2 Lite series is in good enough
> shape and there's a possibility to act on this months-old suggestion to split out
> the OPP tables which as we have confirmed the JH7110S is the same SoC as
> JH7110 it makes a lot of sense to do.
> 
> How is it supposed to work for binned silicon in Linux?

Hi, Conor,  Emil, 

What do you think about this? Hope to hear from you.

Best regards,
Hal

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ