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

[Biju Das]

Hi Krzysztof Kozlowski,

> -----Original Message-----
> From: Krzysztof Kozlowski <krzk@xxxxxxxxxx>
> 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@xxxxxxxxxx>
> >> 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@xxxxxxxxxxxxxx>
> >>>> ---
> >>>>  - This patch depend up on [0]
> >>>>  - [0]
> >>>> https://lore.kernel.org/all/20260128215132.1353381-2-cosmin-gabriel
> >>>> .t
> >>>> anislav.xa@xxxxxxxxxxx/
> >>>
> >>> 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?

It will cover all the invalid cases for eg: Num DMACs = 5

{rx} --> Covered by DMA specifiers with at least one for transmission and one for reception.
{tx}
{rx, rx, rx, rx, rx, rx } --> Covered by the total number of DMACs available on the SoC.
{tx, tx, tx, tx, tx, tx }
....
....

Cheers,
Biju