Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PATCH 2/9] clk: Introduce get_parent_hw clk op
From:   Stephen Boyd <sboyd@kernel.org>
Message-ID: <154941131193.169292.7500057932043013834@swboyd.mtv.corp.google.com>
Cc:     linux-kernel@vger.kernel.org, linux-clk@vger.kernel.org,
        Miquel Raynal <miquel.raynal@bootlin.com>,
        Russell King <linux@armlinux.org.uk>
References: <20190129061021.94775-1-sboyd@kernel.org> <20190129061021.94775-3-sboyd@kernel.org> <e303573aefeaf6a7e3a4b1d820e801354ff900b4.camel@baylibre.com> <154879654428.136743.10048771201181501034@swboyd.mtv.corp.google.com> <ff76dcdb4ceb3209619e5348ed7b575a8ae9df8d.camel@baylibre.com> <154888381385.169292.12776041058756822056@swboyd.mtv.corp.google.com> <97c2375f41fe7dabc4d71f66c9808912eb0ce611.camel@baylibre.com>
User-Agent: alot/0.8
To:     Jerome Brunet <jbrunet@baylibre.com>,
        Michael Turquette <mturquette@baylibre.com>
In-Reply-To: <97c2375f41fe7dabc4d71f66c9808912eb0ce611.camel@baylibre.com>
Date:   Tue, 05 Feb 2019 16:01:51 -0800
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Quoting Jerome Brunet (2019-01-31 10:40:07)
> On Wed, 2019-01-30 at 13:30 -0800, Stephen Boyd wrote:
> > > With this quirk, CCF is making an assumption that might be wrong.
> > >=20
> > > 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.
> > >=20
> > > 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.
> > >=20
> > > 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.
> > >=20
> >=20
> > 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.
>=20
> Stephen, I have nothing against your new API, I'm sure it will solve many
> issues
>=20
> I'm also quite sure that, like round_rate() and determine_rate(), migrati=
ng 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.
>=20
> I have spent quite sometime debugging this weird behavior of CCF, I'd pre=
fer
> if it can avoided for others.
>=20
> Yes, fixing the case I reported does not solves all the problem you have
> mentionned. Keeping this bug does not help either, AFAICT.
>=20
> 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 =3D=3D 1 =
does not
> change anything.
>=20
> I really don't understand why you insist on keeping this special case for
> num_parent =3D=3D 1, when we know it is not coherent.
>=20
> 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.
>=20
>=20

Ok. I'm happy to merge your patch to always call the .get_parent clk op
when num_parents > 0, but please fix all the drivers and analyze all the
implementations of .get_parent to make sure that they aren't broken by
the change in behavior. Furthermore, please add a debug/warning message
into the code when .get_parent returns a number outside of the range of
[0, num_parents) so that they can be converted to use .get_parent_hw
instead. Ideally there wouldn't be anything returning a parent index
outside the range of possible parents from .get_parent because this
analysis of drivers would find those implementations and migrate them to
.get_parent_hw instead.

In parallel, I'd like to convert all drivers to use .get_parent_hw
instead of .get_parent and then remove the .get_parent clk op right
away. I'll start a sweep of the users of clk_hw_get_parent_by_index() (I
see 50 calls in the tree right now) and see if I can convert them to
handle errors returned from that API, probably by just continuing and
ignoring errors. I'll start doing the same conversion for .round_rate
and .determine_rate so that we can get rid of that duplicate clk op as
well. Hopefully that's a mostly mechanical conversion.

For now I'll move this patch to the end of this series so that it
doesn't hold things up otherwise.