Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 8 Aug 2023 15:28:10 +0100
From:   Conor Dooley <conor@kernel.org>
To:     Guenter Roeck <linux@roeck-us.net>
Cc:     Naresh Solanki <naresh.solanki@9elements.com>,
        Jean Delvare <jdelvare@suse.com>,
        krzysztof.kozlowski+dt@linaro.org,
        Rob Herring <robh+dt@kernel.org>,
        Conor Dooley <conor+dt@kernel.org>,
        linux-hwmon@vger.kernel.org,
        Patrick Rudolph <patrick.rudolph@9elements.com>,
        Rob Herring <robh@kernel.org>, devicetree@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 1/3] dt-bindings: hwmon: Add Infineon TDA38640
Message-ID: <20230808-esquire-epidemic-f9bd74ffde25@spud>
References: <20230802193155.2170935-1-Naresh.Solanki@9elements.com>
 <20230808-stand-cheddar-b76b0b7509a0@spud>
 <eced746a-1181-bd8f-6828-4a4eeb79727c@roeck-us.net>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
        protocol="application/pgp-signature"; boundary="XfJu5TZS5xk5xqji"
Content-Disposition: inline
In-Reply-To: <eced746a-1181-bd8f-6828-4a4eeb79727c@roeck-us.net>
Precedence: bulk


--XfJu5TZS5xk5xqji
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Aug 08, 2023 at 07:10:08AM -0700, Guenter Roeck wrote:
> On 8/8/23 04:46, Conor Dooley wrote:
> > On Wed, Aug 02, 2023 at 09:31:51PM +0200, Naresh Solanki wrote:
> > > From: Patrick Rudolph <patrick.rudolph@9elements.com>
> > >=20
> > > The TDA38640 chip has different output control mechanisms depending on
> > > its mode of operation. When the chip is in SVID mode, only
> > > hardware-based output control is supported via ENABLE pin. However, w=
hen
> > > it operates in PMBus mode, software control works perfectly.
> > >=20
> > > To enable software control as a workaround in SVID mode, add the DT
> > > property 'infineon,en-svid-control'. This property will enable the
> > > workaround, which utilizes ENABLE pin polarity flipping for output wh=
en
> > > the chip is in SVID mode.
> >=20
> > Why do you need a custom property for this? How come it is not possible
> > to determine what bus you are on?
> >=20
>=20
> That is not the point. Yes, it can be detected if the control method is
> PMBus or SVID. However, in SVID mode, SVID is supposed to control the
> output, not PMBUs. This is bypassed by controlling the polarity of the
> (physical) output enable signal. We do _not_ want this enabled automatica=
lly
> in SVID mode. Its side effects on random boards using this chip are unkno=
wn.
> Thus, this needs a property which specifically enables this functionality
> for users who _really_ need to use it and (hopefully) know what they are
> doing.

Hmm, reading this it makes a lot more sense why this is a property - I
guess I just struggled to understand the commit message here,
particularly what the benefit of using the workaround is. I'm still
having difficulty parsing the commit & property text though - its
unclear to me when you would need to use it - so I will stay out
of the way & let Rob or Krzysztof handle things.

--XfJu5TZS5xk5xqji
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQRh246EGq/8RLhDjO14tDGHoIJi0gUCZNJQ+gAKCRB4tDGHoIJi
0rsaAP4p4HX4bMrdis5l4TikUX588o40cMUso+iMzqcRc+4sBQEAiZOIdiIzqofV
HE+wZrIM/ImGNTwKIwWUHO0dKzccKg8=
=+V64
-----END PGP SIGNATURE-----

--XfJu5TZS5xk5xqji--