From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ot1-f52.google.com (mail-ot1-f52.google.com [209.85.210.52]) (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 3C3B33CC7D3 for ; Wed, 24 Jun 2026 15:13:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782314001; cv=none; b=kU7XgdK8KtihEiHaZMR9/DUjN0O/q/WH9DzYi/J2ZY858o++7COhKt60A8+tYGvZVEO/1+kxqCIhzDtBKrUegQ+cAd/+gCuDbntOD9CI7Yp45NxGpH+g7yeVulcUkrZ12U+yEDdnTQ9PXD73w3RFQAvkCQEvqZQMvaWSmYIsxMM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782314001; c=relaxed/simple; bh=S7HTvQJvi9q3ObEnOv2xXX/hy6wHNAPvkD4FGpz2B8U=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=AfczPVesJ2LtD12D5WljT2QIfDClSS89hoS24ADKWZc0NJLnxCNGG0Mq20XACIWP+RNKrt55CYNoKZyKxg3dnaf0nwT+4gt8Y8TWrH+TelJJQHZKFrf/pHkDZXyNUqRZTd5gFbNyoOkOGk43/8nsOfBQ7c/MEa/W15d4cMVUI0A= 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 header.i=@baylibre.com header.b=U/5Y866A; arc=none smtp.client-ip=209.85.210.52 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 header.i=@baylibre.com header.b="U/5Y866A" Received: by mail-ot1-f52.google.com with SMTP id 46e09a7af769-7e6b5c374e5so1040729a34.0 for ; Wed, 24 Jun 2026 08:13:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre.com; s=google; t=1782313998; x=1782918798; 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=HAsvraZ6mLfXZddrVTxKfH+cnaP/AcM6qIT+GUf0HZM=; b=U/5Y866AWO1pTARc3qO/TlN8hRIZ2uffotr8pLtTxATWLKSvnEzSrSM5+eXw2UmRPF c0/LfCHSx0rUIsEY+8qvjXTh/YC/iBBZISXAXxGGWfJaWRNo2oGs0OjeW4oXdGG65GCP yIYKwJpWKJ18OMQuvW7Q8cPaNdUfGlBONDRPKy84A3oaB9jVZWrIvgrhiD4DDcRt7T2x vCGJswsw7jTz7KkZwPcKnXT+Zu8R63mlRIIOkMd0iyddFyW6vQZNtOdffEvUrg6ii43T fanr2wAbfy4iZGfBxf7CVhFP/zDvnRRi/KNmA84lXWu7TihYTOVjnnJFEChwgWY/GvB7 D8bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782313998; x=1782918798; 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=HAsvraZ6mLfXZddrVTxKfH+cnaP/AcM6qIT+GUf0HZM=; b=WHis8CzWCTz0IRr5gu5oEnbsuUTS1WuLMXbuVpj89taY3jGVffmhvgun0NAmKUOQAR XTPBNk5ulroHamFlP5SZPoCp5PQ6oGbRQEmtzRXkPRK5+YsA//Y57iLe1t8qbA5a9XgT OQ17P0uLIcuXXlQUja0CRlQyeAcY9MBgCafYcil9TdA+31R7YmOSkJQYfG3q+53cF/7+ bpTzZDC/K7WvWDjXZ4Z5w7sF7j5Pg2xm4yjlqkyRgiQXeN7Rd+woUh6q90H7VcMu0url vhep1RPVj5bAlgWdp7A+XV52CEYYTVnYKkMfScX9Nbh3HdUOAgom+hA5w2ZdjMR4VgNf UM+g== X-Forwarded-Encrypted: i=1; AFNElJ/nh1vfgZdcKBLcgJEZXsi+kwKy83ktOAZpPLWnyY089OeZ/YHsdk46ySFcUsIM2GeVF4YLrvNZ6Qocnag=@vger.kernel.org X-Gm-Message-State: AOJu0YyfOfcKU2ins8bhraZnoQ7lwA4TXc+F8u4wAOQ62WLlALI2S9cq YJeXgUFbmHLzg1ua3D7UjpIudQ9klGlhMV8M0iV8E9BJzWaditF1Bi9MiNyUNYaa16M= X-Gm-Gg: AfdE7clpdIWgHoDr53RngJNepP0KFS+KaSUJl2zlp7ynUpAnCC1BmIu1nLWT/JMMhH8 RiVDxBmk2D33b820gs1K/Coq5s//d8QPMazIlXd2Q2SAJe6zRBZpE1Pa7g2HYnhGaUGeboApBaB CPXaSKMAzMv/pTt5Agp4iCVXt6usuFZaALWwSxD8ixJysVaWph1gthENI0FyjlQiH1E0XH2xCxt D6yDuRVcP/4NsSZcTkHUP167x+2EjLjvM0sZjznSxAlvPqBlAr2Ga6OLqe/5cvw1lLfIWrLjNXc 2t5PqrbgFps5PrO6XUKdq95zDRC6sclnKTCGmeWo7Mi8yIOgyig6GApYXt/zC3mlBZcupDHAoJB WZPA4TW0vQr04NnK/D0Y1SX2rnKrkrBl5+13j3wrgwhpbe5vTt8mZoIqlaWQ/JM0kj0r1gJRlKT 5UzmCKKu8vp/XosPMiE60Kjboml8qdOqV99jrbxVKCCLeKqt0u4YqXOl74SjhFcj8= X-Received: by 2002:a05:6830:7003:b0:7e7:24f9:55c8 with SMTP id 46e09a7af769-7e99152425fmr450926a34.5.1782313998318; Wed, 24 Jun 2026 08:13:18 -0700 (PDT) Received: from ?IPV6:2600:8803:e7e4:500:68dc:b788:b3ac:e34e? ([2600:8803:e7e4:500:68dc:b788:b3ac:e34e]) by smtp.gmail.com with ESMTPSA id 46e09a7af769-7e94406d488sm11520762a34.8.2026.06.24.08.13.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 24 Jun 2026 08:13:16 -0700 (PDT) Message-ID: Date: Wed, 24 Jun 2026 10:13:15 -0500 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 v3 1/2] dt-bindings: iio: dac: Add AD5529R To: Janani Sunil , Jonathan Cameron , Rodrigo Alencar <455.rodrigo.alencar@gmail.com> Cc: =?UTF-8?Q?Nuno_S=C3=A1?= , Conor Dooley , Janani Sunil , Lars-Peter Clausen , Michael Hennerich , =?UTF-8?Q?Nuno_S=C3=A1?= , Andy Shevchenko , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Philipp Zabel , Jonathan Corbet , Shuah Khan , linux-iio@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, Mark Brown References: <20260619-obstinate-polo-a230bef97fda@spud> <20260619-bunch-diocese-dd7805cc17ff@spud> <20260619-concierge-doozy-9c161533c369@spud> <20260621153330.79b6600c@jic23-huawei> <5u4dnsgxwcwie45f24cacyzf3dko4srhyyyhcpom6tsvhqtmpc@y7d7gmex6n7k> <5guhkvoxhkzevjm4b45hhk3772akpnz3givr3gb56x5ywamzyf@oiycreun4y62> <20260623155732.318f34f2@jic23-huawei> <9abc53d0-432f-48fc-9e21-4d9a3c5e129f@gmail.com> Content-Language: en-US From: David Lechner In-Reply-To: <9abc53d0-432f-48fc-9e21-4d9a3c5e129f@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit >>>>>     >>>>>> But yes, I do feel that the whole feature is for aggregation so seeing >>>>>> one device with 32 channels is the expectation here? Rather than seeing >>>>>> two devices with 16 channels. >>>>> Yes, I think aggregation is the whole point there... so that the IIO driver >>>>> is multi-device-aware. >>>> Which makes me feel that different pins per device might be possible >>>> from an HW point of view but does not make much sense. For example, for >>>> the buffer example I would expect LDAC to be shared between all the >>>> devices. >>> That is why I would still suggest the multi-dac node in the middle... >>> the parent node can hold shared resources, while the dac children can >>> have their own, overriding or inheriting stuff. >>> >> Before going down that path I'd want confirmation this is something we >> actually think anyone will build. >> >> Jonathan > > To directly answer your question- we currently do not have a platform that supports multi device topology with independent supplies or reset lines. > Given that, I agree to start with the parallel wiring assumption and defer per chip resource variation under there is a solid use case. I will also drop the "adi,resolution" proposal and proceed with "adi,device-addrs" in the AD5529R binding. > With all of the above, the proposed binding for the multi-device follow up series would look like: > > >     dac@0 { >         compatible = "adi,ad5529r-16"; >         reg = <0>; >         adi,device-addrs = <0 1>; >         reset-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>; >         vdd-supply  = <&vdd_reg>; >         hvdd-supply = <&hvdd_reg>; > >         channel@0  { reg = <0>;  adi,output-range-microvolt = <0 5000000>; }; >         channel@16 { reg = <16>; adi,output-range-microvolt = <0 40000000>; }; >     }; > > Does this look reasonable to everyone? > > Regards, > Janani Sunil > LGTM. Seems like the simplest way to handle it and should cover most use cases.