From: sebastian.hesselbarth@gmail.com (Sebastian Hesselbarth)
To: linux-arm-kernel@lists.infradead.org
Subject: AM335x OMAP2 common clock external fixed-clock registration
Date: Thu, 16 Apr 2015 22:37:19 +0200 [thread overview]
Message-ID: <55301D7F.30708@gmail.com> (raw)
In-Reply-To: <20150416161756.GA27590@deathray>
On 16.04.2015 18:17, Michael Welling wrote:
> On Thu, Apr 16, 2015 at 07:32:32AM +0300, Tero Kristo wrote:
>> On 04/15/2015 11:51 PM, Michael Welling wrote:
>>> On Wed, Apr 15, 2015 at 01:45:53PM -0700, Mike Turquette wrote:
>>>> On Wed, Apr 15, 2015 at 12:47 PM, Michael Welling <mwelling@ieee.org> wrote:
[...]
>>>>> There is still an issue with the si5351.
>>>>>
>>>>> I had to comment out the clk_put here for the frequency to show up:
>>>>> http://lxr.free-electrons.com/source/drivers/clk/clk-si5351.c#L1133
>>>>>
>>>>> Ideas?
>>>>
>>>> What is the most recent upstream commit that you are based on?
>>>
>>> I am working from 4.0.0-rc7.
>>>
>>> 7b43b47373d40d557cd7e1a84a0bd8ebc4d745ab
>>
>> Hmm, I wonder why si5351 calls clk_put immediately after of_clk_get
>> in the first place, as far as I understand this destroys the clock
>> handle, which is still being used later in the code.
>
> Not sure how this ever worked. This has been in the code since the
> initial commit.
The reason it worked before may be related with recent rework of
clk_put() itself and clk cookies instead of pointers. I lost track on
the recent clk subsystem changes here, sorry.
However, droping the clk immediately surely isn't right.
The thing is, we can remove the clk_put() just because there is no
_remove() for that driver. I remember that back in the days the driver
was mainlined, clk removal wasn't too easy.
FWIW, as soon as _remove() support will be added by someone, we'll have
to rethink passing struct clk* by platform_data or at least
double-check if we ever used [of_]clk_get() to obtain it.
Mind to send a patch removing the clk_put() on !IS_ERR and add a proper
error path instead? While of_clk_get() is the only calls that need
cleanup on error in si5351_dt_parse() we should probably move that
calls to the end of this function. Otherwise we'd also have to cleanup
on every of_parse_foo() failure.
Sebastian
next prev parent reply other threads:[~2015-04-16 20:37 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-14 21:17 AM335x OMAP2 common clock external fixed-clock registration Michael Welling
2015-04-15 6:34 ` Tero Kristo
2015-04-15 14:09 ` Michael Welling
2015-04-15 18:43 ` Tero Kristo
2015-04-15 19:47 ` Michael Welling
2015-04-15 20:45 ` Mike Turquette
2015-04-15 20:51 ` Michael Welling
2015-04-16 4:32 ` Tero Kristo
2015-04-16 16:17 ` Michael Welling
2015-04-16 20:37 ` Sebastian Hesselbarth [this message]
2015-04-16 22:09 ` Michael Welling
2015-04-16 23:23 ` Sebastian Hesselbarth
2015-04-17 2:00 ` Michael Welling
2015-04-17 7:13 ` Tero Kristo
2015-04-17 9:12 ` Sebastian Hesselbarth
2015-04-17 10:18 ` Russell King - ARM Linux
2015-04-17 19:06 ` Michael Welling
2015-04-17 19:39 ` Russell King - ARM Linux
2015-04-17 19:56 ` Michael Turquette
2015-04-17 16:59 ` Michael Welling
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55301D7F.30708@gmail.com \
--to=sebastian.hesselbarth@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).