From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ot1-f51.google.com (mail-ot1-f51.google.com [209.85.210.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 7B1B1DDAB for ; Wed, 3 Dec 2025 21:50:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764798649; cv=none; b=muY9HMOGL5Wi+JCfVwO6TW8IQb7Bda0E4vkmz/lBqmZM5LJvhTKjaFGqbFC3xiQ7IHLtjytD1JTUzD+njovyBvBpElSL2c3q+Ennl3sGhaZ2kx6NfljR33QWH+WPs7wNaEj6WLS3YvZ8dDg/7BWfRdj6R2e1dDi2XZNfmuHe4vc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764798649; c=relaxed/simple; bh=ZXM2nfJu5oJwY2GOEZGATNrTU2G/aWMWHGcN8Dki1p4=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=uOoATFbFyuS6kqVWcE5C0G+RplxdVR863kaFGgj7VpE2G5n/653VBHOW9DR9NopTpcVULBVj0pY12rwIzS7Pif2MKC3CyhCCOriXldL1AP3xSC0KX+aHZ9FhGB39WHVL5BwIb9TzT/nJ1Q47gjHT2jB+7F2dv1omV3y7GE8EBP4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=baylibre.com; spf=pass smtp.mailfrom=baylibre.com; dkim=pass (2048-bit key) header.d=baylibre-com.20230601.gappssmtp.com header.i=@baylibre-com.20230601.gappssmtp.com header.b=WaYNyBLJ; arc=none smtp.client-ip=209.85.210.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=baylibre.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=baylibre.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=baylibre-com.20230601.gappssmtp.com header.i=@baylibre-com.20230601.gappssmtp.com header.b="WaYNyBLJ" Received: by mail-ot1-f51.google.com with SMTP id 46e09a7af769-7c52fa75cd3so209768a34.3 for ; Wed, 03 Dec 2025 13:50:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20230601.gappssmtp.com; s=20230601; t=1764798645; x=1765403445; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=VOXwn281er3xrUTkTtRg7swbv+pAMR6MbFqtuUChdDQ=; b=WaYNyBLJrWuyLgqV5DLUGQbBREyg2hP0nNHg/p5/IIZQefN8E8qr8ZAbwEPNi4hpZC wqmF6dYqJX51Qt+f71c75ydSBO+GJ3OTT7JWQASsTGR8VU3xxE0F0RCShCu3qAkpPEIt HG08CvCIQn18OR6h9wA/4qA6jooUZGxS4/Xf4KcRACVS6pIVChYAwOGm+sNv/Eux+/0o gfic8zEms9xX61ROEuSJNXfXPgHWROhV0te/2YQeuV/4janzIQuLiDqftX8b1Dt/j0Ax uoIxIor32oAzbZJVMudUi3gDVIrPVmTe+Rntb+YvrRJBt7hXRtSHY6wC55HRB+fx9BQK OAHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764798645; x=1765403445; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=VOXwn281er3xrUTkTtRg7swbv+pAMR6MbFqtuUChdDQ=; b=I1lpEQI/8CqRA2ZM5EGj2tjKEs4qNRFCHtLUaM7F4eFff3+8U/S0Z5tmI/RNoGdUDp Rp1641P9Ez6lldxbQAFKsRfyv3NCgRWAE+ke1hzr75TxDh3e03MwuNc6e4CMOPfxmZQ7 P6ESlWcOp2S1F4pqnrAtZvAIE4KKCCW1oIXaM4OwwSZ5VOSMGryS8zBkysbVUBTyIn0l FG3RcqPttnSAXrWd4dcoq0t12+WkIyKsvVZvLL9xeDhcX+eARy8guj1wE2Rro/avgV5r 4SEN4eLPCTYGzL9m3sWt0Z6i+i6ZdVOSsc8JtA8SM2e2PYx29L4NpXxRCSHc5vLzzBGU 4p0Q== X-Forwarded-Encrypted: i=1; AJvYcCXna1RUfSAvahlqygP5evirv0Gy7mpsFUPDbx97a1iCS5MlB7AlZZTjmYXKFedyzTN3JokhEcHfNHfzWNs=@vger.kernel.org X-Gm-Message-State: AOJu0YwpfMi3Dem6x9G40Hv30Ny72hdCuve14ryvIXKG2P0rIDjhI6gE xCkvubixVxNlWwNt0QS61OVfKabgJ5RZnqp/gxs1jboTY/3XzFLs4TGtPU2QfsUGbyg= X-Gm-Gg: ASbGncsSuoY162HKnqfrzXMxXkde7pl/+eNqpKj6nfooRr5qyvMmno1uWOMRFCfx7TM FxHzv/dfi6bEeqCWoQ9Ip42YVSjnnNfKQs3G7Awox5CixNpch44SmdjVA2tZqt2T6DRRtra9KEa /eW1RdnwilFtMtRRylayLf3ozSawgC2DzATTf1MWWDhW/zloPHVZzBBYvHXeqjjlBpo9rSfk0wd Vm/qXD1Z4zk4qI99WR9XNYvAgrIvwjTtFxKU48kS9+voryy+lXgBM6Vcth7Y6L72CDIdi/LjM98 jpRoJTWAzIcJRoODNLcew8iG9SIgUi7O7eDPVp566psbtF38lcujJF9ModRBNNcW8kjvpvt3xb0 W3VGddVOsvssc7aZrg/RUqjduEns0z82nmDaUUx2tQImfwr6RIjYLhwU0xqsGLCINzcOekjVaXj ocgpa2LFLnA40s+gU= X-Google-Smtp-Source: AGHT+IGUpwPWULKfwpJt6xdvUQml+OeY2AizRJFVIHBX8/UQQAjzB4wdDPV7yTsLxrebEUH9T57tUg== X-Received: by 2002:a05:6830:919:b0:7c7:66f7:2caf with SMTP id 46e09a7af769-7c94dab06dbmr2589753a34.10.1764798645378; Wed, 03 Dec 2025 13:50:45 -0800 (PST) Received: from ?IPV6:2600:8803:e7e4:500:6b05:aad2:5053:6d1? ([2600:8803:e7e4:500:6b05:aad2:5053:6d1]) by smtp.gmail.com with ESMTPSA id 46e09a7af769-7c90f640e61sm9472724a34.13.2025.12.03.13.50.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 03 Dec 2025 13:50:45 -0800 (PST) Message-ID: <3b80f8f3-c435-49f8-8c55-42568215bf0b@baylibre.com> Date: Wed, 3 Dec 2025 15:50:43 -0600 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH RFC 3/6] iio: core: Add cleanup.h support for iio_device_claim_*() To: Kurt Borja , Andy Shevchenko , Lars-Peter Clausen , Michael Hennerich , Jonathan Cameron , Benson Leung , Antoniu Miclaus , Gwendal Grignou , Shrikant Raskar , Per-Daniel Olsson Cc: =?UTF-8?Q?Nuno_S=C3=A1?= , Andy Shevchenko , Guenter Roeck , Jonathan Cameron , linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org, chrome-platform@lists.linux.dev References: <20251203-lock-impr-v1-0-b4a1fd639423@gmail.com> <20251203-lock-impr-v1-3-b4a1fd639423@gmail.com> Content-Language: en-US From: David Lechner In-Reply-To: <20251203-lock-impr-v1-3-b4a1fd639423@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 define > a general GUARD class, and then defining the _direct and _buffer > conditional ones. Commit messages should say why we need this. Also, this seems like two separate things. Adding a new claim/release pair and adding the conditional guard support to the existing ones. So perhaps better as two separate patches. > > 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 *dev, struct iio_dev *indio_dev, > } > EXPORT_SYMBOL_GPL(__devm_iio_device_register); > > +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_dev); > int __devm_iio_device_register(struct device *dev, struct iio_dev *indio_dev, > struct module *this_mod); > int iio_push_event(struct iio_dev *indio_dev, u64 ev_code, s64 timestamp); > +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); > > +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); > +} It was unfortunate that we had to drop "mode" from iio_device_claim_direct_mode() during the recent API change, but at least it is fairly obvious that "direct" 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 until we release the claim". I would call it something like iio_device_{claim,release}_current_mode(). > + > /* > * 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(struct iio_dev *indio_dev) > bool iio_device_claim_buffer(struct iio_dev *indio_dev); > void iio_device_release_buffer(struct iio_dev *indio_dev); > > +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)); > + > extern const struct bus_type iio_bus_type; > > /** >