From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: From: Vlad Zakharov To: "sboyd@codeaurora.org" CC: "mark.rutland@arm.com" , "linux-kernel@vger.kernel.org" , "mturquette@baylibre.com" , "Jose.Abreu@synopsys.com" , "linux-clk@vger.kernel.org" , "linux-snps-arc@lists.infradead.org" Subject: Re: [PATCH v2] clk/axs10x: introduce AXS10X pll driver Date: Thu, 20 Apr 2017 15:13:41 +0000 Message-ID: <1492701221.18176.51.camel@synopsys.com> References: <1487682670-4164-1-git-send-email-vzakhar@synopsys.com> <20170405013525.GJ18246@codeaurora.org> <1491408370.9650.24.camel@synopsys.com> <20170419164949.GH7065@codeaurora.org> In-Reply-To: <20170419164949.GH7065@codeaurora.org> Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 List-ID: SGkgU3RlcGhlbiwNCg0KT24gV2VkLCAyMDE3LTA0LTE5IGF0IDA5OjQ5IC0wNzAwLCBzYm95ZEBj b2RlYXVyb3JhLm9yZyB3cm90ZToNCj4gT24gMDQvMDUsIFZsYWQgWmFraGFyb3Ygd3JvdGU6DQo+ ID4gDQo+ID4gSGkgU3RlcGhlbiwNCj4gPiANCj4gPiBPbiBUdWUsIDIwMTctMDQtMDQgYXQgMTg6 MzUgLTA3MDAsIFN0ZXBoZW4gQm95ZCB3cm90ZToNCj4gPiA+IA0KPiA+ID4gPiANCj4gPiA+ID4g K8KgwqDCoMKgwqAucGxsX3RhYmxlID0gKHN0cnVjdCBwbGxfb2ZfdGFibGUgW10pew0KPiA+ID4g PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqB7DQo+ID4gPiA+ICvCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAucHJhdGUgPSAyNzAwMDAwMCwNCj4gPiA+IA0KPiA+ ID4gQ2FuIHRoaXMgYmUgYW5vdGhlciBjbGsgaW4gdGhlIGZyYW1ld29yayBpbnN0ZWFkIG9mIGhh cmRjb2RpbmcNCj4gPiA+IHRoZSBwYXJlbnQgcmF0ZT8NCj4gPiANCj4gPiBJbiBmYWN0IHRoZXJl IGlzIGFub3RoZXIgY2xrIGluIHRoZSBmcmFtZXdvcmsgdGhhdCByZXByZXNlbnRzIHRoaXMgcGFy ZW50IGNsb2NrLiBCdXQgdGhpcyBmaWVsZCBpcyBuZWVkZWQgdG8gZ2V0DQo+ID4gYXBwcm9wcmlh dGUgcGxsX2NmZ190YWJsZSBhcyBpdCBkZXBlbmRzIG9uIHBhcmVudCBjbG9jayBmcmVxdWVuY3ku IEJlbG93IGluIHBsbF9jZmdfZ2V0IGZ1bmN0aW9uIHdlIGFyZSBzZWFyY2hpbmcNCj4gPiBmb3IN Cj4gPiB0aGUgY29ycmVjdCB0YWJsZSBjb21wYXJpbmcgLnBhcmVudF9ub2RlIGZpZWxkIHdpdGgg cmVhbCBoYXJkd2FyZSBwYXJlbnQgY2xvY2sgZnJlcXVlbmN5Og0KPiA+IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0+OC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KPiA+IGZvciAoaSA9IDA7IHBsbF90YWJsZVtpXS5wcmF0ZSAhPSAwOyBpKyspDQo+ID4gwqAg wqAgaWYgKHBsbF90YWJsZVtpXS5wcmF0ZSA9PSBwcmF0ZSkNCj4gPiDCoCDCoCDCoCDCoCByZXR1 cm4gcGxsX3RhYmxlW2ldLnBsbF9jZmdfdGFibGU7DQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLT44LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0K PiBXaGVuIGlzIHRoYXQgZG9uZSB0aG91Z2g/IER1cmluZyByb3VuZF9yYXRlIGFuZCByZWNhbGNf cmF0ZSB0aGUNCj4gcGFyZW50IGZyZXF1ZW5jeSBpcyBwYXNzZWQgaW50byB0aGUgZnVuY3Rpb24s IHNvIGl0IHNob3VsZCBiZQ0KPiBwb3NzaWJsZSB0byB1c2UgdGhhdCBpZiB0aGUgdHJlZSBpcyBw cm9wZXJseSBleHByZXNzZWQuDQo+IA0KDQpJIHRoaW5rIHRoYXQgd2UgaGF2ZW4ndCB1bmRlcnN0 b29kIGVhY2ggb3RoZXIgY29ycmVjdGx5Lg0KQW55d2F5IEkgaGF2ZSBjaGVja2VkIG91dCBvdXIg aGFyZHdhcmUgZG9jdW1lbnRhdGlvbnMgYW5kIGZpbmQgb3V0IHRoYXQgaW4gZmFjdCBmb3IgdG9k YXkncyB2ZXJzaW9uIG9mIGhhcmR3YXJlIHdlIGRvbid0DQpoYXZlIHNpdHVhdGlvbnMgd2hlbiBz dWNoIHBsbHMgY2FuIGJlIGRyaXZlbiBieSBkaWZmZXJlbnQgcGFyZW50IGNsb2NrLiBTbyB0aGlz IGFwcHJvYWNoIGlzIG5vdCByZXF1aXJlZCBhdCB0aGUgbW9tZW50Lg0KSSBhbSBnb2luZyB0byBz aW1wbGlmeSBteSBkcml2ZXIgc28gaXQgd2lsbCByZWZsZWN0IGN1cnJlbnQgdmVyc2lvbiBvZiBo YXJkd2FyZSBhbmQgaWYgYW55dGhpbmcgY2hhbmdlcyBJIHdpbGwgYmV0dGVyDQpwcm92aWRlIGEg bmV3IHBhdGNoLg0KDQo+ID4gU3VyZS4gQ291bGQgeW91IGJlIHNvIGtpbmQgdG8gZXhwbGFpbiB3 aGF0IGlzIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gaHcgYW5kIG5vbi1odyBiYXNlZCBwcm92aWRl ciBhbmQgY2xrDQo+ID4gcmVnaXN0cmF0aW9uDQo+ID4gZnVuY3Rpb25zIHBsZWFzZT8gSW4gd2hp Y2ggY2FzZXMgdGhleSBhcmUgcHJlZmVycmVkP8KgDQo+ID4gDQo+IA0KPiBXZSdyZSB0cnlpbmcg dG8gc3BsaXQgdGhlIGNvbnN1bWVyIGFuZCBwcm92aWRlciBBUElzIGFsb25nIHN0cnVjdA0KPiBj bGtfaHcgYW5kIHN0cnVjdCBjbGsgcmVzcGVjdGl2ZWx5LiBJZiB3ZSBjYW4gaGF2ZSBkcml2ZXJz IG9ubHkNCj4gcmVnaXN0ZXJzIGNsa19odyBwb2ludGVycyBhbmQgbmV2ZXIgZ2V0IGJhY2sgYW55 dGhpbmcgYnV0IGFuDQo+IGVycm9yIGNvZGUsIHRoZW4gd2UgY2FuIGZvcmNlIGNvbnN1bWVycyB0 byBhbHdheXMgZ28gdGhyb3VnaCB0aGUNCj4gY2xrX2dldCgpIGZhbWlseSBvZiBBUElzLiBUaGVu IHdlIGNhbiBlYXNpbHkgdGVsbCB3aG8gaXMgYQ0KPiBwcm92aWRlciwgd2hvIGlzIGEgY29uc3Vt ZXIsIGFuZCB3aG8gaXMgYSBwcm92aWRlciArIGEgY29uc3VtZXIuDQo+IFJpZ2h0IG5vdyB0aGlz IGlzbid0IGFsd2F5cyBjbGVhciBjdXQgYmVjYXVzZSBjbGtfaHcgaGFzIGFjY2Vzcw0KPiB0byBz dHJ1Y3QgY2xrLCBhbmQgYWxzbyBjbGtfcmVnaXN0ZXIoKSByZXR1cm5zIGEgY2xrIHBvaW50ZXIs IGJ1dA0KPiBpdCBkb2Vzbid0IHJlYWxseSBnZXQgdXNlZCBieSBhbnl0aGluZyBpbiBhIHByb3Zp ZGVyIGRyaXZlciwNCj4gdW5sZXNzIHByb3ZpZGVyIGRyaXZlcnMgYXJlIGRvaW5nIHNvbWV0aGlu ZyB3aXRoIHRoZSBjb25zdW1lcg0KPiBBUEkuDQoNCkkgYW0gc29ycnkgZm9yIG15IGZvb2xpc2gg cXVlc3Rpb25zLCBidXQgYXMgSSB1bmRlcnN0YW5kIEkgc2hvdWxkIHVzZSBody1iYXNlZCBmdW5j dGlvbnMgZm9yIGNsayBwcm92aWRlcnMgYnV0IGl0IGlzIG5vdA0Kc3RpbGwgY2xlYXIgZW5vdWdo IGZvciBtZSB3aGVuIHNob3VsZCBJIHVzZSBub24taHcgZnVuY3Rpb25zPyBEb2VzIGFueSBkcml2 ZXJzIG5lZWQgc3RydWN0IGNsayB3aGVuIHRoZXkgYXJlIGluaXRpYXRpbmcNCm9yIHByb2Jpbmcg dGhlbXNlbHZlcz8gQW5kIHdoYXQgY2xrIGNvbnN1bWVyIGNhbiBiZSB1c2VkIGZvcj8NCg0KPiAN Cj4gPiANCj4gPiA+IA0KPiA+ID4gDQo+ID4gPiA+IA0KPiA+ID4gPiArfQ0KPiA+ID4gPiArDQo+ ID4gPiA+ICtDTEtfT0ZfREVDTEFSRShheHMxMHhfcGxsX2Nsb2NrLCAic25wcyxheHMxMHgtYXJj LXBsbC1jbG9jayIsIG9mX3BsbF9jbGtfc2V0dXApOw0KPiA+ID4gDQo+ID4gPiBEb2VzIHRoaXMg bmVlZCB0byBiZSBDTEtfT0ZfREVDTEFSRV9EUklWRVI/IEkgbWVhbiBkb2VzIHRoZQ0KPiA+ID4g ZHJpdmVyIG5lZWQgdG8gcHJvYmUgYW5kIGFsc28gaGF2ZSB0aGlzIG9mIGRlY2xhcmUgaGFwcGVu PyBJcyB0aGUNCj4gPiA+IFBMTCBzcGVjaWFsIGFuZCBuZWVkcyB0byBiZSB1c2VkIGZvciB0aGUg dGltZXJzPw0KPiA+IA0KPiA+IEl0IGlzIHNwZWNpYWwgYW5kIGlzIHVzZWQgZm9yIHRoZSB0aW1l cnMsIHNvIHdlIGhhdmUgdG8gQ0xLX09GX0RFQ0xBUkUgaXQuIE9uIHRoZSBvdGhlciBoYW5kIHNp bWlsYXIgcGxsIGlzIHVzZWQgdG8NCj4gPiBkcml2ZSBQR1UgY2xvY2sgZnJlcXVlbmN5IGFuZCBv dGhlciBzdWJzeXN0ZW1zIGFuZCBzbyB3ZSBhZGQgdXN1YWwgcHJvYmUgZnVuYy4NCj4gPiANCj4g DQo+IFByZXN1bWFibHkgd2UnbGwgaGF2ZSBkaWZmZXJlbnQgY29tcGF0aWJsZSBzdHJpbmdzIGZv ciB0aGUNCj4gZGlmZmVyZW50IFBMTHMgdGhlbj8gQ0xLX09GX0RFQ0xBUkUoKSB3aWxsIG1ha2Ug aXQgc28gdGhhdCB0aGUNCj4gZGV2aWNlIG5vZGUgdGhhdCBtYXRjaGVzIG5ldmVyIGdldHMgYSAt PnByb2JlKCkgZnJvbSBhDQo+IHBsYXRmb3JtX2RyaXZlciBjYWxsZWQgb24gaXQuIElmIHlvdSB3 YW50IGl0IHRvIGJlIGNhbGxlZCB0d2ljZSwNCj4gdGhlbiB5b3UgbmVlZCB0byB1c2UgQ0xLX09G X0RFQ0xBUkVfRFJJVkVSKCkgaW5zdGVhZC4NCj4gDQoNCkluIGZhY3Qgd2UgZG9uJ3QgbmVlZCBp dCB0byBiZSBjYWxsZWQgdHdpY2UuIEFuZCBhcyB5b3UgY2FuIHNlZSBJIGRvIHByYWN0aWNhbGx5 IHRoZSBzYW1lIHRoaW5ncyBpbiBzZXR1cCBhbmQgcHJvYmUNCmZ1bmN0aW9ucy4gU28gbWF5YmUg SSBjYW4gc29tZWhvdyBhdm9pZCB0aGlzIGNvZGUgZHVwbGljYXRpb24/wqANCkkgbWVhbiB0aGF0 IHRoaXMgZHJpdmVyIGlzIGdvaW5nIGVpdGhlciB0byBiZSB1c2VkIGZvciB0aGUgdGltZXJzIG9y IGFzIGEgc2ltcGxlIHBsYXRmb3JtIGRyaXZlciBmb3IgY2xvY2tpbmcgc29tZQ0KcGVyaXBoZXJh cy4gU28gZm9yIHRoZSBmaXJzdCBjYXNlIEkgaGF2ZSB3cml0dGVuIGEgc2V0dXAgZnVuY3Rpb24g dG8gQ0xLX09GX0RFQ0xBUkUgbXkgZHJpdmVyIGFuZCBmb3IgdGhlIHNlY29uZCBjYXNlDQpJJ3Zl IHdyaXR0ZW4gdXN1YWwgcHJvYmUgZnVuY3Rpb24uIE1heWJlIEkgYW0gbWlzdGFrZW4gYW5kIGl0 IGlzIG5vdCB0aGUgcmlnaHQgd2F5Pw0KDQpUaGFuayB5b3UgZm9yIHlvdSBhbnN3ZXJzLsKgDQoN Ci0tIA0KQmVzdCByZWdhcmRzLA0KVmxhZCBaYWtoYXJvdiA8dnpha2hhckBzeW5vcHN5cy5jb20+ From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vladislav.Zakharov@synopsys.com (Vlad Zakharov) Date: Thu, 20 Apr 2017 15:13:41 +0000 Subject: [PATCH v2] clk/axs10x: introduce AXS10X pll driver In-Reply-To: <20170419164949.GH7065@codeaurora.org> References: <1487682670-4164-1-git-send-email-vzakhar@synopsys.com> <20170405013525.GJ18246@codeaurora.org> <1491408370.9650.24.camel@synopsys.com> <20170419164949.GH7065@codeaurora.org> List-ID: Message-ID: <1492701221.18176.51.camel@synopsys.com> To: linux-snps-arc@lists.infradead.org Hi Stephen, On Wed, 2017-04-19@09:49 -0700, sboyd@codeaurora.org wrote: > On 04/05, Vlad Zakharov wrote: > > > > Hi Stephen, > > > > On Tue, 2017-04-04@18:35 -0700, Stephen Boyd wrote: > > > > > > > > > > > +?????.pll_table = (struct pll_of_table []){ > > > > +?????????????{ > > > > +?????????????????????.prate = 27000000, > > > > > > Can this be another clk in the framework instead of hardcoding > > > the parent rate? > > > > In fact there is another clk in the framework that represents this parent clock. But this field is needed to get > > appropriate pll_cfg_table as it depends on parent clock frequency. Below in pll_cfg_get function we are searching > > for > > the correct table comparing .parent_node field with real hardware parent clock frequency: > > ---------------------------------->8------------------------------------ > > for (i = 0; pll_table[i].prate != 0; i++) > > ? ? if (pll_table[i].prate == prate) > > ? ? ? ? return pll_table[i].pll_cfg_table; > > ---------------------------------->8------------------------------------ > > When is that done though? During round_rate and recalc_rate the > parent frequency is passed into the function, so it should be > possible to use that if the tree is properly expressed. > I think that we haven't understood each other correctly. Anyway I have checked out our hardware documentations and find out that in fact for today's version of hardware we don't have situations when such plls can be driven by different parent clock. So this approach is not required at the moment. I am going to simplify my driver so it will reflect current version of hardware and if anything changes I will better provide a new patch. > > Sure. Could you be so kind to explain what is the difference between hw and non-hw based provider and clk > > registration > > functions please? In which cases they are preferred?? > > > > We're trying to split the consumer and provider APIs along struct > clk_hw and struct clk respectively. If we can have drivers only > registers clk_hw pointers and never get back anything but an > error code, then we can force consumers to always go through the > clk_get() family of APIs. Then we can easily tell who is a > provider, who is a consumer, and who is a provider + a consumer. > Right now this isn't always clear cut because clk_hw has access > to struct clk, and also clk_register() returns a clk pointer, but > it doesn't really get used by anything in a provider driver, > unless provider drivers are doing something with the consumer > API. I am sorry for my foolish questions, but as I understand I should use hw-based functions for clk providers but it is not still clear enough for me when should I use non-hw functions? Does any drivers need struct clk when they are initiating or probing themselves? And what clk consumer can be used for? > > > > > > > > > > > > > > > > > +} > > > > + > > > > +CLK_OF_DECLARE(axs10x_pll_clock, "snps,axs10x-arc-pll-clock", of_pll_clk_setup); > > > > > > Does this need to be CLK_OF_DECLARE_DRIVER? I mean does the > > > driver need to probe and also have this of declare happen? Is the > > > PLL special and needs to be used for the timers? > > > > It is special and is used for the timers, so we have to CLK_OF_DECLARE it. On the other hand similar pll is used to > > drive PGU clock frequency and other subsystems and so we add usual probe func. > > > > Presumably we'll have different compatible strings for the > different PLLs then? CLK_OF_DECLARE() will make it so that the > device node that matches never gets a ->probe() from a > platform_driver called on it. If you want it to be called twice, > then you need to use CLK_OF_DECLARE_DRIVER() instead. > In fact we don't need it to be called twice. And as you can see I do practically the same things in setup and probe functions. So maybe I can somehow avoid this code duplication?? I mean that this driver is going either to be used for the timers or as a simple platform driver for clocking some peripheras. So for the first case I have written a setup function to CLK_OF_DECLARE my driver and for the second case I've written usual probe function. Maybe I am mistaken and it is not the right way? Thank you for you answers.? -- Best regards, Vlad Zakharov From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S970396AbdDTPNy (ORCPT ); Thu, 20 Apr 2017 11:13:54 -0400 Received: from us01smtprelay-2.synopsys.com ([198.182.60.111]:38491 "EHLO smtprelay.synopsys.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S970326AbdDTPNw (ORCPT ); Thu, 20 Apr 2017 11:13:52 -0400 From: Vlad Zakharov To: "sboyd@codeaurora.org" CC: "mark.rutland@arm.com" , "linux-kernel@vger.kernel.org" , "mturquette@baylibre.com" , "Jose.Abreu@synopsys.com" , "linux-clk@vger.kernel.org" , "linux-snps-arc@lists.infradead.org" Subject: Re: [PATCH v2] clk/axs10x: introduce AXS10X pll driver Thread-Topic: [PATCH v2] clk/axs10x: introduce AXS10X pll driver Thread-Index: AQHSjEP84oiIqPaSbUyCNi/neN7GXaG2H7yAgADzSQCAFgzWgIABd3mA Date: Thu, 20 Apr 2017 15:13:41 +0000 Message-ID: <1492701221.18176.51.camel@synopsys.com> References: <1487682670-4164-1-git-send-email-vzakhar@synopsys.com> <20170405013525.GJ18246@codeaurora.org> <1491408370.9650.24.camel@synopsys.com> <20170419164949.GH7065@codeaurora.org> In-Reply-To: <20170419164949.GH7065@codeaurora.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.121.8.118] Content-Type: text/plain; charset="utf-8" Content-ID: <0F2AE462DB0E95408BCF09F0D38C1636@internal.synopsys.com> MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id v3KFDwbQ023319 Hi Stephen, On Wed, 2017-04-19 at 09:49 -0700, sboyd@codeaurora.org wrote: > On 04/05, Vlad Zakharov wrote: > > > > Hi Stephen, > > > > On Tue, 2017-04-04 at 18:35 -0700, Stephen Boyd wrote: > > > > > > > > > > > +     .pll_table = (struct pll_of_table []){ > > > > +             { > > > > +                     .prate = 27000000, > > > > > > Can this be another clk in the framework instead of hardcoding > > > the parent rate? > > > > In fact there is another clk in the framework that represents this parent clock. But this field is needed to get > > appropriate pll_cfg_table as it depends on parent clock frequency. Below in pll_cfg_get function we are searching > > for > > the correct table comparing .parent_node field with real hardware parent clock frequency: > > ---------------------------------->8------------------------------------ > > for (i = 0; pll_table[i].prate != 0; i++) > >     if (pll_table[i].prate == prate) > >         return pll_table[i].pll_cfg_table; > > ---------------------------------->8------------------------------------ > > When is that done though? During round_rate and recalc_rate the > parent frequency is passed into the function, so it should be > possible to use that if the tree is properly expressed. > I think that we haven't understood each other correctly. Anyway I have checked out our hardware documentations and find out that in fact for today's version of hardware we don't have situations when such plls can be driven by different parent clock. So this approach is not required at the moment. I am going to simplify my driver so it will reflect current version of hardware and if anything changes I will better provide a new patch. > > Sure. Could you be so kind to explain what is the difference between hw and non-hw based provider and clk > > registration > > functions please? In which cases they are preferred?  > > > > We're trying to split the consumer and provider APIs along struct > clk_hw and struct clk respectively. If we can have drivers only > registers clk_hw pointers and never get back anything but an > error code, then we can force consumers to always go through the > clk_get() family of APIs. Then we can easily tell who is a > provider, who is a consumer, and who is a provider + a consumer. > Right now this isn't always clear cut because clk_hw has access > to struct clk, and also clk_register() returns a clk pointer, but > it doesn't really get used by anything in a provider driver, > unless provider drivers are doing something with the consumer > API. I am sorry for my foolish questions, but as I understand I should use hw-based functions for clk providers but it is not still clear enough for me when should I use non-hw functions? Does any drivers need struct clk when they are initiating or probing themselves? And what clk consumer can be used for? > > > > > > > > > > > > > > > > > +} > > > > + > > > > +CLK_OF_DECLARE(axs10x_pll_clock, "snps,axs10x-arc-pll-clock", of_pll_clk_setup); > > > > > > Does this need to be CLK_OF_DECLARE_DRIVER? I mean does the > > > driver need to probe and also have this of declare happen? Is the > > > PLL special and needs to be used for the timers? > > > > It is special and is used for the timers, so we have to CLK_OF_DECLARE it. On the other hand similar pll is used to > > drive PGU clock frequency and other subsystems and so we add usual probe func. > > > > Presumably we'll have different compatible strings for the > different PLLs then? CLK_OF_DECLARE() will make it so that the > device node that matches never gets a ->probe() from a > platform_driver called on it. If you want it to be called twice, > then you need to use CLK_OF_DECLARE_DRIVER() instead. > In fact we don't need it to be called twice. And as you can see I do practically the same things in setup and probe functions. So maybe I can somehow avoid this code duplication?  I mean that this driver is going either to be used for the timers or as a simple platform driver for clocking some peripheras. So for the first case I have written a setup function to CLK_OF_DECLARE my driver and for the second case I've written usual probe function. Maybe I am mistaken and it is not the right way? Thank you for you answers.  -- Best regards, Vlad Zakharov