Date:   Tue, 20 Feb 2018 14:19:32 +0000
From:   Robin Murphy <robin.murphy@....com>
To:     Marek Szyprowski <m.szyprowski@...sung.com>,
        Maciej Purski <m.purski@...sung.com>,
        linux-media@...r.kernel.org, linux-samsung-soc@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org,
        dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
        linux-clk@...r.kernel.org
Cc:     David Airlie <airlied@...ux.ie>,
        Michael Turquette <mturquette@...libre.com>,
        Kamil Debski <kamil@...as.org>,
        Andrzej Hajda <a.hajda@...sung.com>,
        Sylwester Nawrocki <s.nawrocki@...sung.com>,
        Thibault Saunier <thibault.saunier@....samsung.com>,
        Joonyoung Shim <jy0922.shim@...sung.com>,
        Russell King <linux@...linux.org.uk>,
        Krzysztof Kozlowski <krzk@...nel.org>,
        Javier Martinez Canillas <javier@....samsung.com>,
        Kukjin Kim <kgene@...nel.org>,
        Hoegeun Kwon <hoegeun.kwon@...sung.com>,
        Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
        Inki Dae <inki.dae@...sung.com>,
        Jeongtae Park <jtp.park@...sung.com>,
        Jacek Anaszewski <jacek.anaszewski@...il.com>,
        Andrzej Pietrasiewicz <andrzej.p@...sung.com>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Stephen Boyd <sboyd@...nel.org>,
        Seung-Woo Kim <sw0312.kim@...sung.com>,
        Hans Verkuil <hansverk@...co.com>,
        Kyungmin Park <kyungmin.park@...sung.com>
Subject: Re: [PATCH 1/8] clk: Add clk_bulk_alloc functions

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 <m.purski@...sung.com>
>>> ---
>>>   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

Powered by blists - more mailing lists