From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ot1-f45.google.com (mail-ot1-f45.google.com [209.85.210.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 1E92C47B42C for ; Sat, 28 Feb 2026 17:35:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.45 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300120; cv=none; b=IzyUb2z3igHgyQUz9OG+P8rMcUIYSxjGdH7u/cwU/4gvPl7wDXaL8j+pzMYgOFR9/0nP4zmlMb026SoLHQ43EHkcT1zbDfQwJWu5W2CKMjSHVFeKOh9if8GdnpiAj40CMmpEtd0BbAK/Sm8NwSjdiK7OijJnddafczD9NA8P6QY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300120; c=relaxed/simple; bh=VpQlLC4yuAZCN83l2FY7W0C9JGWJzKbwyBbG02roCsc=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=q+z01J0wooZQR+5qv/wNoFTM/9SrLiHy3Q8WBr5KSGsn40EOV+s+LcygipJZd2AoLcLCI7YuaDfBhTQQ/ZWuLTVvgc06j2hZAASxLDmsMA7VxEEe7Y7ZAmq198u3SUPIB5qW668J4YI3wNqTdCQIlXhi9YLKGkilEQUq6lc+4K4= 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=evaMal/C; arc=none smtp.client-ip=209.85.210.45 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="evaMal/C" Received: by mail-ot1-f45.google.com with SMTP id 46e09a7af769-7d598f60eeaso1417045a34.2 for ; Sat, 28 Feb 2026 09:35:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20230601.gappssmtp.com; s=20230601; t=1772300117; x=1772904917; 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=46ijH4q4ZMpqLn9riBmDz3nl4kEzUq3GVbhaLZAxiNg=; b=evaMal/CSXFIMO2HYWFGkfkZeabChh/rheJB3H86+nS7C0+OHQ6hiqy0iSC3tQ5MI/ jPJZn72c4JSoiuID5ANryZ41wh37l3AaKnoyblW3IsQ13XCKZjAP4c2pGwl8VOUgHpOb PUiw105K/6tuyJGmT5PkqLMbyexG7MJKUA2s0HqH5xVRR7T7HiQGiuvaDw1RrIrVYgc1 ++HORKppoGLQG/H2rIo7cekPctDk10rSpTf8ehLTDTg+2iTSrrkGMzJEhvxvun8T2lZq dX+GwghOp0RS87mRU5IKOQUPI9S/4r3OTdzPpjFOIBVi6OgarS+fiZ0Aafn2e0yZkPUz YibA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772300117; x=1772904917; 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=46ijH4q4ZMpqLn9riBmDz3nl4kEzUq3GVbhaLZAxiNg=; b=KAt0a5g3jdIyqsMa1w3RNEFUNvYmmX8NJKP2nWBNAZz/CquDUUmLf5TOx5M75/n1Lu 2/ZamirFVSDbR9M01SU6ohPB4qpXcgWnse4Moae58zmQFFp/PsItrHcoEzvgkmNtjYTT gTB53mX7oxw1r1pHeMtO/IQ9Dt4tOiJsdjEWo6aunvyAPkXeAFNtGq7dQMNmCcqp2koO XHfb7d85dGh7mcCON0E6oyNT41r1I6N9LJrJxZ/tOM/+YHgdjgStfx9RCciOfRraL1D6 QGlmNO0ZTisZTky2146fGMrxmZg7QUVS2JVI/sdmzUtsY//2B3WtJfhXex4qxJgzWhB+ EdVQ== X-Forwarded-Encrypted: i=1; AJvYcCUN0I8jxU3KmU68O8SjKl50Q5WDX/FZSsFFhEW3r0MrKoc6rhI4NSUx58nf6/i6CtWJNLPwPgneqeH3qhk=@vger.kernel.org X-Gm-Message-State: AOJu0YyF1K5ac6xswd4QQQa51X7zEj9b2N+SL3hCr9GMup7XtB/oc4LK DMpTnZiY1VtgWa7QqH85TuU8ltpv2pcAx9sWdVXbdR0cs/t9JKGZII7J4sF/D1M3Z2E= X-Gm-Gg: ATEYQzxxgeakeqmsXSV1oqMMVZ4Icw896X87YdZhjuiyT8m3lA6pIJ/Mo4n5Ax9QD4W ykXDMk27ycd0lWGlzeU5og/ibvXW/m8jfIQsC07oRXwS3bWwEeIT0L6JDNNHY5n0h0w9dsVJG/2 Y30FJy2/APmI+F13Ob1Vjh64OUrdQcx4jgVeZ+e6MNm7SbCS2b8zwMHcc6fkF8ThUazbfMxVuOp iIkXQ185lQMMcGBzTjt8haqOlKLad7qPYKRzaqKckPQ6FWBf2FW0nlIo/EPdD8P1mTZRT2cR/e0 W+O0bZ1ldxZmFpiAthIVpb+lta4YitW+UsWJ4nuV7OUicpG5azXuoxIEOv1Lv3p9kfsVlNHdzgH Q5oDtgu6t34LTw0yKafqfFDQ56iVSZ8daKQgEh5jb+sg0fX+JBV/UPUjYuMiDOoWVc2y/7uXxaH dqCG5T0B9KVUMSvUuMlf+ln/G9zgfoluBt6JlykNybhgfBI3uim2Xm/8ttc8x27ywAhaFhTZFTS A== X-Received: by 2002:a05:6830:25d5:b0:7c7:6043:dd93 with SMTP id 46e09a7af769-7d591b2656amr4819921a34.13.1772300117017; Sat, 28 Feb 2026 09:35:17 -0800 (PST) Received: from ?IPV6:2600:8803:e7e4:500:1031:c44e:9f1f:17c1? ([2600:8803:e7e4:500:1031:c44e:9f1f:17c1]) by smtp.gmail.com with ESMTPSA id 46e09a7af769-7d58666ea95sm6809490a34.28.2026.02.28.09.35.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 28 Feb 2026 09:35:16 -0800 (PST) Message-ID: <00ee6df6-422e-40db-8494-3f9da4ccb227@baylibre.com> Date: Sat, 28 Feb 2026 11:35:15 -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] iio: adc: ad799x: use devm_iio_device_register and devm buffer setup To: Archit Anant Cc: jic23@kernel.org, lars@metafoo.de, Michael.Hennerich@analog.com, nuno.sa@analog.com, andy@kernel.org, linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org References: <20260228154515.16639-1-architanant5@gmail.com> <641c4d59-4cfd-49b6-b6de-692db48db1c7@baylibre.com> Content-Language: en-US From: David Lechner In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 2/28/26 11:19 AM, Archit Anant wrote: > Hi David, > > On Sat, Feb 28, 2026 at 10:06 PM David Lechner wrote: >> >> On 2/28/26 9:45 AM, Archit Anant wrote: >>> Convert the driver to use the device-managed versions of >>> iio_device_register() and iio_triggered_buffer_setup(). >>> >>> This simplifies the error handling in ad799x_probe() by removing the >>> 'error_cleanup_ring' goto label. It also removes the need to manually >>> call iio_device_unregister() and iio_triggered_buffer_cleanup() in >>> ad799x_remove(). >>> >> Since we are doing this, why not also handle the regulators and >> rx_buf so that we can drop the remove() function completely? > > I completely agree that dropping the remove() function is the > ideal end state but I initially stopped short of doing that because of two > hurdles: > > 1. regulators: since ad799x_read_raw() needs the regulator pointers > to call regulator_get_voltage(), I couldn't simply use > devm_regulator_get_enable(). In this case, we can use devm_add_action_or_reset() to register the disable callbacks. > > 2. rx_buf: st->rx_buf is dynamically re-allocated (kfree then kmalloc) > inside ad799x_update_scan_mode() based on the scan mask. If I use > devm_kmalloc there, it would leak memory on every mask change. > > To drop remove() completely, would you prefer I use devm_add_action_or_reset() > to register custom disable & free callbacks for the regulators and the > final state of rx_buf? > > If that approach sounds good to you, I will gladly prepare a v2 that > eliminates the remove() function entirely. > > Here, we could also use devm_add_action_or_reset() or we could drop the dynamic allocation altogether and make rx_buf large enough for the largest transfer. The latter would be preferred as that is how we usually do it in general. #define AD799X_MAX_CHANNELS 8 ... struct ad799x_state { ... unsigned int transfer_size; IIO_DECLARE_DMA_BUFFER_WITH_TS(__be16, rx_buf, AD799X_MAX_CHANNELS); }; Note, it is important for this to be the last field in the struct for DMA alignment purposes.