On Mon, Oct 26, 2026 at 11:20 AM Dave Stevenson <[email protected]> wrote: > > On Mon, 19 Oct 2026 at 18:55, Henry Zhang <[email protected]> wrote: > > > > vc4_dsi_host_transfer() fills the command FIFOs and the TXPKT registers > > and waits on a single completion without any locking. Two callers > > sending at the same time, for example a panel driver and a backlight > > update, can overwrite each other's packets, and the timeout recovery > > added in the previous patch could reset the block under a transfer > > that is still in flight. > > > > Hold a mutex for the whole host transfer, including the recovery. > > > > Signed-off-by: Henry Zhang <[email protected]> > > Reviewed-by: Dave Stevenson <[email protected]>
Hi Dave, Thanks for the reviews. Our mails crossed: I sent v3 shortly after, see: https://lore.kernel.org/r/[email protected] Please don't apply v2. Further testing on a Raspberry Pi 4 showed that the recovery in v2 2/3 can turn a lane error into an interrupt storm that hangs the system. v3 rate-limits the error messages, masks the interrupts during the reset and only recovers while the block is enabled. v3 1/4 is unchanged from v2 1/3, so your Reviewed-by still applies there. v3 3/4 is not the same as v2 3/3: the lock is now also taken in the bridge pre_enable, enable, disable and post_disable callbacks, and the patch comes before the recovery, so I did not carry your tag over. I'd be grateful if you could have another look. An automated review of v3 found a race in 4/4: an error interrupt can still run during the reset. I'll fix it in v4 by keeping the handler out with disable_irq() around the reset; 1/4 to 3/4 won't change. Henry
