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]
Date:   Thu, 7 Nov 2019 15:12:09 -0700
From:   Jeffrey Hugo <jeffrey.l.hugo@...il.com>
To:     Stephen Boyd <sboyd@...nel.org>
Cc:     Bjorn Andersson <bjorn.andersson@...aro.org>,
        Michael Turquette <mturquette@...libre.com>,
        Andy Gross <agross@...nel.org>,
        Marc Gonzalez <marc.w.gonzalez@...e.fr>,
        MSM <linux-arm-msm@...r.kernel.org>, linux-clk@...r.kernel.org,
        lkml <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v5 1/3] clk: qcom: Allow constant ratio freq tables for rcg

On Thu, Nov 7, 2019 at 2:43 PM Stephen Boyd <sboyd@...nel.org> wrote:
>
> Quoting Jeffrey Hugo (2019-10-31 11:57:15)
> > Some RCGs (the gfx_3d_src_clk in msm8998 for example) are basically just
> > some constant ratio from the input across the entire frequency range.  It
> > would be great if we could specify the frequency table as a single entry
> > constant ratio instead of a long list, ie:
> >
> >         { .src = P_GPUPLL0_OUT_EVEN, .pre_div = 3 },
> >         { }
> >
> > So, lets support that.
> >
> > We need to fix a corner case in qcom_find_freq() where if the freq table
> > is non-null, but has no frequencies, we end up returning an "entry" before
> > the table array, which is bad.  Then, we need ignore the freq from the
> > table, and instead base everything on the requested freq.
> >
> > Suggested-by: Stephen Boyd <sboyd@...nel.org>
> > Signed-off-by: Jeffrey Hugo <jeffrey.l.hugo@...il.com>
> > ---
>
> Applied to clk-next and fixed the space thing. I guess ceil/floor
> rounding isn't a problem?
>

Thanks for fixing the nit.

Hmm.  Looking back at it, floor is only used with the rcg_floor_ops.
Right now, you can't use a constant ratio table with rcg_floor_ops -
looks like you'd probably hit a null pointer dereference.  I'm having
trouble seeing how the floor operation would work with this constant
ratio idea in a way that would be different than the normal rcg_ops.
I think I would say that either you have a good reason for using the
constant ratio table, in which case you should be using the normal
rcg_ops, or you have a good reason for using floor which is then
incompatible with a constant ratio table.  If you think that the
constant ratio table concept should be applied to floor ops, can you
please detail what you expect the behavior to be?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ