All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Osipenko <digetx@gmail.com>
To: Diogo Ivo <diogo.ivo@tecnico.ulisboa.pt>,
	Mark Brown <broonie@kernel.org>, Lee Jones <lee@kernel.org>
Cc: linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH] mfd: max77620: Avoid regmap mutex deadlock in power-off handler
Date: Wed, 27 May 2026 10:32:58 +0300	[thread overview]
Message-ID: <7cc7626a-ba83-46bb-9a52-325d84bcdfb1@gmail.com> (raw)
In-Reply-To: <6017863a-6587-4b6d-8c10-ade27fbafc2c@tecnico.ulisboa.pt>

21.05.2026 12:19, 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.
I'd suggest not to change anything if there is no real problem.
Otherwise you pleasing ai bot without understanding the problem, maybe
problem doesn't exist in practice.


  reply	other threads:[~2026-05-27  7:33 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-20 14:28 [PATCH] mfd: max77620: Avoid regmap mutex deadlock in power-off handler Diogo Ivo
2026-05-20 14:42 ` Dmitry Osipenko
2026-05-20 14:59   ` Diogo Ivo
2026-05-20 16:19     ` Lee Jones
2026-05-20 16:23       ` Mark Brown
2026-05-20 16:44         ` Dmitry Osipenko
2026-05-21  9:19           ` Diogo Ivo
2026-05-27  7:32             ` Dmitry Osipenko [this message]
2026-05-21  9:14         ` Diogo Ivo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7cc7626a-ba83-46bb-9a52-325d84bcdfb1@gmail.com \
    --to=digetx@gmail.com \
    --cc=broonie@kernel.org \
    --cc=diogo.ivo@tecnico.ulisboa.pt \
    --cc=lee@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.