Linux-RISC-V Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Samuel Holland <samuel.holland@sifive.com>
To: E Shattow <e@freeshell.de>,
	Heinrich Schuchardt <heinrich.schuchardt@canonical.com>,
	Conor Dooley <conor@kernel.org>
Cc: Emil Renner Berthing <kernel@esmil.dk>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Paul Walmsley <pjw@kernel.org>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Alexandre Ghiti <alex@ghiti.fr>,
	Hal Feng <hal.feng@starfivetech.com>,
	linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org,
	devicetree@vger.kernel.org,
	Emil Renner Berthing <emil.renner.berthing@canonical.com>,
	Conor Dooley <conor.dooley@microchip.com>
Subject: Re: [PATCH v1] riscv: dts: starfive: Append starfive,jh7110 compatible to VisionFive 2 Lite
Date: Tue, 9 Dec 2025 15:18:58 +0900	[thread overview]
Message-ID: <d8fa12cc-7a03-4954-8ea5-1e2edf9a149d@sifive.com> (raw)
In-Reply-To: <0bb12889-cb28-44e7-b2d6-7ecba6264d1a@freeshell.de>

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


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  reply	other threads:[~2025-12-09  6:19 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-06 20:45 [PATCH v1] riscv: dts: starfive: Append starfive,jh7110 compatible to VisionFive 2 Lite E Shattow
2025-12-08 16:29 ` Conor Dooley
2025-12-08 16:38   ` Heinrich Schuchardt
2025-12-09  0:53     ` E Shattow
2025-12-09  6:18       ` Samuel Holland [this message]
2025-12-10 16:43         ` Conor Dooley
2025-12-11  4:23           ` E Shattow
2025-12-12 17:59             ` Conor Dooley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d8fa12cc-7a03-4954-8ea5-1e2edf9a149d@sifive.com \
    --to=samuel.holland@sifive.com \
    --cc=alex@ghiti.fr \
    --cc=aou@eecs.berkeley.edu \
    --cc=conor.dooley@microchip.com \
    --cc=conor@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=e@freeshell.de \
    --cc=emil.renner.berthing@canonical.com \
    --cc=hal.feng@starfivetech.com \
    --cc=heinrich.schuchardt@canonical.com \
    --cc=kernel@esmil.dk \
    --cc=krzk+dt@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@dabbelt.com \
    --cc=pjw@kernel.org \
    --cc=robh@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox