From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751806AbeBTOTm (ORCPT ); Tue, 20 Feb 2018 09:19:42 -0500 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:43542 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751370AbeBTOTj (ORCPT ); Tue, 20 Feb 2018 09:19:39 -0500 Subject: Re: [PATCH 1/8] clk: Add clk_bulk_alloc functions To: Marek Szyprowski , Maciej Purski , linux-media@vger.kernel.org, linux-samsung-soc@vger.kernel.org, linux-arm-kernel@lists.infradead.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-clk@vger.kernel.org Cc: David Airlie , Michael Turquette , Kamil Debski , Andrzej Hajda , Sylwester Nawrocki , Thibault Saunier , Joonyoung Shim , Russell King , Krzysztof Kozlowski , Javier Martinez Canillas , Kukjin Kim , Hoegeun Kwon , Bartlomiej Zolnierkiewicz , Inki Dae , Jeongtae Park , Jacek Anaszewski , Andrzej Pietrasiewicz , Mauro Carvalho Chehab , Stephen Boyd , Seung-Woo Kim , Hans Verkuil , Kyungmin Park References: <1519055046-2399-1-git-send-email-m.purski@samsung.com> <1519055046-2399-2-git-send-email-m.purski@samsung.com> From: Robin Murphy Message-ID: Date: Tue, 20 Feb 2018 14:19:32 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Marek, On 20/02/18 09:36, Marek Szyprowski wrote: > Hi Robin, > > On 2018-02-19 17:29, Robin Murphy wrote: >> Hi Maciej, >> >> On 19/02/18 15:43, Maciej Purski wrote: >>> When a driver is going to use clk_bulk_get() function, it has to >>> initialize an array of clk_bulk_data, by filling its id fields. >>> >>> Add a new function to the core, which dynamically allocates >>> clk_bulk_data array and fills its id fields. Add clk_bulk_free() >>> function, which frees the array allocated by clk_bulk_alloc() function. >>> Add a managed version of clk_bulk_alloc(). >> >> Seeing how every subsequent patch ends up with the roughly this same >> stanza: >> >>     x = devm_clk_bulk_alloc(dev, num, names); >>     if (IS_ERR(x) >>         return PTR_ERR(x); >>     ret = devm_clk_bulk_get(dev, x, num); >> >> I wonder if it might be better to simply implement: >> >>     int devm_clk_bulk_alloc_get(dev, &x, num, names) >> >> that does the whole lot in one go, and let drivers that want to do >> more fiddly things continue to open-code the allocation. >> >> But perhaps that's an abstraction too far... I'm not all that familiar >> with the lie of the land here. > > Hmmm. This patchset clearly shows, that it would be much simpler if we > get rid of clk_bulk_data structure at all and let clk_bulk_* functions > to operate on struct clk *array[]. Typically the list of clock names > is already in some kind of array (taken from driver data or statically > embedded into driver), so there is little benefit from duplicating it > in clk_bulk_data. Sadly, I missed clk_bulk_* api discussion and maybe > there are other benefits from this approach. > > If not, I suggest simplifying clk_bulk_* api by dropping clk_bulk_data > structure and switching to clock ptr array: > > int clk_bulk_get(struct device *dev, int num_clock, struct clk *clocks[], >                  const char *clk_names[]); > int clk_bulk_prepare(int num_clks, struct clk *clks[]); > int clk_bulk_enable(int num_clks, struct clk *clks[]); > ... Yes, that's certainly a possibility; if on the other hand there are desirable reasons for the encapsulation (personally, I do think it's quite neat), then maybe num_clocks should get pushed down into clk_bulk_data as well - then with dedicated alloc/free functions as proposed here it could become a simple opaque cookie as far as callers are concerned. I also haven't looked into the origins of the bulk API design, though; I've just been familiarising myself from the perspective of reviewing general clk API usage in drivers. Robin. >>> Signed-off-by: Maciej Purski >>> --- >>>   drivers/clk/clk-bulk.c   | 16 ++++++++++++ >>>   drivers/clk/clk-devres.c | 37 +++++++++++++++++++++++++--- >>>   include/linux/clk.h      | 64 >>> ++++++++++++++++++++++++++++++++++++++++++++++++ >>>   3 files changed, 113 insertions(+), 4 deletions(-) >>> >> >> [...] >>> @@ -598,6 +645,23 @@ struct clk *clk_get_sys(const char *dev_id, >>> const char *con_id); >>>     #else /* !CONFIG_HAVE_CLK */ >>>   +static inline struct clk_bulk_data *clk_bulk_alloc(int num_clks, >>> +                           const char **clk_ids) >>> +{ >>> +    return NULL; >> >> Either way, is it intentional not returning an ERR_PTR() value in this >> case? Since NULL will pass an IS_ERR() check, it seems a bit fragile >> for an allocation call to apparently succeed when the whole API is >> configured out (and I believe introducing new uses of IS_ERR_OR_NULL() >> is in general strongly discouraged.) >> >> Robin. >> >>> +} >>> + >>> +static inline struct clk_bulk_data *devm_clk_bulk_alloc(struct >>> device *dev, >>> +                            int num_clks, >>> +                            const char **clk_ids) >>> +{ >>> +    return NULL; >>> +} >>> + >>> +static inline void clk_bulk_free(struct clk_bulk_data *clks) >>> +{ >>> +} >>> + >>>   static inline struct clk *clk_get(struct device *dev, const char *id) >>>   { >>>       return NULL; >> > Best regards From mboxrd@z Thu Jan 1 00:00:00 1970 From: Robin Murphy Subject: Re: [PATCH 1/8] clk: Add clk_bulk_alloc functions Date: Tue, 20 Feb 2018 14:19:32 +0000 Message-ID: References: <1519055046-2399-1-git-send-email-m.purski@samsung.com> <1519055046-2399-2-git-send-email-m.purski@samsung.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; Format="flowed" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: Content-Language: en-GB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Marek Szyprowski , Maciej Purski , linux-media@vger.kernel.org, linux-samsung-soc@vger.kernel.org, linux-arm-kernel@lists.infradead.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-clk@vger.kernel.org Cc: David Airlie , Michael Turquette , Kamil Debski , Sylwester Nawrocki , Thibault Saunier , Russell King , Krzysztof Kozlowski , Javier Martinez Canillas , Kukjin Kim , Hoegeun Kwon , Bartlomiej Zolnierkiewicz , Jeongtae Park , Jacek Anaszewski , Andrzej Pietrasiewicz , Mauro Carvalho Chehab , Stephen Boyd , Seung-Woo Kim , Hans Verkuil , Kyungmin Park List-Id: linux-samsung-soc@vger.kernel.org SGkgTWFyZWssCgpPbiAyMC8wMi8xOCAwOTozNiwgTWFyZWsgU3p5cHJvd3NraSB3cm90ZToKPiBI aSBSb2JpbiwKPiAKPiBPbiAyMDE4LTAyLTE5IDE3OjI5LCBSb2JpbiBNdXJwaHkgd3JvdGU6Cj4+ IEhpIE1hY2llaiwKPj4KPj4gT24gMTkvMDIvMTggMTU6NDMsIE1hY2llaiBQdXJza2kgd3JvdGU6 Cj4+PiBXaGVuIGEgZHJpdmVyIGlzIGdvaW5nIHRvIHVzZSBjbGtfYnVsa19nZXQoKSBmdW5jdGlv biwgaXQgaGFzIHRvCj4+PiBpbml0aWFsaXplIGFuIGFycmF5IG9mIGNsa19idWxrX2RhdGEsIGJ5 IGZpbGxpbmcgaXRzIGlkIGZpZWxkcy4KPj4+Cj4+PiBBZGQgYSBuZXcgZnVuY3Rpb24gdG8gdGhl IGNvcmUsIHdoaWNoIGR5bmFtaWNhbGx5IGFsbG9jYXRlcwo+Pj4gY2xrX2J1bGtfZGF0YSBhcnJh eSBhbmQgZmlsbHMgaXRzIGlkIGZpZWxkcy4gQWRkIGNsa19idWxrX2ZyZWUoKQo+Pj4gZnVuY3Rp b24sIHdoaWNoIGZyZWVzIHRoZSBhcnJheSBhbGxvY2F0ZWQgYnkgY2xrX2J1bGtfYWxsb2MoKSBm dW5jdGlvbi4KPj4+IEFkZCBhIG1hbmFnZWQgdmVyc2lvbiBvZiBjbGtfYnVsa19hbGxvYygpLgo+ Pgo+PiBTZWVpbmcgaG93IGV2ZXJ5IHN1YnNlcXVlbnQgcGF0Y2ggZW5kcyB1cCB3aXRoIHRoZSBy b3VnaGx5IHRoaXMgc2FtZSAKPj4gc3RhbnphOgo+Pgo+PiDCoMKgwqDCoHggPSBkZXZtX2Nsa19i dWxrX2FsbG9jKGRldiwgbnVtLCBuYW1lcyk7Cj4+IMKgwqDCoMKgaWYgKElTX0VSUih4KQo+PiDC oMKgwqDCoMKgwqDCoCByZXR1cm4gUFRSX0VSUih4KTsKPj4gwqDCoMKgwqByZXQgPSBkZXZtX2Ns a19idWxrX2dldChkZXYsIHgsIG51bSk7Cj4+Cj4+IEkgd29uZGVyIGlmIGl0IG1pZ2h0IGJlIGJl dHRlciB0byBzaW1wbHkgaW1wbGVtZW50Ogo+Pgo+PiDCoMKgwqDCoGludCBkZXZtX2Nsa19idWxr X2FsbG9jX2dldChkZXYsICZ4LCBudW0sIG5hbWVzKQo+Pgo+PiB0aGF0IGRvZXMgdGhlIHdob2xl IGxvdCBpbiBvbmUgZ28sIGFuZCBsZXQgZHJpdmVycyB0aGF0IHdhbnQgdG8gZG8gCj4+IG1vcmUg ZmlkZGx5IHRoaW5ncyBjb250aW51ZSB0byBvcGVuLWNvZGUgdGhlIGFsbG9jYXRpb24uCj4+Cj4+ IEJ1dCBwZXJoYXBzIHRoYXQncyBhbiBhYnN0cmFjdGlvbiB0b28gZmFyLi4uIEknbSBub3QgYWxs IHRoYXQgZmFtaWxpYXIgCj4+IHdpdGggdGhlIGxpZSBvZiB0aGUgbGFuZCBoZXJlLgo+IAo+IEht bW0uIFRoaXMgcGF0Y2hzZXQgY2xlYXJseSBzaG93cywgdGhhdCBpdCB3b3VsZCBiZSBtdWNoIHNp bXBsZXIgaWYgd2UKPiBnZXQgcmlkIG9mIGNsa19idWxrX2RhdGEgc3RydWN0dXJlIGF0IGFsbCBh bmQgbGV0IGNsa19idWxrXyogZnVuY3Rpb25zCj4gdG8gb3BlcmF0ZSBvbiBzdHJ1Y3QgY2xrICph cnJheVtdLiBUeXBpY2FsbHkgdGhlIGxpc3Qgb2YgY2xvY2sgbmFtZXMKPiBpcyBhbHJlYWR5IGlu IHNvbWUga2luZCBvZiBhcnJheSAodGFrZW4gZnJvbSBkcml2ZXIgZGF0YSBvciBzdGF0aWNhbGx5 Cj4gZW1iZWRkZWQgaW50byBkcml2ZXIpLCBzbyB0aGVyZSBpcyBsaXR0bGUgYmVuZWZpdCBmcm9t IGR1cGxpY2F0aW5nIGl0Cj4gaW4gY2xrX2J1bGtfZGF0YS4gU2FkbHksIEkgbWlzc2VkIGNsa19i dWxrXyogYXBpIGRpc2N1c3Npb24gYW5kIG1heWJlCj4gdGhlcmUgYXJlIG90aGVyIGJlbmVmaXRz IGZyb20gdGhpcyBhcHByb2FjaC4KPiAKPiBJZiBub3QsIEkgc3VnZ2VzdCBzaW1wbGlmeWluZyBj bGtfYnVsa18qIGFwaSBieSBkcm9wcGluZyBjbGtfYnVsa19kYXRhCj4gc3RydWN0dXJlIGFuZCBz d2l0Y2hpbmcgdG8gY2xvY2sgcHRyIGFycmF5Ogo+IAo+IGludCBjbGtfYnVsa19nZXQoc3RydWN0 IGRldmljZSAqZGV2LCBpbnQgbnVtX2Nsb2NrLCBzdHJ1Y3QgY2xrICpjbG9ja3NbXSwKPiAgwqDC oMKgIMKgwqDCoCDCoMKgwqAgwqDCoMKgwqAgY29uc3QgY2hhciAqY2xrX25hbWVzW10pOwo+IGlu dCBjbGtfYnVsa19wcmVwYXJlKGludCBudW1fY2xrcywgc3RydWN0IGNsayAqY2xrc1tdKTsKPiBp bnQgY2xrX2J1bGtfZW5hYmxlKGludCBudW1fY2xrcywgc3RydWN0IGNsayAqY2xrc1tdKTsKPiAu Li4KClllcywgdGhhdCdzIGNlcnRhaW5seSBhIHBvc3NpYmlsaXR5OyBpZiBvbiB0aGUgb3RoZXIg aGFuZCB0aGVyZSBhcmUgCmRlc2lyYWJsZSByZWFzb25zIGZvciB0aGUgZW5jYXBzdWxhdGlvbiAo cGVyc29uYWxseSwgSSBkbyB0aGluayBpdCdzIApxdWl0ZSBuZWF0KSwgdGhlbiBtYXliZSBudW1f Y2xvY2tzIHNob3VsZCBnZXQgcHVzaGVkIGRvd24gaW50byAKY2xrX2J1bGtfZGF0YSBhcyB3ZWxs IC0gdGhlbiB3aXRoIGRlZGljYXRlZCBhbGxvYy9mcmVlIGZ1bmN0aW9ucyBhcyAKcHJvcG9zZWQg aGVyZSBpdCBjb3VsZCBiZWNvbWUgYSBzaW1wbGUgb3BhcXVlIGNvb2tpZSBhcyBmYXIgYXMgY2Fs bGVycyAKYXJlIGNvbmNlcm5lZC4KCkkgYWxzbyBoYXZlbid0IGxvb2tlZCBpbnRvIHRoZSBvcmln aW5zIG9mIHRoZSBidWxrIEFQSSBkZXNpZ24sIHRob3VnaDsgCkkndmUganVzdCBiZWVuIGZhbWls aWFyaXNpbmcgbXlzZWxmIGZyb20gdGhlIHBlcnNwZWN0aXZlIG9mIHJldmlld2luZyAKZ2VuZXJh bCBjbGsgQVBJIHVzYWdlIGluIGRyaXZlcnMuCgpSb2Jpbi4KCj4+PiBTaWduZWQtb2ZmLWJ5OiBN YWNpZWogUHVyc2tpIDxtLnB1cnNraUBzYW1zdW5nLmNvbT4KPj4+IC0tLQo+Pj4gwqAgZHJpdmVy cy9jbGsvY2xrLWJ1bGsuY8KgwqAgfCAxNiArKysrKysrKysrKysKPj4+IMKgIGRyaXZlcnMvY2xr L2Nsay1kZXZyZXMuYyB8IDM3ICsrKysrKysrKysrKysrKysrKysrKysrKystLS0KPj4+IMKgIGlu Y2x1ZGUvbGludXgvY2xrLmjCoMKgwqDCoMKgIHwgNjQgCj4+PiArKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysKPj4+IMKgIDMgZmlsZXMgY2hhbmdlZCwgMTEz IGluc2VydGlvbnMoKyksIDQgZGVsZXRpb25zKC0pCj4+Pgo+Pgo+PiBbLi4uXQo+Pj4gQEAgLTU5 OCw2ICs2NDUsMjMgQEAgc3RydWN0IGNsayAqY2xrX2dldF9zeXMoY29uc3QgY2hhciAqZGV2X2lk LCAKPj4+IGNvbnN0IGNoYXIgKmNvbl9pZCk7Cj4+PiDCoCDCoCAjZWxzZSAvKiAhQ09ORklHX0hB VkVfQ0xLICovCj4+PiDCoCArc3RhdGljIGlubGluZSBzdHJ1Y3QgY2xrX2J1bGtfZGF0YSAqY2xr X2J1bGtfYWxsb2MoaW50IG51bV9jbGtzLAo+Pj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgY29uc3QgY2hhciAqKmNsa19pZHMpCj4+PiArewo+ Pj4gK8KgwqDCoCByZXR1cm4gTlVMTDsKPj4KPj4gRWl0aGVyIHdheSwgaXMgaXQgaW50ZW50aW9u YWwgbm90IHJldHVybmluZyBhbiBFUlJfUFRSKCkgdmFsdWUgaW4gdGhpcyAKPj4gY2FzZT8gU2lu Y2UgTlVMTCB3aWxsIHBhc3MgYW4gSVNfRVJSKCkgY2hlY2ssIGl0IHNlZW1zIGEgYml0IGZyYWdp bGUgCj4+IGZvciBhbiBhbGxvY2F0aW9uIGNhbGwgdG8gYXBwYXJlbnRseSBzdWNjZWVkIHdoZW4g dGhlIHdob2xlIEFQSSBpcyAKPj4gY29uZmlndXJlZCBvdXQgKGFuZCBJIGJlbGlldmUgaW50cm9k dWNpbmcgbmV3IHVzZXMgb2YgSVNfRVJSX09SX05VTEwoKSAKPj4gaXMgaW4gZ2VuZXJhbCBzdHJv bmdseSBkaXNjb3VyYWdlZC4pCj4+Cj4+IFJvYmluLgo+Pgo+Pj4gK30KPj4+ICsKPj4+ICtzdGF0 aWMgaW5saW5lIHN0cnVjdCBjbGtfYnVsa19kYXRhICpkZXZtX2Nsa19idWxrX2FsbG9jKHN0cnVj dCAKPj4+IGRldmljZSAqZGV2LAo+Pj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBpbnQgbnVtX2Nsa3MsCj4+PiArwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIGNvbnN0IGNoYXIgKipjbGtf aWRzKQo+Pj4gK3sKPj4+ICvCoMKgwqAgcmV0dXJuIE5VTEw7Cj4+PiArfQo+Pj4gKwo+Pj4gK3N0 YXRpYyBpbmxpbmUgdm9pZCBjbGtfYnVsa19mcmVlKHN0cnVjdCBjbGtfYnVsa19kYXRhICpjbGtz KQo+Pj4gK3sKPj4+ICt9Cj4+PiArCj4+PiDCoCBzdGF0aWMgaW5saW5lIHN0cnVjdCBjbGsgKmNs a19nZXQoc3RydWN0IGRldmljZSAqZGV2LCBjb25zdCBjaGFyICppZCkKPj4+IMKgIHsKPj4+IMKg wqDCoMKgwqAgcmV0dXJuIE5VTEw7Cj4+Cj4gQmVzdCByZWdhcmRzCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmRyaS1kZXZlbCBtYWlsaW5nIGxpc3QKZHJp LWRldmVsQGxpc3RzLmZyZWVkZXNrdG9wLm9yZwpodHRwczovL2xpc3RzLmZyZWVkZXNrdG9wLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2RyaS1kZXZlbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 From: robin.murphy@arm.com (Robin Murphy) Date: Tue, 20 Feb 2018 14:19:32 +0000 Subject: [PATCH 1/8] clk: Add clk_bulk_alloc functions In-Reply-To: References: <1519055046-2399-1-git-send-email-m.purski@samsung.com> <1519055046-2399-2-git-send-email-m.purski@samsung.com> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Marek, On 20/02/18 09:36, Marek Szyprowski wrote: > Hi Robin, > > On 2018-02-19 17:29, Robin Murphy wrote: >> Hi Maciej, >> >> On 19/02/18 15:43, Maciej Purski wrote: >>> When a driver is going to use clk_bulk_get() function, it has to >>> initialize an array of clk_bulk_data, by filling its id fields. >>> >>> Add a new function to the core, which dynamically allocates >>> clk_bulk_data array and fills its id fields. Add clk_bulk_free() >>> function, which frees the array allocated by clk_bulk_alloc() function. >>> Add a managed version of clk_bulk_alloc(). >> >> Seeing how every subsequent patch ends up with the roughly this same >> stanza: >> >> ????x = devm_clk_bulk_alloc(dev, num, names); >> ????if (IS_ERR(x) >> ??????? return PTR_ERR(x); >> ????ret = devm_clk_bulk_get(dev, x, num); >> >> I wonder if it might be better to simply implement: >> >> ????int devm_clk_bulk_alloc_get(dev, &x, num, names) >> >> that does the whole lot in one go, and let drivers that want to do >> more fiddly things continue to open-code the allocation. >> >> But perhaps that's an abstraction too far... I'm not all that familiar >> with the lie of the land here. > > Hmmm. This patchset clearly shows, that it would be much simpler if we > get rid of clk_bulk_data structure at all and let clk_bulk_* functions > to operate on struct clk *array[]. Typically the list of clock names > is already in some kind of array (taken from driver data or statically > embedded into driver), so there is little benefit from duplicating it > in clk_bulk_data. Sadly, I missed clk_bulk_* api discussion and maybe > there are other benefits from this approach. > > If not, I suggest simplifying clk_bulk_* api by dropping clk_bulk_data > structure and switching to clock ptr array: > > int clk_bulk_get(struct device *dev, int num_clock, struct clk *clocks[], > ??? ??? ??? ???? const char *clk_names[]); > int clk_bulk_prepare(int num_clks, struct clk *clks[]); > int clk_bulk_enable(int num_clks, struct clk *clks[]); > ... Yes, that's certainly a possibility; if on the other hand there are desirable reasons for the encapsulation (personally, I do think it's quite neat), then maybe num_clocks should get pushed down into clk_bulk_data as well - then with dedicated alloc/free functions as proposed here it could become a simple opaque cookie as far as callers are concerned. I also haven't looked into the origins of the bulk API design, though; I've just been familiarising myself from the perspective of reviewing general clk API usage in drivers. Robin. >>> Signed-off-by: Maciej Purski >>> --- >>> ? drivers/clk/clk-bulk.c?? | 16 ++++++++++++ >>> ? drivers/clk/clk-devres.c | 37 +++++++++++++++++++++++++--- >>> ? include/linux/clk.h????? | 64 >>> ++++++++++++++++++++++++++++++++++++++++++++++++ >>> ? 3 files changed, 113 insertions(+), 4 deletions(-) >>> >> >> [...] >>> @@ -598,6 +645,23 @@ struct clk *clk_get_sys(const char *dev_id, >>> const char *con_id); >>> ? ? #else /* !CONFIG_HAVE_CLK */ >>> ? +static inline struct clk_bulk_data *clk_bulk_alloc(int num_clks, >>> +?????????????????????????? const char **clk_ids) >>> +{ >>> +??? return NULL; >> >> Either way, is it intentional not returning an ERR_PTR() value in this >> case? Since NULL will pass an IS_ERR() check, it seems a bit fragile >> for an allocation call to apparently succeed when the whole API is >> configured out (and I believe introducing new uses of IS_ERR_OR_NULL() >> is in general strongly discouraged.) >> >> Robin. >> >>> +} >>> + >>> +static inline struct clk_bulk_data *devm_clk_bulk_alloc(struct >>> device *dev, >>> +??????????????????????????? int num_clks, >>> +??????????????????????????? const char **clk_ids) >>> +{ >>> +??? return NULL; >>> +} >>> + >>> +static inline void clk_bulk_free(struct clk_bulk_data *clks) >>> +{ >>> +} >>> + >>> ? static inline struct clk *clk_get(struct device *dev, const char *id) >>> ? { >>> ????? return NULL; >> > Best regards