Re: [PATCH v2 1/4] dt-bindings: iio: adc: ad7192: Add properties

From: "Nuno Sá" <noname.nuno@gmail.com>
To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
	David Lechner <dlechner@baylibre.com>,
	Alisa-Dariana Roman <alisadariana@gmail.com>
Cc: Alisa-Dariana Roman <alisa.roman@analog.com>,
	Michael Hennerich <michael.hennerich@analog.com>,
	linux-iio@vger.kernel.org,  devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Lars-Peter Clausen <lars@metafoo.de>,
	Alexandru Tachici <alexandru.tachici@analog.com>,
	 Jonathan Cameron <jic23@kernel.org>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Conor Dooley <conor+dt@kernel.org>,
	 Ceclan Dumitru <dumitru.ceclan@analog.com>
Subject: Re: [PATCH v2 1/4] dt-bindings: iio: adc: ad7192: Add properties
Date: Mon, 05 Feb 2024 10:50:55 +0100	[thread overview]
Message-ID: <b319f01721fba04cb91d4bc61db69894d0e9a0c9.camel@gmail.com> (raw)
In-Reply-To: <5bc2bd1e-16a8-4de4-bec6-9391addacc89@linaro.org>

On Mon, 2024-02-05 at 10:28 +0100, Krzysztof Kozlowski wrote:
> On 02/02/2024 23:20, David Lechner wrote:
> > > > 
> > > > And this should be input clock.
> > > > 
> > > > > +    type: boolean
> > > > > +
> > > > > +  adi,int-clock-output-enable:
> > > > > +    description: |
> > > > > +      Internal 4.92 MHz clock available on MCLK2 pin.
> > > > > +    type: boolean
> > > > 
> > > > This should be clock-cells and clock provider.
> > > > 
> > > > Unless you are just documenting already used interface which you do not
> > > > want to break...
> > 
> > This property is already used in the mainline Linux driver, so sounds
> > like the "don't want to break it" case. But it would make sense to
> > deprecate this property and use standard clock provider bindings
> > instead.
> 
> One could think like that, but what type of process would it create?
> Send driver changes WITHOUT binding, then document whatever crap you
> have saying "Linux already supports it!".
> 
> Whenever such argument is used, I am repeating the same.
> 
> Let's be more clear: NAK if this is clock provider and the only argument
> is that someone sneaked undocumented interface bypassing review.
> 

Fair enough... 

Alisa,

I guess you have two alternatives then:

1) Drop this patch;
2) Add proper clock provider properties.

I would obviously go with 2). You can then take care of backward compatibility in the
driver. Like, if clock-cells is present, ignore the legacy properties and properly
export the clocks we have in the device.

- Nuno Sá