From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f44.google.com (mail-ed1-f44.google.com [209.85.208.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 80E3E301468 for ; Wed, 3 Dec 2025 14:48:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764773289; cv=none; b=bmcnRzZx63vxQqyVRJlTHX6nW2QPJcr4mRMxSXmj5ROxTmyTxjJfx9oaffsBDgFZFhs94V8oYYSyY8L7N+iMNPybi2hM3Q9ACVDWK9iW57hK7SWQgW8/zL4FvfrMPXybRT1gJlPbcC59jl25cNMR3kUohDWCZbB2fqYfm+lqyGI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764773289; c=relaxed/simple; bh=oL35OKvGOxDskjgVdfPaKqYXVuHhqzw09HymFZTzoDY=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=Mu5GoSanmwyx8DuAE/Kh8vkAmu555HnogI83TnbC1EcY0OZz0Oss+/Uke0Mtphz0EeQpv0atVCkOm7+Yimy1tz4uZwI10Bnm1mFOyuT0N6M+JWGmy3ayjjlBy1pq9P3pw0yQpc1rttBYa7sEe8AwR2P44dMwNt6hFz+NxQWF3R4= 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=faUnit+e; arc=none smtp.client-ip=209.85.208.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="faUnit+e" Received: by mail-ed1-f44.google.com with SMTP id 4fb4d7f45d1cf-6418b55f86dso12171064a12.1 for ; Wed, 03 Dec 2025 06:48:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1764773286; x=1765378086; 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=oL35OKvGOxDskjgVdfPaKqYXVuHhqzw09HymFZTzoDY=; b=faUnit+eZTfoiBFjAP2wYoa0lbqq8nu9I3p4ocoBPQdVN5NHvI8YuOAmsnOqwdoi6S SHeq/cDFjfg/CaO1FuwWjgIJDK7yKVT39NFRkjBlBcB59U5jCHHf13Tlfe9tYTGcuKHt 1nB70HxWvq+GLM9U4K0Ig5QA4cCdUhTw9y/kDdfEBRnizeFDzob+jj5O9PGRSebpmk/Y IG8qMftvRrJC1VIa8i4vtog8xlupAVd+/Nc5qqbWjElzKREcft/JriI10bSgnF/QFn0M z5dcvDRxp5wRjElcvnL0dRZxn2TcByh9SFxsoIy+W4iDTVI8CtnZEDNq/FxYroZcNEQd wl4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764773286; x=1765378086; 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=oL35OKvGOxDskjgVdfPaKqYXVuHhqzw09HymFZTzoDY=; b=AAMvNSbzVCUoHX7JnYjWWQxbQlTKhb+PMvoCvPU70gztJN1LQ6srNz1kco08dXv3x0 M+zsVfgsYkbEk74q5oD0kPfTUMVFk1iE9RMM02jerCgf2G+2ZmxQHjpJ+uRWKOnAOdxK VXBlwZqMXh1t9M6lluPCxMJ+FWfu/JdxV0m6LdkrLPqBTrltU/bhmzoUjg3uqntBuTiB 4NxoFtopc39BEEcmbXyfA5l4WZkjecP4lNP97K8gH3U1vXRU62FpIls/91tSDRaYzGCf TY8vr7aMMIuOGoUSvwxf8uR+3hie3RKowQG15YlOTBUbwAuNC4/tfWEydq8RT8JzoHjl Egew== X-Forwarded-Encrypted: i=1; AJvYcCUYv3jxxRAsDsdWwgi8aJAvol/sAyOPphiGPc6jgk8skcrmrtXI+lSywod1YRWcDOdsWdcDaBdgi7nUDBE=@vger.kernel.org X-Gm-Message-State: AOJu0YzT/JpTvgrowYdRBRGsj8qu3UJoISWmNDRMedyF3Y0nxVU0MmiJ me8V81p+vc4S/03Tt+A0o/FyjKo78qHqSUHd/ljCf+2bJdSvlFehP1jDRmsmPg== X-Gm-Gg: ASbGncu9gkf7s72Vtm5DfCKaikq0ocTTOw2r9Fqv2kemo7qsJVQD00QtQajUFSknWHy 8LxQENpWHiJj923hI7ezLGuz4zO+12JhygwzbU+PTIDjBZb7IafUgbgR0MW5Iu/OF7/KCs3Sj/d LRX4LVHJ41L31qHyPJqIwgRK8+N2IoOl/mVVZrdP6JpankLxX8Dn8YaiPcYhn9z3kbxZ4lDGdp1 k6AFd3cy5fIpIcI+DR5ghL/TM7Z1PNUh7/zq0Wkh92iMJ95UzGW+blSUlWG6Fc0/fprIBDr4G7M 3jXkk7uLnu6vzMuLVSOmJOaDJ4HnRA/0t6Aups2yBrlImj3IJkICMU45sCyQih546sDAzOPru4H Zcc19vl4PR+RMwxS06xKgbK5utSx3u0Owcy5W4GwVH0z5GZCRVmnjRLIeERDeG7OifRb34T2dlX 8nNZizROC5zOA= X-Google-Smtp-Source: AGHT+IFGmiSxZ43YfANUOAK2kxqz366FrP8VXObqiHTmbXUrUCjFmKAoNnC01rZ2yC7eX7J63HXKeA== X-Received: by 2002:a17:907:7210:b0:b73:7710:fe03 with SMTP id a640c23a62f3a-b79dc77e2a6mr310276466b.58.1764773285339; Wed, 03 Dec 2025 06:48:05 -0800 (PST) Received: from [10.5.0.2] ([185.128.9.168]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b76f5a4b757sm1793579066b.66.2025.12.03.06.48.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Dec 2025 06:48:04 -0800 (PST) Message-ID: Subject: Re: [PATCH v3 2/3] iio: adc: Initial support for AD4134 From: Nuno =?ISO-8859-1?Q?S=E1?= To: Andy Shevchenko Cc: Andy Shevchenko , Marcelo Schmitt , linux-iio@vger.kernel.org, devicetree@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, jic23@kernel.org, nuno.sa@analog.com, dlechner@baylibre.com, andy@kernel.org, Michael.Hennerich@analog.com, robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org, corbet@lwn.net, marcelo.schmitt1@gmail.com Date: Wed, 03 Dec 2025 14:48:44 +0000 In-Reply-To: References: 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 Wed, 2025-12-03 at 14:59 +0200, Andy Shevchenko wrote: > On Wed, Dec 03, 2025 at 11:02:45AM +0000, Nuno S=C3=A1 wrote: > > On Tue, 2025-12-02 at 23:26 +0200, Andy Shevchenko wrote: > > > On Tue, Dec 2, 2025 at 10:55=E2=80=AFPM Marcelo Schmitt > > > wrote: >=20 > Nuno, may you please remove unrelated context when replying? It was not that much. That is why I did not bothered :) ... >=20 > >=20 > > Hmm, can you share why we should have a reset controller for the above?= =C2=A0 >=20 > My point here is to have a standard way of handling "reset" pin independe= ntly > of what's beneath in the HW =E2=80=94 GPIO or other means to assert/deass= ert it. That makes sense. >=20 > > Unless I'm missing something, even with the aux device, you'll need the= code to > > optionally add it which (I think) will already force you to check the e= xistence for > > the pin (which would be a bit odd IMO). >=20 > If this is the case, it needs to be fixed, but reset framework provides > _optional() API, that's what should be used for the cases where reset is > optional. Let reset framework to handle that. Ok, I think I was also misunderstanding you. So you mean that instead of do= ing=20 devm_gpiod_get_optional() we should use one of the devm_reset_control_get_*= () calls?=C2=A0 Ok, I went to check the reset core implementation and with [1] I take back = my comment. I can see now that the framework will automatically handle creating the auxdevice. So whi= le I still think most of the times we'll still see reset-gpios in bindings, it makes sense to have t= his HW abstraction in the code. One thing to note is that the reset framework always enforces reset-gpios a= nd we do have places where reset pins have different ids (just because that's how the datasheet = defines them). ... >=20 > > Having said the above, I would be up for some kind of helper in gpiolib= . > > I still see way too often people misinterpreting the meaning of > > GPIOD_OUT_HIGH and that the value in gpiod_set_value_cansleep() means > > assert/deassert. >=20 > Consider this as a helper :-) Indeed! [1]: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tr= ee/drivers/reset/core.c#n1038 - Nuno S=C3=A1