From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com [209.85.128.45]) (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 503DA3195E5 for ; Tue, 13 Jan 2026 10:38:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.45 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768300686; cv=none; b=AL8rTj150OMqWXjzCS0BD0FGmn6u5WbLk+cqEs7z6SuO6CUH45xX9bN3Y3+8sB6PVmKt99X81XXmcRhLztMV+q1zcPILO8ho/cw42Ufn6CNuG4j98J93TVNAqBqzADPwZPJCTYzd0qHox9PlmsWa8o7Il2q0H8xCrQmk5emyBZI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768300686; c=relaxed/simple; bh=mxOcD1cA12y/6rHKrAjW+DtvChOgFYiutRcSmEc8Wp4=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=ayhH1SDGEO5Jzcmqn+y7NuDWfpnstMmZz/OA7vJBZ1iV73cGD3VNFq6Zz9Gg8Oh+MzMgcjWJDNuOV7TrFMcB3thGqF87Gwrqh9AxXljPsO07kVmk3PpMmvunqPXzoc94EIvhJck/8+lmztmrPt5FiQLagYvBmJe+mxWG66B9R6Q= 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=fI5y+FIe; arc=none smtp.client-ip=209.85.128.45 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="fI5y+FIe" Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-47eddddcdcfso1198975e9.1 for ; Tue, 13 Jan 2026 02:38:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768300683; x=1768905483; 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=mxOcD1cA12y/6rHKrAjW+DtvChOgFYiutRcSmEc8Wp4=; b=fI5y+FIe4yVLc4F3IT8ErlddaAz/KTmNu+1DAHYz5w4I7XgNDhmpT5kRoZQjTN3ihS grq1zk9DvwnI8nlgfy/n531XvFS1mOj6DRPsaNc70uDYvVK1okWUB7g0WKmtunxJpKLg wgu4u1fsFxxQvyg0Ti7nfHNC/j3Apfkhj0rOXqzKCQOnPt9gNQFXzV1F9Yxs0UWBV6qt bcBEeV8+ovstlYBmtn7AyVQCqod/dx48AOQCoY5IjcvZp4cmF2YdB1n6TRikeoy2zCCE PJfaZPWug+yffPoFICVZo4c7sR15lYRgmGYc1QS4zmNEhCD027Jh1kTzhPvrt5FT5AaI F0iA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768300683; x=1768905483; 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=mxOcD1cA12y/6rHKrAjW+DtvChOgFYiutRcSmEc8Wp4=; b=biHf5gHU7Vv0y/ET9rsiUCkoNnQbA8buj8+9ADWGymLqKCIh8sK/+LTWQ/26mZy9PG F748fhqaEDpu/4XKnl0yZnnKkVyZ6OYndpeEm3cjk0zop4RB5M3yaiXNl7QrU6dcOE3a YNl1yDfVjG1/VpXsoAGvL+OhD/zzW6fE35uP2fb5ts4cUUGvfBRrJPpYekrokCiOx63u fJwnxFc4/OQtVvZjTkFcc58ocMhZlSrc+9w8yvIVLOpYxy5qnbLGWqQoLijjdyh/4ryK OC5DgcUEAM4Jc9dX3X1tiBkyCrAtgVDUphulMmEC3kdw+mRgEJ4pG/cXyZV76E6bbXXs zUrg== X-Forwarded-Encrypted: i=1; AJvYcCXJ5vlhME++eKgJvogD66j2CHcRnWgTQ+L4y3ZVmbxK+D4ebIF9pwg8gJkOKAvcLIUEAFih90xM4usEuoo=@vger.kernel.org X-Gm-Message-State: AOJu0YxeB4WAQ46Nr+VuNTvVuAMJDeVqbasfC1Bd0Tc0LHEcz8Yq0Rzu 1OjQhcN3P2dcTcp+YFKwtTuqTZOIRSu+v9y2aWWsHGDkpkKeNP1xnND1 X-Gm-Gg: AY/fxX5p4uwDmgE3oMpXwTJtBk0NJOzFziZ815Jzifw06a1v+aJUAQ8OBl2vnBR/sDA nSoCpzuB0e0R4VUAuqqS2OaY9OiEfHgtJ7LeyNN+U+QaqTAb98E/hQBANgFg/R7cNHkIMyNzkan XzxvsZrIWUyFqGNA5lgFMwTfUA1Mon9zQ8hXqQDChDkmQ9QCceiida8Slx2xQ2AYw6Z2m+sjRhg kQMQJT7HRhxL44mYsmTT4PAnt0q+URIJyBg75MsnKC6lUt8qFXzb8HjpRIocKhI5q/4KBd9Z5Mc GCH+kImbDRlSEXDz7A/GY9SSk7y4qm5WeO6Os9qvdPTMS+RY9+rS7lCQcIzkQP254PWounGtscD 36hADrRRJdL8eIJL5mWov5zGvqdoZwV4yVZ27o6cR4ea66MJlW+yjUVmDlsPERXDurPdaVplcZN q+kKlEorLbg/DYyTgTKTA= X-Google-Smtp-Source: AGHT+IGZWI8BC0XO4q/PcONBO/S1NJ8k2S4bjAnGk5dNdRHI+QqShN6+xW8K63IsOGXYRmKeEVVOOw== X-Received: by 2002:a05:600c:19cc:b0:47d:264e:b35a with SMTP id 5b1f17b1804b1-47d84b19f69mr237676935e9.13.1768300682455; Tue, 13 Jan 2026 02:38:02 -0800 (PST) Received: from [192.168.1.187] ([161.230.67.253]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d7f65d9f0sm409588395e9.12.2026.01.13.02.38.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 13 Jan 2026 02:38:02 -0800 (PST) Message-ID: <98897c0488e67f543f437b96412c78e10a59a81c.camel@gmail.com> Subject: Re: [PATCH v2 3/7] iio: core: Match iio_device_claim_*() semantics and implementation From: Nuno =?ISO-8859-1?Q?S=E1?= To: Jonathan Cameron , Kurt Borja Cc: 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, 13 Jan 2026 10:38:44 +0000 In-Reply-To: <20251227144707.1bebcf27@jic23-huawei> References: <20251211-lock-impr-v2-0-6fb47bdaaf24@gmail.com> <20251211-lock-impr-v2-3-6fb47bdaaf24@gmail.com> <20251227144707.1bebcf27@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-27 at 14:47 +0000, Jonathan Cameron wrote: > On Thu, 11 Dec 2025 21:45:21 -0500 > Kurt Borja wrote: >=20 > > Implement iio_device_claim_buffer_mode() fully inline with the use of > > __iio_dev_mode_lock(), which takes care of sparse annotations. > >=20 > > To completely match iio_device_claim_direct() semantics, we need to > > also change iio_device_claim_buffer_mode() return semantics to usual > > true/false conditional lock semantics. >=20 > I wasn't rushing to review this set because I want it to sit > a little longer than a typical series to get more eyes on it. > Anyhow, long enough for this version at least! >=20 > Whilst I find it hard to care strongly about out of tree drivers > and in place flip of the return logic seems a bit unfair on anyone > trying to keep those rebased on mainline! >=20 > So with that in mind, maybe we need to name it differently even > if we are getting rid of the old implementation all in one patch. >=20 > Given earlier discussion about this one being rather more tricky > to name than the claim_direct because claim_buffer sounds like > we are grabbing the buffer, I'm not sure on the best naming to have > here. iio_device_claim_buffer_m maybe?=C2=A0 Ugly though and > these are super rare so maybe this isn't a particularly major > concern. >=20 > Given I think the people maintaining most out of tree drivers > are Analog Devices maybe this is a question Nuno can answer > for us? >=20 Whatever you prefer :). I'll be the one taking care of any conflict that comes and I do not mind dealing with something more painful if the diff flow makes more sense for upstream. Also not sure we have any out of tree user for these claim buffer APIs - Nuno S=C3=A1