Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 25 Feb 2022 01:14:03 +0200
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
Message-ID: <20220224231403.GA539966@ubuntu2004>
References: <16136311.TfV2VxeR0u@mobilepool36.emlix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <16136311.TfV2VxeR0u@mobilepool36.emlix.com>
Precedence: bulk

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