Re: RE: [PATCH v3 01/10] mailbox: imx: Forward the timeout/ error in imx_mu_generic_tx()

[Sebastian Andrzej Siewior <bigeasy@linutronix.de>]

On 2026-06-26 09:00:04 [+0000], Peng Fan (OSS) wrote:
> > > If you would like to address the AI reported issue further, you may
> > > update readl_poll_timeout to readl_poll_timeout_atomic.
> > 
> > What about the timeout value? Keep it as-is or reduce to?
> 
> Let's keep it as-is.

The call is
	readl_poll_timeout(, , , delay_us = 0, timeout_us = 10000);

so it will _not_ trigger the might_sleep() splat and will compare the
timeout value against ktime_get() so it will loop worst case for 10ms.

If I change it as-is to
	readl_poll_timeout_atomic(, , , delay_us = 0, timeout_us = 10000);

then the result is slightly different: The clocksource is not used
(because it also works in suspend path where it is gone) and so the
timeout_us value is decremented based on the delay_us. If it is 0 then
it only subtracts 1ns per iteration. So the worst case delay becomes now
10.000.000 iterations.
I don't think this is an improvement: In the worst case the delay is
much longer and if there is a watch in that period, it will fire. So it
does not accomplish anything.

Having something like
	readl_poll_timeout_atomic(, , , delay_us = 2, timeout_us = 100);

would lower the delay to 100us max (which is below the 1000HZ tick) and
would spin for 2us between register pools. But I have no idea what is
the expected delay and if it depends on the remote side.

Please be aware that this series except for the remoteproc/ imx_rproc)
has been merged as of v7.2-rc1. I can still send an update to the poll
in imx_mu_generic_tx() but I would prefer an improvement ;)

> Thanks,
> Peng.

Sebastian