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

[Diogo Ivo]

On 5/20/26 18:44, Dmitry Osipenko wrote:
> 20.05.2026 19:23, Mark Brown пишет:
> > 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.
>
> Sounds bad
>
> Diogo, check if shutdown works with added nosmp to kernel's cmdline.

So to be clear shutdown already works with regmap_update_bits() and I
have never encountered this deadlock in my testing as the write to power
off the PMIC needs to happen at a very specific timing. I imagine adding
nosmp will just guarantee that the deadlock can never happen.

> BTW, you can use i2c_smbus_read_byte_data+i2c_smbus_write_byte_data to
> keep the old regmap_update_bits behaviour.

My question here is more if this is actually needed or we can skip the
read. In any case the patch that Lee merged is with regmap_update_bits()
so for the time being this is not a problem.

Best regards,
Diogo