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á
