[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <55B0131F.80404@codeaurora.org>
Date: Wed, 22 Jul 2015 15:03:11 -0700
From: Stephen Boyd <sboyd@...eaurora.org>
To: Vaibhav Hiremath <vaibhav.hiremath@...aro.org>
CC: Krzysztof Kozlowski <k.kozlowski@...sung.com>,
linux-arm-kernel@...ts.infradead.org, robh+dt@...nel.org,
mturquette@...libre.com, lee.jones@...aro.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-clk@...r.kernel.org
Subject: Re: [PATCH 3/4] clk: 88pm800: Add clk provider driver for 88pm800
family of devices
On 07/22/2015 01:16 AM, Vaibhav Hiremath wrote:
>
>
> On Wednesday 22 July 2015 12:16 PM, Krzysztof Kozlowski wrote:
>>
>> I am really busy now so I am not following closely other discussions. I
>> assume you are referring to clk-s2mps11.c. The of_node_put() matches
>> of_get_child_by_name() when parsing DT.
>>
>> So why not of_node_put() just after parsing DT? Well, the result of
>> of_get_child_by_name() is stored in state container for entire device
>> life-cycle so we can use it in of_clk_del_provider().
>>
>> That was the idea behind it. If it looks incorrect I would be happy to
>> see a patch :) .
>>
>
> About to respond, I digged more on kobject stuff and sequence in
> of/dynamic.c and
>
> I think you are right, we need of_node_put, as a result of
> of_get_child_by_name().
>
> Stephen,
> Please let me know if you think otherwise.
>
Yes, sounds fine. I was thinking that we grab the reference to the node
in of_clk_add_provider() so dropping it here was to undo that, but that
isn't true. It probably can be dropped after we register the provider
because adding the provider will keep it pinned, but this way is more
symmetric so it's fine.
Either way, the error path on probe doesn't call of_node_put(), so
that's a leak.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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