From: Jerome Brunet <jbrunet@baylibre.com>
To: Stephen Boyd <sboyd@kernel.org>,
Michael Turquette <mturquette@baylibre.com>
Cc: linux-kernel@vger.kernel.org, linux-clk@vger.kernel.org,
Miquel Raynal <miquel.raynal@bootlin.com>,
Russell King <linux@armlinux.org.uk>
Subject: Re: [PATCH 2/9] clk: Introduce get_parent_hw clk op
Date: Thu, 31 Jan 2019 19:40:07 +0100 [thread overview]
Message-ID: <97c2375f41fe7dabc4d71f66c9808912eb0ce611.camel@baylibre.com> (raw)
In-Reply-To: <154888381385.169292.12776041058756822056@swboyd.mtv.corp.google.com>
On Wed, 2019-01-30 at 13:30 -0800, Stephen Boyd wrote:
> > With this quirk, CCF is making an assumption that might be wrong.
> >
> > The quirk is very easy put in the get_parent() callback of the said
> > driver, or
> > even better, don't provide the callback if it should not be called.
> >
> > I understand the need for a cautious approach. It seems I'm only one with
> > that
> > issue right now and since I have a work around, there is no rush. But we
> > must
> > have plan to make it right.
> >
> > To be clear, I'm not against your new API but I don't think it should be a
> > reason to keep a broken behavior the framework.
> >
>
> So do you think you can use this new clk_op and ignore the problems with
> the .get_parent clk op? Putting effort into fixing the .get_parent
> design isn't very useful from my perspective. There's more than just the
> problem that we don't call it when .num_parents is 1. There's the
> inability to return errors without doing weird things to return an index
> out of range and there isn't any way for us to really know if the clk is
> an orphan or not. If we can migrate all drivers to use the new clk op
> then we can fix these problems too, and deprecate and eventually remove
> the broken by design .get_parent clk op API.
Stephen, I have nothing against your new API, I'm sure it will solve many
issues
I'm also quite sure that, like round_rate() and determine_rate(), migrating to
the new API won't happen overnight. We are likely to still see get_parent()
for a while. I don't understand why we would keep something wrong when it is
that easy to fix.
I have spent quite sometime debugging this weird behavior of CCF, I'd prefer
if it can avoided for others.
Yes, fixing the case I reported does not solves all the problem you have
mentionned. Keeping this bug does not help either, AFAICT.
The fact is that get_parent() already return out of bound values on some
occasion, and we already have to deal with this when converting the index to
parent clk_hw pointer. Doing it in the same way when num_parent == 1 does not
change anything.
I really don't understand why you insist on keeping this special case for
num_parent == 1, when we know it is not coherent.
Considering, that I already proposed the fix, what is the effort here ?
If it is fixing the driver that rely this weird thing, I'd be happy to do it.
Regards
Jerome
next prev parent reply other threads:[~2019-01-31 18:40 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-29 6:10 [PATCH 0/9] Rewrite clk parent handling Stephen Boyd
2019-01-29 6:10 ` [PATCH 1/9] clk: Combine __clk_get() and __clk_create_clk() Stephen Boyd
2019-01-29 6:10 ` [PATCH 2/9] clk: Introduce get_parent_hw clk op Stephen Boyd
2019-01-29 9:34 ` Jerome Brunet
2019-01-29 21:15 ` Stephen Boyd
2019-01-30 9:53 ` Jerome Brunet
2019-01-30 21:30 ` Stephen Boyd
2019-01-31 18:40 ` Jerome Brunet [this message]
2019-02-06 0:01 ` Stephen Boyd
2019-02-13 9:16 ` Jerome Brunet
2019-02-15 17:01 ` Stephen Boyd
2019-02-11 16:09 ` Jeffrey Hugo
2019-02-15 18:47 ` Stephen Boyd
2019-02-15 19:29 ` Jeffrey Hugo
2019-02-15 21:29 ` Stephen Boyd
2019-02-15 21:34 ` Jeffrey Hugo
2019-01-29 6:10 ` [PATCH 3/9] clk: core: clarify the check for runtime PM Stephen Boyd
2019-01-29 6:10 ` [PATCH 4/9] clk: Introduce of_clk_get_hw_from_clkspec() Stephen Boyd
2019-01-29 6:10 ` [PATCH 5/9] clk: Inform the core about consumer devices Stephen Boyd
2019-01-29 6:10 ` [PATCH 6/9] clk: Move of_clk_*() APIs into clk.c from clkdev.c Stephen Boyd
2019-01-29 6:10 ` [PATCH 7/9] clk: Allow parents to be specified without string names Stephen Boyd
2019-01-29 10:12 ` Jerome Brunet
2019-01-29 18:56 ` Stephen Boyd
2019-01-29 21:08 ` Jerome Brunet
2019-02-13 9:32 ` Jerome Brunet
2019-02-15 21:13 ` Stephen Boyd
2019-01-29 6:10 ` [PATCH 8/9] clk: qcom: gcc-sdm845: Migrate to DT parent mapping Stephen Boyd
2019-01-29 6:10 ` [PATCH 9/9] arm64: dts: qcom: Specify XO clk as input to GCC node Stephen Boyd
2019-01-29 10:12 ` [PATCH 0/9] Rewrite clk parent handling Miquel Raynal
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=97c2375f41fe7dabc4d71f66c9808912eb0ce611.camel@baylibre.com \
--to=jbrunet@baylibre.com \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=miquel.raynal@bootlin.com \
--cc=mturquette@baylibre.com \
--cc=sboyd@kernel.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).