All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Boyd <sboyd@codeaurora.org>
To: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Mike Turquette <mturquette@linaro.org>,
	linux-kernel@vger.kernel.org, kernel@pengutronix.de
Subject: Re: [PATCH v2] clk: Do not complain about correctly set read-only muxes when assigning clock parents from device tree
Date: Fri, 09 Jan 2015 10:51:40 -0800	[thread overview]
Message-ID: <54B0233C.60201@codeaurora.org> (raw)
In-Reply-To: <1420815016.3914.16.camel@pengutronix.de>

On 01/09/2015 06:50 AM, Philipp Zabel wrote:
> Hi Stephen,
>
> Am Donnerstag, den 08.01.2015, 13:32 -0800 schrieb Stephen Boyd:
> [...]
>> Why not do this in the core? As far as I can tell other drivers could
>> run into the same problem, no? Does this work?
>>
>> -----8<-------
>>
>> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
>> index f4963b7d4e17..3278645f4729 100644
>> --- a/drivers/clk/clk.c
>> +++ b/drivers/clk/clk.c
>> @@ -1677,16 +1677,18 @@ int clk_set_parent(struct clk *clk, struct clk *parent)
>>  	if (!clk)
>>  		return 0;
>>  
>> -	/* verify ops for for multi-parent clks */
>> -	if ((clk->num_parents > 1) && (!clk->ops->set_parent))
>> -		return -ENOSYS;
>> -
>>  	/* prevent racing with updates to the clock topology */
>>  	clk_prepare_lock();
>>  
>>  	if (clk->parent == parent)
>>  		goto out;
>>  
>> +	/* verify ops for for multi-parent clks */
>> +	if ((clk->num_parents > 1) && (!clk->ops->set_parent)) {
>> +		ret = -ENOSYS;
>> +		goto out;
>> +	}
>> +
>>  	/* check that we are allowed to re-parent if the clock is in use */
>>  	if ((clk->flags & CLK_SET_PARENT_GATE) && clk->prepare_count) {
>>  		ret = -EBUSY;
> "[PATCH] clk: make set_parent succeed for any clock if the parent to be
> set is the same as the current parent" ?
>
> It works, but it also changes the API, as it makes
>    clk_set_parent(some_non_mux, its_current_parent)
> succeed instead of return -ENOSYS.

I would think a non_mux clk would have clk->num_parents == 1, so I don't
see how it would return -ENOSYS here. What you mention should succeed
today. Otherwise we have a bug.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project


  reply	other threads:[~2015-01-09 18:51 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-06 15:45 [PATCH v2] clk: Do not complain about correctly set read-only muxes when assigning clock parents from device tree Philipp Zabel
2015-01-08 21:32 ` Stephen Boyd
2015-01-09 14:50   ` Philipp Zabel
2015-01-09 18:51     ` Stephen Boyd [this message]
2015-01-12  8:42       ` Philipp Zabel
  -- strict thread matches above, loose matches on Subject: below --
2014-12-02 10:44 Philipp Zabel

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=54B0233C.60201@codeaurora.org \
    --to=sboyd@codeaurora.org \
    --cc=kernel@pengutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mturquette@linaro.org \
    --cc=p.zabel@pengutronix.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.