Re: [PATCH] mfd: max77620: Avoid regmap mutex deadlock in power-off handler

[Diogo Ivo]

On 5/20/26 18:23, Mark Brown wrote:
> On Wed, May 20, 2026 at 05:19:00PM +0100, Lee Jones wrote:
> > On Wed, 20 May 2026, Diogo Ivo wrote:
>
> > > This patch was motivated by the Sashiko review I got in [1]. Its point
> > > here is that there is a possibility for a deadlock scenario in which
> > > a secondary CPU obtains the mutex for the regmap and then smp_send_stop()
> > > is called before this secondary CPU gets a chance to release the mutex,
> > > making it so that when the primary CPU tries to acquire it to issue the
> > > write it hangs. Is there something that I am misunderstanding here?
>
> > It's my understanding that using the Regmap wrappers _prevents_ locking
> > issues, rather than causes them.
>
> In the case where the CPU is being powered off during a regmap write
> there is a potential issue - as Diogo says if we're in the middle of
> holding the lock and we power off the CPU that owns the lock then it
> will never be able to release the lock.  I would expect the same issue
> to apply to a bus like I2C or SPI though, they'll hold a lock while
> they're in the middle of doing bus I/O unless you use some special API.

In that case can we call __i2c_smbus_xfer() directy from
max77620_pm_power_off()? Or is that unsafe because it can interfere with
an ongoing transfer? In essence my question is what can we do about
this, Sashiko suggested to move the handler to 
SYS_OFF_MODE_POWER_OFF_PREPARE
but I believe that that would/could be too soon.

Best regards,
Diogo