Re: [PATCH 3/3] memory: renesas-rpc-if: Add support for RZ/T2H SoC

[Krzysztof Kozlowski]

On 16/03/2026 16:02, Geert Uytterhoeven wrote:
> 
>>>   a) The differences are not handled yet, because the extra features of
>>>      one variant (or both variants)  are not yet supported by the supported by the driver
>> So that's why I mentioned how DT understands compatibility. Above does
>> not matter, sorry.
>>
>> Extra features means subset/superset.
> 
> I haven't looked at the differences between the two variants here,
> but I doubt one of them is a superset of the other. Probably both are
> supersets of a common subvariant that doesn't really exist ;-)

That could be the argument. Consider also that we don't care if
superset/subset is a real, design decision. If you have two independent
companies making something working with the same interface, they are
compatible. If one adds one more feature, you have superset/subset.

And we already have some examples of this for simpler devices in hwmon
and/or iio.

> 
>>>   b) The differences are not handled explicitly, but implicitly,
>>>      or elsewhere.
>>>      E.g. the different number of resets is handled implicitly through
>>>      devm_reset_control_array_get_exclusive().
>>
>> Still not an argument in meaning of DT compatibility. Implementation
>> uses the same ABI (through devm_reset_control_array_get_exclusive),
>> right? So devices are compatible for Linux kernel.
> 
> Linux is not the only user of DT.

With such argument (implied: "there is an user which cannot use that
compatibility"), nothing would be ever compatible except devices being
identical. If you cannot find such user, you can write a driver which on
purpose will be incompatible and bring it as an argument.

If there is known incompatible implementation, please mention it.
Otherwise the implementation here kind of rules devices are compatible.
Assuming implementation is working and to some extend usable, e.g.
complete set of some features.

Best regards,
Krzysztof