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

[Krzysztof Kozlowski]

On 16/03/2026 15:34, Geert Uytterhoeven wrote:
> Hi Krzysztof,
> 
> On Mon, 16 Mar 2026 at 15:21, Krzysztof Kozlowski <krzk@xxxxxxxxxx> wrote:
>> On 16/03/2026 15:16, Wolfram Sang wrote:
>>>> Add a new compatible string "renesas,r9a09g077-xspi" for RZ/T2H while
>>>> reusing the existing xspi_info_r9a09g047 OF data. This allows the driver
>>>> to bind correctly on RZ/T2H while the register differences can be handled
>>>> in future updates as the affected configuration registers are not currently
>>>> accessed by the driver.
>>>
>>> This sounds fragile to me. Can you add a comment somewhere in the driver
>>> or headers so people wanting to use these registers will find out that
>>> the SoCs are not compatible anymore?
>>
>> IMO, this patch is not needed. If you need to handle differences in
>> registers, then you add dedicated OF data.
>>
>> The change here (with the bindings) is actually confusing, because
>> effectively it says two contradictory statements:
>> 1. Driver patch: devices are different but they are compatible in
>> meaning of DT,
>> 2. Bindings: devices are not compatible
>>
>> So you need to decide which above, but not both.
>>
>> Eventually provide extensive arguments in terms of how DT understands
>> compatibility.
> 
> I disagree.  Using the same of_data can does not mean the devices are
> 100% compatible.  It can also mean that the devices are different, but

I did not say 100% compatible. I said compatible.

>   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.

>   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.

Best regards,
Krzysztof