From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f51.google.com (mail-ej1-f51.google.com [209.85.218.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 667A03DEFF6 for ; Tue, 25 Aug 2026 10:17:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787653029; cv=none; b=sNCqG8XNEyn1e3d11+vqYPVr3siIjb+YsCXKQbCfEj3VsnqJK1Xp40Yw6zPwvU7H/v992JdWiY4ZVycoev5zqM1IpqXAI3J9yze+6rY1JHErqlQAO/okNE65Gkk8t0ZyzaDAr1FJDQBDoYtkDKB8Uaj/uWWVr7XetwjQzRyXvkk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787653029; c=relaxed/simple; bh=DylEgGTC2ZmoMOn5+eHkLb886mOOmT3l5cOVBuayCvE=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=IbF28XowFuYV0BMNHKdS/aq2ALu34ikqp37mpPH6L7DkuUa12aXpPtjevT/nrolzHTddY3o5ofdUtcD09zyU93nPnt9BKi2VcnB3iStw9tLpQKd7dOd3SN3vHY9iCtr54q1rwIOmAGQ9R7FAGZfhgVjb0Ofdfd0UWG7g+uc2fr4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=SvPNPMDE; arc=none smtp.client-ip=209.85.218.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="SvPNPMDE" Received: by mail-ej1-f51.google.com with SMTP id a640c23a62f3a-c2020421077so780934666b.3 for ; Tue, 25 Aug 2026 03:17:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787653027; x=1788257827; darn=vger.kernel.org; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=obDo/k9wFAw+PAwhVDyJ3UlS7CKTwOSt/1gZeRxnOT8=; b=SvPNPMDEE+ar8U0t8nKtrM3A62+j/e3qTTxmYSa64ZvQcJ46/07oK23/n+lEnAGqbl Gu8ABt12kfk9NB9IVFXjV4wP+JNW4taog45HDFyVWTqXH02I97RAK2zN7+SOuDA3asIx 4FG4RZgTaNJzW/QZwmdUiPNqNiOhSwM97IN6wHfqlhlJPDiA4BCw3vuV0bayprC/qUCI mIa182fukrKo7u4o0y+IFpG3dzD1nQ5TPu+LpDQeFMCsNamrdkR//q5bdx1AAUJe1r+l UxQ1apBtMaVv9OP+8AqgR1ZTwL32KWvwr9rPzCJRyV0rjtBufMDp8tCTv1YfMcAFxBAW s9Gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787653027; x=1788257827; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=obDo/k9wFAw+PAwhVDyJ3UlS7CKTwOSt/1gZeRxnOT8=; b=BYlIWw3aXr8ijbyey+kRxU8WoOQEKz9Z/187+yWTfRGNk3Q65jWavCvi94AWLjrYom TS81z/89mhK3PaRwqMOtO8cWoiS1ze1CNS8j1NZvqKgyYreJ8S4VqJiPItnNRxVfkgdt 7NuXioaGJcL6llPNEEZaj9CAWHwnclpq17gSq6/4023lt9561PigJWR+XBon8Nvjdn9t U0qdeKMkAuQ9iKVPZ4NVfc3jcJW9M7OS3sJzA6fwiCBrzWiIzdOv1vSCiVEiYAVLjqNK kYHSdXaMjxD1BindZNmWbPq01svNwPu2EfuwvxPR+7K/wCF5Ndu4XIsBJhrXXEcHeaB7 8uJA== X-Forwarded-Encrypted: i=1; AHgh+RoFtbfWZGAzcT1JgUW0ImuwwsvEkT0MvvOojT0P/p4JaPWRmsvoXYqR1MfkAnrLGTcLqcajvG0Kvy22ieY=@vger.kernel.org X-Gm-Message-State: AFuF++lUPGIGQGD/j84PHJ55wDr9vUloNaHc1AdX+HnoDGfAt2ZMtAvw Zv7qg6MV/eppYY2SjkKi2fBuzUzj0wWVtTUHwoHMEP9rL6fbra2EFltb X-Gm-Gg: AR+sD11o3tzP53Etmbl6v6O/xZM0VjkBI5YXUGYGRtxbQ58FbPhN8+VQET6QVnmPvnI sAJvLokxsDaRLA7anG4PyXnHOlu0ieAPU3LyowAl2DNB02FK04Cm+uJ1aSwbApm2UMpPOjOn6ZH Z5dyz+VXhHPy6ZAIO+yBMRM0mrE5x0RoOtExgR+AcpVuKMqDJvE+FChL4AGt0Ss9WMxKVKgFz/r YgNvBI2maNe3AH0e4OCHMHKEAOEViSvCpQjGcuFVwd5O27370KflSM23OE+zJH6K/UtltLFwexP 5h3Sb4XoOInuQZ82PK8g2ZO3/xhu4t5sfspQD3INNaBrLrxbK1FamV34svjwzshL8D5BQGABHQo LJNKq7nc4HTS6wHw/uhjc9v3JYjxE8N8/dHynY80H0z/dbLV8d7ys7P/Qs0c26hI0XuHuheC8gP MaPV6Dq0le2TL/6qkpX6fRJf0Glsa0KwR8deL6gn9T1pUEgN+aoeoFpYdF9TeESxHGkb4wrHMgY ohQH84SRWMUpAQLnYIh0j7CpBpA+OhBf5r6Dx0/L1Rm56ccGA9owpbhQao2HzGtXL3jeD1aNgz7 fl/nVkYLs5FCCpJQ7D1K+EYfTsEdEHkRneFsRaoCp1P007PgkQIV3GQ8KoFQp6uM5qCKZd6x19w 8aktrR6kKjibZ/4J5lXEkgl6PuXJxJVQtEiDO9TOfYTAAsQZp/fuxSM0XAD/+5sElNwJvtw== X-Received: by 2002:a17:907:1983:b0:c16:66dc:3ab7 with SMTP id a640c23a62f3a-c2491ccca9emr2777700466b.10.1787653026209; Tue, 25 Aug 2026 03:17:06 -0700 (PDT) Received: from localhost (90-182-112-124.rcp.o2.cz. [90.182.112.124]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c24966fa8aasm1800093566b.34.2026.08.25.03.17.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 25 Aug 2026 03:17:06 -0700 (PDT) Date: Tue, 25 Aug 2026 12:17:04 +0200 From: Joshua Crofts To: Esben Haabendal , linux-iio@vger.kernel.org, devicetree@vger.kernel.org Cc: Jonathan Cameron , Lars-Peter Clausen , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Martin Kepplinger , Sean Nyekjaer , David Lechner , Nuno =?ISO-8859-1?Q?S=E1?= , Andy Shevchenko , Martin Kepplinger , Christoph Muellner , linux-kernel@vger.kernel.org Subject: Re: [PATCH v6 7/9] iio: accel: mma8452: Drop unneeded lock acquire on read Message-ID: <20260825121704.00004ed3@gmail.com> In-Reply-To: <20260825-mma8452-open-drain-v6-7-9b252804ee80@geanix.com> References: <20260825-mma8452-open-drain-v6-0-9b252804ee80@geanix.com> <20260825-mma8452-open-drain-v6-7-9b252804ee80@geanix.com> X-Mailer: Claws Mail 4.4.0 (GTK 3.24.51; x86_64-w64-mingw32) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Tue, 25 Aug 2026 10:27:45 +0200 Esben Haabendal wrote: > There is no need to acquire data->lock when calling mma8452_read(), and > dropping that makes it less likely to end up in an AB-BA deadlock > situation. > > Signed-off-by: Esben Haabendal > --- > drivers/iio/accel/mma8452.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c > index 7ef1a9a91c31..9ae2c3e60576 100644 > --- a/drivers/iio/accel/mma8452.c > +++ b/drivers/iio/accel/mma8452.c > @@ -504,9 +504,7 @@ static int mma8452_read_raw(struct iio_dev *indio_dev, > if (!iio_device_claim_direct(indio_dev)) > return -EBUSY; > > - mutex_lock(&data->lock); > ret = mma8452_read(data, buffer); > - mutex_unlock(&data->lock); > iio_device_release_direct(indio_dev); > if (ret < 0) > return ret; > Sashiko has something to say and I tend to agree at the moment: Could removing this lock expose mma8452_read() to race conditions with PM auto-suspend and event configuration? mma8452_read() can be interrupted by the PM auto-suspend worker, which puts the device in STANDBY and disables regulators while mma8452_drdy() is actively polling over I2C. This can lead to I/O timeouts or errors. Additionally, concurrent sysfs writes to event configurations invoke mma8452_change_config(), which puts the hardware into STANDBY to modify registers. The Standby transition flushes the hardware FIFO. If this occurs between the mma8452_drdy() check and the i2c_smbus_read_i2c_block_data() in mma8452_read(), the block read will fetch flushed or stale data. -- Kind regards, Joshua Crofts