linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Cristian Ciocaltea <cristian.ciocaltea@gmail.com>
To: Rolf Eike Beer <eb@emlix.com>
Cc: Manivannan Sadhasivam <mani@kernel.org>,
	Lee Jones <lee.jones@linaro.org>,
	linux-actions@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: atc260x has broken locking
Date: Fri, 25 Feb 2022 01:14:03 +0200	[thread overview]
Message-ID: <20220224231403.GA539966@ubuntu2004> (raw)
In-Reply-To: <16136311.TfV2VxeR0u@mobilepool36.emlix.com>

Hi Eike,

On Wed, Feb 23, 2022 at 12:07:48PM +0100, Rolf Eike Beer wrote:
> When looking at this functions I found the locking to be broken for the atomic 
> case (comments stripped):
> 
> static void regmap_lock_mutex(void *__mutex)
> {
> 	struct mutex *mutex = __mutex;
> 
> 	if (system_state > SYSTEM_RUNNING && irqs_disabled())
> 		mutex_trylock(mutex);
> 	else
> 		mutex_lock(mutex);
> }
> 
> static void regmap_unlock_mutex(void *__mutex)
> {
> 	struct mutex *mutex = __mutex;
> 
> 	mutex_unlock(mutex);
> }
> 
> When the mutex is already locked and the atomic context is hit then the lock 
> will not be acquired, this is never noticed, and it afterwards is unlocked 
> anyway.
> 
> The comment says this is inspired from i2c_in_atomic_xfer_mode() to detect the 
> atomic case, but the important caller __i2c_lock_bus_helper() actually does 
> check and pass on the return value of mutex_trylock(), which is missing here.

This is indeed a limitation of the current implementation because the
main goal was to offer initial support for SBC poweroff and reboot
use cases, which were the only cases where the atomic context kicks in.

Hence it was more important to make sure those operations are triggered
rather than failing due to an error condition which is hard to be
handled properly - e.g. getting a behaviour similar with the '-EGAIN'
scenario in the I2C implementation.

As a matter of fact the tests I made so far using a RoseapplePi board
didn't reveal any problems, but I will try to do some more extensive
testing and see if the issue becomes visible eventually. Then it would
be easier to try some possible solutions/workarounds.

Out of pure curiosity, on which hardware do you plan to use this, if you
haven't already?

Thanks,
Cristian

> Greetings,
> 
> Eike
> -- 
> Rolf Eike Beer, emlix GmbH, https://www.emlix.com
> Fon +49 551 30664-0, Fax +49 551 30664-11
> Gothaer Platz 3, 37083 Göttingen, Germany
> Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
> Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055
> 
> emlix - smart embedded open source



  reply	other threads:[~2022-02-24 23:14 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-23 11:07 atc260x has broken locking Rolf Eike Beer
2022-02-24 23:14 ` Cristian Ciocaltea [this message]
2022-02-25  7:36   ` Rolf Eike Beer

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=20220224231403.GA539966@ubuntu2004 \
    --to=cristian.ciocaltea@gmail.com \
    --cc=eb@emlix.com \
    --cc=lee.jones@linaro.org \
    --cc=linux-actions@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mani@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).