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

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

[E Shattow]

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@canonical.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@canonical.com>
Signed-off-by: E Shattow <e@freeshell.de>
---
 .../dts/starfive/jh7110-starfive-visionfive-2-lite-emmc.dts     | 2 +-
 .../boot/dts/starfive/jh7110-starfive-visionfive-2-lite.dts     | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2-lite-emmc.dts b/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2-lite-emmc.dts
index e27a662d4022..7544efa95de4 100644
--- a/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2-lite-emmc.dts
+++ b/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2-lite-emmc.dts
@@ -9,7 +9,7 @@
 
 / {
 	model = "StarFive VisionFive 2 Lite eMMC";
-	compatible = "starfive,visionfive-2-lite-emmc", "starfive,jh7110s";
+	compatible = "starfive,visionfive-2-lite-emmc", "starfive,jh7110s", "starfive,jh7110";
 };
 
 &mmc0 {
diff --git a/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2-lite.dts b/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2-lite.dts
index b96eea4fa7d5..b9913991a1b7 100644
--- a/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2-lite.dts
+++ b/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2-lite.dts
@@ -9,7 +9,7 @@
 
 / {
 	model = "StarFive VisionFive 2 Lite";
-	compatible = "starfive,visionfive-2-lite", "starfive,jh7110s";
+	compatible = "starfive,visionfive-2-lite", "starfive,jh7110s", "starfive,jh7110";
 };
 
 &mmc0 {

base-commit: 5e5ea7f61610239fca058011e7d4f342b34d1558
-- 
2.50.0


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

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

[Conor Dooley]

[-- Attachment #1.1: Type: text/plain, Size: 2733 bytes --]

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@canonical.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@canonical.com>
> Signed-off-by: E Shattow <e@freeshell.de>

You can't do this without modifying the binding too, as this doesn't
pass dtbs_check.

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 actual advantage of having it? If there's some software that this
would make a difference for, please mention it in the commit message.

Cheers,
Conor.

> ---
>  .../dts/starfive/jh7110-starfive-visionfive-2-lite-emmc.dts     | 2 +-
>  .../boot/dts/starfive/jh7110-starfive-visionfive-2-lite.dts     | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2-lite-emmc.dts b/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2-lite-emmc.dts
> index e27a662d4022..7544efa95de4 100644
> --- a/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2-lite-emmc.dts
> +++ b/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2-lite-emmc.dts
> @@ -9,7 +9,7 @@
>  
>  / {
>  	model = "StarFive VisionFive 2 Lite eMMC";
> -	compatible = "starfive,visionfive-2-lite-emmc", "starfive,jh7110s";
> +	compatible = "starfive,visionfive-2-lite-emmc", "starfive,jh7110s", "starfive,jh7110";
>  };
>  
>  &mmc0 {
> diff --git a/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2-lite.dts b/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2-lite.dts
> index b96eea4fa7d5..b9913991a1b7 100644
> --- a/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2-lite.dts
> +++ b/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2-lite.dts
> @@ -9,7 +9,7 @@
>  
>  / {
>  	model = "StarFive VisionFive 2 Lite";
> -	compatible = "starfive,visionfive-2-lite", "starfive,jh7110s";
> +	compatible = "starfive,visionfive-2-lite", "starfive,jh7110s", "starfive,jh7110";
>  };
>  
>  &mmc0 {
> 
> base-commit: 5e5ea7f61610239fca058011e7d4f342b34d1558
> -- 
> 2.50.0
> 

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 161 bytes --]

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

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

[Heinrich Schuchardt]

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@canonical.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@canonical.com>
>> Signed-off-by: E Shattow <e@freeshell.de>
> 
> You can't do this without modifying the binding too, as this doesn't
> pass dtbs_check.
> 
> 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 actual advantage of having it? If there's some software that this
> 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.

Best regards

Heinrich

> 
> Cheers,
> Conor.
> 
>> ---
>>   .../dts/starfive/jh7110-starfive-visionfive-2-lite-emmc.dts     | 2 +-
>>   .../boot/dts/starfive/jh7110-starfive-visionfive-2-lite.dts     | 2 +-
>>   2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2-lite-emmc.dts b/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2-lite-emmc.dts
>> index e27a662d4022..7544efa95de4 100644
>> --- a/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2-lite-emmc.dts
>> +++ b/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2-lite-emmc.dts
>> @@ -9,7 +9,7 @@
>>   
>>   / {
>>   	model = "StarFive VisionFive 2 Lite eMMC";
>> -	compatible = "starfive,visionfive-2-lite-emmc", "starfive,jh7110s";
>> +	compatible = "starfive,visionfive-2-lite-emmc", "starfive,jh7110s", "starfive,jh7110";
>>   };
>>   
>>   &mmc0 {
>> diff --git a/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2-lite.dts b/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2-lite.dts
>> index b96eea4fa7d5..b9913991a1b7 100644
>> --- a/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2-lite.dts
>> +++ b/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2-lite.dts
>> @@ -9,7 +9,7 @@
>>   
>>   / {
>>   	model = "StarFive VisionFive 2 Lite";
>> -	compatible = "starfive,visionfive-2-lite", "starfive,jh7110s";
>> +	compatible = "starfive,visionfive-2-lite", "starfive,jh7110s", "starfive,jh7110";
>>   };
>>   
>>   &mmc0 {
>>
>> base-commit: 5e5ea7f61610239fca058011e7d4f342b34d1558
>> -- 
>> 2.50.0
>>


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

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

[E Shattow]

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@canonical.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@canonical.com>
>>> Signed-off-by: E Shattow <e@freeshell.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

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

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

[Samuel Holland]

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

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

[Conor Dooley]

[-- Attachment #1.1: Type: text/plain, Size: 2330 bytes --]

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.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 161 bytes --]

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

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

[E Shattow]

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

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

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

[Conor Dooley]

[-- Attachment #1.1: Type: text/plain, Size: 2922 bytes --]

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.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 161 bytes --]

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