RE: [PATCH] spi: rzv2h-rspi: Fix DMA transfer error handling for signal interruption
From: Fabrizio Castro
Date: Mon Jun 29 2026 - 06:33:10 EST
Hi Cosmin,
> From: Cosmin-Gabriel Tanislav <cosmin-gabriel.tanislav.xa@xxxxxxxxxxx>
> Sent: 29 June 2026 11:22
> To: wsa+renesas <wsa+renesas@xxxxxxxxxxxxxxxxxxxx>; Felix Gu <ustc.gu@xxxxxxxxx>
> Cc: Fabrizio Castro <fabrizio.castro.jz@xxxxxxxxxxx>; Mark Brown <broonie@xxxxxxxxxx>; linux-
> spi@xxxxxxxxxxxxxxx; linux-renesas-soc@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx
> Subject: RE: [PATCH] spi: rzv2h-rspi: Fix DMA transfer error handling for signal interruption
>
> > From: Wolfram Sang <wsa+renesas@xxxxxxxxxxxxxxxxxxxx>
> > Sent: Friday, June 26, 2026 7:43 PM
> >
> > On Sat, Jun 27, 2026 at 12:02:29AM +0800, Felix Gu wrote:
> > > wait_event_interruptible_timeout() can return a negative error code when
> > > interrupted by a signal. The original code treated all non-zero return
> > > values as success, which would incorrectly synchronize DMA channels and
> > > return 0 instead of propagating the interruption error.
> > >
> > > Fixes: fa08b566860b ("spi: rzv2h-rspi: add support for DMA mode")
> > > Signed-off-by: Felix Gu <ustc.gu@xxxxxxxxx>
> >
> > Patch looks correct. But it makes me wonder if interrupting the transfer
> > has actually been tested? Cosmin, can you recall such tests? From my I2C
> > experience, I know it can be hard to get the state maching back to a
> > consistent state. Sometimes, it was preferred to simply use
> > wait_event_timeout() instead and drop interruptible support.
>
> Hi Wolfram, Felix.
>
> I don't think we tested interrupting the transfer.
>
> I can run some tests locally this week and see how it behaves.
>
> Looking at it now, the timeout / -ERESTARTSYS path might need some
> extra logic to put the controller in a good state.
>
> I also think the patch is correct and should be accepted for now.
I think perhaps let's test it before accepting the patch.
Cheers,
Fab