From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dy1-f174.google.com (mail-dy1-f174.google.com [74.125.82.174]) (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 EDAA619EED3 for ; Sun, 22 Feb 2026 21:31:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.174 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771795888; cv=none; b=avQF0mxdJf70Mn6aBO/id8M2REQny+rKAGqZ59/9nyg1/I09RRwLrtfmebA2YKI6l16HT8HVn+vQvYHtYgH45WIFd0Bxz5m8kN4tPGn1wX7FnrK27FH/PUenH68FTdaKQ3eUNM6k/UNbbeNAHqJZ2HBC9WaIoYNcBHNiILN7emA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771795888; c=relaxed/simple; bh=QzjME7zcYdVaQ3w3zHJF+94MbWLnBCtVKpePFUUeZ8s=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=GkOZMJUgTa7ruknBST4wosBOmDrrW/z06PIdlH/HRw9nvLM4/ezh/qtRulxaSgCF/f1AqlZbmmZxKVwHMh50PbwBVsNp6N1fOrMUVegxrSwGwbPr4sjbuwsp9GuZRXj4Rm+hBctZOtiJSdsFaUFM6t+llk3+vljBtyF45fQXVRs= 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=HQdyR6Xp; arc=none smtp.client-ip=74.125.82.174 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="HQdyR6Xp" Received: by mail-dy1-f174.google.com with SMTP id 5a478bee46e88-2ba94dbf739so3932434eec.1 for ; Sun, 22 Feb 2026 13:31:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1771795886; x=1772400686; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=w7RhOYqSZYG7/4DzPKHxyo/THmHlSU/4FOb0tUj651s=; b=HQdyR6XpXovX9ta792x5e3wfZNwsBEQQojpEE2YbIUwXnYuZq1ofadYI+9K6oQC32P Ri3Bwg35TS+yS+RrqWV7Yg0oVAb8MnjfrpJe94WNhlAaIVAQ9+os2iTk0ChoJWWO60pc BqDfVCIolnxk+59FnvA4+wuyxplF+zyweHI7DMRv7Z3HKt2lSOmePlKS2CKYi/LdHAhQ gQ1rbPZEYAKea2aacZbrHGIoLLk0+vM6ZVoa0uBOYboFBYiqVuKPp7teHNMrfCevI4lt 2SKaYY9RWMpCs/Az54jJ/L5UylVFPIZumepM9j+HFXzyWiqlq+GibefmgOjmSDLaVTZN Og5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771795886; x=1772400686; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=w7RhOYqSZYG7/4DzPKHxyo/THmHlSU/4FOb0tUj651s=; b=s81t7lCsIlww6QD4up9hueUOpu5Vad9OKSzMuLVBdawIhhH9SZKq0xZUZ/a3dP9LeN zXsRcfdjzTZIocluw1a6x90iPmCSC6YNy0upvvIaq0N13FAMWNymdIGBFHjXSueA0X+G hpCHz6ewvJuYYXX9GDayMi41EDZr1MXB0Ycw+nI/tlIrYMLnPE19w82SsgKeKmF4Konh gwJUjwWahIE9D08YRpQxNH8C9QlSEwQERcK2KitvAj+mEQwEhYmT1nJlM+ecYU6ELKPb oklfhXgb3Sk5YmwDuvt1hEG5ZGs0k/DFBsMZdYVtCAFJMQrpaw3lxJHvjg+c8iAEDgIT dRwA== X-Forwarded-Encrypted: i=1; AJvYcCUqfXOzXnGIB80PoMmAHAcESmqgrwgc/gnXvLyCdIKJaNV+poammQ8UegiMlRUk6Y5dUFcQq9CObNJfO2Y=@vger.kernel.org X-Gm-Message-State: AOJu0YzURrBZQW3Xu3njimxclZ1A2InkfvIXqbvGLPM/krpjuEZQdzVO IqooPdHsIzNsdAXSiNeyeRuuiWDGyNDbBIbp71JuspgQnpCS+lsc6rkd X-Gm-Gg: AZuq6aJvvz1vYMxYYMQWE4O0TKiWZyr5G/XdlTJJqtnJxerKnmR9KAeRmOkgAu8tsK1 sG0qUEwe23TlUFxQrXA2UVzQuQGFidVyxztiUynVaGabaqql0WXXHBBJCLuectCEAkIhy5/t5aX Gk4V8TYSfBmuh0LnXaAPVJhIVEhzAKX2dDEAqYhiIvSjZ8yYKZYO/Y3r+zF8XKn52OV1g2vL91N q+Bg3mPrjw4Hn4Wel7IofCxc9Uu6k1olMpPdYnd5tqB37C6mJ0PlbjZAfkIya9gUGQgBHTWq1+S GQ+KneeDyIrnFga5tLbCitoKglEUUeOZ22aJiKVqu0pSd8cMhONWUrZajV2bMNQc2WwnjWgFKuc Bc8R9+6BN747Rfw66+Nu6dzL0E+wRP2Z8Gqiuoixxxgv27uDL076tccSM+AOOkc+N0rzqhHrYI0 ll1rt8AWIdLQ7h0WMFH2iTi9bWBdb8//uxF+QRKQPHVK0xLTvv2XzH6DQPEbXFrIs= X-Received: by 2002:a05:693c:2293:b0:2b0:4902:c55c with SMTP id 5a478bee46e88-2bd7bd03e39mr3161672eec.18.1771795885912; Sun, 22 Feb 2026 13:31:25 -0800 (PST) Received: from google.com ([2a00:79e0:2ebe:8:c6c:6cca:170e:c77b]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-2bd7dbe82d3sm4014173eec.21.2026.02.22.13.31.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 22 Feb 2026 13:31:25 -0800 (PST) Date: Sun, 22 Feb 2026 13:31:22 -0800 From: Dmitry Torokhov To: David Lechner Cc: Andy Shevchenko , Jonathan Cameron , Nuno =?utf-8?B?U8Oh?= , Andy Shevchenko , Linus Walleij , Bartosz Golaszewski , linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org, linux-gpio@vger.kernel.org Subject: Re: [PATCH v2 3/4] iio: adc: ti-ads7950: switch to using guard() notation Message-ID: References: <20260219022929.3558081-1-dmitry.torokhov@gmail.com> <20260219022929.3558081-4-dmitry.torokhov@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Sat, Feb 21, 2026 at 11:20:42AM -0600, David Lechner wrote: > On 2/19/26 1:51 AM, Andy Shevchenko wrote: > > On Wed, Feb 18, 2026 at 06:29:27PM -0800, Dmitry Torokhov wrote: > >> guard() notation allows early returns when encountering errors, making > > > > guard()() > > > > // strictly speaking > > > >> control flow more obvious. Use it. > > > > I like the change, but... > > > >> Also variables that now only hold error codes (or 0) are renamed to > >> "error" to make their purpose clearer. > > Normally I would not give my opinion on this, but since I wrote the driver > originally, I will say please don't rename. I prefer to always use "ret". I hope I can convince you otherwise. IMO "ret" or "retval" should be used when the returned value is intended to be used during normal operation. For cases where we only expect to have an error or 0 for success "error" or "err" is more appropriate. This allows you to write error = do_action(...); if (error) { // handle error somehow, typically simply report. } This also helps when reading the code as you know that there is usually no reason to care about the specific value in this variable (maybe except -EPROBE_DEFER). I will push the conversion ret -> error to the very last patch so it can easily be dropped if I am unsuccessful in swaying your opinion. Thanks. -- Dmitry