Received-SPF: pass (google.com: domain of linux-kernel+bounces-33859-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Date: Mon, 22 Jan 2024 17:48:44 +0000
From: Conor Dooley <conor@kernel.org>
To: Jonathan Cameron <jic23@kernel.org>
Cc: Ceclan Dumitru <mitrutzceclan@gmail.com>, linus.walleij@linaro.org,
	brgl@bgdev.pl, andy@kernel.org, linux-gpio@vger.kernel.org,
	Lars-Peter Clausen <lars@metafoo.de>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Michael Walle <michael@walle.cc>,
	Andy Shevchenko <andy.shevchenko@gmail.com>,
	Arnd Bergmann <arnd@arndb.de>, ChiaEn Wu <chiaen_wu@richtek.com>,
	Niklas Schnelle <schnelle@linux.ibm.com>,
	Leonard =?iso-8859-1?Q?G=F6hrs?= <l.goehrs@pengutronix.de>,
	Mike Looijmans <mike.looijmans@topic.nl>,
	Haibo Chen <haibo.chen@nxp.com>,
	Hugo Villeneuve <hvilleneuve@dimonoff.com>,
	David Lechner <dlechner@baylibre.com>,
	Ceclan Dumitru <dumitru.ceclan@analog.com>,
	linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v12 1/2] dt-bindings: adc: add AD7173
Message-ID: <20240122-bloating-dyslexic-cbc0258c898a@spud>
References: <20240118125001.12809-1-mitrutzceclan@gmail.com>
 <20240118-lunar-anthem-31bf3b9b351d@spud>
 <b96d5bfc-cc38-44c7-a88f-e7ac5e4eb71d@gmail.com>
 <20240118-freebase-uptake-ec5fdf786d20@spud>
 <20240121154118.389e4e87@jic23-huawei>
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="dlghW/7VOeuyh/eL"
Content-Disposition: inline
In-Reply-To: <20240121154118.389e4e87@jic23-huawei>


--dlghW/7VOeuyh/eL
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Jan 21, 2024 at 03:41:18PM +0000, Jonathan Cameron wrote:
> On Thu, 18 Jan 2024 16:06:29 +0000
> Conor Dooley <conor@kernel.org> wrote:
> > On Thu, Jan 18, 2024 at 05:51:20PM +0200, Ceclan Dumitru wrote:
> > > On 1/18/24 17:23, Conor Dooley wrote: =20
> > > > On Thu, Jan 18, 2024 at 02:49:22PM +0200, Dumitru Ceclan wrote: =20
> > > >> +  adi,clock-select:
> > > >> +    description: |
> > > >> +      Select the ADC clock source. Valid values are:
> > > >> +      int         : Internal oscillator
> > > >> +      int-out     : Internal oscillator with output on XTAL2 pin
> > > >> +      ext-clk     : External clock input on XTAL2 pin
> > > >> +      xtal        : External crystal on XTAL1 and XTAL2 pins
> > > >> +
> > > >> +    $ref: /schemas/types.yaml#/definitions/string
> > > >> +    enum:
> > > >> +      - int
> > > >> +      - int-out
> > > >> +      - ext-clk
> > > >> +      - xtal
> > > >> +    default: int =20
> > > > I am not a fan of properties like this one, that in my view reimple=
ment
> > > > things that are supported by the regular clocks properties. I've got
> > > > some questions for you so I can understand whether or not this cust=
om
> > > > property is required.
> > > >=20
> > > > Whether or not the ext-clk or xtal is used is known based on
> > > > clock-names - why is the custom property required to determine that=
? =20
> >=20
> > > > If neither of those clocks are present, then the internal clock wou=
ld be
> > > > used. Choosing to use the internal clock if an external one is prov=
ided
> > > > sounds to me like a software policy decision made by the operating
> > > > system. =20
> > >=20
> > > If there was no int-out, sure. I considered that the choice between i=
nt
> > > and int-out could be made here. So better for driver to choose int/in=
t-out? =20
> >=20
> > This part of my comments was specifically about choosing between use of
> > the internal clock when ext-clk or xtal are provided, which I think
> > excludes the possibility of using int-out, since the XTAL2 pin is an
> > input.
> >=20
> > There's 3 situations:
> > - no external clock provided
> > - ext-clk provided
> > - xtal provided
> >=20
> > For the former, you know you're in that state when no "clocks" property
> > is present. The latter two you can differentiate based on "clock-names".
> >=20
> > Choosing to use the internal clock if an external clock is provided
> > seems to be a software policy decision, unless I am mistaken.
>=20
> Agreed, though it rarely makes sense as if someone put down a precision
> clock they normally wanted you to use it!
>=20
> So as a general rule we don't both providing policy controls beyond if
> there is extra hardware (external clock source) then use that.
>=20
> If someone has a good reason to want to do something else then we can
> probably figure out a reasonable way to control it.

Yah, I figured there'd be few situations, outside of maybe debugging
hardware issues, where that internal clock is more desirable to use.

> > > > Finally, if the ADC has a clock output, why can that not be represe=
nted
> > > > by making the ADC a clock-controller?
> > > >  =20
> > >=20
> > > Was not familiar with this/did not cross my mind. So if xtal/ext-clk =
is
> > > present, the driver should detect it and disable the option for clock
> > > output? (Common pin XTAL2) =20
> >=20
> > Yeah, if those clocks are provided you would not register as a clock
> > controller. If there is a user of the output clock, it should have its
> > own "clocks" property that references the ADC's output.
> >=20
> > Your dt-binding could also make clocks/clock-names & clock-controller
> > mutually exclusive.
>=20
> That would indeed be the nicest solution.  How this has been done
> in drivers has somewhat 'evolved' over time, but this is the nicest
> option from point of view of standard bindings and clarity over what
> is going on.

Yeah, I know that this has not really been normal thing to do in some
corners of the kernel (ethernet PHYs in particular I think have been
rolling their own clock controller stuff) and I've been trying to push
back on these kinds of things for new devices.

Thanks,
Conor.

--dlghW/7VOeuyh/eL
Content-Type: application/pgp-signature; name="signature.asc"

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

iHUEABYIAB0WIQRh246EGq/8RLhDjO14tDGHoIJi0gUCZa6qfAAKCRB4tDGHoIJi
0vMQAQCkGjF6Fel/gAV0+3hyoOgjeGJlUQke4fQTA7TAyHhtgAD8D09ND39sB4Fl
GkrIpXdiwl4J3kvcv2KuxONa90Pj3QY=
=LJJG
-----END PGP SIGNATURE-----

--dlghW/7VOeuyh/eL--