From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yx1-f52.google.com (mail-yx1-f52.google.com [74.125.224.52]) (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 876BE2FC860 for ; Thu, 4 Dec 2025 17:18:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.224.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764868719; cv=none; b=Wa2PteY39zhBK+/xqnXWpCFlCwzqydN/L6zyrIgwLZpF7JQX3Vt7tC9VF1A1vxS61WV8NY4yBuLBcYH8Z7Yd6crgDTgZSfdGuZRuXRpTcJRH683YUQxixB9BkWc5x6t9kfhp1hAIdj4C29sX4dMYRBV1LY/Bv7+GNfqxOz8psJI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764868719; c=relaxed/simple; bh=w5RO6277pwEdoRV/iCWPDDTJbBvxzyRZV8oInYrd1Ks=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:Subject:From:To: References:In-Reply-To; b=EMbr7IQsuzci4nVMaqjCg2NWkMd/YNC8fwHMt4+rzdncuNphLeLdEDP3n37EMsvmHcKzQzj5elePwjqmRtHJqrM9z29fJeIswMOHjlMXFQcWavdCFv7ZapvQTxys1Rdsl19/BJxiykzzbSp+AyJ9sa88hhtgSY0NTJtn7/U41Ks= 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=EM3+o/sW; arc=none smtp.client-ip=74.125.224.52 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="EM3+o/sW" Received: by mail-yx1-f52.google.com with SMTP id 956f58d0204a3-64107188baeso1009135d50.3 for ; Thu, 04 Dec 2025 09:18:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1764868714; x=1765473514; darn=vger.kernel.org; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-transfer-encoding:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=ivAIPIWdEQpOqShwhFKKKcoQuY7GbJruOniXmCZT+v4=; b=EM3+o/sWuolwQSvrsBLdrRDywsuDMVVObAZtFG3wx18Agi63TSsxFXEK2qKZjiYXAp mAAS64aQYaKT1q/m80jdVdtKgOhARVE6mtK76unjujs9BoLl47rIb2KIM+7cha9+QeH4 BC0Iy/b3bUaMJoIbYT3dywLwtcv0pmejmiZs8rkI0LeawHxGfX/f4J3e/8vg9tMrua73 zGp2lCk99yAlYLm9UgNXDWMeF30jQ1FPhc+IzOJWkQCdMphgp4mTK+z51G3u9JxkMsiq +diDWNIsz6zcxdM5jr3D+tT3bbbL7cvRhIYsUQ4PawLbMKtWDQ3PlUGVU8Q+joNBPCoH s7lA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764868714; x=1765473514; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-transfer-encoding:mime-version:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=ivAIPIWdEQpOqShwhFKKKcoQuY7GbJruOniXmCZT+v4=; b=NBeuWWEw7VVUS8IAp4nLZTqmZyX4UeN3dhX8wWc2aUWFAS4wVwODxqwBUl8SWvR6cY YbLKUjzw7K+/Q7+GlgtNYdlNICyrj109Vifke+HMKG/SmSbjLFzOjEJRkcOjhkwZDWHK +etdewY6X+rhpBs9UW1ogl3x9rhCNJPU2+ZJbrsE5XWycbQFWICGlG2JXHvB3lb3pG0a nzM4UZ7XbOhmoZIl/3CYA2sXHm5EXMPOP8qt66p442OlG9bPM5+ysKBsuVbDnVSRehaj eFd7zMyN3OyTjk3J9f32jV9bDIxy5o5xwCdL+NMnkf0bQsbzYDbZDH+0WuIZscxIaVme Mj9w== X-Forwarded-Encrypted: i=1; AJvYcCXO+ya41xsKTB8jx0P+jCso5Uq+JkL4Y4z1Q0lZ+5s6zzpH/xPGT9SlNOwvwPUETQYQSyQ5YAD5rLHatzA=@vger.kernel.org X-Gm-Message-State: AOJu0YwRPf2fVyZNVUSCVadXig7iJppE/8KTNRowcCWgYqqtIAkWZQAw jxDW38RmDc1CopcLPHLgQCbKaeu12fYsKsOntkWE9MKE/1G5FhsmhdtP X-Gm-Gg: ASbGnctY3sgqYP4X2AZB3d5JTbHMeH1o+AnHuJXDV2CQ7qV14POSwduzG1YzWtyy65S QLbXL7cFs4i6DG2DlCHSopl73l/+ki+0pfsA5A9Jh4DvxXtqW9Nft8ux2jvV0YnG0BocY7Nl3HN ddHC7AqmTZTffQAbhATUvrqDqZhFx//V/s3Fet7GNkUN6wvQ7tjt+glftg2fj+COxN9/cSt2K2y DX9sOKFq/bJVLTDU6lcbl/ZNM5I76w/bRGnCXzqQxVK1R/YHcJyY+AOXwqceD4H3Ew7Dxl9acYD 6uQC6kY1/TVPHBgrurFtGErKeKFBCJ9G8lyf85NcQQApsUV62+cS7Krjz/xmXZFnqLZoEhDvckE pcJWlkiXF1dt24J33Ea5hXhADoz57DYuiwKCFmEMkSR6ak2VyuInjL+UL1WT5D5oTQVPmq7P1sf SUfVy89Q== X-Google-Smtp-Source: AGHT+IFU4LjIIZEnMPIZfgYISjzHy2WuWRbeXPAd/C/KtX4PeTBWdjMsBm52g/3NTmdJv1w+Mg+DCQ== X-Received: by 2002:a05:690e:e8d:b0:640:dda6:e957 with SMTP id 956f58d0204a3-64436ff2772mr5243894d50.36.1764868714036; Thu, 04 Dec 2025 09:18:34 -0800 (PST) Received: from localhost ([2800:bf0:4580:3149:7d4:54b1:c444:6f2f]) by smtp.gmail.com with ESMTPSA id 00721157ae682-78c1b78e5f5sm7330197b3.41.2025.12.04.09.18.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 04 Dec 2025 09:18:33 -0800 (PST) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Thu, 04 Dec 2025 12:18:31 -0500 Message-Id: Cc: =?utf-8?q?Nuno_S=C3=A1?= , "Andy Shevchenko" , "Guenter Roeck" , "Jonathan Cameron" , , , Subject: Re: [PATCH RFC 3/6] iio: core: Add cleanup.h support for iio_device_claim_*() From: "Kurt Borja" To: "David Lechner" , "Kurt Borja" , "Andy Shevchenko" , "Lars-Peter Clausen" , "Michael Hennerich" , "Jonathan Cameron" , "Benson Leung" , "Antoniu Miclaus" , "Gwendal Grignou" , "Shrikant Raskar" , "Per-Daniel Olsson" X-Mailer: aerc 0.21.0-0-g5549850facc2 References: <20251203-lock-impr-v1-0-b4a1fd639423@gmail.com> <20251203-lock-impr-v1-3-b4a1fd639423@gmail.com> <3b80f8f3-c435-49f8-8c55-42568215bf0b@baylibre.com> In-Reply-To: On Wed Dec 3, 2025 at 5:34 PM -05, David Lechner wrote: > On 12/3/25 3:50 PM, David Lechner wrote: >> On 12/3/25 1:18 PM, Kurt Borja wrote: >>> Add guard() and ACQUIRE() support for iio_device_claim_*() lock. >>> >>> This involves exporting iio_device_{claim, release}() wrappers to defin= e >>> a general GUARD class, and then defining the _direct and _buffer >>> conditional ones. >>=20 >> Commit messages should say why we need this. >>=20 >> Also, this seems like two separate things. Adding a new claim/release pa= ir >> and adding the conditional guard support to the existing ones. So perhap= s >> better as two separate patches. >>=20 >>> >>> Suggested-by: Andy Shevchenko >>> Signed-off-by: Kurt Borja >>> --- >>> drivers/iio/industrialio-core.c | 12 ++++++++++++ >>> include/linux/iio/iio.h | 20 ++++++++++++++++++++ >>> 2 files changed, 32 insertions(+) >>> >>> diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio= -core.c >>> index adf0142d0300..da090c993fe8 100644 >>> --- a/drivers/iio/industrialio-core.c >>> +++ b/drivers/iio/industrialio-core.c >>> @@ -2171,6 +2171,18 @@ int __devm_iio_device_register(struct device *de= v, struct iio_dev *indio_dev, >>> } >>> EXPORT_SYMBOL_GPL(__devm_iio_device_register); >>> =20 >>> +void __iio_device_claim(struct iio_dev *indio_dev) >>> +{ >>> + mutex_lock(&to_iio_dev_opaque(indio_dev)->mlock); >>> +} >>> +EXPORT_SYMBOL_GPL(__iio_device_claim); >>> + >>> +void __iio_device_release(struct iio_dev *indio_dev) >>> +{ >>> + mutex_unlock(&to_iio_dev_opaque(indio_dev)->mlock); >>> +} >>> +EXPORT_SYMBOL_GPL(__iio_device_release); >>> + >>> /** >>> * __iio_device_claim_direct - Keep device in direct mode >>> * @indio_dev: the iio_dev associated with the device >>> diff --git a/include/linux/iio/iio.h b/include/linux/iio/iio.h >>> index 27da9af67c47..472b13ec28d3 100644 >>> --- a/include/linux/iio/iio.h >>> +++ b/include/linux/iio/iio.h >>> @@ -10,6 +10,7 @@ >>> #include >>> #include >>> #include >>> +#include >>> #include >>> #include >>> #include >>> @@ -661,9 +662,23 @@ void iio_device_unregister(struct iio_dev *indio_d= ev); >>> int __devm_iio_device_register(struct device *dev, struct iio_dev *ind= io_dev, >>> struct module *this_mod); >>> int iio_push_event(struct iio_dev *indio_dev, u64 ev_code, s64 timesta= mp); >>> +void __iio_device_claim(struct iio_dev *indio_dev); >>> +void __iio_device_release(struct iio_dev *indio_dev); >>> bool __iio_device_claim_direct(struct iio_dev *indio_dev); >>> void __iio_device_release_direct(struct iio_dev *indio_dev); >>> =20 >>> +static inline void iio_device_claim(struct iio_dev *indio_dev) >>> + __acquires(indio_dev) >>> +{ >>> + __iio_device_claim(indio_dev); >>> +} >>> + >>> +static inline void iio_device_release(struct iio_dev *indio_dev) >>> + __releases(indio_dev) >>> +{ >>> + __iio_device_release(indio_dev); >>> +} >>=20 >> It was unfortunate that we had to drop "mode" from iio_device_claim_dire= ct_mode() >> during the recent API change, but at least it is fairly obvious that "di= rect" >> is a mode. Here, dropping "mode" from the name hurts the understanding. = These >> could also use some documentation comments to explain what these are for= and >> when it is appropriate to use them. I had to really dig around the code = to >> come to the understanding that these mean "don't allow switching modes u= ntil >> we release the claim". I agree. >>=20 >> I would call it something like iio_device_{claim,release}_current_mode()= . >>=20 >>=20 >>> + >>> /* >>> * Helper functions that allow claim and release of direct mode >>> * in a fashion that doesn't generate many false positives from sparse= . >>> @@ -690,6 +705,11 @@ static inline void iio_device_release_direct(struc= t iio_dev *indio_dev) >>> bool iio_device_claim_buffer(struct iio_dev *indio_dev); >>> void iio_device_release_buffer(struct iio_dev *indio_dev); >>> =20 >>> +DEFINE_GUARD(iio_device_claim, struct iio_dev *, iio_device_claim(_T), >>> + iio_device_release(_T)); >>> +DEFINE_GUARD_COND(iio_device_claim, _buffer, iio_device_claim_buffer(_= T)); >>> +DEFINE_GUARD_COND(iio_device_claim, _direct, iio_device_claim_direct(_= T)); >>> + > > When I made the comments about keeping "mode" in the name, I forgot > that DEFINE_GUARD_COND() only extends a DEFINE_GUARD(). So I understand > if we need to make names that fit a certain pattern rather than what > I suggested. > > Still would be nice to have: > > iio_device_claim_mode() > iio_device_claim_mode_direct() > iio_device_claim_mode_buffer() > iio_device_release_mode() > > Just really annoying to rename iio_device_{claim,release}_direct() > everywhere since we just did that. We could keep both names around > for a while though to avoid the churn. If we rename iio_device_claim_direct() (which is huge), maybe we can pick shorter names and more descriptive names while at it? I was thinking something like: iio_mode_lock() iio_mode_lock_direct() iio_mode_lock_buffer() iio_mode_unlock() Shorter names will also keep lines short when using guards. > > It also means that we should remove __iio_device_release_direct() and > iio_device_release_buffer_mode() to make it clear that there is only > a single "release" function used by all variants of "claim". I agree. --=20 ~ Kurt