[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <54086A77.6050708@collabora.com>
Date: Thu, 04 Sep 2014 15:34:47 +0200
From: Tomeu Vizoso <tomeu.vizoso@...labora.com>
To: Stephen Boyd <sboyd@...eaurora.org>,
Mike Turquette <mturquette@...aro.org>
CC: Stephen Warren <swarren@...dotorg.org>,
Tomasz Figa <t.figa@...sung.com>, linux-kernel@...r.kernel.org,
Javier Martinez Canillas <javier.martinez@...labora.co.uk>,
rabin@....in, Thierry Reding <thierry.reding@...il.com>,
Peter De Schrijver <pdeschrijver@...dia.com>,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v8 4/7] clk: use struct clk only for external API
On 09/04/2014 01:45 AM, Stephen Boyd wrote:
> On 09/01/14 08:34, Tomeu Vizoso wrote:
>
>>
>> NOTE: with this patch, clk_get_parent() behaves like clk_get(), i.e. it
>> needs to be matched with a clk_put(). Otherwise, memory will leak.
>>
> [...]
>> }
>> +EXPORT_SYMBOL_GPL(clk_provider_get_parent);
>> +
>> +/**
>> + * clk_get_parent - return the parent of a clk
>> + * @clk_user: the clk whose parent gets returned
>> + *
>> + * Simply returns clk->parent. Returns NULL if clk is NULL.
>
> We should at least document here that clk_put() is expected to be called
> when it's not being used.
Good point.
> I wonder why it's this way though. Why can't
> every clk_core have a private clk pointer to it's parent that's created
> during registration time? Then we just hand that out for
> clk_get_parent() and destroy it when the clk_core is freed?
Well, that wouldn't be a per-user clock any more, right? I see though
how it would be desirable not to burden the caller with having to free
the per-user clk.
Thanks,
Tomeu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists