linux-kernel - Re: [PATCH 2/9] clk: Introduce get_parent

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <97c2375f41fe7dabc4d71f66c9808912eb0ce611.camel@baylibre.com>
Date:   Thu, 31 Jan 2019 19:40:07 +0100
From:   Jerome Brunet <jbrunet@...libre.com>
To:     Stephen Boyd <sboyd@...nel.org>,
        Michael Turquette <mturquette@...libre.com>
Cc:     linux-kernel@...r.kernel.org, linux-clk@...r.kernel.org,
        Miquel Raynal <miquel.raynal@...tlin.com>,
        Russell King <linux@...linux.org.uk>
Subject: Re: [PATCH 2/9] clk: Introduce get_parent_hw clk op

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