Received: by 2002:a05:7412:1e0b:b0:fc:a2b0:25d7 with SMTP id kr11csp400065rdb; Thu, 15 Feb 2024 03:55:18 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCXTVI4uaqXqbcs37np9Yn4f5g5qox21pZt0LQUdEVWwe0qxAarjquMFmeEmAcfVVNaU7rS6QMkV+7BWrYmKZ1WTPeSG3bBZ9qJPsAWJaQ== X-Google-Smtp-Source: AGHT+IEuVuw7/lsyCSsMBxV4MoXx24kDxp/MruGd3Uwa6c2fIrcMRXKqrO4+m99Aa5Hedk0rzVwO X-Received: by 2002:a05:6a20:4323:b0:1a0:7b31:f38d with SMTP id h35-20020a056a20432300b001a07b31f38dmr2028416pzk.13.1707998118157; Thu, 15 Feb 2024 03:55:18 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1707998118; cv=pass; d=google.com; s=arc-20160816; b=kaIrk8CKtAUYrGD/NwzEeViFYDwHdl9ey209l0CkJAC0tUeRX/kcFWR2kdUaB29gCg W3133RvXjW6C+GONlQlaJlBIHB5xK8n6yPJ7YfjLw+45rmpXRKL2cEY2zKtOQH1l3cyJ q1dJge+1lH5IE8Y0lUK08ByO+WWNRZFhDDcLubV2V0P+6uRC4rlDQXQItexUP4P6NfkE tEfD6/6wOU/+t9vPB2bcwd6G47PUlQDwzLf9Q7O0Y81IuoeBIVNcR8IsVMEFCuWl1Cki pwIL1kBUoY30OyUY33VAL0hgxF47ABs0cdEzM3aOzitO1G0newaAG+VefSqcwY9zFB00 XK8g== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-disposition:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:message-id:subject:cc :to:from:date:dkim-signature; bh=E5iV1Nad6sXKUv6VBW3snwrymCA89FbrN4QhZdPLmL8=; fh=hOMdgak3S6iMAMgzQ3yghI0L6GCV+qezqESPtbD2wYo=; b=b1pcGfFqWvm5O5mYc8gV6WQHtoEMVG+vxWK3jxoFKIFZfq8sSE7xoS084biNcqFnds 2YPu9nAHjm0lvsaZuUUhlbJJzsPim8ZVC4CBYxAmQmA67c5QzvOkQnP8Qe4rrSiiWUwc azwFHAm3dIhNmTpslemY2ONQ77Kfzv4aCt/uWnIIRnRMAYULpQApBsxVDIA0Vpv/WHQi gqDf0s3ckdqgDD4gfo+ho2BzXSXw8uVGz7JePZ6UQC+qtEYs0qS+IpshSnN97P/xgpk8 Q75lLvWx3kmLzEGhfoqubSAA0Q+eXYcJALMFJr7HuXSMU9EHZN/TCMXsVprvC1nqKufJ HMbw==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=ftKTfYVm; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-66833-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-66833-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [2604:1380:45e3:2400::1]) by mx.google.com with ESMTPS id b124-20020a633482000000b005dc8914839bsi1011119pga.5.2024.02.15.03.55.17 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 15 Feb 2024 03:55:18 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-66833-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=ftKTfYVm; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-66833-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-66833-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 626D3289DA3 for ; Thu, 15 Feb 2024 11:49:00 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id CA24212BEAD; Thu, 15 Feb 2024 11:48:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ftKTfYVm" Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EFA0312B151; Thu, 15 Feb 2024 11:48:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707997723; cv=none; b=G0dPfYZn1I0SgPPsK04EyomRoJC06S7/aiaaYb+KlsDIjRO/o7pPkF6TR38doxW7e4IowoS/Z5e0fk8TH2q0cdpT0pqgGmL7HUdIr2NlJSdwCO0gw3StS5nOhQeRmTiq70LLpq+VW/uDNvu7IHmhYJ6yPiK93xsdJ7FzRfcAgrc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707997723; c=relaxed/simple; bh=6kDEft4yZaxt/MvQeW3rybsZfR6n+Mzo3vGvIfyQKQE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=nuEW2XSEBQIVfLBXfkdADNJIiwPPQEVC54yH5jSwIyhguUiRnl3RLHpiH/YQbyyLcXx41cvrv7I0rN0/b0BzvcMShpnF5n/D7sMmA5yomWkU9rWtn8C15wuNzRcwY1grgKBWy88aa14b7YAmJQ+Sk/cjb8k+7PCQIgf1Hq7yejI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ftKTfYVm; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 480B7C433F1; Thu, 15 Feb 2024 11:48:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1707997722; bh=6kDEft4yZaxt/MvQeW3rybsZfR6n+Mzo3vGvIfyQKQE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ftKTfYVmcIdKYvWge8L8BBtCRgVqZZ9ialp4cCC53VwdtXVajE9sBlA4SI/8JsytO XUedARwlNTgDSIcYKk9cOO0k3m8oU14yua8WaCl9hUwQaZliMXY1MWt652hu8IxIqP 5OmMyAr8crOwvtMXoZfslk3O64NZE3Dem9+s1kL4Snub36vuhyVr/RWsb0QMv3CiKJ yP8j3pQQuhQleiS35vt8HkabskExuoKv7rexXMYIhcwj+dgPsR/gU8iZ7v6A6D8RwG HMtXAWnAUzphwyycYlpDUBFIEX45xxHlXGzTOsOr0zpuPBOBy2w5Qxgu4pwlNpH0j7 zFP01YRueGoLQ== Date: Thu, 15 Feb 2024 11:48:38 +0000 From: Conor Dooley To: Guenter Roeck Cc: Naresh Solanki , Jean Delvare , Rob Herring , Krzysztof Kozlowski , Conor Dooley , mazziesaccount@gmail.com, linux-hwmon@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] dt-bindings: hwmon: tda38640: Add interrupt & regulator properties Message-ID: <20240215-wildfire-dotted-a561e86a6054@spud> References: <20240214092504.1237402-1-naresh.solanki@9elements.com> <20240214-trinity-delouse-6dcd0b046895@spud> <0f1665e5-bae1-4a17-a976-cc225a28dad3@roeck-us.net> <20240214-dimly-wife-5b6239d4adec@spud> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="tmiZQ9tIrjdkv1MF" Content-Disposition: inline In-Reply-To: --tmiZQ9tIrjdkv1MF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 14, 2024 at 05:17:04PM -0800, Guenter Roeck wrote: > On 2/14/24 11:55, Conor Dooley wrote: > [ ... ] > > > > Why "vout0" if there's only one output? Is it called that in the > > > > documentation? I had a quick check but only saw it called "vout". > > > > Are there other related devices that would have multiple regulators > > > > that might end up sharing the binding? > > > >=20 > > >=20 > > > Primarily because that is what the PMBus core generates for the driver > > > because no one including me was aware that this is unacceptable > > > for single-output drivers. > >=20 > > Is it unacceptable? If you're implying that I am saying it is, that's > > not what I was doing here - I'm just wondering why it was chosen. > > Numbering when there's only one seems odd, so I was just looking for the > > rationale. > >=20 >=20 > Given the tendency of corporate speak (aka "this was a good attempt" for > a complete screwup), and since this did come up before, I did interpret > it along that line. My apologies if that was not the idea. I'm not gonna go and decree that "vout0" is unacceptable, if it was called that in documentation that I had missed or was convention, I was just gonna say "okay, that sounds reasonable to me". > Still, I really don't know how to resolve this for existing PMBus drivers > which do register "vout0" even if there is only a single output regulator. I had a quick look at that series, none of the devices that I checked out there seem to have documented regulators at all. Some of the devices were only documented in trivial-devices.yaml. Relying on the naming of undocumented child nodes is a bug in those drivers & I guess nobody cares about dtbs_check complaints for those platforms. The example that was linked in the other thread doesn't even use a valid compatible :( https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/ar= ch/arm/boot/dts/aspeed/aspeed-bmc-delta-ahe50dc.dts?id=3D8d3dea210042f54b95= 2b481838c1e7dfc4ec751d#n21 I guess it uses the i2c device ids to probe on that platform, or have I missed something there? Cheers, Conor. --tmiZQ9tIrjdkv1MF Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRh246EGq/8RLhDjO14tDGHoIJi0gUCZc36FQAKCRB4tDGHoIJi 0pUaAQCoI/EW1WcdOCPKDAlNbr2bCXACKjFu6s7NFg8LVaQekQD+IGn2qZPeluC+ C6w8/WhsHQp3eI+6sJbs1z6r/ZvPZw0= =VQ5Y -----END PGP SIGNATURE----- --tmiZQ9tIrjdkv1MF--