Re: [PATCH 3/5] spi: dt-bindings: renesas,rzv2h-rspi: Document RZ/G3E SoC support

[Krzysztof Kozlowski <krzk@kernel.org>]

On 04/03/2026 16:52, Biju Das wrote:
> Hi Krzysztof Kozlowski,
> 
>> -----Original Message-----
>> From: Krzysztof Kozlowski <krzk@kernel.org>
>> Sent: 04 March 2026 15:40
>> Subject: Re: [PATCH 3/5] spi: dt-bindings: renesas,rzv2h-rspi: Document RZ/G3E SoC support
>>
>> On 04/03/2026 16:34, Biju Das wrote:
>>> Hi Krzysztof Kozlowski,
>>>
>>>> -----Original Message-----
>>>> From: Krzysztof Kozlowski <krzk@kernel.org>
>>>> Sent: 04 March 2026 15:06
>>>> Subject: Re: [PATCH 3/5] spi: dt-bindings: renesas,rzv2h-rspi:
>>>> Document RZ/G3E SoC support
>>>>
>>>> On 18/02/2026 08:50, Krzysztof Kozlowski wrote:
>>>>> On Tue, Feb 17, 2026 at 05:23:47PM +0100, Tommaso Merciai wrote:
>>>>>> Document the RSPI controller on the Renesas RZ/G3E SoC. The block
>>>>>> is compatible with the RSPI implementation found on the RZ/V2H(P) family.
>>>>>>
>>>>>> Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
>>>>>> ---
>>>>>>  - This patch depend up on [0]
>>>>>>  - [0]
>>>>>> https://lore.kernel.org/all/20260128215132.1353381-2-cosmin-gabriel
>>>>>> .t
>>>>>> anislav.xa@renesas.com/
>>>>>
>>>>> I am not even looking there, start reviewing each other patches, so
>>>>> you won't be sending FIXES instead of reviews.
>>>>
>>>> You kind of ignored the problem and the other patch got merged.
>>>
>>> We prepared a patch updating the description and it is under internal review:
>>
>> That's not the point. The point was that you give PUBLIC review that mentioned patch is incomplete and
>> must be changed.
>>
>> Not prepare a follow-up patch. That's exactly my complain I raised, so you solved nothing.
> 
> We were supposed to send a v2 with description after your review, by the time the other patch got merged.
> 
> Now we prepared an incremental patch just for updating the description and it is under internal review.
> 
>>
>>>
>>> This will cover any combinations.
>>>
>>>   description:
>>>       Must contain unique references to DMA specifiers, with at least one
>>>       for transmission and one for reception. Each category may include
>>>       multiple entries, constrained only by the total number of DMACs
>>>       available on the SoC.
>>
>> No. Solves nothing. Renesas folks were supposed to review patches instead of letting poor code be
>> merged to THEN develop fixes.
> 
> Why you think this description won't fix the issue with multiple DMACS?

Because I asked you TO REVIEW the patch while it was inflight.

Did it happen? No.

Explain me how posting patch now solves the past events, that patch was
already merged and no review from Renesas was given?


Best regards,
Krzysztof