From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ua1-f49.google.com (mail-ua1-f49.google.com [209.85.222.49]) (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 E79D92ED844 for ; Thu, 4 Dec 2025 17:31:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764869471; cv=none; b=e6HSycNRQqQrsYIuKsnYzlM0CFR0LIfUUN5UvG7U/XEMJx2W7Vld+qqbtMMi00noDTlvqVVPcyLXK6TW1x+wT5/fFu7uitxdPCSS+jRvrhqxRDRQU9Pfuwmd46jRbc75eDUe0tCZgH3xw4BP1SvzceSt6n2P7nNqDIPLQJwsMWY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764869471; c=relaxed/simple; bh=Esx9mFokG/UV+AY7kqpOxxAjdUm5ixVVhSJ6k0ZcV+I=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:Subject:From:To: References:In-Reply-To; b=DQ1zUeL1/2oVgvdvfeoOrBj2+ZQtQ/rr6jxqfWpd65H7KIi1KKIplHUGHVNDfCZeF+j2yQuUgnz/7CdoEx9qKpr9DJLnMcI77DZ8gRjR+qWqk0BM6tZ71ADefngfIyFUQe6OV7oyZWLhlK0QVU6T27e7HX8plHFBsxiaXmCumc0= 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=cT4yX61j; arc=none smtp.client-ip=209.85.222.49 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="cT4yX61j" Received: by mail-ua1-f49.google.com with SMTP id a1e0cc1a2514c-9372149216bso729604241.3 for ; Thu, 04 Dec 2025 09:31:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1764869469; x=1765474269; 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=vw+EvpNnPRJxP20IZuJNEAzYLUTff2US5yBiiE9zOkw=; b=cT4yX61jaracH18ksyYPeg2prQmzU9ZIvH2M5sXkmUQflXOL15XGYjlIrHcchhvk4t JHgS+Pu/nN6JXL8Fwa0mOda8Yv460/KmZT76jeTPiMFE1gUHR0701+7uOivLPeBQz44H SZ2Ptt1IiclsHEq2kG4x7g70U2tAW79Fr7boXWtQA63KQWHkHHC1Pv9FM68xmh/DNCZQ 6PJusDbgsYnX961E73PubKAFHCWO7uK+sBCqC03dj9XalrNe/x6j75sBZEt29jL/1VX6 rbp3vOIa40z8d/4K0XZ93SKsT1hVc5lnsA7kZaJt+H34j7Q4UYP7hvs4PxeF1toNr8+u b7Mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764869469; x=1765474269; 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=vw+EvpNnPRJxP20IZuJNEAzYLUTff2US5yBiiE9zOkw=; b=RoRhWZ4+r4MDpp49FZxQs8IJNsDoz4/B8Ae1N2FPbl1Dev/mzfCJUBFr9b2WuWK9p5 1jk4WEo/IQ88GqgL6hnLc16gz8bLuoK9BELOp2eBGUxcCX3FfGlxiz6SCtLHRfFbywTU BKyP6vb90oIDMDVscGVG9sn01SalrISOeVm6A5iLo9gQVThNl61quWFEylPkOp/aWN1n Bu8Qgy8Fs7tOgmbAchGfQSWCF9EQZosLzZMk2kR9h6zNfxJ076JC2PQ1RlGLcH/kbDLk 3eHah1nGGHMTO4u4ex5apf5l/pCYLOmzF1JBYdD7B1gTEqct+eveaXbdHfio/2w8pQ9e LanA== X-Forwarded-Encrypted: i=1; AJvYcCV6CiZpCgW3LrRuM+XyUU7QnRy5ziqyQd4O2sxtLI2n1VsjV0hWrH28t6upycwCrYFFhkhYU+8uVVnM4vU=@vger.kernel.org X-Gm-Message-State: AOJu0YzCnYy2ZBuorxcy9CND5WkigFStehKPgMdtATrc+htFRe8kdouk e+rSdmtTTlDG6xC7Qv/gLnATHXsa6DAJScJ0MuwfYZU4EVTZ2abI3Pss X-Gm-Gg: ASbGncsesWy1enREE5HdlpaTBoDvw9u44AM1L9l+80ZNlLeyu1cljWlLGucsDp4zBNT Ujflr0b0fDHDcpbYeGcVMVGiyp9zd58pl/+4Aw0LzCJi9pr3Cbqe5jA/SwyXzHg+kiahuq1H8jG h/OahfTL9TXjb8c13akrtCAzyiZQk/4pl/FZMM0UU2cyFrntLRKJ8T8EB1lZXSS5K1dl1roPvD0 CFlKDNt/L9sZoiv8kSB7TK2fejiqUkwvAKZggVbbqQ2O8iDd70XQKegAKlENx6btnKDVBQhW54f qGOycyTF/wPhssFdNshBZTzbSkOHa5NPGPcO1Rmr1bGyfgwyIx05Ju8jtNONtXCp5IZyiPGanP9 dOsY6eHcSGJ/2/d9FG99dp/qoFI5IHjpXiTSjEzKrBXr9/sLL78IYGO9cLXOOyWFckFy4unlSZ2 gNadjmCw== X-Google-Smtp-Source: AGHT+IEQujdux4QraYp2XErML+qKO/H8lj6CXVbdb1YysmjPx5gDd7EVF0btGcmqCZdDMC/Z/LMbkw== X-Received: by 2002:a05:6102:510e:b0:5db:e851:9395 with SMTP id ada2fe7eead31-5e50685ba09mr1439059137.7.1764869464743; Thu, 04 Dec 2025 09:31:04 -0800 (PST) Received: from localhost ([2800:bf0:4580:3149:7d4:54b1:c444:6f2f]) by smtp.gmail.com with ESMTPSA id ada2fe7eead31-5e5107cbc30sm962080137.1.2025.12.04.09.31.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 04 Dec 2025 09:31:04 -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:31:02 -0500 Message-Id: Cc: "David Lechner" , =?utf-8?q?Nuno_S=C3=A1?= , "Andy Shevchenko" , "Guenter Roeck" , "Jonathan Cameron" , , , Subject: Re: [PATCH RFC 6/6] iio: light: opt4060: Use cleanup.h for IIO locks From: "Kurt Borja" To: =?utf-8?q?Nuno_S=C3=A1?= , "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-6-b4a1fd639423@gmail.com> <17ac2fa9033104c3bf9260fbecc1c9a5b42fcbba.camel@gmail.com> In-Reply-To: <17ac2fa9033104c3bf9260fbecc1c9a5b42fcbba.camel@gmail.com> On Thu Dec 4, 2025 at 9:42 AM -05, Nuno S=C3=A1 wrote: > On Wed, 2025-12-03 at 14:18 -0500, Kurt Borja wrote: >> Simplify and drop "hacky" busy-waiting code in >> opt4060_set_driver_state() by using guard(). >>=20 >> Signed-off-by: Kurt Borja >> --- >> =C2=A0drivers/iio/light/opt4060.c | 52 +++++++++++++++------------------= ------------ >> =C2=A01 file changed, 17 insertions(+), 35 deletions(-) >>=20 >> diff --git a/drivers/iio/light/opt4060.c b/drivers/iio/light/opt4060.c >> index 500899d7bd62..903963606143 100644 >> --- a/drivers/iio/light/opt4060.c >> +++ b/drivers/iio/light/opt4060.c >> @@ -22,6 +22,7 @@ >> =C2=A0#include >> =C2=A0#include >> =C2=A0#include >> +#include >> =C2=A0 >> =C2=A0/* OPT4060 register set */ >> =C2=A0#define OPT4060_RED_MSB 0x00 >> @@ -302,41 +303,22 @@ static int opt4060_set_driver_state(struct iio_dev= *indio_dev, >> =C2=A0 =C2=A0=C2=A0=C2=A0 bool continuous_irq) >> =C2=A0{ >> =C2=A0 struct opt4060_chip *chip =3D iio_priv(indio_dev); >> - int ret =3D 0; >> -any_mode_retry: >> - if (!iio_device_claim_buffer(indio_dev)) { >> - /* >> - * This one is a *bit* hacky. If we cannot claim buffer mode, >> - * then try direct mode so that we make sure things cannot >> - * concurrently change. And we just keep trying until we get one >> - * of the modes... >> - */ >> - if (!iio_device_claim_direct(indio_dev)) >> - goto any_mode_retry; >> - /* >> - * This path means that we managed to claim direct mode. In >> - * this case the buffer isn't enabled and it's okay to leave >> - * continuous mode for sampling and/or irq. >> - */ >> - ret =3D opt4060_set_state_common(chip, continuous_sampling, >> - =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 continuous_irq); >> - iio_device_release_direct(indio_dev); >> - return ret; >> - } else { >> - /* >> - * This path means that we managed to claim buffer mode. In >> - * this case the buffer is enabled and irq and sampling must go >> - * to or remain continuous, but only if the trigger is from this >> - * device. >> - */ >> - if (!iio_trigger_validate_own_device(indio_dev->trig, indio_dev)) >> - ret =3D opt4060_set_state_common(chip, true, true); >> - else >> - ret =3D opt4060_set_state_common(chip, continuous_sampling, >> - =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 continuous_irq); >> - iio_device_release_buffer(indio_dev); >> - } >> - return ret; >> + >> + guard(iio_device_claim)(indio_dev); >> + >> + /* >> + * If we manage to claim buffer mode and we are using our own trigger, >> + * IRQ and sampling must go to or remain continuous. >> + */ >> + if (iio_buffer_enabled(indio_dev) && iio_trigger_using_own(indio_dev)) >> + return opt4060_set_state_common(chip, true, true); >> + > > I think that if we are open coding lock(mlock) plus iio_buffer_enabled, t= hen > iio_device_claim kind of loses it's real meaning. To me > > guard(iio_device_claim)(indio_dev); > > it's basically iio_dev_lock It is! That's why I think if we go down this route we should rename the API as proposed in [1]. [1] https://lore.kernel.org/linux-iio/DEPLQT84HBAO.2GAY5BHP05HNL@gmail.com/ --=20 ~ Kurt