From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com [209.85.128.44]) (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 848952D0C84 for ; Tue, 9 Dec 2025 10:33:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765276417; cv=none; b=lFe8vrSM7rjZA3LKMS+vMdZFjEBA4tgj4eSWQcBudAM9jn3XK2a9yWhLFn8dFCu+91b+Z2WvcajLQmM1VhqcwtAwjMqBZTuRnWoYe/drMdIYD7HOHhVRQojTS9lIA5ugXnPtqOmGxTfyrSsf65GdHS3exCdDOxZQZleYmn92zzY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765276417; c=relaxed/simple; bh=6vUYZ7ZB1XA9z9XfSJy6LYoyZNPS3TghgWHThsU7xZg=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=uhIDsfP+HafWJ19NK1OOqkp9iDM3TGJfP4angjqe1ZK/9gxlTDeZufxDhyAGsNctaC9uy2MXldYY3/ynAWuf+oTwdy3xZrAL4pQZFebau9yBkN+z/XKOpiKZ7GZ5IfgNezeM+rz26ciLjKNEc4yvzi6d8HAXuz5FJ87h3jpDsQo= 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=FXJPCgqN; arc=none smtp.client-ip=209.85.128.44 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="FXJPCgqN" Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-4779a637712so40292875e9.1 for ; Tue, 09 Dec 2025 02:33:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1765276414; x=1765881214; darn=vger.kernel.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=6vUYZ7ZB1XA9z9XfSJy6LYoyZNPS3TghgWHThsU7xZg=; b=FXJPCgqNR2x07Ds+wUdit0Ax7Vpt0t9xLQ4SQDrFB0MQHGF85CcLG+nVr3aG/rtxnQ oWMBO8EFFbOMyQRFhog5HAkr9EvbyQEQs64LLp3NSLBb3AWgxDJLUt0BWPy1wcJmioX/ rZQemYn/vYPgZif62SJy9xc9BvTtVmnL9K3RbqcXg/O96n2NXJhIajxV6sPmPssoGzTX 1dQX12tL9VvG8jaPfgSt+TUQIhZrYH1BVA8O+OxT8AVPSdh7+G0nv2FOAsG2kAUJUlfc k+rsrJ/vXFv/lC0ncJrz+lleg10QXGWnti8fqy1FSJ2x8UyYOSHJhdideHKrWXx/ejdx 050Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765276414; x=1765881214; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=6vUYZ7ZB1XA9z9XfSJy6LYoyZNPS3TghgWHThsU7xZg=; b=T+2ZTryion5tleL7CGhD9AtmglNOwxucO0iM0h/8TIr5r4LgI6AcSiGG5cs24LCTBZ sPvvYE2gWzwGy0vjbN1XQGAc6HcdOOwx6swJV0ICC0TUUK4dCkbwGoSW/BR8m6DHqXXQ 0q4a+vBsWdCnF4L/ID9GgsHMQcQddOdmHMVLOg8m9B6WDFnYDS6dUQibtvKjplLetGix ZP/J+fscPIZVfEQaZshKMODmJiXsULfAJFrxWNxPq3FKbnik29KOti5AUQT5E+Sj/je4 u3Nu8cpzON6qNNIPIqCdseEIk7paPcwiU+930VS9KMz3pCSc4s9MFQVlMUVuwXoNM3QG gJhw== X-Forwarded-Encrypted: i=1; AJvYcCUTIoF10QKkcjA5CMmtZrldZU2no1xpR3kVpXraU8G8uI5XGbXoprroPwsMyemcO6PP8Jy9oBlUZu6SsWQ=@vger.kernel.org X-Gm-Message-State: AOJu0YyH/9LduP0YOQkFNzS5f1SLc1K4/30d0KXN7SEWUvMkr/drpxwy Ozm7G7xUQburMmIpwZhWN7SONWsO+i9mKC70rKffNQKAB9mLdarMca+P X-Gm-Gg: ASbGncv5b9q7fy59cUQG/mhqe8TecyWfdepJonOioBPW+jhyZBcqa4QoIPOEVbM1ImI FBumScEyxirSOEAzntnf93IYmd+21Y9GPAv/nwiq6BMy1eyCqqPxvUt7eSSYGz5rYRC/vYk1ELI tLbh8LNy88YdsWF/3/+gJ4oOQr0sDk8ScTN8uweN4MXhSblFhX7b7uSAIqnzYx+k+cP+qOm2Tv8 /NFLDHxsg80BBHvLcJJS0a+CXko4c8GTy1tP+gI+dnMZXk/1hs72e2qDZKSCFZNmdZH8ZWluDtw T+y+NZYGZUnRzT3DjIMByBuvR5RW/QBbFmb7IBTvMj/+NtMyrekOHaOYrmUnqZvGkHRa0nxbagT 7drwBvewiLNFpkclHL4iCVWTkF6b85ogjv06E2byNPDavP/BJkWGgb0aveeXc6jrpsb3tmBiIov yMT1RI3SVjVl17HrMV1hs= X-Google-Smtp-Source: AGHT+IGZQrJg+7CP7PO6TcoDaHyiNMGgsBliDZ1Lgu0m6bB12DU/JkBOondvRTh7wk+YcAEp6Q+UiQ== X-Received: by 2002:a05:600c:a43:b0:47a:75b6:32c with SMTP id 5b1f17b1804b1-47a7b17cfdfmr29371385e9.2.1765276413463; Tue, 09 Dec 2025 02:33:33 -0800 (PST) Received: from [192.168.1.187] ([161.230.67.253]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47a7d3749bbsm15685995e9.3.2025.12.09.02.33.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 09 Dec 2025 02:33:33 -0800 (PST) Message-ID: <54483083c42cf7500239ebb7c0d32d25f11bb02f.camel@gmail.com> Subject: Re: [PATCH RFC 0/6] iio: core: Introduce cleanup.h support for mode locks From: Nuno =?ISO-8859-1?Q?S=E1?= To: Jonathan Cameron , Andy Shevchenko Cc: Kurt Borja , Andy Shevchenko , Lars-Peter Clausen , Michael Hennerich , Benson Leung , Antoniu Miclaus , Gwendal Grignou , Shrikant Raskar , Per-Daniel Olsson , David Lechner , Nuno =?ISO-8859-1?Q?S=E1?= , Andy Shevchenko , Guenter Roeck , Jonathan Cameron , linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org, chrome-platform@lists.linux.dev Date: Tue, 09 Dec 2025 10:34:13 +0000 In-Reply-To: <20251206184645.51099254@jic23-huawei> References: <20251203-lock-impr-v1-0-b4a1fd639423@gmail.com> <77ca77847511e67066a150096a7af2fb84f1f25f.camel@gmail.com> <20251206184645.51099254@jic23-huawei> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.58.2 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 On Sat, 2025-12-06 at 18:46 +0000, Jonathan Cameron wrote: > On Thu, 4 Dec 2025 17:07:28 +0200 > Andy Shevchenko wrote: >=20 > > On Thu, Dec 4, 2025 at 4:35=E2=80=AFPM Nuno S=C3=A1 wrote: > > > On Wed, 2025-12-03 at 14:18 -0500, Kurt Borja wrote:=C2=A0=20 > > > >=20 > > > > In a recent driver review discussion [1], Andy Shevchenko suggested= we > > > > add cleanup.h support for the lock API: > > > >=20 > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 iio_device_claim_{direct,buffer_mode= }().=C2=A0=20 > > >=20 > > > We already went this patch and then reverted it. I guess before we di= d not had > > > ACQUIRE() and ACQUIRE_ERR() but I'm not sure that makes it much bette= r. Looking at the > > > last two patches on how we are handling the buffer mode stuff, I'm re= ally not convinced... > > >=20 > > > Also, I have doubts sparse can keep up with the __cleanup stuff so I'= m not sure the > > > annotations much make sense if we go down this path. Unless we want t= o use both > > > approaches which is also questionable.=C2=A0=20 > >=20 > > This, indeed, needs a (broader) discussion and I appreciate that Kurt > > sent this RFC. Jonathan, what's your thoughts? >=20 > I was pretty heavily involved in discussions around ACQUIRE() and it's us= e > in CXL and runtime PM (though that's still evolving with Rafael trying > to improve the syntax a little).=C2=A0 As you might guess I did have this= use > in mind during those discussions. >=20 > As far as I know by avoiding the for loop complexity of the previous > try we made and looking (under the hood) like guard() it should be much > easier and safer to use.=C2=A0 Looking at this was on my list, so I'm ver= y happy > to see this series from Kurt exploring how it would be done. >=20 > Sparse wise there is no support for now for any of the cleanup.h magic > other than ignoring it.=C2=A0 That doesn't bother me that much though as = these > macros create more or less hidden local variables that are hard to mess > with in incorrect ways. >=20 > So in general I'm very much in favour of this for same reasons I jumped > in last time (which turned out to be premature!) >=20 > This will be particularly useful in avoiding the need for helper function= s > in otherwise simple code flows. >=20 Ok, it seems we are going down the path to introduce this again. I do agree= the new ACQUIRE() macros make things better (btw, I would be in favor of something similar to= pm runtime). Though I'm still a bit worried about the device lock helper (the iio_device_claim = one). We went through some significant work in order to make mlock private (given historical abus= e of it) and this is basically making it public again. So I would like to either think a bit = harder to see if we can avoid it or just keep the code in patches 5 and 6 as is (even though th= e dance in there is really not pretty). At the very least I would like to see a big, fat comment stating that lock = is not to be randomly used by drivers to protect their own internal data structures and state. - Nuno S=C3=A1